이전의 게시글에 이어서 쿠버네티스 설치를 계속 해보자 한다.
우선 쿠버네티스 설치가 완료되었으니 쿠버네티스의 node가 정상 작동하는지 확인하기 위해 아래 명령어를 실행해주었다.
kubectl get nodes위 명령어를 실행하니 처음에는 정상적으로 node의 상태가 뜨더니 몇 분 후 다시 입력하자 The connection to the server x.x.x.x:port was refused라는 명령어가 발생하는 문제가 발생...
이 문제를 해결하기 위해 해당 kubenetes 서비스의 상태를 확인해봐야 했다.
sudo systemctl status kubelet위의 명령어를 입력하자 connect: connection refused" 라는 에러 로그가 남아있는 것을 볼 수 있었다.
이를 해결하기 위해 chat cpt에 검색을 해보니 에러 발생 가설을 세울 수 있었다.
- VM 네트워크 보안 문제
- 방화벽 문제
- kube-apiserver 비정상 동작
VM 네트워크 보안 문제
위의 가설을 해결하기 위해 우선 VM의 설정 옵션을 들어가야했다. 우선 VM을 azure 서비스에서 만들었기 때문에 azure VM 옵션에서 네트워크 보안에 들어가 아웃바운드 규칙을 하나 추가한다.
우선 테스트 용이라서 any 옵션에서 *포트로 모든 접속을 허용하는 규칙을 생성하고 다시 한번 실행해보았더니 에러가 그대로 유지하는 아주 행복한 결과를 맞지할 수 있었다....
방화벽 문제
해당 VM 내부 방화벽 설정에서 해당 포트가 열려있지 않아서 문제가 발생할 수도 있다고 한다.
sudo netstat -tulnp | grep 6443
# 위 명령어로 6443 포트가 열려있는지 확인(포트번호는 알아서 교체)
sudo ufw allow 6443/tcp
# 열려있지 않으면 위 명령어로 열어주기위의 과정을 해보았으나 역시나 결과는 실패.... 다음으로 넘어가보자...
kube-apiserver 비정상 동작
위 문제를 해결하기 위해 kube-apiserver가 실행은 되고 있는지 확인해봐야한다.
sudo docker ps | grep kube-apiserver위 명령어를 쳐보니 동작은 하고 있다는 것을 볼 수 있었다.
sudo journalctl -u kube-apiserver -f여기서 해당 서비스의 로그를 살펴보니 여기서도 접속을 할 수 없다고 connection refused가 뜨는 것을 볼 수 있었다... 아니 해당 에러가 떠서 로그를 찾아보는데 여기서도 똑같은 에러가 뜨면 어떡하라고.....
우선 침착하게 kubeadm을 초기화 즉 클러스터를 초기화하고 다시 철치해보았다...
sudo kubeadm reset
sudo kubeadm init결과는 동일.... 게시글은 짧지만 이 빙빙도는 에러 로그를 자그만치 2일동안 반복하고 있었다.... chat gpt와 말씨름을 하기 지쳐 구글링을 시작
그러니 나와 같은 문제를 가지고 있던 사람을 발견할 수 있었다... (출처)
확인해보니 컨테이너 런타임 라이브러리의 호환문제라고 한다..... 필자는 containerd라는 라이브러리를 사용하고 있었는데 Ubuntu 22.04부터는 해당 라이브러리 호환이 안되서 문제가 발생하고 있었다....
해결 방법은 아래와 같다.
- containerd를 사용하지 말고 대신, CRI-O를 사용
- Ubuntu 22.04를 20.04로 변경하기
- containerd의 config 파일을 직접 수정하기(SystemdCgroup = ture) 및 ubuntu 22.04를 그대로 쓰면서 kubernetes와 containerd 버전을 수정
처음에는 가장 쉬운 3번째 방식을 사용해보았다... 해당 containerd의 버전을 낮춰야해서 현재 사용하고 있는 1.7을 지우고 1.5로 버전을 다운그레이드 후 실행해보았더니 그래도 connection refused가 지속적으로 발생하고 있었다...
그러니 1번을 택할 수 밖에 없었다 containerd 라이브러리를 아예 지우고 cri-o 라이브러리를 재설치를 진행했다.... 설치 과정은 아래와 같다
# 저장소 설정
OS=xUbuntu_22.04
VERSION=1.28
echo "deb [signed-by=/usr/share/keyrings/libcontainers-archive-keyring.gpg] \
https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" \
| sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
echo "deb [signed-by=/usr/share/keyrings/libcontainers-cri-o-keyring.gpg] \
https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" \
| sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
sudo mkdir -p /usr/share/keyrings
curl -fsSL https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key \
| gpg --dearmor -o /usr/share/keyrings/libcontainers-archive-keyring.gpg
curl -fsSL https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/Release.key \
| gpg --dearmor -o /usr/share/keyrings/libcontainers-cri-o-keyring.gpg
# CRI-O 설치
sudo apt update
sudo apt install cri-o cri-o-runc
# CRI-O 시작 및 활성화
sudo systemctl daemon-reload
sudo systemctl enable crio --now
# 쿠버네티스와 CRI-O 연동
sudo kubeadm init --cri-socket /var/run/crio/crio.sock
sudo cat /var/lib/kubelet/kubeadm-flags.env
sudo kubeadm init --cri-socket /var/run/crio/crio.sock
그리고 로그를 보니 이번에는 에러 메시지가 바뀌는 것을 볼 수 있었다.... 드디어 뭔가 된거겠지라는 희망을 가지고 에러 메시지를 확인해보았다..
preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling
메시지는 위와 같았다 확인해보니 node에 taint가 적용되어있는데 해당 taint 설정에 적합한 pod이 없어서 스케줄링이 되어있지 않고 있다는 것을 알았다.
그래서 이를 해결해주기 위해 node의 taint 속성을 제거
kubectl taint nodes <node-name> node-role.kubernetes.io/control-plane:NoSchedule-위 명령어로 제거 하자 정상적으로 pod이 running이 되는 것을 볼 수 있었다... 장장 3일에 걸쳐서 쿠버네티스 설치 완료... 정말 이런 infra적인 부분은 책으로 공부할 때보다 직접해봐야 뭔가 이런 시행착오를 겪으면서 능숙해지는거 같다....
kubectl run test-nginx --image=nginx:1.14위 명령어로 nginx 실행하는 Pod을 하나 만들고
kubectl port-forward pod/test-nginx 8080:80해당 명령어로 로컬에서 포트를 해당 pod과 연결후 localhost:8080으로 접속하니 
위와 같이 잘 접속할 수 있었다...
다음에는 내부에서가 아닌 외부에서 접속하는 방법을 가지고 글을 써보도록 하겠습니다~!
