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 (lihatBuat kemampuan kro), 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 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 mendukungstring,integer,boolean,, dan number tipe dengan kendala sepertirequired,,minimum/maximum,default, dan. enum pattern

Untuk informasi lebih lanjut, lihat SimpleSchemadi 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 menggunakanschema.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

includeWhenBidang 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 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 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, lihatpertimbangan kro untuk EKS.

Langkah selanjutnya

• pertimbangan kro untuk EKS- Pelajari tentang pola khusus EKS, RBAC, dan integrasi dengan ACK dan Argo CD

• Dokumentasi kro - Dokumentasi kro komprehensif termasuk ekspresi CEL tingkat lanjut, pola validasi, dan pemecahan masalah