1.4. 주요 기술 변경 사항
OpenShift Container Platform 4.13에는 다음과 같은 주요 기술 변경 사항이 추가되었습니다.
추가 클라우드 공급자를 위한 클라우드 컨트롤러 관리자
Kubernetes 커뮤니티는 클라우드 컨트롤러 관리자를 사용하기 위해 Kubernetes 컨트롤러 관리자 사용을 사용 중단하여 기본 클라우드 플랫폼과 상호 작용할 계획입니다. 따라서 새 클라우드 플랫폼에 대한 Kubernetes 컨트롤러 관리자 지원을 추가할 계획이 없습니다.
이 OpenShift Container Platform 릴리스에 추가된 Nutanix 구현에서는 클라우드 컨트롤러 관리자를 사용합니다. 또한 이 릴리스에서는 VMware vSphere용 클라우드 컨트롤러 관리자를 사용할 수 있는 General Availability를 소개합니다.
클라우드 컨트롤러 관리자에 대한 자세한 내용은 Kubernetes Cloud Controller Manager 설명서 를 참조하십시오.
클라우드 컨트롤러 관리자 및 클라우드 노드 관리자 배포 및 라이프사이클을 관리하려면 Cluster Cloud Controller Manager Operator를 사용합니다.
자세한 내용은 Platform Operator 참조의 Cluster Cloud Controller Manager Operator 항목을 참조하십시오.
MCD에서 일시 중지된 풀에서 kubelet CA 인증서를 동기화
이전에는 MCO(Machine Config Operator)에서 kubelet 클라이언트 인증 기관 (CA) 인증서 /etc/kubernetes/kubelet-ca.crt
를 일반 머신 구성 업데이트의 일부로 업데이트했습니다. OpenShift Container Platform 4.13부터 kubelet-ca.crt
가 일반 머신 구성 업데이트의 일부로 더 이상 업데이트되지 않습니다. 이러한 변경으로 인해 MCD(Machine Config Daemon)는 인증서 변경이 발생할 때마다 kubelet-ca.crt
를 최신 상태로 유지합니다.
또한 머신 구성 풀이 일시 중지된 경우 MCD에서 새로 순환된 인증서를 해당 노드로 푸시할 수 있습니다. 인증서 변경 사항이 포함된 새로 렌더링된 머신 구성이 이전 버전과 같이 풀에 대해 생성됩니다. 풀은 업데이트가 필요함을 나타냅니다. 이 조건은 이 제품의 향후 릴리스에서 제거됩니다. 그러나 인증서가 별도로 업데이트되므로 추가 업데이트가 없다고 가정하여 풀을 일시 정지 상태로 유지하는 것이 안전합니다.
또한 노드에 항상 최신 kubelet-ca.crt
가 있어야 하므로 MachineConfigControllerPausedPoolKubeletCA
경고가 제거되었습니다.
SSH 키 위치 변경
OpenShift Container Platform 4.13에서는 RHEL 9.2 기반 RHCOS가 도입되었습니다. 이번 업데이트 이전에는 RHCOS의 /home/core/.ssh/authorized_keys
에 SSH 키가 있었습니다. 이번 업데이트를 통해 RHEL 9.2 기반 RHCOS에서 SSH 키는 /home/core/.ssh/authorized_keys.d/ignition
에 있습니다.
기본 OpenSSH /etc/ssh/sshd_config
서버 구성 파일을 사용자 지정한 경우 이 Red Hat 지식베이스 문서에 따라 업데이트해야 합니다.
Pod 보안 허용에 대한 향후 제한 적용
현재는 Pod 보안 위반이 감사 로그에 기록되어 경고로 표시되지만 Pod는 거부되지 않습니다.
Pod 보안 허용에 대한 글로벌 제한 적용은 현재 OpenShift Container Platform의 다음 마이너 릴리스에 대해 예정되어 있습니다. 이 제한 적용이 활성화되면 Pod 보안 위반이 있는 Pod가 거부됩니다.
향후 변경을 준비하려면 워크로드가 적용되는 Pod 보안 승인 프로필과 일치하는지 확인합니다. 전역 또는 네임스페이스 수준에서 정의된 시행된 보안 표준에 따라 구성되지 않은 워크로드는 거부됩니다. restricted-v2
SCC는 제한된 Kubernetes 정의에 따라 워크로드를 허용합니다. https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted
Pod 보안 위반을 수신하는 경우 다음 리소스를 참조하십시오.
- Pod 보안 위반을 유발하는 워크로드를 찾는 방법에 대한 정보는 Pod 보안 위반 식별 을 참조하십시오.
Pod 보안 승인 라벨 동기화가 수행되는 시기를 이해하려면 Pod 보안 표준과의 보안 컨텍스트 제약 조건 동기화를 참조하십시오. Pod 보안 허용 라벨은 다음과 같은 특정 상황에서 동기화되지 않습니다.
-
워크로드는
openshift-
가 앞에 있는 시스템 생성 네임스페이스에서 실행됩니다. - 워크로드는 Pod 컨트롤러 없이 직접 생성된 Pod에서 실행됩니다.
-
워크로드는
-
필요한 경우
pod-security.kubernetes.io/enforce
라벨을 설정하여 네임스페이스 또는 Pod에서 사용자 정의 승인 프로필을 설정할 수 있습니다.
oc-mirror 플러그인에서 OpenShift API 끝점에서 그래프 데이터 컨테이너 이미지를 검색
oc-mirror OpenShift CLI(oc
) 플러그인은 GitHub에서 전체 그래프 데이터 리포지토리를 다운로드하는 대신 OpenShift API 끝점에서 그래프 데이터 tarball을 다운로드합니다. 외부 공급업체가 아닌 Red Hat에서 이 데이터를 검색하는 것은 외부 콘텐츠에 대한 엄격한 보안 및 규정 준수 제한이 있는 사용자에게 더 적합합니다.
oc-mirror 플러그인이 다운로드한 데이터는 그래프 데이터 리포지토리에 있지만 OpenShift Update Service에는 필요하지 않은 콘텐츠를 제외합니다. 또한 컨테이너는 UBI 대신 UBI 마이크로를 기본 이미지로 사용하므로 이전보다 훨씬 작은 컨테이너 이미지를 생성합니다.
이러한 변경 사항은 oc-mirror 플러그인의 사용자 워크플로에 영향을 미치지 않습니다.
그래프 데이터 컨테이너 이미지의 Dockerfile이 OpenShift API 끝점에서 검색됨
Dockerfile을 사용하여 OpenShift Update Service의 그래프 데이터 컨테이너 이미지를 생성하는 경우 이제 그래프 데이터 tarball이 GitHub 대신 OpenShift API 끝점에서 다운로드됩니다.
자세한 내용은 OpenShift Update Service 그래프 데이터 컨테이너 이미지 생성을 참조하십시오.
이제 vSphere 사용자 프로비저닝 인프라 클러스터에서 nodeip-configuration 서비스가 활성화됨
OpenShift Container Platform 4.13에서 이제 vSphere 사용자 프로비저닝 인프라 클러스터에서 nodeip-configuration
서비스가 활성화됩니다. 이 서비스는 OpenShift Container Platform에서 노드를 부팅할 때 Kubernetes API 서버와 통신하는 데 사용하는 NIC(네트워크 인터페이스 컨트롤러)를 결정합니다. 드문 경우지만 업그레이드 후 서비스가 잘못된 노드 IP를 선택할 수 있습니다. 이 경우 NODEIP_HINT
기능을 사용하여 원래 노드 IP를 복원할 수 있습니다. 네트워크 문제 해결을 참조하십시오.
Operator SDK 1.28
OpenShift Container Platform 4.13에서는 Operator SDK 1.28을 지원합니다. 이 최신 버전을 설치하거나 업데이트하려면 Operator SDK CLI 설치를 참조하십시오.
Operator SDK 1.28에서는 Kubernetes 1.26을 지원합니다.
Operator SDK 1.25를 사용하여 이전에 생성되거나 유지 관리되는 Operator 프로젝트가 있는 경우 Operator SDK 1.28과의 호환성을 유지하도록 프로젝트를 업데이트합니다.
RHEL 9.2에 따른 RHCOS의 디스크 순서 동작 변경
OpenShift Container Platform 4.13에서는 RHEL 9.2 기반 RHCOS가 도입되었습니다. 이번 업데이트를 통해 심볼릭 디스크 이름 지정이 재부팅 시 변경될 수 있습니다. 이로 인해 설치 후 구성 파일을 적용하거나 서비스 생성을 위해 /dev/sda
와 같은 심볼릭 이름을 사용하는 디스크를 참조하는 노드를 프로비저닝하는 경우 문제가 발생할 수 있습니다. 이 문제의 영향은 구성 중인 구성 요소에 따라 다릅니다. dev/disk/by-id
와 같은 특정 디스크 참조를 포함하여 장치에 특정 이름 지정 체계를 사용하는 것이 좋습니다.
이러한 변경으로 인해 모니터링이 각 노드의 설치 장치에 대한 정보를 수집하는 경우 기존 자동화 워크플로우를 조정해야 할 수 있습니다.
자세한 내용은 RHEL 설명서 를 참조하십시오.
호스팅된 컨트롤 플레인의 백업, 복원 및 재해 복구에 대한 문서
OpenShift Container Platform 4.13 설명서에서 호스팅된 클러스터에서 etcd를 백업 및 복원하고 AWS 리전 내 호스팅 클러스터를 복원하는 절차가 "백업 및 복원" 섹션에서 "호스트 컨트롤 플레인" 섹션으로 이동되었습니다. 내용 자체는 변경되지 않았습니다.