7.3. CRI-O 컨테이너 런타임 문제 해결
7.3.1. CRI-O 컨테이너 런타임 엔진 정보
CRI-O는 Kubernetes 네이티브 컨테이너 엔진 구현으로 운영 체제와 긴밀하게 통합되어 효율적이고 최적화된 Kubernetes 환경을 제공합니다. CRI-O 컨테이너 엔진은 각 OpenShift Container Platform 클러스터 노드에서 systemd 서비스로 실행됩니다.
컨테이너 런타임 문제가 발생하면 각 노드에서 crio
systemd 서비스의 상태를 확인합니다. 컨테이너 런타임 문제가 있는 노드에서 CRI-O journald 장치 로그를 수집합니다.
7.3.2. CRI-O 런타임 엔진 상태 확인
각 클러스터 노드에서 CRI-O 컨테이너 런타임 엔진 상태를 확인할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
디버그 Pod 내에서 노드의
crio
systemd 서비스를 쿼리하여 CRI-O 상태를 검토합니다.노드의 디버그 Pod를 시작합니다.
$ oc debug node/my-node
디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를/host
로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.# chroot /host
참고RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.15 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우
oc
작업이 영향을 받습니다. 이러한 상황에서 대신ssh core @ <node>.<cluster_name>.<base_domain>
을 사용하여 노드에 액세스할 수 있습니다.crio
systemd 서비스가 노드에서 활성 상태인지 확인합니다.# systemctl is-active crio
보다 자세한
crio.service
상태 요약을 출력합니다.# systemctl status crio.service
7.3.3. CRI-O journald 장치 로그 수집
CRI-O 문제가 발생하는 경우 노드에서 CRI-O journald 장치 로그를 얻을 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - API 서비스가 작동하고 있어야 합니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - 컨트롤 플레인 또는 컨트롤 플레인 시스템의 정규화된 도메인 이름이 있어야 합니다.
프로세스
CRI-O journald 장치 로그를 수집합니다. 다음 예제는 클러스터 내의 모든 컨트롤 플레인 노드에서 로그를 수집합니다.
$ oc adm node-logs --role=master -u crio
특정 노드에서 CRI-O journald 장치 로그를 수집합니다.
$ oc adm node-logs <node_name> -u crio
API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다.
<node>.<cluster_name>.<base_domain>
을 적절한 값으로 바꿉니다.$ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
참고RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.15 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. SSH를 통해 진단 데이터를 수집하기 전에
oc adm must gather
및 기타oc
명령을 실행하여 충분한 데이터를 수집할 수 있는지 확인하십시오. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우oc
작업이 영향을 받습니다. 이러한 상황에서ssh core@<node>.<cluster_name>.<base_domain>
을 사용하여 노드에 액세스할 수 있습니다.
7.3.4. CRI-O 스토리지 정리
다음 문제가 발생하는 경우 CRI-O 임시 스토리지를 수동으로 삭제할 수 있습니다.
노드는 모든 Pod에서 실행할 수 없으며 다음과 같은 오류가 나타납니다.
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to mount container XXX: error recreating the missing symlinks: error reading name of symlink for XXX: open /var/lib/containers/storage/overlay/XXX/link: no such file or directory
작업 노드에 새 컨테이너를 생성할 수 없으며 "can't stat lower layer" 오류가 나타납니다.
can't stat lower layer ... because it does not exist. Going through storage to recreate the missing symlinks.
-
클러스터 업그레이드 후 또는 재부팅을 시도하는 경우 노드는
NotReady
상태입니다. -
crio
(컨테이너 런타임 구현)가 제대로 작동하지 않습니다. -
컨테이너 런타임 인스턴스(
crio
)가 작동하지 않기 때문에oc debug node/<node_name
>을 사용하여 노드에서 디버그 쉘을 시작할 수 없습니다.
CRI-O 스토리지를 완전히 지우고 오류를 해결하려면 다음 프로세스를 따르십시오.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
노드에서
cordon
을 사용합니다. 이는 노드가Ready
상태가 되면 워크로드가 예약되지 않도록 하기 위한 것입니다.SchedulingDisabled
가 상태 섹션에 있으면 예약이 비활성화되어 있음을 알 수 있습니다.$ oc adm cordon <node_name>
노드를 cluster-admin으로 드레이닝합니다.
$ oc adm drain <node_name> --ignore-daemonsets --delete-emptydir-data
참고Pod 또는 Pod 템플릿의
terminationGracePeriodSeconds
속성은 정상 종료 기간을 제어합니다. 이 속성은 30초에 기본값으로 설정되지만 필요에 따라 각 애플리케이션에 맞게 사용자 지정할 수 있습니다. 90초 이상으로 설정하면 Pod가SIGKILLed
로 표시되고 성공적으로 종료되지 않을 수 있습니다.노드가 반환되면 SSH 또는 콘솔을 통해 노드에 다시 연결합니다. 그런 다음 root 사용자에 연결합니다.
$ ssh core@node1.example.com $ sudo -i
kubelet을 수동으로 중지합니다.
# systemctl stop kubelet
컨테이너 및 pod를 중지합니다.
다음 명령을 사용하여
HostNetwork
에 없는 Pod를 중지합니다. 제거를 통해HostNetwork
에 있는 네트워킹 플러그인 pod를 사용하므로 먼저 제거해야 합니다... for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done
다른 모든 Pod를 중지합니다.
# crictl rmp -fa
crio 서비스를 수동으로 중지합니다.
# systemctl stop crio
이러한 명령을 실행한 후 임시 스토리지를 완전히 초기화할 수 있습니다.
# crio wipe -f
crio 및 kubelet 서비스를 시작합니다.
# systemctl start crio # systemctl start kubelet
crio 및 kubelet 서비스가 시작되고 노드가
Ready
상태에 있으면 정리가 작동했는지 알 수 있습니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION ci-ln-tkbxyft-f76d1-nvwhr-master-1 Ready, SchedulingDisabled master 133m v1.28.5
노드를 예약 가능으로 표시합니다.
SchedulingDisabled
상태가 더 이상 아닐 때 예약이 활성화되어 있음을 알 수 있습니다.$ oc adm uncordon <node_name>
출력 예
NAME STATUS ROLES AGE VERSION ci-ln-tkbxyft-f76d1-nvwhr-master-1 Ready master 133m v1.28.5