Halaman ini menunjukkan cara terbaik menggunakan Pengontrol Konfigurasi saat mengoperasikan layanan yang sangat tersedia atau mengelola resource di beberapa region Google Cloud.
Pengontrol Konfigurasi berjalan di satu region, sehingga dapat menoleransi kegagalan zona ketersediaan. Namun, jika seluruh region gagal, Pengontrol Konfigurasi akan kehilangan ketersediaan. Ada dua strategi berbeda untuk mengatasi kegagalan regional, dan pilihan Anda bergantung pada apa yang akan Anda lakukan jika suatu region gagal:
Jika Anda akan 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
Pengontrol Konfigurasi menggunakan cluster GKE regional. Meskipun cluster regional dapat menoleransi kegagalan satu zona di suatu region, cluster menjadi tidak tersedia jika beberapa zona di region gagal.
Jika instance Pengontrol Konfigurasi Anda 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 mempengaruhi resource Google Cloud yang ada di region Pengontrol Konfigurasi, Anda tidak dapat memperbaiki resource tersebut.
Karena Anda juga tidak dapat mengonfigurasi ulang resource di region lain, kegagalan di satu region kini memengaruhi kemampuan Anda untuk membuat 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 Anda tidak dapat mengirim perubahan ke penyedia Git tersebut. Atau, jika Config Sync tidak dapat membaca dari Git, perubahan Git tidak akan diterapkan ke cluster, sehingga Config Connector tidak 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 apa pun jika suatu region gagal. Dalam hal ini, Anda dapat memilih untuk menerima bahwa kegagalan regional menyebabkan bidang kontrol konfigurasi menjadi tidak tersedia.
Misalnya, jika Anda hanya beroperasi di satu region, mungkin tidak ada konfigurasi ulang berguna yang dapat Anda lakukan jika region tersebut gagal. Demikian pula, jika Anda memiliki satu titik database kegagalan di satu region, Anda mungkin tidak dapat melakukan pemulihan hingga region tersebut pulih. Untuk aplikasi yang tidak memerlukan ketersediaan tertinggi absolut, situasi ini dapat menjadi kompromi yang wajar terhadap biaya dan kompleksitas.
Menemukan instance Pengontrol Konfigurasi di region yang sama memberi Anda konsekuensi bersama: Pengontrol Konfigurasi tersedia selama region utama Anda tersedia. Menemukan instance Pengontrol Konfigurasi di region yang berbeda juga bisa menjadi pilihan yang baik; meskipun kini Anda harus memikirkan potensi kegagalan di dua region, Anda dapat menghindari kegagalan berkorelasi dari bidang kontrol konfigurasi dengan kegagalan region utama.
Atau, jika Anda memiliki konfigurasi redundan multi-regional, sistem Anda mungkin akan otomatis menghindari region yang gagal. Di sini juga, Anda mungkin tidak ingin melakukan konfigurasi ulang jika suatu region gagal. Dalam hal ini, Anda dapat memilih satu instance Pengontrol Konfigurasi.
Melakukan failover secara manual ke instance Pengontrol Konfigurasi kedua
Anda mungkin perlu melakukan konfigurasi ulang jika suatu region gagal sehingga Anda dapat mengatasi kegagalan tersebut. Anda mungkin juga ingin terus mengonfigurasi resource di region lain, meskipun instance Pengontrol Konfigurasi Anda berada di region yang gagal. Dalam hal ini, sebaiknya gunakan instance Pengontrol Konfigurasi kedua di region kedua.
Meskipun tidak direkomendasikan, dua instance Pengontrol Konfigurasi dapat berjalan dengan konfigurasi yang identik. Kedua instance berlomba untuk membaca dari repositori Git yang sama dan menerapkan perubahan yang sama ke Google Cloud. Namun, banyak kasus ekstrem membuat konfigurasi ini tidak dapat diandalkan. Kedua instance Pengontrol Konfigurasi mengamati repositori Git pada waktu yang sedikit berbeda; keduanya mungkin mencoba menerapkan versi konfigurasi Google Cloud yang sedikit berbeda. Beberapa penulis aktif di Google Cloud dapat meningkatkan kemungkinan Anda mengalami kuota atau batas kapasitas. Sejumlah kecil resource Config Connector juga tidak idempoten, dan memerlukan perhatian lebih seperti yang dijelaskan di sisa bagian ini. Oleh karena itu, sebaiknya jangan memiliki dua cluster Pengontrol Konfigurasi yang melakukan rekonsiliasi secara aktif.
Sebagai gantinya, jika region yang menjalankan Pengontrol Konfigurasi Anda gagal, sebaiknya jalankan Pengontrol Konfigurasi lain di region kedua. Instance Pengontrol Konfigurasi baru harus dikonfigurasi sama persis dengan instance pertama, dibaca dari repositori Git yang sama. Menyiapkan skrip untuk menampilkan dan mengonfigurasi instance Pengontrol Konfigurasi Anda 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 menyinkronkan status yang diinginkan ke Google Cloud.
Ada dua hal yang harus diperhatikan dalam situasi ini:
Jika cluster Pengontrol Konfigurasi pertama masih berjalan, atau mulai berjalan ketika region pertama dipulihkan, cluster mungkin akan mencoba menerapkan status lama ke Google Cloud. Jika Anda dapat menghentikan cluster Pengontrol Konfigurasi di region pertama sebelum memulai cluster Pengontrol Konfigurasi 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 batasan seputar akuisisi. Secara khusus, sebaiknya berhati-hatilah seputar resource
Folder, dan hindari resourceIAMServiceAccountKey(misalnya, menggunakan GKE Workload Identity).
Satu instance Pengontrol Konfigurasi per region
Jika ingin menghindari instance Pengontrol Konfigurasi di satu region yang memengaruhi region lain, Anda juga dapat mempertimbangkan untuk menjalankan instance Pengontrol Konfigurasi per region, di mana setiap instance Pengontrol Konfigurasi mengelola resource di region tersebut.
Konfigurasi ini dapat diterapkan, tetapi bukan merupakan salah satu opsi yang kami rekomendasikan karena alasan berikut:
Beberapa resource menjangkau beberapa region (seperti Cloud DNS), yang membuat strategi ini terbatas.
Umumnya, memiliki cluster Pengontrol Konfigurasi di region yang sama akan menghadapi masalah kegagalan berkorelasi: Anda perlu mengonfigurasi ulang resource secara persis ketika kegagalan regional memengaruhi Pengontrol Konfigurasi di region tersebut.
Anda harus memisahkan resource Config Connector berdasarkan region.
Pengontrol Konfigurasi saat ini tidak tersedia di semua region.
Mengonfigurasi resource Google Cloud secara langsung
Dalam situasi tertentu, Anda dapat membuat perubahan langsung pada resource Google Cloud dasar, tanpa melalui Git atau Config Connector. Config Connector mencoba memperbaiki setiap "drift", jadi jika instance Pengontrol Konfigurasi Anda masih berjalan, Config Connector akan menganggap setiap perubahan yang Anda lakukan sebagai "penyimpangan" secara manual dan mencoba mengembalikan perubahan tersebut.
Namun, jika Anda menghentikan instance Pengontrol Konfigurasi, atau jika region sedang offline, ini dapat menjadi tindakan sementara yang berguna.
Saat instance Pengontrol Konfigurasi Anda dipulihkan, Config Connector mungkin akan mencoba mengembalikan perubahan manual Anda. Untuk menghindari situasi ini, Anda dapat membuat perubahan terkait di Git untuk setiap perubahan yang Anda buat secara manual.