1.8. 확인된 문제

OpenShift Container Platform 4.1에서는 익명 사용자가 검색 엔드 포인트에 액세스할 수 있었습니다. 이후 릴리스에서는 일부 검색 끝점이 통합된 API 서버로 전달되기 때문에 보안 악용에 대한 가능성을 줄이기 위해 이 액세스를 취소했습니다. 그러나 인증되지 않은 액세스는 기존 사용 사례가 손상되지 않도록 업그레이드된 클러스터에 보존됩니다.

OpenShift Container Platform 4.1에서 4.14로 업그레이드된 클러스터의 클러스터 관리자인 경우 인증되지 않은 액세스를 취소하거나 계속 허용할 수 있습니다. 인증되지 않은 액세스가 필요하지 않은 경우 해당 액세스를 취소해야 합니다. 인증되지 않은 액세스를 계속 허용하는 경우 이에 따라 보안 위험이 증가될 수 있다는 점에 유의하십시오.

다음 스크립트를 사용하여 감지 끝점에 대한 인증되지 않은 액세스를 취소하십시오.

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

이 스크립트는 인증되지 않은 주제를 다음 클러스터 역할 바인딩에서 제거합니다.

(BZ#1821771)

설치 프로그램에서 GCP(Google Cloud Platform) 서비스 계정과 연결된 모든 프로젝트를 가져올 수 없는 경우 컨텍스트 데드라인 초과 오류 메시지와 함께 설치에 실패합니다.

이 동작은 다음 조건이 충족되면 발생합니다.

다음 알려진 문제는 릴리스 후보 3 또는 4를 사용하여 OpenShift Container Platform 배포를 초기 액세스 버전으로 업데이트한 사용자에게 적용됩니다.

노드 식별 기능이 도입되면 root로 실행 중인 일부 Pod가 권한이 없는 실행을 위해 업데이트됩니다. OpenShift Container Platform 4.14의 초기 액세스 버전으로 업데이트된 사용자의 경우 4.14 공식 버전으로 업그레이드하려고 하면 진행되지 않을 수 있습니다. 이 시나리오에서 Network Operator는 다음 상태를 보고하여 update: DaemonSet "/openshift-network-node-identity/network-node-identity" 업데이트가 롤링임을 나타냅니다.

이 문제를 해결하려면 다음 명령을 실행하여 openshift-network-node-identify 네임스페이스의 모든 Pod를 삭제할 수 있습니다. oc delete --force=true -n openshift-network-node-identity --all pod. 이 명령을 실행하면 업데이트가 계속됩니다.

초기 액세스에 대한 자세한 내용은 candidate-4.14 채널.

OpenShift Container Platform 4.14에서 모든 노드는 기본 RHEL 9 구성과 일치하는 내부 리소스 관리를 위해 Linux 제어 그룹 버전 2(cgroup v2)를 사용합니다. 그러나 클러스터에 성능 프로필을 적용하면 성능 프로필과 관련된 대기 시간이 짧은 튜닝 기능이 cgroup v2를 지원하지 않습니다.

결과적으로 성능 프로필을 적용하면 클러스터의 모든 노드가 재부팅되어 cgroup v1 구성으로 다시 전환합니다. 이 재부팅에는 성능 프로필의 대상이 아닌 컨트롤 플레인 노드 및 작업자 노드가 포함됩니다.

클러스터의 모든 노드를 cgroups v2 구성으로 되돌리려면 Node 리소스를 편집해야 합니다. 자세한 내용은 Linux cgroup v2 구성을 참조하십시오. 마지막 성능 프로필을 제거하여 클러스터를 cgroups v2 구성으로 되돌릴 수 없습니다. (OCPBUGS-16976)

OpenShift Container Platform 4.14부터는 라우터 역할을 하는 노드가 있는 클러스터 관리자에게 바람직하지 않은 영향을 방지하기 위해 OVN-Kubernetes 기반 클러스터 배포에서 글로벌 IP 주소 전달이 비활성화됩니다. OVN-Kubernetes는 이제 관리형 인터페이스별로 전달을 활성화하고 제한합니다.

네트워크 리소스에서 gatewayConfig.ipForwarding 사양을 사용하여 OVN-Kubernetes 관리 인터페이스에서 모든 트래픽에 대한 IP 전달을 제어할 수 있습니다. OVN-Kubernetes와 관련된 모든 트래픽을 전달하려면 제한 사항을 지정합니다. 모든 IP 트래픽을 전달할 수 있도록 Global 을 지정합니다. 새 설치의 경우 기본값은 Restricted 입니다. 4.14로 업그레이드하는 경우 기본값은 Global 입니다. (OCPBUGS-3176) (OCPBUGS-16051)

현재 Kubernetes 관련 문제로 인해 CPU 관리자는 마지막 Pod의 CPU 리소스를 노드에 사용 가능한 CPU 리소스 풀로 반환할 수 없습니다. 후속 Pod가 노드에 허용되면 이러한 리소스를 할당할 수 있습니다. 그러나 이렇게 하면 마지막 포드가 됩니다. CPU 관리자는 이 Pod의 리소스를 사용 가능한 풀로 되돌릴 수 없습니다.

이 문제는 CPU 부하 분산 기능에 영향을 미칩니다. 이러한 기능은 사용 가능한 풀로 CPU 관리자를 해제하는 CPU 관리자에 따라 다릅니다. 결과적으로 보장되지 않는 Pod가 적은 CPU 수로 실행될 수 있었습니다. 이 문제를 해결하려면 영향을 받는 노드에서 가장 적합한 CPU 관리자 정책을 사용하여 Pod를 예약합니다. 이 Pod는 마지막 Pod가 되어 리소스가 사용 가능한 풀로 올바르게 릴리스되도록 합니다. (OCPBUGS-17792)

듀얼 스택 네트워크를 사용하는 환경에서 호스팅 클러스터를 생성할 때 다음과 같은 DNS 관련 문제가 발생할 수 있습니다.

이러한 문제를 해결하려면 듀얼 스택 네트워크의 DNS 구성 지침에 따라 DNS 서버 설정을 구성합니다. (OCPBUGS-22753, OCPBUGS-23234)

OpenShift Container Platform의 호스트된 컨트롤 플레인에서는 다음 Operator 및 구성 요소가 테스트되지 않습니다(OCPSTRAT-605).

노드 테인트를 제거하지 못하여 vSphere의 에이전트 기반 설치가 실패하여 설치가 보류 중 상태가 됩니다. 단일 노드 OpenShift 클러스터는 영향을 받지 않습니다. 다음 명령을 실행하여 노드 테인트를 수동으로 삭제하여 이 문제를 해결할 수 있습니다.

$ oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-

(OCPBUGS-20049)

이 릴리스의 기술 프리뷰 기능인 Azure 기밀 가상 머신을 사용하는 데 알려진 문제가 있습니다. 컨트롤 플레인 프로비저닝 프로세스가 30분 후에 시간 초과되므로 이 기능을 사용하도록 구성된 클러스터를 설치할 수 없습니다.

이 경우 설치를 완료하기 위해 openshift-install create cluster 명령을 두 번 실행할 수 있습니다.

이 문제를 방지하려면 머신 세트를 사용하여 기존 클러스터에서 기밀 VM을 활성화할 수 있습니다. (OCPBUGS-18488)

마스터 클록(T-GM)으로 구성된 Intel Westport Channel e810 NIC의 글로벌 탐색 Satellite 시스템(GNSS) 모듈은 GPS FIX 상태 및 GNSS 모듈과 GNSS 연결 위성 간의 GNSS 오프셋을 보고할 수 있습니다.

현재 T-GM 구현에서는 ubxtool CLI를 사용하여 GNSS 오프셋 및 GPS FIX 값을 읽기 위해 ublox 모듈을 조사하지 않습니다. 대신 gpsd 서비스를 사용하여 GPS FIX 정보를 읽습니다. 이는 ubxtool CLI의 현재 구현이 응답을 수신하는 데 2초가 걸리며 모든 호출과 함께 CPU 사용량이 3배 증가하기 때문입니다. (OCPBUGS-17422)

컨트롤 플레인 노드에 예약된 Microsoft Azure File NFS 볼륨을 사용하여 Pod를 생성하면 마운트가 거부됩니다.

이 문제를 해결하려면 컨트롤 플레인 노드를 예약할 수 있고 작업자 노드에서 Pod를 실행할 수 있는 경우 nodeSelector 또는 Affinity를 사용하여 작업자 노드에서 Pod를 예약합니다. (OCPBUGS-18581)

현재 OpenShift Container Platform 4.14에서 HAProxy 버전 2.6.13으로 업데이트하면 트래픽 재암호화에 P99 대기 시간이 증가합니다. 이는 Ingress 트래픽 볼륨이 IngressController CR(사용자 정의 리소스)의 HAProxy 구성 요소를 상당한 부하에 배치하는 경우 관찰됩니다. 대기 시간 증가는 전체 처리량에 영향을 주지 않으므로 일관성이 유지됩니다.

기본 IngressController CR은 4개의 HAProxy 스레드로 구성됩니다. 특히 트래픽이 재암호화되는 트래픽이 많은 동안 P99 대기 시간이 증가한 경우 대기 시간을 줄이기 위해 HAProxy 스레드 수를 늘리는 것이 좋습니다. (OCPBUGS-18936)

기능을 비활성화한 Single-node OpenShift에서 openshift-controller-manager-operator 를 지속적으로 다시 시작할 수 있습니다. 이 문제를 해결하려면 빌드 기능을 활성화하거나 builds.config.openshift.io CRD를 수동으로 생성합니다.

다음 단계를 수행하여 builds.config.openshift.io CRD를 수동으로 생성합니다.

(OCPBUGS-21778)

버전 4.14.2 이전의 OpenShift Container Platform 4.14 버전에서 Azure AD Workload Identity를 사용하는 Microsoft Azure 클러스터에 알려진 문제가 있습니다. eastus 리전의 새 Azure 스토리지 계정에 대한 기본 보안 설정을 최근 변경하면 해당 리전에서 Azure AD 워크로드 ID를 사용하는 클러스터를 설치할 수 없습니다. 현재 다른 지역은 영향을 받지 않지만 향후 영향을 받을 수 있습니다.

이 문제는 OpenShift Container Platform 4.14.2 에서 해결되었습니다.

이 문제를 해결하려면 단기 인증 정보를 사용하도록 Azure 클러스터 구성 절차에서 ccoctl azure create-all 을 실행하기 전에 공용 액세스를 허용하는 스토리지 계정을 수동으로 생성합니다.

다음 단계를 수행합니다.

(OCPBUGS-22651)