Menggunakan ClusterResourcePlacement untuk menyebarkan sumber daya yang tercakup dalam kluster

Artikel ini menjelaskan CLUSTERResourcePlacement API, yang memungkinkan penempatan sumber daya dari kluster hub ke kluster anggota menggunakan Azure Kubernetes Fleet Manager.

Admin platform sering kali perlu menyebarkan sumber daya Kubernetes ke beberapa kluster karena berbagai alasan, misalnya:

• Mengelola kontrol akses menggunakan peran dan pengikatan peran di beberapa kluster.
• Menjalankan aplikasi infrastruktur, seperti Prometheus atau Flux, yang perlu ada di semua kluster.

Pengembang aplikasi sering kali perlu menyebarkan sumber daya Kubernetes ke beberapa kluster karena berbagai alasan, misalnya:

• Menyebarkan aplikasi penyajian video ke dalam beberapa kluster di berbagai wilayah untuk pengalaman menonton latensi rendah.
• Menyebarkan aplikasi kelir belanja ke dua wilayah berpasangan bagi pelanggan untuk terus berbelanja selama pemadaman satu wilayah.
• Menyebarkan aplikasi komputasi batch ke dalam kluster dengan kumpulan simpul spot murah yang tersedia.

Sangat melelahkan untuk membuat, memperbarui, dan melacak sumber daya Kubernetes ini di beberapa kluster secara manual. Fleet Manager menyediakan penyebaran sumber daya Kubernetes untuk mengaktifkan manajemen sumber daya Kubernetes dalam skala besar. Dengan Fleet Manager, Anda dapat membuat sumber daya Kubernetes pada kluster hub yang dikelola Armada dan menyebarkannya ke kluster anggota yang dipilih melalui Sumber Daya Kustom Kubernetes: MemberCluster dan ClusterResourcePlacement.

Dukungan Manajer Armada untuk sumber daya kustom didasarkan pada proyek KubeFleet CNCF.

Gambaran umum CLUSTERResourcePlacement API

Objek ClusterResourcePlacement digunakan untuk memberi tahu penjadwal armada cara menempatkan sekumpulan objek cakupan kluster tertentu dari kluster hub armada ke kluster anggota. Saat memilih namespace, semua objek dengan cakupan namespace di dalamnya—seperti Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets, dan PersistentVolumeClaims—disertakan dan disebarkan bersama-sama.

Untuk skenario yang memerlukan kontrol mendetail atas sumber daya ruang lingkup namespace individu dalam namespace, lihat ResourcePlacement, yang memungkinkan penyebarluasan selektif sumber daya tertentu daripada seluruh namespace.

Dengan ClusterResourcePlacement, Anda dapat:

• Pilih sumber daya mana yang akan disebarluaskan. Ini dapat berupa sumber daya Kubernetes cakupan kluster yang ditentukan menggunakan referensi Kubernetes Group Version Kind (GVK), atau namespace, yang menyebarluaskan namespace layanan dan semua sumber dayanya.
• Tentukan kebijakan penempatan untuk memilih kluster anggota. Kebijakan ini dapat secara eksplisit memilih kluster berdasarkan nama, atau secara dinamis memilih kluster berdasarkan label dan properti kluster.
• Tentukan strategi peluncuran untuk meluncurkan pembaruan sumber daya Kubernetes yang dipilih dengan aman ke beberapa kluster target.
• Lihat kemajuan propagasi untuk setiap kluster target.

Pemilihan sumber daya

ClusterResourcePlacement mendukung pemilihan sumber daya dalam cakupan kluster dan namespace menggunakan pemilih sumber daya. Setiap pemilih sumber daya dapat menentukan:

• Grup, Versi, Jenis (GVK): Jenis sumber daya Kubernetes yang akan dipilih.
• Nama: Nama sumber daya tertentu.
• Selektor label: Label untuk mencocokkan beberapa sumber daya.

Cakupan pemilihan namespace (pratinjau)

Penting

Bidang selectionScope ini tersedia dalam placement.kubernetes-fleet.io/v1beta1 versi API sebagai fitur pratinjau. Ini tidak tersedia di placement.kubernetes-fleet.io/v1 API.

Saat memilih namespace, Anda dapat menggunakan selectionScope untuk mengontrol apakah hanya menyebarkan namespace itu sendiri atau namespace beserta semua isinya.

• Perilaku default (ketika selectionScope tidak ditentukan): Menyebarkan namespace dan semua sumber daya di dalamnya.
• NamespaceOnly: Hanya menyebarkan objek namespace itu sendiri, tanpa sumber daya apa pun dalam namespace. Ini berguna ketika Anda ingin membuat namespace di seluruh kluster sambil mengelola sumber daya individual secara terpisah menggunakan ResourcePlacement.

Contoh berikut menunjukkan cara menyebarluaskan hanya namespace tanpa kontennya menggunakan API v1beta1:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Pendekatan ini memungkinkan alur kerja di mana administrator platform menggunakan ClusterResourcePlacement untuk membuat namespace layanan, sementara tim aplikasi menggunakan ResourcePlacement untuk kontrol terperindas atas sumber daya tertentu dalam namespace tersebut.

Jenis penempatan

Jenis penempatan berikut tersedia untuk mengontrol jumlah kluster tempat sumber daya Kubernetes tertentu perlu disebarluaskan:

• PickFixed menempatkan sumber daya ke daftar kluster anggota tertentu berdasarkan nama.
• PickAll menempatkan sumber daya ke semua kluster anggota, atau semua kluster anggota yang memenuhi kriteria. Kebijakan ini berguna untuk menempatkan beban kerja infrastruktur, seperti aplikasi pemantauan atau pelaporan kluster.
• PickN adalah opsi penempatan yang paling fleksibel dan memungkinkan pemilihan kluster berdasarkan batasan penyebaran afinitas atau topologi dan berguna saat menyebarkan beban kerja di beberapa kluster yang sesuai untuk memastikan ketersediaan diinginkan.

Jenis penempatan PickFixed

Jika Anda ingin menyebarkan beban kerja ke sekumpulan kluster anggota yang PickFixed diketahui, Anda dapat menggunakan kebijakan penempatan untuk memilih kluster berdasarkan nama.

clusterNames adalah satu-satunya opsi kebijakan yang valid untuk jenis penempatan ini.

Contoh berikut menunjukkan cara menyebarkan test-deployment namespace layanan ke kluster cluster1 anggota dan cluster2.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-fixed
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

Jenis penempatan PickAll

Anda dapat menggunakan PickAll jenis penempatan untuk menyebarkan beban kerja di semua kluster anggota dalam armada atau ke subset kluster yang cocok dengan kriteria yang Anda tetapkan.

Saat membuat jenis penempatan ini, jenis afinitas kluster berikut dapat ditentukan:

• requiredDuringSchedulingIgnoredDuringExecution: karena kebijakan ini diperlukan selama penjadwalan, kebijakan ini memfilter kluster berdasarkan kriteria yang ditentukan.

Contoh berikut menunjukkan cara menyebarkan prod-deployment namespace layanan dan semua objeknya di semua kluster berlabel :environment: production

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickall
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

Jenis penempatan PickN

Jenis PickN penempatan adalah opsi yang paling fleksibel dan memungkinkan penempatan sumber daya ke dalam jumlah kluster yang dapat dikonfigurasi berdasarkan batasan penyebaran afinitas dan topologi.

Saat membuat jenis penempatan ini, jenis afinitas kluster berikut dapat ditentukan:

• requiredDuringSchedulingIgnoredDuringExecution: karena kebijakan ini diperlukan selama penjadwalan, kebijakan ini memfilter kluster berdasarkan kriteria yang ditentukan.
• preferredDuringSchedulingIgnoredDuringExecution: karena kebijakan ini lebih disukai, tetapi tidak diperlukan selama penjadwalan, kebijakan ini memberi peringkat kluster berdasarkan kriteria yang ditentukan.

Anda dapat mengatur afinitas yang diperlukan dan lebih disukai. Afinitas yang diperlukan mencegah penempatan ke kluster yang tidak cocok, dan afinitas pilihan menyediakan pengurutan kluster yang valid.

PickN dengan afinitas

Menggunakan afinitas dengan PickN fungsi kebijakan penempatan yang mirip dengan menggunakan afinitas dengan penjadwalan pod.

Contoh berikut menunjukkan cara menyebarkan beban kerja ke tiga kluster. Hanya kluster dengan critical-allowed: "true" label yang merupakan target penempatan yang valid, dan preferensi diberikan kepada kluster dengan label critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-01
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN dengan batasan penyebaran topologi

Anda dapat menggunakan batasan penyebaran topologi untuk memaksa pembagian penempatan kluster di seluruh batas topologi untuk memenuhi persyaratan ketersediaan. Misalnya, gunakan batasan ini untuk membagi penempatan di seluruh wilayah atau memperbarui cincin. Anda juga dapat mengonfigurasi batasan penyebaran topologi untuk mencegah penjadwalan jika batasan tidak dapat dipenuhi (whenUnsatisfiable: DoNotSchedule) atau menjadwalkan sebaik mungkin (whenUnsatisfiable: ScheduleAnyway).

Contoh berikut menunjukkan cara menyebarkan sekumpulan sumber daya tertentu di beberapa wilayah dan mencoba menjadwalkan di seluruh kluster anggota dengan hari pembaruan yang berbeda.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-02
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Untuk informasi selengkapnya, lihat dokumentasi KubeFleet tentang batasan penyebaran topologi.

Opsi kebijakan penempatan

Tabel ini meringkas bidang kebijakan penjadwalan yang tersedia untuk setiap jenis penempatan.

Bidang Kebijakan	PickFixed	PilihSemua	PickN
placementType	✅	✅	✅
affinity	❌	✅	✅
clusterNames	✅	❌	❌
numberOfClusters	❌	❌	✅
topologySpreadConstraints	❌	❌	✅

Memilih kluster berdasarkan label dan properti

Label dan properti yang tersedia untuk memilih kluster

Saat menggunakan PickN jenis penempatan dan PickAll , Anda dapat menggunakan label dan properti berikut sebagai bagian dari kebijakan Anda.

Label

Label berikut secara otomatis ditambahkan ke semua kluster anggota dan dapat digunakan untuk pemilihan kluster target dalam kebijakan penempatan sumber daya.

Etiket	Deskripsi
fleet.azure.com/location	Wilayah Azure kluster (westus)
fleet.azure.com/resource-group	Grup Sumber Daya Azure dari kluster (rg_prodapps_01)
fleet.azure.com/subscription-id	Pengidentifikasi Langganan Azure tempat kluster berada. Diformat sebagai UUID/GUID.
fleet.azure.com/cluster-name	Nama kluster
fleet.azure.com/member-name	Nama anggota Armada yang sesuai dengan kluster

Anda juga dapat menggunakan label kustom apa pun yang Anda terapkan ke kluster Anda.

Properti

Properti berikut ini tersedia untuk digunakan sebagai bagian dari kebijakan penempatan.

Properti CPU dan memori direpresentasikan sebagai unit sumber daya Kubernetes.

Properti biaya adalah desimal, yang mewakili biaya per jam dalam Dolar AS untuk komputasi Azure yang digunakan untuk simpul dalam kluster. Biaya didasarkan pada harga publik Azure.

Nama Properti	Deskripsi
kubernetes-fleet.io/node-count	Simpul yang tersedia pada kluster anggota.
resources.kubernetes-fleet.io/total-cpu	Total unit sumber daya CPU kluster.
resources.kubernetes-fleet.io/allocatable-cpu	Unit sumber daya CPU kluster yang dapat dialokasi.
resources.kubernetes-fleet.io/available-cpu	Unit sumber daya CPU kluster yang tersedia.
resources.kubernetes-fleet.io/total-memory	Total unit sumber daya memori kluster.
resources.kubernetes-fleet.io/memori-yang-dapat-dialokasikan	Unit sumber daya memori kluster yang dapat dialokasi.
resources.kubernetes-fleet.io/available-memory	Unit sumber daya memori kluster yang tersedia.
kubernetes.azure.com/biaya-per-inti-cpu	Biaya inti per CPU kluster.
kubernetes.azure.com/per-gb-memory-cost	Biaya memori per GiB kluster.
kubernetes.azure.com/vm-sizes/{vm-sku-name}/capacity	Jumlah simpul jenis vm-sku-name yang tersedia di kluster*. Contoh nama SKU VM: NV16as_v4. * Pratinjau melalui API v1beta1.

Menentukan kriteria pencocokan pilihan

Saat menggunakan properti kluster dalam kriteria kebijakan, Anda menentukan:

• Nama: Nama properti, yang merupakan salah satu properti yang tercantum dalam properti dalam artikel ini.

• Operator: Operator yang digunakan untuk mengekspresikan kondisi antara nilai batasan/yang diinginkan dan nilai yang diamati pada kluster. Operator berikut saat ini didukung:

  • Gt (Lebih besar dari): nilai kluster yang diamati dari properti yang diberikan harus lebih besar dari nilai dalam kondisi sebelum dapat dipilih untuk penempatan sumber daya.
  • Ge (Lebih besar dari atau sama dengan): nilai kluster yang diamati dari properti yang diberikan harus lebih besar dari atau sama dengan nilai dalam kondisi sebelum dapat dipilih untuk penempatan sumber daya.
  • Lt (Kurang dari): nilai kluster yang diamati dari properti yang diberikan harus kurang dari nilai dalam kondisi sebelum dapat dipilih untuk penempatan sumber daya.
  • Le (Kurang dari atau sama dengan): nilai kluster yang diamati dari properti yang diberikan harus kurang dari atau sama dengan nilai dalam kondisi sebelum dapat dipilih untuk penempatan sumber daya.
  • Eq (Sama dengan): nilai kluster yang diamati dari properti yang diberikan harus sama dengan nilai dalam kondisi sebelum dapat dipilih untuk penempatan sumber daya.
  • Ne (Tidak sama dengan): nilai kluster yang diamati dari properti yang diberikan harus tidak sama dengan nilai dalam kondisi sebelum dapat dipilih untuk penempatan sumber daya.

  Jika Anda menggunakan operator Gt, , Ge, LtLe, Eq, atau Ne, daftar nilai dalam kondisi harus memiliki satu nilai.

• Nilai: Daftar nilai, yang merupakan nilai properti yang mungkin.

Armada mengevaluasi setiap kluster berdasarkan properti yang ditentukan dalam kondisi. Kegagalan untuk memenuhi kondisi yang tercantum di bawah requiredDuringSchedulingIgnoredDuringExecution mengecualikan kluster anggota ini dari penempatan sumber daya.

Catatan

Jika kluster anggota tidak memiliki properti yang dinyatakan dalam kondisi tersebut, kluster tersebut akan secara otomatis gagal dalam kondisi tersebut.

Berikut adalah contoh kebijakan penempatan untuk memilih hanya kluster dengan lima node atau lebih.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Cara kerja peringkat properti

Saat preferredDuringSchedulingIgnoredDuringExecution digunakan, pengurut properti memberi peringkat semua kluster dalam armada berdasarkan nilainya dalam urutan naik atau turun. Bobot yang digunakan untuk pemesanan dihitung berdasarkan nilai yang ditentukan.

Pengurut properti terdiri dari:

• Nama: Nama properti kluster.
• Urutan pengurutan: Urutan pengurutan bisa berupa Ascending atau Descending. Ketika Ascending urutan digunakan, kluster anggota dengan nilai yang diamati lebih rendah lebih disukai. Ketika Descending pesanan digunakan, kluster anggota dengan nilai yang diamati lebih tinggi lebih disukai.

Urutan turun

Untuk urutan pengurutan Menurun, bobot proporsional dihitung menggunakan rumus:

((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight

Misalnya, Anda ingin memberi peringkat kluster berdasarkan properti kapasitas CPU yang tersedia dalam urutan turun dan Anda memiliki armada tiga kluster dengan CPU yang tersedia berikut:

Kluster	Kapasitas CPU yang tersedia
cluster-a	100
cluster-b	20
cluster-c	10

Dalam hal ini, pengurut menghitung bobot berikut:

Kluster	Kapasitas CPU yang tersedia	Penghitungan	Beban
cluster-a	100	(100 - 10) / (100 - 10)	100%
cluster-b	20	(20 - 10) / (100 - 10)	11.11%
cluster-c	10	(10 - 10) / (100 - 10)	0%

Urutan naik

Untuk urutan pengurutan Naik, bobot proporsional dihitung menggunakan rumus:

(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight

Misalnya, Anda ingin memberi peringkat kluster berdasarkan biaya per CPU-core mereka dalam urutan naik dan Bahwa Anda memiliki armada tiga kluster dengan biaya inti CPU berikut:

Kluster	Biaya inti per CPU
cluster-a	1
cluster-b	0,2
cluster-c	0.1

Dalam hal ini, pengurut menghitung bobot berikut:

Kluster	Biaya inti per CPU	Penghitungan	Beban
cluster-a	1	1 - ((1 - 0.1) / (1 - 0.1))	0%
cluster-b	0,2	1 - ((0.2 - 0.1) / (1 - 0.1))	88,89%
cluster-c	0.1	1 - (0.1 - 0.1) / (1 - 0.1)	100%

Rekam jepret sumber daya

Manajer Armada menyimpan riwayat 10 kebijakan penjadwalan penempatan yang terakhir digunakan, bersama dengan versi sumber daya yang telah dipilih penempatan.

Rekam jepret ini dapat digunakan dengan strategi peluncuran bertahap untuk mengontrol versi yang disebarkan.

Untuk informasi selengkapnya, lihat dokumentasi tentang rekam jepret.

Merangkum sumber daya menggunakan objek amplop

Saat menyebarkan sumber daya ke kluster anggota setelah model hub dan spoke, penting untuk dipahami bahwa kluster hub itu sendiri juga merupakan kluster Kubernetes. Sumber daya apa pun yang ingin Anda sebarkan pertama kali akan diterapkan langsung ke kluster hub, yang dapat menyebabkan beberapa potensi efek samping:

1. Efek Samping yang Tidak Diinginkan: Sumber daya seperti ValidatingWebhookConfigurations, MutatingWebhookConfigurations, atau Admission Controller akan menjadi aktif pada kluster hub, berpotensi mencegat dan memengaruhi operasi kluster hub.

2. Risiko Keamanan: Sumber daya RBAC (Peran, ClusterRoles, RoleBindings, ClusterRoleBindings) yang ditujukan untuk kluster anggota dapat memberikan izin yang tidak diinginkan pada kluster hub.

3. Batasan Sumber Daya: ResourceQuotas, FlowSchema, atau LimitRanges yang ditentukan untuk kluster anggota akan berlaku pada kluster hub. Meskipun efek samping tersebut umumnya tidak membahayakan, mungkin ada kasus di mana Anda ingin menghindari batasan ini pada kluster hub.

Untuk menghindari efek samping yang tidak perlu tersebut, manajer armada Azure Kubernetes menyediakan sumber daya kustom untuk membungkus objek untuk menyelesaikan masalah ini. Objek amplop itu sendiri diterapkan ke hub, tetapi sumber daya yang dikandungnya hanya diekstrak dan diterapkan ketika mereka mencapai kluster anggota. Dengan cara ini, seseorang dapat menentukan sumber daya yang harus disebarkan tanpa benar-benar menyebarkan kontennya pada kluster hub. Untuk informasi selengkapnya, lihat dokumentasi tentang objek amplop.

Menggunakan Tolerations

ClusterResourcePlacement objek mendukung spesifikasi toleransi, yang berlaku untuk ClusterResourcePlacement objek. Setiap objek toleransi terdiri dari bidang berikut:

• key: Kunci toleransi.
• value: Nilai toleransi.
• effect: Efek toleransi, seperti NoSchedule.
• operator: Operator toleransi, seperti Exists atau Equal.

Setiap toleransi digunakan untuk mentolerir satu atau beberapa taint tertentu yang diterapkan pada ClusterResourcePlacement. Setelah semua taint pada ditoleransi MemberCluster , penjadwal kemudian dapat menyebarkan sumber daya ke kluster. Anda tidak dapat memperbarui atau menghapus toleransi dari ClusterResourcePlacement objek setelah dibuat.

Untuk informasi selengkapnya, lihat dokumentasi tentang toleransi.

Mengonfigurasi strategi peluncuran

Armada menggunakan strategi pembaruan bergulir untuk mengontrol bagaimana pembaruan diluncurkan di seluruh kluster.

Dalam contoh berikut, penjadwal armada meluncurkan pembaruan untuk setiap kluster secara berurutan, menunggu setidaknya unavailablePeriodSeconds di antara kluster. Status peluncuran dianggap berhasil jika semua sumber daya diterapkan dengan benar ke kluster. Pemeriksaan status peluncuran tidak berkade ke sumber daya anak, jadi misalnya, tidak mengonfirmasi bahwa pod yang dibuat oleh penyebaran menjadi siap.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Untuk informasi selengkapnya, lihat dokumentasi tentang strategi peluncuran.

Menentukan status penempatan

Penjadwal Armada memperbarui detail dan status pada keputusan penempatan ke ClusterResourcePlacement objek. Output mencakup informasi berikut:

• Kondisi yang saat ini berlaku untuk penempatan, yang mencakup apakah penempatan berhasil diselesaikan.
• Bagian status penempatan untuk setiap kluster anggota, yang menunjukkan status penyebaran ke kluster tersebut.

Contoh berikut menunjukkan ClusterResourcePlacement bahwa menyebarkan test namespace layanan dan test-1 ConfigMap ke dalam dua kluster anggota menggunakan PickN. Penempatan berhasil diselesaikan dan sumber daya ditempatkan ke aks-member-1 dalam kluster dan aks-member-2 .

Anda dapat melihat informasi ini menggunakan kubectl describe crp <name> perintah .

kubectl describe crp crp-1

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

Untuk informasi selengkapnya, lihat dokumentasi tentang cara memahami hasil penempatan.

Pemicu perubahan penempatan

Penjadwal Armada memprioritaskan stabilitas penempatan beban kerja yang ada. Prioritas ini dapat membatasi jumlah perubahan yang menyebabkan beban kerja dihapus dan dijadwalkan ulang. Skenario berikut dapat memicu perubahan penempatan:

• Perubahan kebijakan penempatan dalam ClusterResourcePlacement objek dapat memicu penghapusan dan penjadwalan ulang beban kerja.
  • Operasi peluasan skala (meningkat numberOfClusters tanpa perubahan lain) menempatkan beban kerja hanya pada kluster baru dan tidak memengaruhi penempatan yang ada.
• Perubahan kluster, termasuk:
  • Kluster baru yang memenuhi syarat dapat memicu penempatan jika kluster baru memenuhi kebijakan penempatan, misalnya, PickAll kebijakan.
  • Kluster dengan penempatan dihapus dari armada. Tergantung pada kebijakan, penjadwal mencoba menempatkan semua beban kerja yang terpengaruh pada kluster yang tersisa tanpa memengaruhi penempatan yang ada.

Perubahan khusus sumber daya (memperbarui sumber daya atau memperbarui ResourceSelector di ClusterResourcePlacement objek) diluncurkan secara bertahap di penempatan yang ada tetapi tidak memicu penjadwalan ulang beban kerja.

Langkah berikutnya

• Gunakan penempatan sumber daya kluster untuk menyebarkan beban kerja di beberapa kluster.
• Menggunakan ResourcePlacement untuk menyebarkan sumber daya dengan cakupan namespace.
• Penempatan sumber daya Kubernetes lintas kluster cerdas berdasarkan properti kluster anggota.
• Mengontrol pengusiran dan gangguan untuk penempatan sumber daya kluster.
• Menentukan strategi peluncuran untuk penempatan sumber daya kluster.
• FAQ penempatan sumber daya kluster.