아키텍처

이 용어집은 아키텍처 콘텐츠에 사용되는 일반적인 용어를 정의합니다. 이 용어는 OpenShift Container Platform 아키텍처를 효과적으로 이해하는 데 도움이 됩니다.

클러스터 관리자는 OpenShift Container Platform 설치 프로그램을 사용하여 다음 방법 중 하나를 사용하여 클러스터를 설치하고 배포할 수 있습니다.

컨트롤 플레인 은 작업자 노드와 클러스터의 Pod를 관리합니다. MCP(머신 구성 풀)를 사용하여 노드를 구성할 수 있습니다. MCP는 처리하는 리소스를 기반으로 하는 컨트롤 플레인 구성 요소 또는 사용자 워크로드와 같은 머신 그룹입니다. OpenShift Container Platform은 호스트에 다양한 역할을 할당합니다. 이러한 역할은 클러스터에서 시스템의 기능을 정의합니다. 클러스터에는 표준 컨트롤 플레인 및 작업자 역할 유형의 정의가 포함되어 있습니다.

Operator를 사용하여 컨트롤 플레인에서 서비스를 패키지, 배포 및 관리할 수 있습니다. Operator는 다음 서비스를 제공하기 때문에 OpenShift Container Platform의 중요한 구성 요소입니다.

개발자는 다양한 툴, 방법 및 형식을 사용하여 고유한 요구 사항에 따라 컨테이너화된 애플리케이션을 개발할 수 있습니다. 예를 들면 다음과 같습니다.

Kubernetes 매니페스트를 생성하여 Git 리포지토리에 저장할 수도 있습니다. Kubernetes는 포드라는 기본 장치에서 작동합니다. 포드는 클러스터에서 실행 중인 프로세스의 단일 인스턴스입니다. Pod에는 하나 이상의 컨테이너가 포함될 수 있습니다. 일련의 포드 및 해당 액세스 정책을 그룹화하여 서비스를 생성할 수 있습니다. 서비스에서는 포드가 생성 및 삭제될 때 사용할 다른 애플리케이션에 영구 내부 IP 주소 및 호스트 이름을 제공합니다. Kubernetes는 애플리케이션 유형을 기반으로 워크로드를 정의합니다.

클러스터 관리자는 다음 RHCOS(Red Hat Enterprise Linux CoreOS) 작업을 수행할 수 있습니다.

OpenShift Container Platform 설치 프로그램은 클러스터를 배포하는 데 필요한 Ignition 구성 파일을 생성합니다. RHCOS(Red Hat Enterprise Linux CoreOS)는 초기 구성 중에 Ignition을 사용하여 분할, 포맷, 파일 작성, 사용자 구성 등의 일반적인 디스크 작업을 수행합니다. 처음 부팅하는 동안 Ignition은 설치 미디어 또는 사용자가 지정한 위치에서 구성을 읽고 해당 구성을 머신에 적용합니다.

Ignition 작동 방식, OpenShift Container Platform 클러스터의 RHCOS(Red Hat Enterprise Linux CoreOS) 프로세스, Ignition 구성 파일을 보고, 설치 후 Ignition 구성을 변경할 수 있습니다.

승인 플러그인을 사용하여 OpenShift Container Platform의 기능을 규제할 수 있습니다. 리소스 요청이 인증되고 승인된 후 승인 플러그인은 마스터 API에 대한 리소스 요청을 가로채서 리소스 요청의 유효성을 검사하고 확장 정책이 준수되도록 합니다. 허용 플러그인은 보안 정책, 리소스 제한 또는 구성 요구 사항을 적용하는 데 사용됩니다.

OpenShift Container Platform은 컨테이너화된 애플리케이션을 개발하고 실행하기 위한 플랫폼입니다. 애플리케이션 및 애플리케이션을 지원하는 데이터센터를 몇 대의 머신 및 애플리케이션에서 수백만 클라이언트에 서비스를 제공하는 수천 대의 컴퓨터로 확장 가능하도록 설계되었습니다.

Kubernetes에 기반을 둔 OpenShift Container Platform은 대규모 통신, 스트리밍 비디오, 게임, 뱅킹 및 기타 애플리케이션의 엔진 역할을 하는 동일한 기술을 통합합니다. Red Hat의 오픈 기술로 구현하면 컨테이너화된 애플리케이션을 단일 클라우드에서 온프레미스 및 다중 클라우드 환경으로 확장할 수 있습니다.

2.1.3. OpenShift Container Platform 개요

OpenShift Container Platform은 Kubernetes에 다음과 같은 향상된 기능을 포함한 엔터프라이즈급 개선사항을 제공합니다.

• 하이브리드 클라우드 배포. 다양한 퍼블릭 클라우드 플랫폼 또는 데이터센터에 OpenShift Container Platform 클러스터를 배포할 수 있습니다.
• 통합된 Red Hat 기술. OpenShift Container Platform의 주요 구성 요소는 RHEL(Red Hat Enterprise Linux) 및 관련 Red Hat 기술을 기반으로 합니다. OpenShift Container Platform은 Red Hat의 엔터프라이즈급 소프트웨어에 대한 강력한 테스트 및 인증 이니셔티브의 이점을 제공합니다.
• 오픈 소스 개발 모델. 개발은 공개적으로 완료되었으며 소스 코드는 공개 소프트웨어 리포지토리에서 구할 수 있습니다. 이 오픈 협업을 통해 빠른 혁신과 개발을 촉진할 수 있습니다.

Kubernetes는 애플리케이션 관리에 뛰어나지만 플랫폼 수준 요구사항 또는 배포 프로세스를 지정하거나 관리하지는 않습니다. 강력하고 유연한 플랫폼 관리 도구 및 프로세스는 OpenShift Container Platform 4.8이 제공하는 중요한 이점입니다. 다음 섹션에서는 OpenShift Container Platform의 고유한 기능과 이점에 관해 설명합니다.

2.1.3.1. 사용자 정의 운영 체제

OpenShift Container Platform은 OpenShift Container Platform에서 컨테이너화된 애플리케이션을 실행하도록 특별히 설계된 컨테이너 지향 운영 체제인 RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하며 새로운 도구와 함께 작업하여 빠른 설치, Operator 기반 관리 및 단순화된 업그레이드를 제공합니다.

RHCOS는 다음을 포함합니다.

• OpenShift Container Platform이 머신을 처음 시작하고 구성하기 위한 최초 부팅 시스템 구성으로 사용하는 Ignition
• 운영 체제와 밀접하게 통합되어 효율적이고 최적화된 Kubernetes 환경을 제공하는 Kubernetes 기본 컨테이너 런타임 구현인 CRI-O. CRI-O는 컨테이너 실행, 중지 및 다시 시작 기능을 제공합니다. OpenShift Container Platform 3에서 사용하던 Docker Container Engine을 완전히 대체합니다.
• 컨테이너 시작 및 모니터링을 담당하는 Kubernetes의 기본 노드 에이전트인 Kubelet

OpenShift Container Platform 4.8에서는 모든 컨트롤 플레인 머신에 RHCOS를 사용해야 하지만, 작업자 머신이라고도 하는 컴퓨팅 머신의 운영 체제로 RHEL(Red Hat Enterprise Linux)을 사용할 수 있습니다. RHEL 작업자를 사용하도록 선택한 경우 모든 클러스터 머신에 RHCOS를 사용할 때보다 시스템 유지보수를 더 많이 수행해야 합니다.

2.1.3.2. 단순화된 설치 및 업데이트 프로세스

OpenShift Container Platform 4.8을 사용하면 적절한 권한이 있는 계정이 있는 경우 단일 명령을 실행하고 몇 가지 값을 제공하여 지원되는 클라우드에 프로덕션 클러스터를 배포할 수 있습니다. 지원되는 플랫폼을 사용하는 경우 클라우드 설치를 사용자 정의하거나 데이터센터에 클러스터를 설치할 수도 있습니다.

모든 머신, 업데이트 또는 업그레이드에 RHCOS를 사용하는 클러스터의 경우 OpenShift Container Platform은 고도로 자동화된 간단한 프로세스입니다. OpenShift Container Platform은 운영 체제 자체를 포함하여 각 머신에서 실행되는 시스템 및 서비스를 중앙 컨트롤 플레인에서 완전히 제어하므로 업그레이드가 자동 이벤트가 되도록 설계되었습니다. 클러스터에 RHEL 작업자 머신이 포함된 경우 컨트롤 플레인은 간소화된 업데이트 프로세스를 통해 이점을 얻을 수 있지만 RHEL 머신을 업그레이드하려면 추가 작업을 수행해야 합니다.

2.1.3.3. 기타 주요 기능

Operator는 OpenShift Container Platform 4.8 코드 베이스의 기본 단위이자 애플리케이션 및 애플리케이션에서 사용할 소프트웨어 구성 요소를 편리하게 배포할 수 있는 방법입니다. OpenShift Container Platform에서 Operator는 플랫폼 기반 역할을 하며 운영 체제 및 컨트롤 플레인 애플리케이션을 수동으로 업그레이드할 필요가 없습니다. Cluster Version Operator 및 Machine Config Operator와 같은 OpenShift Container Platform Operator를 사용하면 중요한 구성 요소를 클러스터 전체에서 간단하게 관리할 수 있습니다.

OLM(Operator Lifecycle Manager)과 OperatorHub에서는 애플리케이션을 개발 및 배포하는 사용자에게 Operator를 저장하고 배포하는 기능을 제공합니다.

Red Hat Quay Container Registry는 대부분의 컨테이너 이미지와 Operator에 OpenShift Container Platform 클러스터를 제공하는 Quay.io 컨테이너 레지스트리입니다. Quay.io는 수백만 개의 이미지와 태그를 저장하는 Red Hat Quay의 공개 레지스트리 버전입니다.

OpenShift Container Platform의 Kubernetes의 기타 향상된 기능에는 소프트웨어 정의 네트워킹(SDN), 인증, 로그 집계, 모니터링 및 라우팅 개선이 포함됩니다. OpenShift Container Platform에서는 포괄적인 웹 콘솔과 사용자 정의 OpenShift CLI(oc) 인터페이스도 제공합니다.

2.1.3.4. OpenShift Container Platform 라이프사이클

다음 그림에서는 기본 OpenShift Container Platform 라이프사이클을 보여줍니다.

• OpenShift Container Platform 클러스터 생성
• 클러스터 관리
• 애플리케이션 개발 및 배포
• 애플리케이션 스케일링

그림 2.1. 상위 레벨 OpenShift Container Platform 개요

OpenShift Container Platform 설치 프로그램에서는 유연성을 제공합니다. 설치 프로그램을 사용하면 설치 프로그램이 프로비저닝하고 클러스터가 유지보수하는 인프라에 클러스터를 배포하거나 준비하고 유지보수하는 인프라에 클러스터를 배포할 수 있습니다.

이 두 가지 기본 유형의 OpenShift Container Platform 클러스터는 종종 설치 관리자 프로비저닝 인프라 클러스터 및 사용자 프로비저닝 인프라 클러스터라고 합니다.

두 유형의 클러스터에는 모두 다음과 같은 특징이 있습니다.

동일한 설치 프로그램을 사용하여 두 유형의 클러스터를 모두 배포합니다. 설치 프로그램에서 생성된 주요 자산은 부트스트랩, 마스터 및 작업자 머신의 Ignition 구성 파일입니다. 이 세 가지 구성과 올바르게 구성된 인프라를 사용하면 OpenShift Container Platform 클러스터를 시작할 수 있습니다.

OpenShift Container Platform 설치 프로그램은 일련의 대상 및 종속 항목을 사용하여 클러스터 설치를 관리합니다. 설치 프로그램에는 달성해야 할 대상 세트가 있으며 각 대상에는 종속 항목 세트가 있습니다. 각 대상은 고유한 종속 항목에만 관련되므로 여러 대상이 병렬로 수행되도록 설치 프로그램이 작동할 수 있습니다. 궁극적인 목표는 실행 중인 클러스터입니다. 설치 프로그램은 명령을 실행하지 않고 종속 항목을 충족함으로써 명령을 다시 작성하기 위해 명령을 실행하는 대신 기존 구성 요소를 인식하고 사용할 수 있습니다.

다음 다이어그램에서는 설치 대상 및 종속 항목의 서브 세트를 보여줍니다.

그림 3.1. OpenShift Container Platform 설치 대상 및 종속 항목

설치 후 각 클러스터 머신에서는 RHCOS(Red Hat Enterprise Linux CoreOS)를 운영 체제로 사용합니다. RHCOS는 RHEL(Red Hat Enterprise Linux)의 변경 불가능한 컨테이너 호스트 버전이며 기본적으로 SELinux가 활성화된 RHEL 커널을 제공합니다. 여기에는 Kubernetes 노드 에이전트인 kubelet 및 Kubernetes에 최적화된 CRI-O 컨테이너 런타임이 포함됩니다.

OpenShift Container Platform 4.8 클러스터의 모든 컨트롤 플레인 시스템은 Ignition이라는 중요한 최초 부팅 프로비저닝 도구를 포함하는 RHCOS를 사용해야 합니다. 이 도구를 사용하면 클러스터가 머신을 구성할 수 있습니다. 운영 체제 업데이트는 Operator가 클러스터 전체에서 롤아웃한 컨테이너 이미지에 임베드된 Atomic OSTree 리포지토리로 제공됩니다. 실제 운영 체제 변경은 rpm-ostree를 사용하여 각 머신에서 원자 작업으로 수행됩니다. 이러한 기술을 사용하면 OpenShift Container Platform에서 전체 플랫폼을 최신 상태로 유지하는 내부 업그레이드를 통해 클러스터의 다른 애플리케이션을 관리하는 것처럼 운영 체제를 관리할 수 있습니다. 이러한 내부 업데이트는 운영 팀의 부담을 줄일 수 있습니다.

모든 클러스터 머신의 운영 체제로 RHCOS를 사용하는 경우 클러스터가 운영 체제를 포함한 구성 요소 및 머신의 모든 측면을 관리합니다. 그러면 설치 프로그램 및 Machine Config Operator만 머신을 변경할 수 있습니다. 설치 프로그램에서는 Ignition 구성 파일을 사용하여 각 머신의 정확한 상태를 설정하고 Machine Config Operator는 설치 후 새 인증서 또는 키 적용과 같은 머신에 대한 추가 변경을 완료합니다.

3.1.2. 설치 프로세스

OpenShift Container Platform 클러스터를 설치할 때 OpenShift Cluster Manager 사이트의 해당 인프라 공급자 페이지에서 설치 프로그램을 다운로드합니다. 이 사이트에서는 다음을 관리합니다.

• 계정용 REST API
• 필수 구성 요소를 얻는 데 사용하는 풀 시크릿인 레지스트리 토큰
• 사용 지표 수집이 용이하도록 클러스터 ID를 Red Hat 계정에 연결하는 클러스터 등록

OpenShift Container Platform 4.8에서 설치 프로그램은 자산 세트에서 일련의 파일 변환을 수행하는 Go 바이너리 파일입니다. 설치 프로그램과 상호 작용하는 방법은 설치 유형에 따라 다릅니다.

• 설치 관리자 프로비저닝 인프라가 있는 클러스터의 경우 인프라 부트스트랩 및 프로비저닝을 직접 수행하는 대신 설치 프로그램에 위임합니다. 설치 프로그램은 클러스터를 지원하는 데 필요한 모든 네트워킹, 머신 및 운영 체제를 생성합니다.
• 클러스터의 인프라를 프로비저닝하고 관리하는 경우 부트스트랩 머신, 네트워킹, 부하 분산, 스토리지 및 개별 클러스터 머신을 포함한 모든 클러스터 인프라 및 리소스를 제공해야 합니다.

설치하는 동안 install-config.yaml이라는 설치 구성 파일, Kubernetes 매니페스트 및 머신 유형에 맞는 Ignition 구성 파일의 세 가지 파일 세트를 사용합니다.

중요

설치 중에 기본 RHCOS 운영 체제를 제어하는 Kubernetes 및 Ignition 구성 파일을 수정할 수 있습니다. 그러나 이러한 오브젝트를 수정한 내용이 적합한지 확인할 수 있는 유효성 검사는 없습니다. 이러한 오브젝트를 수정하면 클러스터가 작동하지 않을 수 있습니다. 이 위험 때문에 문서화된 절차를 따르거나 Red Hat 지원 부서에서 지시하지 않는 한 Kubernetes 및 Ignition 구성 파일 수정은 지원되지 않습니다.

설치 구성 파일은 Kubernetes 매니페스트로 변환된 다음 매니페스트가 Ignition 구성 파일로 래핑됩니다. 설치 프로그램은 이러한 Ignition 구성 파일을 사용하여 클러스터를 생성합니다.

설치 프로그램을 실행할 때 설치 구성 파일이 모두 제거되므로 다시 사용하려는 모든 구성 파일을 백업하십시오.

중요

설치 중에 설정한 매개변수는 수정할 수 없지만 설치 후에는 많은 클러스터 속성을 수정할 수 있습니다.

설치 관리자가 프로비저닝한 인프라를 사용하는 설치 프로세스

기본 설치 유형에서는 설치 관리자 프로비저닝 인프라를 사용합니다. 기본적으로 설치 프로그램은 설치 마법사 역할을 하여 자체적으로 결정할 수 없는 값을 입력하라는 메시지를 표시하고 나머지 매개변수에 대한 적절한 기본값을 제공합니다. 고급 인프라 시나리오를 지원하도록 설치 프로세스를 사용자 정의할 수도 있습니다. 설치 프로그램은 클러스터의 기본 인프라를 프로비저닝합니다.

표준 클러스터 또는 사용자 정의된 클러스터를 설치할 수 있습니다. 표준 클러스터에서는 클러스터를 설치하는 데 필요한 최소 세부 정보를 제공합니다. 사용자 지정 클러스터를 사용하면 컨트롤 플레인에서 사용하는 머신 수, 클러스터가 배포하는 가상 머신 유형 또는 Kubernetes 서비스 네트워크의 CIDR 범위와 같은 플랫폼에 대한 세부 정보를 지정할 수 있습니다.

가능하면 이 기능을 사용하여 클러스터 인프라를 프로비저닝 및 유지보수하지 않아도 됩니다. 다른 모든 환경에서는 설치 프로그램을 사용하여 클러스터 인프라를 프로비저닝하는 데 필요한 자산을 생성합니다.

OpenShift Container Platform은 설치 프로그램에서 프로비저닝한 인프라 클러스터를 통해 운영 체제 자체를 포함하여 클러스터의 모든 측면을 관리합니다. 각 머신은 결합하는 클러스터에서 호스팅되는 리소스를 참조하는 구성으로 부팅됩니다. 이 구성을 사용하면 업데이트가 적용될 때 클러스터가 자체적으로 관리될 수 있습니다.

사용자 프로비저닝 인프라를 사용하는 설치 프로세스

제공하는 인프라에 OpenShift Container Platform도 설치할 수 있습니다. 설치 프로그램을 사용하여 클러스터 인프라를 프로비저닝하고 클러스터 인프라를 생성한 다음 제공한 인프라에 클러스터를 배포하는 데 필요한 자산을 생성합니다.

설치 프로그램이 프로비저닝한 인프라를 사용하지 않는 경우 다음을 포함하여 클러스터 자원을 직접 관리하고 유지보수해야 합니다.

• 클러스터를 구성하는 컨트롤 플레인 및 컴퓨팅 머신의 기본 인프라
• 로드 밸런서
• DNS 레코드 및 필수 서브넷을 포함한 클러스터 네트워킹
• 클러스터 인프라 및 애플리케이션용 스토리지

클러스터가 사용자 프로비저닝 인프라를 사용하는 경우 RHEL 컴퓨팅 머신을 클러스터에 추가할 수 있습니다.

설치 프로세스 세부사항

클러스터의 각 머신에는 프로비저닝 시 클러스터에 대한 정보가 필요하므로 OpenShift Container Platform은 초기 구성 중에 임시 부트스트랩 머신을 사용하여 필요한 정보를 영구 컨트롤 플레인에 제공합니다. 클러스터 생성 방법을 설명하는 Ignition 구성 파일을 사용하여 부팅됩니다. 부트스트랩 머신은 컨트롤 플레인을 구성하는 컨트롤 플레인 머신 (마스터 머신이라고도 함)을 생성합니다. 그런 다음 컨트롤 플레인 시스템에서는 작업자 머신이라고도 하는 컴퓨팅 머신을 만듭니다. 다음 그림은 이 프로세스를 보여줍니다.

그림 3.2. 부트스트랩, 컨트롤 플레인 및 컴퓨팅 시스템 생성

클러스터 머신이 초기화되면 부트스트랩 머신이 손상됩니다. 모든 클러스터에서는 부트스트랩 프로세스를 사용하여 클러스터를 초기화하지만, 클러스터의 인프라를 프로비저닝하는 경우 많은 단계를 수동으로 완료해야 합니다.

중요

• 설치 프로그램에서 생성하는 Ignition 구성 파일에 24시간 후에 만료되는 인증서가 포함되어 있습니다. 이 인증서는 그 후에 갱신됩니다. 인증서를 갱신하기 전에 클러스터가 종료되고 24시간이 지난 후에 클러스터가 다시 시작되면 클러스터는 만료된 인증서를 자동으로 복구합니다. 예외적으로 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 자세한 내용은 Recovering from expired control plane certificates 문서를 참조하십시오.
• 클러스터를 설치한 후 24시간에서 22시간까지의 인증서가 교체되기 때문에 생성된 후 12시간 이내에 Ignition 구성 파일을 사용하는 것이 좋습니다. 12시간 이내에 Ignition 구성 파일을 사용하면 설치 중에 인증서 업데이트가 실행되는 경우 설치 실패를 방지할 수 있습니다.

클러스터 부트스트랩에는 다음 단계가 포함됩니다.

1. 부트스트랩 머신이 부팅되고 컨트롤 플레인 머신을 부팅하는 데 필요한 원격 리소스 호스팅이 시작됩니다. (인프라를 프로비저닝할 경우 수동 조작 필요)
2. 부트스트랩 머신은 단일 노드 etcd 클러스터와 임시 Kubernetes 컨트롤 플레인을 시작합니다.
3. 컨트롤 플레인 머신은 부트스트랩 머신에서 원격 리소스를 가져오고 부팅을 완료합니다. (인프라를 프로비저닝할 경우 수동 조작 필요)
4. 임시 컨트롤 플레인은 프로덕션 컨트롤러 플레인을 프로덕션 컨트롤 플레인 머신에 예약합니다.
5. CVO(Cluster Version Operator)가 온라인 상태가 되어 etcd Operator를 설치합니다. etcd Operator는 모든 컨트롤 플레인 노드에서 etcd를 확장합니다.
6. 임시 컨트롤 플레인이 종료되고 제어를 프로덕션 컨트롤 플레인에 전달합니다.
7. 부트스트랩 머신은 OpenShift Container Platform 구성 요소를 프로덕션 컨트롤 플레인에 주입합니다.
8. 설치 프로그램이 부트스트랩 머신을 종료합니다. (인프라를 프로비저닝할 경우 수동 조작 필요)
9. 컨트롤 플레인이 컴퓨팅 노드를 설정합니다.
10. 컨트롤 플레인은 일련의 Operator 형태로 추가 서비스를 설치합니다.

이 부트스트랩 프로세스의 결과는 OpenShift Container Platform 클러스터가 실행 중인 것입니다. 그런 다음 클러스터는 지원되는 환경에서 컴퓨팅 머신 생성을 포함하여 일상적인 작업에 필요한 나머지 구성 요소를 다운로드하고 구성합니다.

설치 범위

OpenShift Container Platform 설치 프로그램의 범위는 의도적으로 한정됩니다. 단순성과 성공을 보장하도록 설계되었습니다. 설치가 완료된 후 많은 추가 구성 작업을 완료할 수 있습니다.

추가 리소스

• OpenShift Container Platform 구성 리소스에 대한 자세한 내용은 사용 가능한 클러스터 사용자 정의를 참조하십시오.

OSUS(OpenShift Update Service)는 RHCOS(Red Hat Enterprise Linux CoreOS)를 포함하여 OpenShift Container Platform에 대한 업데이트를 제공합니다. 구성 요소 Operator의 정점과 이를 연결하는 에지를 포함하는 그래프 또는 다이어그램을 제공합니다. 그래프의 에지에는 안전하게 업데이트할 수 있는 버전이 표시됩니다. 정점은 관리형 클러스터 구성 요소의 상태를 지정하는 업데이트 페이로드입니다.

클러스터의 CVO (Cluster Version Operator)는 OpenShift Update Service를 확인하여 현재 구성 요소 버전 및 그래프의 정보를 기반으로 유효한 업데이트 및 업데이트 경로를 확인합니다. 업데이트를 요청하면 CVO는 해당 업데이트에 릴리스 이미지를 사용하여 클러스터를 업데이트합니다. 릴리스 아티팩트는 Quay에서 컨테이너 이미지로 호스팅됩니다.

OpenShift Update Service가 호환 가능한 업데이트만 제공할 수 있도록 자동화를 지원하는 버전 확인 파이프 라인이 제공됩니다. 각 릴리스 아티팩트는 지원되는 클라우드 플랫폼 및 시스템 아키텍처 및 기타 구성 요소 패키지와의 호환성 여부를 확인합니다. 파이프 라인에서 적용 가능한 버전이 있음을 확인한 후 OpenShift Update Service는 해당 버전 업데이트를 사용할 수 있음을 알려줍니다.

연속 업데이트 모드에서는 두 개의 컨트롤러가 실행됩니다. 하나의 컨트롤러는 페이로드 매니페스트를 지속적으로 업데이트하여 매니페스트를 클러스터에 적용한 다음 Operator의 제어된 롤아웃 상태를 출력하여 사용 가능한지, 업그레이드했는지 또는 실패했는지의 여부를 나타냅니다. 두 번째 컨트롤러는 OpenShift Update Service를 폴링하여 업데이트를 사용할 수 있는지 확인합니다.

업데이트 프로세스 중에 MCO (Machine Config Operator)는 새 구성을 클러스터 머신에 적용합니다. MCO는 머신 설정 풀의 maxUnavailable 필드에 지정된 노드 수를 제한하고 이를 사용할 수없는 것으로 표시합니다. 기본적으로 이 값은 1로 설정됩니다. MCO는 새 설정을 적용하여 컴퓨터를 다시 시작합니다.

RHEL (Red Hat Enterprise Linux) 머신을 작업자로 사용하는 경우 먼저 시스템에서 OpenShift API를 업데이트해야하기 때문에 MCO는 이 머신에서 kubelet을 업데이트하지 않습니다.

새 버전의 사양이 이전 kubelet에 적용되므로 RHEL 머신을 Ready 상태로 되돌릴 수 없습니다. 컴퓨터를 사용할 수 있을 때까지 업데이트를 완료할 수 없습니다. 그러나 사용 불가능한 최대 노드 수를 설정하면 사용할 수 없는 머신의 수가 이 값을 초과하지 않는 경우에도 정상적인 클러스터 작업을 계속할 수 있습니다.

OpenShift Update Service는 Operator 및 하나 이상의 애플리케이션 인스턴스로 구성됩니다.

Operator의 관리 상태는 Operator가 설계 의도에 따라 클러스터의 해당 구성 요소에 대한 리소스를 적극적으로 관리하고 있는지 여부를 판별합니다. Unmanaged 상태로 설정된 Operator는 구성 변경에 응답하지 않고 업데이트되지도 않습니다.

비프로덕션 클러스터 또는 디버깅 중에는 이 기능이 유용할 수 있지만, Unmanaged 상태의 Operator는 지원되지 않으며 개별 구성 요소의 구성 및 업그레이드를 클러스터 관리자가 전적으로 통제하게 됩니다.

다음과 같은 방법으로 Operator를 Unmanaged 상태로 설정할 수 있습니다.

컨트롤 플레인 구성 요소 또는 사용자 워크로드를 실행하는 머신은 처리하는 리소스 유형에 따라 그룹으로 나뉩니다. 이러한 머신 그룹을 MCP(Machine config pool)라고 합니다. 각 MCP는 노드 세트와 해당 머신 구성을 관리합니다. 노드의 역할은 해당 노드가 속한 MCP를 결정합니다. MCP는 할당된 노드 역할 레이블을 기반으로 노드를 관리합니다. MCP의 노드에는 동일한 구성이 있습니다. 즉, 워크로드 증가 또는 감소에 따라 노드를 확장하고 제거할 수 있습니다.

기본적으로 클러스터가 설치될 때 생성되는 master 및 worker라는 두 개의 MCP가 있습니다. 각 기본 MCP에는 MCP(Machine Config Operator)에 의해 적용되는 정의된 구성이 있으며 MCP를 관리하고 MCP 업그레이드를 가능하게 합니다. 추가 MCP 또는 사용자 지정 풀을 생성하여 기본 노드 유형 이외의 사용자 지정 사용 사례가 있는 노드를 관리할 수 있습니다.

사용자 지정 풀은 작업자 풀에서 구성을 상속하는 풀입니다. 작업자 풀을 대상으로 하는 머신 구성을 사용하지만 사용자 지정 풀을 대상으로 하는 변경 사항만 배포할 수 있는 기능을 추가합니다. 사용자 지정 풀은 작업자 풀의 구성을 상속하므로 작업자 풀에 대한 모든 변경 사항이 사용자 정의 풀에도 적용됩니다. 작업자 풀에서 구성을 상속하지 않는 사용자 지정 풀은 MCO에서 지원되지 않습니다.

클러스터에서 관리할 모든 노드 역할에 대한 사용자 지정 풀을 사용하는 것이 좋습니다. 예를 들어 인프라 워크로드를 처리하기 위해 인프라 노드를 생성하는 경우 사용자 지정 인프라 MCP를 생성하여 해당 노드를 그룹화하는 것이 좋습니다. 작업자 노드에 infra 역할 레이블을 적용하면 worker,infra 이중 레이블이 있지만 사용자 지정 인프라 MCP가 없는 경우 MCO는 이를 작업자 노드로 간주합니다. 노드에서 worker 레이블을 제거하고 사용자 지정 풀에서 그룹화하지 않고 infra 레이블을 적용하면 노드는 MCO에서 인식되지 않으며 클러스터에서 관리되지 않습니다.

MCO는 풀에 독립적으로 업데이트를 적용합니다. 예를 들어 모든 풀에 영향을 미치는 업데이트가 있는 경우 각 풀의 노드는 서로 병렬로 업데이트됩니다. 사용자 지정 풀을 추가하면 해당 풀에서 노드도 마스터 및 작업자 노드와 동시에 업데이트를 시도합니다.

OpenShift Container Platform은 호스트에 다른 역할을 할당합니다. 이 역할은 클러스터 내에서 머신의 기능을 정의합니다. 클러스터에는 표준 마스터 및 작업자 역할 유형의 정의가 포함됩니다.

Operator는 OpenShift Container Platform의 가장 중요한 구성 요소 중 하나입니다. Operator는 컨트롤 플레인에서 서비스를 패키징, 배포 및 관리하는 기본 방법입니다. 또한 사용자가 실행하는 애플리케이션에 이점을 제공할 수 있습니다.

Operator는 kubectl 및 oc 명령과 같은 CLI 툴 및 Kubernetes API와 통합됩니다. 애플리케이션 모니터링, 상태 점검 수행, OTA(Over-the-air) 업데이트 관리 및 애플리케이션이 지정된 상태로 유지되도록 하는 수단을 제공합니다.

Operator에서는 더 세분화된 구성 환경도 제공합니다. 글로벌 구성 파일을 수정하는 대신 Operator가 표시하는 API를 수정하여 각 구성 요소를 구성합니다.

CRI-O 및 Kubelet은 모든 노드에서 실행되므로 Operator를 사용하여 거의 모든 다른 클러스터 기능을 컨트롤 플레인에서 관리할 수 있습니다. Operator를 사용하여 컨트롤 플레인에 추가되는 구성 요소에는 중요한 네트워킹 및 인증 정보 서비스가 포함됩니다.

두 가지 모두 유사한 Operator 개념과 목표를 따르지만 OpenShift Container Platform의 Operator는 목적에 따라 서로 다른 두 시스템에서 관리합니다.

OpenShift Container Platform 4.8은 운영 체제와 클러스터 관리를 모두 통합합니다. 클러스터는 클러스터 노드에서 RHCOS(Red Hat Enterprise Linux CoreOS)에 대한 업데이트를 포함하여 자체 업데이트를 관리하므로 OpenShift Container Platform은 노드 업그레이드 오케스트레이션을 단순화하는 독단적인 라이프사이클 관리 환경을 제공합니다.

OpenShift Container Platform은 3개의 데몬 세트와 컨트롤러를 사용하여 노드 관리를 단순화합니다. 이러한 데몬 세트는 표준 Kubernetes 스타일 구성을 사용하여 호스트에 대한 운영 체제 업데이트 및 구성 변경을 오케스트레이션합니다. 다음이 포함됩니다.

머신 구성은 Ignition 구성의 서브 세트입니다. machine-config-daemon은 OSTree 업데이트를 수행해야 하는지 아니면 일련의 systemd kubelet 파일 변경, 구성 변경 또는 운영 체제나 OpenShift Container Platform 구성의 기타 변경 사항을 적용해야 하는지 확인하기 위해 머신 구성을 읽습니다.

노드 관리 작업을 수행할 때 KubeletConfig 사용자 정의 리소스(CR)를 생성하거나 수정합니다.

여러 가지 방법으로 컨테이너를 사용하여 애플리케이션 개발에 접근할 수 있으며 상황에 따라 다른 접근 방식이 더 적합할 수 있습니다. 이러한 다양성 중 일부를 설명하기 위해 제시된 일련의 접근 방식은 단일 컨테이너를 개발하는 것으로 시작하여 궁극적으로 해당 컨테이너를 대기업의 미션 크리티컬 애플리케이션으로 배포하는 것입니다. 이러한 접근 방식은 컨테이너화된 애플리케이션 개발에 사용할 수 있는 다양한 도구, 형식 및 방법을 보여줍니다. 이 주제에서는 다음을 설명합니다.

애플리케이션에 대한 아이디어가 있으며 컨테이너화하고 싶은 경우를 살펴보겠습니다.

먼저 buildah 또는 docker와 같은 컨테이너를 빌드하는 도구와 컨테이너에 들어가는 내용을 설명하는 파일(일반적으로 Dockerfile)이 필요합니다.

다음으로 결과 컨테이너 이미지를 넣을 위치가 필요하므로 실행하려는 위치로 끌어올 수 있습니다. 이 위치는 컨테이너 레지스트리입니다.

이러한 각 구성 요소의 몇 가지 예는 사용자가 직접 제공하는 Dockerfile을 제외하고 대부분의 Linux 운영 체제에 기본적으로 설치됩니다.

다음 다이어그램은 이미지를 작성하고 푸시하는 프로세스를 보여줍니다.

그림 5.1. 컨테이너화된 간단한 애플리케이션을 생성하여 레지스트리로 푸시

RHEL(Red Hat Enterprise Linux)을 운영 체제로 실행하는 컴퓨터를 사용하는 경우 컨테이너화된 애플리케이션을 생성하는 프로세스에는 다음 단계가 필요합니다.

컨테이너 이미지를 빌드하고 레지스트리에 푸시하며 실행하는 프로세스에 관한 자세한 내용은 Buildah로 사용자 정의 이미지 빌드를 참조하십시오.

5.2.2. 기본 이미지 옵션

애플리케이션을 빌드하기 위해 선택한 기본 이미지에는 애플리케이션의 Linux 시스템과 유사한 소프트웨어 세트가 포함되어 있습니다. 고유 이미지를 빌드하면 소프트웨어가 해당 파일 시스템에 배치되고 해당 파일 시스템이 운영 체제를 보는 것처럼 인식합니다. 이 기본 이미지를 선택하면 향후 컨테이너의 안전성, 효율성 및 업그레이드 가능성에 큰 영향을 미칩니다.

Red Hat에서는 Red Hat Universal Base Images(UBI)라는 새로운 기본 이미지 세트를 제공합니다. 이 이미지는 Red Hat Enterprise Linux를 기반으로 하며 과거 Red Hat에서 제공한 기본 이미지와 유사하지만 한 가지 큰 차이점이 있습니다. 이는 Red Hat 서브스크립션이 없이 자유롭게 재배포할 수 있습니다. 결과적으로 공유 방법이나 환경에 따라 다른 이미지를 만드는 것에 대한 걱정 없이 UBI 이미지에서 애플리케이션을 빌드할 수 있습니다.

이 UBI 이미지에는 표준, 초기화 및 최소 버전이 있습니다. Node.js, Perl 또는 Python과 같은 특정 런타임 환경에 종속된 애플리케이션의 기초로 Red Hat Software Collections 이미지를 사용할 수도 있습니다. 이러한 런타임 기본 이미지 중 일부 특수 버전은 S2I(Source-to-Image) 이미지라고 합니다. S2I 이미지를 사용하면 해당 코드를 실행할 준비가 된 기본 이미지 환경에 코드를 삽입할 수 있습니다.

다음 그림과 같이 카탈로그 → 개발자 카탈로그를 선택하여 OpenShift Container Platform 웹 UI에서 S2I 이미지를 직접 사용할 수 있습니다.

그림 5.2. 특정 런타임이 필요한 앱에 맞는 S2I 기본 이미지 선택

컨테이너 이미지는 컨테이너화된 애플리케이션의 기본 구성 요소이지만 OpenShift Container Platform과 같은 Kubernetes 환경에서 해당 애플리케이션을 관리하고 배포하려면 추가 정보가 필요합니다. 일반적으로 이미지를 생성한 후의 단계는 다음과 같습니다.

다른 사용자가 애플리케이션을 실행할 수 있게 하려면 애플리케이션을 Operator로 패키징하고 배포하는 것이 좋습니다. 앞에서 언급했듯이 Operator는 애플리케이션을 설치하는 즉시 애플리케이션 실행 작업이 완료되지 않음을 확인하는 라이프사이클 구성 요소를 애플리케이션에 추가합니다.

Operator로 애플리케이션을 생성할 때 애플리케이션을 실행하고 유지보수하는 방법에 관한 고유 지식을 빌드할 수 있습니다. 애플리케이션 업그레이드, 백업, 스케일링 또는 지속적인 상태 추적을 위한 기능을 빌드할 수 있습니다. 애플리케이션을 올바르게 구성하면 Operator 업데이트와 같은 유지보수 작업이 Operator의 사용자에게 표시되지 않고 자동으로 발생할 수 있습니다.

유용한 Operator의 예는 특정 시간에 자동으로 데이터를 백업하도록 설정된 Operator입니다. Operator가 정해진 시간에 애플리케이션의 백업을 관리하게 하면 시스템 관리자가 이를 기억하는 데 쏟는 시간이 절약됩니다.

데이터 백업 또는 인증서 교체와 같이 일반적으로 수동으로 완료되는 모든 애플리케이션 유지보수는 Operator를 통해 자동으로 완료할 수 있습니다.

RHCOS(Red Hat Enterprise Linux CoreOS)는 자동화된 원격 업그레이드 기능을 갖춘 RHEL(Red Hat Enterprise Linux)의 품질 표준을 제공하여 차세대 단일 목적 컨테이너 운영 체제 기술을 나타냅니다.

RHCOS는 모든 OpenShift Container Platform 머신에 대해 OpenShift Container Platform 4.8의 구성 요소로만 지원됩니다. RHCOS는 OpenShift Container Platform 컨트롤 플레인 머신 또는 마스터 머신에 지원되는 유일한 운영 체제입니다. RHCOS는 모든 클러스터 머신의 기본 운영 체제이지만 RHEL을 운영 체제로 사용하는 작업자 머신이라고도 하는 컴퓨팅 머신을 생성할 수 있습니다. OpenShift Container Platform 4.8에 RHCOS를 배포하는 일반적인 방법에는 두 가지가 있습니다.

부트스트랩 머신을 배포하는 데 사용된 Ignition 구성 파일을 보려면 다음 명령을 실행하십시오.

$ openshift-install create ignition-configs --dir $HOME/testconfig

몇 가지 질문에 대답하면 bootstrap.ign, master.ign 및 worker.ign 파일이 입력한 디렉터리에 표시됩니다.

bootstrap.ign 파일의 내용을 보려면 jq 필터를 통해 전송하십시오. 해당 파일의 스니펫은 다음과 같습니다.

$ cat $HOME/testconfig/bootstrap.ign | jq
{
  "ignition": {
    "version": "3.2.0"
  },
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "ssh-rsa AAAAB3NzaC1yc...."
        ]
      }
    ]
  },
  "storage": {
    "files": [
      {
        "overwrite": false,
        "path": "/etc/motd",
        "user": {
          "name": "root"
        },
        "append": [
          {
            "source": "data:text/plain;charset=utf-8;base64,VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2VzIGFyZSByZWxlYXNlLWltYWdlLnNlcnZpY2UgZm9sbG93ZWQgYnkgYm9vdGt1YmUuc2VydmljZS4gVG8gd2F0Y2ggdGhlaXIgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IHJlbGVhc2UtaW1hZ2Uuc2VydmljZSAtdSBib290a3ViZS5zZXJ2aWNlCg=="
          }
        ],
        "mode": 420
      },
...

bootstrap.ign 파일에 나열된 파일의 내용을 디코딩하려면 해당 파일의 내용을 나타내는 base64 인코딩 데이터 문자열을 base64 -d 명령으로 전송하십시오. 다음은 위의 출력에서 부트스트랩 머신에 추가된 /etc/motd 파일의 내용을 사용하는 예입니다.

$ echo VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2VzIGFyZSByZWxlYXNlLWltYWdlLnNlcnZpY2UgZm9sbG93ZWQgYnkgYm9vdGt1YmUuc2VydmljZS4gVG8gd2F0Y2ggdGhlaXIgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IHJlbGVhc2UtaW1hZ2Uuc2VydmljZSAtdSBib290a3ViZS5zZXJ2aWNlCg== | base64 --decode

This is the bootstrap node; it will be destroyed when the master is fully up.

The primary services are release-image.service followed by bootkube.service. To watch their status, run e.g.

  journalctl -b -f -u release-image.service -u bootkube.service

master.ign 및 worker.ign 파일에서 해당 명령을 반복하여 각 머신 유형에 대한 Ignition 구성 파일의 소스를 확인하십시오.  worker.ign에 다음과 같은 행이 표시되어 부트스트랩 머신에서 Ignition 구성을 가져오는 방법을 식별해야 합니다.

"source": "https://api.myign.develcluster.example.com:22623/config/worker",

bootstrap.ign 파일에서 배울 수 있는 몇 가지 사항은 다음과 같습니다.

머신 구성 풀은 노드 클러스터와 해당 머신 구성을 관리합니다. 머신 구성에는 클러스터의 구성 정보가 포함됩니다. 알려진 모든 머신 구성 풀을 나열하려면 다음을 수행하십시오.

$ oc get machineconfigpools

NAME   CONFIG                                  UPDATED UPDATING DEGRADED
master master-1638c1aea398413bb918e76632f20799 False   False    False
worker worker-2feef4f8288936489a5a832ca8efe953 False   False    False

모든 머신 구성을 나열하려면 다음을 수행하십시오.

$ oc get machineconfig

NAME                                      GENERATEDBYCONTROLLER   IGNITIONVERSION   CREATED   OSIMAGEURL

00-master                                 4.0.0-0.150.0.0-dirty   3.2.0             16m
00-master-ssh                             4.0.0-0.150.0.0-dirty                     16m
00-worker                                 4.0.0-0.150.0.0-dirty   3.2.0             16m
00-worker-ssh                             4.0.0-0.150.0.0-dirty                     16m
01-master-kubelet                         4.0.0-0.150.0.0-dirty   3.2.0             16m
01-worker-kubelet                         4.0.0-0.150.0.0-dirty   3.2.0             16m
master-1638c1aea398413bb918e76632f20799   4.0.0-0.150.0.0-dirty   3.2.0             16m
worker-2feef4f8288936489a5a832ca8efe953   4.0.0-0.150.0.0-dirty   3.2.0             16m

Machine Config Operator는 이러한 머신 구성을 적용할 때 Ignition과 약간 다르게 작동합니다. 머신 구성을 순서대로 읽습니다(00*에서 99*까지). 머신 구성 내부의 레이블을 사용하여 각 노드 유형(마스터 또는 작업자)을 식별합니다. 동일한 파일이 여러 머신 구성 파일에 표시되면 마지막 파일이 우선합니다. 예를 들어, 99* 파일에 표시되는 파일이 00* 파일에 표시되는 동일한 파일을 대체합니다. 입력 MachineConfig 오브젝트가 "렌더링된" MachineConfig 오브젝트로 통합되며, 이는 운영자가 대상으로 사용하고 머신 구성 풀에 표시되는 값입니다.

머신 구성에서 관리 중인 파일을 보려면 특정 MachineConfig 오브젝트 내에서 "Path:"를 찾으십시오. 예를 들면 다음과 같습니다.

$ oc describe machineconfigs 01-worker-container-runtime | grep Path:

            Path:            /etc/containers/registries.conf
            Path:            /etc/containers/storage.conf
            Path:            /etc/crio/crio.conf

머신 구성 파일에 나중 파일의 이름을 지정하십시오(예: 10-worker-container-runtime). 각 파일의 내용은 URL 스타일 데이터로 되어 있습니다. 그런 다음 새 머신 구성을 클러스터에 적용하십시오.

허용 플러그인은 OpenShift Container Platform 4.8이 작동하는 방식을 규제하는 데 사용됩니다. 허용 플러그인은 마스터 API에 대한 요청을 가로채기하여 리소스 요청의 유효성을 검사하고 요청이 인증되고 인증된 후 정책을 준수하도록 합니다. 예를 들어 보안 정책, 리소스 제한 또는 구성 요구사항을 적용하는 데 일반적으로 사용됩니다.

승인 플러그인은 순서에 따라 승인 체인으로 실행됩니다. 순서에서 승인 플러그인이 요청을 거부하면 전체 체인이 중단되고 오류가 반환됩니다.

OpenShift Container Platform에는 각 리소스 유형에 대해 사용되는 기본 승인 플러그인 세트가 있습니다. 클러스터가 올바르게 작동하는 데 필요합니다. 허용 플러그인은 책임이 없는 리소스를 무시합니다.

기본값 외에도 사용자 정의 웹 후크 서버를 호출하는 웹 후크 승인 플러그인을 통해 승인 체인을 동적으로 확장할 수 있습니다. 웹 후크 승인 플러그인에는 변경 승인 플러그인과 검증 승인 플러그인의 두 가지 유형이 있습니다. 변경 승인 플러그인이 먼저 실행되며 리소스를 수정하고 요청을 검증할 수 있습니다. 검증 승인 플러그인은 변경 승인 플러그인에 의해 트리거되는 수정도 검증할 수 있도록 요청을 검증하고 변경 승인 플러그인 후에 실행됩니다.

변경 승인 플러그인을 통해 웹 후크 서버를 호출하면 대상 오브젝트와 관련된 리소스에 부작용이 발생할 수 있습니다. 이러한 상황에서는 최종 결과가 예상한 대로인지 확인하는 단계를 수행해야 합니다.

OpenShift Container Platform 4.8에서는 기본 검증 및 승인 플러그인이 활성화됩니다. 이러한 기본 플러그인은 Ingress 정책, 클러스터 리소스 제한 덮어쓰기 및 할당량 정책과 같은 기본 컨트롤 플레인 기능에 기여합니다. 다음 목록에는 기본 승인 플러그인이 포함되어 있습니다.

OpenShift Container Platform 기본 승인 플러그인 외에도 웹 후크 서버를 호출하는 웹 후크 승인 플러그인을 통해 동적 승인을 구현하여 승인 체인의 기능을 확장할 수 있습니다. 웹 후크 서버는 정의된 엔드포인트에서 HTTP를 통해 호출됩니다.

OpenShift Container Platform에는 다음 두 가지 유형의 웹 후크 승인 플러그인이 있습니다.

API 요청이 입력되면 변경 또는 검증 승인 플러그인이 구성의 외부 웹 후크 목록을 사용하여 병렬로 호출합니다.

웹 후크 승인 플러그인과 웹 후크 서버 간 통신은 TLS를 사용해야 합니다. CA 인증서를 생성하고 인증서를 사용하여 웹 후크 승인 서버에서 사용하는 서버 인증서에 서명하십시오. PEM으로 인코딩된 CA 인증서는 서비스 제공 인증서 보안과 같은 메커니즘을 사용하여 웹 후크 승인 플러그인에 제공됩니다.

다음 다이어그램은 여러 웹 후크 서버가 호출되는 순차적 승인 체인 프로세스를 보여줍니다.

그림 7.1. 변경 및 검증 승인 플러그인을 사용하는 API 승인 체인

웹 후크 승인 플러그인 사용 사례의 예는 모든 Pod에 공통 레이블 세트가 있어야 하는 경우입니다. 이 예에서 변경 승인 플러그인은 레이블을 삽입할 수 있으며 검증 승인 플러그인은 레이블이 예상대로 있는지 확인할 수 있습니다. 계속하여 OpenShift Container Platform에서 필요한 레이블이 포함된 포드를 스케줄링하고 그렇지 않은 레이블은 거부합니다.

일반적인 웹 후크 승인 플러그인 사용 사례는 다음과 같습니다.

클러스터 관리자는 API 서버 승인 체인의 변경 승인 플러그인 또는 검증 승인 플러그인을 통해 웹 후크 서버를 호출할 수 있습니다.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default 5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: None

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default  5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: Unknown

이 절차에서는 동적 승인을 구성하기 위한 고급 단계를 간략하게 설명합니다. 승인 체인의 기능은 웹 후크 서버를 호출하도록 웹 후크 승인 플러그인을 구성하여 확장합니다.

웹 후크 서버는 집계 API 서버로도 구성됩니다. 그러면 다른 OpenShift Container Platform 구성 요소가 내부 인증서를 사용하여 웹 후크와 통신하고 oc 명령을 사용하여 테스트를 용이하게 합니다. 또한 웹 후크에 대한 역할 기반 액세스 제어(RBAC)를 가능하게 하고 다른 API 서버의 토큰 정보가 웹 후크에 공개되는 것을 방지합니다.