Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Kubernetes pod failover melalui pemutusan jaringan
Kita mulai dengan tinjauan konsep kunci, komponen, dan pengaturan yang mempengaruhi bagaimana Kubernetes berperilaku selama pemutusan jaringan antara node dan bidang kontrol Kubernetes. EKS sesuai dengan Kubernetes hulu, jadi semua konsep, komponen, dan pengaturan Kubernetes yang dijelaskan di sini berlaku untuk penerapan EKS dan EKS Hybrid Nodes.
Ada perbaikan yang telah dilakukan pada EKS secara khusus untuk meningkatkan perilaku failover pod selama pemutusan jaringan, untuk informasi selengkapnya lihat GitHub masalah #131294
Konsep
Nodai dan Toleransi: Nodai dan toleransi digunakan di Kubernetes untuk mengontrol penjadwalan pod ke node. Taint diatur oleh node-lifecycle-controller untuk menunjukkan bahwa node tidak memenuhi syarat untuk penjadwalan atau bahwa pod pada node tersebut harus diusir. Ketika node tidak dapat dijangkau karena pemutusan jaringan, node-lifecycle-controller menerapkan node.kubernetes. io/unreachable ternoda dengan NoSchedule efek, dan dengan NoExecute efek jika kondisi tertentu terpenuhi. Node.kubernetes. io/unreachable tint sesuai dengan Si NodeCondition ap yang Tidak Diketahui. Pengguna dapat menentukan toleransi untuk noda di tingkat aplikasi di. PodSpec
-
NoSchedule: Tidak ada Pod baru yang dijadwalkan pada node tercemar kecuali mereka memiliki toleransi yang cocok. Pod yang sudah berjalan di node tidak diusir.
-
NoExecute: Polong yang tidak mentolerir noda segera diusir. Pod yang mentolerir noda (tanpa menentukan tolerationSeconds) tetap terikat selamanya. Pod yang mentolerir noda dengan TolerationSeconds yang ditentukan tetap terikat untuk waktu yang ditentukan. Setelah waktu itu berlalu, pengendali siklus hidup node mengusir Pod dari node.
Sewa Node: Kubernetes menggunakan Lease API untuk mengkomunikasikan detak jantung node kubelet ke server API Kubernetes. Untuk setiap node, ada objek Lease dengan nama yang cocok. Secara internal, setiap detak jantung kubelet memperbarui bidang SPEC.RenewTime dari objek Lease. Bidang kontrol Kubernetes menggunakan stempel waktu bidang ini untuk menentukan ketersediaan node. Jika node terputus dari bidang kontrol Kubernetes, mereka tidak dapat memperbarui SPEC.RenewTime untuk Sewa mereka, dan bidang kontrol menafsirkannya sebagai Ready menjadi Unknown. NodeCondition
Komponen-komponen
| Komponen | Sub-component | Deskripsi |
|---|---|---|
|
Pesawat kontrol Kubernetes |
kube-api server |
Server API adalah komponen inti dari bidang kontrol Kubernetes yang mengekspos API Kubernetes. |
|
Pesawat kontrol Kubernetes |
pengendali siklus hidup simpul |
Salah satu pengontrol yang dijalankan oleh kube-controller-manager. Ini bertanggung jawab untuk mendeteksi dan menanggapi masalah node. |
|
Pesawat kontrol Kubernetes |
penjadwal kubus |
Komponen bidang kontrol yang mengawasi Pod yang baru dibuat tanpa simpul yang ditetapkan, dan memilih node untuk dijalankan. |
|
Node Kubernetes |
kubelet |
Agen yang berjalan pada setiap node dalam cluster. Kubelet mengawasi PodSpecs dan memastikan bahwa wadah yang dijelaskan di dalamnya berjalan dan sehat. PodSpecs |
Pengaturan konfigurasi
| Komponen | Pengaturan | Deskripsi | K8s standar | EKS default | Dapat dikonfigurasi dalam EKS |
|---|---|---|---|---|---|
|
kube-api server |
default-unreachable-tolerasi-detik |
Men |
300 |
300 |
Tidak |
|
pengendali siklus hidup simpul |
node-monitor-periode rahmat |
Jumlah waktu sebuah node tidak responsif sebelum ditandai tidak sehat. Harus N kali lebih banyak dari kubelet |
40 |
40 |
Tidak |
|
pengendali siklus hidup simpul |
ambang ukuran cluster besar |
Jumlah node di mana node-lifecycle-controller memperlakukan cluster sebagai besar untuk logika penggusuran. |
50 |
100,000 |
Tidak |
|
pengendali siklus hidup simpul |
ambang batas zona yang tidak sehat |
Persentase node di zona yang harus Tidak Siap agar zona tersebut diperlakukan sebagai tidak sehat. |
55% |
55% |
Tidak |
|
kubelet |
frekuensi pembaruan-status simpul |
Seberapa sering kubelet memposting status node ke bidang kontrol. Harus kompatibel dengan |
10 |
10 |
Ya |
|
kubelet |
label simpul |
Label untuk ditambahkan saat mendaftarkan node di cluster. Label |
Tidak ada |
Tidak ada |
Ya |
Kubernetes pod failover melalui pemutusan jaringan
Perilaku yang dijelaskan di sini mengasumsikan pod berjalan sebagai Deployments Kubernetes dengan pengaturan default, dan EKS digunakan sebagai penyedia Kubernetes. Perilaku aktual mungkin berbeda berdasarkan lingkungan Anda, jenis pemutusan jaringan, aplikasi, dependensi, dan konfigurasi cluster. Konten dalam panduan ini divalidasi menggunakan aplikasi tertentu, konfigurasi cluster, dan subset plugin. Sangat disarankan untuk menguji perilaku di lingkungan Anda sendiri dan dengan aplikasi Anda sendiri sebelum pindah ke produksi.
Ketika ada pemutusan jaringan antara node dan bidang kontrol Kubernetes, kubelet pada setiap node yang terputus tidak dapat berkomunikasi dengan bidang kontrol Kubernetes. Akibatnya, kubelet tidak dapat mengusir pod pada node tersebut sampai koneksi dipulihkan. Ini berarti bahwa pod yang berjalan pada node tersebut sebelum pemutusan jaringan terus berjalan selama pemutusan, dengan asumsi tidak ada kegagalan lain yang menyebabkan mereka mati. Singkatnya, Anda dapat mencapai stabilitas statis selama pemutusan jaringan antara node dan bidang kontrol Kubernetes, tetapi Anda tidak dapat melakukan operasi mutasi pada node atau beban kerja Anda sampai koneksi dipulihkan.
Ada lima skenario utama yang menghasilkan perilaku failover pod yang berbeda berdasarkan sifat pemutusan jaringan. Dalam semua skenario, cluster menjadi sehat kembali tanpa intervensi operator setelah node terhubung kembali ke bidang kontrol Kubernetes. Skenario di bawah ini menguraikan hasil yang diharapkan berdasarkan pengamatan kami, tetapi hasil ini mungkin tidak berlaku untuk semua konfigurasi aplikasi dan cluster yang mungkin.
Skenario 1: Gangguan cluster penuh
Hasil yang diharapkan: Pod pada node yang tidak dapat dijangkau tidak diusir dan terus berjalan di node tersebut.
Gangguan cluster penuh berarti semua node dalam cluster terputus dari bidang kontrol Kubernetes. Dalam skenario ini, node-lifecycle-controller pada bidang kontrol mendeteksi bahwa semua node di cluster tidak dapat dijangkau dan membatalkan penggusuran pod apa pun.
Administrator cluster akan melihat semua node dengan status Not Ready selama pemutusan. Status pod tidak berubah, dan tidak ada pod baru yang dijadwalkan pada node mana pun selama pemutusan dan koneksi ulang berikutnya.
Skenario 2: Gangguan zona penuh
Hasil yang diharapkan: Pod pada node yang tidak dapat dijangkau tidak diusir dan terus berjalan di node tersebut.
Gangguan zona penuh berarti semua node di zona terputus dari bidang kontrol Kubernetes. Dalam skenario ini, node-lifecycle-controller pada bidang kontrol mendeteksi bahwa semua node di zona tidak dapat dijangkau dan membatalkan penggusuran pod apa pun.
Administrator cluster akan melihat semua node dengan status Not Ready selama pemutusan. Status pod tidak berubah, dan tidak ada pod baru yang dijadwalkan pada node mana pun selama pemutusan dan koneksi ulang berikutnya.
Skenario 3: Gangguan zona mayoritas
Hasil yang diharapkan: Pod pada node yang tidak dapat dijangkau tidak diusir dan terus berjalan di node tersebut.
Gangguan zona mayoritas berarti bahwa sebagian besar node di zona tertentu terputus dari bidang kontrol Kubernetes. Zona di Kubernetes ditentukan oleh node dengan label yang sama. topology.kubernetes.io/zone Jika tidak ada zona yang ditentukan dalam cluster, gangguan mayoritas berarti sebagian besar node di seluruh cluster terputus. Secara default, mayoritas ditentukan oleh node-lifecycle-controllerunhealthy-zone-threshold, yang diatur ke 55% di Kubernetes dan EKS. Karena large-cluster-size-threshold diatur ke 100.000 di EKS, jika 55% atau lebih node di suatu zona tidak dapat dijangkau, penggusuran pod dibatalkan (mengingat sebagian besar cluster jauh lebih kecil dari 100.000 node).
Administrator cluster akan melihat sebagian besar node di zona dengan status Not Ready selama pemutusan, tetapi status pod tidak akan berubah, dan mereka tidak akan dijadwal ulang pada node lain.
Perhatikan bahwa perilaku di atas hanya berlaku untuk cluster yang lebih besar dari tiga node. Dalam cluster yang terdiri dari tiga node atau kurang, pod pada node yang tidak dapat dijangkau dijadwalkan untuk digusur, dan pod baru dijadwalkan pada node yang sehat.
Selama pengujian, kami kadang-kadang mengamati bahwa pod diusir dari tepat satu node yang tidak dapat dijangkau selama pemutusan jaringan, bahkan ketika sebagian besar node zona tidak dapat dijangkau. Kami masih menyelidiki kemungkinan kondisi balapan di Kubernetes node-lifecycle-controller sebagai penyebab perilaku ini.
Skenario 4: Gangguan zona minoritas
Hasil yang diharapkan: Pod diusir dari node yang tidak dapat dijangkau, dan pod baru dijadwalkan pada node yang tersedia dan memenuhi syarat.
Gangguan minoritas berarti bahwa persentase node yang lebih kecil di suatu zona terputus dari bidang kontrol Kubernetes. Jika tidak ada zona yang ditentukan dalam cluster, gangguan minoritas berarti minoritas node di seluruh cluster terputus. Seperti yang dinyatakan, minoritas didefinisikan oleh unhealthy-zone-threshold pengaturan node-lifecycle-controller, yaitu 55% secara default. Dalam skenario ini, jika pemutusan jaringan berlangsung lebih lama dari default-unreachable-toleration-seconds (5 menit) dan node-monitor-grace-period (40 detik), dan kurang dari 55% node di zona tidak dapat dijangkau, pod baru dijadwalkan pada node yang sehat sementara pod pada node yang tidak dapat dijangkau ditandai untuk digusur.
Administrator cluster akan melihat pod baru yang dibuat pada node yang sehat, dan pod pada node yang terputus akan ditampilkan sebagaiTerminating. Ingat bahwa, meskipun pod pada node yang terputus memiliki Terminating status, mereka tidak sepenuhnya diusir sampai node terhubung kembali ke bidang kontrol Kubernetes.
Skenario 5: Node restart selama gangguan jaringan
Hasil yang diharapkan: Pod pada node yang tidak dapat dijangkau tidak dimulai sampai node terhubung kembali ke bidang kontrol Kubernetes. Failover pod mengikuti logika yang dijelaskan dalam Skenario 1-3, tergantung pada jumlah node yang tidak dapat dijangkau.
Restart node selama gangguan jaringan berarti kegagalan lain (seperti siklus daya, peristiwa kehabisan memori, atau masalah lain) terjadi pada node pada saat yang sama dengan pemutusan jaringan. Pod yang berjalan pada node tersebut ketika pemutusan jaringan dimulai tidak secara otomatis dimulai ulang selama pemutusan jika kubelet juga telah dimulai ulang. Kubelet menanyakan server API Kubernetes selama startup untuk mempelajari pod mana yang harus dijalankan. Jika kubelet tidak dapat mencapai server API karena pemutusan jaringan, kubelet tidak dapat mengambil informasi yang diperlukan untuk memulai pod.
Dalam skenario ini, alat pemecahan masalah lokal seperti crictl CLI tidak dapat digunakan untuk memulai pod secara manual sebagai ukuran “pecahan kaca”. Kubernetes biasanya menghapus pod yang gagal dan membuat yang baru daripada memulai ulang pod yang ada (lihat #10213
