Menggunakan repositori hierarkis

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