1.4. 새로운 기능 및 개선 사항

RHCOS는 OpenShift Container Platform 4.8과 OpenShift Container Platform 4.7.24 이상에서 RHEL (Red Hat Enterprise Linux) 8.4 패키지를 사용합니다. 이를 통해 최신 수정 사항, 기능 및 향상된 기능은 물론 최신 하드웨어 지원 및 드라이버 업데이트를 받을 수 있습니다. OpenShift Container Platform 4.6은 전체 라이프사이클 동안 RHEL 8.2 EUS 패키지를 계속 사용하는 EUS (Extended Update Support) 릴리스입니다.

스트림 메타데이터는 OpenShift Container Platform을 설치하는 동안 클러스터에 메타데이터를 삽입하기 위한 표준화된 JSON 형식을 제공합니다. 자동화 기능 향상을 위해 새로운 openshift-install coreos print-stream-json 명령은 스크립팅 가능한 머신에서 읽을 수 있는 형식으로 스트림 메타데이터를 출력하는 방법을 제공합니다.

사용자 프로비저닝 설치의 경우 openshift-install 바이너리에는 AWS AMI와 같은 OpenShift Container Platform과 함께 사용하기 위해 테스트된 RHCOS 부팅 이미지에 대한 참조가 포함되어 있습니다. 이제 https://github.com/coreos/stream-metadata-go에서 공식 stream-metadata-go 라이브러리를 사용하여 Go 프로그램에서 스트림 메타데이터를 구문 분석할 수 있습니다.

자세한 내용은 스트림 메타데이터로 RHCOS AMI 액세스를 참조하십시오.

OpenShift Container Platform에는 머신 구성을 생성하고 검증할 수 있도록 Butane config Transpiler가 포함되어 있습니다. 이제 Butane을 사용하여 LUKS 디스크 암호화, 부팅 디스크 미러링 및 사용자 지정 커널 모듈에 대한 머신 구성을 생성하는 것이 좋습니다.

자세한 내용은 Butane 을 사용하여 머신 구성 생성을 참조하십시오.

클라우드 관리자가 이미 사용자 지정 /etc/chrony.conf 구성을 설정한 경우 RHCOS는 더 이상 클라우드 플랫폼에서 기본값으로 PEERNTP=no 옵션을 설정하지 않습니다. 그렇지 않으면 PEERNTP=no 옵션이 기본값으로 계속 설정됩니다. 자세한 내용은 BZ#1924869에서 참조하십시오.

베어 메탈 설치 중에 다중 경로를 활성화하는 것은 OpenShift Container Platform 4.8 이상에서 프로비저닝된 노드에 지원됩니다. 설치된 시스템 자체에서 첫 번째 부팅부터 다중 경로를 사용하도록 커널 인수를 coreos-installer install 명령에 추가하여 다중 경로를 활성화할 수 있습니다. 시스템 구성을 통해 다중 경로를 활성화하면 설치 후 지원을 계속 사용할 수 있지만 OpenShift Container Platform 4.8부터 프로비저닝된 노드에는 설치 후 다중 경로를 활성화하는 것이 좋습니다.

자세한 내용은 RHCOS에서 커널 인수로 멀티패스 활성화를 참조하십시오.

install-config.yaml 파일에서 platform.azure.resourceGroupName 필드를 정의하여 Azure에 클러스터를 설치할 기존 리소스 그룹을 정의할 수 있습니다. 이 리소스 그룹은 비어 있어야 하며 단일 클러스터에만 사용해야 합니다. 클러스터 구성 요소는 리소스 그룹의 모든 리소스에 대한 소유권을 가정합니다.

설치 프로그램의 서비스 주체 범위를 이 리소스 그룹으로 제한하는 경우 해당 환경에서 설치 프로그램에서 사용하는 기타 모든 리소스에 퍼블릭 DNS 영역 및 가상 네트워크와 같은 필수 권한이 있는지 확인해야 합니다. 설치 프로그램을 사용하여 클러스터를 삭제하면 사용자 지정 리소스 그룹이 삭제됩니다.

install-config.yaml 파일에서 compute.platform.aws.iamRole 및 controlPlane.platform.aws.iamRole 필드를 설정하여 머신 인스턴스 프로파일에 기존 Amazon Web Services (AWS) IAM 역할을 정의할 수 있습니다. 이렇게 하면 IAM 역할에 대해 다음을 수행할 수 있습니다.

install-config.yaml 파일에서 platform.aws.hostedZone 필드를 설정하여 클러스터의 기존 Route 53 개인 호스트 영역을 정의할 수 있습니다. 자체 VPC를 제공하는 경우에만 기존 호스팅 영역을 사용할 수 있습니다.

GCP(Google Cloud Platform)용 OpenShift Container Platform 설치 프로그램은 이제 머신 CIDR 내에서 최대한 큰 서브넷을 생성합니다. 이를 통해 클러스터는 적절한 크기의 머신 CIDR을 사용하여 클러스터의 노드 수를 수용할 수 있습니다.

이번 릴리스에서는 모든 노드에 데몬 세트를 배포하는 클러스터 Operator의 업그레이드 기간이 크게 단축되었습니다. 예를 들어 250-노드 테스트 클러스터의 업그레이드 시간은 7.5시간에서 1.5시간으로 줄어들어 추가 노드당 1분 미만으로 업그레이드 시간이 단축되었습니다.

업데이트 할 때 머신 구성 풀이 업데이트를 완료하지 않은 경우 MCO(Machine Config Operator)에서 Upgradeable=False 상태를 머신 구성 클러스터 Operator에 보고합니다. 이 상태는 향후 마이너 업데이트를 차단하지만 향후 패치 업데이트 또는 현재 업데이트를 차단하지 않습니다. 이전에는 작업자 풀이 업데이트를 수행하지 않은 경우에도 컨트롤 플레인 머신 구성 풀의 상태에 따라 MCO에서 Upgradeable 상태를 보고했습니다.

OpenShift Container Platform 4.8에서는 베어 메탈에 설치 관리자 프로비저닝 클러스터를 배포할 때 Fujitsu 하드웨어 및 Fujitsu iRMC 기본 보드 관리 컨트롤러 프로토콜을 사용할 수 있습니다. 현재 Fujitsu는 베어 메탈에 설치 관리자 프로비저닝 설치를 위해 iRMC S5 펌웨어 버전 3.05P 이상을 지원합니다. OpenShift Container Platform 4.8의 개선 사항 및 버그 수정 사항은 다음과 같습니다.

이제 컴퓨팅 머신에 SR-IOV(Single-root I/O Virtualization) 네트워크를 사용하는 RHOSP에 클러스터를 배포할 수 있습니다.

자세한 내용은 SR-IOV 연결 컴퓨팅 머신을 지원하는 OpenStack에 클러스터 설치를 참조하십시오.

이번 업데이트를 통해 Ironic Python Agent에서 세부 검사 중 인터페이스 목록에 VLAN 인터페이스를 보고합니다. 또한 IP 주소는 인터페이스에 포함되어 CSR을 올바르게 생성할 수 있습니다. 결과적으로 VLAN 인터페이스를 포함한 모든 인터페이스에 대해 CSR을 가져올 수 있습니다. 자세한 내용은 BZ#1888712을 참조하십시오.

OSUS(OpenShift Update Service)는 Red Hat Enterprise Linux CoreOS(RHCOS)를 비롯한 OpenShift Container Platform에 대한 무선(OTA; Over-the-Air) 업데이트를 제공합니다. 이전에는 공용 API 뒤에 있는 Red Hat 호스팅 서비스로만 액세스할 수 있었지만 이제 로컬로 설치할 수 있습니다. OpenShift Update Service는 Operator 및 하나 이상의 애플리케이션 인스턴스로 구성되며 이제 OpenShift Container Platform 4.6 이상에서 일반적으로 사용할 수 있습니다.

자세한 내용은 OpenShift 업데이트 서비스 이해를 참조하십시오.

console 및 downloads의 경우 새 ingress 구성 경로 구성 API spec.componentRoutes를 사용하도록 사용자 정의 경로 기능이 구현되었습니다. Console Operator 구성에 사용자 지정 경로 사용자 정의가 이미 포함되어 있지만 console 경로의 경우에만 사용됩니다. console-operator 구성을 통한 경로 구성은 더 이상 사용되지 않습니다. 따라서 console 사용자 정의 경로가 ingress 구성 및 console-operator 구성에 모두 설정된 경우 새 ingress 구성 사용자 정의 경로 구성이 우선합니다.

자세한 내용은 콘솔 경로 사용자 지정을 참조하십시오.

웹 콘솔에서 빠른 시작에 포함된 CLI 코드 조각을 실행할 수 있습니다. 이 기능을 사용하려면 Web Terminal Operator를 설치해야 합니다. Web Terminal Operator를 설치하지 않는 경우 웹 터미널에서 실행되는 웹 터미널 및 코드 조각 작업이 표시되지 않습니다. 또는 Web Terminal Operator가 설치되어 있는지 여부에 관계없이 코드 조각을 클립보드에 복사할 수 있습니다.

이전 버전에서는 빠른 시작 사전 요구 사항이 빠른 시작 카드의 목록 대신 결합된 텍스트로 표시되었습니다. 확장성을 염두에 두고 이제 사전 요구 사항이 카드가 아닌 팝업 메뉴에 표시됩니다.

이번 릴리스에서는 다음을 수행할 수 있습니다.

Default 감사 로그 정책에서는 OAuth 액세스 토큰 생성(로그인) 및 삭제(로그아웃) 요청에 대한 요청 본문을 기록합니다. 이전에는 삭제 요청 본문이 기록되지 않았습니다.

감사 로그 정책에 대한 자세한 내용은 노드 감사 로그 정책 구성을 참조하십시오.

이제 헤드리스 서비스에 대한 서비스 제공 인증서를 생성하면 *.<service.name>.<service.namespace>.svc 형식으로 와일드카드 제목이 포함됩니다. 이렇게 하면 이러한 Pod에 대한 인증서를 수동으로 생성할 필요 없이 개별 상태 저장 세트 Pod에 TLS 보안 연결을 수행할 수 있습니다.

자세한 내용은 서비스 인증서 추가 를 참조하십시오.

Compliance Operator는 OpenShift Container Platform 클러스터에 대한 많은 검사 및 업데이트 적용을 자동화합니다. 그러나 클러스터를 규정 준수 상태로 전환하려면 관리자가 Compliance Operator API 및 기타 구성 요소와 상호 작용해야 하는 경우가 많습니다. oc-compliance 플러그인을 사용할 수 있으며 프로세스를 더 쉽게 수행할 수 있습니다.

자세한 내용은 oc-compliance 플러그인 사용을참조하십시오.

이제 Kubernetes API 서버 TLS 보안 프로파일 설정도 Kubernetes 스케줄러 및 Kubernetes 컨트롤러 관리자에서 지원됩니다.

자세한 내용은 TLS 보안 프로파일 설정을 참조하십시오.

이제 Kubernetes API 서버의 HTTP 서버로 작동할 때 kubelet에 대한 TLS 보안 프로필을 설정할 수 있습니다.

자세한 내용은 TLS 보안 프로파일 설정을 참조하십시오.

이전에는 oauth-proxy 명령에서 인증에 사용되는 htpasswd 파일에서 SHA-1 해시 암호만 사용할 수 있었습니다. oauth-proxy 에는 bcrypt 암호 해시를 사용하는 htpasswd 항목이 지원됩니다. 자세한 내용은 BZ#1874322를 참조하십시오.

OpenShift Container Platform 4.8에서는 프로비저닝된 컨트롤 플레인 및 작업자 노드의 UEFI Secure Boot 모드를 자동으로 활성화하고 노드를 제거할 때 해제하는 기능을 지원합니다. 이 기능을 사용하려면 install-config.yaml 파일에서 노드의 bootMode 구성 설정을 UEFISecureBoot로 설정합니다. Red Hat은 펌웨어 버전 2.75.75.75 이상을 실행하는 10세대 HPE 하드웨어 또는 13세대 Dell 하드웨어에 대한 관리형 Secure Boot를 사용하는 설치 관리자 프로비저닝 설치를 지원합니다. 자세한 내용은 install-config.yaml 파일에서 관리형 Secure Boot 구성에서 참조하십시오.

베어 메탈 인프라에 설치된 클러스터에서 OVN-Kubernetes 클러스터 네트워크 공급자는 IPv4 및 IPv6 주소 제품군을 모두 지원합니다.

이전 버전의 OpenShift Container Platform에서 업그레이드하는 설치 관리자 프로비저닝 베어 메탈 클러스터의 경우 듀얼 스택 네트워킹을 지원하도록 클러스터를 변환해야 합니다. 자세한 내용은 IPv4/IPv6 듀얼 스택 네트워킹으로 변환을 참조하십시오.

사용자 프로비저닝 클러스터에 대해 OpenShift SDN 클러스터 네트워크 공급자를 OVN-Kubernetes 클러스터 네트워크 공급자로의 마이그레이션이 지원됩니다. 자세한 내용은 OpenShift SDN 클러스터 네트워크 공급자에서 마이그이션을 참조하십시오.

OpenShift SDN의 송신 IP 기능은 해당 네임스페이스에 여러 송신 IP 주소가 할당된 경우 지정된 네임스페이스의 노드 간에 네트워크 트래픽을 균등하게 조정합니다. 각 IP 주소는 다른 노드에 있어야 합니다. 자세한 내용은 OpenShift SDN에 대한 프로젝트의 송신 IP 구성을 참조하십시오.

OpenShift SDN 또는 OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 Ingress 컨트롤러가 클러스터 네트워크 또는 호스트 네트워크에서 실행되는지 여부와 관계없이 네트워크 정책 규칙의 Ingress 컨트롤러에서 트래픽을 선택할 수 있습니다. 네트워크 정책 규칙에서 policy-group.network.openshift.io/ingress: "" 네임스페이스 선택기 레이블은 Ingress 컨트롤러의 트래픽과 일치합니다. network.openshift.io/policy-group: ingress 네임스페이스 선택기 레이블을 계속 사용할 수 있지만, 이는 향후 OpenShift Container Platform 릴리스에서 제거할 수 있는 레거시 레이블입니다.

OpenShift Container Platform의 이전 릴리스에서는 다음과 같은 제한 사항이 있었습니다.

자세한 내용은 네트워크 정책 정보를 참조하십시오.

OVN-Kubernetes 클러스터 네트워크 공급자 또는 OpenShift SDN 클러스터 네트워크 공급자를 사용하는 경우 policy-group.network.openshift.io/host-network: "" 네임스페이스 선택기를 사용하여 네트워크 정책 규칙에서 호스트 네트워크 트래픽을 선택할 수 있습니다.

OVN-Kubernetes 클러스터 네트워크 공급자를 사용하는 경우 네임스페이스에서 네트워크 정책에 대한 감사 로깅을 활성화할 수 있습니다. 로그는 syslog 호환 형식이며 로컬에 저장되거나 UDP 연결을 통해 전송되거나 UNIX 도메인 소켓으로 전송할 수 있습니다. 허용된 연결, 드롭된 연결 또는 두 연결을 모두 기록할지 여부를 지정할 수 있습니다. 자세한 내용은 네트워크 정책 이벤트 로깅을 참조하십시오.

NetworkPolicy API를 구현하는 MultiNetworkPolicy API를 사용하여 macvlan 추가 네트워크에 적용되는 네트워크 정책을 생성할 수 있습니다. 자세한 내용은 다중 네트워크 정책 구성을 참조하십시오.

OpenShift Container Platform 4.8에서는 추가 Intel 및 Mellanox 네트워크 인터페이스 컨트롤러를 지원합니다.

자세한 내용은 지원되는 장치를 참조하십시오.

Operator와 함께 배포된 Network Resources Injector는 Downward API를 사용하여 대규모 페이지 요청 및 제한에 대한 정보를 노출하도록 기능이 개선되었습니다. Pod 사양에 대규모 페이지 요청 또는 제한이 포함되어 있으면 /etc/podnetinfo 경로에 정보가 노출됩니다.

자세한 내용은 Downward API 에 대한 대규보 페이지 리소스 주입을 참조하십시오.

OpenShift Container Platform 4.8에는 pod 네트워크의 네트워크 흐름에 대한 메타데이터를 네트워크 흐름 수집기로 보내는 기능이 추가되어 있습니다. 지원되는 프로토콜은 다음과 같습니다.

패킷 데이터는 네트워크 흐름 수집기로 전송되지 않습니다. 프로토콜, 소스 주소, 대상 주소, 포트 번호, 바이트 수, 기타 패킷 수준 정보 등의 패킷 수준 메타데이터가 네트워크 흐름 수집기로 전송됩니다.

자세한 내용은 네트워크 흐름 추적을 참조하십시오.

OpenShift Container Platform 4.8 이상 릴리스에는 클러스터 멤버십 정보를 사용하여 A/AAAA 레코드를 생성하는 기능이 포함되어 있습니다. 이렇게 하면 노드 이름이 해당 IP 주소로 확인됩니다. 노드가 API에 등록되면 클러스터는 CoreDNS-mDNS를 사용하지 않고 노드 정보를 분산할 수 있습니다. 그러면 멀티캐스트 DNS와 연결된 네트워크 트래픽이 제거됩니다.

OpenShift Container Platform은 HAProxy 2.2로 업데이트되어 HTTP 헤더 이름을 Host:xyz.com에서 host: xyz.com과 같이 기본값으로 소문자로 변경합니다. 기존 애플리케이션이 HTTP 헤더 이름의 대문자에 민감한 경우 Ingress Controller spec.httpHeaders.headerNameCaseAdjustments API 필드를 사용하여 기존 애플리케이션을 수정할 때 까지 지원합니다. HAProxy 2.2를 사용 가능하면 OpenShift Container Platform을 업그레이드하기 전에 spec.httpHeaders.headerNameCaseAdjustments를 사용하여 필요한 구성을 추가하십시오.

자세한 내용은 HTTP 헤더 대/소문자 변환을 참조하십시오.

OpenShift Container Platform이 HAProxy 2.2로 업데이트되어 HTTP 헤더에 대한 몇 가지 추가 제한이 적용됩니다. 이러한 제한 사항은 애플리케이션에서 발생할 수 있는 보안 약점을 완화하기 위한 것입니다. 특히 HTTP 요청 줄에서 호스트 이름을 지정하는 HTTP 클라이언트 요청은 요청 행과 요청의 HTTP 호스트 헤더가 모두 지정되거나 포트 번호를 생략하지 않는 경우 거부됩니다. 예를 들어 헤더 host: hostname 을 사용하는 요청 GET http://hostname:80/path 는 호스트 헤더가 아닌 동안 요청 행이 포트 번호를 지정하므로 HTTP 400 "Bad 요청" 응답을 사용하여 거부됩니다. 이 제한의 목적은 요청 smuggling 공격을 완화하기 위한 것입니다.

HTTP/2가 활성화된 경우 이전 버전의 OpenShift Container Platform에서 이 엄격한 HTTP 헤더 검증이 활성화되었습니다. 즉, OpenShift Container Platform 4.7 클러스터에서 HTTP/2를 활성화하고 HTTP 400 오류를 확인하여 문제가 있는 클라이언트 요청을 테스트할 수 있습니다. HTTP/2를 활성화하는 방법에 대한 자세한 내용은 HTTP/2 Ingress 연결 활성화를 참조하십시오.

OpenShift Container Platform 4.8에서는 내부 로드 밸런서를 사용하여 GCP에서 생성된 Ingress 컨트롤러에 대한 글로벌 액세스 옵션을 추가로 지원합니다. 글로벌 액세스 옵션을 활성화하면 로드 밸런서와 동일한 VPC 네트워크 및 컴퓨팅 리전 내의 모든 리전의 클라이언트가 클러스터에서 실행되는 워크로드에 도달할 수 있습니다.

자세한 내용은 GCP에서 Ingress 컨트롤러에 대한 글로벌 액세스 구성을 참조하십시오.

OpenShift Container Platform 4.8에서는 클러스터에서 처리할 수 있는 들어오는 연결의 양을 늘리기 위해 스레드 수를 설정하는 기능을 추가 지원합니다.

자세한 내용은 Ingress 컨트롤러 스레드 수 설정을 참조하십시오.

OpenShift Container Platform 4.8에서는 특히 HostNetwork 또는 NodePortService 엔드포인트 게시 전략 유형의 경우 클라우드가 아닌 플랫폼의 Ingress 컨트롤러에 대한 PROXY 프로토콜을 구성할 수 있도록 지원합니다.

자세한 내용은 Ingress 컨트롤러의 PROXY 프로토콜 구성을 참조하십시오.

OpenShift Container Platform 4.8에서는 설치 관리자 프로비저닝 클러스터는 작업자 노드의 컨트롤 플레인 노드 및 NTP 클라이언트에 NTP(Network Time Protocol) 서버를 구성하고 배포할 수 있습니다. 이를 통해 작업자는 라우팅 가능한 네트워크에서 연결이 끊어진 경우에도 컨트롤 플레인 노드의 NTP 서버에서 날짜와 시간을 검색할 수 있습니다. 배포 후 NTP 서버 및 NTP 클라이언트를 구성하고 배포할 수도 있습니다.

Kuryr-Kubernetes를 사용하는 RHOSP(Red Hat OpenStack Platform)에 OpenShift Container Platform 4.8 배포에서는 default/kubernetes 서비스의 API 로드 밸런서는 더 이상 CNO(Cluster Network Operator)에 의해 관리되지 않고 kuryr-controller 자체에서 대신 관리됩니다. 이는 다음을 의미합니다.

베어 메탈 클러스터에 지원되는 설치 프로그램 및 설치 관리자 프로비저닝 설치는 provisioning 네트워크 없이 클러스터를 배포하는 기능을 제공합니다. OpenShift Container Platform 4.8 이상에서는 CBO(Cluster Baremetal Operator)를 사용하여 설치 후 provisioning 네트워크를 활성화할 수 있습니다.

베어 메탈 설치의 컨트롤 플레인 노드에서 실행하려면 VIP 주소가 필요한 경우 컨트롤 플레인 노드에서 독점적으로 실행하도록 apiVIP 및 ingressVIP VIP 주소를 구성해야 합니다. 기본적으로 OpenShift Container Platform에서는 작업자 머신 구성 풀의 모든 노드가 apiVIP 및 ingressVIP VIP 주소를 호스팅할 수 있습니다. 베어 메탈 환경에서는 컨트롤 플레인 노드의 개별 서브넷에 작업자 노드를 배포하므로 apiVIP 및 ingressVIP 가상 IP 주소를 구성하여 컨트롤 플레인 노드에서 독점적으로 실행하도록 구성하면 별도의 서브넷에 작업자 노드를 배포하여 문제가 발생하지 않습니다. 보다 자세한 내용은 컨트롤 플레인에서 실행하기 위한 네트워크 구성 요소 설정에서 참조하십시오.

OpenShift Container Platform 4.8에서는 RHOSP(Red Hat OpenStack Platform) 및 베어 메탈 설치 관리자 프로비저닝 클러스터의 apiVIP 및 ingressVIP 트래픽을 처리하도록 외부 로드 밸런서를 구성할 수 있습니다. 외부 로드 밸런싱 서비스와 컨트롤 플레인 노드는 동일한 L2 네트워크에서 실행해야 하며 VLAN을 사용하여 로드 밸런싱 서비스와 컨트롤 플레인 노드 간에 트래픽을 라우팅할 때 동일한 VLAN에서 실행해야 합니다.

apiVIP 및 ingressVIP 트래픽을 처리하도록 로드 밸런서를 구성하는 것은 VMware 설치 관리자 프로비저닝 클러스터에 지원되지 않습니다.

OpenShift Container Platform 4.8에는 이중 스택 네트워킹을 사용하도록 구성된 클러스터에 대한 OVN-Kubernetes IPsec 지원이 추가되었습니다.

송신 라우터 CNI 플러그인을 일반적으로 사용할 수 있습니다. EgressRouter API 오브젝트를 지원하도록 Cluster Network Operator 기능이 개선되었습니다. OVN-Kubernetes를 사용하는 클러스터에 송신 라우터를 추가하는 프로세스가 간소화됩니다. 송신 라우터 오브젝트를 생성하면 Operator에서 네트워크 연결 정의 및 배포를 자동으로 추가합니다. 배포의 pod는 송신 라우터 역할을 합니다.

보다 자세한 내용은 송신 라우터 Pod 사용에 대한 고려 사항을 참조하십시오.

베어 메탈 기반의 OpenShift Container Platform 클러스터에서 IP 페일오버가 지원됩니다. IP 페일오버는 keepalived를 사용하여 호스트 집합에서 외부 액세스가 가능한 VIP 주소 집합을 호스팅합니다. 각 VIP는 한 번에 하나의 호스트에서만 서비스를 제공합니다. keepalived 는 VRRP(Virtual Router Redundancy Protocol)를 사용하여 호스트 집합에서 VIP를 제공하는 서비스를 결정합니다. 호스트를 사용할 수 없게 되거나 keepalived 서비스가 응답하지 않는 경우 VIP가 세트의 다른 호스트로 전환됩니다. 즉, 호스트를 사용할 수 있는 한 VIP는 항상 서비스됩니다.

자세한 내용은 IP 페일오버 구성을 참조하십시오.

OpenShift Container Platform 4.8에서는 사용자 정의 노드 선택기 및 허용 오차를 사용하여 특정 노드에서 CoreDNS를 실행하거나 실행하지 않도록 데몬 세트를 구성할 수 있습니다.

자세한 내용은 DNS pod 배치 제어를 참조하십시오.

RHOSP(Red Hat OpenStack Platform)의 OpenShift Container Platform 클러스터에서 이제 모든 배포 유형에 대해 공급자 네트워크를 지원합니다.

클러스터 관리자는 이제 headerBufferMaxRewriteByte 및 headerBufferBytes Ingress 컨트롤러 튜닝 매개변수를 설정하여 Ingress 컨트롤러마다 tune.maxrewrite 및 tune.bufsize HAProxy 메모리 옵션을 구성할 수 있습니다.

보다 자세한 내용은 Ingress 컨트롤러 구성 매개변수에서 참조하십시오.

GCP(Google Cloud Platform) PD(Persistent Disk) CSI(Container Storage Interface) 드라이버는 GCP 환경에서 자동으로 배포 및 관리되므로 드라이버를 수동으로 설치하지 않고도 이러한 볼륨을 동적으로 프로비저닝할 수 있습니다. 이 기능은 이전에 OpenShift Container Platform 4.7에서 기술 프리뷰 기능으로 소개되었으며 현재 OpenShift Container Platform 4.8에서 일반적으로 사용 가능하며 활성화되어 있습니다.

자세한 내용은 GCP PD CSI 드라이버 Operator에서 참조하십시오.

Azure Disk CSI Driver Operator는 PVC(영구 볼륨 클레임)를 생성하는 데 사용할 수 있는 기본 스토리지 클래스 오브젝트를 제공합니다. 이 드라이버를 관리하는 Azure Disk CSI Driver Operator는 기술 프리뷰로 사용할 수 있습니다.

자세한 내용은 Azure Disk CSI Driver Operator에서 참조하십시오.

vSphere CSI Driver Operator는 PVC(영구 볼륨 클레임)를 생성하는 데 사용할 수 있는 기본 스토리지 클래스를 제공합니다. 이 드라이버를 관리하는 vSphere CSI Driver Operator는 기술 프리뷰로 사용할 수 있습니다.

자세한 내용은 vSphere CSI Driver Operator에서 참조하십시오.

OpenShift Container Platform 4.8부터 동등한 CSI 드라이버로 다음 in-tree 볼륨 플러그인에 대한 자동 마이그레이션을 기술 프리뷰 기능으로 사용할 수 있습니다.

자세한 내용은 자동 CSI 마이그레이션을 참조하십시오.

AWS(Amazon Web Services) Elastic File System (EFS) 기술 프리뷰 기능이 제거되어 더 이상 지원되지 않습니다.

이제 설치 중에 Cinder 볼륨의 가용성 영역을 선택할 수 있습니다. 이미지 레지스트리의 특정 가용성 영역에서 Cinder 볼륨을 사용할 수도 있습니다.

OLM(Operator Lifecycle Manager)을 사용하여 Operator를 설치하는 클러스터 관리자는 현재 API 또는 하위 수준 API와 관련된 오류 조건에 직면할 수 있습니다. 이전에는 OLM이 Operator 설치 또는 업데이트 요청을 이행할 수 없는 이유에 대한 정보가 없었습니다. 이러한 오류는 오브젝트 속성의 오타 또는 누락된 RBAC와 같은 간단한 문제부터 메타데이터 구문 분석으로 인해 카탈로그에서 항목을 로드할 수 없는 더 복잡한 문제에 이르기까지 다양할 수 있습니다.

관리자에게 이러한 문제를 성공적으로 디버깅하기 위해 다양한 하위 수준 API 간의 상호 작용 프로세스 또는 OLM Pod 로그로의 액세스에 대한 이해를 요구하지 않기 때문에 OpenShift Container Platform 4.8에서는 OLM의 다음과 같은 개선 사항이 도입되어 관리자에게 보다 이해하기 쉬운 오류 보고 및 메시지를 제공합니다.

InstallPlan 오브젝트에서 정의한 설치 계획에서 API 서버 가용성 또는 다른 작성자와의 충돌로 인해 일시적인 오류가 발생할 수 있습니다. 이전에는 이러한 오류로 인해 수동 정리가 필요한 부분적으로 적용된 설치 계획이 종료되었습니다. 이번 개선된 기능으로 Catalog Operator는 설치 계획 실행 중에 최대 1분 동안 오류를 다시 시도합니다. 새 .status.message 필드는 재시도가 발생할 때 사람이 읽을 수 있는 표시를 제공합니다.

Operator 그룹 또는 여러 Operator 그룹이 없는 네임스페이스에 서브스크립션을 생성하면 이전에 설치 계획을 사용하여 Operator 설치가 중단되고 phase=Installing에 영구적으로 남아 있었습니다. 이번 개선된 기능을 통해 설치 계획이 phase=Failed로 즉시 전환되어 관리자가 잘못된 Operator 그룹을 수정한 다음 서브스크립션을 삭제하고 다시 생성할 수 있습니다.

네임스페이스에서 종속성 확인이 실패할 때 생성되는 ResolutionFailed 이벤트는 이제 참조된 카탈로그 소스에 없는 패키지 또는 채널을 참조하는 서브스크립션이 포함된 경우 네임스페이스에 더 구체적인 텍스트를 제공합니다. 이전에는 이 메시지가 일반적이었습니다.

no candidate operators found matching the spec of subscription '<name>'

이번 개선된 기능을 통해 메시지는 보다 구체화됩니다.

no operators found in package <name> in the catalog referenced by subscription <name>

no operators found from catalog <name> in namespace openshift-marketplace referenced by subscription <name>

no operators found in channel <name> of package <name> in the catalog referenced by subscription <name>

no operators found with name <name>.<version> in channel <name> of package <name> in the catalog referenced by subscription <name>

Operator에 대한 레거시 패키지 매니페스트 형식 지원은 OpenShift Container Platform 4.8 이상에서 제거됩니다. 번들 형식은 OpenShift Container Platform 4.6부터 OLM(Operator Lifecycle Manager)의 기본 Operator 패키징 형식입니다. 더 이상 사용되지 않는 패키지 매니페스트 형식으로 처음 생성된 Operator 프로젝트가 있는 경우 Operator SDK pkgman-to-bundle 명령을 사용하여 프로젝트를 번들 형식으로 마이그레이션할 수 있습니다.

자세한 내용은 번들 형식으로 패키지 매니페스트 프로젝트 마이그레이션을 참조하십시오.

Operator를 설치하고 관리하려면 OLM(Operator Lifecycle Manager)이 클러스터의 카탈로그에서 참조하는 인덱스 이미지에 Operator 번들을 나열해야 합니다. Operator 작성자는 Operator SDK를 사용하여 Operator 및 모든 종속 항목에 대한 번들이 포함된 인덱스를 생성할 수 있습니다. 이 기능은 원격 클러스터에서 테스트하고 컨테이너 레지스트리에 게시하는 데 유용합니다.

자세한 내용은 번들 Operator가 포함된 카탈로그 게시를 참조하십시오.

Operator SDK의 run bundle-upgrade 하위 명령은 최신 버전의 번들 이미지를 지정하여 설치된 Operator가 최신 버전으로 업그레이드되도록 트리거하는 작업을 자동화합니다. 이전에는 하위 명령은 run bundle 하위 명령을 사용하여 처음 설치한 Operator만 업그레이드할 수 있었습니다. 이번 개선된 기능을 통해 이제 기존 OLM(Operator Lifecycle Manager) 워크플로우와 함께 처음 설치된 Operator에서도 run bundle-upgrade가 작동합니다.

보다 자세한 내용은 Operator Lifecycle Manager에서 Operator 업그레이드 테스트에서 참조하십시오.

OpenShift Container Platform 버전에서 API가 제거되면 제거된 API를 계속 사용하는 클러스터 버전에서 실행되는 Operator가 더 이상 제대로 작동하지 않게 됩니다. Operator 작성자는 Operator 사용자의 중단을 방지하기 위해 API 사용 중단 및 제거를 수용하도록 Operator 프로젝트를 업데이트해야 합니다.

자세한 내용은 OpenShift Container Platform 버전과 Operator 호환성 제어를 참조하십시오.

빌드

Telemetry에는 새 openshift:build_by_strategy:sum 게이지 메트릭이 포함되어 있으며 이는 전략 유형별로 빌드 수를 Telemeter Client로 전송합니다. 이 메트릭을 사용하면 사이트 안정성 엔지니어(SRE)와 제품 관리자가 OpenShift Container Platform 클러스터에서 실행되는 빌드 종류를 확인할 수 있습니다.

이전 버전에서는 빌드에서 회사 아티팩트 리포지토리에 액세스하는 데 필요한 클러스터 PKI 인증 기관을 사용할 수 없었습니다. 이제 mountTrustedCA를 true로 설정하여 클러스터 사용자 정의 PKI 인증 기관을 마운트하도록 BuildConfig 오브젝트를 구성할 수 있습니다.

vSphere에서 머신을 실행할 때 MachineAutoscaler 리소스 정의에서 minReplicas 값을 0으로 설정할 수 있습니다. 이 값을 0으로 설정하면 클러스터 자동 스케일러는 시스템이 사용 중인지에 따라 0으로 시스템 집합을 스케일링합니다. 자세한 내용은 MachineAutoscaler 리소스 정의에서 참조하십시오.

/etc/kubernetes/kubelet-ca.crt 인증 기관 (CA) 자동 순환에 더 이상 MCO(Machine Config Operator)가 노드를 드레이닝하거나 클러스터를 재부팅할 필요가 없습니다.

이번 변경의 일환으로 다음과 같은 수정 사항에 따라 MCO가 노드를 드레이닝할 필요가 없습니다.

MCO가 이러한 변경 사항을 감지하면 변경 사항을 적용한 다음 노드를 분리합니다.

자세한 내용은 Machine Config Operator 이해를 참조하십시오.

이전 버전에서는 머신 세트를 생성하려면 사용자가 CPU 고정 설정, NUMA 고정 설정, CPU 토폴로지 변경 등을 수동으로 구성해야 호스트에서 성능을 개선할 수 있었습니다. 이번 개선된 기능을 통해 사용자는 MachineSet 리소스에서 정책을 선택하여 설정을 자동으로 채울 수 있습니다. 자세한 내용은 BZ#1941334에서 참조하십시오.

이제 MachineSet 리소스에 hugepages 속성을 제공할 수 있습니다. 이번 개선된 기능으로 oVirt에서 사용자 지정 속성을 사용하여 MachineSet 리소스의 노드를 생성하고 이러한 노드에 하이퍼바이저의 hugepages를 사용하도록 지시합니다. 자세한 내용은 BZ#1948963에서 참조하십시오.

OpenShift Container Platform 4.8은 선택한 ImageContentSourcePolicy 개체 변경에 대한 워크로드 중단을 방지할 수 있습니다. 이 기능을 사용하면 사용자와 팀이 워크로드 중단 없이 미러 및 레지스트리를 추가할 수 있습니다. 결과적으로 /etc/containers/registries.conf 파일에서 다음과 같은 변경에 대해 워크로드 중단이 더 이상 발생하지 않습니다.

/etc/containers/registries.conf 파일의 다른 변경 사항의 경우 Machine Config Operator는 기본적으로 노드를 드레이닝하여 변경 사항을 적용합니다. 자세한 내용은 BZ#1943315에서 참조하십시오.

이제 Descheduler에 operator.openshift.io/v1 API 그룹을 사용할 수 있습니다. Descheduler의 operator.openshift.io/v1beta1 API 그룹에 대한 지원은 향후 릴리스에서 제거될 수 있습니다.

Descheduler를 설치한 openshift-kube-descheduler-operator 네임스페이스에 openshift.io/cluster-monitoring=true 레이블을 추가하여 Descheduler에 대한 Prometheus 지표를 활성화할 수 있습니다.

다음 Descheduler 지표를 사용할 수 있습니다.

이번 릴리스에서는 Pod 사양에서 Huge Page에 대한 요청 및 제한을 설정하면 Downward API를 사용하여 컨테이너 내에서 Pod 할당을 표시할 수 있습니다. 이러한 개선 사항은 DownwardAPIHugePages 기능 게이트를 사용합니다. OpenShift Container Platform 4.8에서는 기능 게이트를 활성화합니다.

자세한 내용은 Downward API를 사용하여 Huge Page 리소스 사용을 참조하십시오.

NFD(노드 기능 검색) Operator는 OpenShift Container Platform 클러스터의 각 노드에서 사용 가능한 하드웨어 기능을 탐지합니다. 그런 다음 노드 레이블을 사용하여 노드 오브젝트를 수정합니다. 이를 통해 NFD Operator에서 특정 노드의 기능을 알릴 수 있습니다. OpenShift Container Platform 4.8에서는 NFD Operator에 대한 세 가지 추가 레이블을 지원합니다.

Poison Pill Operator를 사용하여 비정상적인 노드를 자동으로 재부팅할 수 있습니다. 따라서 상태 저장 애플리케이션 및 RWO(ReadWriteOnce) 볼륨의 다운 타임을 최소화하고 일시적인 오류가 발생하면 컴퓨팅 용량을 복원합니다.

Poison Pill Operator는 모든 클러스터 및 하드웨어 유형에서 작동합니다.

자세한 내용은 Poison Pill Operator를 사용하여 노드 해결을 참조하십시오.

/etc/kubernetes/kubelet-ca.crt 인증 기관 (CA) 자동 순환에 더 이상 MCO(Machine Config Operator)가 노드를 드레이닝하거나 클러스터를 재부팅할 필요가 없습니다.

이번 변경의 일환으로 다음과 같은 수정 사항에 따라 MCO가 노드를 드레이닝할 필요가 없습니다.

MCO가 이러한 변경 사항을 감지하면 변경 사항을 적용한 다음 노드를 분리합니다.

자세한 내용은 Machine Config Operator 이해를 참조하십시오.

이제 OpenShift Container Platform VPA(Vertical Pod Autoscaler)를 일반적으로 사용할 수 있습니다. VPA는 Pod의 컨테이너 상태와 현재 CPU 및 메모리 리소스를 자동으로 확인하고 확인된 사용량에 따라 리소스 제한 및 요청을 업데이트할 수 있습니다.

아래 설명된 대로 VerticalPodAutoscalerController 오브젝트를 수정하여 하나의 복제본만 필요한 Pod와 함께 VPA를 사용할 수도 있습니다. 이전에는 VPA에서 두 개 이상의 복제본이 필요한 Pod에서만 작동했습니다.

보다 자세한 내용은 수직 Pod 자동 스케일러를 사용하여 Pod 리소스 수준 자동 조정에서 참조하십시오.

기본적으로 워크로드 오브젝트는 VPA가 Pod를 자동으로 업데이트할 수 있도록 최소 두 개의 복제본을 지정해야 합니다. 따라서 두 개 미만의 복제본을 지정하는 워크로드 오브젝트는 VPA에서 작동하지 않습니다. minReplicas 매개변수를 추가하도록 VerticalPodAutoscalerController 오브젝트를 수정하여 클러스터 전체 최소 값을 변경할 수 있습니다.

보다 자세한 내용은 수직 Pod 자동 스케일러를 사용하여 Pod 리소스 수준 자동 조정에서 참조하십시오.

OpenShift Container Platform은 노드가 시작될 때 system-reserved 설정의 최적의 크기 값을 자동으로 확인할 수 있습니다. 이전에는 system-reserved 설정의 CPU 및 메모리 할당이 수동으로 설정하는 데 필요한 고정된 제한사항이었습니다.

자동 리소스 할당이 활성화되면 각 노드의 스크립트가 노드에 설치된 CPU 및 메모리 용량을 기반으로 예약된 각각의 리소스에 최적 값이 계산됩니다.

자세한 내용은 노드의 리소스 자동 할당을 참조하십시오.

이제 이미지 풀 및 푸시를 위해 허용되거나 차단된 레지스트리 목록을 생성할 때 레지스트리 내에서 별도의 리포지토리를 지정할 수 있습니다. 이전 버전에서는 레지스트리만 지정할 수 있었습니다.

자세한 내용은 특정 레지스트리 추가 및 특정 레지스트리 차단을 참조하십시오.

이제 cron 작업 사용자 정의 리소스를 일반적으로 사용할 수 있습니다. 이러한 변경의 일환으로 cron 작업의 성능을 크게 개선하는 새 컨트롤러가 구현되었습니다. cron 작업에 대한 자세한 내용은 작업 및 cron 작업 이해를 참조하십시오.

OpenShift Container Platform 4.8에는 다음 경고 규칙 변경 사항이 포함됩니다.

OpenShift Container Platform 4.8에서는 다음 릴리스에서 제거될 API를 사용할 때 실행되는 두 개의 새 경고가 도입되었습니다.

새 APIRequestCount API를 사용하여 더 이상 사용되지 않는 API를 사용하는 항목을 추적할 수 있습니다. 이를 통해 다음 릴리스로 업그레이드하기 위한 작업이 필요한지 여부를 계획할 수 있습니다.

OpenShift Container Platform 4.8에는 다음과 같은 모니터링 스택 구성 요소 및 종속 항목에 대한 버전 업데이트가 포함되어 있습니다.

kube-state-metrics가 버전 2.0.0으로 업그레이드되었습니다. 다음 메트릭은 kube-state-metrics 버전 1.9에서 더 이상 사용되지 않으며 버전 2.0.0에서 제거됩니다.

타사 Alertmanager UI에 대한 링크는 OpenShift Container Platform 웹 콘솔의 모니터링 경고 페이지에서 제거됩니다. 또한 타사 Grafana UI에 대한 링크는 모니터링 대시보드 페이지에서 제거됩니다. openshift-monitoring 프로젝트의 네트워킹 경로 페이지로 이동하여 관리자 화면의 웹 콘솔에서 Grafana 및 Alertmanager UI에 대한 경로에 계속 액세스할 수 있습니다.

OpenShift Container Platform 웹 콘솔의 모니터링 대시보드 페이지에서 새로운 확장 기능을 사용할 수 있습니다.

단일 노드 클러스터에서 테스트를 실행하면 SR-IOV 및 SCTP 테스트를 포함하여 특정 테스트에 시간 초과가 발생하고 컨트롤 플레인 및 작업자 노드가 필요한 테스트를 건너뜁니다. 노드를 재부팅해야 하는 구성으로 인해 OpenShift 컨트롤 플레인을 비롯한 전체 환경이 재부팅되므로 완료하는 데 시간이 더 오래 걸립니다. 컨트롤 플레인 노드 및 작업자 노드가 필요한 모든 PTP 테스트는 건너뜁니다. 테스트를 시작할 때 노드 수를 확인하고 그에 따라 테스트 동작을 조정하기 때문에 추가 구성이 필요하지 않습니다.

검색 모드에서 PTP 테스트를 실행할 수 있습니다. 테스트에서는 클러스터 외부에서 구성된 PTP 컨트롤 플레인을 검색합니다. 다음 매개 변수가 필요합니다.

Performance Addon Operator를 사용하면 성능 프로필을 구성하여 각 네트워크 장치에 대한 NIC (Network Interface Card) 대기열 수를 조정할 수 있습니다. 장치 네트워크 대기열을 사용하면 패킷을 여러 물리적 대기열에 분산할 수 있으며 각 대기열은 패킷 처리를 위해 별도의 스레드를 가져옵니다.

DPDK(Data Plane Development Kit) 기반 워크로드의 경우 NIC 대기열을 예약된 CPU 또는 하우스키핑 CPU 수로 줄여 대기 시간을 단축하는 것이 중요합니다.

자세한 내용은 Performance Addon Operator를 사용하여 NIC 대기열 단축을 참조하십시오.

OpenShift Container Platform 4.8의 클러스터 최대값 지침이 업데이트되었습니다.

해당 환경의 클러스터 한도를 추정하려면 OpenShift Container Platform Limit Calculator를 사용하십시오.

이제 PPC (Performance Profile Creator) 툴을 사용하여 성능 프로파일을 생성할 수 있습니다. 툴은 클러스터의 must-gather 데이터와 여러 사용자 지정 프로파일 인수를 소비하고, 이 정보를 사용하여 하드웨어 및 토폴로지에 적합한 성능 프로파일을 생성합니다.

자세한 내용은 성능 프로파일 생성을 참조하십시오.

이제 NFD(Node Feature Discovery) Operator를 사용할 수 있습니다. 이를 사용하여 하드웨어 기능과 시스템 구성을 감지하기 위한 Kubernetes 애드온 기능인 NFD(Node Feature Discovery)을 오케스트레이션하여 노드 수준 정보를 노출합니다.

이제 Kubernetes에서 특수 소프트웨어 및 하드웨어 장치를 활성화할 수 있도록 드라이버 툴킷(Driver Toolkit)을 드라이버 컨테이너의 기본 이미지로 사용할 수 있습니다. 현재 기술 프리뷰 기능입니다.

새로운 개선 사항에서는 백업 후와 복원 전에 etcd 스냅샷의 상태를 확인합니다. 이전 버전에서는 백업 프로세스가 스냅샷이 완료되었는지 확인하지 않았으며 복원 프로세스에서 복원된 스냅샷이 손상되지 않고 유효한지 확인하지 못했습니다. 이제 백업 또는 복원 중에 디스크가 손상되면 관리자에게 오류가 명확하게 보고됩니다. 자세한 내용은 BZ#1965024에서 참조하십시오.

OpenShift Container Platform 4.8에서는 제한된 네트워크에서 작업하는 사용자가 Insights Operator 아카이브를 Insights Advisor에 수집하고 업로드하여 잠재적인 문제를 진단할 수 있습니다. 또한 사용자는 업로드하기 전에 Insights Operator 아카이브에 포함된 중요한 데이터를 읽을 수 있습니다.

자세한 내용은 네트워크가 제한된 환경에서 원격 상태 보고 사용을 참조하십시오.

OpenShift Container Platform 웹 콘솔의 Insights Advisor에서 0개의 문제를 발견한 것으로 보고했던 것을 이제 올바르게 보고합니다. 이전에는 Insights Advisor는 정보를 제공하지 않았습니다.

OpenShift Container Platform 4.8에서 Insights Operator는 다음과 같은 추가 정보를 수집합니다.

Red Hat은 이러한 추가 정보를 사용하여 Insights Advisor에서 개선된 수정 단계를 제공할 수 있습니다.

Insights Operator는 이제 비정상적인 SAP Pod에 대한 데이터를 수집할 수 있습니다. SDI 설치에 실패하면 초기화 Pod 중 실패한 항목을 확인하여 문제를 발견할 수 있습니다. 이제 Insights Operator에서 SAP/SDI 네임스페이스에서 실패한 Pod에 대한 정보를 수집할 수 있습니다. 자세한 내용은 BZ#1930393에서 참조하십시오.

Insights Operator는 이제 SAP 클러스터에서 Datahubs 리소스를 수집할 수 있습니다. 이 데이터를 사용하면 SAP 클러스터에서만 수집된 모든 데이터가 누락되어 클러스터에 SDI 설치 여부를 확인할 수 없는 경우에도 SAP 클러스터를 Insights Operator 아카이브의 비SAP 클러스터와 구분할 수 있습니다. 자세한 내용은 BZ#1940432에서 참조하십시오.

Amazon Web Services Security Token Service (AWS STS)를 사용하도록 Cloud Credential Operator (CCO) 유틸리티 (ccoctl)를 설정할 수 있습니다. CCO가 STS를 사용하도록 구성되면 단기적이고 제한된 권한 보안 인증 정보를 제공하는 IAM 역할을 구성 요소에 할당합니다.

이 기능은 이전에 OpenShift Container Platform 4.7에서 기술 프리뷰 기능으로 소개되었으며 현재 OpenShift Container Platform 4.8에서 일반적으로 사용할 수 있습니다.

자세한 내용은 STS로 수동 모드 사용을 참조하십시오.

OpenShift 샌드박스 컨테이너 새 기능, 버그 수정, 알려진 문제 및 비동기 에라타 업데이트를 검토하려면 OpenShift 샌드박스 컨테이너 1.0 릴리스 노트 를 참조하십시오.