Halaman ini menjelaskan cara Config Sync membaca konfigurasi dari sumber kebenaran hierarkis dan menerapkan konfigurasi yang dihasilkan ke cluster Anda secara otomatis.
Jika menginginkan fleksibilitas struktural yang lebih besar (misalnya, Anda ingin membuat subfolder resource), Anda dapat membuat sumber kebenaran tidak terstruktur. Sumber tepercaya yang tidak terstruktur direkomendasikan untuk sebagian besar kasus penggunaan. Jika sudah menggunakan sumber tepercaya secara hierarkis, Anda dapat mengonversinya menjadi sumber tepercaya yang tidak terstruktur.
Untuk memahami cara Config Sync menggunakan repositori hierarkis, sebaiknya
Anda sudah terbiasa dengan repositori Git dan antarmuka command
line git
.
Struktur direktori
Untuk sumber hierarkis, Config Sync memanfaatkan struktur yang menyerupai sistem file, dan menggunakan direktori untuk menentukan cluster atau namespace yang relevan dengan konfigurasi.
namespaces/
Direktori namespaces/
berisi konfigurasi untuk namespace dan objek cakupan
namespace. Struktur dalam namespaces/
adalah mekanisme yang mendorong
pewarisan namespace.
Anda dapat membatasi namespace yang dapat mewarisi konfigurasi, dengan menggunakan
NamespaceSelector.
cluster/
Direktori cluster/
berisi konfigurasi yang berlaku untuk seluruh cluster, bukan untuk namespace. Secara default, konfigurasi apa pun dalam direktori cluster/
berlaku
untuk setiap cluster yang terdaftar di Config Sync. Anda dapat membatasi
cluster mana yang dapat dipengaruhi oleh konfigurasi menggunakan
ClusterSelector.
clusterregistry/
Direktori clusterregistry/
bersifat opsional, dan berisi konfigurasi untuk
ClusterSelectors.
ClusterSelectors membatasi cluster tempat konfigurasi diterapkan, dan dirujuk dalam
konfigurasi yang ditemukan di direktori cluster/
dan namespaces/
.
system/
Direktori system/
berisi konfigurasi untuk Operator.
Contoh sumber kebenaran hierarkis
Struktur direktori berikut menunjukkan cara menggunakan sumber kebenaran hierarkis Config Sync untuk mengonfigurasi cluster Kubernetes yang digunakan bersama oleh dua tim berbeda, team-1
dan team-2
.
- Setiap tim memiliki namespace Kubernetes, akun layanan Kubernetes, kuota resource, kebijakan jaringan, dan pengikatan peran mereka sendiri.
- Administrator cluster menyiapkan kebijakan di
namespaces/limit-range.yaml
untuk membatasi alokasi resource (ke Pod atau container) di kedua namespace. - Administrator cluster juga menyiapkan ClusterRoles dan ClusterRoleBindings.
Sumber hierarki Config Sync yang valid harus berisi
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 cakupan namespace. Setiap subdirektori pada namespaces/
menyertakan
konfigurasi untuk objek namespace dan semua objek cakupan namespace di
namespace tersebut. Nama subdirektori harus sama dengan nama
objek namespace. Objek cakupan namespace yang perlu dibuat di setiap namespace, dapat ditempatkan langsung di bagian namespaces/
(misalnya, namespaces/limit-range.yaml
).
Direktori system/
berisi konfigurasi untuk Operator ConfigManagement.
├── 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 tepercaya hierarkis, Anda dapat menggunakan konsep pewarisan namespace untuk menerapkan konfigurasi secara otomatis ke grup namespace di semua cluster tempat namespace tersebut ada (atau seharusnya ada).
Pewarisan namespace berlaku untuk direktori namespaces/
repositori hierarkis dan semua subdirektorinya. Konfigurasi di direktori lain dalam repositori, seperti cluster/
, tidak dapat diwarisi.
Dalam sumber tepercaya hierarki, 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 namespace juga dapat berisi konfigurasi untuk jenis objek Kubernetes lainnya. Direktori namespace tidak boleh berisi subdirektori. Konfigurasi namespace mewakili namespace sebenarnya dalam cluster.Direktori namespace abstrak berisi direktori namespace. Library ini juga dapat berisi konfigurasi untuk objek Kubernetes lainnya, tetapi tidak boleh langsung berisi konfigurasi untuk namespace. Direktori namespace abstrak tidak merepresentasikan objek dalam cluster Kubernetes, tetapi direktori namespace turunannya yang mewakili objek tersebut.
Untuk membantu memastikan bahwa sumber namespace dan namespace abstrak Anda memiliki jenis konfigurasi dan struktur yang benar, error KNV1003: IllegalNamespaceSubdirectoryError melaporkan jika ada masalah.
Konfigurasi dalam direktori namespace hanya berlaku untuk namespace tersebut. Namun, konfigurasi dalam direktori namespace abstrak diterapkan ke semua direktori namespace turunan namespace abstrak tersebut (atau namespace turunan yang cocok dengan NamespaceSelector konfigurasi, jika ada).
Pewarisan konfigurasi dalam direktori namespaces/
sebagian besar didasarkan pada lokasinya dalam hierarki direktori di sumber tepercaya. Untuk memahami
konfigurasi mana yang diterapkan ke namespace tertentu dalam cluster tertentu, Anda dapat
menjelajahi
repositori contoh pewarisan namespace.
Namespace yang dibatasi
config-management-system
adalah namespace yang dibatasi. Anda tidak bisa 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 dalam sumber tepercaya Anda
Saat melakukan perubahan pada sumber tepercaya yang membuat atau menghapus direktori namespace dari dalam
direktori namespaces/
, Anda mungkin akan mendapatkan hasil yang tidak diharapkan, bergantung pada tindakannya:
- Membuat direktori: jika hierarki
namespaces/
yang valid di-commit ke sumber kebenaran, Config Sync akan membuat namespace, lalu membuat objek Kubernetes dalam namespace tersebut untuk setiap konfigurasi yang dikandung atau diwarisi oleh direktori namespace. - Menghapus direktori: menghapus direktori namespace adalah operasi destruktif. Namespace, dan isinya, dihapus, pada setiap cluster yang dikelola oleh Config Sync tempat namespace berada. Jika Anda menghapus direktori namespace abstrak yang berisi direktori namespace turunan, semua namespace tersebut beserta isinya akan 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 direktori namespace abstrak tidak memiliki efek yang terlihat secara eksternal.
Memindahkan direktori: memindahkan namespace atau direktori namespace abstrak di dalam
namespaces/
tidak akan menghapus namespace atau objek di dalamnya, kecuali saat namespace dimulai atau berhenti mewarisi konfigurasi dari direktori namespace abstrak, akibat perubahan pada hierarkinya.
Langkah selanjutnya
- Pelajari cara mengelola namespace dan objek cakupan namespace