Red Hat Summit릴리스 노트
초록
Red Hat 문서에 관한 피드백 제공
피드백을 제공하거나 HCIDOCS 프로젝트에 대한 Jira 문제를 생성하여 피드백을 제공하거나 오류를 보고할 수 있습니다. 여기서 피드백의 진행 상황을 추적할 수 있습니다. Red Hat Jira 계정이 있어야 하며 로그인해야 합니다.
- Create Issue 양식을 시작합니다.
요약,설명 및 보고자 필드를 완료합니다.
설명 필드에 문서 URL, 장 또는 섹션 번호, 문제에 대한 자세한 설명을 포함합니다.
- 생성을 클릭합니다.
1장. 릴리스 정보
이 릴리스 노트에서는 Red Hat OpenShift Container Platform 4.17과 함께 OpenShift 샌드박스 컨테이너 1.8의 개발을 추적합니다. 릴리스 노트에는 원본 티켓에 대한 링크가 포함되어 있습니다. 개인 티켓에는 링크가 없습니다.
OpenShift Container Platform은 FIPS용으로 설계되었습니다. FIPS 모드에서 부팅된 RHEL(Red Hat Enterprise Linux CoreOS) 또는 RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 경우 OpenShift Container Platform 코어 구성 요소는 x86_64,ppc64le, s390x 아키텍처에서만 FIPS 140-2/140-3 Validation에 대해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.
NIST 검증 프로그램에 대한 자세한 내용은 암호화 모듈 유효성 검사 프로그램을 참조하십시오. 검증을 위해 제출된 개별 RHEL 암호화 라이브러리의 최신 NIST 상태는 규정 준수 활동 및 정부 표준을 참조하십시오.
Red Hat 고객 포털에서 이 릴리스의 주요 버전 및 마이너 버전의 경우 보안 및 버그 수정을 포함한 모든 권고를 볼 수 있습니다.
2장. 버그 수정
이 섹션에서는 OpenShift 샌드박스 컨테이너 1.8에서 수정된 버그에 대해 설명합니다.
Azure에서 KataConfig 를 삭제할 때 Pod VM 이미지가 삭제됨
이전에는 KataConfig 사용자 지정 리소스를 삭제할 때 Pod VM 이미지가 삭제되지 않았을 수 있었습니다. 필요한 경우 Azure CLI를 사용하여 이미지의 Pod VM 개요를 확인하고 수동으로 삭제해야 하는 해결 방법이 필요합니다.
이 문제는 OpenShift 샌드박스 컨테이너의 1.8.1 릴리스에서 해결되었습니다.
3장. 확인된 문제
이 섹션에서는 OpenShift 샌드박스 컨테이너 1.8의 알려진 문제에 대해 설명합니다.
Azure의 기밀성 컨테이너에 대해 기본적으로 비활성화된 보안 부팅
보안 부팅은 Azure의 기밀성 컨테이너에 대해 기본적으로 비활성화되어 있습니다. 이는 보안 위험입니다. 이 문제를 해결하려면 피어 Pod 구성 맵을 업데이트할 때 ENABLE_SECURE_BOOT 를 true 로 설정합니다.
CPU가 오프라인 상태인 경우 컨테이너 CPU 리소스 제한 증가
요청된 CPU가 오프라인 상태인 경우 컨테이너 CPU 리소스 제한을 사용하여 Pod에 사용 가능한 CPU 수를 늘리십시오. 기능을 사용할 수 있는 경우 oc rsh <pod> 명령을 실행하여 Pod 에 액세스한 다음 lscpu 명령을 실행하여 CPU 리소스 문제를 진단할 수 있습니다.
$ lscpu
출력 예:
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13
오프라인 CPU 목록은 예측할 수 없으며 실행 시 실행으로 변경될 수 있습니다.
이 문제를 해결하려면 다음 예와 같이 Pod 주석을 사용하여 추가 CPU를 요청합니다.
metadata:
annotations:
io.katacontainers.config.hypervisor.default_vcpus: "16"sizeLimit 을 늘리면 임시 볼륨이 확장되지 않습니다.
볼륨 크기 기본값이 샌드박스 컨테이너에 할당된 메모리의 50%이므로 Pod 사양에서 sizeLimit 매개변수를 사용하여 임시 볼륨을 확장할 수 없습니다.
이 문제를 해결하려면 볼륨을 다시 마운트하여 크기를 변경합니다. 예를 들어 샌드박스 컨테이너에 할당된 메모리가 6GB이고 임시 볼륨이 /var/lib/containers 에 마운트된 경우 다음 명령을 실행하여 기본적으로 이 볼륨의 크기를 3GB 이상으로 늘릴 수 있습니다.
$ mount -o remount,size=4G /var/lib/containers
mount 명령은 Pod 내에서 실행해야 합니다. Pod 매니페스트 자체의 일부로 이를 포함하거나 oc rsh 를 실행하고 mount 명령을 실행하여 Pod에서 쉘 세션을 시작할 수 있습니다.
OpenShift 샌드박스 컨테이너 1.7 이상에서는 OpenShift Container Platform 4.14 및 이전 버전에서 작동하지 않습니다.
OpenShift 샌드박스 컨테이너 Operator를 설치하거나 업그레이드하기 전에 OpenShift Container Platform 4.15 이상으로 업그레이드해야 합니다. 자세한 내용은 OpenShift 샌드박스 컨테이너 Operator 1.7을 사용할 수 없으며 OSC 1.7.0으로 업그레이드하여 KnowledgeBase에서 Peer Pod를 ContainerCreating 상태로 실행합니다.
AWS의 Podvm 이미지 빌더에서 스냅샷 뒤를 남겨 둡니다.
Podvm 이미지 빌더는 스냅샷에서 AMI 이미지를 생성하고 적절한 설치 제거 프로세스 AMI가 삭제되는 동안 스냅샷 자체는 삭제되지 않으며 수동 삭제가 필요합니다.
이는 AWS의 모든 피어 Pod 버전에서 수행됩니다.
Jira:KATA-3478
클러스터 해제 전에 적절한 kataconfig 삭제가 없으면 활성 Pod vms가 계속 실행될 수 있었습니다.
피어 Pod 기능이 없으면 OSC 운영자의 설치 제거로 클러스터를 해제할 수 있지만 피어 Pod를 사용하면 Pod가 클러스터 작업자 노드(피어 Pod당 생성된 podvm 인스턴스에서) 외부에서 실행 중이며 클러스터를 종료하기 전에 적절한 kataconfig 삭제가 수행되지 않으면 이러한 podvm 인스턴스가 종료되지 않습니다.
Jira:KATA-3480
4장. 기술 프리뷰
이 섹션에서는 OpenShift 샌드박스 컨테이너 1.8에서 사용할 수 있는 모든 기술 프리뷰 목록을 제공합니다.
자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
IBM Z 및 IBM LinuxONE에 대한 피어 Pod 지원
IBM Z® 및 IBM® LinuxONE(s390x 아키텍처)에서 피어 Pod를 사용하여 중첩된 가상화 없이 OpenShift 샌드박스 컨테이너 워크로드를 배포할 수 있습니다.
Jira:KATA-2030
Microsoft Azure Cloud Computing Services, IBM Z 및 IBM LinuxONE의 기밀 컨테이너
기밀 컨테이너는 클라우드 네이티브 애플리케이션에 대한 향상된 보안을 제공하여 사용 중인 경우에도 컨테이너와 해당 데이터를 보호하는 TEE(신뢰할 수 있는 실행 환경)라는 보안 및 격리된 환경에서 실행할 수 있습니다.
다음 제한 사항을 확인합니다.
- CVM(비밀 가상 머신) 루트 파일 시스템(rootfs)의 암호화 및 무결성 보호 없음: CVM은 TEE 내에서 실행되며 컨테이너 워크로드를 실행합니다. rootfs의 암호화 및 무결성 보호 부족으로 인해 악의적인 관리자가 rootfs에 기록된 중요한 데이터를 추출하거나 rootfs 데이터를 변조할 수 있습니다. rootfs에 대한 무결성 보호 및 암호화는 현재 진행 중입니다. 모든 애플리케이션 쓰기가 메모리에 있는지 확인해야 합니다.
- 암호화된 컨테이너 이미지 지원 없음: 서명된 컨테이너 이미지 지원만 현재 사용할 수 있습니다. 암호화된 컨테이너 이미지 지원이 진행 중입니다.
- Kata shim과 CVM 내부의 에이전트 구성 요소 간의 통신에는 변조가 적용됩니다. CVM 내부의 에이전트 구성 요소는 OpenShift 작업자 노드에서 실행되는 Kata shim에서 Kubernetes API 명령을 실행해야 합니다. CVM에서 컨테이너의 Kubernetes exec 및 로그 API를 해제하는 에이전트 정책을 사용하여 Kubernetes API를 통한 중요한 데이터 유출을 방지합니다. 그러나 이는 완료되지 않으며 shim과 에이전트 구성 요소 간의 통신 채널을 강화하기 위한 추가 작업이 진행 중입니다. 에이전트 정책은 Pod 주석을 사용하여 런타임 시 재정의할 수 있습니다. 현재 Pod의 런타임 정책 주석은 인증 프로세스에서 확인하지 않습니다.
- 암호화된 pod-to-pod 통신에 대한 기본 지원이 없습니다. Pod-to-pod 통신은 암호화되지 않습니다. 모든 pod-to-pod 통신에 대해 애플리케이션 수준에서 TLS를 사용해야 합니다.
- 작업자 노드와 CVM 내부에서 이미지를 이중 가져오기: 컨테이너 이미지가 TEE 내에서 실행되는 CVM에서 다운로드 및 실행됩니다. 그러나 현재 이미지는 작업자 노드에도 다운로드됩니다.
- 기밀 컨테이너를 위한 CVM 이미지를 빌드하려면 클러스터에서 OpenShift 샌드박스 컨테이너 Operator를 사용할 수 있어야 합니다.
Jira:KATA-2416
부록 A. 구성 요소별 티켓 목록
이 문서에는 Bugzilla 및 JIRA 티켓이 기재되어 있습니다. 링크는 티켓을 설명하는 이 문서의 릴리스 노트로 이어집니다.
| Component | 티켓 |
|---|---|
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
