5.2. OpenShift Container Platform의 머신 역할
OpenShift Container Platform은 호스트에 다른 역할을 할당합니다. 이 역할은 클러스터 내에서 머신의 기능을 정의합니다. 클러스터에는 표준 마스터 및 작업자 역할 유형의 정의가 포함됩니다.
클러스터에는 부트스트랩 역할의 정의도 포함되어 있습니다. 부트스트랩 머신은 클러스터 설치 중에만 사용되므로 해당 기능은 클러스터 설치 설명서에 설명되어 있습니다.
5.2.1. 컨트롤 플레인 및 노드 호스트 호환성
OpenShift Container Platform 버전은 컨트롤 플레인 호스트와 노드 호스트 간의 일치해야 합니다. 예를 들어 4.11 클러스터에서 모든 컨트롤 플레인 호스트는 4.11이어야 하며 모든 노드는 4.11이어야 합니다.
클러스터 업그레이드 중 일시적인 불일치가 허용됩니다. 예를 들어 OpenShift Container Platform 4.10에서 4.11로 업그레이드할 때 일부 노드는 다른 노드보다 먼저 4.11로 업그레이드됩니다. 컨트롤 플레인 호스트 및 노드 호스트의 장기간 스케핑은 이전 컴퓨팅 시스템을 버그 및 누락된 기능에 노출시킬 수 있습니다. 사용자는 가능한 한 빨리 스키핑된 컨트롤 플레인 호스트 및 노드 호스트를 해결해야 합니다.
kubelet 서비스는 kube-apiserver 보다 최신이 아니어야 하며 OpenShift Container Platform 버전이 홀수인지 여부에 따라 최대 두 개의 마이너 버전일 수 있습니다. 아래 표는 적절한 버전 호환성을 보여줍니다.
| OpenShift Container Platform 버전 | 지원되는 kubelet skew |
|---|---|
| 홀수 OpenShift Container Platform 마이너 버전 [1] | 이전 버전 중 하나 이상 |
| OpenShift Container Platform 마이너 버전 [2] | 이전 버전 2개 |
- 예를 들어 OpenShift Container Platform 4.5, 4.7, 4.9, 4.11입니다.
- 예를 들면 OpenShift Container Platform 4.6, 4.8, 4.10입니다.
5.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가 구성을 관리하고 업그레이드를 원활하게 수행할 수 있도록 머신을 그룹화하는데 사용됩니다.
5.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.11은 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
