Halaman ini menunjukkan cara terbaik menggunakan Pengontrol Konfigurasi saat mengoperasikan dengan ketersediaan tinggi atau mengelola resource di berbagai region Google Cloud.
Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya dan merencanakan kapasitas serta kebutuhan infrastruktur Anda. Untuk mempelajari lebih lanjut tentang peran umum dan contoh tugas yang kami di konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise yang umum.
Pengontrol Konfigurasi berjalan di satu region, sehingga dapat menoleransi kegagalan zona ketersediaan, tetapi jika seluruh region gagal, Pengontrol Konfigurasi kehilangan ketersediaan. Ada dua jenis perbedaan untuk menangani kegagalan regional, dan pilihan Anda tergantung pada apa yang akan dilakukan jika suatu region gagal:
Jika Anda akan membuat perubahan konfigurasi sebagai respons terhadap kegagalan regional, membuat instance Pengontrol Konfigurasi kedua.
Jika Anda tidak akan membuat perubahan konfigurasi, menggunakan satu instance Pengontrol Konfigurasi.
Memahami skenario kegagalan
Pengontrol Konfigurasi menggunakan cluster GKE regional. Meskipun cluster regional dapat menoleransi kegagalan satu zona dalam di region, cluster akan menjadi tidak tersedia jika beberapa zona di region tersebut gagal.
Jika instance Pengontrol Konfigurasi gagal, berarti Google Cloud Anda yang ada resource tetap dalam status saat ini. Namun, bahkan jika aplikasi Anda masih berjalan, Anda tidak dapat mengubah konfigurasinya saat Pengontrol Konfigurasi tidak tersedia. Ini berlaku untuk resource di region yang sama dan 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 resource kegagalan mempengaruhi resource Google Cloud yang ada di Pengontrol Konfigurasi Anda tidak bisa memperbaiki resource tersebut.
Karena Anda juga tidak dapat mengonfigurasi ulang resource di region lain, kegagalan di satu wilayah kini telah memengaruhi kemampuan Anda untuk melakukan perubahan di wilayah lain.
Skenario kegagalan lainnya juga dimungkinkan. Misalnya, jika Anda mengonfigurasi Config Sync untuk mengambil dari penyedia Git eksternal, Anda harus mempertimbangkan mode kegagalan penyedia Git tersebut. Anda mungkin tidak dapat melakukan konfigurasi perubahan karena Anda tidak dapat mengirim perubahan ke penyedia Git tersebut. Atau jika Config Sync tidak dapat membaca dari Git, maka perubahan Git apa pun tidak akan diterapkan ke cluster, sehingga Config Connector tidak menerapkannya. Namun, kegagalan regional sering menjadi skenario kegagalan yang paling penting, karena skenario kegagalan lainnya biasanya tidak berkorelasi dengan kegagalan Pengontrol Konfigurasi.
Gunakan satu cluster untuk ketersediaan regional
Dalam banyak skenario, Anda tidak akan melakukan konfigurasi ulang apa pun jika region gagal. Dalam kasus 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 itu gagal. Demikian pula, jika Anda memiliki dengan titik tunggal database kegagalan di satu region, Anda mungkin tidak dapat pulihkan hingga region tersebut pulih. Untuk aplikasi yang tidak memerlukan ketersediaan tertinggi, situasi ini merupakan konsekuensi yang wajar terhadap biaya dan kompleksitas.
Menemukan instance Pengontrol Konfigurasi di region yang sama akan memberi Anda instance fate: Pengontrol Konfigurasi tersedia selama region utama Anda yang tersedia. Menemukan instance Pengontrol Konfigurasi di region yang berbeda bisa menjadi pilihan yang baik; walaupun Anda sekarang harus memikirkan potensi di dua region, Anda menghindari kegagalan berkorelasi pada konfigurasi Anda bidang kontrol dengan kegagalan region utama.
Atau, jika Anda memiliki konfigurasi redundan multi-regional, sistem Anda mungkin secara otomatis menghindari {i>region<i} yang gagal. Di sini juga, Anda mungkin tidak ingin melakukan konfigurasi ulang jika sebuah region gagal. Dalam hal ini, Anda mungkin memilih satu instance Pengontrol Konfigurasi.
Melakukan failover secara manual ke instance Pengontrol Konfigurasi kedua
Anda mungkin perlu melakukan beberapa konfigurasi ulang jika region gagal sehingga Anda dapat memperbaiki kegagalannya. Anda mungkin juga ingin melanjutkan konfigurasi resource di region lain, meskipun instance Pengontrol Konfigurasi Anda terletak di region yang gagal. Dalam hal ini, sebaiknya gunakan Pengontrol Konfigurasi kedua di region kedua.
Meskipun tidak disarankan, 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. Dua instance Pengontrol Konfigurasi mengamati repositori Git pada waktu yang sedikit berbeda; mereka mungkin mencoba menerapkan versi yang sedikit berbeda dari konfigurasi Google Cloud Anda. Beberapa penulis aktif ke Google Cloud meningkatkan kemungkinan Anda menemukan kuota atau batas kapasitas. Sejumlah kecil resource Config Connector juga bukan idempoten, dan membutuhkan perhatian ekstra seperti yang dibahas di bagian selanjutnya. Oleh karena itu, kami tidak boleh menggunakan dua cluster Pengontrol Konfigurasi, baik secara aktif merekonsiliasi.
Sebaiknya, jika region yang menjalankan Pengontrol Konfigurasi Anda gagal, maka Anda menjalankan Pengontrol Konfigurasi lain dalam satu detik teritorial Anda. Instance Pengontrol Konfigurasi baru harus dikonfigurasi secara identik ke yang pertama, membaca dari repositori Git yang sama. Persiapan skrip untuk memunculkan dan mengonfigurasi instance Pengontrol Konfigurasi Anda mungkin akan berguna dalam skenario ini. Saat Anda membuat instance Pengontrol Konfigurasi baru, Config Sync 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 dimulai saat region pertama pulih, maka region tersebut mungkin mencoba menerapkan region 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 daftar sumber daya yang memerlukan perhatian khusus, lihat referensi dengan batasan seputar akuisisi. Secara khusus, sebaiknya Anda berhati-hati seputar resource
Folder, dan menghindari resourceIAMServiceAccountKey(misalnya, menggunakan GKE Workload Identity).
Satu instance Pengontrol Konfigurasi per region
Jika Anda ingin menghindari instance Pengontrol Konfigurasi di satu region yang memengaruhi di region lain, Anda juga dapat mempertimbangkan untuk menjalankan Config Controller per region, tempat setiap instance Pengontrol Konfigurasi mengelola resource di region tersebut.
Konfigurasi ini dapat diterapkan, tetapi bukan salah satu opsi yang kami rekomendasikan karena alasan berikut:
Beberapa resource menjangkau beberapa region (seperti Cloud DNS), yang membuat strategi terbatas.
Umumnya, memiliki cluster Pengontrol Konfigurasi di region yang sama mengalami masalah kegagalan berkorelasi: Anda ingin mengonfigurasi ulang resource secara persis ketika kegagalan regional memengaruhi Pengontrol Konfigurasi di di wilayah tersebut.
Anda harus memisahkan resource Config Connector berdasarkan region.
Pengontrol Konfigurasi saat ini hanya tersedia di region tertentu.
Mengonfigurasi resource Google Cloud secara langsung
Dalam situasi tertentu, Anda dapat langsung melakukan perubahan pada resource Google Cloud yang mendasarinya, tanpa melalui Git atau Config Connector. Config Connector mencoba memperbaiki "penyimpangan", jadi jika Pengontrol Konfigurasi Anda instance masih berjalan, Config Connector akan mempertimbangkan setiap perubahan yang Anda lakukan secara manual menjadi "penyimpangan" dan mencoba untuk mengembalikannya.
Namun, jika Anda menghentikan instance Pengontrol Konfigurasi, atau jika region secara {i>offline<i}, ini bisa menjadi tindakan sementara yang berguna.
Saat instance Pengontrol Konfigurasi Anda pulih, Config Connector kemungkinan akan mencoba untuk mengembalikan perubahan manual Anda. Untuk menghindari situasi ini, Anda dapat membuat perubahan di Git untuk setiap perubahan yang Anda buat secara manual.