Halaman ini menjelaskan cara Config Sync membaca configs dari sumber kebenaran hierarkis dan menerapkan konfigurasi yang dihasilkan ke cluster secara otomatis.
Jika Anda menginginkan lebih banyak fleksibilitas struktural (misalnya, Anda ingin membuat {i>subfolder<i} sumber daya) Anda dapat membuat sumber tepercaya tidak terstruktur. Data tidak terstruktur (Unstructured-data) sumber yang terpercaya direkomendasikan untuk sebagian besar kasus penggunaan. Jika Anda sudah menggunakan sumber kebenaran hierarkis, Anda dapat mengonversinya menjadi sumber tepercaya tidak terstruktur.
Untuk memahami bagaimana Config Sync menggunakan repositori hierarkis, sebaiknya
jika Anda tidak asing dengan repositori Git dan command line git
dalam antarmuka berbasis web
yang sederhana.
Struktur direktori
Untuk sumber hierarkis, Config Sync memanfaatkan struktur mirip sistem file, dan menggunakan direktori untuk menentukan cluster atau namespace mana dengan konfigurasi yang relevan.
namespaces/
Direktori namespaces/
berisi konfigurasi untuk namespace dan cakupan namespace
objek terstruktur dalam jumlah besar. Struktur dalam namespaces/
adalah mekanisme yang mendorong
pewarisan namespace.
Anda bisa membatasi namespace mana yang dapat mewarisi konfigurasi, dengan menggunakan
NamespaceSelector.
cluster/
Direktori cluster/
berisi konfigurasi yang berlaku untuk seluruh cluster, bukan
dibandingkan dengan namespace. Secara default, konfigurasi apa pun di direktori cluster/
berlaku
ke setiap cluster yang terdaftar di Config Sync. Anda dapat membatasi
cluster yang dapat dipengaruhi oleh
konfigurasi dengan menggunakan
ClusterSelector.
clusterregistry/
Direktori clusterregistry/
bersifat opsional, dan berisi konfigurasi untuk
ClusterSelectors.
ClusterSelectors membatasi di cluster mana konfigurasi diterapkan, dan yang direferensikan
yang ditemukan di direktori cluster/
dan namespaces/
.
system/
Direktori system/
berisi konfigurasi untuk Operator.
Contoh sumber kebenaran hierarkis
Struktur direktori berikut menunjukkan cara menggunakan Config Sync
sumber tepercaya hierarkis untuk mengonfigurasi cluster Kubernetes yang digunakan bersama oleh dua
tim yang berbeda, team-1
dan team-2
.
- Setiap tim memiliki namespace Kubernetes sendiri, akun layanan Kubernetes, resource kuota, kebijakan jaringan, binding peran.
- Administrator cluster menyiapkan kebijakan di
namespaces/limit-range.yaml
untuk membatasi alokasi resource (untuk Pod atau container) di kedua namespace. - Administrator cluster juga menyiapkan ClusterRoles dan ClusterRoleBindings.
Sumber hierarki Config Sync yang valid harus menyertakan
tiga subdirektori: cluster/
, namespaces/
, dan system/
.
Direktori cluster/
berisi konfigurasi yang berlaku untuk seluruh cluster
(seperti ClusterRole, ClusterRoleBinding), bukan ke namespace.
Direktori namespaces/
berisi konfigurasi untuk objek namespace dan
objek dengan cakupan namespace. Setiap subdirektori di bagian namespaces/
berisi bagian
untuk objek namespace dan semua objek cakupan namespace di bawah
namespace. Nama subdirektori harus sama dengan nama subdirektori
namespace. Objek cakupan namespace yang perlu dibuat di setiap
dapat ditempatkan langsung di namespaces/
(misalnya,
namespaces/limit-range.yaml
).
Direktori system/
berisi konfigurasi untuk ConfigManagement Operator.
├── cluster
│ ├── clusterrolebinding-namespace-reader.yaml
│ ├── clusterrole-namespace-reader.yaml
│ ├── clusterrole-secret-admin.yaml
│ └── clusterrole-secret-reader.yaml
├── namespaces
│ ├── limit-range.yaml
│ ├── team-1
│ │ ├── namespace.yaml
│ │ ├── network-policy-default-deny-egress.yaml
│ │ ├── resource-quota-pvc.yaml
│ │ ├── rolebinding-secret-reader.yaml
│ │ └── sa.yaml
│ └── team-2
│ ├── namespace.yaml
│ ├── network-policy-default-deny-all.yaml
│ ├── resource-quota-pvc.yaml
│ ├── rolebinding-secret-admin.yaml
│ └── sa.yaml
├── README.md
└── system
└── repo.yaml
Menggunakan pewarisan namespace dan namespace abstrak
Dengan sumber kebenaran hierarkis, Anda dapat menggunakan konsep namespace pewarisan untuk menerapkan konfigurasi secara otomatis ke grup namespace di semua cluster tempat namespace tersebut ada (atau harus ada).
Pewarisan namespace berlaku untuk namespaces/
dari repositori hierarkis
dan semua subdirektorinya. Konfigurasi di
direktori lain dalam repositori, seperti cluster/
, tidak tunduk kepada
pewarisan.
Dalam sumber kebenaran hierarkis,
Direktori namespaces/
dapat berisi dua jenis subdirektori yang berbeda:
Direktori namespace berisi konfigurasi untuk namespace. Nama file yang berisi konfigurasi tidak penting, tetapi konfigurasi harus memiliki
kind: Namespace
. Direktori {i>namespace<i} juga dapat berisi konfigurasi untuk jenis objek Kubernetes lain. Direktori namespace tidak boleh berisi subdirektori. Konfigurasi namespace mewakili namespace sebenarnya dalam .Direktori namespace abstrak berisi direktori namespace. Aplikasi ini dapat juga berisi konfigurasi untuk objek Kubernetes lain, tetapi tidak secara langsung berisi konfigurasi untuk namespace. Direktori namespace abstrak tidak merepresentasikan objek di cluster Kubernetes, tetapi namespace turunannya direktori.
Untuk membantu memastikan bahwa sumber namespace dan namespace abstrak Anda memiliki jenis konfigurasi dan struktur yang benar, error KNV1003: IllegalNamespaceSubdirectoryError laporan ketika terjadi masalah.
Konfigurasi dalam direktori namespace hanya berlaku untuk namespace tersebut. Namun, konfigurasi di direktori namespace abstrak diterapkan ke semua direktori namespace turunan (atau namespace turunan yang sesuai dengan konfigurasi NamespaceSelector, jika ada).
Pewarisan konfigurasi di direktori namespaces/
sebagian besar didasarkan
pada lokasinya di dalam pohon
direktori di sumber yang terpercaya. Untuk memahami
diterapkan ke namespace tertentu di cluster tertentu, Anda bisa
jelajahi
repositori contoh warisan namespace.
Namespace yang dibatasi
config-management-system
adalah namespace terbatas. Anda tidak dapat
menggunakannya sebagai
direktori namespace abstrak. Anda dapat menentukan
Namespace config-management-system
, tetapi satu-satunya jenis resource yang diizinkan
untuk namespace config-management-system
adalah RootSync
.
Membuat perubahan pada sumber kebenaran Anda
Saat Anda melakukan perubahan pada sumber tepercaya yang membuat atau menghapus direktori namespace dari dalam
namespaces/
, Anda mungkin mendapatkan hasil yang tidak terduga bergantung pada tindakannya:
- Membuat direktori: saat hierarki
namespaces/
yang valid berkomitmen terhadap sumber tepercaya, Config Sync membuat namespace, dan kemudian membuat objek Kubernetes dalam namespace tersebut untuk setiap konfigurasi yang yang ada di dalam direktori namespace. - Menghapus direktori: menghapus direktori namespace akan suatu operasi yang destruktif. Namespace ini, beserta isinya, akan dihapus, di setiap cluster yang dikelola oleh Config Sync tempat namespace berada. Jika Anda menghapus direktori namespace abstrak yang berisi namespace turunan semua ruang nama tersebut dan isinya dihapus dari setiap cluster yang dikelola oleh Config Sync.
Mengganti nama direktori: Mengganti nama direktori namespace adalah penghapusan, diikuti dengan pembuatan dan dianggap sebagai operasi yang destruktif. Mengganti nama namespace abstrak tidak memiliki pengaruh yang terlihat secara eksternal.
Memindahkan direktori: memindahkan namespace atau direktori namespace abstrak dalam
namespaces/
tidak akan menghapus namespace atau objek di dalamnya, kecuali jika namespace mulai atau berhenti mewarisi konfigurasi dari direktori namespace abstrak, karena terhadap perubahan dalam hierarkinya.
Langkah selanjutnya
- Pelajari cara mengelola namespace dan objek cakupan namespace