3.5. 호스트된 클러스터 워크로드 배포

호스팅된 컨트롤 플레인을 배포하기 위한 적절한 노드 레이블링은 사전 요구 사항입니다.

관리 클러스터 관리자는 관리 클러스터 노드에서 다음 레이블 및 테인트를 사용하여 컨트롤 플레인 워크로드를 예약합니다.

control-plane Pod를 호스팅하는 노드에 다음 레이블을 적용합니다.

호스팅된 클러스터의 Pod에는 허용 오차가 있으며 스케줄러는 선호도 규칙을 사용하여 스케줄링합니다. Pod는 컨트롤 플레인 및 Pod에 대한 클러스터 의 테인트를 허용합니다. 스케줄러는 hypershift.openshift.io/control-plane 및 hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} 로 레이블이 지정된 노드에 Pod 예약에 우선순위를 지정합니다.

ControllerAvailabilityPolicy 옵션의 경우 호스팅된 컨트롤 플레인 명령줄 인터페이스인 hcp, deploy의 기본값인 HighlyAvailable 을 사용합니다. 이 옵션을 사용하면 topology.kubernetes.io/zone 을 토폴로지 키로 설정하여 다양한 장애 도메인에서 호스트된 클러스터 내에서 각 배포에 대한 Pod를 예약할 수 있습니다. 다른 장애 도메인에서 호스팅된 클러스터 내에서 배포에 대한 Pod 예약은 고가용성 컨트롤 플레인에만 사용할 수 있습니다.

  spec:
    nodeSelector:
      node-role.kubernetes.io/infra: ""

  spec:
    nodeSelector:
      node-role.kubernetes.io/infra: ""

이렇게 하면 각 호스팅된 클러스터의 호스팅 컨트롤 플레인이 적합한 인프라 노드 워크로드이며 기본 OpenShift Container Platform 노드에 액세스할 필요가 없습니다.

기본 제공 우선순위 클래스 4개가 호스트된 클러스터 Pod의 우선 순위 및 선점에 영향을 미칩니다. 다음과 같은 순서로 관리 클러스터에 Pod를 생성할 수 있습니다.

기본적으로 호스트 클러스터의 Pod는 control-plane 및 cluster taint를 허용합니다. 그러나 호스팅된 클러스터가 HostedCluster.spec.tolerations 를 설정하여 호스트당 클러스터별로 해당 테인트를 허용할 수 있도록 노드에서 사용자 지정 테인트를 사용할 수도 있습니다.

  spec:
    tolerations:
    - effect: NoSchedule
      key: kubernetes.io/custom
      operator: Exists

  spec:
    tolerations:
    - effect: NoSchedule
      key: kubernetes.io/custom
      operator: Exists

--tolerations hcp CLI 인수를 사용하여 클러스터를 생성하는 동안 호스트된 클러스터에 허용 오차를 설정할 수도 있습니다.

--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"

--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"

호스트별로 호스팅된 클러스터 Pod 배치를 세밀하게 제어하려면 nodeSelectors 와 함께 사용자 정의 허용 오차를 사용합니다. 호스트 클러스터 그룹을 공동 배치하고 다른 호스팅 클러스터에서 격리할 수 있습니다. 인프라 및 컨트롤 플레인 노드에 호스팅 클러스터를 배치할 수도 있습니다.

호스팅된 클러스터의 허용 오차는 컨트롤 플레인의 Pod에만 분배됩니다. 가상 머신을 실행하기 위해 pod와 같은 관리 클러스터 및 인프라 관련 Pod에서 실행되는 다른 Pod를 구성하려면 다른 프로세스를 사용해야 합니다.

호스트된 컨트롤 플레인을 구성하여 네트워크 트래픽 또는 컨트롤 플레인 Pod를 분리할 수 있습니다.