Masalah umum dan solusi untuk pembuatan serta pengelolaan kluster - Container Service for Kubernetes

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

Migrasi kluster yang dikelola sendiri ke ACK

ACK menyediakan solusi migrasi untuk memindahkan kluster Kubernetes yang dikelola sendiri ke kluster ACK secara mulus dengan dampak minimal terhadap bisnis Anda. Untuk informasi selengkapnya, lihat Ikhtisar solusi migrasi Kubernetes.

Kompatibilitas gambar Alibaba Cloud Linux dan CentOS

Ya, keduanya kompatibel. Untuk informasi selengkapnya, lihat Alibaba Cloud Linux 3.

Mengubah runtime kontainer setelah pembuatan kluster

Tidak, Anda tidak dapat mengubah runtime kontainer setelah kluster dibuat. Namun, Anda dapat membuat node pool yang menggunakan runtime berbeda. Untuk informasi selengkapnya, lihat Buat dan kelola node pool.

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

Catatan

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

Perbandingan runtime kontainer

Container Service for Kubernetes mendukung tiga jenis runtime: containerd, Docker, dan Sandboxed-Container. Kami merekomendasikan Anda menggunakan runtime containerd. Runtime Docker hanya didukung di kluster yang menjalankan Kubernetes 1.22 atau versi sebelumnya. Runtime Sandboxed-Container hanya didukung di kluster yang menjalankan Kubernetes 1.24 atau versi sebelumnya. Untuk perbandingan lengkap antara runtime ini, lihat Perbandingan runtime containerd, Sandboxed-Container, dan Docker. Saat Anda melakukan upgrade kluster ACK ke Kubernetes 1.24 atau versi lebih baru, Anda harus memigrasikan runtime kontainer node dari Docker ke containerd. Untuk informasi selengkapnya, lihat Migrasikan runtime kontainer node dari Docker ke containerd.

Sertifikasi ACK dan MLPS 2.0 Level 3

Anda dapat mengaktifkan penguatan berbasis MLPS untuk kluster Anda dan mengonfigurasi kebijakan pemeriksaan baseline. Berdasarkan Alibaba Cloud Linux, Anda dapat menerapkan MLPS 2.0 Level 3 dan mengonfigurasi pemeriksaan baseline untuk kepatuhan MLPS guna memenuhi persyaratan berikut:

Otentikasi identitas
Kontrol akses
Audit keamanan
Pencegahan intrusi
Pencegahan kode berbahaya

Untuk informasi selengkapnya, lihat Aktifkan penguatan berbasis MLPS untuk kluster ACK.

Dukungan ACK dan Istio

Ya. Anda dapat menggunakan Service Mesh (ASM) Alibaba Cloud. ASM adalah produk service mesh yang sepenuhnya kompatibel dengan Istio komunitas. Lapisan kontrol yang sepenuhnya dikelola memungkinkan Anda fokus pada pengembangan dan penerapan aplikasi bisnis. ASM kompatibel dengan berbagai sistem operasi node dan plugin jaringan di kluster ACK. Anda dapat menambahkan kluster ACK yang sudah ada ke instance ASM dan menggunakan fitur-fitur seperti manajemen trafik, penanganan kesalahan, pemantauan terpadu, dan manajemen log. Untuk informasi selengkapnya, lihat Tambahkan kluster ke instance ASM. Untuk informasi penagihan ASM, lihat Penagihan ASM.

Kumpulkan informasi diagnostik

Jika kluster Kubernetes mengalami masalah atau node tidak normal, Anda dapat menggunakan fitur diagnostik satu klik yang disediakan oleh ACK untuk mengidentifikasi masalah tersebut. Untuk informasi selengkapnya, lihat Gunakan diagnostik kluster.

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

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 China (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

Output-nya mirip seperti berikut. Nama file log yang dihasilkan berbeda setiap kali Anda menjalankan skrip. Contoh ini menggunakan 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 berisi informasi diagnostik kluster:
```
ls -ltr | grep diagnose_1514939155.tar.gz
```
Catatan
Ganti diagnose_1514939155.tar.gz dengan nama file log aktual di lingkungan Anda.

Node Windows

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

Catatan

Windows hanya didukung untuk node pekerja.

Login ke node pekerja yang tidak normal dan buka tool command-line.
Jalankan perintah berikut untuk masuk ke mode PowerShell:
```
powershell
```
Jalankan perintah berikut untuk mengunduh dan menjalankan skrip diagnostik.
Anda dapat mengunduh skrip diagnostik untuk node Windows dari wilayah kluster Anda. Ganti [$Region_ID] dalam perintah dengan ID wilayah kluster Anda.
```
Invoke-WebRequest -UseBasicParsing -Uri http://aliacs-k8s-[$Region_ID].oss-[$Region_ID].aliyuncs.com/public/pkg/windows/diagnose/diagnose.ps1 | Invoke-Expression
```
Output berikut menunjukkan bahwa informasi diagnostik berhasil dikumpulkan.
```
INFO: Compressing diagnosis clues ...
INFO: ...done
INFO: Please get diagnoses_1514939155.zip for diagnostics
```
Catatan
File diagnoses_1514939155.zip disimpan di direktori tempat skrip dijalankan.

Lakukan troubleshooting masalah kluster ACK

Langkah 1: Periksa node kluster

Jalankan perintah berikut untuk melihat status node di kluster. Pastikan semua node ada dan berada dalam status Ready.

kubectl get nodes

Output yang diharapkan mirip seperti berikut.

NAME                      STATUS   ROLES    AGE   VERSION
cn-hxxx.20   Ready    master   86m   v1.18.8-aliyun.1
cn-hxxx.21   Ready    master   84m   v1.18.8-aliyun.1
cn-hxxx.22   Ready    master   81m   v1.18.8-aliyun.1
cn-hxxx.23   Ready    <none>   78m   v1.18.8-aliyun.1
cn-hxxx.24   Ready    <none>   78m   v1.18.8-aliyun.1
cn-hxxx.25   Ready    <none>   78m   v1.18.8-aliyun.1

Jika semua node ada dan berada dalam status Ready, maka node kluster dalam kondisi sehat.
Jika ada node yang tidak normal, lanjutkan ke Langkah 2.

Jalankan perintah berikut untuk melihat informasi dan event detail untuk sebuah node.
Ganti [$NODE_NAME] dengan nama node Anda.
```
kubectl describe node [$NODE_NAME]
```
Catatan
Untuk informasi selengkapnya tentang output kubectl, lihat Node Status.

Langkah 2: Periksa komponen kluster

Jika Anda tidak dapat mengidentifikasi masalah setelah memeriksa node kluster, periksa log komponen kluster di lapisan kontrol.

Jalankan perintah berikut untuk melihat semua komponen di namespace kube-system.

kubectl get pods -n kube-system

Output yang diharapkan sebagai berikut.

NAME                                             READY   STATUS      RESTARTS   AGE
alicloud-monitor-controller-6fbd5454f9-tvsls     1/1     Running     0          91m
aliyun-acr-credential-helper-587bf4b6f8-bq2bg    1/1     Running     0          91m
cloud-controller-manager-74q86                   1/1     Running     0          91m
cloud-controller-manager-sktzk                   1/1     Running     0          91m
cloud-controller-manager-tkvtz                   1/1     Running     0          91m
coredns-64d57b9c4b-222pj                         1/1     Running     0          91m
coredns-64d57b9c4b-fcr8t                         1/1     Running     0          91m
csi-plugin-5hnn8                                 4/4     Running     0          91m
csi-plugin-6wxtm                                 4/4     Running     0          91m
csi-plugin-jdvg4                                 4/4     Running     0          91m
csi-plugin-njd28                                 4/4     Running     0          91m
csi-plugin-tvf2h                                 4/4     Running     0          91m
csi-plugin-zt76m                                 4/4     Running     0          91m
csi-provisioner-84c4866d86-874wm                 7/7     Running     0          91m
csi-provisioner-84c4866d86-wvj86                 7/7     Running     0          91m
ingress-nginx-admission-create-9gnv8             0/1     Completed   0          91m
ingress-nginx-admission-patch-wjskw              0/1     Completed   2          91m
kube-apiserver-cn-huhehaote.1xxx 0               1/1     Running     0          95m
kube-apiserver-cn-huhehaote.1xxx 1               1/1     Running     0          95m
kube-apiserver-cn-huhehaote.1xxx 2               1/1     Running     0          95m
kube-controller-manager-cn-huhehaote.1xxx 20     1/1     Running     1          100m
kube-controller-manager-cn-huhehaote.1xxx 21     1/1     Running     1          97m
kube-controller-manager-cn-huhehaote.1xxx 22     1/1     Running     1          91m
kube-flannel-ds-b5zt4                            1/1     Running     0          91m
kube-flannel-ds-blj25                            1/1     Running     0          91m
kube-flannel-ds-d8v7j                            1/1     Running     0          91m
kube-flannel-ds-dq6nz                            1/1     Running     0          91m
kube-flannel-ds-vx97g                            1/1     Running     0          91m
kube-flannel-ds-wp8cj                            1/1     Running     0          91m
kube-proxy-master-8kl67                          1/1     Running     0          91m
kube-proxy-master-mnqmt                          1/1     Running     0          91m
kube-proxy-master-zfns9                          1/1     Running     0          91m
kube-proxy-worker-j2gr2                          1/1     Running     0          91m
kube-proxy-worker-n69x8                          1/1     Running     0          91m
kube-proxy-worker-qrft5                          1/1     Running     0          100m
kube-scheduler-cn-huhehaote.1xxx l20             1/1     Running     0          97m
kube-scheduler-cn-huhehaote.1xxx l21             1/1     Running     0          97m
kube-scheduler-cn-huhehaote.1xxx l22             1/1     Running     0          95m
metrics-server-84f55db549-h9n4k                  1/1     Running     0          91m
nginx-ingress-controller-7474b6cc84-7pk7v        1/1     Running     0          91m
nginx-ingress-controller-7474b6cc84-hg8l9        1/1     Running     0          91m

Pod yang namanya diawali dengan kube- adalah komponen sistem kluster Kubernetes. Pod yang namanya diawali dengan coredns- adalah plugin DNS. Output ini menunjukkan bahwa komponen berada dalam kondisi normal. Jika ada komponen yang tidak normal, lanjutkan ke langkah berikutnya.

Jalankan perintah berikut untuk melihat log komponen yang tidak normal guna mengidentifikasi dan menyelesaikan masalah.
Ganti [$Component_Name] dengan nama komponen yang tidak normal.
```
kubectl logs -f [$Component_Name] -n kube-system
```

Langkah 3: Periksa komponen kubelet

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

Masalah kluster umum

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

Masalah	Solusi
Komponen API Server atau komponen master berhenti: Anda tidak dapat membuat, menghentikan, atau memperbarui sumber daya seperti Pod, Service, dan Deployment. Pod dan Service yang sudah ada tetap berfungsi kecuali jika mereka perlu memanggil API Kubernetes, yang digunakan oleh aplikasi seperti Kubernetes Dashboard.	Komponen ACK memiliki ketersediaan tinggi bawaan. Kami merekomendasikan Anda memeriksa apakah komponen itu sendiri tidak normal. Misalnya, API Server kluster ACK secara default menggunakan instance CLB. Anda dapat melakukan troubleshooting status abnormal instance CLB tersebut.
Data backend untuk API Server hilang: API Server tidak dapat dimulai. Pod dan Service yang sudah ada tetap berfungsi kecuali jika mereka perlu memanggil API Kubernetes, yang digunakan oleh aplikasi seperti Kubernetes Dashboard. Anda harus memulihkan atau membangun kembali data API Server untuk memulai API Server.	Jika Anda telah membuat snapshot, Anda dapat memulihkan data dari snapshot tersebut saat terjadi masalah. Jika Anda belum membuat snapshot, ajukan tiket. Setelah masalah terselesaikan, lakukan langkah-langkah berikut untuk mencegah terjadinya masalah ini: Gunakan plugin penyimpanan yang disediakan oleh ACK untuk penyimpanan persisten. Untuk informasi selengkapnya, lihat Gunakan volume disk yang disediakan secara dinamis. Buat snapshot secara berkala untuk volume data yang digunakan oleh kubelet. Untuk informasi selengkapnya, lihat Buat snapshot untuk satu volume disk.
Sebuah node mati, dan semua Pod di node tersebut berhenti berjalan.	Gunakan workload seperti Deployment, StatefulSet, atau DaemonSet untuk membuat Pod, bukan membuat Pod secara langsung. Hal ini memastikan bahwa Pod pengganti dijadwalkan di node yang sehat jika terjadi kegagalan node.
Komponen kubelet gagal: Pod tidak dapat dibuat di node tempat kubelet gagal. kubelet mungkin telah menghapus beberapa Pod secara tidak benar. Node ditandai sebagai `NotReady`. Deployment atau Replication Controller membuat Pod baru di node lain.	Jika Anda telah membuat snapshot, Anda dapat menggunakannya untuk memulihkan data saat terjadi masalah. Jika Anda belum membuat snapshot, ajukan tiket untuk melaporkan masalah tersebut. Setelah masalah terselesaikan, buat snapshot secara berkala untuk volume data yang digunakan oleh kubelet. Untuk informasi selengkapnya, lihat Buat snapshot untuk satu volume disk. Gunakan workload seperti Deployment, StatefulSet, atau DaemonSet untuk membuat Pod, bukan membuat Pod secara langsung. Hal ini memastikan bahwa Pod dijadwalkan ulang ke node sehat lainnya.
Masalah disebabkan oleh konfigurasi manual atau alasan lain.	Jika Anda telah membuat snapshot, Anda dapat menggunakannya untuk memulihkan data saat terjadi masalah. Jika Anda belum membuat snapshot, ajukan tiket untuk melaporkan masalah tersebut. Setelah masalah terselesaikan, buat snapshot secara berkala untuk volume data yang digunakan oleh kubelet. Untuk informasi selengkapnya, lihat Buat snapshot untuk satu volume disk.

Konfigurasi otorisasi detail halus

Secara default, Pengguna RAM atau Peran RAM tidak memiliki izin untuk memanggil OpenAPI layanan cloud apa pun. Untuk menggunakan dan mengelola kluster ACK, Anda harus memberikan kebijakan sistem AliyunCSFullAccess atau kebijakan kustom untuk Container Service for Kubernetes kepada Pengguna RAM atau Peran RAM tersebut. 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 otorisasi kepada Pengguna RAM guna mengelola sumber daya internal kluster, seperti membuat Deployment dan Service.
Dalam skenario yang memerlukan kontrol detail halus atas izin baca dan tulis pada sumber daya, lihat Gunakan kebijakan RBAC kustom untuk membatasi operasi pada sumber daya di kluster guna mengonfigurasi izin RBAC yang lebih detail halus menggunakan ClusterRole dan Role kustom.
Saat Pengguna RAM mengakses konsol, Anda juga harus mengonfigurasi izin layanan cloud yang sesuai untuk menggunakan fitur seperti melihat aktivitas penskalaan node pool dan dasbor pemantauan kluster. Untuk informasi selengkapnya, lihat Izin yang diperlukan untuk konsol Container Service for Kubernetes.

Rentang alamat IP apa saja yang harus diizinkan untuk kebijakan kontrol akses SLB API Server kluster?

Aturan daftar kontrol akses (ACL) untuk instance SLB API Server harus mengizinkan Blok CIDR berikut.

Blok CIDR 100.104.0.0/16, yang dicadangkan untuk lapisan kontrol Container Service for Kubernetes.
Blok CIDR utama dan tambahan dari Virtual Private Cloud (VPC) kluster, atau blok CIDR dari vSwitch tempat node kluster berada.
Blok CIDR egress klien yang perlu mengakses API server.
Untuk kluster ACK Edge, Anda juga harus menambahkan blok CIDR egress node edge.
Untuk kluster ACK Lingjun, Anda juga harus menambahkan blok CIDR Virtual Private Datacenter (VPD) Lingjun.

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

Akses node master

Klaster khusus: Untuk informasi selengkapnya, lihat Hubungkan ke node master kluster ACK dedicated menggunakan SSH.
Kluster managed: Node lapisan kontrol kluster ACK managed dikelola sepenuhnya. Anda tidak dapat login ke terminal node lapisan kontrol. Jika Anda perlu login ke node lapisan kontrol, pertimbangkan untuk menggunakan klaster khusus.

Jika node master kluster ACK dedicated tidak sengaja dihapus, apakah kluster tersebut masih dapat di-upgrade?

Tidak. Setelah Anda menghapus node master dari klaster khusus, Anda tidak dapat menambahkan node master atau melakukan upgrade kluster. Anda dapat membuat kluster ACK dedicated (tidak tersedia lagi).

Kluster ACK dedicated: Apakah node master dapat dihapus atau ditambahkan, dan apa saja operasi berisiko tinggi?

Tidak. Menambahkan atau menghapus node master dari klaster khusus dapat menyebabkan kluster menjadi tidak dapat digunakan dan tidak dapat dipulihkan.

Untuk node master klaster khusus, operasi yang tidak tepat dapat membuat node master atau bahkan seluruh kluster tidak dapat digunakan. Operasi berisiko tinggi meliputi mengganti sertifikat master atau etcd, memodifikasi komponen inti, menghapus atau memformat data di direktori inti seperti /etc/kubernetes pada node, dan menginstal ulang sistem operasi. Untuk informasi selengkapnya, lihat Operasi berisiko tinggi terkait kluster.

Kluster ACK dedicatedAPI Servererror:`api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after xxx`. Apa yang harus saya lakukan?

Gejala

Saat Anda membuat Pod di klaster khusus, API Server mengembalikan error kedaluwarsa sertifikat, atau log atau event kube-controller-manager menunjukkan error kedaluwarsa sertifikat. Pesan error-nya 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

Di Kubernetes, API Server memiliki sertifikat bawaan untuk LoopbackClient internalnya. Di versi komunitas, sertifikat ini memiliki periode validitas 1 tahun dan tidak dapat diputar secara otomatis. Sertifikat ini hanya diputar dan diperbarui saat Pod API Server di-restart. Jika kluster tidak di-upgrade selama lebih dari satu tahun, sertifikat internal kedaluwarsa, menyebabkan permintaan API gagal. Untuk informasi selengkapnya, lihat #86552.

Untuk mengurangi risiko stabilitas akibat periode validitas sertifikat yang singkat di versi komunitas, ACK memperpanjang periode validitas default sertifikat bawaan ini menjadi 10 tahun untuk kluster yang menjalankan Kubernetes 1.24 atau versi lebih baru. Untuk informasi selengkapnya tentang perubahan dan cakupan dampaknya, lihat Perubahan Produk: Periode Validitas Sertifikat Internal API Server Kluster ACK.

Solusi

Anda dapat login ke node master dan menjalankan perintah berikut untuk menanyakan waktu kedaluwarsa sertifikat LoopbackClient.

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, lihat Lakukan upgrade kluster ACK secara manual untuk meng-upgrade kluster ke versi 1.24 atau versi lebih baru. Kami merekomendasikan Anda memigrasikan ke instance ACK Managed Cluster Pro (Migrasi panas kluster ACK dedicated ke instance ACK Managed Cluster Pro).
Untuk klaster khusus yang tidak dapat di-upgrade dalam waktu dekat, login ke setiap node master dan restart 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 {}
```