Mengatur file konfigurasi dalam sumber tepercaya

Halaman ini menjelaskan cara mengatur konfigurasi dalam sumber tepercaya.

Seiring berkembangnya organisasi Anda, Anda mungkin perlu mengelola konfigurasi di seluruh fleet cluster dan mendukung beberapa tim yang bekerja di repositori yang sama. Bagian penting dari strategi GitOps yang berhasil adalah memastikan bahwa konfigurasi diterapkan ke cluster yang benar dan tim dapat bekerja tanpa saling mengganggu.

Tentang file konfigurasi

Config Sync dirancang untuk operator cluster yang mengelola banyak cluster. Anda dapat memastikan bahwa cluster Anda memenuhi standar bisnis dan kepatuhan dengan mengizinkan Config Sync mengelola namespace, Role, RoleBinding, ResourceQuota, dan objek Kubernetes penting lainnya, di seluruh armada Anda.

Saat mengelola resource ini, Config Sync akan menjaga cluster terdaftar Anda tetap sinkron menggunakan konfigurasi. Konfigurasi adalah file YAML atau JSON di sumber tepercaya. Config Sync mendukung repositori Git, image OCI, dan diagram Helm sebagai sumber tepercaya. Konfigurasi berisi jenis detail konfigurasi yang sama yang dapat Anda terapkan secara manual ke cluster menggunakan perintah kubectl apply. Anda dapat membuat konfigurasi untuk objek Kubernetes apa pun yang dapat ada dalam cluster. Namun, beberapa objek Kubernetes, seperti Secret, berisi informasi sensitif yang mungkin tidak sesuai untuk disimpan dalam sumber tepercaya. Pertimbangkan dengan cermat apakah akan mengelola jenis objek ini menggunakan Config Sync.

Persyaratan dan batasan

  • Beberapa resource Kubernetes berisi kolom yang tidak dapat diubah, seperti pemilih Pod dalam objek Deployment. Anda tidak dapat mengubah kolom yang tidak dapat diubah dalam konfigurasi dengan mengubah nilai dalam sumber tepercaya. Mencoba melakukan perubahan tersebut akan menyebabkan error KNV2009. Jika Anda perlu mengubah kolom yang tidak dapat diubah, hapus objek dari sumber tepercaya Anda, tunggu hingga Config Sync menghapus objek dari cluster, lalu buat ulang objek di sumber tepercaya Anda dengan pembaruan Anda.

  • Jika Anda menggunakan submodul Git, Anda harus memberi akses Config Sync ke semua repositori, termasuk submodul apa pun.

  • Anda tidak dapat menggunakan Config Sync untuk mengelola ClusterRole Kubernetes bawaan secara langsung. GKE dilengkapi dengan beberapa peran yang dapat diakses pengguna bawaan, seperti cluster-admin, admin, edit, dan view. Anda tidak dapat mengelola ClusterRole ini secara langsung dengan Config Sync, karena Config Sync akan berkonflik dengan GKE. Untuk menambahkan izin ke ClusterRole bawaan, gunakan penggabungan peran untuk mengubahnya secara tidak langsung. Untuk mengubah peran, buat ClusterRole dengan nama unik di sumber tepercaya Anda dengan anotasi yang sesuai.

Mengatur sumber tepercaya Anda

Anda dapat mengonfigurasi Config Sync untuk menyinkronkan dari seluruh repositori, atau dari folder atau cabang tertentu. Karena fleksibilitas ini, susun file konfigurasi Anda berdasarkan kebutuhan tim atau organisasi Anda.

Sebaiknya saat mengonfigurasi Config Sync, Anda menetapkan sourceFormat ke unstructured. Jenis sumber terstruktur (hierarkis) memerlukan struktur folder yang sangat spesifik agar dapat menyinkronkan konfigurasi Anda dengan benar dan menambahkan kompleksitas yang tidak perlu dalam sebagian besar kasus.

Sebagian besar dokumentasi Config Sync, termasuk halaman ini, menggunakan format tidak terstruktur secara default, tetapi Anda dapat menemukan informasi tentang format hierarkis, jika diperlukan, di Menggunakan repositori hierarkis.

Saat menggunakan sumber yang tidak terstruktur, Anda memiliki fleksibilitas untuk mengatur konfigurasi agar sesuai dengan alur kerja tim Anda. Bagian ini memberikan beberapa pola umum untuk menyusun repositori Anda.

Tata letak berbasis lingkungan

Pendekatan umum adalah mengatur repositori Anda berdasarkan lingkungan.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

Dalam contoh ini, sumber tepercaya disusun sebagai berikut:

  • cluster-essentials/: berisi konfigurasi yang berlaku untuk semua cluster, terlepas dari lingkungannya. Hal ini dapat mencakup resource seperti Definisi Resource Kustom (CRD) dan namespace penting.
  • environments/: direktori induk untuk semua konfigurasi khusus lingkungan.
  • system/: berisi konfigurasi untuk layanan tingkat sistem seperti pemantauan.

Pendekatan ini mudah dipahami dan dinavigasi serta memberikan jalur promosi yang jelas untuk perubahan dari satu lingkungan ke lingkungan lainnya.

Saat menyiapkan Config Sync dalam skenario ini, Anda akan membuat beberapa objek RootSync di setiap cluster. Misalnya, cluster pengembangan memiliki RootSync objek yang disinkronkan dari cluster-essentials/, system/, dan environments/dev/.

Tata letak berbasis cluster

Jika fokus Anda adalah mengelola fleet cluster individual dengan konfigurasi yang berbeda, tata letak berbasis cluster mungkin lebih cocok.

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

Dalam contoh ini, sumber tepercaya disusun sebagai berikut:

  • clusters/: berisi direktori untuk setiap cluster yang Anda kelola.
  • shared/: menyimpan konfigurasi yang umum di semua cluster, seperti peran RBAC dan kebijakan keamanan.

Pendekatan ini efektif untuk mengelola banyak cluster jika semua cluster tersebut memiliki konfigurasi unik, karena memberikan kepemilikan dan isolasi konfigurasi yang jelas. Pendekatan ini bisa lebih rumit untuk dikelola jika Anda memiliki banyak konfigurasi cluster bersama.

Saat menyiapkan Config Sync dalam skenario ini, Anda dapat menggunakan RepoSync untuk mengonfigurasi setiap cluster agar disinkronkan dari shared dan direktori khusus cluster.

Tata letak berbasis tim

Untuk organisasi yang timnya berbeda-beda mengelola aplikasi atau layanan yang berbeda-beda, tata letak berbasis tim dapat efektif. Pendekatan ini menyelaraskan struktur sumber tepercaya dengan struktur organisasi Anda.

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

Dalam contoh ini, sumber tepercaya disusun dengan cara berikut:

  • teams/: mengatur konfigurasi menurut tim, dengan setiap tim mengelola konfigurasi aplikasi dan layanan mereka sendiri.
  • platform/: berisi konfigurasi seluruh cluster yang dikelola oleh tim platform pusat dan digunakan oleh semua tim.

Pendekatan ini memungkinkan tim mengelola siklus rilis dan konfigurasi mereka sendiri serta mengurangi kemungkinan perubahan yang dilakukan satu tim memengaruhi tim lain secara tidak sengaja. Namun, pendekatan ini memerlukan pengelolaan dependensi yang cermat antara tim aplikasi dan tim platform.

Saat Anda menyiapkan Config Sync, untuk skenario ini, setiap tim menggunakan objek RootSync untuk menyinkronkan konfigurasi, misalnya team-alpha menyinkronkan dari teams/team-alpha/.

Memvalidasi file konfigurasi

Setelah membuat, mengatur, dan menambahkan file konfigurasi ke sumber kebenaran, gunakan perintah nomos vet --source-format=unstructured untuk memeriksa sintaks dan validitas konfigurasi Anda. Tindakan ini membantu Anda menghindari error selama atau setelah sinkronisasi.

Mengabaikan mutasi objek

Jika Anda tidak ingin Config Sync mempertahankan status objek di cluster setelah objek tersebut ada, tambahkan anotasi client.lifecycle.config.k8s.io/mutation: ignore ke objek yang mutasinya ingin diabaikan oleh Config Sync.

Contoh berikut menunjukkan cara menambahkan anotasi ke objek:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

Anda tidak dapat mengubah anotasi ini secara manual pada objek terkelola di cluster.

Mengonversi repositori hierarkis menjadi repositori tidak terstruktur

Jika Anda menggunakan repositori hierarkis dan ingin mengonversinya menjadi repositori tidak terstruktur, jalankan perintah berikut:

nomos hydrate PATH

Ganti PATH dengan jalur ke direktori Anda.

Perintah ini akan membuat direktori compiled/ di direktori kerja saat ini. Dalam direktori tersebut, subdirektori dibuat untuk setiap cluster yang terdaftar. Subdirektori ini berisi konfigurasi yang telah sepenuhnya diselesaikan dan dapat digunakan di repositori yang tidak terstruktur.

Untuk mengetahui detail selengkapnya, lihat perintah nomos.

Jika Anda lebih suka mengonversi repositori secara manual, selesaikan petunjuk berikut:

  1. Hapus konfigurasi Repo di direktori system/ dari repositori Git Anda. Resource Repo tidak diperlukan untuk repositori tidak terstruktur.

  2. Direktori namespace abstrak tidak didukung di repositori tidak terstruktur. Oleh karena itu, deklarasikan namespace semua resource yang awalnya disertakan dalam direktori namespaces/ dan subdirektorinya.

  3. Pewarisan namespace tidak didukung di repositori tidak terstruktur. Oleh karena itu, deklarasikan semua resource yang awalnya diwarisi di namespace turunan (yang awalnya berada di direktori namespaces/).

Langkah berikutnya