6.13. 인프라 노드 생성
머신 API가 작동하는 클러스터에서만 고급 머신 관리 및 스케일링 기능을 사용할 수 있습니다. 사용자 프로비저닝 인프라가 있는 클러스터에는 Machine API를 사용하기 위해 추가 검증 및 구성이 필요합니다.
인프라 플랫폼 유형이 있는 클러스터는 Machine API를 사용할 수 없습니다. 이 제한은 클러스터에 연결된 컴퓨팅 머신이 기능을 지원하는 플랫폼에 설치된 경우에도 적용됩니다. 설치 후에는 이 매개변수를 변경할 수 없습니다.
클러스터의 플랫폼 유형을 보려면 다음 명령을 실행합니다.
$ oc get infrastructure cluster -o jsonpath='{.status.platform}'인프라 머신 세트를 사용하여 기본 라우터, 통합 컨테이너 이미지 레지스트리 및 클러스터 지표 및 모니터링과 같은 인프라 구성 요소만 호스팅하는 머신을 생성할 수 있습니다. 이러한 인프라 머신은 환경을 실행하는 데 필요한 총 서브스크립션 수에 포함되지 않습니다.
프로덕션 배포에서는 인프라 구성 요소를 유지하기 위해 3개 이상의 머신 세트를 배포하는 것이 좋습니다. OpenShift Logging 및 Red Hat OpenShift Service Mesh 모두 Elasticsearch를 배포하므로 3개의 인스턴스를 다른 노드에 설치해야 합니다. 이러한 각 노드는 고가용성을 위해 다른 가용 영역에 배포할 수 있습니다. 이 구성에는 가용성 영역마다 하나씩 세 개의 서로 다른 머신 세트가 필요합니다. 여러 가용성 영역이 없는 글로벌 Azure 리전에서는 가용성 세트를 사용하여 고가용성을 보장할 수 있습니다.
인프라 노드에 NoSchedule 테인트를 추가하면 해당 노드에서 실행 중인 기존 DNS Pod가 잘못 예약 됨으로 표시됩니다. 잘못 스케줄링된 DNS Pod에서 허용 오차를 삭제하거나 추가해야 합니다.
6.13.1. OpenShift Container Platform 인프라 구성 요소
각 자체 관리형 Red Hat OpenShift 서브스크립션에는 OpenShift Container Platform 및 기타 OpenShift 관련 구성 요소에 대한 권한이 포함되어 있습니다. 이러한 권한은 OpenShift Container Platform 컨트롤 플레인 및 인프라 워크로드를 실행하는 데 포함되며 크기 조정 중에 고려하지 않아도 됩니다.
인프라 노드로 자격을 부여하고 포함된 인타이틀먼트를 사용하려면 최종 사용자 애플리케이션의 일부가 아닌 클러스터를 지원하는 구성 요소만 해당 인스턴스에서 실행할 수 있습니다. 예를 들면 다음과 같은 구성 요소가 있습니다.
- Kubernetes 및 OpenShift Container Platform 컨트롤 플레인 서비스
- 기본 라우터
- 통합된 컨테이너 이미지 레지스트리
- HAProxy 기반 Ingress 컨트롤러
- 사용자 정의 프로젝트를 모니터링하기위한 구성 요소를 포함한 클러스터 메트릭 수집 또는 모니터링 서비스
- 클러스터 집계 로깅
- Red Hat Quay
- Red Hat OpenShift Data Foundation
- Red Hat Advanced Cluster Security for Kubernetes
- Red Hat Advanced Cluster Security for Kubernetes
- Red Hat OpenShift GitOps
- Red Hat OpenShift Pipelines
- Red Hat OpenShift Service Mesh
다른 컨테이너, Pod 또는 구성 요소를 실행하는 모든 노드는 서브스크립션을 적용해야 하는 작업자 노드입니다.
인프라 노드 및 인프라 노드에서 실행할 수 있는 구성 요소에 대한 자세한 내용은 엔터프라이즈 Kubernetes 문서의 OpenShift 크기 조정 및 서브스크립션 가이드의 "Red Hat OpenShift 컨트롤 플레인 및 인프라 노드" 섹션을 참조하십시오.
인프라 노드를 생성하려면 머신 세트를 사용하거나노드에 레이블을 지정하거나 머신 구성 풀을 사용할 수 있습니다.
6.13.1.1. 인프라 노드 생성
설치 관리자 프로비저닝 인프라 환경 또는 머신 API에서 컨트롤 플레인 노드를 관리하는 클러스터의 인프라 머신 세트 생성을 참조하십시오.
클러스터의 요구 사항은 infra 노드라고도 불리는 인프라를 프로비저닝해야 합니다. 설치 프로그램은 컨트롤 플레인 및 작업자 노드에 대한 프로비저닝만 제공합니다. 작업자 노드는 레이블을 통해 인프라 노드 또는 애플리케이션 ( app, app 이라고도 함)으로 지정할 수 있습니다.
프로세스
애플리케이션 노드 역할을 수행할 작업자 노드에 레이블을 추가합니다.
$ oc label node <node-name> node-role.kubernetes.io/app=""
인프라 노드 역할을 수행할 작업자 노드에 레이블을 추가합니다.
$ oc label node <node-name> node-role.kubernetes.io/infra=""
해당 노드에
infra역할 및app역할이 있는지 확인합니다.$ oc get nodes
기본 클러스터 수준 노드 선택기를 생성합니다. 기본 노드 선택기는 모든 네임스페이스에서 생성된 Pod에 적용됩니다. 이렇게 하면 Pod의 기존 노드 선택기와 교차점이 생성되어 Pod의 선택기가 추가로 제한됩니다.
중요기본 노드 선택기 키가 Pod 라벨 키와 충돌하는 경우 기본 노드 선택기가 적용되지 않습니다.
그러나 Pod를 예약할 수 없게 만들 수 있는 기본 노드 선택기를 설정하지 마십시오. 예를 들어 Pod의 라벨이
node-role.kubernetes.io/master=""와 같은 다른 노드 역할로 설정된 경우 기본 노드 선택기를node-role.kubernetes.io/infra=""와 같은 특정 노드 역할로 설정하면 Pod를 예약할 수 없게 될 수 있습니다. 따라서 기본 노드 선택기를 특정 노드 역할로 설정할 때 주의해야 합니다.또는 프로젝트 노드 선택기를 사용하여 클러스터 수준 노드 선택기 키 충돌을 방지할 수 있습니다.
Scheduler오브젝트를 편집합니다.$ oc edit scheduler cluster
적절한 노드 선택기를 사용하여
defaultNodeSelector필드를 추가합니다.apiVersion: config.openshift.io/v1 kind: Scheduler metadata: name: cluster spec: defaultNodeSelector: node-role.kubernetes.io/infra="" 1 # ...- 1
- 이 예제 노드 선택기는 기본적으로 인프라 노드에 Pod를 배포합니다.
- 파일을 저장하여 변경 사항을 적용합니다.
이제 인프라 리소스를 새로 레이블이 지정된 인프라 노드로 이동할 수 있습니다.
추가 리소스
