Mengonfigurasi Config Controller untuk ketersediaan tinggi

Halaman ini menunjukkan cara terbaik menggunakan Config Controller saat mengoperasikan layanan dengan ketersediaan tinggi 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 rujuk dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE 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 berbeda untuk menangani kegagalan regional, dan pilihan Anda bergantung pada apa yang akan Anda lakukan jika suatu region gagal:

Memahami skenario kegagalan

Config Controller menggunakan cluster GKE regional. Meskipun cluster regional dapat mentoleransi kegagalan satu zona dalam suatu region, cluster akan menjadi tidak tersedia jika beberapa zona dalam region tersebut gagal.

Jika instance Config Controller Anda gagal, resource Google Cloud yang ada akan tetap dalam statusnya saat ini. Namun, meskipun aplikasi Anda masih berjalan, Anda tidak dapat mengubah konfigurasinya saat Config Controller tidak tersedia. Hal ini berlaku untuk resource di region yang sama dan untuk resource di region lain yang Anda kelola dari Config Controller di region yang tidak tersedia.

Karena Anda tidak dapat mengonfigurasi ulang resource di region yang sama, jika kegagalan regional 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 memengaruhi kemampuan Anda untuk melakukan perubahan di region lain.

Skenario kegagalan lainnya juga mungkin terjadi. Misalnya, jika Anda mengonfigurasi Config Sync untuk menarik 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, maka perubahan Git apa pun tidak diterapkan ke kluster, sehingga Config Connector tidak menerapkannya. Namun, kegagalan regional sering kali menjadi skenario kegagalan yang paling penting, karena skenario kegagalan lainnya biasanya tidak berkorelasi dengan kegagalan Config Controller.

Menggunakan satu cluster untuk ketersediaan regional

Dalam banyak skenario, Anda tidak akan melakukan konfigurasi ulang jika suatu region gagal. Dalam hal ini, Anda dapat memilih untuk menerima bahwa kegagalan regional menyebabkan bidang kontrol konfigurasi Anda menjadi tidak tersedia.

Misalnya, jika Anda hanya beroperasi di satu region, mungkin tidak ada rekonfigurasi 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 melakukan pemulihan hingga region tersebut pulih. Untuk aplikasi yang tidak memerlukan ketersediaan tertinggi mutlak, situasi ini dapat menjadi pertukaran yang wajar terhadap biaya dan kompleksitas.

Menemukan instance Config Controller di region yang sama akan memberi Anda nasib yang sama: Config Controller tersedia selama region utama Anda tersedia. Menempatkan instance Config Controller di region lain juga bisa menjadi pilihan yang baik; meskipun sekarang Anda harus memikirkan potensi kegagalan di dua region, Anda menghindari kegagalan berkorelasi pada bidang kontrol konfigurasi dengan kegagalan region utama.

Atau, jika Anda memiliki konfigurasi redundan multi-regional, sistem Anda dapat otomatis menghindari region yang gagal. Di sini juga, Anda mungkin tidak ingin melakukan rekonfigurasi jika suatu region gagal. Dalam hal ini, Anda dapat memilih satu instance Config Controller.

Melakukan failover secara manual ke instance Config Controller kedua

Anda mungkin perlu 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 Pengontrol Konfigurasi Anda berada di region yang gagal. Dalam kasus ini, sebaiknya gunakan instance Config Controller kedua di region kedua.

Meskipun tidak direkomendasikan, dua instance Config Controller 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 Config Controller mengamati repositori Git pada waktu yang sedikit berbeda; keduanya mungkin mencoba menerapkan konfigurasi Google Cloud versi yang sedikit berbeda. Beberapa penulis aktif dapat meningkatkan kemungkinan Anda mencapai kuota atau batas kecepatan. Google Cloud Sejumlah kecil resource Config Connector juga tidak idempoten, dan memerlukan perhatian ekstra seperti yang dibahas di bagian ini. Oleh karena itu, sebaiknya jangan memiliki dua cluster Pengontrol Konfigurasi yang keduanya melakukan rekonsiliasi secara aktif.

Sebaiknya, jika region yang menjalankan Pengontrol Konfigurasi Anda gagal, jalankan Pengontrol Konfigurasi lain di region kedua. Instance Config Controller baru harus dikonfigurasi secara identik dengan instance pertama, dengan membaca dari repositori Git yang sama. Menyiapkan skrip untuk memunculkan dan mengonfigurasi instance Config Controller mungkin berguna dalam skenario ini. Saat Anda membuat instance Config Controller 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 Config Controller pertama masih berjalan, atau mulai berjalan saat wilayah pertama dipulihkan, cluster tersebut mungkin 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 penanganan khusus, lihat resource dengan pembatasan terkait akuisisi. Secara khusus, sebaiknya berhati-hatilah dengan resource Folder, dan hindari resource IAMServiceAccountKey (misalnya, gunakan Federasi Identitas Beban Kerja GKE untuk GKE).

Satu instance Config Controller per region

Jika Anda ingin menghindari instance Config Controller di satu region 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), sehingga strategi ini terbatas.

  • Umumnya, memiliki cluster Pengontrol Konfigurasi di region yang sama akan mengalami masalah kegagalan yang saling terkait: Anda ingin mengonfigurasi ulang resource tepat saat kegagalan regional memengaruhi Pengontrol Konfigurasi di region tersebut.

  • Anda harus memisahkan resource Config Connector menurut region.

  • Config Controller saat ini tidak tersedia di semua wilayah.

Mengonfigurasi Google Cloud resource secara langsung

Dalam keadaan tertentu, Anda dapat melakukan perubahan langsung pada resource Google Cloud yang mendasarinya, tanpa melalui Git atau Config Connector. Config Connector mencoba memperbaiki "penyimpangan", jadi jika instance Config Controller Anda masih berjalan, Config Connector menganggap setiap perubahan yang Anda lakukan secara manual sebagai "penyimpangan" dan mencoba mengembalikannya.

Namun, jika Anda menghentikan instance Config Controller, atau jika region sedang offline, hal ini dapat menjadi tindakan sementara yang berguna.

Saat instance Config Controller Anda pulih, Config Connector kemungkinan akan mencoba mengembalikan perubahan manual Anda. Untuk menghindari situasi ini, Anda dapat membuat perubahan yang sesuai di Git untuk setiap perubahan yang Anda buat secara manual.