6.2. OpenShift Container Platform의 머신 역할
OpenShift Container Platform은 호스트에 다른 역할을 할당합니다. 이 역할은 클러스터 내에서 머신의 기능을 정의합니다. 클러스터에는 표준 master 및 worker 역할 유형에 대한 정의가 포함되어 있습니다.
클러스터에는 bootstrap 역할의 정의도 포함되어 있습니다. 부트스트랩 머신은 클러스터 설치 중에만 사용되므로 해당 기능은 클러스터 설치 설명서에 설명되어 있습니다.
6.2.1. 컨트롤 플레인 및 노드 호스트 호환성
OpenShift Container Platform 버전은 컨트롤 플레인 호스트와 노드 호스트 간에 일치해야 합니다. 예를 들어 4.13 클러스터에서는 모든 컨트롤 플레인 호스트가 4.13이고 모든 노드가 4.13이어야 합니다.
클러스터 업그레이드 중에 일시적인 불일치가 허용됩니다. 예를 들어 OpenShift Container Platform 4.12에서 4.13으로 업그레이드할 때 일부 노드는 4.13로 업그레이드됩니다. 컨트롤 플레인 호스트 및 노드 호스트가 오래 걸리는 경우 이전 컴퓨팅 머신이 버그 및 누락된 기능에 노출될 수 있습니다. 사용자는 가능한 한 빨리 스쿼드 컨트롤 플레인 호스트 및 노드 호스트를 확인해야 합니다.
kubelet 서비스는 kube-apiserver 보다 최신이 아니어야 하며 OpenShift Container Platform 버전이 홀수인지 여부에 따라 최대 두 개의 마이너 버전일 수 있습니다. 아래 표에서는 적절한 버전 호환성을 보여줍니다.
| OpenShift Container Platform 버전 | 지원되는 kubelet skew |
|---|---|
| 홀수의 OpenShift Container Platform 마이너 버전 [1] | 최대 하나의 이전 버전 |
| 짝수의 OpenShift Container Platform 마이너 버전 [2] | 최대 두개의 이전 버전 |
- 예를 들면 OpenShift Container Platform 4.11, 4.13입니다.
- 예를 들면 OpenShift Container Platform 4.10, 4.12입니다.
6.2.2. 클러스터 작업자
Kubernetes 클러스터에서 작업자 노드는 Kubernetes 사용자가 요청한 실제 워크로드가 실행되고 관리되는 위치입니다. 작업자 노드는 용량을 알리고 컨트롤 플레인 서비스에서 Pod 및 컨테이너를 시작할 노드를 결정합니다. 컨테이너 엔진인 CRI-O를 포함하여 각 작업자 노드에서 중요한 서비스가 실행됩니다. 컨테이너 워크로드 실행 및 중지 요청을 수락 및 수행하는 서비스인 Kubelet, 작업자 간의 Pod 통신을 관리하는 서비스 프록시, 컨테이너를 생성하고 실행하는 runC 또는 crun 하위 수준 컨테이너 런타임입니다.
기본 runC 대신 crun을 활성화하는 방법에 대한 자세한 내용은 ContainerRuntimeConfig CR 생성 설명서를 참조하십시오.
OpenShift Container Platform에서 컴퓨팅 머신 세트는 worker 머신 역할이 할당된 컴퓨팅 머신을 제어합니다. worker 역할 드라이브가 있는 머신은 자동 스케일링하는 특정 머신 풀이 관리하는 워크로드를 컴퓨팅합니다. OpenShift Container Platform에는 여러 머신 유형을 지원할 수 있는 용량이 있으므로 worker 역할의 시스템은 compute 머신으로 분류됩니다. 이 릴리스에서는 기본 유형의 컴퓨팅 머신이 작업자 머신이기 때문에 작업자 머신과 컴퓨팅 머신이라는 용어는 서로 바꿔 사용할 수 있습니다. 이후 버전의 OpenShift Container Platform에서는 기본적으로 인프라 머신과 같은 다른 유형의 컴퓨팅 머신이 사용될 수 있습니다.
컴퓨팅 머신 세트는 machine-api 네임스페이스에서 컴퓨팅 머신 리소스의 그룹입니다. 컴퓨팅 머신 세트는 특정 클라우드 공급자에서 새 컴퓨팅 머신을 시작하도록 설계된 구성입니다. 반대로 MCP(Machine config pool)는 MCO(Machine Config Operator) 네임스페이스의 일부입니다. MCP는 MCO가 구성을 관리하고 업그레이드를 원활하게 수행할 수 있도록 머신을 그룹화하는데 사용됩니다.
6.2.3. 클러스터 컨트롤 플레인
Kubernetes 클러스터에서 master 노드는 Kubernetes 클러스터를 제어하는 데 필요한 서비스를 실행합니다. OpenShift Container Platform에서 컨트롤 플레인은 master 머신 역할이 있는 컨트롤 플레인 시스템으로 구성됩니다. 여기에는 OpenShift Container Platform 클러스터 관리를 위한 Kubernetes 서비스 외에도 많은 것이 포함되어 있습니다.
대부분의 OpenShift Container Platform 클러스터의 경우 컨트롤 플레인 시스템은 일련의 독립 실행형 머신 API 리소스로 정의됩니다. 지원되는 클라우드 공급자 및 OpenShift Container Platform 버전 조합의 경우 컨트롤 플레인 머신 세트를 사용하여 컨트롤 플레인을 관리할 수 있습니다. 모든 컨트롤은 모든 컨트롤 플레인 시스템을 삭제하고 클러스터를 중단하지 못하도록 컨트롤 플레인 머신에 추가 제어가 적용됩니다.
모든 프로덕션 배포에 정확히 세 개의 컨트롤 플레인 노드를 사용해야 합니다.
컨트롤 플레인의 Kubernetes 카테고리에 속하는 서비스에는 Kubernetes API 서버, etcd, Kubernetes 컨트롤러 관리자 및 Kubernetes 스케줄러가 포함됩니다.
표 6.1. 컨트롤 플레인에서 실행되는 Kubernetes 서비스
| 구성 요소 | 설명 |
|---|---|
| Kubernetes API 서버 | Kubernetes API 서버는 포드, 서비스 및 복제 컨트롤러의 데이터를 검증하고 구성합니다. 클러스터의 공유 상태에 대한 초점도 제공합니다. |
| etcd | etcd는 영구 컨트롤 플레인 상태를 저장하고 다른 구성 요소는 etcd에서 변경 사항을 감시하여 지정된 상태로 전환합니다. |
| Kubernetes 컨트롤러 관리자 | Kubernetes 컨트롤러 관리자는 etcd에서 복제, 네임스페이스 및 서비스 계정 컨트롤러 오브젝트와 같은 오브젝트의 변경사항을 감시한 다음 API를 사용하여 지정된 상태를 적용합니다. 이러한 여러 프로세스는 한 번에 하나의 활성 리더가 있는 클러스터를 생성합니다. |
| Kubernetes 스케줄러 | Kubernetes 스케줄러는 할당된 노드가 없는 새로 생성된 Pod를 감시하고 Pod를 호스팅할 수 있는 최상의 노드를 선택합니다. |
OpenShift API 서버, OpenShift 컨트롤러 관리자 및 OpenShift OAuth API 서버 및 OpenShift OAuth 서버를 포함하는 컨트롤 플레인에서 실행되는 OpenShift 서비스도 있습니다.
표 6.2. 컨트롤 플레인에서 실행되는 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 서비스로 실행되는 반면 다른 서비스는 정적 Pod로 실행됩니다.
시스템 서비스는 특정 시스템이 시작된 직후에 항상 필요한 서비스에 적합합니다. 컨트롤 플레인 시스템의 경우 원격 로그인을 허용하는 sshd가 포함됩니다. 다음과 같은 서비스도 포함됩니다.
- 컨테이너를 실행하고 관리하는 CRI-O 컨테이너 엔진(crio). OpenShift Container Platform 4.13에서는 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
