Halaman ini menunjukkan cara terbaik menggunakan Config Controller saat mengoperasikan layanan yang sangat tersedia atau mengelola resource di beberapa region Google Cloud.
Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya serta merencanakan kapasitas dan kebutuhan infrastruktur. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.
Config Controller berjalan di satu region, sehingga dapat mentoleransi kegagalan zona ketersediaan, tetapi jika seluruh region gagal, Config Controller akan kehilangan ketersediaan. Ada dua strategi yang berbeda untuk menangani kegagalan regional, dan pilihan Anda bergantung pada tindakan yang akan Anda lakukan jika suatu region gagal:
Jika Anda ingin membuat perubahan konfigurasi sebagai respons terhadap kegagalan regional, buat instance Pengontrol Konfigurasi kedua.
Jika Anda tidak akan membuat perubahan konfigurasi, gunakan satu instance Pengontrol Konfigurasi.
Memahami skenario kegagalan
Config Controller menggunakan cluster GKE regional. Meskipun cluster regional dapat mentoleransi kegagalan satu zona dalam region, cluster tidak akan tersedia jika beberapa zona dalam region gagal.
Jika instance Config Controller gagal, resource Google Cloud yang ada akan tetap dalam status saat ini. Namun, meskipun aplikasi Anda masih berjalan, Anda tidak dapat mengubah konfigurasinya saat Pengontrol Konfigurasi tidak tersedia. Hal ini berlaku untuk resource di region yang sama dan untuk resource di region lain yang Anda kelola dari Pengontrol Konfigurasi di region yang tidak tersedia.
Karena Anda tidak dapat mengonfigurasi ulang resource di region yang sama, jika kegagalan regional memang memengaruhi resource Google Cloud yang ada di region Config Controller, Anda tidak dapat memperbaiki resource tersebut.
Karena Anda juga tidak dapat mengonfigurasi ulang resource di region lain, kegagalan di satu region kini telah memengaruhi kemampuan Anda untuk melakukan perubahan di region lain.
Skenario kegagalan lainnya juga mungkin terjadi. Misalnya, jika Anda mengonfigurasi Config Sync untuk mengambil dari penyedia Git eksternal, Anda harus mempertimbangkan mode kegagalan penyedia Git tersebut. Anda mungkin tidak dapat membuat perubahan konfigurasi karena tidak dapat mendorong perubahan ke penyedia Git tersebut. Atau jika Config Sync tidak dapat membaca dari Git, perubahan Git apa pun tidak akan diterapkan ke kluster, sehingga Config Connector tidak akan menerapkannya. Namun, kegagalan regional sering kali merupakan skenario kegagalan yang paling penting, karena skenario kegagalan lainnya biasanya tidak berkorelasi dengan kegagalan Pengontrol Konfigurasi.
Menggunakan satu cluster untuk ketersediaan regional
Dalam banyak skenario, Anda tidak akan melakukan konfigurasi ulang jika region gagal. Dalam hal ini, Anda dapat memilih untuk menerima bahwa kegagalan regional menyebabkan bidang kontrol konfigurasi Anda tidak tersedia.
Misalnya, jika Anda hanya beroperasi di satu region, mungkin tidak ada konfigurasi ulang yang berguna yang dapat Anda lakukan jika region tersebut gagal. Demikian pula, jika Anda memiliki database titik tunggal kegagalan di satu region, Anda mungkin tidak dapat memulihkan hingga region tersebut pulih. Untuk aplikasi yang tidak memerlukan ketersediaan tertinggi mutlak, situasi ini dapat menjadi kompromi yang wajar terhadap biaya dan kompleksitas.
Menempatkan instance Config Controller di wilayah yang sama akan memberi Anda nasib bersama: Config Controller tersedia selama wilayah utama Anda tersedia. Menempatkan instance Config Controller di region yang berbeda juga dapat menjadi pilihan yang baik; meskipun sekarang Anda harus memikirkan potensi kegagalan di dua region, Anda akan menghindari kegagalan bidang kontrol konfigurasi yang berkorelasi dengan kegagalan region utama.
Atau, jika Anda memiliki konfigurasi redundan multi-regional, sistem Anda mungkin secara otomatis mengalihkan traffic dari region yang gagal. Di sini juga, Anda mungkin tidak ingin melakukan konfigurasi ulang jika region gagal. Dalam hal ini, Anda dapat memilih satu instance Config Controller.
Melakukan failover secara manual ke instance Config Controller kedua
Anda mungkin ingin melakukan beberapa konfigurasi ulang jika suatu region gagal sehingga Anda dapat memperbaiki kegagalan tersebut. Anda mungkin juga ingin terus mengonfigurasi resource di region lain, meskipun instance Config Controller Anda berada di region yang gagal. Dalam hal ini, sebaiknya gunakan instance Config Controller kedua di region kedua.
Meskipun tidak direkomendasikan, dua instance Config Controller dapat berjalan dengan konfigurasi yang sama. Kedua instance berlomba untuk membaca dari repositori Git yang sama dan menerapkan perubahan yang sama ke Google Cloud. Namun, banyak kasus ekstrem yang membuat konfigurasi ini tidak dapat diandalkan. Dua instance Config Controller mengamati repositori Git pada waktu yang sedikit berbeda; keduanya mungkin mencoba menerapkan versi konfigurasi Google Cloud yang sedikit berbeda. Beberapa penulis aktif ke Google Cloud akan meningkatkan kemungkinan Anda mengalami kuota atau batas kapasitas. Sejumlah kecil resource Config Connector juga tidak idempoten, dan memerlukan perhatian ekstra seperti yang dibahas di bagian lain dalam bagian ini. Oleh karena itu, sebaiknya jangan memiliki dua cluster Config Controller yang secara aktif melakukan rekonsiliasi.
Sebaiknya, jika region yang menjalankan Config Controller Anda gagal, jalankan Config Controller lain di region kedua. Instance Config Controller baru harus dikonfigurasi secara identik dengan instance pertama, yang membaca dari repositori Git yang sama. Menyiapkan skrip terlebih dahulu untuk menampilkan dan mengonfigurasi instance Config Controller mungkin berguna dalam skenario ini. Saat Anda membuat instance Config Controller baru, Config Sync akan membaca dan menerapkan status yang diinginkan dari Git ke Kubernetes; Config Connector akan menyinkronkan status yang diinginkan ke Google Cloud.
Ada dua hal yang perlu diperhatikan dalam situasi ini:
Jika cluster Config Controller pertama masih berjalan, atau mulai berjalan saat region pertama pulih, cluster tersebut mungkin akan mencoba menerapkan status lama ke Google Cloud. Jika Anda dapat menghentikan cluster Config Controller di region pertama sebelum memulai cluster Config Controller kedua, Anda dapat menghindari potensi konflik ini.
Tidak semua resource Config Connector dapat diterapkan kembali dengan lancar dari Git. Untuk mengetahui daftar resource yang memerlukan perhatian khusus, lihat resource dengan pembatasan seputar akuisisi. Secara khusus, sebaiknya berhati-hatilah dengan resource
Folder, dan hindari resourceIAMServiceAccountKey(misalnya, gunakan GKE Workload Identity Federation untuk GKE).
Satu instance Config Controller per region
Jika Anda ingin menghindari instance Config Controller di satu region yang memengaruhi region lain, Anda juga dapat mempertimbangkan untuk menjalankan instance Config Controller per region, dengan setiap instance Config Controller mengelola resource di region tersebut.
Konfigurasi ini dapat digunakan, tetapi bukan salah satu opsi yang kami rekomendasikan karena alasan berikut:
Beberapa resource mencakup beberapa region (seperti Cloud DNS), yang membuat strategi ini terbatas.
Umumnya, memiliki cluster Config Controller di region yang sama akan mengalami masalah kegagalan yang berkorelasi: Anda ingin mengonfigurasi ulang resource tepat saat kegagalan regional memengaruhi Config Controller di region tersebut.
Anda harus membagi resource Config Connector menurut region.
Pengontrol Konfigurasi saat ini tidak tersedia di semua wilayah.
Mengonfigurasi resource Google Cloud secara langsung
Dalam keadaan luar biasa, Anda dapat melakukan perubahan langsung ke resource Google Cloud yang mendasarinya, tanpa melalui Git atau Config Connector. Config Connector mencoba memperbaiki "drift" apa pun, jadi jika instance Config Controller Anda masih berjalan, Config Connector akan menganggap perubahan apa pun yang Anda buat secara manual sebagai "drift" dan mencoba mengembalikannya.
Namun, jika Anda menghentikan instance Config Controller, atau jika region sedang offline, tindakan ini dapat menjadi tindakan sementara yang berguna.
Saat instance Config Controller Anda pulih, Config Connector kemungkinan akan mencoba memulihkan perubahan manual Anda. Untuk menghindari situasi ini, Anda dapat membuat perubahan yang sesuai di Git untuk setiap perubahan yang Anda buat secara manual.