Share via

Penyebaran sumber daya Kubernetes dari kluster hub ke kluster anggota (Pratinjau)

  • Artikel

Artikel ini menjelaskan konsep penyebaran sumber daya Kubernetes dari kluster hub ke kluster anggota menggunakan Azure Kubernetes Fleet Manager (Armada).

Admin platform sering kali perlu menyebarkan sumber daya Kubernetes ke dalam 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 dalam 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. Armada menyediakan penyebaran sumber daya Kubernetes untuk mengaktifkan manajemen sumber daya Kubernetes dalam skala besar. Dengan Fleet, Anda dapat membuat sumber daya Kubernetes di kluster hub dan menyebarkannya ke kluster anggota yang dipilih melalui Kubernetes Custom Resources: MemberCluster dan ClusterResourcePlacement. Armada mendukung sumber daya kustom ini berdasarkan solusi multi-kluster cloud-native sumber terbuka. Untuk informasi selengkapnya, lihat dokumentasi Armada hulu.

Penting

Fitur pratinjau Azure Kubernetes Fleet Manager tersedia berdasarkan layanan mandiri. Pratinjau disediakan "apa adanya" dan "sebagaimana tersedia," dan mereka dikecualikan dari perjanjian tingkat layanan dan garansi terbatas. Pratinjau Azure Kubernetes Fleet Manager sebagian dicakup oleh dukungan pelanggan berdasarkan upaya terbaik. Dengan demikian, fitur-fitur ini tidak dimaksudkan untuk penggunaan produksi.

Alur kerja penyebaran sumber daya

Diagram yang menunjukkan bagaimana sumber daya Kubernetes disebarluaskan ke kluster anggota.

Apa itu MemberCluster?

Setelah kluster bergabung dengan armada, sumber daya kustom yang sesuai MemberCluster dibuat pada kluster hub. Anda dapat menggunakan sumber daya kustom ini untuk memilih kluster target dalam penyebaran sumber daya.

Label berikut dapat digunakan untuk pemilihan kluster target dalam penyebaran sumber daya dan secara otomatis ditambahkan ke semua kluster anggota:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Untuk informasi selengkapnya, lihat referensi API MemberCluster.

Apa itu ClusterResourcePlacement?

Objek ClusterResourcePlacement digunakan untuk memberi tahu penjadwal Armada cara menempatkan sekumpulan objek cakupan kluster tertentu dari kluster hub ke dalam kluster anggota. Objek yang dicakup namespace seperti Deployments, StatefulSets, DaemonSets, Config Peta, Secrets, dan PersistentVolumeClaims disertakan saat namespace yang berisi dipilih.

Dengan ClusterResourcePlacement, Anda dapat:

  • Pilih sumber daya Kubernetes dengan cakupan kluster mana yang akan disebarluaskan ke kluster anggota.
  • Tentukan kebijakan penempatan untuk memilih subset atau semua kluster anggota secara manual atau otomatis sebagai kluster target.
  • Tentukan strategi peluncuran untuk meluncurkan pembaruan sumber daya Kubernetes yang dipilih dengan aman ke beberapa kluster target.
  • Lihat kemajuan propagasi terhadap setiap kluster target.

Objek ClusterResourcePlacement mendukung penggunaan ConfigMap untuk mengapit objek untuk membantu menyebar ke kluster anggota tanpa efek samping yang tidak diinginkan. Metode pemilihan meliputi:

  • Grup, versi, dan jenis: Pilih dan tempatkan semua sumber daya dari jenis yang diberikan.
  • Grup, versi, jenis, dan nama: Pilih dan tempatkan satu sumber daya tertentu dari jenis tertentu.
  • Grup, versi, jenis, dan label: Pilih dan tempatkan semua sumber daya dari jenis tertentu yang cocok dengan label yang disediakan.

Untuk informasi selengkapnya, lihat ClusterResourcePlacement referensi API.

Saat membuat ClusterResourcePlacement, jenis afinitas berikut dapat ditentukan:

  • requiredDuringSchedulingIgnoredDuringExecution: Karena afinitas ini adalah jenis yang diperlukan selama penjadwalan, ini memfilter kluster berdasarkan propertinya.
  • preferredDuringSchedulingIgnoredDuringExecution: Karena afinitas ini hanya dari jenis pilihan, tetapi tidak diperlukan selama penjadwalan, ini memberikan peringkat preferensial ke kluster berdasarkan properti yang ditentukan oleh Anda seperti ketersediaan biaya atau sumber daya.

Beberapa jenis penempatan tersedia untuk mengontrol jumlah kluster tempat sumber daya Kubernetes perlu disebarluaskan:

  • PickAll menempatkan sumber daya ke semua kluster anggota yang tersedia. Kebijakan ini berguna untuk menempatkan beban kerja infrastruktur, seperti aplikasi pemantauan atau pelaporan kluster.
  • PickFixed menempatkan sumber daya ke dalam daftar kluster anggota tertentu berdasarkan nama.
  • 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.

PickAll kebijakan penempatan

Anda dapat menggunakan PickAll kebijakan penempatan untuk menyebarkan beban kerja di semua kluster anggota dalam armada (secara opsional cocok dengan serangkaian kriteria).

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

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

Kebijakan sederhana ini mengambil test-deployment namespace layanan dan semua sumber daya yang terkandung di dalamnya dan menyebarkannya ke semua kluster anggota dalam armada dengan label yang diberikan environment . Jika semua kluster diinginkan, Anda dapat menghapus affinity istilah sepenuhnya.

PickFixed kebijakan penempatan

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

Contoh berikut menunjukkan cara menyebarkan test-deployment namespace ke dalam kluster cluster1 anggota dan cluster2:

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

PickN kebijakan penempatan

Kebijakan 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.

PickN dengan afinitas

Menggunakan afinitas dengan PickN fungsi kebijakan penempatan yang mirip dengan menggunakan afinitas dengan penjadwalan pod. Anda dapat mengatur afinitas yang diperlukan dan lebih disukai. Afinitas yang diperlukan mencegah penempatan ke kluster yang tidak cocok dengan mereka afinitas yang ditentukan, dan afinitas pilihan memungkinkan untuk memesan set kluster yang valid ketika keputusan penempatan sedang dibuat.

Contoh berikut menunjukkan cara menyebarkan beban kerja ke dalam 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/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
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, memisahkan 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/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Untuk informasi selengkapnya, lihat dokumentasi Batasan sebaran topologi hulu Armada.

Perbarui strategi

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

Contoh berikut menunjukkan cara mengonfigurasi strategi pembaruan bergulir menggunakan pengaturan default:

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

Penjadwal 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, misalnya, tidak mengonfirmasi bahwa pod yang dibuat oleh penyebaran menjadi siap.

Untuk informasi selengkapnya, lihat dokumentasi Armada strategi peluncuran upstream.

Status penempatan

Penjadwal Armada memperbarui detail dan status pada keputusan penempatan ke ClusterResourcePlacement objek. Anda dapat melihat informasi ini menggunakan kubectl describe crp <name> perintah . 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 .

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
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

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 PickAll memenuhi syarat dapat memicu penempatan jika memenuhi kebijakan penempatan, misalnya, kebijakan.
    • Kluster dengan penempatan dihapus dari armada akan mencoba mengganti semua beban kerja yang terpengaruh tanpa memengaruhi penempatan mereka yang lain.

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.

Toleransi

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 Armada hulu.

Mengakses API Kubernetes dari kluster sumber daya Armada

Jika Anda membuat sumber daya Azure Kubernetes Fleet Manager dengan kluster hub diaktifkan, Anda dapat menggunakannya untuk mengontrol skenario secara terpusat seperti penyebaran objek Kubernetes. Untuk mengakses API Kubernetes dari kluster sumber daya Armada, ikuti langkah-langkah dalam Mengakses API Kubernetes kluster sumber daya Armada dengan Azure Kubernetes Fleet Manager.

Langkah berikutnya

Siapkan penyebaran sumber daya Kubernetes dari kluster hub ke kluster anggota.