1.7. 확인된 문제

사용자 프로비저닝 인프라를 사용하여 vSphere의 가상 머신의 전원을 켜는 경우 노드를 확장하는 프로세스가 예상대로 작동하지 않을 수 있습니다. 하이퍼바이저 구성에서 알려진 문제로 인해 시스템이 하이퍼바이저 내에 생성되지만 전원이 켜지지 않습니다. 머신 세트를 확장한 후 노드가 Provisioning 상태에 있는 것으로 표시되면 vSphere 인스턴스 자체에서 가상 머신의 상태를 조사할 수 있습니다. VMware 명령 govc tasks 및 govc events 이벤트를 사용하여 가상 시스템의 상태를 확인합니다. 다음과 유사한 오류 메시지가 있는지 확인합니다.

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

이 VMware KBase 문서의 지침에 따라 문제를 해결할 수 있습니다. 자세한 내용은 Red Hat Knowledgebase 솔루션 [UPI vSphere] 노드 확장이 예상대로 작동하지 않음을 참조하십시오. (BZ#1918383)

OpenShift Container Platform 4.6.8에서는 CLO(Cluster Logging Operator)에서 인증서를 다시 생성하는 방법을 변경한 버그 수정이 도입되었습니다. 이번 수정으로 인해 EO(OpenShift Elasticsearch Operator)가 클러스터를 다시 시작하는 동안 CLO에서 인증서를 다시 생성할 수 있는 문제가 발생합니다. 이로 인해 EO와 클러스터 간에 통신 문제가 발생하여 EO 노드에서 인증서가 일치하지 않습니다.

Elasticsearch를 업그레이드할 때 일치하지 않는 인증서로 인해 문제가 발생할 수 있습니다. 이 문제를 해결하려면 CLO 및 EO를 선택적으로 별도로 업그레이드할 수 있습니다. 작동하지 않는 경우 다음 명령을 실행하여 Elasticsearch Pod를 다시 시작합니다.

oc delete pod -l component=es

$ oc delete pod -l component=es

Pod가 재시작되면 일치하지 않는 인증서가 수정되어 업그레이드 문제를 해결합니다. (BZ#1906641)

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

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

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

for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;

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

operator-sdk new 또는 operator-sdk create api 명령을 --helm-chart 플래그를 지정하지 않고 실행하면 기본 보일러 플레이트 Nginx 차트를 사용하는 Helm 기반 Operator가 빌드됩니다. 이 예제 차트는 업스트림 쿠버네티스에서 올바르게 작동하지만 OpenShift Container Platform에 성공적으로 배포되지 않습니다.

이 문제를 해결하려면 --helm-chart 플래그를 사용하여 OpenShift Container Platform에 성공적으로 배포하는 Helm 차트를 제공합니다. 예를 들면 다음과 같습니다.

operator-sdk new <operator_name> --type=helm \
  --helm-chart=<repo>/<name>

$ operator-sdk new <operator_name> --type=helm \
  --helm-chart=<repo>/<name>

(BZ#1874754)

인프라 ID가 접두사로 지정되지 않은 머신에서 사용하는 방화벽 규칙은 설치 관리자 프로비저닝 인프라를 사용하여 GCP(Google Cloud Platform)에서 실행되는 클러스터를 삭제할 때 보존됩니다. 이로 인해 설치 프로그램의 제거 프로세스가 실패합니다. 이 문제를 해결하려면 GCP 웹 콘솔에서 머신의 방화벽 규칙을 수동으로 삭제해야 합니다.

gcloud compute firewall-rules delete <firewall_rule_name>

$ gcloud compute firewall-rules delete <firewall_rule_name>

인프라 ID가 없는 머신의 방화벽 규칙을 제거하면 클러스터를 삭제할 수 있습니다. (BZ#1801968)

OpenShift Container Platform 4.6에서는 리소스 지표 API 서버에서 사용자 정의 지표를 지원합니다. 리소스 지표 API 서버는 OpenAPI 사양을 구현하지 않으며 다음 메시지가 kube-apiserver 로그로 전송됩니다.

controller.go:114] loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: OpenAPI spec does not exist
controller.go:127] OpenAPI AggregationController: action for item v1beta1.metrics.k8s.io: Rate Limited Requeue.

controller.go:114] loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: OpenAPI spec does not exist
controller.go:127] OpenAPI AggregationController: action for item v1beta1.metrics.k8s.io: Rate Limited Requeue.

경우에 따라 이러한 오류로 인해 KubeAPIErrorsHigh 경고가 표시될 수 있지만, OpenShift Container Platform 기능을 저하시키는 근본적인 문제는 확인되지 않았습니다. (BZ#1819053)

AWS 계정이 전역 조건을 사용하여 모든 작업을 거부하거나 특정 권한이 필요한 AWS 조직 서비스 컨트롤 정책(SCP)을 사용하도록 구성된 경우, 권한을 검증하는 AWS 정책 시뮬레이터 API에서 거짓 부정을 생성합니다. 권한을 검증할 수 없는 경우 설치에 필요한 권한이 제공된 자격 증명에 있어도 OpenShift Container Platform AWS를 설치할 수 없습니다.

이 문제를 해결하기 위해 install-config.yaml 구성 파일에서 credentialsMode 매개변수 값을 설정하여 AWS 정책 시뮬레이터 권한 점검을 바이패스할 수 있습니다. credentialsMode 값은 CCO(Cloud Credential Operator)의 동작을 지원되는 세 가지 모드 중 하나로 변경합니다.

apiVersion: v1
baseDomain: cluster1.example.com
credentialsMode: Mint 
compute:
- architecture: amd64
  hyperthreading: Enabled
...

apiVersion: v1
baseDomain: cluster1.example.com
credentialsMode: Mint 

compute:
- architecture: amd64
  hyperthreading: Enabled
...

이 점검을 바이패스하는 경우 제공하는 자격 증명에 지정된 모드에 필요한 권한이 있는지 확인하십시오.

(BZ#1829101)

보안을 강화하기 위해 기본 CRI-O 기능 목록에서 NET_RAW 및 SYS_CHROOT 기능을 더 이상 사용할 수 없습니다.

NET_RAW 및 SYS_CHROOT 기능은 OpenShift Container Platform 4.5.16의 기본 기능에서 제거되었습니다. 4.5.16 이전 릴리스에서 생성된 클러스터에 대한 영향을 줄이기 위해 기본 기능 목록이 별도의 머신 구성에 포함됩니다. 99-worker-generated-crio-capabilities 및 99-master-generated-crio-capabilities. OpenShift Container Platform은 이전 릴리스에서 업데이트할 때 새 머신 구성을 생성합니다.

업그레이드 후에는 NET_RAW 및 SYS_CHROOT 기능을 비활성화한 다음 워크로드를 테스트하는 것이 좋습니다. 해당 기능을 제거할 준비가 되면 99-worker-generated-crio-capabilities 및 99-master-generated-crio-capabilities 머신 구성을 삭제합니다.

중요: 이전 릴리스에서 업데이트하는 경우 4.6으로 업데이트하기 전에 4.5.16으로 업데이트합니다. (BZ#1874671).

TLS 확인이 필요한 oc 명령의 경우 인증서에서 주체 대체 이름을 설정하지 않으면 확인 작업에서 일반 이름 필드로 대체하지 않고 다음 오류와 함께 명령이 실패합니다.

x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

이 문제를 해결하기 위해 적절한 주체 대체 이름이 설정된 인증서를 사용하거나 oc 명령 앞에 GODEBUG=x509ignoreCN=0을 지정하여 이 동작을 일시적으로 덮어쓸 수 있습니다.

향후 4.6 z-stream에서는 오류 대신 경고를 반환하여 사용자가 인증서를 업데이트하여 준수하도록 더 많은 시간을 허용할 수 있습니다.

(BZ#1889204)

관리자는 제한된 네트워크 환경(연결이 끊긴 클러스터라고도 함)에서 OpenShift Container Platform 4.6 클러스터에서 OLM(Operator Lifecycle Manager)을 사용하도록 redhat-operators 카탈로그를 미러링할 수 있습니다. 그러나 다음 Operator는 예상된 공개 호스트 이름 registry .redhat. io 대신 개인 호스트 이름 registry-proxy.engineering.redhat.com 을 사용하여 mapping.txt 파일에 항목을 반환합니다.

이로 인해 일반적으로 내부 Red Hat 테스트를 위한 액세스 불가능한 프라이빗 레지스트리에 대해 이미지가 실패합니다. 이 문제를 해결하려면 mapping.txt 파일을 생성한 후 다음 명령을 실행합니다.

sed -i -e 's/registry-proxy.engineering.redhat.com/registry.redhat.io/g' \
    -e 's/rh-osbs\/amq7-/amq7\//g' \
    -e 's/amq7\/tech-preview-/amq7-tech-preview\//g' \
    ./redhat-operator-index-manifests/imageContentSourcePolicy.yaml \
    ./redhat-operator-index-manifests/mapping.txt

$ sed -i -e 's/registry-proxy.engineering.redhat.com/registry.redhat.io/g' \
    -e 's/rh-osbs\/amq7-/amq7\//g' \
    -e 's/amq7\/tech-preview-/amq7-tech-preview\//g' \
    ./redhat-operator-index-manifests/imageContentSourcePolicy.yaml \
    ./redhat-operator-index-manifests/mapping.txt

PowerVM의 IBM Power Systems의 OpenShift Container Platform의 경우 다음 요구 사항이 권장됩니다.

Red Hat Operator 게시 프로세스의 버그로 인해 OpenShift Container Platform 4.6 인덱스 이미지의 스테이징 환경 버전이 간략하게 게시되었습니다. 버그가 해결되었으며 이미지가 올바른 콘텐츠로 곧 다시 게시되었습니다.

이 단계 레지스트리 이미지를 사용하는 동안 Operator를 설치하거나 업그레이드하려고 하면 openshift-marketplace 네임스페이스의 작업이 예상 공개 호스트 이름 registry.stage.redhat. io 대신 프라이빗 호스트 이름 registry.stage.redhat.io 로 표시되는 다음과 같은 오류와 함께 실패할 수 있습니다 .redhat.io:

ImagePullBackOff for
Back-off pulling image "registry.stage.redhat.io/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c746ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

ImagePullBackOff for
Back-off pulling image "registry.stage.redhat.io/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c746ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

rpc error: code = Unknown desc = error pinging docker registry registry.stage.redhat.io: Get "https://registry.stage.redhat.io/v2/": dial tcp: lookup registry.stage.redhat.io on 10.0.0.1:53: no such host

rpc error: code = Unknown desc = error pinging docker registry registry.stage.redhat.io: Get "https://registry.stage.redhat.io/v2/": dial tcp: lookup registry.stage.redhat.io on 10.0.0.1:53: no such host

이로 인해 액세스 불가능한 프라이빗 레지스트리에 대해 이미지 풀이 실패했으며 일반적으로 내부 Red Hat 테스트를 위해 빌드되었으며 관련 Operator 설치 및 업그레이드에 성공하지 못했습니다. 이 문제를 정리하려면 해결 방법은 장애가 발생한 서브스크립션 새로 고침을 참조하십시오. (BZ#1909152)