GKE di VMware dirancang untuk membatasi cakupan kegagalan dan memprioritaskan fungsi yang penting untuk kelangsungan bisnis. Dokumen ini menjelaskan dampak fungsi cluster Anda saat terjadi kegagalan. Informasi ini dapat membantu Anda memprioritaskan area untuk memecahkan masalah jika Anda mengalami masalah.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.Fungsi inti GKE di VMware mencakup kategori berikut:
- Jalankan beban kerja: Beban kerja yang ada dapat terus berjalan. Ini adalah pertimbangan paling penting untuk menjaga kelangsungan bisnis. Meskipun cluster Anda mengalami masalah, workload yang ada mungkin terus berjalan tanpa gangguan.
- Mengelola beban kerja: Anda dapat membuat, memperbarui, dan menghapus beban kerja. Ini adalah pertimbangan terpenting kedua dalam menskalakan workload saat traffic meningkat, meskipun cluster memiliki masalah.
- Mengelola cluster pengguna: Anda dapat mengelola node, mengupdate, mengupgrade, dan menghapus cluster pengguna. Hal ini kurang penting dibandingkan dengan pertimbangan siklus proses aplikasi. Jika kapasitas pada node yang ada tersedia, ketidakmampuan untuk mengubah cluster pengguna tidak memengaruhi beban kerja pengguna.
- Mengelola cluster admin: Anda dapat memperbarui dan mengupgrade cluster admin. Ini adalah pertimbangan yang paling tidak penting karena cluster admin tidak menghosting beban kerja pengguna apa pun. Jika cluster admin Anda mengalami masalah, beban kerja aplikasi akan terus berjalan tanpa gangguan.
Bagian berikut menggunakan kategori fungsi inti ini untuk menjelaskan dampak dari jenis skenario kegagalan tertentu.
Mode kegagalan
Jenis kegagalan berikut dapat memengaruhi performa GKE di cluster VMware.
Kegagalan host ESXi
Dalam skenario kegagalan ini, host ESXi yang menjalankan instance mesin virtual (VM) yang menghosting node Kubernetes mungkin berhenti berfungsi atau menjadi jaringan terpartisi.
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Kelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan dan pemulihan otomatis | Kemungkinan gangguan dan pemulihan otomatis | Gangguan dan pemulihan otomatis | Gangguan dan pemulihan otomatis |
| Penjelasan | Pod yang berjalan di VM yang dihosting oleh host yang gagal akan terganggu, dan secara otomatis dijadwalkan ulang ke VM responsif lainnya. Jika aplikasi pengguna memiliki kapasitas workload cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang mengimplementasikan percobaan ulang. |
Jika kegagalan host memengaruhi VM bidang kontrol di cluster pengguna non-HA atau lebih dari satu VM bidang kontrol di cluster pengguna dengan ketersediaan tinggi (HA), akan terjadi gangguan. | Gangguan akan terjadi jika kegagalan host memengaruhi VM bidang kontrol atau VM pekerja di cluster admin. | Jika kegagalan host memengaruhi VM bidang kontrol di cluster admin, akan terjadi gangguan. |
| Pemulihan | vSphere HA akan otomatis memulai ulang VM di host yang responsif. | vSphere HA akan otomatis memulai ulang VM di host yang responsif. | vSphere HA akan otomatis memulai ulang VM di host yang responsif. | vSphere HA akan otomatis memulai ulang VM di host yang responsif. |
| Pencegahan | Deploy beban kerja dengan cara HA untuk meminimalkan kemungkinan gangguan. | Gunakan cluster pengguna dengan ketersediaan tinggi (HA) untuk meminimalkan kemungkinan gangguan. | — | — |
Kegagalan VM
Dalam skenario kegagalan ini, VM mungkin terhapus secara tiba-tiba, boot disk mungkin rusak, atau VM mungkin disusupi karena masalah sistem operasi.
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Kelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan dan pemulihan otomatis | Kemungkinan gangguan dan pemulihan otomatis | Gangguan dan pemulihan otomatis/manual | Gangguan dan pemulihan manual |
| Penjelasan | Pod yang berjalan pada VM pekerja yang gagal akan terganggu, dan pod tersebut akan otomatis dijadwal ulang ke VM responsif lainnya oleh Kubernetes. Jika aplikasi pengguna memiliki kapasitas workload cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang mengimplementasikan percobaan ulang. |
Jika VM bidang kontrol di cluster pengguna non-HA atau lebih dari satu VM bidang kontrol di cluster pengguna dengan ketersediaan tinggi (HA), akan terjadi gangguan. | Jika VM bidang kontrol atau VM pekerja di cluster admin gagal, akan terjadi gangguan. | Jika VM bidang kontrol di cluster admin gagal, akan terjadi gangguan. |
| Pemulihan | VM yang gagal akan otomatis dipulihkan jika perbaikan otomatis node diaktifkan di cluster pengguna. | VM yang gagal akan otomatis dipulihkan jika perbaikan otomatis node diaktifkan di cluster admin. | VM pekerja yang gagal di cluster admin akan otomatis dipulihkan jika perbaikan otomatis node diaktifkan di cluster admin. Untuk memulihkan VM bidang kontrol cluster admin, lihat Memperbaiki VM bidang kontrol cluster admin. |
Untuk memulihkan VM bidang kontrol cluster admin, lihat Memperbaiki VM bidang kontrol cluster admin. |
| Pencegahan | Deploy beban kerja dengan cara HA untuk meminimalkan kemungkinan gangguan. | Gunakan cluster pengguna dengan ketersediaan tinggi (HA) untuk meminimalkan kemungkinan gangguan. | — | — |
Kegagalan penyimpanan
Dalam skenario kegagalan ini, konten dalam file VMDK mungkin rusak karena VM yang dihentikan secara tidak wajar, atau kegagalan datastore dapat menyebabkan data etcd dan PersistentVolumes (PV) hilang.
kegagalan etcd
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Kelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Tidak ada gangguan | Kemungkinan gangguan dan Pemulihan manual | Gangguan dan pemulihan manual | Gangguan dan pemulihan manual |
| Penjelasan | — | Jika penyimpanan etcd di cluster pengguna non-HA atau lebih dari satu replika etcd di cluster pengguna dengan ketersediaan tinggi (HA) gagal, akan terjadi gangguan. | Jika penyimpanan etcd di cluster pengguna non-HA atau lebih dari satu replika etcd di cluster pengguna dengan ketersediaan tinggi (HA) gagal, akan terjadi gangguan. Jika replika etcd dalam cluster admin gagal, akan terjadi gangguan. |
Jika replika etcd dalam cluster admin gagal, akan terjadi gangguan. |
| Pencegahan | — | GKE di VMware menyediakan proses manual untuk pulih dari kegagalan. | GKE di VMware menyediakan proses manual untuk pulih dari kegagalan. | GKE di VMware menyediakan proses manual untuk pulih dari kegagalan. |
Kegagalan PV aplikasi pengguna
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Kelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan | Tidak ada gangguan | Tidak ada gangguan | Tidak ada gangguan |
| Penjelasan | Beban kerja yang menggunakan PV yang gagal akan terpengaruh. Deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. |
— | — | — |
Kegagalan load balancer
Dalam skenario kegagalan ini, kegagalan load balancer mungkin memengaruhi beban kerja pengguna yang mengekspos Layanan jenis LoadBalancer.
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Kelola cluster admin | |
|---|---|---|---|---|
| Gangguan dan pemulihan manual | ||||
| Penjelasan |
Terjadi gangguan selama beberapa detik hingga load balancer standby memulihkan koneksi VIP bidang kontrol admin. Gangguan layanan mungkin mencapai 2 detik saat menggunakan Seesaw, dan hingga 300 detik saat menggunakan F5. Durasi gangguan failover MetalLB bertambah seiring peningkatan jumlah node load balancer. Dengan kurang dari 5 node, gangguan terjadi dalam waktu 10 detik. |
|||
| Pemulihan | Seesaw HA otomatis mendeteksi kegagalan dan beralih ke instance cadangan. GKE di VMware menyediakan proses manual untuk pulih dari kegagalan Seesaw. |
|||
Memulihkan cluster yang rusak
Bagian berikut menjelaskan cara memulihkan cluster yang rusak.
Pemulihan dari kegagalan host ESXi
GKE di VMware mengandalkan vSphere HA untuk menyediakan pemulihan dari kegagalan host ESXi. vSphere HA dapat terus memantau host ESXi dan memulai ulang VM secara otomatis di host lain jika diperlukan. Hal ini transparan terhadap GKE di pengguna VMware.
Pemulihan dari kegagalan VM
Kegagalan VM dapat meliputi hal berikut:
Penghapusan VM yang tidak terduga.
Kerusakan boot disk VM, seperti boot disk yang menjadi hanya baca karena log jurnal spam.
Kegagalan booting VM karena masalah penyiapan jaringan atau disk berperforma rendah, seperti VM tidak dapat melakukan booting karena alamat IP tidak dapat dialokasikan.
Kerusakan sistem file overlay Docker.
Hilangnya VM bidang kontrol admin karena kegagalan upgrade.
Masalah sistem operasi.
GKE di VMware menyediakan mekanisme pemulihan otomatis untuk node add-on admin, bidang kontrol pengguna, dan node pengguna. Fitur perbaikan otomatis node ini dapat diaktifkan per cluster admin dan cluster pengguna.
VM bidang kontrol admin bersifat spesial karena tidak dikelola oleh cluster Kubernetes, dan ketersediaannya tidak memengaruhi kelangsungan bisnis. Untuk pemulihan kegagalan VM bidang kontrol admin, hubungi Layanan Pelanggan Cloud.
Pemulihan dari kegagalan penyimpanan
Beberapa kegagalan penyimpanan dapat dimitigasi dengan vSphere HA dan vSAN tanpa memengaruhi GKE di VMware. Namun, kegagalan penyimpanan tertentu mungkin muncul dari level vSphere yang menyebabkan kerusakan atau kehilangan data di berbagai GKE di komponen VMware.
Informasi stateful pada cluster dan beban kerja pengguna disimpan di tempat-tempat berikut:
- etcd: Setiap cluster (cluster admin dan cluster pengguna) memiliki database etcd yang menyimpan status (objek Kubernetes) cluster tersebut.
- PersistentVolumes: Digunakan oleh komponen sistem dan beban kerja pengguna.
Pemulihan dari kerusakan atau kehilangan data etcd
etcd adalah database yang digunakan oleh Kubernetes untuk menyimpan semua status cluster, termasuk manifes aplikasi pengguna. Operasi siklus proses aplikasi akan berhenti berfungsi jika database etcd dari cluster pengguna rusak atau hilang. Operasi siklus proses cluster pengguna akan berhenti berfungsi jika database etcd cluster admin rusak atau hilang.
etcd tidak menyediakan mekanisme bawaan yang andal untuk mendeteksi kerusakan data. Anda perlu melihat log Pod etcd jika mencurigai bahwa data etcd rusak atau hilang.
Pod etcd yang tertunda/error/error-looping tidak selalu berarti bahwa data etcd rusak atau hilang. Kemungkinan penyebabnya adalah error pada VM yang menghosting Pod etcd. Anda harus melakukan pemulihan etcd berikut hanya untuk kerusakan atau kehilangan data.
Agar dapat memulihkan (ke status cluster terbaru) dari kerusakan atau kehilangan data etcd, data etcd harus dicadangkan setelah operasi siklus proses apa pun di cluster (misalnya, membuat, memperbarui, atau mengupgrade). Untuk mencadangkan data etcd, lihat Mencadangkan cluster admin dan Mencadangkan cluster pengguna.
Dengan memulihkan data etcd, cluster akan berubah ke status sebelumnya. Jika cadangan diambil sebelum aplikasi di-deploy, lalu cadangan tersebut digunakan untuk memulihkan cluster, aplikasi yang baru-baru ini di-deploy tidak akan berjalan di cluster yang dipulihkan. Misalnya, jika Anda menggunakan snapshot etcd dari cluster admin yang di-snapshot sebelum membuat cluster pengguna, cluster admin yang dipulihkan akan menghapus bidang kontrol cluster pengguna. Oleh karena itu, sebaiknya cadangkan cluster setelah setiap operasi cluster kritis.
Kerusakan atau kegagalan kehilangan data etcd dapat terjadi dalam skenario berikut:
Satu node dari cluster etcd tiga node (cluster pengguna HA) rusak secara permanen karena kerusakan atau kehilangan data. Dalam hal ini, hanya satu {i>node<i} yang rusak dan kuorum etcd masih ada. Skenario ini mungkin terjadi di cluster HA, ketika data salah satu replika etcd rusak atau hilang. Masalah ini dapat diperbaiki tanpa kehilangan data dengan mengganti replika etcd yang gagal dengan replika baru dalam keadaan bersih. Untuk informasi selengkapnya, lihat Mengganti replika etcd yang gagal.
Dua node cluster etcd tiga node (cluster pengguna HA) dirusak secara permanen karena terjadi kerusakan atau kehilangan data. Kuorum hilang, jadi mengganti replika etcd yang gagal dengan yang baru tidak akan membantu. Status cluster harus dipulihkan dari data cadangan. Untuk mengetahui informasi selengkapnya, lihat Memulihkan cluster pengguna dari cadangan (HA).
Cluster etcd node tunggal (cluster admin atau cluster pengguna non-HA) dirusak secara permanen karena kerusakan atau kehilangan data. Kuorum hilang, jadi Anda harus membuat klaster baru dari cadangan. Untuk mengetahui informasi selengkapnya, lihat Memulihkan cluster pengguna dari cadangan (non-HA).
Pemulihan dari kerusakan atau kehilangan PV aplikasi pengguna
Anda dapat menggunakan solusi penyimpanan partner tertentu untuk mencadangkan dan memulihkan PersistentVolumes aplikasi pengguna. Untuk mengetahui daftar partner penyimpanan yang telah memenuhi syarat untuk GKE di VMware, lihat Partner Penyimpanan Anthos Ready.
Pemulihan dari kegagalan load balancer
Untuk load balancer Seesaw yang dipaketkan, Anda dapat pulih dari kegagalan dengan membuat ulang load balancer. Untuk membuat ulang load balancer, upgrade Seesaw ke versi yang sama seperti yang ditunjukkan dalam Mengupgrade load balancer untuk cluster admin.
Dalam kasus kegagalan load balancer cluster admin, bidang kontrol mungkin tidak dapat dijangkau. Jalankan upgrade di VM bidang kontrol admin yang memiliki akses bidang kontrol.
Untuk load balancer terintegrasi (F5), hubungi Dukungan F5.
Untuk load balancer MetalLB yang dipaketkan, load balancer menggunakan node cluster sebagai load balancer. Perbaikan node otomatis tidak dipicu jika ada masalah load balancer. Anda dapat mengikuti proses manual untuk memperbaiki node.