1.8. 확인된 문제

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

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

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

## 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)

일부 작업자 머신이 시작되지 않기 때문에 IBM Cloud VPC 클러스터가 간헐적으로 설치되지 않을 수 있습니다. 대신 이러한 작업자 시스템은 프로비저닝 된 단계에 남아 있습니다.

이 문제에 대한 해결방법이 있습니다. 초기 설치를 수행한 호스트에서 오류가 발생한 시스템을 삭제하고 설치 프로그램을 다시 실행합니다.

카탈로그 소스 업데이트 후 OLM에서 서브스크립션 상태를 업데이트하는 데 시간이 걸립니다. 이는 Topology Aware Lifecycle Manager(TALM)에서 수정이 필요한지 여부를 결정하는 경우 서브스크립션 정책의 상태가 계속 준수로 표시될 수 있습니다. 결과적으로 서브스크립션 정책에 지정된 Operator가 업그레이드되지 않습니다. 이 문제를 해결하려면 카탈로그 소스 정책의 spec 섹션에 다음과 같이 status 필드를 포함합니다.

metadata:
  name: redhat-operators-disconnected
spec:
  displayName: disconnected-redhat-operators
  image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.11
status:
  connectionState:
    lastObservedState: READY

이렇게 하면 OLM에서 새 인덱스 이미지를 가져오고 Pod를 준비하도록 지연을 완화하여 카탈로그 소스 정책 업데이트 및 서브스크립션 상태 업데이트 사이의 시간을 줄입니다. 문제가 지속되고 서브스크립션 정책 상태 업데이트가 여전히 늦은 경우 동일한 서브스크립션 정책 또는 다른 이름으로 동일한 ClusterGroupUpdate CR을 적용하여 다른 ClusterGroupUpdate CR을 적용할 수 있습니다. (OCPBUGS-2813)

ClusterGroupUpdate CR이 시작될 때 선택한 모든 클러스터가 호환되는 경우 TALM은 정책 수정을 건너뜁니다. 수정된 카탈로그 소스 정책 및 동일한 ClusterGroupUpdate CR의 서브스크립션 정책이 있는 Operator 업데이트는 완료되지 않습니다. 서브스크립션 정책은 카탈로그 소스 변경이 적용될 때까지 계속 준수하므로 건너뜁니다. 이 문제를 해결하려면 common-subscription 정책에서 하나의 CR에 다음 변경 사항을 추가합니다. 예를 들면 다음과 같습니다.

metadata.annotations.upgrade: "1"

이로 인해 ClusterGroupUpdate CR이 시작되기 전에 정책을 준수하지 않습니다. (OCPBUGS-2812)

BMCEventSubscription CR은 ACM이 배포된 다중 클러스터 환경에서 통화 클러스터에 대한 Redfish 서브스크립션을 생성하지 못합니다. 여기서 metal3 서비스는 hub 클러스터에서만 실행됩니다. 해결방법은 다음 명령을 실행하여 Redfish API를 직접 호출하여 서브스크립션을 생성하는 것입니다.

curl -X POST -i --insecure -u "<BMC_username>:<BMC_password>" https://<BMC_IP>/redfish/v1/EventService/Subscriptions \
    -H 'Content-Type: application/json' \
    --data-raw '{
    "Protocol": "Redfish",
    "Context": "any string is valid",
    "Destination": "https://hw-event-proxy-openshift-bare-metal-events.apps.example.com/webhook",
    "EventTypes": ["Alert"]
    }'

201 Created 응답과 Location: /redfish/v1/EventService/Subscriptions/<sub_id >가 포함된 헤더가 수신되어 Redfish 이벤트 서브스크립션이 성공적으로 생성되었음을 나타냅니다. (OCPBUGSM-43707)

GitOps ZTP 방법을 사용하여 클러스터를 관리하고 설치가 완료되지 않은 클러스터를 삭제하는 경우 hub 클러스터에서 클러스터 네임스페이스를 정리하면 무기한 중단될 수 있습니다. 네임스페이스 삭제를 완료하려면 클러스터 네임스페이스의 두 CR에서 baremetalhost.metal3.io 종료자를 제거하십시오.

플랫폼 Operator 및 RukPak의 알려진 문제:

외부 클라우드 공급자를 사용하는 클러스터는 교체 후 업데이트된 인증 정보를 검색하지 못할 수 있습니다. 영향을 받는 플랫폼은 다음과 같습니다.

이 문제를 해결하려면 다음 명령을 실행하여 openshift-cloud-controller-manager Pod를 다시 시작합니다.

$ oc delete pods --all -n openshift-cloud-controller-manager

(OCPBUGS-5036)

OVN-Kubernetes 네트워크 공급자를 사용하는 클러스터에서 컨트롤 플레인 머신이 교체되면 OVN-Kubernetes와 관련된 Pod가 대체 머신에서 시작되지 않을 수 있습니다. 이 경우 새 머신에 네트워킹이 부족하면 etcd에서 이전 머신을 교체할 수 없습니다. 결과적으로 클러스터가 이 상태에 있으며 성능이 저하될 수 있습니다. 이 동작은 컨트롤 플레인이 수동 또는 컨트롤 플레인 머신 세트로 교체될 때 발생할 수 있습니다.

현재 이 문제가 발생한 경우 이 문제를 해결할 수 있는 해결방법이 없습니다. 이 문제를 방지하려면 컨트롤 플레인 머신 세트를 비활성화하고 클러스터가 OVN-Kubernetes 네트워크 공급자를 사용하는 경우 컨트롤 플레인 시스템을 수동으로 교체하지 마십시오. (OCPBUGS-5306)

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

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