1.8. 확인된 문제
OpenShift Container Platform 4.1에서는 익명 사용자가 검색 엔드 포인트에 액세스할 수 있었습니다. 이후 릴리스에서는 일부 검색 끝점이 통합된 API 서버로 전달되기 때문에 보안 악용에 대한 가능성을 줄이기 위해 이 액세스를 취소했습니다. 그러나 인증되지 않은 액세스는 기존 사용 사례가 손상되지 않도록 업그레이드된 클러스터에 보존됩니다.
OpenShift Container Platform 4.1에서 4.7로 업그레이드된 클러스터의 클러스터 관리자인 경우 인증되지 않은 액세스를 취소하거나 계속 허용할 수 있습니다. 특별히 필요한 경우가 아니면 인증되지 않은 액세스를 취소하는 것이 좋습니다. 인증되지 않은 액세스를 계속 허용하는 경우 이에 따라 보안 위험이 증가될 수 있다는 점에 유의하십시오.
주의인증되지 않은 액세스에 의존하는 애플리케이션이있는 경우 인증되지 않은 액세스를 취소하면 HTTP
403
오류가 발생할 수 있습니다.다음 스크립트를 사용하여 감지 끝점에 대한 인증되지 않은 액세스를 취소하십시오.
## 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
이 스크립트는 인증되지 않은 주제를 다음 클러스터 역할 바인딩에서 제거합니다.
-
cluster-status-binding
-
discovery
-
system:basic-user
-
system:discovery
-
system:openshift:discovery
-
사용자 프로비저닝 인프라를 사용하여 vSphere의 가상 머신의 전원을 켜는 경우 노드를 확장하는 프로세스가 예상대로 작동하지 않을 수 있습니다. 하이퍼바이저 구성에서 알려진 문제로 인해 시스템이 하이퍼바이저 내에 생성되지만 전원이 켜지지 않습니다. 머신 세트를 확장한 후 노드가
Provisioning
상태에 있는 것으로 표시되면 vSphere 인스턴스 자체에서 가상 머신의 상태를 조사할 수 있습니다. VMware 명령govc tasks
및govc events
이벤트를 사용하여 가상 시스템의 상태를 확인합니다. 다음과 유사한 오류 메시지가 있는지 확인합니다.[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]
이 VMware KBase 문서의 지침에 따라 문제를 해결할 수 있습니다. 자세한 내용은 Red Hat Knowledgebase 솔루션 [UPI vSphere] 노드 확장이 예상대로 작동하지 않음을 참조하십시오. (BZ#1918383)
x86_64
아키텍처를 사용하는 클러스터를 실행 중이고install-config.yaml
파일에platform: none
필드가 설정되어 있는 경우 OpenShift Container Platform 클러스터 버전 4.7에 새 설치 또는 클러스터 버전 4.6에서 버전 4.7으로 업그레이드가 실패할 수 있습니다. 이 오류는 클러스터가 가상 하드웨어 버전 14 이상으로 구성된 VM(가상 머신)을 사용하는 경우 발생합니다. 이 문제를 해결하기 위해 가상 하드웨어 버전 13을 사용하도록 VM을 구성할 수 있습니다.VMware VMC( VMware Cloud)에 배포된 클러스터는 가상 하드웨어 버전 14 이상에서 이러한 문제가 발생하지 않습니다. (BZ#1941714)
- Prometheus의 PVC로 연결된 클러스터 모니터링을 실행 중인 경우 OpenShift Container Platform 4.7로 업그레이드하는 동안 OOM이 종료될 수 있습니다. Prometheus에 영구 저장소를 사용하는 경우 클러스터 업그레이드 중 그리고 업그레이드가 완료된 후 몇 시간 동안 Prometheus 메모리 사용량이 두 배로 증가합니다. OOM 종료 문제가 발생하지 않도록 하려면 업그레이드 전에 사용 가능한 메모리 크기의 두 배인 작업자 노드를 허용합니다. (BZ#1925061)
pod를 시작 및 중지하면 Pod가
Terminating
상태로 유지될 수 있습니다. 이 문제를 해결하려면 다음 명령을 실행하여 정지 상태의 Pod를 제거해야 합니다.$ oc delete --force -n <project_name> <pod_name>
이는 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. (BZ#1929463)
- RHCOS 실시간(RT) 커널은 현재 컨트롤 플레인 노드가 아닌 컴퓨팅 노드에서만 지원됩니다. OpenShift Container Platform 4.7의 RT 커널에서는 컴팩트 클러스터가 지원되지 않습니다. (BZ#1887007)
- 현재 OpenShift Container Platform 제한으로 인해 AWS C2S 시크릿 지역에 설치된 클러스터에서 기술 프리뷰 기능인 AWS Secure Token Service (STS)를 사용할 수 없습니다. 이는 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. (BZ#1927157)
- Red Hat의 권장 CloudFormation 템플릿을 기반으로 자체 인프라를 사용하여 AWS C2S 시크릿 리전에 클러스터를 설치하면 설치 프로세스 중에 부트스트랩 노드를 생성하는 문제로 인해 작동하지 않습니다. (BZ#1924080)
Performance Addon Operator를 4.6에서 4.7로 업그레이드하면 오류와 함께 실패합니다.
"Warning TooManyOperatorGroups 11m operator-lifecycle-manager csv created in namespace with multiple operatorgroups, can't pick one automatically"
업그레이드하기 전 이전에 특정 네임스페이스에 설치된 경우 Performance Addon Operator 업그레이드에 설명된 절차를 따릅니다.
지원되는 NIC에서 SR-IOV 변경 사항을 적용하려면 재부팅이 필요합니다. 현재 SR-IOV는 준비 상태가 되면 재부팅을 수행합니다. Machine Config 정책 변경과 함께 이 노드를 재부팅하는 경우 노드가 확인되지 않은 상태로 유지될 수 있습니다. Machine Config Operator는 업데이트된 정책이 적용되지 않은 경우 적용된 것으로 가정합니다.
참고이 경합 상태는 MCP 및 SR-IOV 변경 사항이 있는 Machine Config Pool에 노드를 추가하여 발생할 수도 있습니다.
이 문제를 방지하려면 MCO 및 SR-IOV 변경이 필요한 새 노드를 순서대로 완료해야 합니다. 먼저 모든 MCO 구성을 적용하고 노드가 안정될 때까지 기다립니다. 그런 다음 SR-IOV 구성을 적용합니다.
SR-IOV가 포함된 Machine Config Pool에 새 노드를 추가하는 경우 Machine Config Pool에서 SR-IOV 정책을 제거한 다음 새 작업자를 추가하여 이 문제를 해결할 수 있습니다. 그런 다음 SR-IOV 정책을 다시 적용합니다.
-
stalld
서비스는 커널의 버그를 트리거하여 노드가 정지됩니다. 이 문제를 해결하기 위해 Performance Addon Operator는 기본적으로stalld
를 비활성화합니다. 수정은 DPDK 기반 워크로드와 관련된 대기 시간에 영향을 미치지만 커널 버그 (BZ#1912118)가 수정되면 기능이 복원됩니다. -
ruby-kafka-1.1.0
및fluent-plugin-kafka-0.13.1
gems가 있는 Fluentd Pod는 Apache Kafka 버전 0.10.1.0과 호환되지 않습니다. 자세한 내용은 Red Hat OpenShift Logging 5.0 릴리스 노트의 “알려진 문제"에서 참조하십시오. Mellanox MT27800 제품군 [ConnectX-5] 어댑터 카드에서 PTP(Precision Time Protocol) 결함이 확인되고 있습니다.
ptp4l
로그에서 클럭 동기화를 중단하는 오류가 확인되고 있습니다.이러한 오류로 인해 NIC 하드웨어 클럭 재설정이 필요하므로 일반 시스템 클럭 업데이트보다 큰 업데이트가 발생합니다. 이 문제의 근본 원인은 알 수 없으며 현재 해결 방법이 없습니다.
-
이전 버전에서는 OpenStack SDK의 버그로 인해 서버 그룹
OSP16
을 요청할 때 오류가 발생했습니다. 결과적으로 UPI playbookcontrol-plane.yaml
은 컨트롤 플레인 서버를 생성하기 위한 작업 중에 실패했습니다. 임시 해결 방법으로 OpenStack SDK를 업데이트하도록 핫픽스를 요청하면 bastion 호스트에서 OpenStack SDK를 업데이트하여 UPI Ansible 작업을 업데이트하여python-openstacksdk-0.36.4-1.20201113235938.el8ost
를 실행할 수 있습니다. 이 핫픽스를 사용하면 playbook이 성공적으로 실행됩니다. (BZ#1891816) 최신 Dell 펌웨어(04.40.00.00) 노드를 사용하여 베어 메탈에 IPI 설치를 시도할 때 배포되지 않으며 오류가 상태에 표시됩니다. 이는 Dell 펌웨어 (4.40.00.00)가 eHTML5를 Virtual Console Plug-in으로 사용하기 때문입니다.
이 문제를 해결하려면 Virtual Console Plugin을 HTML5로 변경하고 배포를 다시 실행합니다. 이제 노드가 성공적으로 배포됩니다. 자세한 내용은 가상 미디어를 사용하여 설치를 위한 펌웨어 요구 사항에서 참조하십시오.
부트스트랩 중 Kuryr를 사용하는 RHOSP 클러스터 설치 시 다음 메시지와 함께 시간 초과됩니다.
INFO Waiting up to 20m0s for the Kubernetes API at https://api.ostest.shiftstack.com:6443... INFO API v1.20.0+ba45583 up INFO Waiting up to 30m0s for bootstrapping to complete... ERROR Attempted to gather ClusterOperator status after wait failure: listing ClusterOperator objects: Get "https://api.ostest.shiftstack.com:6443/apis/config.openshift.io/v1/clusteroperators": dial tcp 10.46.44.166:6443: connect: connection refused INFO Use the following commands to gather logs from the cluster INFO openshift-install gather bootstrap --help FATAL failed to wait for bootstrapping to complete: timed out waiting for the condition
시간 초과는 Kuryr가 클러스터 노드의 RHOSP Networking 서비스(neutron) 서브넷을 감지하는 방법의 변경으로 인해 발생합니다.
이 문제를 해결하려면 설치 문서의 "Kubernetes 매니페스트 및 Ignition 구성 파일 생성" 섹션에 설명된 대로 컨트롤 플레인 머신 매니페스트를 제거하지 마십시오. 다음 명령을 실행하도록 지시하는 경우:
$ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml
다음 명령을 실행하십시오.
$ rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml
- OpenShift Container Platform 4.3 및 4.4에서는 사용자가 여러 탭에 콘솔을 열고 있는 경우 Developer 화면의 일부 사이드바 링크가 프로젝트에 직접 연결되지 않으며 선택한 프로젝트에서 예기치 않은 변화가 발생합니다. 이 문제는 향후 릴리스에서 해결될 예정입니다. (BZ#1839101)
- OpenShift Container Platform 4.5에서 확장 권한이 있는 사용자는 배포 또는 배포 구성에 대한 편집 권한이 없는 경우 콘솔을 사용하여 배포 또는 배포 구성을 확장할 수 없습니다. 이 문제는 향후 릴리스에서 해결될 예정입니다. (BZ#1886888)
- OpenShift Container Platform 4.5에서는 Developer 화면에 최소한의 데이터가 있거나 또는 데이터가 없는 경우 대부분의 모니터링 차트 또는 그래프 (CPU 사용량, 메모리 사용량 및 대역폭)에 -1~1의 범위가 표시됩니다. 그러나 이러한 값은 모두 제로 미만의 값이 될 수 없습니다. 이 문제는 향후 릴리스에서 해결될 예정입니다. (BZ#1904106)
- 현재 웹 콘솔 퀵스타트 카드의 사전 요구 사항이 목록 대신 단락으로 표시됩니다. 이 문제는 향후 릴리스에서 해결될 예정입니다. (BZ#1905147)
- 현재 Search Page에서 Name 필터를 적용하거나 제거한 후 Pipeline 리소스 테이블이 즉시 업데이트되지 않습니다. 그러나 페이지를 새로 고치거나 Pipeline을 닫고 Pipelines 섹션을 확장하면 Name 필터가 적용됩니다. Name 필터를 삭제할 때도 동일한 동작이 표시됩니다. 이 문제는 향후 릴리스에서 해결될 예정입니다. (BZ#1901207).
- Operator SDK CLI 툴은 macOS에서 실행을 지원하지만 현재 OpenShift 미러 사이트에서 macOS 바이너리가 누락되어 있습니다. macOS 바이너리가 향후 업데이트에 추가됩니다. (BZ#1930357)
- 현재 IPsec이 활성화된 클러스터에서 RHEL(Red Hat Enterprise Linux) 7.9 노드는 RHCOS(Red Hat Enterprise Linux CoreOS) 노드와 통신할 수 없습니다. (BZ#1925925)
모든 HTTP 트래픽을 HTTPS로 리디렉션하는 관리자가 프로비저닝한 외부 로드 밸런서를 통해 기본 Ingress 컨트롤러를 노출하는 클러스터가 있는 경우, 4.6에서 4.7으로 업그레이드 프로세스 중에 엣지 종료를 사용하려면 새로운 일반 텍스트 Ingress Canary 경로를 패치해야 합니다.
샘플 패치 명령
$ oc patch route/canary -n openshift-ingress-canary -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'
openvswitch ("net: openvswitch: reorder masks array based") 코드를 업데이트하면 openvswitch /openvswitch/flow_table::flow_lookup이 선점 가능한 (및 마이그레이션 가능한) 섹션의 각 cpu 데이터에 액세스하여 실시간 커널 패닉이 발생합니다. 결과적으로 kernel-rt는 불안정해 지고 지연 시간이 짧은 애플리케이션에 영향을 미칩니다.
이러한 문제가 해결될 때까지 OpenShift Container Platform 4.7으로 업그레이드하지 않는 것이 좋습니다.
SR-IOV 장치 플러그인에서는 노드의 VFIO 장치를 리소스로 공개하는 것을 허용하지 않습니다. 이로 인해 DPDK 워크로드가 Intel 장치에서 차단됩니다.
이 문제가 해결될 때까지 SR-IOV 고객은 OpenShift Container Platform 4.7으로 업그레이드하지 않는 것이 좋습니다.
OpenShift Container Platform 4.7에서 Operator 인프라 코드에 추가된
ConfigInformers
개체가 제대로 시작되지 않습니다. 결과적으로ConfigObserver
개체가 캐시를 동기화하지 못했습니다. 이러한 상황이 발생하면 oVirt CSI Driver Operator가 몇 분 후에 종료되어 지속적으로 재부팅이 반복됩니다. 해결 방법으로 다음 절차를 수행할 수 있습니다.oVirt CSI Operator에서 프로젝트를 클러스터로 전환합니다.
$ oc project openshift-cluster-csi-drivers
warning: restart
메시지를 확인합니다.$ oc status
경고가 없는 경우 다음 명령을 입력합니다.
$ oc get pods
결과적으로 oVirt CSI Driver Operator가 더 이상 지속적으로 다시 시작되지 않습니다. (BZ#1929777)
-
명령이 주석 이름과 값 간의 구분 기호로 등호(
=
)를 포함하는 LDAP 그룹 이름에 대해oc annotate
명령은 작동하지 않습니다. 이 문제를 해결하려면oc patch
또는oc edit
를 사용하여 주석을 추가합니다. (BZ#1917280) -
OVN-Kubernetes 네트워크 공급자는
NodePort
- 및LoadBalancer
-유형 서비스에 대한externalTrafficPolicy
기능을 지원하지 않습니다.service.spec.externalTrafficPolicy
필드는 서비스의 트래픽이 노드-로컬 또는 클러스터 전체 엔드포인트로 라우팅되는지 여부를 결정합니다. 현재 이러한 트래픽은 기본적으로 클러스터 전체 엔드포인트로 라우팅되며 노드 로컬 엔드포인트로 트래픽을 제한할 수 없습니다. 이 문제는 향후 릴리스에서 해결될 예정입니다. (BZ#1903408) - 현재 Kubernetes 포트 충돌 문제로 인해 Pod가 재배포된 후에도 Pod 간 통신이 중단될 수 있습니다. 자세한 내용과 해결 방법은 Red Hat 지식 베이스 솔루션 Port collisions between pod and cluster IPs on OpenShift 4 with OVN-Kubernetes에서 참조하십시오. (BZ#1939676, BZ#1939045)
- OpenShift Container Platform 4.7에서는 웹 콘솔에 Pod 제한 및 요청이 표시되지 않습니다. 이 기능은 모니터링에 변경 사항이 발생하지 않고 이 릴리스에서 구현할 수 없습니다. 이 기능은 OpenShift Container Platform 4.8 릴리스에서 수정되었습니다. 자세한 내용은 Red Hat Knowledge Base 솔루션 OpenShift Container Platform 4.7 콘솔이 더 이상 CPU 및 메모리 사용량 차트에 요청 또는 제한 행을 표시하지 않음(BZ#1975147)을 참조하십시오.