4장. 컨트롤 플레인 아키텍처
컨트롤 플레인 시스템으로 구성된 컨트롤 플레인은 AWS 클러스터에서 Red Hat OpenShift Service를 관리합니다. 컨트롤 플레인 머신에서는 작업자 머신이라고도 하는 컴퓨팅 머신의 워크로드를 관리합니다. 클러스터 자체는 CVO(Cluster Version Operator) 작업과 개별 Operator 세트를 통해 머신의 모든 업그레이드를 관리합니다.
이 컨트롤 플레인 아키텍처는 호스팅되는 컨트롤 플레인(HCP)이 있는 AWS(ROSA)의 Red Hat OpenShift Service에서 지원되지 않습니다.
4.1. AWS의 Red Hat OpenShift Service에서 시스템 역할
AWS의 Red Hat OpenShift Service는 호스트에 다른 역할을 할당합니다. 이 역할은 클러스터 내에서 머신의 기능을 정의합니다. 클러스터에는 표준 master
및 worker
역할 유형에 대한 정의가 포함되어 있습니다.
4.1.1. 클러스터 작업자
Kubernetes 클러스터에서 작업자 노드는 Kubernetes 사용자가 요청한 실제 워크로드를 실행하고 관리합니다. 작업자 노드는 용량을 알리고 컨트롤 플레인 서비스인 스케줄러는 Pod 및 컨테이너를 시작할 노드를 결정합니다. 다음 중요한 서비스는 각 작업자 노드에서 실행됩니다.
- CRI-O - 컨테이너 엔진입니다.
- kubelet: 컨테이너 워크로드 실행 및 중지 요청을 수락하고 이행하는 서비스입니다.
- 작업자 간 Pod의 통신을 관리하는 서비스 프록시입니다.
- 컨테이너를 생성하고 실행하는 runC 또는 crun 하위 수준 컨테이너 런타임입니다.
기본 runC 대신 crun을 활성화하는 방법에 대한 자세한 내용은 ContainerRuntimeConfig
CR 생성 설명서를 참조하십시오.
AWS의 Red Hat OpenShift Service에서 컴퓨팅 머신 세트는 작업자
시스템 역할이 할당된 컴퓨팅 머신을 제어합니다. worker
역할 드라이브가 있는 머신은 자동 스케일링하는 특정 머신 풀이 관리하는 워크로드를 컴퓨팅합니다. AWS의 Red Hat OpenShift Service에는 여러 머신 유형을 지원할 수 있는 용량이 있으므로 worker
역할의 시스템은 컴퓨팅 머신으로 분류됩니다. 이 릴리스에서는 기본 유형의 컴퓨팅 머신이 작업자 머신이기 때문에 작업자 머신과 컴퓨팅 머신이라는 용어는 서로 바꿔 사용할 수 있습니다. 향후 AWS의 Red Hat OpenShift Service 버전에서는 인프라 머신과 같은 다양한 유형의 컴퓨팅 머신이 기본적으로 사용될 수 있습니다.
컴퓨팅 머신 세트는 machine-api
네임스페이스에서 컴퓨팅 머신 리소스의 그룹입니다. 컴퓨팅 머신 세트는 특정 클라우드 공급자에서 새 컴퓨팅 머신을 시작하도록 설계된 구성입니다. 반대로 MCP(Machine config pool)는 MCO(Machine Config Operator) 네임스페이스의 일부입니다. MCP는 MCO가 구성을 관리하고 업그레이드를 원활하게 수행할 수 있도록 머신을 그룹화하는데 사용됩니다.
4.1.2. 클러스터 컨트롤 플레인
Kubernetes 클러스터에서 master 노드는 Kubernetes 클러스터를 제어하는 데 필요한 서비스를 실행합니다. AWS의 Red Hat OpenShift Service에서 컨트롤 플레인은 마스터
머신 역할이 있는 컨트롤 플레인 시스템으로 구성됩니다. 여기에는 AWS 클러스터에서 Red Hat OpenShift Service를 관리하기 위한 Kubernetes 서비스 이상의 것이 포함되어 있습니다.
대부분의 AWS 클러스터에서 Red Hat OpenShift Service는 컨트롤 플레인 시스템은 일련의 독립 실행형 머신 API 리소스로 정의됩니다. 컨트롤 플레인은 컨트롤 플레인 머신 세트로 관리됩니다. 모든 컨트롤 플레인 시스템을 삭제하고 클러스터를 중단하지 못하도록 컨트롤 플레인 시스템에 추가 제어가 적용됩니다.
단일 가용성 영역 클러스터 및 여러 가용성 영역 클러스터에는 최소 3개의 컨트롤 플레인 노드가 필요합니다.
컨트롤 플레인의 Kubernetes 카테고리에 속하는 서비스에는 Kubernetes API 서버, etcd, Kubernetes 컨트롤러 관리자 및 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 서비스도 있습니다.
구성 요소 | 설명 |
---|---|
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 토큰과 같은 AWS의 Red Hat OpenShift Service에 인증할 데이터를 검증하고 구성합니다. OpenShift OAuth API 서버는 Cluster Authentication Operator가 관리합니다. |
OpenShift OAuth 서버 | 사용자는 OpenShift OAuth 서버에서 토큰을 요청하여 API에 자신을 인증합니다. OpenShift OAuth 서버는 Cluster Authentication Operator가 관리합니다. |
컨트롤 플레인 시스템에서 이러한 서비스 중 일부는 systemd 서비스로 실행되는 반면 다른 서비스는 정적 Pod로 실행됩니다.
시스템 서비스는 특정 시스템이 시작된 직후에 항상 필요한 서비스에 적합합니다. 컨트롤 플레인 시스템의 경우 원격 로그인을 허용하는 sshd가 포함됩니다. 다음과 같은 서비스도 포함됩니다.
- 컨테이너를 실행하고 관리하는 CRI-O 컨테이너 엔진(crio). AWS 4의 Red Hat OpenShift Service는 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