pertimbangan kro untuk EKS - Amazon EKS
Kapan menggunakan kroPola RBACIntegrasi dengan kemampuan EKS lainnyaPengorganisasian ResourceGraphDefinitionsPembuatan versi dan pembaruanValidasi dan pengujianDokumentasi huluLangkah selanjutnya

Bantu tingkatkan halaman ini

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

pertimbangan kro untuk EKS

Topik ini mencakup pertimbangan penting untuk menggunakan Kemampuan EKS untuk kro, termasuk kapan harus menggunakan komposisi sumber daya, pola RBAC, dan integrasi dengan kemampuan EKS lainnya.

Kapan menggunakan kro

kro dirancang untuk menciptakan pola infrastruktur yang dapat digunakan kembali dan kustom APIs yang menyederhanakan manajemen sumber daya yang kompleks.

Gunakan kro saat Anda perlu:

  • Buat platform swalayan dengan disederhanakan APIs untuk tim aplikasi

  • Standarisasi pola infrastruktur di seluruh tim (database+cadangan+pemantauan)

  • Kelola dependensi sumber daya dan berikan nilai antar sumber daya

  • Membangun abstraksi kustom yang menyembunyikan kompleksitas implementasi

  • Tulis beberapa sumber daya ACK ke dalam blok bangunan tingkat yang lebih tinggi

  • Aktifkan GitOps alur kerja untuk tumpukan infrastruktur yang kompleks

Jangan gunakan kro saat:

  • Mengelola sumber daya yang sederhana dan mandiri (gunakan sumber daya ACK atau Kubernetes secara langsung)

  • Anda memerlukan logika runtime dinamis (kro bersifat deklaratif, bukan imperatif)

  • Sumber daya tidak memiliki dependensi atau konfigurasi bersama

kro unggul dalam menciptakan “jalur beraspal” - pola yang berpendirian dan dapat digunakan kembali yang memudahkan tim untuk menerapkan infrastruktur kompleks dengan benar.

Pola RBAC

kro memungkinkan pemisahan kekhawatiran antara tim platform yang membuat ResourceGraphDefinitions dan tim aplikasi yang membuat instance.

Tanggung jawab tim platform

Tim platform membuat dan memelihara ResourceGraphDefinitions (RGDs) yang mendefinisikan kustom APIs.

Izin yang dibutuhkan:

  • Buat, perbarui, hapus ResourceGraphDefinitions

  • Mengelola jenis sumber daya yang mendasarinya (Penerapan, Layanan, sumber daya ACK)

  • Akses ke semua ruang nama tempat RGDs akan digunakan

Contoh ClusterRole untuk tim platform:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-kro-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

Untuk konfigurasi RBAC mendetail, lihat. Konfigurasikan izin kro

Tanggung jawab tim aplikasi

Tim aplikasi membuat contoh sumber daya khusus yang ditentukan oleh RGDs tanpa perlu memahami kompleksitas yang mendasarinya.

Izin yang dibutuhkan:

  • Membuat, memperbarui, menghapus contoh sumber daya kustom

  • Baca akses ke namespace mereka

  • Tidak ada akses ke sumber daya yang mendasarinya atau RGDs

Manfaat:

  • Tim menggunakan sederhana, tingkat tinggi APIs

  • Tim platform mengontrol detail implementasi

  • Mengurangi risiko kesalahan konfigurasi

  • Orientasi lebih cepat untuk anggota tim baru

Integrasi dengan kemampuan EKS lainnya

Menyusun sumber daya ACK

kro sangat kuat bila dikombinasikan dengan ACK untuk menciptakan pola infrastruktur.

Pola umum:

  • Aplikasi dengan penyimpanan: ember S3+antrian SQS+konfigurasi notifikasi

  • Tumpukan basis data: contoh RDS+grup parameter+grup keamanan+Rahasia Secrets Manager

  • Jaringan: VPC+subnet+tabel rute+grup keamanan+gateway NAT

  • Hitung dengan penyimpanan: EC2 instance+volume EBS+profil instans IAM

kro menangani urutan ketergantungan, meneruskan nilai antara sumber daya (seperti ARNs dan string koneksi), dan mengelola siklus hidup penuh sebagai satu unit.

Untuk contoh penyusunan sumber daya ACK, lihatKonsep ACK.

GitOps dengan Argo CD

Gunakan Kemampuan EKS untuk Argo CD untuk menyebarkan keduanya RGDs dan instance dari repositori Git.

Organisasi repositori:

  • Platform repo: Berisi ResourceGraphDefinitions dikelola oleh tim platform

  • Repo aplikasi: Berisi contoh sumber daya khusus yang dikelola oleh tim aplikasi

  • Repo bersama: Berisi keduanya RGDs dan instance untuk organisasi yang lebih kecil

Pertimbangan:

  • Terapkan RGDs sebelum instance (Gelombang sinkronisasi CD Argo dapat membantu)

  • Gunakan Proyek CD Argo terpisah untuk tim platform dan aplikasi

  • Tim platform mengontrol akses repositori RGD

  • Tim aplikasi memiliki akses hanya-baca ke definisi RGD

Untuk informasi lebih lanjut tentang Argo CD, lihatBekerja dengan Argo CD.

Pengorganisasian ResourceGraphDefinitions

Atur RGDs berdasarkan tujuan, kompleksitas, dan kepemilikan.

Dengan tujuan:

  • Infrastruktur: Tumpukan basis data, jaringan, penyimpanan

  • Aplikasi: Aplikasi web, APIs, pekerjaan batch

  • Platform: Layanan bersama, pemantauan, pencatatan

Dengan kompleksitas:

  • Sederhana: 2-3 sumber daya dengan dependensi minimal

  • Sedang: 5-10 sumber daya dengan beberapa dependensi

  • Kompleks: 10+ sumber daya dengan dependensi kompleks

Konvensi penamaan:

  • Gunakan nama deskriptif:webapp-with-database, s3-notification-queue

  • Sertakan versi dalam nama untuk melanggar perubahan: webapp-v2

  • Gunakan awalan yang konsisten untuk terkait RGDs:, platform- app-

Strategi namespace:

  • RGDs memiliki cakupan cluster (bukan namespaced)

  • Instance diberi namespaced

  • Gunakan pemilih namespace RGDs untuk mengontrol tempat instance dapat dibuat

Pembuatan versi dan pembaruan

Rencanakan evolusi RGD dan migrasi instans.

Pembaruan RGD:

  • Perubahan yang tidak melanggar: Perbarui RGD di tempat (tambahkan bidang opsional, sumber daya baru dengan IncludeWhen)

  • Perubahan yang melanggar: Buat RGD baru dengan nama berbeda (webapp-v2)

  • Penghentian: Tandai lama RGDs dengan anotasi, komunikasikan garis waktu migrasi

Migrasi contoh:

  • Buat instance baru dengan RGD yang diperbarui

  • Validasi instance baru bekerja dengan benar

  • Hapus instance lama

  • kro menangani pembaruan sumber daya yang mendasarinya secara otomatis

Praktik terbaik:

  • Uji perubahan RGD di lingkungan non-produksi terlebih dahulu

  • Gunakan versi semantik dalam nama RGD untuk perubahan besar

  • Perubahan pemecahan dokumen dan jalur migrasi

  • Berikan contoh migrasi untuk tim aplikasi

Validasi dan pengujian

Validasi RGDs sebelum menerapkan ke produksi.

Strategi validasi:

  • Validasi skema: kro memvalidasi struktur RGD secara otomatis

  • Instance dry-run: Buat instance pengujian di ruang nama pengembangan

  • Tes integrasi: Verifikasi sumber daya yang disusun bekerja bersama

  • Penegakan kebijakan: Gunakan pengontrol penerimaan untuk menegakkan standar organisasi

Masalah umum untuk diuji:

  • Ketergantungan dan pemesanan sumber daya

  • Nilai yang lewat di antara sumber daya (ekspresi CEL)

  • Inklusi sumber daya bersyarat (IncludeWhen)

  • Perbanyakan status dari sumber daya yang mendasarinya

  • Izin RBAC untuk pembuatan contoh

Dokumentasi hulu

Untuk informasi rinci tentang penggunaan kro:

Langkah selanjutnya