Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

3.5. 호스팅된 클러스터 워크로드 분산

OpenShift Container Platform용 호스팅 제어 플레인을 시작하기 전에 노드에 적절한 레이블을 지정하여 호스팅된 클러스터의 포드를 인프라 노드에 예약할 수 있도록 해야 합니다. 노드 라벨링은 다음과 같은 이유로도 중요합니다.

  • 높은 가용성과 적절한 작업 부하 배포를 보장합니다. 예를 들어, 제어 평면 워크로드가 OpenShift Container Platform 구독에 포함되지 않도록 하려면 node-role.kubernetes.io/infra 레이블을 설정하면 됩니다.
  • 관리 클러스터의 다른 워크로드와 제어 평면 워크로드가 분리되도록 보장합니다.

  • 배포에 맞게 제어 평면 워크로드가 올바른 다중 테넌시 배포 수준으로 구성되었는지 확인합니다. 분포 수준은 다음과 같습니다.

    • 모든 것이 공유됨: 호스팅된 클러스터의 제어 평면은 제어 평면에 지정된 모든 노드에서 실행될 수 있습니다.
    • 요청 제공 격리: 제공 포드는 자체 전용 노드에서 요청됩니다.
    • 공유되는 것이 없습니다. 각 제어 평면에는 전용 노드가 있습니다.

단일 호스팅 클러스터에 노드를 전용하는 방법에 대한 자세한 내용은 "관리 클러스터 노드 레이블 지정"을 참조하세요.

중요

작업 부하에 관리 클러스터를 사용하지 마세요. 작업 부하는 제어 평면이 실행되는 노드에서 실행되어서는 안 됩니다.

3.5.1. 레이블링 관리 클러스터 노드
링크 복사

호스팅된 제어 평면을 배포하려면 적절한 노드 레이블이 필요합니다.

관리 클러스터 관리자는 관리 클러스터 노드에서 다음 레이블과 테인을 사용하여 제어 평면 작업 부하를 예약합니다.

  • hypershift.openshift.io/control-plane: true : 이 레이블과 taint를 사용하여 호스팅된 제어 평면 워크로드를 실행하기 위한 노드를 전담합니다. 값을 true 로 설정하면 관리 클러스터의 인프라 구성 요소나 실수로 배포된 다른 작업 부하 등 다른 구성 요소와 제어 평면 노드를 공유하는 것을 방지할 수 있습니다.
  • hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} : 노드를 단일 호스팅 클러스터에 전용하려는 경우 이 레이블과 taint를 사용합니다.

제어 평면 Pod를 호스팅하는 노드에 다음 레이블을 적용합니다.

  • node-role.kubernetes.io/infra : 이 레이블을 사용하면 제어 평면 워크로드가 구독에 포함되지 않습니다.

  • topology.kubernetes.io/zone : 이 레이블을 관리 클러스터 노드에서 사용하여 장애 도메인 전반에 고가용성 클러스터를 배포합니다. 영역은 영역이 설정된 노드의 위치, 랙 이름 또는 호스트 이름이 될 수 있습니다. 예를 들어, 관리 클러스터에는 다음과 같은 노드가 있습니다: worker-1a , worker-1b , worker-2a , worker-2b . worker-1a 및 worker-1b 노드는 rack1 에 있고, worker-2a 및 worker-2b 노드는 rack2 에 있습니다. 각 랙을 가용성 영역으로 사용하려면 다음 명령을 입력하세요. 

    $ oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
    Copy to Clipboard Toggle word wrap 
    $ oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
    Copy to Clipboard Toggle word wrap

호스팅된 클러스터의 Pod에는 허용 범위가 있으며, 스케줄러는 친화성 규칙을 사용하여 이를 스케줄링합니다. 포드는 제어 평면 과 포드의 클러스터 에 대한 오염을 허용합니다. 스케줄러는 hypershift.openshift.io/control-plane 및 hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} 로 레이블이 지정된 노드에 Pod 예약에 우선순위를 지정합니다.

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

프로세스

호스트 클러스터를 활성화하려면 다음 예와 같이 Pod를 인프라 노드에 예약해야 합니다. HostedCluster.spec.nodeSelector 를 설정합니다. 

  spec:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
Copy to Clipboard Toggle word wrap

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

3.5.2. 우선순위 클래스
링크 복사

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

  • Hypershift-operator: HyperShift Operator Pod
  • Hypershift-etcd: etcd 용 Pod
  • Hypershift-api-critical: API 호출 및 리소스 승인에 필요한 Pod입니다. 이러한 Pod에는 kube-apiserver, 집계 API 서버 및 웹 후크와 같은 Pod가 포함됩니다.
  • Hypershift-control-plane: API-critical는 아니지만 클러스터 버전 Operator와 같이 높은 우선 순위가 필요한 컨트롤 플레인의 Pod입니다.

3.5.3. 사용자 정의 테인트 및 톨러레이션
링크 복사

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

중요

호스팅된 클러스터에 대한 허용 오차를 전달하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

설정 예

  spec:
    tolerations:
    - effect: NoSchedule
      key: kubernetes.io/custom
      operator: Exists
Copy to Clipboard Toggle word wrap

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

CLI 인수 예

--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
Copy to Clipboard Toggle word wrap

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

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

3.5.4. 컨트롤 플레인 격리
링크 복사

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

3.5.4.1. 네트워크 정책 격리
링크 복사

호스트된 각 컨트롤 플레인은 전용 Kubernetes 네임스페이스에서 실행되도록 할당됩니다. 기본적으로 Kubernetes 네임스페이스는 모든 네트워크 트래픽을 거부합니다.

다음 네트워크 트래픽은 Kubernetes CNI(Container Network Interface)에서 강제 적용하는 네트워크 정책을 통해 허용됩니다.

  • 동일한 네임스페이스(Intra-tenant)의 수신 pod-to-pod 통신
  • 테넌트의 호스트된 kube-apiserver Pod에 포트 6443의 수신
  • network.openshift.io/policy-group: 모니터링 라벨을 사용하여 관리 클러스터 Kubernetes 네임스페이스의 메트릭 스크랩을 모니터링 할 수 있습니다.

3.5.4.2. 컨트롤 플레인 Pod 격리
링크 복사

네트워크 정책 외에도 각 호스팅된 컨트롤 플레인 포드는 restricted 보안 컨텍스트 제약 조건을 사용하여 실행됩니다. 이 정책은 모든 호스트 기능에 대한 액세스를 거부하고 고객 컨트롤 플레인을 호스팅하는 각 네임스페이스에 고유하게 할당된 SELinux 컨텍스트를 사용하여 Pod를 UID로 실행해야 합니다.

이 정책은 다음 제약 조건을 확인합니다.

  • Pod는 권한으로 실행할 수 없습니다.
  • Pod는 호스트 디렉터리 볼륨을 마운트할 수 없습니다.
  • Pod는 사전 할당된 UID 범위에서 사용자로 실행해야 합니다.
  • Pod는 사전 할당된 MCS 라벨을 사용하여 실행해야 합니다.
  • Pod는 호스트 네트워크 네임스페이스에 액세스할 수 없습니다.
  • Pod는 호스트 네트워크 포트를 노출할 수 없습니다.
  • Pod는 호스트 PID 네임스페이스에 액세스할 수 없습니다.
  • 기본적으로 Pod는 KILL,MKNOD,SETUID 및 SETGID 와 같은 Linux 기능을 삭제합니다.

각 관리 클러스터 작업자 노드에서 kubelet 및 crio 와 같은 관리 구성 요소는 호스팅된 컨트롤 플레인을 지원하는 Pod의 SELinux 컨텍스트에 액세스할 수 없는 SELinux 레이블로 보호됩니다.

다음 SELinux 레이블은 주요 프로세스 및 소켓에 사용됩니다.

  • kubelet: system_u:system_r:unconfined_service_t:s0
  • crio: system_u:system_r:container_runtime_t:s0
  • crio.sock: system_u:object_r:container_var_run_t:s0
  • <example user container processes>: system_u:system_r:container_t:s0:c14,c24
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat