**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.
# Komposisi Sumber Daya dengan kro (Kube Resource Orchestrator)
**kro (Kube Resource Orchestrator)** adalah proyek asli Kubernetes open-source yang memungkinkan Anda mendefinisikan Kubernetes kustom menggunakan konfigurasi sederhana dan langsung. APIs Dengan kro, Anda dapat dengan mudah mengkonfigurasi kustom baru APIs yang membuat sekelompok objek Kubernetes dan operasi logis di antara mereka.
Dengan Kemampuan EKS, kro dikelola sepenuhnya oleh AWS, menghilangkan kebutuhan untuk menginstal, memelihara, dan menskalakan pengontrol kro pada cluster Anda.
## Bagaimana kro Bekerja
kro memperkenalkan Custom Resource Definition (CRD) yang disebut `ResourceGraphDefinition` (RGD) yang memungkinkan pembuatan Kubernetes kustom yang sederhana dan efisien. APIs Saat Anda membuat`ResourceGraphDefinition`, kro menggunakan ekstensi Kubernetes asli untuk membuat dan mengelola yang baru APIs di klaster Anda. Dari spesifikasi sumber daya tunggal ini, kro akan membuat dan mendaftarkan CRD baru untuk Anda berdasarkan spesifikasi Anda dan akan beradaptasi untuk mengelola sumber daya kustom Anda yang baru ditentukan.
RGDs dapat menyertakan beberapa sumber daya, dan kro akan menentukan saling ketergantungan dan pemesanan sumber daya, jadi Anda tidak perlu melakukannya. Anda dapat menggunakan sintaks sederhana untuk menyuntikkan konfigurasi dari satu sumber daya ke sumber daya lainnya, sangat menyederhanakan komposisi dan menghilangkan kebutuhan akan operator “lem” di cluster Anda. Dengan kro, sumber daya kustom Anda dapat menyertakan sumber daya Kubernetes asli serta Custom Resource Definition (CRDs) yang diinstal di cluster.
kro mendukung satu jenis sumber daya utama:
+ **ResourceGraphDefinition (RGD)**: Mendefinisikan sumber daya kustom Kubernetes, merangkum satu atau beberapa sumber daya Kubernetes asli atau kustom yang mendasarinya
Selain sumber daya ini, kro akan membuat dan mengelola siklus hidup sumber daya kustom Anda yang dibuat dengannya, serta semua sumber daya konstituennya.
kro terintegrasi secara mulus dengan AWS Controllers for Kubernetes (ACK), memungkinkan Anda untuk menyusun sumber daya beban kerja dengan sumber daya untuk membuat abstraksi tingkat yang lebih tinggi. AWS Ini memungkinkan Anda untuk membuat blok bangunan cloud Anda sendiri, menyederhanakan manajemen sumber daya dan mengaktifkan pola yang dapat digunakan kembali dengan pengaturan konfigurasi default dan tidak dapat diubah berdasarkan standar organisasi Anda.
## Manfaat kro
kro memungkinkan tim platform untuk membuat Kubernetes kustom yang menyusun beberapa sumber daya menjadi APIs abstraksi tingkat yang lebih tinggi. Ini menyederhanakan manajemen sumber daya dengan memungkinkan pengembang untuk menyebarkan aplikasi kompleks menggunakan sumber daya kustom yang sederhana, standar, dan berversi. Anda menentukan pola yang dapat digunakan kembali untuk kombinasi sumber daya umum, memungkinkan pembuatan sumber daya yang konsisten di seluruh organisasi Anda.
kro menggunakan [Common Expression Language (CEL) di Kubernetes](https://kubernetes.io/docs/reference/using-api/cel/) untuk meneruskan nilai antar sumber daya dan menggabungkan logika bersyarat, memberikan fleksibilitas dalam komposisi sumber daya. Anda dapat menyusun sumber daya Kubernetes dan AWS sumber daya yang dikelola oleh ACK ke dalam kustom terpadu APIs, memungkinkan definisi aplikasi dan infrastruktur yang lengkap.
kro mendukung konfigurasi deklaratif melalui manifes Kubernetes, memungkinkan GitOps alur kerja dan infrastruktur sebagai praktik kode yang terintegrasi secara mulus dengan proses pengembangan Anda yang ada. Sebagai bagian dari Kemampuan Terkelola EKS, kro dikelola sepenuhnya oleh AWS, menghilangkan kebutuhan untuk menginstal, mengonfigurasi, dan memelihara pengontrol kro di cluster Anda.
**Contoh: Membuat ResourceGraphDefinition**
Contoh berikut menunjukkan sederhana `ResourceGraphDefinition` yang membuat aplikasi web dengan Deployment dan Service:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
```
Saat pengguna membuat instance sumber daya `WebApplication` kustom, kro secara otomatis membuat sumber daya Deployment dan Service yang sesuai, mengelola siklus hidup mereka bersama dengan sumber daya kustom.
## Integrasi dengan Kemampuan Terkelola EKS Lainnya
kro terintegrasi dengan Kemampuan Terkelola EKS lainnya.
+ ** AWS Controller for Kubernetes (ACK): Gunakan kro untuk menyusun sumber daya ACK** ke dalam abstraksi tingkat yang lebih tinggi, menyederhanakan manajemen sumber daya. AWS
+ **Argo CD**: Gunakan Argo CD untuk mengelola penyebaran sumber daya kustom kro di beberapa cluster, memungkinkan GitOps alur kerja untuk blok bangunan platform dan tumpukan aplikasi Anda.
## Memulai dengan kro
Untuk memulai dengan Kemampuan EKS untuk kro:
1. [Buat sumber daya kemampuan kro](create-kro-capability.md) di kluster EKS Anda melalui AWS Konsol, AWS CLI, atau infrastruktur pilihan Anda sebagai alat kode.
1. Create ResourceGraphDefinitions (RGDs) yang menentukan komposisi kustom APIs dan sumber daya Anda.
1. Terapkan instance sumber daya kustom Anda untuk menyediakan dan mengelola Kubernetes dan resource yang mendasarinya. AWS
# Buat kemampuan kro
Topik ini menjelaskan cara membuat kemampuan kro di cluster Amazon EKS Anda.
## Prasyarat
Sebelum membuat kemampuan kro, pastikan Anda memiliki:
+ Cluster Amazon EKS yang sudah ada yang menjalankan versi Kubernetes yang didukung (semua versi dalam dukungan standar dan diperpanjang didukung)
+ Izin IAM yang memadai untuk membuat sumber daya kemampuan di kluster EKS
+ (Untuk CLI/Eksctl) Alat CLI yang sesuai diinstal dan dikonfigurasi
**catatan**
Tidak seperti ACK dan Argo CD, kro tidak memerlukan izin IAM tambahan di luar kebijakan kepercayaan. kro beroperasi sepenuhnya di dalam cluster Anda dan tidak melakukan panggilan API. AWS Namun, Anda masih perlu memberikan Peran Kemampuan IAM dengan kebijakan kepercayaan yang sesuai. Untuk informasi tentang mengonfigurasi izin Kubernetes RBAC untuk kro, lihat. [Konfigurasikan izin kro](kro-permissions.md)
## Pilih alat Anda
Anda dapat membuat kemampuan kro menggunakan, AWS CLI Konsol Manajemen AWS, atau eksctl:
+ [Buat kemampuan kro menggunakan Konsol](kro-create-console.md)- Gunakan Konsol untuk pengalaman terpandu
+ [Buat kemampuan kro menggunakan CLI AWS](kro-create-cli.md)- Gunakan AWS CLI untuk scripting dan otomatisasi
+ [Buat kemampuan kro menggunakan eksctl](kro-create-eksctl.md)- Gunakan eksctl untuk pengalaman asli Kubernetes
## Apa yang terjadi ketika Anda membuat kemampuan kro
Saat Anda membuat kemampuan kro:
1. EKS membuat layanan kemampuan kro dan mengonfigurasinya untuk memantau dan mengelola sumber daya di cluster Anda
1. Definisi Sumber Daya Kustom (CRDs) diinstal di klaster Anda
1. Entri akses dibuat secara otomatis untuk Peran Kemampuan IAM Anda `AmazonEKSKROPolicy` yang memberikan izin untuk mengelola ResourceGraphDefinitions dan instansinya (lihat) [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)
1. Kemampuan mengasumsikan Peran Kemampuan IAM yang Anda berikan (hanya digunakan untuk hubungan kepercayaan)
1. kro mulai mengawasi `ResourceGraphDefinition` sumber daya dan instansinya
1. Status kemampuan berubah dari `CREATING` menjadi `ACTIVE`
Setelah aktif, Anda dapat membuat ResourceGraphDefinitions untuk menentukan kustom APIs dan membuat instance dari mereka APIs.
**catatan**
Entri akses yang dibuat secara otomatis mencakup `AmazonEKSKROPolicy` yang memberikan izin kro untuk mengelola ResourceGraphDefinitions dan instansinya. Untuk memungkinkan kro membuat sumber daya Kubernetes yang mendasari yang ditentukan dalam ResourceGraphDefinitions (seperti Deployment, Services, atau sumber daya ACK), Anda harus mengonfigurasi kebijakan entri akses tambahan. Untuk mempelajari lebih lanjut tentang entri akses dan cara mengonfigurasi izin tambahan, lihat [Konfigurasikan izin kro](kro-permissions.md) dan. [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)
## Langkah selanjutnya
Setelah membuat kemampuan kro:
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan komposisi sumber daya
+ [konsep kro](kro-concepts.md)- Pelajari tentang SimpleSchema, ekspresi CEL, dan pola komposisi sumber daya
# Buat kemampuan kro menggunakan Konsol
Topik ini menjelaskan cara membuat kapabilitas kro (Kube Resource Orchestrator) menggunakan. Konsol Manajemen AWS
## Buat kemampuan kro
1. Buka konsol Amazon EKS di https://console.aws.amazon.com/eks/ rumah\$1/cluster.
1. Pilih nama cluster Anda untuk membuka halaman detail cluster.
1. Pilih tab **Kemampuan**.
1. Di navigasi kiri, pilih **kro (Kube Resource Orchestrator**).
1. Pilih **Buat kemampuan kro**.
1. Untuk **Peran Kemampuan IAM**:
+ Jika Anda sudah memiliki Peran Kemampuan IAM, pilih dari dropdown
+ Jika Anda perlu membuat peran, pilih **Buat peran kro**
Ini membuka konsol IAM di tab baru dengan kebijakan kepercayaan yang telah diisi sebelumnya. Peran ini tidak memerlukan izin IAM tambahan karena kro beroperasi sepenuhnya di dalam klaster Anda.
Setelah membuat peran, kembali ke konsol EKS dan peran akan dipilih secara otomatis.
**catatan**
Tidak seperti ACK dan Argo CD, kro tidak memerlukan izin IAM tambahan di luar kebijakan kepercayaan. kro beroperasi sepenuhnya di dalam cluster Anda dan tidak melakukan panggilan API. AWS
1. Pilih **Buat**.
Proses pembuatan kapabilitas dimulai.
## Verifikasi kemampuan aktif
1. Pada tab **Kemampuan**, lihat status kemampuan kro.
1. Tunggu status berubah dari `CREATING` ke`ACTIVE`.
1. Setelah aktif, kemampuan siap digunakan.
Untuk informasi tentang status kemampuan dan pemecahan masalah, lihat. [Bekerja dengan sumber daya kemampuan](working-with-capabilities.md)
## Berikan izin untuk mengelola sumber daya Kubernetes
Saat Anda membuat kemampuan kro, Entri Akses EKS secara otomatis dibuat dengan`AmazonEKSKROPolicy`, yang memungkinkan kro untuk mengelola ResourceGraphDefinitions dan instance-instancenya. Namun, tidak ada izin yang diberikan secara default untuk membuat sumber daya Kubernetes yang mendasarinya (seperti Deployment, Services ConfigMaps, dll.) yang ditentukan dalam file Anda. ResourceGraphDefinitions
Desain yang disengaja ini mengikuti prinsip hak istimewa terkecil—berbeda memerlukan izin yang berbeda ResourceGraphDefinitions . Anda harus secara eksplisit mengonfigurasi izin yang dibutuhkan kro berdasarkan sumber daya yang akan Anda kelola. ResourceGraphDefinitions
Untuk memulai dengan cepat, pengujian, atau lingkungan pengembangan, gunakan`AmazonEKSClusterAdminPolicy`:
1. Di konsol EKS, navigasikan ke tab **Access** cluster Anda.
1. Di bawah **entri Access**, temukan entri untuk peran kemampuan kro Anda (itu akan memiliki peran ARN yang Anda buat sebelumnya).
1. Pilih entri akses untuk membuka detailnya.
1. Di bagian **Kebijakan akses**, pilih **Kebijakan akses asosiasi**.
1. Pilih `AmazonEKSClusterAdminPolicy` dari daftar kebijakan.
1. Untuk **cakupan Akses**, pilih **Cluster**.
1. Pilih **Kaitkan**.
**penting**
Ini `AmazonEKSClusterAdminPolicy` memberikan izin luas untuk membuat dan mengelola semua sumber daya Kubernetes, termasuk kemampuan untuk membuat jenis sumber daya apa pun di semua ruang nama. Ini nyaman untuk pengembangan dan POCs tetapi tidak boleh digunakan dalam produksi. Untuk produksi, buat kebijakan RBAC khusus yang hanya memberikan izin yang diperlukan untuk sumber daya spesifik yang akan Anda ResourceGraphDefinitions kelola. Untuk panduan tentang mengonfigurasi izin hak istimewa terkecil, lihat dan. [Konfigurasikan izin kro](kro-permissions.md) [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)
## Verifikasi sumber daya kustom tersedia
Setelah kemampuan aktif, verifikasi bahwa sumber daya kustom kro tersedia di klaster Anda.
**Menggunakan konsol**
1. Arahkan ke klaster Anda di konsol Amazon EKS
1. Pilih tab **Sumber Daya**
1. Pilih **Ekstensi**
1. Pilih **CustomResourceDefinitions**
Anda akan melihat jenis `ResourceGraphDefinition` sumber daya yang terdaftar.
**Menggunakan kubectl**
```
kubectl api-resources | grep kro.run
```
Anda akan melihat jenis `ResourceGraphDefinition` sumber daya yang terdaftar.
## Langkah selanjutnya
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan komposisi sumber daya
+ [konsep kro](kro-concepts.md)- Pelajari tentang SimpleSchema, ekspresi CEL, dan pola komposisi
+ [Bekerja dengan sumber daya kemampuan](working-with-capabilities.md)- Kelola sumber daya kemampuan kro Anda
# Buat kemampuan kro menggunakan CLI AWS
Topik ini menjelaskan cara membuat kapabilitas kro (Kube Resource Orchestrator) menggunakan CLI. AWS
## Prasyarat
+ ** AWS CLI** — Versi `2.12.3` atau yang lebih baru. Untuk memeriksa versi Anda, jalankan`aws --version`. Untuk informasi selengkapnya, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di Panduan Pengguna Antarmuka Baris AWS Perintah.
+ **`kubectl`**— Alat baris perintah untuk bekerja dengan cluster Kubernetes. Untuk informasi selengkapnya, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
## Langkah 1: Buat Peran Kemampuan IAM
Buat file kebijakan kepercayaan:
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Buat peran IAM:
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**catatan**
Tidak seperti ACK dan Argo CD, kro tidak memerlukan izin IAM tambahan. kro beroperasi sepenuhnya di dalam cluster Anda dan tidak melakukan panggilan API. AWS Peran tersebut hanya diperlukan untuk membangun hubungan kepercayaan dengan layanan kemampuan EKS.
## Langkah 2: Buat kemampuan kro
Buat sumber daya kemampuan kro di cluster Anda. Ganti *region-code* dengan AWS Wilayah tempat klaster Anda berada (seperti`us-west-2`) dan *my-cluster* dengan nama cluster Anda.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--type KRO \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/KROCapabilityRole \
--delete-propagation-policy RETAIN
```
Perintah segera kembali, tetapi kemampuannya membutuhkan waktu untuk menjadi aktif karena EKS menciptakan infrastruktur dan komponen kemampuan yang diperlukan. EKS akan menginstal Definisi Sumber Daya Kustom Kubernetes yang terkait dengan kemampuan ini di cluster Anda saat sedang dibuat.
**catatan**
Jika Anda menerima kesalahan bahwa klaster tidak ada atau Anda tidak memiliki izin, verifikasi:
Nama cluster sudah benar
AWS CLI Anda dikonfigurasi untuk wilayah yang benar
Anda memiliki izin IAM yang diperlukan
## Langkah 3: Verifikasi kemampuan aktif
Tunggu kemampuan untuk menjadi aktif. Ganti *region-code* dengan AWS Region tempat cluster Anda berada dan ganti *my-cluster* dengan nama cluster Anda.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.status' \
--output text
```
Kemampuan siap ketika status ditampilkan`ACTIVE`.
Anda juga dapat melihat detail kemampuan lengkap:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
```
## Langkah 4: Berikan izin untuk mengelola sumber daya Kubernetes
Saat Anda membuat kemampuan kro, Entri Akses EKS secara otomatis dibuat dengan`AmazonEKSKROPolicy`, yang memungkinkan kro untuk mengelola ResourceGraphDefinitions dan instance-instancenya. Namun, tidak ada izin yang diberikan secara default untuk membuat sumber daya Kubernetes yang mendasarinya (seperti Deployment, Services ConfigMaps, dll.) yang ditentukan dalam file Anda. ResourceGraphDefinitions
Desain yang disengaja ini mengikuti prinsip hak istimewa terkecil—berbeda memerlukan izin yang berbeda ResourceGraphDefinitions . Misalnya: \$1 A ResourceGraphDefinition yang hanya membuat ConfigMaps dan Rahasia membutuhkan izin yang berbeda dari yang membuat Deployment dan Services \$1 A ResourceGraphDefinition yang membuat sumber daya ACK membutuhkan izin untuk sumber daya khusus tertentu \$1 Beberapa ResourceGraphDefinitions mungkin hanya membaca sumber daya yang ada tanpa membuat yang baru
Anda harus secara eksplisit mengonfigurasi izin yang dibutuhkan kro berdasarkan sumber daya yang akan Anda kelola. ResourceGraphDefinitions
### Pengaturan cepat
Untuk memulai dengan cepat, pengujian, atau lingkungan pengembangan, gunakan`AmazonEKSClusterAdminPolicy`:
Dapatkan peran kapabilitas ARN:
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.roleArn' \
--output text)
```
Kaitkan kebijakan admin klaster:
```
aws eks associate-access-policy \
--region region-code \
--cluster-name my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**penting**
Ini `AmazonEKSClusterAdminPolicy` memberikan izin luas untuk membuat dan mengelola semua sumber daya Kubernetes, termasuk kemampuan untuk membuat jenis sumber daya apa pun di semua ruang nama. Ini nyaman untuk pengembangan dan POCs tetapi tidak boleh digunakan dalam produksi. Untuk produksi, buat kebijakan RBAC khusus yang hanya memberikan izin yang diperlukan untuk sumber daya spesifik yang akan Anda ResourceGraphDefinitions kelola. Untuk panduan tentang mengonfigurasi izin hak istimewa terkecil, lihat dan. [Konfigurasikan izin kro](kro-permissions.md) [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)
## Langkah 5: Verifikasi sumber daya kustom tersedia
Setelah kemampuan aktif, verifikasi bahwa sumber daya kustom kro tersedia di klaster Anda:
```
kubectl api-resources | grep kro.run
```
Anda akan melihat jenis `ResourceGraphDefinition` sumber daya yang terdaftar.
## Langkah selanjutnya
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan komposisi sumber daya
+ [konsep kro](kro-concepts.md)- Pelajari tentang SimpleSchema, ekspresi CEL, dan pola komposisi
+ [Bekerja dengan sumber daya kemampuan](working-with-capabilities.md)- Kelola sumber daya kemampuan kro Anda
# Buat kemampuan kro menggunakan eksctl
Topik ini menjelaskan cara membuat kapabilitas kro (Kube Resource Orchestrator) menggunakan eksctl.
**catatan**
Langkah-langkah berikut memerlukan versi `0.220.0` eksctl atau yang lebih baru. Untuk memeriksa versi Anda, jalankan`eksctl version`.
## Langkah 1: Buat Peran Kemampuan IAM
Buat file kebijakan kepercayaan:
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Buat peran IAM:
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**catatan**
Tidak seperti ACK dan Argo CD, kro tidak memerlukan izin IAM tambahan di luar kebijakan kepercayaan. kro beroperasi sepenuhnya di dalam cluster Anda dan tidak melakukan panggilan API. AWS
## Langkah 2: Buat kemampuan kro
Buat kemampuan kro menggunakan eksctl. Ganti *region-code* dengan AWS Region tempat cluster Anda berada dan ganti *my-cluster* dengan nama cluster Anda.
```
eksctl create capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--type KRO \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/KROCapabilityRole
```
Perintah segera kembali, tetapi kemampuannya membutuhkan waktu untuk menjadi aktif.
## Langkah 3: Verifikasi kemampuan aktif
Periksa status kemampuan. Ganti *region-code* dengan AWS Region tempat cluster Anda berada dan ganti *my-cluster* dengan nama cluster Anda.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-kro
```
Kemampuan siap ketika status ditampilkan`ACTIVE`.
## Langkah 4: Berikan izin untuk mengelola sumber daya Kubernetes
Secara default, kro hanya dapat membuat dan mengelola ResourceGraphDefinitions dan instance mereka. Untuk memungkinkan kro membuat dan mengelola sumber daya Kubernetes yang mendasari yang ditentukan dalam Anda ResourceGraphDefinitions, kaitkan kebijakan `AmazonEKSClusterAdminPolicy` akses dengan entri akses kapabilitas.
Dapatkan peran kapabilitas ARN:
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--query 'capability.roleArn' \
--output text)
```
Kaitkan kebijakan admin klaster:
```
aws eks associate-access-policy \
--region region-code \
--cluster my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**penting**
Ini `AmazonEKSClusterAdminPolicy` memberikan izin luas untuk membuat dan mengelola semua sumber daya Kubernetes dan dimaksudkan untuk merampingkan memulai. Untuk penggunaan produksi, buat kebijakan RBAC yang lebih ketat yang hanya memberikan izin yang diperlukan untuk sumber daya spesifik yang akan Anda kelola. ResourceGraphDefinitions Untuk panduan tentang mengonfigurasi izin hak istimewa paling sedikit, lihat dan. [Konfigurasikan izin kro](kro-permissions.md) [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)
## Langkah 5: Verifikasi sumber daya kustom tersedia
Setelah kemampuan aktif, verifikasi bahwa sumber daya kustom kro tersedia di klaster Anda:
```
kubectl api-resources | grep kro.run
```
Anda akan melihat jenis `ResourceGraphDefinition` sumber daya yang terdaftar.
## Langkah selanjutnya
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan komposisi sumber daya
+ [konsep kro](kro-concepts.md)- Pelajari tentang SimpleSchema, ekspresi CEL, dan pola komposisi
+ [Bekerja dengan sumber daya kemampuan](working-with-capabilities.md)- Kelola sumber daya kemampuan kro Anda
# konsep kro
kro memungkinkan tim platform untuk membuat Kubernetes kustom yang menyusun beberapa sumber daya menjadi APIs abstraksi tingkat yang lebih tinggi. Topik ini berjalan melalui contoh praktis, kemudian menjelaskan konsep inti yang perlu Anda pahami ketika bekerja dengan Kemampuan EKS untuk kro.
## Memulai dengan kro
Setelah membuat kemampuan kro (lihat[Buat kemampuan kro](create-kro-capability.md)), Anda dapat mulai membuat kustom APIs menggunakan ResourceGraphDefinitions di cluster Anda.
Berikut adalah contoh lengkap yang membuat abstraksi aplikasi web sederhana:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: webapplication
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
group: kro.run
spec:
name: string | required=true
image: string | default="nginx:latest"
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
selector:
matchLabels:
app: ${schema.spec.name}
template:
metadata:
labels:
app: ${schema.spec.name}
spec:
containers:
- name: app
image: ${schema.spec.image}
ports:
- containerPort: 80
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
spec:
selector:
app: ${schema.spec.name}
ports:
- protocol: TCP
port: 80
targetPort: 80
```
Setelah menerapkan ini ResourceGraphDefinition, tim aplikasi dapat membuat aplikasi web menggunakan API Anda yang disederhanakan:
```
apiVersion: kro.run/v1alpha1
kind: WebApplication
metadata:
name: my-app
spec:
name: my-app
replicas: 5
```
kro secara otomatis membuat Deployment dan Service dengan konfigurasi yang sesuai. Karena `image` tidak ditentukan, ia menggunakan nilai default `nginx:latest` dari skema.
## Konsep inti
**penting**
kro memvalidasi ResourceGraphDefinitions pada waktu pembuatan, bukan saat runtime. Saat Anda membuat RGD, kro memvalidasi sintaks CEL, memeriksa ekspresi tipe terhadap skema Kubernetes yang sebenarnya, memverifikasi keberadaan bidang, dan mendeteksi dependensi melingkar. Ini berarti kesalahan langsung tertangkap saat Anda membuat RGD, sebelum instance apa pun diterapkan.
### ResourceGraphDefinition
A ResourceGraphDefinition (RGD) mendefinisikan Kubernetes API kustom dengan menentukan:
+ **Skema** - Struktur API menggunakan SimpleSchema format (nama bidang, jenis, default, validasi)
+ **Resources** - Template untuk Kubernetes atau AWS resource yang mendasarinya untuk dibuat
+ **Dependensi** - Bagaimana sumber daya berhubungan satu sama lain (terdeteksi secara otomatis dari referensi bidang)
Saat Anda menerapkan RGD, kro mendaftarkan Custom Resource Definition (CRD) baru di cluster Anda. Tim aplikasi kemudian dapat membuat instance API kustom Anda, dan kro menangani pembuatan dan pengelolaan semua sumber daya yang mendasarinya.
Untuk informasi selengkapnya, lihat [ResourceGraphDefinition Ikhtisar](https://kro.run/docs/concepts/rgd/overview/) di dokumentasi kro.
### SimpleSchema format
SimpleSchema menyediakan cara yang disederhanakan untuk mendefinisikan skema API tanpa memerlukan pengetahuan OpenAPI:
```
schema:
apiVersion: v1alpha1
kind: Database
spec:
name: string | required=true description="Database name"
size: string | default="small" enum=small,medium,large
replicas: integer | default=1 minimum=1 maximum=5
```
SimpleSchema mendukung`string`,`integer`,`boolean`,, dan `number` tipe dengan kendala seperti`required`,,`minimum`/`maximum`,`default`, dan. `enum` `pattern`
Untuk informasi lebih lanjut, lihat [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)di dokumentasi kro.
### Ekspresi CEL
kro menggunakan Common Expression Language (CEL) untuk mereferensikan nilai secara dinamis dan menambahkan logika bersyarat. Ekspresi CEL dibungkus `${` `}` dan dan dapat digunakan dalam dua cara:
**Ekspresi mandiri** - Seluruh nilai bidang adalah ekspresi tunggal:
```
spec:
replicas: ${schema.spec.replicaCount} # Expression returns integer
labels: ${schema.spec.labelMap} # Expression returns object
```
Hasil ekspresi menggantikan seluruh nilai bidang dan harus sesuai dengan jenis bidang yang diharapkan.
**Template string** - Satu atau lebih ekspresi yang disematkan dalam string:
```
metadata:
name: "${schema.spec.prefix}-${schema.spec.name}" # Multiple expressions
annotation: "Created by ${schema.spec.owner}" # Single expression in string
```
Semua ekspresi dalam template string harus mengembalikan string. Gunakan `string()` untuk mengonversi jenis lain:`"replicas-${string(schema.spec.count)}"`.
**Referensi bidang** - Akses nilai spesifikasi contoh menggunakan`schema.spec`:
```
template:
metadata:
name: ${schema.spec.name}-deployment
namespace: ${schema.metadata.namespace} # Can also reference metadata
spec:
replicas: ${schema.spec.replicas}
```
**Akses bidang opsional** - Gunakan `?` untuk bidang yang mungkin tidak ada:
```
# For ConfigMaps or Secrets with unknown structure
value: ${configmap.data.?DATABASE_URL}
# For optional status fields
ready: ${deployment.status.?readyReplicas > 0}
```
Jika bidang tidak ada, ekspresi kembali `null` bukannya gagal.
**Sumber daya bersyarat** - Sertakan sumber daya hanya jika kondisi terpenuhi:
```
resources:
- id: ingress
includeWhen:
- ${schema.spec.enableIngress == true}
template:
# ... ingress configuration
```
`includeWhen`Bidang menerima daftar ekspresi boolean. Semua kondisi harus benar untuk sumber daya yang akan dibuat. Saat ini, hanya `includeWhen` dapat mereferensikan `schema.spec` bidang.
**Transformasi** - Mengubah nilai menggunakan operator dan fungsi ternary:
```
template:
spec:
resources:
requests:
memory: ${schema.spec.size == "small" ? "512Mi" : "2Gi"}
# String concatenation
image: ${schema.spec.registry + "/" + schema.spec.imageName}
# Type conversion
port: ${string(schema.spec.portNumber)}
```
**Referensi lintas sumber daya** - Nilai referensi dari sumber daya lain:
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: configmap
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
```
Saat Anda mereferensikan sumber daya lain dalam ekspresi CEL, itu secara otomatis membuat dependensi. kro memastikan sumber daya yang direferensikan dibuat terlebih dahulu.
Untuk informasi selengkapnya, lihat [Ekspresi CEL](https://kro.run/docs/concepts/rgd/cel-expressions/) dalam dokumentasi kro.
### Ketergantungan sumber daya
kro secara otomatis menyimpulkan dependensi dari ekspresi CEL—Anda tidak menentukan urutannya, Anda menjelaskan hubungan. Ketika satu sumber daya mereferensikan yang lain menggunakan ekspresi CEL, kro membuat dependensi dan menentukan urutan pembuatan yang benar.
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: notification
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: BucketNotification
spec:
bucket: ${bucket.spec.name} # Creates dependency: notification depends on bucket
```
Ekspresi `${bucket.spec.name}` menciptakan ketergantungan. kro membangun grafik asiklik terarah (DAG) dari semua sumber daya dan dependensinya, kemudian menghitung urutan topologi untuk pembuatan.
**Urutan pembuatan**: Sumber daya dibuat dalam urutan topologi (dependensi terlebih dahulu).
**Pembuatan paralel**: Sumber daya tanpa dependensi dibuat secara bersamaan.
**Urutan penghapusan: Sumber daya dihapus dalam urutan** topologi terbalik (tanggungan terlebih dahulu).
**Dependensi melingkar: Tidak diizinkan—kro menolak ResourceGraphDefinitions dengan dependensi** melingkar selama validasi.
Anda dapat melihat urutan pembuatan yang dihitung:
```
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
Untuk informasi selengkapnya, lihat [Inferensi grafik](https://kro.run/docs/concepts/rgd/dependencies-ordering/) dalam dokumentasi kro.
## Menulis dengan ACK
kro bekerja secara mulus dengan Kemampuan EKS untuk ACK untuk menyusun AWS sumber daya dengan sumber daya Kubernetes:
```
resources:
# Create {aws} S3 bucket with ACK
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-files
# Inject bucket details into Kubernetes ConfigMap
- id: config
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
# Use ConfigMap in application deployment
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app
envFrom:
- configMapRef:
name: ${config.metadata.name}
```
Pola ini memungkinkan Anda membuat AWS sumber daya, mengekstrak detailnya (ARNs, URLs, titik akhir), dan menyuntikkannya ke dalam konfigurasi aplikasi Anda—semuanya dikelola sebagai satu unit.
Untuk lebih banyak pola komposisi dan contoh lanjutan, lihat[pertimbangan kro untuk EKS](kro-considerations.md).
## Langkah selanjutnya
+ [pertimbangan kro untuk EKS](kro-considerations.md)- Pelajari tentang pola khusus EKS, RBAC, dan integrasi dengan ACK dan Argo CD
+ [Dokumentasi kro - Dokumentasi](https://kro.run/docs/overview) kro komprehensif termasuk ekspresi CEL tingkat lanjut, pola validasi, dan pemecahan masalah
# Konfigurasikan izin kro
Tidak seperti ACK dan Argo CD, kro tidak memerlukan izin IAM. kro beroperasi sepenuhnya di dalam klaster Kubernetes Anda dan tidak melakukan panggilan API. AWS Kontrol akses ke sumber daya kro menggunakan Kubernetes RBAC standar.
## Cara kerja izin dengan kro
kro menggunakan dua jenis sumber daya Kubernetes dengan cakupan yang berbeda:
**ResourceGraphDefinitions**: Sumber daya dengan cakupan cluster yang mendefinisikan kustom. APIs Biasanya dikelola oleh tim platform yang merancang dan memelihara standar organisasi.
**Instance: Sumber** daya kustom dengan cakupan nama dibuat dari. ResourceGraphDefinitions Dapat dibuat oleh tim aplikasi dengan izin RBAC yang sesuai.
Secara default, kemampuan kro memiliki izin untuk mengelola ResourceGraphDefinitions dan instansinya melalui kebijakan entri `AmazonEKSKROPolicy` akses. Namun, kro memerlukan izin tambahan untuk membuat dan mengelola sumber daya Kubernetes yang mendasari yang ditentukan dalam ResourceGraphDefinitions (seperti Deployment, Services, atau resource ACK). Anda harus memberikan izin ini melalui kebijakan entri akses atau Kubernetes RBAC. Untuk detail tentang pemberian izin ini, lihat izin sumber daya [arbitrer kro](capabilities-security.md#kro-resource-permissions).
## Izin tim platform
Tim platform memerlukan izin untuk membuat dan mengelola ResourceGraphDefinitions.
**Contoh ClusterRole untuk tim platform**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-platform-admin
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["*"]
```
**Mengikat anggota tim platform**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-team-kro-admin
subjects:
- kind: Group
name: platform-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-platform-admin
apiGroup: rbac.authorization.k8s.io
```
## Izin tim aplikasi
Tim aplikasi memerlukan izin untuk membuat instance sumber daya khusus di ruang nama mereka.
**Contoh Peran untuk tim aplikasi**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-app-developer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["create", "get", "list", "update", "delete", "patch"]
```
**Mengikat anggota tim aplikasi**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-kro-developer
namespace: my-app
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: kro-app-developer
apiGroup: rbac.authorization.k8s.io
```
**catatan**
Grup API dalam Peran (`kro.run`dalam contoh ini) harus cocok dengan yang `apiVersion` ditentukan dalam skema Anda ResourceGraphDefinition.
## Akses hanya-baca
Berikan akses hanya-baca ke tampilan ResourceGraphDefinitions dan instance tanpa izin modifikasi.
**Hanya baca ClusterRole**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-viewer
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["get", "list", "watch"]
```
**Peran hanya-baca untuk instance**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-instance-viewer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["get", "list", "watch"]
```
## Akses multi-namespace
Berikan tim aplikasi akses ke beberapa ruang nama menggunakan dengan ClusterRoles . RoleBindings
**ClusterRole untuk akses multi-namespace**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-multi-namespace-developer
rules:
- apiGroups: ["kro.run"]
resources: ["webapps"]
verbs: ["create", "get", "list", "update", "delete"]
```
**Mengikat ke ruang nama tertentu:**
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-dev-access
namespace: development
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-staging-access
namespace: staging
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
```
## Praktik terbaik
**Prinsip hak istimewa terkecil**: Berikan hanya izin minimum yang diperlukan untuk tanggung jawab masing-masing tim.
**Gunakan grup alih-alih pengguna individu**: Ikat peran ke grup daripada pengguna individu untuk pengelolaan yang lebih mudah.
**Masalah platform dan aplikasi terpisah**: Tim platform mengelola ResourceGraphDefinitions, tim aplikasi mengelola instance.
**Isolasi namespace**: Gunakan ruang nama untuk mengisolasi tim atau lingkungan yang berbeda, dengan RBAC mengontrol akses ke setiap namespace.
**Akses hanya-baca untuk audit: Menyediakan** akses hanya-baca ke tim keamanan dan kepatuhan untuk tujuan audit.
## Langkah selanjutnya
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan komposisi sumber daya
+ [konsep kro](kro-concepts.md)- Memahami SimpleSchema, ekspresi CEL, dan pola komposisi
+ [Pertimbangan keamanan untuk Kemampuan EKS](capabilities-security.md)- Tinjau praktik terbaik keamanan untuk kemampuan
# 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\$1cadangan\$1pemantauan)
+ 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](kro-permissions.md)
### 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\$1antrian SQS\$1konfigurasi notifikasi
+ **Tumpukan basis data**: contoh RDS\$1grup parameter\$1grup keamanan\$1Rahasia Secrets Manager
+ **Jaringan**: VPC\$1subnet\$1tabel rute\$1grup keamanan\$1gateway NAT
+ **Hitung dengan penyimpanan**: EC2 instance\$1volume EBS\$1profil 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, lihat[Konsep ACK](ack-concepts.md).
### 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, lihat[Bekerja dengan Argo CD](working-with-argocd.md).
## 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\$1 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:
+ [Memulai dengan kro - Creating](https://kro.run/docs/guides/getting-started) ResourceGraphDefinitions
+ [Ekspresi CEL](https://kro.run/docs/concepts/cel) - Menulis ekspresi CEL
+ [Panduan kro](https://kro.run/docs/guides/) - Pola komposisi lanjutan
+ [Pemecahan masalah - Pemecahan](https://kro.run/docs/troubleshooting) masalah dan debugging
## Langkah selanjutnya
+ [Konfigurasikan izin kro](kro-permissions.md)- Konfigurasikan RBAC untuk tim platform dan aplikasi
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan siklus hidup sumber daya
+ [Memecahkan masalah dengan kemampuan kro](kro-troubleshooting.md)- Memecahkan masalah kro
+ [Konsep ACK](ack-concepts.md)- Pelajari tentang sumber daya ACK untuk komposisi
+ [Bekerja dengan Argo CD](working-with-argocd.md)- Menyebarkan RGDs dan contoh dengan GitOps
# Memecahkan masalah dengan kemampuan kro
Topik ini memberikan panduan pemecahan masalah untuk Kemampuan EKS untuk kro, termasuk pemeriksaan kesehatan kemampuan, izin RBAC, kesalahan ekspresi CEL, dan masalah komposisi sumber daya.
**catatan**
Kemampuan EKS sepenuhnya dikelola dan dijalankan di luar cluster Anda. Anda tidak memiliki akses ke log pengontrol atau `kro-system` namespace. Pemecahan masalah berfokus pada kesehatan kemampuan, konfigurasi RBAC, dan status sumber daya.
## Kemampuan aktif tetapi ResourceGraphDefinitions tidak bekerja
Jika kemampuan kro Anda menunjukkan `ACTIVE` status tetapi ResourceGraphDefinitions tidak membuat sumber daya yang mendasarinya, periksa kesehatan kemampuan, izin RBAC, dan status sumber daya.
**Periksa kesehatan kemampuan**:
Anda dapat melihat masalah kesehatan dan status kemampuan di konsol EKS atau menggunakan AWS CLI.
**Konsol**:
1. Buka konsol Amazon EKS di https://console.aws.amazon.com/eks/ rumah\$1/cluster.
1. Pilih nama cluster Anda.
1. Pilih tab **Observability**.
1. Pilih **Monitor cluster**.
1. Pilih tab **Kemampuan** untuk melihat kesehatan dan status untuk semua kemampuan.
** AWS CLI**:
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
# Look for issues in the health section
```
**Penyebab umum**:
+ Izin **RBAC hilang: kro tidak memiliki izin** untuk membuat sumber daya Kubernetes yang mendasarinya
+ **Ekspresi CEL tidak valid: Kesalahan** sintaks di ResourceGraphDefinition
+ **Ketergantungan sumber daya**: Sumber daya dependen belum siap
+ **Validasi skema**: Instance tidak cocok dengan persyaratan skema RGD
**Verifikasi izin RBAC**:
```
# Check if capability has cluster admin policy
kubectl get accessentry -A | grep kro
```
Jika kemampuan tidak memiliki izin yang diperlukan, kaitkan `AmazonEKSClusterAdminPolicy` dengan entri akses kemampuan kro, atau buat kebijakan RBAC yang lebih ketat untuk penggunaan produksi. Lihat [Konfigurasikan izin kro](kro-permissions.md) untuk detail.
**Periksa ResourceGraphDefinition status**:
```
# List all RGDs
kubectl get resourcegraphdefinition
# Describe specific RGD
kubectl describe resourcegraphdefinition my-rgd
# Check for validation errors
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions}'
```
ResourceGraphDefinitions memiliki tiga kondisi status utama:
+ `ResourceGraphAccepted`- Apakah RGD lulus validasi (sintaks CEL, pemeriksaan tipe, keberadaan bidang)
+ `KindReady`- Apakah CRD untuk API kustom Anda dibuat dan terdaftar
+ `ControllerReady`- Apakah kro secara aktif menonton instance API kustom Anda
Jika `ResourceGraphAccepted` ya`False`, periksa pesan kondisi untuk kesalahan validasi seperti bidang yang tidak dikenal, ketidakcocokan tipe, atau dependensi melingkar.
## Instans dibuat tetapi sumber daya yang mendasarinya tidak muncul
Jika instance sumber daya kustom ada tetapi sumber daya Kubernetes yang mendasarinya (Deployment, Services, ConfigMaps) tidak dibuat, verifikasi kro memiliki izin dan periksa kesalahan komposisi.
**Periksa status instance**:
```
# Describe the instance (replace with your custom resource kind and name)
kubectl describe custom-kind
my-instance
# View instance events
kubectl get events --field-selector involvedObject.name=my-instance
# Check instance status conditions
kubectl get custom-kind
my-instance -o jsonpath='{.status.conditions}'
# Check instance state
kubectl get custom-kind
my-instance -o jsonpath='{.status.state}'
```
Instance memiliki `state` bidang yang menunjukkan status tingkat tinggi:
+ `ACTIVE`- Instance berhasil berjalan
+ `IN_PROGRESS`- Instance sedang diproses atau direkonsiliasi
+ `FAILED`- Instance gagal untuk mendamaikan
+ `DELETING`- Instance sedang dihapus
+ `ERROR`- Terjadi kesalahan selama pemrosesan
Instans juga memiliki empat kondisi status:
+ `InstanceManaged`- Finalizer dan label diatur dengan benar
+ `GraphResolved`- Grafik runtime dibuat dan sumber daya diselesaikan
+ `ResourcesReady`- Semua sumber daya dibuat dan siap
+ `Ready`- Kesehatan contoh keseluruhan (hanya menjadi `True` ketika semua sub-kondisi) `True`
Fokus pada `Ready` kondisi untuk menentukan kesehatan contoh. Jika `Ready` ya`False`, periksa sub-kondisi untuk mengidentifikasi fase mana yang gagal.
**Verifikasi izin RBAC**:
Kemampuan kro membutuhkan izin untuk membuat sumber daya Kubernetes yang mendasari yang ditentukan dalam Anda. ResourceGraphDefinitions
```
# Check if the capability has the AmazonEKSClusterAdminPolicy
kubectl get accessentry -A | grep kro
```
Jika izin tidak ada, kaitkan `AmazonEKSClusterAdminPolicy` dengan entri akses kemampuan kro, atau buat kebijakan RBAC yang lebih ketat untuk penggunaan produksi. Lihat [Konfigurasikan izin kro](kro-permissions.md) untuk detail.
## Kesalahan ekspresi CEL
Kesalahan ekspresi CEL ditangkap pada waktu ResourceGraphDefinition pembuatan, bukan saat instance dibuat. kro memvalidasi semua sintaks CEL, mengecek tipe ekspresi terhadap skema Kubernetes, dan memverifikasi keberadaan bidang saat Anda membuat RGD.
**Kesalahan validasi CEL umum**:
+ **Referensi bidang yang tidak ditentukan**: Mereferensikan bidang yang tidak ada dalam skema atau sumber daya
+ **Ketidakcocokan tipe**: Ekspresi mengembalikan tipe yang salah (misalnya, string di mana bilangan bulat diharapkan)
+ **Sintaks tidak valid**: Tanda kurung, tanda kutip, atau operator tidak ada dalam ekspresi CEL
+ **Jenis sumber daya tidak dikenal**: Merujuk CRD yang tidak ada di cluster
**Periksa status validasi RGD**:
```
# Check if RGD was accepted
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions[?(@.type=="ResourceGraphAccepted")]}'
# View detailed validation errors
kubectl describe resourcegraphdefinition my-rgd
```
Jika `ResourceGraphAccepted` ya`False`, pesan kondisi berisi kesalahan validasi.
**Contoh ekspresi CEL yang valid**:
```
# Reference schema field
${schema.spec.appName}
# Conditional expression
${schema.spec.replicas > 1}
# String template (expressions must return strings)
name: "${schema.spec.appName}-service"
# Standalone expression (can be any type)
replicas: ${schema.spec.replicaCount}
# Resource reference
${deployment.status.availableReplicas}
# Optional field access (returns null if field doesn't exist)
${configmap.data.?DATABASE_URL}
```
## Dependensi sumber daya tidak terselesaikan
kro secara otomatis menyimpulkan dependensi dari ekspresi CEL dan membuat sumber daya dalam urutan yang benar. Jika sumber daya tidak dibuat seperti yang diharapkan, periksa urutan ketergantungan dan kesiapan sumber daya.
**Lihat urutan pembuatan yang dihitung**:
```
# See the order kro will create resources
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
Ini menunjukkan urutan yang dihitung berdasarkan referensi ekspresi CEL antar sumber daya.
**Periksa kesiapan sumber daya**:
```
# View instance status to see which resources are ready
kubectl get custom-kind
my-instance -o jsonpath='{.status}'
# Check specific resource status
kubectl get deployment my-deployment -o jsonpath='{.status.conditions}'
```
**Verifikasi kondisi ReadyWhen (jika digunakan**):
`readyWhen`Bidang ini opsional. Jika tidak ditentukan, sumber daya dianggap siap segera setelah pembuatan. Jika Anda telah menentukan `readyWhen` kondisi, verifikasi bahwa kondisi tersebut memeriksa kesiapan sumber daya dengan benar:
```
resources:
- id: deployment
readyWhen:
- ${deployment.status.availableReplicas == deployment.spec.replicas}
```
**Periksa acara sumber daya**:
```
# View events for the underlying resources
kubectl get events -n namespace --sort-by='.lastTimestamp'
```
## Kegagalan validasi skema
Jika instance gagal dibuat karena kesalahan validasi skema, verifikasi instance cocok dengan persyaratan skema RGD.
**Periksa kesalahan validasi**:
```
# Attempt to create instance and view error
kubectl apply -f instance.yaml
# View existing instance validation status
kubectl describe custom-kind
my-instance | grep -A 5 "Validation"
```
**Masalah validasi** umum:
+ **Bidang wajib hilang**: Instance tidak menyediakan semua bidang skema yang diperlukan
+ **Ketidakcocokan tipe**: Menyediakan string di mana bilangan bulat diharapkan
+ Nilai **enum tidak valid: Menggunakan nilai** yang tidak ada dalam daftar yang diizinkan
+ **Ketidakcocokan pola**: String tidak cocok dengan pola regex
**Tinjau skema RGD**:
```
# View the schema definition
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.spec.schema}'
```
Pastikan instans Anda menyediakan semua bidang wajib dengan tipe yang benar.
## Langkah selanjutnya
+ [pertimbangan kro untuk EKS](kro-considerations.md)- pertimbangan kro dan praktik terbaik
+ [Konfigurasikan izin kro](kro-permissions.md)- Konfigurasikan RBAC untuk tim platform dan aplikasi
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan siklus hidup sumber daya
+ [Memecahkan Masalah Kemampuan EKS](capabilities-troubleshooting.md)- Panduan pemecahan masalah kemampuan umum
# Membandingkan Kemampuan EKS untuk kro dengan kro yang dikelola sendiri
Kemampuan EKS untuk kro menyediakan fungsionalitas yang sama dengan kro yang dikelola sendiri, tetapi dengan keunggulan operasional yang signifikan. Untuk perbandingan umum Kemampuan EKS vs solusi yang dikelola sendiri, lihat[Pertimbangan Kemampuan EKS](capabilities-considerations.md).
Kemampuan EKS untuk kro menggunakan pengontrol kro hulu yang sama dan sepenuhnya kompatibel dengan kro hulu. ResourceGraphDefinitions, ekspresi CEL, dan komposisi sumber daya bekerja secara identik. Untuk dokumentasi dan contoh kro lengkap, lihat dokumentasi [kro](https://kro.run/docs/overview).
## Jalur migrasi
Anda dapat bermigrasi dari kro yang dikelola sendiri ke kemampuan terkelola tanpa downtime.
**penting**
Sebelum bermigrasi, pastikan pengontrol kro yang dikelola sendiri menjalankan versi yang sama dengan Kemampuan EKS untuk kro. Periksa versi kemampuan di konsol EKS atau gunakan`aws eks describe-capability`, lalu tingkatkan instalasi yang dikelola sendiri agar sesuai. Ini mencegah masalah kompatibilitas selama migrasi.
1. Perbarui pengontrol kro yang dikelola sendiri untuk digunakan `kube-system` untuk sewa pemilihan pemimpin:
```
helm upgrade --install kro \
oci://ghcr.io/awslabs/kro/kro-chart \
--namespace kro \
--set leaderElection.namespace=kube-system
```
Ini memindahkan sewa pengontrol`kube-system`, memungkinkan kemampuan terkelola untuk berkoordinasi dengannya.
1. Buat kemampuan kro di cluster Anda (lihat[Buat kemampuan kro](create-kro-capability.md))
1. Kemampuan terkelola mengenali yang ada ResourceGraphDefinitions dan contoh, mengambil alih rekonsiliasi
1. Secara bertahap turunkan atau hapus penerapan kro yang dikelola sendiri:
```
helm uninstall kro --namespace kro
```
Pendekatan ini memungkinkan kedua pengendali untuk hidup berdampingan dengan aman selama migrasi. Kemampuan yang dikelola secara otomatis mengadopsi ResourceGraphDefinitions dan contoh yang sebelumnya dikelola oleh kro yang dikelola sendiri, memastikan rekonsiliasi berkelanjutan tanpa konflik.
## Langkah selanjutnya
+ [Buat kemampuan kro](create-kro-capability.md)- Buat sumber daya kemampuan kro
+ [konsep kro](kro-concepts.md)- Memahami konsep kro dan komposisi sumber daya