Topik ini menjelaskan pertanyaan umum dan solusi terkait pembuatan serta pengelolaan kluster. - Container Service for Kubernetes

Topik ini menjelaskan masalah umum dan solusinya terkait pembuatan, penggunaan, dan pengelolaan kluster.

Bagaimana cara memigrasikan kluster Kubernetes yang dikelola sendiri ke ACK?

Alibaba Cloud Container Service for Kubernetes (ACK) menyediakan solusi mulus untuk memigrasikan kluster Kubernetes yang dikelola sendiri ke kluster ACK. Solusi ini memastikan bisnis Anda tidak terganggu selama migrasi. Untuk informasi selengkapnya, lihat Ikhtisar Solusi Migrasi Kubernetes.

Apakah kluster dengan sistem operasi Alibaba Cloud Linux kompatibel dengan citra kontainer berbasis CentOS?

Ya, kompatibel. Kluster yang menjalankan Alibaba Cloud Linux kompatibel dengan citra kontainer berbasis CentOS. Untuk informasi selengkapnya, lihat Alibaba Cloud Linux 3.

Jika saya memilih runtime kontainer containerd saat membuat kluster, dapatkah saya mengubahnya menjadi Docker nanti?

Tidak, tidak bisa. Setelah kluster dibuat, Anda tidak dapat mengubah runtime kontainernya. Namun, Anda dapat membuat kelompok node yang menggunakan runtime kontainer berbeda dalam kluster yang sama. Untuk informasi selengkapnya, lihat Membuat dan mengelola kelompok node.

Untuk memigrasikan runtime kontainer sebuah node dari Docker ke containerd, lihat Migrasikan runtime kontainer sebuah node dari Docker ke containerd.

Catatan

Docker tidak didukung sebagai runtime kontainer bawaan untuk kluster yang menjalankan Kubernetes 1.24 atau versi lebih baru. Anda harus menggunakan containerd sebagai runtime kelompok node untuk kluster tersebut.

Apa perbedaan antara runtime containerd, Docker, dan sandboxed container?

Container Service for Kubernetes mendukung tiga jenis runtime: containerd, Docker, dan Sandboxed-Container. Kami merekomendasikan Anda menggunakan containerd sebagai runtime kontainer. Anda dapat menggunakan Docker sebagai runtime kontainer pada kluster yang menjalankan Kubernetes 1.22 dan versi sebelumnya. Anda dapat menggunakan Sandboxed-Container sebagai runtime kontainer pada kluster yang menjalankan Kubernetes 1.24 dan versi sebelumnya. Untuk perbandingan antara runtime ini, lihat Perbandingan runtime containerd, Sandboxed-Container, dan Docker. Jika kluster Anda menggunakan Docker sebagai runtime kontainer, Anda harus memigrasikan runtime kontainer ke containerd sebelum memperbarui versi Kubernetes kluster Anda ke 1.24 atau versi lebih baru. Untuk informasi selengkapnya, lihat Migrasikan runtime kontainer node dari Docker ke containerd.

Apakah Container Service for Kubernetes (ACK) tersertifikasi untuk MLPS 2.0 Level 3?

Ya, benar. Anda dapat mengaktifkan perlindungan terklasifikasi untuk kluster Anda dan mengonfigurasi kebijakan pemeriksaan baseline. Berdasarkan Alibaba Cloud Linux, Anda dapat menerapkan MLPS 2.0 Level 3 dan mengonfigurasi pemeriksaan baseline kepatuhan perlindungan terklasifikasi untuk memenuhi persyaratan berikut:

Otentikasi identitas
Kontrol akses
Audit keamanan
Pencegahan intrusi
Pencegahan kode berbahaya

Untuk informasi selengkapnya, lihat Petunjuk pengerasan ACK MLPS.

Apakah kluster ACK mendukung Istio?

Ya, benar. Anda dapat menggunakan Service Mesh (ASM) milik Alibaba Cloud. ASM adalah produk service mesh yang sepenuhnya kompatibel dengan Istio komunitas. ASM menyediakan bidang kontrol yang sepenuhnya dikelola sehingga Anda dapat fokus mengembangkan dan menerapkan aplikasi bisnis Anda. ASM mendukung berbagai sistem operasi untuk node ACK dan berbagai plugin jaringan yang diterapkan dalam kluster. Anda dapat menambahkan kluster ACK yang sudah ada ke instans ASM untuk menggunakan fitur-fitur seperti manajemen lalu lintas, penanganan gangguan, pemantauan terpadu, dan manajemen log. Untuk informasi selengkapnya, lihat Menambahkan kluster ke instans ASM. Untuk informasi penagihan ASM, lihat Penagihan ASM.

Bagaimana cara mengumpulkan informasi diagnostik untuk kluster Kubernetes?

Jika kluster Kubernetes mengalami masalah atau sebuah node tidak normal, Anda dapat menggunakan fitur diagnostik yang disediakan oleh ACK untuk membantu menemukan masalah dalam kluster. Untuk informasi selengkapnya, lihat Gunakan diagnostik kluster.

Jika fitur diagnostik kluster tidak memenuhi kebutuhan Anda, Anda dapat mengumpulkan informasi diagnostik dari node master dan node pekerja yang tidak normal. Ikuti langkah-langkah berikut untuk mengumpulkan informasi dari node Linux atau Windows.

Kumpulkan informasi diagnostik dari node Linux

Node pekerja dapat menjalankan Linux atau Windows, tetapi node master hanya dapat menjalankan Linux. Metode berikut berlaku untuk node master maupun node pekerja yang menjalankan Linux. Contoh ini menggunakan node master.

Login ke node master kluster Kubernetes dan jalankan perintah berikut untuk mengunduh skrip diagnostik.
```
curl -o /usr/local/bin/diagnose_k8s.sh http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/diagnose/diagnose_k8s.sh
```
Catatan
Skrip diagnostik untuk node Linux hanya dapat diunduh dari wilayah Tiongkok (Hangzhou).
Jalankan perintah berikut untuk memberikan izin eksekusi pada skrip diagnostik.
```
chmod u+x /usr/local/bin/diagnose_k8s.sh
```
Jalankan perintah berikut untuk berpindah ke direktori yang ditentukan.
```
cd /usr/local/bin
```

Jalankan perintah berikut untuk menjalankan skrip diagnostik.

diagnose_k8s.sh

Keluaran berikut akan ditampilkan. Nama file log yang dihasilkan oleh skrip diagnostik bervariasi. Pada contoh ini, file tersebut bernama diagnose_1514939155.tar.gz.

......
+ echo 'please get diagnose_1514939155.tar.gz for diagnostics'
please get diagnose_1514939155.tar.gz for diagnostics
+ echo 'Please upload diagnose_1514939155.tar.gz'
Please upload diagnose_1514939155.tar.gz

Jalankan perintah berikut untuk melihat file yang menyimpan informasi diagnostik kluster.
```
ls -ltr | grep diagnose_1514939155.tar.gz
```
Catatan
Ganti diagnose_1514939155.tar.gz dengan nama file log yang sebenarnya.

Kumpulkan informasi diagnostik dari node Windows

Untuk mengumpulkan informasi diagnostik dari node pekerja yang menjalankan Windows, unduh dan jalankan skrip diagnostik.

Catatan

Windows hanya dapat digunakan untuk node pekerja.

Login ke node pekerja yang tidak normal, buka jendela Run, masukkan cmd, lalu klik OK untuk membuka antarmuka baris perintah.
Jalankan perintah berikut untuk memasuki mode PowerShell.
```
powershell
```
Jalankan perintah berikut untuk mengunduh dan menjalankan skrip diagnostik.
Skrip diagnostik untuk node Windows dapat diunduh dari wilayah tempat kluster berada. Ganti [$Region_ID] dalam perintah dengan ID wilayah yang sebenarnya.
```
Invoke-WebRequest -UseBasicParsing -Uri http://aliacs-k8s-[$Region_ID].oss-[$Region_ID].aliyuncs.com/public/pkg/windows/diagnose/diagnose.ps1 | Invoke-Expression
```
Keluaran berikut menunjukkan bahwa informasi diagnostik telah dikumpulkan.
```
INFO: Compressing diagnosis clues ...
INFO: ...done
INFO: Please get diagnoses_1514939155.zip for diagnostics
```
Catatan
File diagnoses_1514939155.zip disimpan ke direktori tempat skrip dijalankan.

Bagaimana cara memecahkan masalah dalam kluster ACK?

1. Periksa node kluster

Jalankan perintah berikut untuk melihat status node dalam kluster. Pastikan semua node ada dan berada dalam status Ready.
```
kubectl get nodes
```
Keluaran yang diharapkan mirip dengan berikut.
- Jika semua node ada dan berada dalam status Ready, maka node kluster normal.
- Jika sebuah node tidak normal, lanjutkan ke Langkah 2.
Jalankan perintah berikut untuk melihat informasi detail dan event untuk sebuah node.
Ganti [$NODE_NAME] dengan nama node Anda.
```
kubectl describe node [$NODE_NAME]
```
Catatan
Untuk informasi tentang keluaran kubectl, lihat Status node.

2. Periksa komponen kluster

Jika Anda tidak dapat mengidentifikasi masalah setelah memeriksa node kluster, lanjutkan untuk memeriksa log komponen pada bidang kontrol.

Jalankan perintah berikut untuk melihat semua komponen dalam namespace kube-system.
```
kubectl get pods -n kube-system
```
Keluaran yang diharapkan sebagai berikut. Pod dengan nama yang diawali `kube-` adalah komponen sistem kluster Kubernetes. Pod dengan nama yang diawali `coredns-` adalah plugin DNS. Keluaran yang diharapkan menunjukkan bahwa komponen berada dalam status normal. Jika sebuah komponen berada dalam status tidak normal, lanjutkan ke langkah berikutnya.
Jalankan perintah berikut untuk melihat log komponen yang tidak normal guna menemukan dan menyelesaikan masalah.
Ganti [$Component_Name] dengan nama komponen yang tidak normal.
```
kubectl logs -f [$Component_Name] -n kube-system
```

3. Periksa komponen kubelet

Jalankan perintah berikut untuk memeriksa status kubelet.
```
systemctl status kubelet
```
Jika status kubelet tidak aktif (running), jalankan perintah berikut untuk melihat log kubelet guna menemukan dan menyelesaikan masalah.
```
journalctl -u kubelet
```

Masalah umum kluster

Tabel berikut mencantumkan beberapa penyebab umum kegagalan kluster ACK dan solusinya.

Skenario Pemecahan Masalah	Solusi
Komponen API Server atau komponen master berhenti berjalan: Anda tidak dapat membuat, menghentikan, atau memperbarui sumber daya, seperti pod, layanan, dan deployment. Pod dan layanan yang sudah ada tetap berjalan kecuali jika perlu memanggil API ACK, seperti Kubernetes Dashboard.	Komponen ACK memiliki fitur ketersediaan tinggi bawaan. Periksa apakah komponen itu sendiri tidak normal. Misalnya, API Server kluster ACK secara default menggunakan instans SLB. Anda dapat memecahkan masalah instans SLB untuk menentukan penyebab status tidak normal.
Data backend untuk API Server hilang: API Server tidak dapat dimulai. Pod dan layanan yang sudah ada tetap berjalan kecuali jika perlu memanggil API ACK, seperti Kubernetes Dashboard. Anda harus memulihkan atau membangun ulang data API Server untuk memulai API Server.	Jika Anda telah membuat snapshot, Anda dapat memulihkan data dari snapshot untuk menyelesaikan masalah. Jika Anda belum membuat snapshot, Anda dapat mengajukan tiket. Setelah masalah terselesaikan, Anda dapat menggunakan metode berikut untuk mencegahnya terjadi lagi: Gunakan plugin volume yang disediakan oleh ACK untuk mempertahankan data. Untuk informasi selengkapnya, lihat Gunakan volume disk yang disediakan secara dinamis. Buat snapshot secara berkala untuk volume yang dikelola oleh kubelet. Untuk informasi selengkapnya, lihat Buat snapshot untuk satu volume disk.
Sebuah node mati, dan semua pod pada node tersebut berhenti berjalan.	Gunakan beban kerja, seperti deployment, StatefulSet, atau DaemonSet, untuk membuat pod alih-alih membuat pod secara langsung. Hal ini mencegah pod gagal dijadwalkan ke node sehat lainnya.
Komponen kubelet gagal: Pod tidak dapat dibuat pada node dengan kubelet yang tidak normal. Kubelet mungkin telah menghapus beberapa pod secara salah. Node ditandai sebagai `Unhealthy`. Deployment atau ReplicationController membuat pod baru pada node lain.	Jika Anda telah membuat snapshot sebelum masalah terjadi, Anda dapat memulihkan data dari snapshot untuk menyelesaikannya. Jika Anda belum membuat snapshot, ajukan tiket untuk melaporkan masalah tersebut. Setelah masalah terselesaikan, buat snapshot secara berkala untuk volume yang dikelola oleh kubelet. Untuk informasi selengkapnya, lihat Buat snapshot untuk satu volume disk. Gunakan beban kerja, seperti deployment, StatefulSet, atau DaemonSet, untuk membuat pod alih-alih membuat pod secara langsung. Hal ini mencegah pod gagal dijadwalkan ke node sehat lainnya.
Kesalahan konfigurasi atau masalah lainnya.	Jika Anda telah membuat snapshot sebelum masalah terjadi, Anda dapat memulihkan data dari snapshot untuk menyelesaikannya. Jika Anda belum membuat snapshot, ajukan tiket untuk melaporkan masalah tersebut. Setelah masalah terselesaikan, buat snapshot secara berkala untuk volume yang dikelola oleh kubelet. Untuk informasi selengkapnya, lihat Buat snapshot untuk satu volume persisten cloud disk.

Bagaimana cara memberikan izin detail halus ketika Pengguna RAM mengoperasikan kluster ACK?

Secara default, Pengguna RAM dan Peran RAM tidak memiliki izin untuk menggunakan OpenAPI layanan Alibaba Cloud. Anda harus memberikan izin sistem AliyunCSFullAccess untuk Container Service atau izin kustom yang diperlukan agar mereka dapat menggunakan dan mengelola kluster ACK. Untuk informasi selengkapnya, lihat Berikan izin akses ke kluster dan sumber daya cloud menggunakan RAM.
Berdasarkan mekanisme RBAC Kubernetes, Anda harus menggunakan RBAC untuk memberikan izin kepada Pengguna RAM guna mengelola sumber daya dalam kluster, seperti membuat deployment dan layanan.
Untuk skenario yang memerlukan kontrol detail halus atas izin baca dan tulis sumber daya, Anda dapat menggunakan ClusterRole dan Role kustom untuk mengonfigurasi izin RBAC yang lebih rinci. Untuk informasi selengkapnya, lihat Gunakan RBAC kustom untuk membatasi operasi pada sumber daya dalam kluster.
Ketika Pengguna RAM mengakses konsol, Anda juga harus memberikan izin yang diperlukan untuk layanan Alibaba Cloud terkait agar dapat menggunakan fitur-fitur seperti melihat aktivitas penskalaan kelompok node dan dasbor kluster. Untuk informasi selengkapnya, lihat Ketergantungan izin konsol Container Service.

Saat mengonfigurasi kebijakan kontrol akses untuk instans SLB API Server kluster, rentang alamat IP mana yang perlu diizinkan?

Aturan daftar kontrol akses (ACL) untuk instans SLB API Server harus mengizinkan rentang alamat IP berikut.

Blok CIDR yang dikelola oleh Container Service for Kubernetes, yaitu 100.104.0.0/16.
Blok CIDR utama dan blok CIDR tambahan (jika ada) dari virtual private cloud (VPC) kluster, atau blok CIDR vSwitch tempat node kluster berada.
Blok CIDR egress klien yang perlu mengakses titik akhir koneksi server API di sisi pengguna.
Selain blok CIDR di atas, kluster ACK Edge harus mengizinkan blok CIDR egress node tepi.
Selain blok CIDR di atas, kluster ACK Lingjun harus mengizinkan blok CIDR Virtual Private Datacenter (VPD) Lingjun.

Untuk informasi selengkapnya, lihat Konfigurasikan kebijakan kontrol akses untuk API Server.

Bagaimana cara mengakses node master?

ACK dedicated cluster: Untuk informasi selengkapnya, lihat Hubungkan ke node master kluster khusus ACK menggunakan SSH.
ACK managed cluster: Node bidang kontrol ACK managed cluster sepenuhnya dikelola. Anda tidak dapat login ke terminal node bidang kontrol. Untuk login ke node bidang kontrol, pertimbangkan untuk menggunakan ACK dedicated cluster.

Jika saya tidak sengaja menghapus node master dari ACK dedicated cluster, apakah saya masih dapat meningkatkan kluster?

Tidak, tidak bisa. Setelah Anda menghapus node master dari ACK dedicated cluster, Anda tidak dapat menambahkan node master atau meningkatkan kluster. Anda dapat membuat kluster khusus ACK (Telah Dihentikan).

Dapatkah saya menambahkan atau menghapus node master dari ACK dedicated cluster? Apa saja operasi berisiko tinggi?

Tidak, tidak bisa. Menambahkan atau menghapus node master dari ACK dedicated cluster dapat menyebabkan kluster menjadi tidak dapat digunakan dan tidak dapat dipulihkan.

Untuk node master ACK dedicated cluster, operasi yang tidak tepat dapat menyebabkan node master atau bahkan seluruh kluster menjadi tidak tersedia. Operasi berisiko tinggi termasuk mengganti sertifikat master atau etcd, memodifikasi komponen inti, menghapus atau memformat data di direktori inti seperti /etc/kubernetes pada sebuah node, atau menginstal ulang sistem operasi. Untuk informasi selengkapnya, lihat Operasi berisiko tinggi terkait kluster.

Apa yang harus saya lakukan jika ACK dedicated cluster API Server mengembalikan kesalahan `"api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after xxx`?

Gejala

Saat Anda membuat pod di ACK dedicated cluster, API Server mengembalikan kesalahan kedaluwarsa sertifikat, atau log atau event kube-controller-manager menunjukkan kesalahan kedaluwarsa sertifikat. Pesan kesalahan sebagai berikut.

"https://localhost:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX

"https://[::1]:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX

Penyebab

Dalam Kubernetes, API Server memiliki sertifikat bawaan untuk server LoopbackClient internalnya. Dalam versi komunitas, sertifikat ini memiliki periode validitas satu tahun dan tidak dapat diputar secara otomatis. Sertifikat ini hanya diputar dan diperbarui secara otomatis saat pod API Server dimulai ulang. Jika versi Kubernetes belum ditingkatkan selama lebih dari satu tahun, sertifikat internal kedaluwarsa, yang menyebabkan permintaan API gagal. Untuk informasi selengkapnya, lihat #86552.

Untuk mengurangi risiko yang disebabkan oleh periode validitas sertifikat yang singkat pada kluster ACK yang menjalankan Kubernetes 1.24 atau versi lebih baru, periode validitas default sertifikat bawaan diperpanjang menjadi 10 tahun. Untuk informasi selengkapnya, lihat Perubahan Produk: Perubahan Periode Validitas Sertifikat Internal API Server Kluster ACK.

Solusi

Dalam perintah tersebut, XX.XX.XX.XX adalah alamat IP lokal node master.

curl --resolve apiserver-loopback-client:6443:XX.XX.XX.XX -k -v https://apiserver-loopback-client:6443/healthz 2>&1 |grep expire

Untuk kluster dengan sertifikat 1 tahun yang telah kedaluwarsa atau akan segera kedaluwarsa, tingkatkan kluster ke versi 1.24 atau versi lebih baru. Untuk informasi selengkapnya, lihat Tingkatkan kluster secara manual. Kami merekomendasikan Anda untuk memigrasikan ke instans ACK Managed Cluster Pro. Untuk informasi selengkapnya, lihat Migrasi panas kluster khusus ACK ke ACK Managed Cluster Pro.
Untuk ACK dedicated clusters yang tidak dapat ditingkatkan dalam waktu dekat, login ke setiap node master dan mulai ulang secara manual API Server untuk menghasilkan sertifikat baru yang valid.
- Node containerd
```
crictl pods  |grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' crictl stopp {}
```
- Node Docker
```
docker ps | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' docker restart {}
```