5.3. 부트스트랩 VM 문제 해결
OpenShift Container Platform 설치 프로그램은 OpenShift Container Platform 클러스터 노드 프로비저닝을 처리하는 부트스트랩 노드 가상 머신을 생성합니다.
프로세스
설치 프로그램을 트리거한 후 약 10~15분 정도 후에
virsh
명령을 사용하여 부트스트랩 VM이 작동하는지 확인합니다.sudo virsh list
$ sudo virsh list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고부트스트랩 VM의 이름은 항상 클러스터 이름으로 시작하여 그 뒤에 임의의 문자 집합이 있고 "bootstrap"이라는 단어로 끝납니다.
부트스트랩 VM이 10-15 분 후에 실행되지 않는 경우 다음 명령을 실행하여 시스템에서
libvirtd
가 실행되고 있는지 확인합니다.systemctl status libvirtd
$ systemctl status libvirtd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 부트스트랩 VM이 작동하는 경우 해당 VM에 로그인합니다.
virsh console
명령을 사용하여 부트스트랩 VM의 IP 주소를 찾습니다.sudo virsh console example.com
$ sudo virsh console example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요provisioning
네트워크없이 OpenShift Container Platform 클러스터를 배포하는 경우172.22.0.2
와 같은 개인 IP 주소가 아닌 공용 IP 주소를 사용해야 합니다.IP 주소를 가져온 후
ssh
명령을 사용하여 부트스트랩 VM에 로그인합니다.참고이전 단계의 콘솔 출력에서
ens3
에서 제공되는 IPv6 IP 주소 또는ens4
에서 제공되는 IPv4 IP를 사용할 수 있습니다.ssh core@172.22.0.2
$ ssh core@172.22.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
부트스트랩 VM에 성공적으로 로그인하지 못한 경우 다음 시나리오 중 하나가 발생했을 가능성이 있습니다.
-
172.22.0.0/24
네트워크에 연결할 수 없습니다. 프로비저너와provisioning
네트워크 브리지 간의 네트워크 연결을 확인합니다. 이 문제는provisioning
네트워크를 사용하는 경우 발생할 수 있습니다. -
공용 네트워크를 통해 부트스트랩 VM에 연결할 수 없습니다.
baremetal
네트워크에서 SSH를 시도할 때provisioner
호스트, 특히baremetal
네트워크 브리지의 연결을 확인합니다. -
Permission denied (publickey, password, keyboard-interactive)
문제가 발생했습니다. 부트스트랩 VM에 액세스하려고하면Permission denied
오류가 발생할 수 있습니다. VM에 로그인하려는 사용자의 SSH 키가install-config.yaml
파일에 설정되어 있는지 확인합니다.
5.3.1. 부트스트랩 VM은 클러스터 노드를 부팅할 수 없습니다. 링크 복사링크가 클립보드에 복사되었습니다!
배포 중에 부트스트랩 VM이 클러스터 노드를 부팅하지 못하여 VM이 RHCOS 이미지로 노드를 프로비저닝하지 못할 수 있습니다. 이 시나리오는 다음과 같은 이유로 발생할 수 있습니다.
-
install-config.yaml
파일 관련 문제 - baremetal 네트워크를 사용할 때 대역 외 네트워크 액세스 문제
이 문제를 확인하기 위해 ironic
과 관련된 세 가지 컨테이너를 사용할 수 있습니다.
-
Ironic
-
ironic-inspector
프로세스
부트스트랩 VM에 로그인합니다.
ssh core@172.22.0.2
$ ssh core@172.22.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 컨테이너 로그를 확인하려면 다음을 실행합니다.
sudo podman logs -f <container_name>
[core@localhost ~]$ sudo podman logs -f <container_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
;container_name>
;을ironic
또는ironic-inspector
중 하나로 바꿉니다. 컨트롤 플레인 노드가 PXE에서 부팅되지 않는 문제가 발생하면ironic
pod를 확인합니다.ironic
pod에는 IPMI를 통해 노드에 로그인을 시도하기 때문에 클러스터 노드를 부팅하려는 시도에 대한 정보가 포함되어 있습니다.
가능한 이유
배포가 시작되면 클러스터 노드가 ON
상태 일 수 있습니다.
해결책
IPMI를 통해 설치를 시작하기 전에 OpenShift Container Platform 클러스터 노드의 전원을 끄십시오.
ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
$ ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
5.3.2. 로그 검사 링크 복사링크가 클립보드에 복사되었습니다!
RHCOS 이미지를 다운로드하거나 액세스하는 데 문제가 발생하면 먼저 install-config.yaml
구성 파일에서 URL이 올바른지 확인합니다.
RHCOS 이미지를 호스팅하는 내부 웹 서버의 예
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c
clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
coreos-downloader
컨테이너는 install-config.yaml
구성 파일에서 지정하는 외부 quay.io 레지스트리 또는 웹 서버 또는 외부 quay.io 레지스트리에서 리소스를 다운로드합니다. coreos-downloader
컨테이너가 실행 중인지 확인하고 필요에 따라 로그를 검사합니다.
프로세스
부트스트랩 VM에 로그인합니다.
ssh core@172.22.0.2
$ ssh core@172.22.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 부트스트랩 VM 내에서
coreos-downloader
컨테이너의 상태를 확인합니다.sudo podman logs -f coreos-downloader
[core@localhost ~]$ sudo podman logs -f coreos-downloader
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 부트스트랩 VM이 이미지의 URL에 액세스할 수 없는 경우
curl
명령을 사용하여 VM이 이미지에 액세스할 수 있는지 확인합니다.배포 단계에서 모든 컨테이너가 시작되었는지 여부를 나타내는
bootkube
로그를 검사하려면 다음을 실행합니다.journalctl -xe
[core@localhost ~]$ journalctl -xe
Copy to Clipboard Copied! Toggle word wrap Toggle overflow journalctl -b -f -u bootkube.service
[core@localhost ~]$ journalctl -b -f -u bootkube.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dnsmasq
,mariadb
,httpd
및ironic
를 포함한 모든 Pod가 실행 중인지 확인합니다.sudo podman ps
[core@localhost ~]$ sudo podman ps
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod에 문제가 있는 경우 문제가있는 컨테이너의 로그를 확인합니다.
ironic
서비스의 로그를 확인하려면 다음 명령을 실행합니다.sudo podman logs ironic
[core@localhost ~]$ sudo podman logs ironic
Copy to Clipboard Copied! Toggle word wrap Toggle overflow