아키텍처

컨테이너 이미지와 컨테이너 이미지에서 실행되는 컨테이너는 최신 애플리케이션 개발을 위한 기본 빌딩 블록이지만 규모에 맞게 실행하려면 안정적이고 유연한 배포 시스템이 필요합니다. Kubernetes는 컨테이너를 오케스트레이션하는 사실상의 표준입니다.

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈 소스 컨테이너 오케스트레이션 엔진입니다. Kubernetes의 일반적인 개념은 다음과 같이 매우 간단합니다.

불과 몇 년 만에 Kubernetes는 대규모 클라우드와 온프레미스에서 채택되었습니다. 오픈 소스 개발 모델을 사용하면 많은 사용자가 네트워킹, 스토리지 및 인증과 같은 구성 요소에 다른 기술을 구현하여 Kubernetes를 확장할 수 있습니다.

컨테이너화된 애플리케이션을 사용하면 기존 배포 방법을 사용하는 것보다 많은 이점이 있습니다. 애플리케이션이 모든 종속 항목을 포함하는 운영 체제에 한 번 설치될 것으로 예상되는 경우 컨테이너를 통해 애플리케이션이 해당 애플리케이션과 함께 종속 항목을 유지할 수 있습니다. 컨테이너화된 애플리케이션을 생성하면 많은 이점이 있습니다.

Red Hat OpenShift Service on AWS는 다음과 같은 향상된 기능을 포함하여 Kubernetes에 엔터프라이즈급 개선 사항을 제공합니다.

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

ROSA와 HCP를 사용하면 퍼블릭 또는 프라이빗 네트워크에서 클러스터를 생성할 수 있습니다. 다음 이미지는 공용 네트워크와 사설 네트워크의 아키텍처를 보여줍니다.

그림 3.2. 공용 네트워크에 HCP가 배포된 ROSA

그림 3.3. 개인 네트워크에 HCP가 배포된 ROSA

ROSA Classic을 사용하면 공용 또는 프라이빗 네트워크를 통해 액세스할 수 있는 클러스터를 생성할 수 있습니다.

다음과 같은 방법으로 API 서버 엔드 포인트 및 Red Hat SRE 관리에 대한 액세스 패턴을 사용자 지정할 수 있습니다.

다음 이미지는 퍼블릭 및 프라이빗 네트워크 모두에 배포된 ROSA Classic 클러스터의 아키텍처를 보여줍니다.

그림 3.4. 공개 및 개인 네트워크에 배포된 ROSA Classic

ROSA Classic 클러스터에는 Ingress 컨트롤러, 이미지 레지스트리 및 모니터링과 같은 OpenShift 구성 요소가 배포되는 인프라 노드가 포함됩니다. 인프라 노드와 여기에 배포된 OpenShift 구성 요소는 ROSA 서비스 SRE에 의해 관리됩니다.

다음 유형의 클러스터는 ROSA Classic에서 사용할 수 있습니다.

AWS PrivateLink 클러스터를 생성하는 Red Hat 관리형 인프라는 프라이빗 서브넷에서 호스팅됩니다. Red Hat과 고객 제공 인프라 간의 연결은 AWS PrivateLink VPC 엔드포인트를 통해 생성됩니다.

다음 다이어그램에서는 PrivateLink 클러스터의 네트워크 연결을 보여줍니다.

그림 3.5. 프라이빗 서브넷에 배포된 멀티 AZ AWS PrivateLink 클러스터

ROSA는 고객이 VPC 내에 대기 시간에 민감한 애플리케이션 워크로드를 배치할 수 있는 대도시 분산 가용성 영역인 AWS 로컬 영역의 사용을 지원합니다. 로컬 영역은 AWS 리전의 확장이며 기본적으로 활성화되어 있지 않습니다. 로컬 영역을 활성화 및 구성하면 유연성이 향상되고 대기 시간이 단축되도록 트래픽이 로컬 영역으로 확장됩니다. 자세한 내용은 "로컬 영역에서 머신 풀 구성"을 참조하십시오.

다음 다이어그램은 로컬 영역으로 라우팅되는 트래픽이 없는 ROSA 클러스터를 표시합니다.

그림 3.6. 로컬 영역으로 라우팅되는 트래픽이 없는 ROSA 클러스터

다음 다이어그램은 로컬 영역으로 라우팅되는 트래픽이 있는 ROSA 클러스터를 표시합니다.

그림 3.7. 로컬 영역으로 라우팅되는 트래픽이 있는 ROSA 클러스터

Kubernetes 클러스터에서 작업자 노드는 Kubernetes 사용자가 요청한 실제 워크로드를 실행하고 관리합니다. 작업자 노드는 용량을 알리고 컨트롤 플레인 서비스인 스케줄러는 Pod 및 컨테이너를 시작할 노드를 결정합니다. 다음 중요한 서비스는 각 작업자 노드에서 실행됩니다.

AWS의 Red Hat OpenShift Service에서 컴퓨팅 머신 세트는 작업자 시스템 역할이 할당된 컴퓨팅 머신을 제어합니다. worker 역할 드라이브가 있는 머신은 자동 스케일링하는 특정 머신 풀이 관리하는 워크로드를 컴퓨팅합니다. AWS의 Red Hat OpenShift Service에는 여러 머신 유형을 지원할 수 있는 용량이 있으므로 worker 역할의 시스템은 컴퓨팅 머신으로 분류됩니다. 이 릴리스에서는 기본 유형의 컴퓨팅 머신이 작업자 머신이기 때문에 작업자 머신과 컴퓨팅 머신이라는 용어는 서로 바꿔 사용할 수 있습니다. 향후 AWS의 Red Hat OpenShift Service 버전에서는 인프라 머신과 같은 다양한 유형의 컴퓨팅 머신이 기본적으로 사용될 수 있습니다.

Kubernetes 클러스터에서 master 노드는 Kubernetes 클러스터를 제어하는 데 필요한 서비스를 실행합니다. AWS의 Red Hat OpenShift Service에서 컨트롤 플레인은 마스터 머신 역할이 있는 컨트롤 플레인 시스템으로 구성됩니다. 여기에는 AWS 클러스터에서 Red Hat OpenShift Service를 관리하기 위한 Kubernetes 서비스 이상의 것이 포함되어 있습니다.

대부분의 AWS 클러스터에서 Red Hat OpenShift Service는 컨트롤 플레인 시스템은 일련의 독립 실행형 머신 API 리소스로 정의됩니다. 컨트롤 플레인은 컨트롤 플레인 머신 세트로 관리됩니다. 모든 컨트롤 플레인 시스템을 삭제하고 클러스터를 중단하지 못하도록 컨트롤 플레인 시스템에 추가 제어가 적용됩니다.

컨트롤 플레인의 Kubernetes 카테고리에 속하는 서비스에는 Kubernetes API 서버, etcd, Kubernetes 컨트롤러 관리자 및 Kubernetes 스케줄러가 포함됩니다.

OpenShift API 서버, OpenShift 컨트롤러 관리자 및 OpenShift OAuth API 서버 및 OpenShift OAuth 서버를 포함하는 컨트롤 플레인에서 실행되는 OpenShift 서비스도 있습니다.

컨트롤 플레인 시스템에서 이러한 서비스 중 일부는 systemd 서비스로 실행되는 반면 다른 서비스는 정적 Pod로 실행됩니다.

시스템 서비스는 특정 시스템이 시작된 직후에 항상 필요한 서비스에 적합합니다. 컨트롤 플레인 시스템의 경우 원격 로그인을 허용하는 sshd가 포함됩니다. 다음과 같은 서비스도 포함됩니다.

CRI-O 및 Kubelet은 다른 컨테이너를 실행하기 전에 실행되어야 하기 때문에 systemd 서비스로 호스트에서 직접 실행해야 합니다.

installer-* 및 revision-pruner-* 컨트롤 플레인 Pod는 root 사용자가 소유한 /etc/kubernetes 디렉토리에 쓰기 때문에 root 권한으로 실행해야 합니다. 이러한 pod에는 다음과 같은 네임스페이스에 있습니다.

OLM(Operator Lifecycle Manager) 및 OperatorHub는 AWS의 Red Hat OpenShift Service에서 Kubernetes 네이티브 애플리케이션을 Operator로 관리하는 데 도움이 되는 기본 구성 요소입니다. 함께 클러스터에서 사용 가능한 선택적 애드온 Operator를 검색, 설치 및 관리하기 위한 시스템을 제공합니다.

AWS 웹 콘솔의 Red Hat OpenShift Service에서 OperatorHub를 사용하여 dedicated-admin 역할 및 권한이 있는 관리자는 Operator 카탈로그에서 설치할 Operator를 선택할 수 있습니다. OperatorHub에서 Operator를 설치한 후에는 전역 또는 특정 네임스페이스에서 사용자 애플리케이션에서 실행할 수 있도록 할 수 있습니다.

Red Hat Operator, 인증된 Operator, 커뮤니티 Operator가 포함된 기본 카탈로그 소스를 사용할 수 있습니다. dedicated-admin 역할의 관리자는 사용자 정의 Operator 세트를 포함할 수 있는 고유한 사용자 정의 카탈로그 소스도 추가할 수 있습니다.

개발자는 Operator SDK를 사용하여 OLM 기능을 활용하는 사용자 정의 Operator를 작성할 수 있습니다. 그런 다음 Operator를 번들로 제공하고 사용자 정의 카탈로그 소스에 추가할 수 있습니다. 이 소스는 클러스터에 추가하고 사용자가 사용할 수 있도록 합니다.

etcd를 사용하면 다음과 같은 여러 가지 방법으로 이점을 누릴 수 있습니다.

클러스터 구성 및 관리에 대한 안정적인 접근 방식을 보장하기 위해 etcd는 etcd Operator를 사용합니다. Operator는 AWS의 Red Hat OpenShift Service와 같은 Kubernetes 컨테이너 플랫폼에서 etcd 사용을 단순화합니다. etcd Operator를 사용하면 etcd 멤버를 만들거나 삭제하고, 클러스터의 크기를 조정하고, 백업을 수행하고, etcd를 업그레이드할 수 있습니다.

etcd Operator는 다음을 관찰, 분석 및 작동합니다.

etcd에는 클러스터 상태가 있으며 이는 지속적으로 업데이트됩니다. 이 상태는 지속적으로 유지되므로 높은 빈도로 인해 작은 변화가 많이 발생합니다. 결과적으로 Red Hat SRE(사이트 안정성 엔지니어링)는 대기 시간이 짧은 I/O로 etcd 클러스터 멤버를 백업합니다.

CUDA(Compute Unified Device Architecture)는 GPU의 일반 컴퓨팅을 위해 NVIDIA에서 개발한 병렬 컴퓨팅 플랫폼 및 프로그래밍 모델입니다.

스트림은 GPU에서 문제순으로 실행되는 일련의 작업입니다. CUDA 명령은 일반적으로 기본 스트림에서 순차적으로 실행되며 이전 작업이 완료될 때까지 작업이 시작되지 않습니다.

다양한 스트림의 작업을 비동기적으로 처리하면 병렬 작업을 실행할 수 있습니다. 한 스트림에서 발행된 작업은 다른 작업이 다른 스트림으로 발행되기 전, 중 또는 후에 실행됩니다. 이를 통해 GPU는 정해진 순서로 여러 작업을 동시에 실행하여 성능이 향상됩니다.

GPU 시간 분할은 여러 CUDA 애플리케이션을 실행할 때 과부하된 GPU에서 예약된 워크로드를 상호 저장합니다.

GPU의 복제본 세트를 정의하여 Kubernetes에서 GPU를 시간 분할할 수 있으며 각각 워크로드를 실행하기 위해 개별적으로 Pod에 배포할 수 있습니다. MIG(Multi-instance GPU)와 달리 복제본 간 메모리 또는 내결함성이 없지만 일부 워크로드의 경우 공유하지 않는 것보다 좋습니다. 내부적으로 GPU 시간 분할은 동일한 기본 GPU의 복제본에서 멀티플렉션에 사용됩니다.

시간 분할에 대한 클러스터 전체 기본 구성을 적용할 수 있습니다. 노드별 구성을 적용할 수도 있습니다. 예를 들어 Cryostat T4 GPU가 있는 노드에만 시간 분할 구성을 적용하고 다른 GPU 모델의 노드를 수정할 수 없습니다.

클러스터 전체 기본 구성을 적용한 다음 노드에 레이블을 지정하여 해당 노드에 노드별 구성을 지정하여 이러한 두 가지 접근 방식을 결합할 수 있습니다.

CUDA Multi-Process Service(MPS)를 사용하면 단일 GPU가 여러 CUDA 프로세스를 사용할 수 있습니다. 프로세스는 GPU에서 병렬로 실행되며 GPU 컴퓨팅 리소스의 포화 상태를 제거합니다. 또한 MPS는 다양한 프로세스에서 커널 작업 및 메모리를 복사하여 사용률을 향상시킬 수 있습니다.

MG(Multi-instance GPU)를 사용하여 GPU 컴퓨팅 단위와 메모리를 여러MIG 인스턴스로 분할할 수 있습니다. 이러한 각 인스턴스는 시스템 관점에서 독립 실행형 GPU 장치를 나타내며 노드에서 실행되는 모든 애플리케이션, 컨테이너 또는 가상 머신에 연결할 수 있습니다. GPU를 사용하는 소프트웨어는 이러한 기타 각 인스턴스를 개별 GPU로 처리합니다.

MIG는 전체 GPU의 전체 성능이 필요하지 않은 애플리케이션이 있는 경우에 유용합니다. 새로운 NVIDIA Ampere 아키텍처의 MIG 기능을 사용하면 하드웨어 리소스를 여러 GPU 인스턴스로 분할할 수 있으며 각 GPU 인스턴스는 운영 체제에서 독립적인 CUDA 지원 GPU로 사용할 수 있습니다.

NVIDIA GPU Operator 버전 1.7.0 이상은 A100 및 A30 Ampere 카드에 대해MIG 지원을 제공합니다. 이러한 GPU 인스턴스는 전용 하드웨어 리소스와 완전히 격리된 최대 7개의 독립 CUDA 애플리케이션을 지원하도록 설계되었습니다.

가상 머신(VM)은 NVIDIA vGPU를 사용하여 단일 물리적 GPU에 직접 액세스할 수 있습니다. 엔터프라이즈 전체의 VM에서 공유하여 다른 장치에서 액세스할 수 있는 가상 GPU를 생성할 수 있습니다.

이 기능은 GPU 성능의 기능과 vGPU가 제공하는 관리 및 보안 이점을 결합합니다. vGPU가 제공하는 추가 이점으로 VM 환경에 대한 사전 관리 및 모니터링, 혼합 VDI 및 컴퓨팅 워크로드를 위한 워크로드 분산, 여러 VM의 리소스 공유 등이 포함됩니다.

buildah, podman 및 skopeo를 사용하여 컨테이너를 빌드하고 관리하면 AWS 또는 기타 Kubernetes 환경에서 컨테이너를 배포하기 위해 특별히 조정된 기능이 포함된 업계 표준 컨테이너 이미지가 생성됩니다. 이러한 툴은 데몬이 없으며 루트 권한 없이 실행할 수 있으므로 실행하기 위한 오버헤드가 줄어듭니다.

AWS의 Red Hat OpenShift Service에서 궁극적으로 컨테이너를 실행하면 CRI-O 컨테이너 엔진을 사용합니다. CRI-O는 AWS 클러스터의 Red Hat OpenShift Service의 모든 작업자 및 컨트롤 플레인 시스템에서 실행되지만 CRI-O는 아직 AWS의 Red Hat OpenShift Service 외부에서 독립 실행형 런타임으로 지원되지 않습니다.

애플리케이션을 빌드하기 위해 선택한 기본 이미지에는 애플리케이션의 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 이미지를 사용하면 해당 코드를 실행할 준비가 된 기본 이미지 환경에 코드를 삽입할 수 있습니다.

S2I 이미지는 AWS 웹 UI의 Red Hat OpenShift Service에서 직접 사용할 수 있습니다. 개발자 화면에서 +추가 보기로 이동하고 개발자 카탈로그 타일에서 개발자 카탈로그 에서 사용 가능한 모든 서비스를 확인합니다.

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

컨테이너 레지스트리에 컨테이너 이미지를 저장하면 다른 사용자와 공유하고 궁극적으로 실행되는 플랫폼에서 사용할 수 있게 됩니다. 무료 계정을 제공하는 대규모 공용 컨테이너 레지스트리 또는 추가 스토리지와 특수 기능을 제공하는 프리미엄 버전을 선택할 수 있습니다. 조직에 독점적이거나 다른 사용자와 선택적으로 공유할 수 있는 고유한 레지스트리도 설치할 수 있습니다.

Red Hat 이미지 및 인증된 파트너 이미지를 얻으려면 Red Hat Registry에서 그릴 수 있습니다. Red Hat Registry는 인증되지 않고 더 이상 사용되지 않는 registry.access.redhat.com과 인증이 필요한 registry.redhat.io의 두 위치로 표시됩니다. Container images section of the Red Hat Ecosystem Catalog에서 Red Hat Registry의 Red Hat 및 파트너 이미지에 관해 알아볼 수 있습니다. Red Hat 컨테이너 이미지를 나열하는 것 외에도 적용된 보안 업데이트를 기반으로 한 상태 점수를 포함하여 해당 이미지의 내용과 품질에 대한 광범위한 정보를 보여줍니다.

대규모 공개 레지스트리에는 Docker Hub 및 Quay.io가 있습니다. Quay.io 레지스트리는 Red Hat이 소유하고 관리합니다. AWS의 Red Hat OpenShift Service에 사용되는 많은 구성 요소는 컨테이너 이미지와 AWS 자체에 Red Hat OpenShift Service를 배포하는 데 사용되는 Operator를 포함하여 Quay.io에 저장됩니다. Quay.io는 Helm 차트를 포함하여 다른 유형의 콘텐츠를 저장하는 수단도 제공합니다.

자체 프라이빗 컨테이너 레지스트리를 원하는 경우 AWS의 Red Hat OpenShift Service 자체에 AWS의 Red Hat OpenShift Service와 함께 설치되어 클러스터에서 실행되는 프라이빗 컨테이너 레지스트리가 포함되어 있습니다. Red Hat은 Red Hat Quay라는 개인용 Quay.io 레지스트리 버전도 제공합니다. Red Hat Quay에는 지역 복제, Git 빌드 트리거, Clair 이미지 스캔 및 기타 여러 기능이 포함되어 있습니다.

여기에 언급된 모든 레지스트리는 해당 레지스트리에서 이미지를 다운로드하기 위해 자격 증명이 필요할 수 있습니다. 이러한 인증 정보 중 일부는 AWS의 Red Hat OpenShift Service에서 클러스터 전체에서 제공되며 다른 인증 정보는 개인에게 할당할 수 있습니다.

컨테이너 이미지는 docker가 있는 기본 단위이지만 Kubernetes가 작동하는 기본 단위는 pod라고 합니다. 포드는 애플리케이션을 빌드하는 다음 단계를 나타냅니다. 포드는 하나 이상의 컨테이너를 포함할 수 있습니다. 핵심은 포드가 배포, 스케일링 및 관리하는 단일 단위라는 것입니다.

확장성과 네임스페이스는 포드에 들어갈 내용을 결정할 때 고려해야 할 주요 항목입니다. 쉽게 배포하기 위해 포드에 컨테이너를 배포하고 자체 로깅 및 모니터링 컨테이너를 포드에 포함시킬 수 있습니다. 나중에 포드를 실행하고 추가 인스턴스를 스케일링해야 하는 경우 다른 컨테이너도 함께 확장됩니다. 네임스페이스의 경우 포드의 컨테이너는 동일한 네트워크 인터페이스, 공유 스토리지 볼륨 및 리소스 제한(예: 메모리 및 CPU)을 공유하므로, 포드의 콘텐츠를 단일 단위로 관리하기가 쉬워집니다. 포드의 컨테이너는 System V 세마포어 또는 POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있습니다.

개별 포드는 Kubernetes에서 확장 가능한 단위를 나타내지만 서비스는 포드 세트를 함께 그룹화하여 부하 분산과 같은 작업을 완료할 수 있는 완전하고 안정적인 애플리케이션을 생성하는 수단을 제공합니다. 또한 서비스는 삭제할 때까지 동일한 IP 주소에서 계속 사용할 수 있기 때문에 포드보다 영구적입니다. 서비스가 사용 중이면 이름으로 요청되고 AWS 클러스터의 Red Hat OpenShift Service는 해당 이름을 서비스를 구성하는 포드에 도달할 수 있는 IP 주소 및 포트로 확인됩니다.

컨테이너화된 애플리케이션은 특성상 실행되는 운영 체제뿐 아니라 사용자와 분리됩니다. Kubernetes 매니페스트의 일부는 컨테이너화된 애플리케이션과의 통신을 세밀하게 제어할 수 있는 네트워크 정책을 정의하여 애플리케이션을 내부 및 외부 네트워크에 노출하는 방법을 설명합니다. HTTP, HTTPS 및 기타 서비스에 대한 수신 요청을 클러스터 외부에서 클러스터 내부 서비스로 연결하려면 Ingress 리소스를 사용할 수 있습니다.

컨테이너에 서비스를 통해 제공될 수 있는 데이터베이스 스토리지 대신 온-디스크 스토리지가 필요한 경우 매니페스트에 볼륨을 추가하여 해당 스토리지를 포드에서 사용하게 만들 수 있습니다. 영구 볼륨(PV)을 생성하거나 포드 정의에 추가되는 볼륨을 동적으로 생성하도록 매니페스트를 구성할 수 있습니다.

애플리케이션을 구성하는 Pod 그룹을 정의한 후 Deployment 및 DeploymentConfig 오브젝트에서 해당 Pod를 정의할 수 있습니다.

다음으로 애플리케이션 유형이 애플리케이션 실행 방법에 어떤 영향을 미치는지 고려하십시오.

Kubernetes는 다양한 종류의 애플리케이션에 적합한 다양한 유형의 워크로드를 정의합니다. 애플리케이션에 적합한 워크로드를 판별하려면 애플리케이션이 다음과 같은지 고려하십시오.

작성하는 애플리케이션에는 데이터베이스 또는 로깅 구성 요소와 같은 지원 구성 요소가 필요할 수 있습니다. 이러한 요구를 충족시키기 위해 AWS 웹 콘솔의 Red Hat OpenShift Service에서 사용할 수 있는 다음 카탈로그에서 필요한 구성 요소를 얻을 수 있습니다.

개발 팀의 특정 요구에 맞게 지원 Operator 및 템플릿을 구성한 다음 개발자가 작업하는 네임스페이스에서 사용 가능하게 만들 수 있습니다. 많은 사용자가 다른 모든 네임스페이스에서 액세스할 수 있으므로 openshift 네임스페이스에 공유 템플릿을 추가합니다.

Kubernetes 매니페스트를 사용하면 Kubernetes 애플리케이션을 구성하는 구성 요소를 더 완벽하게 이해할 수 있습니다. 이러한 매니페스트를 YAML 파일로 작성하고 oc apply 명령을 실행하는 등의 작업을 통해 클러스터에 적용하여 배포합니다.

이 시점에서 컨테이너 개발 프로세스를 자동화하는 방법을 고려하십시오. 이상적으로 이미지를 빌드하고 레지스트리로 푸시하는 일종의 CI 파이프라인이 있습니다. 특히, GitOps 파이프라인은 컨테이너 개발을 애플리케이션 빌드에 필요한 소프트웨어를 저장하는 데 사용하는 Git 리포지토리와 통합합니다.

이 시점의 워크플로우는 다음과 같습니다.

변경 승인 플러그인은 승인 프로세스의 변경 단계에서 호출되므로 리소스 콘텐츠가 지속되기 전에 수정할 수 있습니다. 변경 승인 플러그인을 통해 호출할 수 있는 웹 후크의 한 예는 네임스페이스의 주석을 사용하여 라벨 선택기를 찾고 Pod 사양에 추가하는 Pod 노드 선택기 기능입니다.

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

승인 프로세스의 검증 단계에서 검증 승인 플러그인이 호출됩니다. 이 단계에서는 특정 API 리소스에 대한 변형을 적용하여 리소스가 다시 변경되지 않게 합니다. 포드 노드 선택기는 검증 승인 플러그인에 의해 호출되는 웹 후크의 예이며, 네임스페이스의 노드 선택기 제한에 따라 모든 nodeSelector 필드가 제한되도록 합니다.

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