4장. OpenShift Container Platform 컨트롤 플레인
4.1. OpenShift Container Platform 컨트롤 플레인 이해
컨트롤 플레인 머신(마스터 머신이라고도 함)으로 구성된 컨트롤 플레인은 OpenShift Container Platform 클러스터를 관리합니다. 컨트롤 플레인 머신에서는 작업자 머신이라고도 하는 컴퓨팅 머신의 워크로드를 관리합니다. 클러스터 자체에서 Cluster Version Operator, Machine Config Operator 및 개별 Operator 세트의 작업을 통해 머신과 관련된 모든 업그레이드를 관리합니다.
4.1.1. 머신 구성 풀을 사용한 노드 구성 관리
컨트롤 플레인 구성 요소 또는 사용자 워크로드를 실행하는 머신은 처리하는 리소스 유형에 따라 그룹으로 나뉩니다. 이러한 머신 그룹을 MCP(Machine config pool)라고 합니다. 각 MCP는 노드 세트와 해당 머신 구성을 관리합니다. 노드의 역할은 해당 노드가 속한 MCP를 결정합니다. MCP는 할당된 노드 역할 레이블을 기반으로 노드를 관리합니다. MCP의 노드에는 동일한 구성이 있습니다. 즉, 워크로드 증가 또는 감소에 따라 노드를 확장하고 제거할 수 있습니다.
기본적으로 클러스터가 설치될 때 생성되는 master 및 worker라는 두 개의 MCP가 있습니다. 각 기본 MCP에는 MCP(Machine Config Operator)에 의해 적용되는 정의된 구성이 있으며 MCP를 관리하고 MCP 업그레이드를 가능하게 합니다. 추가 MCP 또는 사용자 지정 풀을 생성하여 기본 노드 유형 이외의 사용자 지정 사용 사례가 있는 노드를 관리할 수 있습니다.
사용자 지정 풀은 작업자 풀에서 구성을 상속하는 풀입니다. 작업자 풀을 대상으로 하는 머신 구성을 사용하지만 사용자 지정 풀을 대상으로 하는 변경 사항만 배포할 수 있는 기능을 추가합니다. 사용자 지정 풀은 작업자 풀의 구성을 상속하므로 작업자 풀에 대한 모든 변경 사항이 사용자 정의 풀에도 적용됩니다. 작업자 풀에서 구성을 상속하지 않는 사용자 지정 풀은 MCO에서 지원되지 않습니다.
노드는 하나의 MCP에만 포함될 수 있습니다. 노드에 worker,infra와 같이 여러 MCP에 해당하는 여러 레이블이 있는 경우 작업자 풀이 아닌 인프라 사용자 지정 풀로 관리됩니다. 사용자 지정 풀은 노드 레이블을 기반으로 관리할 노드를 선택하는 데 우선 순위를 두고 사용자 지정 풀에 속하지 않은 노드는 작업자 풀에서 관리합니다.
클러스터에서 관리할 모든 노드 역할에 대한 사용자 지정 풀을 사용하는 것이 좋습니다. 예를 들어 인프라 워크로드를 처리하기 위해 인프라 노드를 생성하는 경우 사용자 지정 인프라 MCP를 생성하여 해당 노드를 그룹화하는 것이 좋습니다. 작업자 노드에 infra 역할 레이블을 적용하면 worker,infra 이중 레이블이 있지만 사용자 지정 인프라 MCP가 없는 경우 MCO는 이를 작업자 노드로 간주합니다. 노드에서 worker 레이블을 제거하고 사용자 지정 풀에서 그룹화하지 않고 infra 레이블을 적용하면 노드는 MCO에서 인식되지 않으며 클러스터에서 관리되지 않습니다.
인프라 워크로드를 실행하는 경우에만 infra 역할로 레이블이 지정된 노드는 총 서브스크립션 수에 포함되지 않습니다. 인프라 노드를 관리하는 MCP는 클러스터가 서브스크립션을 결정하는 방법에서 상호 배타적일 수 있습니다. 적절한 infra 역할로 노드를 태그하고 테인트를 사용하여 사용자 워크로드가 해당 노드에서 예약되지 않도록 하는 것이 인프라 워크로드에 대한 서브스크립션 요금을 부과하지 않도록 하는 유일한 요구 사항입니다.
MCO는 풀에 독립적으로 업데이트를 적용합니다. 예를 들어 모든 풀에 영향을 미치는 업데이트가 있는 경우 각 풀의 노드는 서로 병렬로 업데이트됩니다. 사용자 지정 풀을 추가하면 해당 풀에서 노드도 마스터 및 작업자 노드와 동시에 업데이트를 시도합니다.
4.1.2. OpenShift Container Platform의 머신 역할
OpenShift Container Platform은 호스트에 다른 역할을 할당합니다. 이 역할은 클러스터 내에서 머신의 기능을 정의합니다. 클러스터에는 표준 마스터 및 작업자 역할 유형의 정의가 포함됩니다.
클러스터에는 부트스트랩 역할의 정의도 포함되어 있습니다. 부트스트랩 머신은 클러스터 설치 중에만 사용되므로 해당 기능은 클러스터 설치 설명서에 설명되어 있습니다.
4.1.2.1. 컨트롤 플레인 및 노드 호스트 호환성
OpenShift Container Platform 버전은 컨트롤 플레인 호스트와 노드 호스트 간의 일치해야 합니다. 예를 들어 4.9 클러스터에서는 모든 컨트롤 플레인 호스트가 4.9이고 모든 노드가 4.9이어야 합니다.
클러스터를 업그레이드하는 동안 일시적인 불일치가 허용됩니다. 예를 들어 OpenShift Container Platform 4.8에서 4.9로 업그레이드하는 경우 일부 노드는 다른 노드보다 4.9로 업그레이드됩니다. 컨트롤 플레인 호스트와 노드 호스트를 많이 사용하면 이전 컴퓨팅 머신이 버그 및 누락된 기능에 노출될 수 있습니다. 사용자는 최대한 빨리 불일치 컨트롤 플레인 호스트와 노드 호스트를 확인해야 합니다.
kubelet 서비스는 kube-apiserver 보다 최신 상태가 아니어야 하며 OpenShift Container Platform 버전이 홀수인지에 따라 이전 버전 2개까지 이전할 수 있습니다. 아래 표는 적절한 버전 호환성을 보여줍니다.
| OpenShift Container Platform 버전 | 지원되는 kubelet 불일치 |
|---|---|
| 홀수 OpenShift Container Platform 마이너 버전 [1] | 이전 버전 최대 1개 |
| OpenShift Container Platform 마이너 버전도 [2] | 이전 버전 최대 2개 |
- 예를 들어 OpenShift Container Platform 4.5, 4.7, 4.9입니다.
- 예를 들면 OpenShift Container Platform 4.6, 4.8, 4.10입니다.
4.1.2.2. 클러스터 작업자
Kubernetes 클러스터에서 작업자 노드는 Kubernetes 사용자가 요청한 실제 워크로드가 실행되고 관리되는 위치입니다. 작업자 노드는 용량을 알리고 마스터 서비스의 일부인 스케줄러는 컨테이너와 포드를 시작할 노드를 결정합니다. 컨테이너 엔진인 CRI-O, 컨테이너 워크로드 실행 및 중지 요청을 수락 및 이행하는 서비스인 Kubelet 및 작업자 간의 포드 통신을 관리하는 서비스 프록시를 포함하여 각 작업자 노드에서 중요한 서비스가 실행됩니다.
OpenShift Container Platform에서 머신 세트가 작업자 머신을 제어합니다. 작업자 역할 드라이브가 있는 머신은 자동 스케일링하는 특정 머신 풀이 관리하는 워크로드를 컴퓨팅합니다. OpenShift Container Platform에는 여러 머신 유형을 지원할 수 있는 용량이 있으므로 작업자 머신은 컴퓨팅 머신으로 분류됩니다. 이 릴리스에서는 기본 유형의 컴퓨팅 머신이 작업자 머신이기 때문에 작업자 머신과 컴퓨팅 머신이라는 용어는 서로 바꿔 사용할 수 있습니다. 이후 버전의 OpenShift Container Platform에서는 기본적으로 인프라 머신과 같은 다른 유형의 컴퓨팅 머신이 사용될 수 있습니다.
머신 세트는 machine-api 네임스페이스에서 머신 리소스의 그룹입니다. 머신 세트는 특정 클라우드 공급자에서 새 머신을 시작하기 위해 설계된 구성입니다. 반대로 MCP(Machine config pool)는 MCO(Machine Config Operator) 네임스페이스의 일부입니다. MCP는 MCO가 구성을 관리하고 업그레이드를 원활하게 수행할 수 있도록 머신을 그룹화하는데 사용됩니다.
4.1.2.3. 클러스터 마스터
Kubernetes 클러스터에서 컨트롤 플레인 노드(마스터 노드라고도 함)는 Kubernetes 클러스터를 제어하는 데 필요한 서비스를 실행합니다. OpenShift Container Platform에서 컨트롤 플레인 시스템은 컨트롤 플레인입니다. 여기에는 OpenShift Container Platform 클러스터 관리를 위한 Kubernetes 서비스 외에도 많은 것이 포함되어 있습니다. 컨트롤 플레인 역할의 모든 머신은 컨트롤 플레인 머신이므로 마스터 와 컨트롤 플레인 이라는 용어는 서로 바꿔 사용할 수 있습니다. 컨트롤 플레인 시스템은 머신 세트로 그룹화되는 대신 일련의 독립 실행형 머신 API 리소스로 정의됩니다. 모든 컨트롤 플레인 시스템을 삭제하고 클러스터를 손상시키지 않도록 컨트롤 플레인 시스템에 추가 컨트롤이 적용됩니다.
모든 프로덕션 배포에 정확히 세 개의 컨트롤 플레인 노드를 사용해야 합니다.
마스터의 Kubernetes 카테고리에 속하는 서비스에는 Kubernetes API 서버, etcd, Kubernetes 컨트롤러 관리자 및 Kuberbetes 스케줄러가 포함됩니다.
| 구성 요소 | 설명 |
|---|---|
| Kubernetes API 서버 | Kubernetes API 서버는 포드, 서비스 및 복제 컨트롤러의 데이터를 검증하고 구성합니다. 클러스터의 공유 상태에 대한 초점도 제공합니다. |
| etcd | etcd는 지속적 마스터 상태를 저장하고 다른 구성 요소는 etcd가 변경사항을 감시하여 지정된 상태로 변경될 수 있게 합니다. |
| Kubernetes 컨트롤러 관리자 | Kubernetes 컨트롤러 관리자는 etcd에서 복제, 네임스페이스 및 서비스 계정 컨트롤러 오브젝트와 같은 오브젝트의 변경사항을 감시한 다음 API를 사용하여 지정된 상태를 적용합니다. 이러한 여러 프로세스는 한 번에 하나의 활성 리더가 있는 클러스터를 생성합니다. |
| Kubernetes 스케줄러 | Kubernetes 스케줄러는 할당된 노드가 없는 새로 생성된 Pod를 감시하고 Pod를 호스팅할 수 있는 최상의 노드를 선택합니다. |
OpenShift API 서버, OpenShift 컨트롤러 관리자 및 OpenShift OAuth API 서버 및 OpenShift OAuth 서버를 포함하는 컨트롤 플레인에서 실행되는 OpenShift 서비스도 있습니다.
| 구성 요소 | 설명 |
|---|---|
| OpenShift API 서버 | OpenShift API 서버는 프로젝트, 경로 및 템플릿과 같은 OpenShift 리소스의 데이터 유효성을 검사하고 구성합니다. OpenShift API 서버는 OpenShift API Server Operator가 관리합니다. |
| OpenShift 컨트롤러 관리자 | OpenShift 컨트롤러 관리자는 etcd에서 프로젝트, 경로 및 템플릿 컨트롤러 오브젝트와 같은 OpenShift 오브젝트의 변경사항을 감시한 다음 API를 사용하여 지정된 상태를 적용합니다. OpenShift 컨트롤러 관리자는 OpenShift Controller Manager Operator가 관리합니다. |
| OpenShift OAuth API 서버 | OpenShift OAuth API 서버는 사용자, 그룹 및 OAuth 토큰과 같은 OpenShift Container Platform에 인증할 데이터의 유효성을 검사하고 구성합니다. OpenShift OAuth API 서버는 Cluster Authentication Operator가 관리합니다. |
| OpenShift OAuth 서버 | 사용자는 OpenShift OAuth 서버에서 토큰을 요청하여 API에 자신을 인증합니다. OpenShift OAuth 서버는 Cluster Authentication Operator가 관리합니다. |
컨트롤 플레인 시스템의 이러한 서비스 중 일부는 systemd 서비스로 실행되는 반면 다른 서비스는 정적 포드로 실행됩니다.
시스템 서비스는 특정 시스템이 시작된 직후에 항상 필요한 서비스에 적합합니다. 컨트롤 플레인 시스템의 경우 원격 로그인을 허용하는 sshd가 포함됩니다. 다음과 같은 서비스도 포함됩니다.
- 컨테이너를 실행하고 관리하는 CRI-O 컨테이너 엔진(crio). OpenShift Container Platform 4.6에서는 Docker Container Engine 대신 CRI-O를 사용합니다.
- Kubelet(kubelet): 마스터 서비스에서 머신의 컨테이너 관리 요청을 수락합니다.
CRI-O 및 Kubelet은 다른 컨테이너를 실행하기 전에 실행되어야 하기 때문에 systemd 서비스로 호스트에서 직접 실행해야 합니다.
installer-* 및 revision-pruner-* 컨트롤 플레인 Pod는 root 사용자가 소유한 /etc/kubernetes 디렉토리에 쓰기 때문에 root 권한으로 실행해야 합니다. 이러한 pod에는 다음과 같은 네임스페이스에 있습니다.
-
openshift-etcd -
openshift-kube-apiserver -
openshift-kube-controller-manager -
openshift-kube-scheduler
4.1.3. OpenShift Container Platform의 Operator
OpenShift Container Platform에서 Operator는 컨트롤 플레인에서 서비스를 패키징, 배포 및 관리하는 기본 방법입니다. 또한 사용자가 실행하는 애플리케이션에 이점을 제공합니다. Operator는 kubectl 및 oc 명령과 같은 CLI 툴 및 Kubernetes API와 통합됩니다. 애플리케이션을 감시하고, 상태 검사를 수행하며, 무선 업데이트를 관리하고, 애플리케이션이 지정된 상태를 유지하게 하는 수단을 제공합니다.
CRI-O 및 Kubelet은 모든 노드에서 실행되므로 Operator를 사용하여 거의 모든 다른 클러스터 기능을 컨트롤 플레인에서 관리할 수 있습니다. Operator는 OpenShift Container Platform 4.6의 가장 중요한 구성 요소 중 하나입니다. Operator를 사용하여 컨트롤 플레인에 추가되는 구성 요소에는 중요한 네트워킹 및 자격 증명 서비스가 포함됩니다.
OpenShift Container Platform 클러스터에서 다른 Operator를 관리하는 Operator는 Cluster Version Operator입니다.
OpenShift Container Platform 4.6에서는 다양한 클래스의 Operator를 사용하여 클러스터 작업을 수행하고 애플리케이션이 사용할 클러스터에서 서비스를 실행합니다.
4.1.3.1. OpenShift Container Platform의 Platform Operator
OpenShift Container Platform 4.6에서 모든 클러스터 기능은 일련의 플랫폼 Operator로 나뉩니다. Platform Operator는 전체 클러스터 애플리케이션 로깅, Kubernetes 컨트롤 플레인 관리 또는 머신 프로비저닝 시스템과 같은 특정 클러스터 기능 영역을 관리합니다.
각 Operator는 클러스터 기능을 결정하기 위해 간단한 API를 제공합니다. Operator는 해당 구성 요소의 라이프사이클 관리 세부사항을 숨깁니다. Operator는 단일 구성 요소 또는 수십 개의 구성 요소를 관리할 수 있지만 최종 목표는 항상 일반적인 작업을 자동화하여 운영 부담을 줄이는 것입니다. Operator에서는 더 세분화된 구성 환경도 제공합니다. 글로벌 구성 파일을 수정하는 대신 Operator가 표시하는 API를 수정하여 각 구성 요소를 구성합니다.
4.1.3.2. OLM에서 관리하는 Operator
OLM(Cluster Operator Lifecycle Management) 구성 요소는 애플리케이션에서 사용할 수 있는 Opeartor를 관리합니다. OpenShift Container Platform을 구성하는 Operator는 관리하지 않습니다. OLM은 Kubernetes 네이티브 애플리케이션을 Operator로 관리하는 프레임워크입니다. Kubernetes 매니페스트를 관리하는 대신 Kubernetes Operator를 관리합니다. OLM은 Red Hat Operators와 Certified Operators의 두 가지 Operator 클래스를 관리합니다.
일부 Red Hat Operator는 스케줄러 및 문제 탐지기와 같은 클러스터 기능을 구동합니다. 자체적으로 관리하고 etcd와 같이 애플리케이션에서 사용할 수 있는 기타 기능이 제공됩니다. OpenShift Container Platform은 또한 커뮤니티가 빌드하고 유지보수하는 인증된 Operator를 제공합니다. 이 인증된 Operator는 기존 애플리케이션에 API 계층을 제공하므로 Kubernetes 구성을 통해 애플리케이션을 관리할 수 있습니다.
4.1.3.3. OpenShift 업데이트 서비스 정보
OSUS(OpenShift Update Service)는 Red Hat Enterprise Linux CoreOS(RHCOS)를 비롯한 OpenShift Container Platform에 대한 무선 업데이트를 제공합니다. 구성 요소 Operator의 정점과 이를 연결하는 에지를 포함하는 그래프 또는 다이어그램을 제공합니다. 그래프의 에지에는 안전하게 업데이트할 수 있는 버전이 표시됩니다. 정점은 관리형 클러스터 구성 요소의 상태를 지정하는 업데이트 페이로드입니다.
클러스터의 CVO (Cluster Version Operator)는 OpenShift Update Service를 확인하여 현재 구성 요소 버전 및 그래프의 정보를 기반으로 유효한 업데이트 및 업데이트 경로를 확인합니다. 업데이트를 요청하면 CVO는 해당 업데이트에 릴리스 이미지를 사용하여 클러스터를 업데이트합니다. 릴리스 아티팩트는 Quay에서 컨테이너 이미지로 호스팅됩니다.
OpenShift Update Service가 호환 가능한 업데이트만 제공할 수 있도록 자동화를 지원하는 버전 확인 파이프 라인이 제공됩니다. 각 릴리스 아티팩트는 지원되는 클라우드 플랫폼 및 시스템 아키텍처 및 기타 구성 요소 패키지와의 호환성 여부를 확인합니다. 파이프 라인에서 적용 가능한 버전이 있음을 확인한 후 OpenShift Update Service는 해당 버전 업데이트를 사용할 수 있음을 알려줍니다.
OpenShift Update Service는 현재 클러스터에 권장되는 모든 업데이트를 표시합니다. OpenShift Update Service에서 업그레이드 경로를 권장하지 않는 경우 업데이트 또는 대상 릴리스와 관련된 알려진 문제로 인해 발생할 수 있습니다.
연속 업데이트 모드에서는 두 개의 컨트롤러가 실행됩니다. 하나의 컨트롤러는 페이로드 매니페스트를 지속적으로 업데이트하여 매니페스트를 클러스터에 적용한 다음 Operator의 제어된 롤아웃 상태를 출력하여 사용 가능한지, 업그레이드했는지 또는 실패했는지의 여부를 나타냅니다. 두 번째 컨트롤러는 OpenShift Update Service를 폴링하여 업데이트를 사용할 수 있는지 확인합니다.
최신 버전으로의 업그레이드만 지원됩니다. 클러스터를 이전 버전으로 되돌리거나 롤백을 수행하는 것은 지원되지 않습니다. 업데이트에 실패하면 Red Hat 지원에 문의하십시오.
업데이트 프로세스 중에 MCO (Machine Config Operator)는 새 구성을 클러스터 머신에 적용합니다. MCO는 머신 설정 풀의 maxUnavailable 필드에 지정된 노드 수를 제한하고 이를 사용할 수없는 것으로 표시합니다. 기본적으로 이 값은 1로 설정됩니다. MCO는 새 설정을 적용하여 컴퓨터를 다시 시작합니다.
RHEL (Red Hat Enterprise Linux) 머신을 작업자로 사용하는 경우 먼저 시스템에서 OpenShift API를 업데이트해야하기 때문에 MCO는 이 머신에서 kubelet을 업데이트하지 않습니다.
새 버전의 사양이 이전 kubelet에 적용되므로 RHEL 머신을 Ready 상태로 되돌릴 수 없습니다. 컴퓨터를 사용할 수 있을 때까지 업데이트를 완료할 수 없습니다. 그러나 사용 불가능한 최대 노드 수를 설정하면 사용할 수 없는 머신의 수가 이 값을 초과하지 않는 경우에도 정상적인 클러스터 작업을 계속할 수 있습니다.
OpenShift Update Service는 Operator 및 하나 이상의 애플리케이션 인스턴스로 구성됩니다.
4.1.3.4. Machine Config Operator 이해
OpenShift Container Platform 4.6은 운영 체제와 클러스터 관리를 모두 통합합니다. 클러스터는 클러스터 노드에서 RHCOS(Red Hat Enterprise Linux CoreOS)에 대한 업데이트를 포함하여 자체 업데이트를 관리하므로 OpenShift Container Platform은 노드 업그레이드 오케스트레이션을 단순화하는 독단적인 라이프사이클 관리 환경을 제공합니다.
OpenShift Container Platform은 3개의 데몬 세트와 컨트롤러를 사용하여 노드 관리를 단순화합니다. 이러한 데몬 세트는 표준 Kubernetes 스타일 구성을 사용하여 호스트에 대한 운영 체제 업데이트 및 구성 변경을 오케스트레이션합니다. 다음이 포함됩니다.
-
컨트롤 플레인에서 머신 업그레이드를 조정하는
machine-config-controller. 모든 클러스터 노드를 모니터링하고 구성 업데이트를 오케스트레이션합니다. -
클러스터의 각 노드에서 실행되며 머신 구성에 정의된 구성으로 MachineConfigController의 지시에 따라 머신을 업데이트하는
machine-config-daemon데몬 세트. 노드가 변경사항을 감지하면 포드를 비우고 업데이트를 적용한 다음 재부팅합니다. 이러한 변경사항은 지정된 머신 구성 및 제어 kubelet 구성을 적용하는 Ignition 구성 파일의 형태로 제공됩니다. 업데이트 자체는 컨테이너로 제공됩니다. 이 프로세스는 OpenShift Container Platform 및 RHCOS 업데이트를 성공적으로 관리하는 데 핵심입니다. -
클러스터에 참여할 때 컨트롤 플레인 노드에 Ignition 구성 파일을 제공하는
machine-config-server데몬 세트.
머신 구성은 Ignition 구성의 서브 세트입니다. machine-config-daemon은 OSTree 업데이트를 수행해야 하는지 아니면 일련의 systemd kubelet 파일 변경, 구성 변경 또는 운영 체제나 OpenShift Container Platform 구성의 기타 변경 사항을 적용해야 하는지 확인하기 위해 머신 구성을 읽습니다.
노드 관리 작업을 수행할 때 KubeletConfig 사용자 정의 리소스(CR)를 생성하거나 수정합니다.
머신 구성을 변경하면 Machine Config Operator에서 변경 사항을 적용하기 위해 해당 노드를 자동으로 재부팅합니다.
머신 구성 변경사항이 적용된 후 노드가 자동 재부팅되지 않게 하려면 해당 머신 구성 풀에서 spec.paused 필드를 true로 설정하여 자동 부팅 프로세스를 일시중지해야 합니다. 일시 정지되면 spec.paused 필드를 false로 설정하고 노드가 새 구성으로 재부팅될 때까지 머신 구성 변경 사항이 적용되지 않습니다.
