3장. Microsoft Azure Red Hat OpenShift에 기밀 컨테이너 배포
Microsoft Azure Red Hat OpenShift에서 기밀 컨테이너 워크로드를 배포할 수 있습니다.
3.1. 준비 링크 복사링크가 클립보드에 복사되었습니다!
Azure Red Hat OpenShift에 기밀 컨테이너를 배포하기 전에 이러한 사전 요구 사항 및 개념을 검토하십시오.
3.1.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 기밀 컨테이너 워크로드를 실행하는 클러스터에 최신 버전의 Red Hat OpenShift Container Platform을 설치했습니다.
- 신뢰할 수 있는 환경의 OpenShift Container Platform 클러스터에 Red Hat build of Trustee를 배포했습니다. 자세한 내용은 Red Hat build of Trustee를 참조하십시오.
- 작업자 노드 및 Pod VM(가상 머신)에 사용되는 서브넷의 통신에 포트 15150 및 9000을 활성화했습니다. 포트를 사용하면 작업자 노드에서 실행 중인 Kata shim과 pod VM에서 실행되는 Kata 에이전트 간에 통신할 수 있습니다.
3.1.2. 아웃바운드 연결 링크 복사링크가 클립보드에 복사되었습니다!
피어 Pod가 공용 인터넷과 같은 외부 네트워크와 통신할 수 있도록 하려면 Pod VM(가상 머신) 서브넷에 대한 아웃바운드 연결을 구성해야 합니다. 이를 위해서는 NAT 게이트웨이를 설정해야 하며, 선택적으로 Azure에서 서브넷이 클러스터의 가상 네트워크(VNet)와 통합되는 방법을 정의합니다.
- 피어 Pod 및 서브넷
- 피어 Pod는 아웃바운드 액세스를 위한 명시적 구성이 필요한 전용 Azure 서브넷에서 작동합니다. 이 서브넷은 OpenShift Container Platform 노드에서 사용하는 기본 작업자 서브넷 또는 피어 Pod를 위해 특별히 생성된 별도의 사용자 정의 서브넷일 수 있습니다.
- VNet 피어링
- 별도의 서브넷을 사용하는 경우 VNet 피어링은 피어 Pod VNet을 클러스터의 VNet에 연결하여 격리를 유지하면서 내부 통신을 보장합니다. 이를 위해서는 VNet 간에 겹치지 않는 CIDR 범위가 필요합니다.
아웃바운드 연결은 다음 두 가지 방법으로 구성할 수 있습니다.
- 기본 작업자 서브넷: NAT 게이트웨이를 포함하도록 기존 작업자 서브넷을 수정합니다. 이는 더 간단하고 클러스터 리소스를 재사용하지만 격리를 줄일 수 있습니다.
- 피어 Pod VNet: 피어 Pod의 전용 VNet 및 서브넷을 설정하고 NAT 게이트웨이를 연결하며 클러스터 VNet과 피어링합니다. 이로 인해 추가 복잡성으로 인해 격리와 유연성이 향상됩니다.
3.1.3. 피어 Pod 리소스 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에 충분한 리소스가 있는지 확인해야 합니다.
피어 Pod 가상 머신(VM)에는 다음 두 위치에 있는 리소스가 필요합니다.
-
작업자 노드입니다. 작업자 노드는 메타데이터, Kata shim 리소스(
containerd-shim-kata-v2), remote-hypervisor 리소스(cloud-api-adaptor) 및 작업자 노드와 피어 Pod VM 간의 터널 설정을 저장합니다. - 클라우드 인스턴스입니다. 클라우드에서 실행되는 실제 피어 Pod VM입니다.
Kubernetes 작업자 노드에 사용되는 CPU 및 메모리 리소스는 피어 Pod를 생성하는 데 사용되는 RuntimeClass(kata-remote) 정의에 포함된 Pod 오버헤드 에 의해 처리됩니다.
클라우드에서 실행되는 총 피어 Pod VM 수는 Kubernetes 노드 확장 리소스로 정의됩니다. 이 제한은 노드당이며 peer-pods-cm 구성 맵의 PEERPODS_LIMIT_PER_NODE 속성에 의해 설정됩니다.
확장된 리소스의 이름은 kata.peerpods.io/vm 이며 Kubernetes 스케줄러에서 용량 추적 및 계정을 처리할 수 있습니다.
OpenShift 샌드박스 컨테이너 Operator를 설치한 후 환경의 요구 사항에 따라 노드당 제한을 편집할 수 있습니다.
변경 웹 후크 는 확장된 리소스 kata.peerpods.io/vm 을 Pod 사양에 추가합니다. 또한 Pod 사양에서 리소스별 항목도 제거합니다(있는 경우). 이를 통해 Kubernetes 스케줄러에서 이러한 확장 리소스를 고려하여 리소스를 사용할 수 있는 경우에만 피어 Pod를 예약할 수 있습니다.
변경 웹 후크는 다음과 같이 Kubernetes Pod를 수정합니다.
-
변경 웹 후크는
TARGET_RUNTIMECLASS환경 변수에 지정된 예상RuntimeClassName값을 Pod에 확인합니다. Pod 사양의 값이TARGET_RUNTIMECLASS의 값과 일치하지 않으면 Pod를 수정하지 않고 웹 후크가 종료됩니다. RuntimeClassName값이 일치하는 경우 Webhook에서 Pod 사양을 다음과 같이 변경합니다.-
Webhook는 Pod에 있는 모든 컨테이너 및 init 컨테이너의
resources필드에서 모든 리소스 사양을 제거합니다. -
Webhook는 Pod의 첫 번째 컨테이너의 resources 필드를 수정하여 확장 리소스(
kata.peerpods.io/vm)를 사양에 추가합니다. 확장된 리소스kata.peerpods.io/vm은 회계 목적으로 Kubernetes 스케줄러에서 사용합니다.
-
Webhook는 Pod에 있는 모든 컨테이너 및 init 컨테이너의
변경 웹 후크는 OpenShift Container Platform의 특정 시스템 네임스페이스가 변경되지 않습니다. 해당 시스템 네임스페이스에 피어 Pod가 생성되면 Pod 사양에 확장 리소스가 포함되지 않는 한 Kubernetes 확장 리소스를 사용하는 리소스 계정이 작동하지 않습니다.
특정 네임스페이스에서 피어 Pod 생성만 허용하도록 클러스터 전체 정책을 정의하는 것이 좋습니다.
3.1.4. Initdata 링크 복사링크가 클립보드에 복사되었습니다!
initdata 사양은 런타임 시 워크로드별 데이터로 Pod를 초기화할 수 있는 유연한 방법을 제공하므로 이러한 데이터를 VM(가상 머신) 이미지에 포함할 필요가 없습니다.
이 접근 방식은 기밀 정보의 노출을 줄이고 사용자 정의 이미지 빌드를 제거하여 유연성을 개선합니다. 예를 들어 initdata에는 세 가지 구성 설정이 포함될 수 있습니다.
- 보안 통신을 위한 X.509 인증서입니다.
- 인증을 위한 암호화 키입니다.
-
기본 Kata Agent 정책을 덮어쓸 때 런타임 동작을 적용하는 선택적 Kata Agent
policy.rego파일입니다.
initdata 콘텐츠는 다음 구성 요소를 구성합니다.
- 인증 에이전트(AA)는 검증에 대한 증명을 전송하여 Pod의 신뢰성을 확인합니다.
- Pod VM 내에서 시크릿 및 보안 데이터 액세스를 관리하는 CDH(비밀 데이터 허브)입니다.
- Kata 에이전트는 런타임 정책을 적용하고 Pod VM 내부의 컨테이너의 라이프사이클을 관리합니다.
initdata.toml 파일을 생성하여 Base64로 인코딩된 gzip-format 문자열로 변환합니다. 다음 방법 중 하나로 워크로드에 initdata 문자열을 적용합니다.
-
글로벌 구성: initdata 문자열을 피어 포드 구성 맵의
INITDATA키 값으로 추가하여 모든 피어 포드에 대한 기본 구성을 생성합니다. Pod 구성: initdata 문자열을 Pod 매니페스트에 주석으로 추가하여 개별 워크로드에 대해 사용자 지정할 수 있습니다.
참고Pod 매니페스트의 initdata 주석은 해당 특정 포드에 대한 피어 포드 구성 맵의 글로벌
INITDATA값을 재정의합니다. Kata 런타임은 Pod 생성 시 자동으로 이 우선 순위를 처리합니다.
그런 다음 initdata 파일에서 해시를 생성합니다. 이 해시는 Red Hat build of Trustee의 RVPS(Reference Value Provider Service) 구성 맵의 참조 값으로 필요합니다.