Mengatur file konfigurasi dalam sumber tepercaya

Halaman ini menjelaskan cara mengatur konfigurasi dalam sumber tepercaya.

Seiring pertumbuhan 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 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, Peran, RoleBinding, ResourceQuota, dan objek Kubernetes penting lainnya, di seluruh fleet Anda.

Saat Config Sync mengelola resource ini, Config Sync akan menjaga cluster terdaftar Anda tetap sinkron menggunakan konfigurasi. Konfigurasi adalah file YAML atau JSON dalam 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 di 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, tunggu Config Sync menghapus objek dari cluster, lalu buat ulang objek di sumber tepercaya dengan pembaruan Anda.

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

  • Anda tidak dapat menggunakan Config Sync untuk mengelola ClusterRole Kubernetes bawaan secara langsung. GKE dilengkapi dengan beberapa peran bawaan yang dapat digunakan pengguna , seperti cluster-admin, admin, edit, dan view. Anda tidak dapat mengelola ClusterRole ini secara langsung dengan Config Sync, jika tidak, Config Sync akan berkonflik dengan GKE. Untuk menambahkan izin ke ClusterRole bawaan, gunakan agregasi 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 dapat mengonfigurasi Config Sync untuk melakukan sinkronisasi dari seluruh repositori, atau dari folder atau cabang tertentu. Karena fleksibilitas ini, atur 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 untuk 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 tidak terstruktur, Anda memiliki fleksibilitas untuk mengatur konfigurasi agar sesuai dengan alur kerja tim Anda. Bagian ini menyediakan 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 diatur sebagai berikut:

  • cluster-essentials/: berisi konfigurasi yang berlaku untuk semua cluster, terlepas dari lingkungan. 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 menyediakan jalur promosi yang jelas untuk perubahan dari satu lingkungan ke lingkungan lain.

Saat menyiapkan Config Sync dalam skenario ini, Anda akan membuat beberapa objek RootSync di setiap cluster. Misalnya, cluster pengembangan memiliki objek RootSync 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 sesuai.

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

Dalam contoh ini, sumber tepercaya diatur 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 dapat lebih kompleks 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 memiliki tim berbeda yang mengelola aplikasi atau layanan yang berbeda, 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 diatur dengan cara berikut:

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

Pendekatan ini memungkinkan tim mengelola siklus konfigurasi dan rilis mereka sendiri serta mengurangi kemungkinan perubahan 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 disinkronkan dari teams/team-alpha/.

Memvalidasi file konfigurasi

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

Mengabaikan mutasi objek

Jika Anda tidak ingin Config Sync mempertahankan status objek di cluster setelah ada, tambahkan anotasi client.lifecycle.config.k8s.io/mutation: ignore ke objek yang ingin Anda abaikan mutasinya 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 ke repositori tidak terstruktur

Jika Anda menggunakan repositori hierarkis dan ingin mengonversinya ke 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 terdaftar. Subdirektori ini berisi konfigurasi yang sepenuhnya diselesaikan dan dapat digunakan di repositori tidak terstruktur.

Untuk mengetahui detail selengkapnya, lihat nomos perintah.

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 bawah direktori namespaces/).

Langkah berikutnya