다음을 통해 공유

허브 클러스터에서 멤버 클러스터로 Kubernetes 리소스 전파

  • 아티클

이 문서에서는 Azure Kubernetes Fleet Manager(Fleet)를 사용한 허브 클러스터에서 멤버 클러스터로의 Kubernetes 리소스 전파에 대한 개념을 설명합니다.

플랫폼 관리자는 다음과 같은 다양한 이유로 Kubernetes 리소스를 여러 클러스터에 배포해야 하는 경우가 많습니다.

  • 여러 클러스터에서 역할 및 역할 바인딩을 사용하여 액세스 제어를 관리할 경우.
  • 모든 클러스터에 있어야 하는 Prometheus 또는 Flux와 같은 인프라 애플리케이션을 실행할 경우.

애플리케이션 개발자는 다음과 같은 다양한 이유로 Kubernetes 리소스를 여러 클러스터에 배포해야 하는 경우가 많습니다.

  • 짧은 대기 시간 시청 환경을 위해 여러 지역의 여러 클러스터에 애플리케이션을 제공하는 비디오를 배포할 경우.
  • 고객이 단일 지역 중단 시 계속 쇼핑할 수 있도록 두 개의 쌍을 이루는 지역에 쇼핑 카트 애플리케이션을 배포할 경우.
  • 저렴한 스폿 노드 풀을 사용할 수 있는 클러스터에 일괄 처리 컴퓨팅 애플리케이션을 배포할 경우.

여러 클러스터에서 이러한 Kubernetes 리소스를 수동으로 만들고, 업데이트하고, 추적하는 것은 지루한 일입니다. Fleet은 Kubernetes 리소스를 대규모로 관리할 수 있도록 Kubernetes 리소스 전파를 제공합니다. Fleet을 사용하면 허브 클러스터에서 Kubernetes 리소스를 만들고 Kubernetes 사용자 지정 리소스(MemberCluster 및 ClusterResourcePlacement)를 통해 선택한 멤버 클러스터에 전파할 수 있습니다. Fleet은 오픈 소스 클라우드 네이티브 다중 클러스터 솔루션 기반으로 이러한 사용자 지정 리소스를 지원합니다. 자세한 내용은 Fleet 문서 업스트림을 참조하세요.

Important

Azure Kubernetes Fleet Manager 미리 보기 기능은 셀프 서비스, 옵트인 기반으로 제공됩니다. 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. Azure Kubernetes Fleet Manager 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다.

리소스 전파 워크플로

Kubernetes 리소스가 멤버 클러스터로 전파되는 방법을 보여 주는 다이어그램.

MemberCluster란?

클러스터가 Fleet에 조인되면 해당 MemberCluster 사용자 지정 리소스가 허브 클러스터에 만들어집니다. 이 사용자 지정 리소스를 사용하여 리소스 전파에서 대상 클러스터를 선택할 수 있습니다.

다음 레이블은 리소스 전파에서 대상 클러스터 선택에 사용할 수 있으며, 모든 멤버 클러스터에 자동으로 추가됩니다.

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

자세한 내용은 MemberCluster API 참조를 참조하세요.

ClusterResourcePlacement란?

ClusterResourcePlacement 개체는 Fleet 스케줄러에게 허브 클러스터의 지정된 클러스터 범위 개체 집합을 멤버 클러스터에 배치하는 방법을 알려주는 데 사용됩니다. Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets 및 PersistentVolumeClaims와 같은 네임스페이스 범위 개체는 포함된 네임스페이스를 선택하면 포함됩니다.

ClusterResourcePlacement로 다음을 수행할 수 있습니다.

  • 멤버 클러스터에 전파할 클러스터 범위 Kubernetes 리소스를 선택합니다.
  • 하위 집합 또는 모든 멤버 클러스터를 대상 클러스터로 수동으로 또는 자동으로 선택할 배치 정책을 지정합니다.
  • 선택한 Kubernetes 리소스의 업데이트를 여러 대상 클러스터에 안전하게 롤아웃하도록 롤아웃 전략을 지정합니다.
  • 각 대상 클러스터에 대한 전파 진행률을 확인합니다.

의도하지 않은 부작용 없이 멤버 클러스터에 전파하기 위해 ClusterResourcePlacement 개체는 ConfigMap을 사용하여 개체를 포함하도록 지원합니다. 선택 방법에는 다음이 포함됩니다.

  • 그룹, 버전 및 종류: 지정된 형식의 모든 리소스를 선택하고 배치합니다.
  • 그룹, 버전, 종류 및 이름: 지정된 형식의 특정 리소스 하나를 선택하고 배치합니다.
  • 그룹, 버전, 종류 및 레이블: 제공된 레이블과 일치하는 지정된 형식의 모든 리소스를 선택하고 배치합니다.

자세한 내용은 ClusterResourcePlacement API 참조를 참조하세요.

ClusterResourcePlacement를 만들 때 다음 선호도 형식을 지정할 수 있습니다.

  • requiredDuringSchedulingIgnoredDuringExecution: 이 유사성은 예약 중에 필수 형식이므로 해당 속성을 기준으로 클러스터를 필터링합니다.
  • preferredDuringSchedulingIgnoredDuringExecution: 이 유사성은 기본 설정 형식일 뿐이고 예약 중에는 필요하지 않으므로 비용 또는 리소스 가용성과 같이 사용자가 지정한 속성을 기반으로 클러스터에 우선 순위 지정을 제공합니다.

Kubernetes 리소스를 전파해야 하는 클러스터 수를 제어하기 위해 여러 배치 형식을 사용할 수 있습니다.

  • PickAll은 리소스를 사용 가능한 모든 멤버 클러스터에 배치합니다. 이 정책은 클러스터 모니터링 또는 애플리케이션 보고와 같은 인프라 워크로드를 배치하는 데 유용합니다.
  • PickFixed는 리소스를 이름별로 특정 멤버 클러스터 목록에 배치합니다.
  • PickN은 가장 유연한 배치 옵션이며 선호도 또는 토폴로지 분산 제약 조건에 따라 클러스터를 선택할 수 있으며 가용성을 보장하기 위해 여러 적절한 클러스터에 워크로드를 분산할 때 유용합니다.

PickAll 배치 정책

Fleet의 모든 멤버 클러스터에 워크로드를 배포하기 위해(선택적으로 조건 집합과 일치) PickAll 배치 정책을 사용할 수 있습니다.

다음 예제에서는 test-deployment 네임스페이스와 모든 해당 개체를 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

이 간단한 정책은 test-deployment 네임스페이스와 그 안에 포함된 모든 리소스를 사용하여 지정된 environment 레이블이 있는 Fleet의 모든 멤버 클러스터에 배포합니다. 모든 클러스터가 필요한 경우 affinity 용어를 완전히 제거하면 됩니다.

PickFixed 배치 정책

알려진 멤버 클러스터 집합에 워크로드를 배포하려는 경우 PickFixed 배치 정책을 사용하여 이름을 기준으로 클러스터를 선택할 수 있습니다.

다음 예제에서는 test-deployment 네임스페이스를 멤버 클러스터 cluster1 및 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 배치 정책

PickN 배치 정책은 가장 유연한 옵션이며, 선호도 및 토폴로지 분산 제약 조건을 기반으로 구성 가능한 수의 클러스터에 리소스를 배치할 수 있습니다.

선호도가 있는 PickN

Pod 예약에 선호도를 사용하는 것과 유사하게 PickN 배치 정책 함수로 선호도를 사용합니다. 필수 및 기본 선호도를 모두 설정할 수 있습니다. 필수 선호도는 이렇게 지정된 선호도와 일치하지 않는 클러스터에 배치하는 것을 방지합니다. 기본 선호도를 사용하면 배치 결정이 내려질 때 유효한 클러스터 집합의 순서를 지정할 수 있습니다.

다음 예제는 워크로드를 세 개의 클러스터에 배포하는 방법을 보여 줍니다. critical-allowed: "true" 레이블이 있는 클러스터만 유효한 배치 대상이며 레이블이 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

토폴로지 분산 제약 조건을 사용하여 토폴로지 경계를 넘어 클러스터 배치를 강제로 분할하여 가용성 요구 사항(예: 지역 간 배치 분산 또는 업데이트 링)을 충족할 수 있습니다. 제약 조건을 충족할 수 없거나(whenUnsatisfiable: DoNotSchedule) 가능한 한 최선으로 예약할 수 없는 경우(whenUnsatisfiable: ScheduleAnyway) 예약을 방지하도록 토폴로지 분산 제약 조건을 구성할 수도 있습니다.

다음 예제는 주어진 리소스 집합을 여러 지역에 분산시키고 업데이트 날짜가 다른 멤버 클러스터에서 일정을 예약하려고 시도하는 방법을 보여 줍니다.

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

자세한 내용은 업스트림 토폴로지 스프레드 제약 조건 Fleet 설명서를 참조하세요.

업데이트 전략

Fleet은 롤링 업데이트 전략을 사용하여 여러 클러스터 배치에 걸쳐 업데이트가 롤아웃되는 방식을 제어합니다.

다음 예제에서는 기본 설정을 사용하여 롤링 업데이트 전략을 구성하는 방법을 보여 줍니다.

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

스케줄러는 각 클러스터에 업데이트를 순차적으로 롤아웃하고 클러스터 간에 최소 unavailablePeriodSeconds를 기다립니다. 모든 리소스가 클러스터에 올바르게 적용된 경우 롤아웃 상태는 성공한 것으로 간주됩니다. 롤아웃 상태 확인은 자식 리소스에 계단식으로 적용되지 않습니다. 예를 들어 배포로 생성된 Pod가 준비되었는지 확인하지 않습니다.

자세한 내용은 롤아웃 전략 업스트림 Fleet 문서를 참조하세요.

배치 상태

Fleet 스케줄러는 배치 결정에 대한 세부 정보 및 상태를 ClusterResourcePlacement 개체로 업데이트합니다. kubectl describe crp <name> 명령을 사용하여 이 정보를 볼 수 있습니다. 출력에는 다음 정보가 포함됩니다.

  • 현재 배치에 적용되는 조건(배치가 성공적으로 완료되었는지 여부 포함)
  • 각 멤버 클러스터에 대한 배치 상태 섹션(해당 클러스터에 대한 배포 상태 표시)

다음 예제에서는 PickN을 사용하여 test 네임스페이스와 test-1 ConfigMap을 두 개의 멤버 클러스터에 배포한 ClusterResourcePlacement를 보여 줍니다. 배치가 성공적으로 완료되었고 리소스가 aks-member-1 및 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

배치 변경 내용

Fleet 스케줄러는 기존 워크로드 배치의 안정성을 우선시합니다. 이 우선 순위로 변경 횟수가 제한되어 워크로드가 제거되거나 다시 예약될 수 있습니다. 다음 시나리오는 배치 변경을 트리거할 수 있습니다.

  • ClusterResourcePlacement 개체의 배치 정책 변경으로 인해 워크로드 제거 및 다시 예약이 트리거될 수 있습니다.
    • 스케일 아웃 작업(다른 변경 없이 numberOfClusters 증가)은 새 클러스터에만 워크로드를 배치하고 기존 배치에 영향을 주지 않습니다.
  • 클러스터 변경 내용에는 다음이 포함됩니다.
    • 적격이 되는 새 클러스터는 배치 정책(예: PickAll 정책)을 충족하는 경우 배치를 트리거할 수 있습니다.
    • Fleet에서 배치가 제거된 클러스터는 다른 배치에 영향을 주지 않고 영향을 받는 모든 워크로드를 다시 배치하려고 시도합니다.

리소스 전용 변경 내용(리소스 업데이트 또는 ClusterResourcePlacement 개체의 ResourceSelector 업데이트)은 기존 배치에서 점진적으로 롤아웃되지만 워크로드의 다시 예약을 트리거하지 않습니다.

톨러레이션

ClusterResourcePlacement 개체는 ClusterResourcePlacement 개체에 적용되는 톨러레이션의 사양을 지원합니다. 각 톨러레이션 개체는 다음 필드로 구성됩니다.

  • key: 톨러레이션의 키.
  • value: 톨러레이션의 값.
  • effect: NoSchedule과 같은 톨러레이션의 효과.
  • operator: Exists 또는 Equal과 같은 톨러레이션의 연산자입니다.

각 톨러레이션은 ClusterResourcePlacement에 적용된 하나 이상의 특정 테인트를 용인하는 데 사용됩니다. MemberCluster의 모든 테인트가 용인되면 스케줄러는 리소스를 클러스터에 전파할 수 있습니다. ClusterResourcePlacement 개체를 만든 후에는 톨러레이션을 업데이트하거나 제거할 수 없습니다.

자세한 내용은 Fleet 문서 업스트림을 참조하세요.

Fleet 리소스 클러스터의 Kubernetes API에 액세스

허브 클러스터를 사용하도록 설정하여 Azure Kubernetes Fleet Manager 리소스를 만든 경우 Kubernetes 개체 전파와 같은 시나리오를 중앙에서 제어하는 데 사용할 수 있습니다. Fleet 리소스 클러스터의 Kubernetes API에 액세스하려면 Azure Kubernetes Fleet Manager를 사용하여 Fleet 리소스 클러스터의 Kubernetes API에 액세스의 단계를 수행하세요.

다음 단계

허브 클러스터에서 멤버 클러스터로 Kubernetes 리소스 전파를 설정합니다.