본문 바로가기
Backend MLOps/On-premise setting

[k8s] kubeadm 을 이용해서 싱글노드 쿠버네티스 환경 구축 - 2

by SteadyForDeep 2023. 8. 23.
반응형

지난번 글에서 kubeadm을 설치하고 containerd, docker 같은 런타임을 이용해서 클러스터를 구성하는 과정을 진행해 보았다.

 

2023.08.17 - [Backend MLOps/On-premise setting] - [k8s] kubeadm 을 이용해서 싱글노드 쿠버네티스 환경 구축 - 1

 

[k8s] kubeadm 을 이용해서 싱글노드 쿠버네티스 환경 구축 - 1

최근 흥미로운 주제가 생겨서 이 시리즈를 적어 본다. 싱글 노드 쿠버네티스를 구성하는 방법은 여러가지가 있다. 쿠버네티스 연습이 필요한 경우 혹은 회사에서 쿠버네티스 환경을 구축해야하

davi06000.tistory.com

 

그런데 apiserver가 계속해서 꺼졌다가 켜졌다가를 반복하는 문제가 있었다.

apiserver가 비활성화되면 클러스터에 상태변경을 명령하거나 상태조회를 하는 것이 불가능하다.

따라서 이 문제를 반드시 해결해야 했다.

 

생각해 볼 수 있는 문제의 가능성은 크게 두가지였다.

하나는 내가 런타임을 두가지 이상 사용해서 충돌이 발생 근본적으로 클러스터가 망가졌거나

다른 하나는 apiserver의 주소가 계속해서 바뀌는 현상이 있을 때 였다.

 

실재로 하나의 노드에서 두가지 이상의 컨테이너 런타임을 활성화하는 것은 권장되지 않는다.

따라서 나의 경우 도커런타임을 선택해서 문제를 해결하려 했다.

sudo systemctl stop containerd
sudo systemctl disable containerd

하지만 원인이 아니었던지 계속해서 같은 증상이 반복되는 현상을 보였다.

 

따라서 두번째가 원인일 결우 고치는 방법을 써보자

 

sudo kubeadm reset
rm -r ~/.kube/
sudo rm -rf /etc/cni/net.d
sudo rm -rf /var/lib/etcd
sudo rm -rf /var/lib/kubelet

sudo kubeadm init --apiserver-advertise-address=$(hostname -I | awk '{print $1}')

첫줄의 명령어를 이용해서 깔끔하게 클러스터를 없애주었다.

그리고 두번째 줄의 명령어를 입력해서 자기 자신의 ip가 apiserver의 ip와 동일해지도록 설정한다.

나의 경우 dhcp 로 할당받은 192.168.0.3이 api 주소가 된다.

달러표시 앞부분을 모두 지우로 echo 를 통해 어떤 ip가 할당되는지 확인할 수 있다.

 

이랬더니 kubelet 이 활성화 되어있음에도 불구하고 타임아웃이 발생해 버렸다.

디깅을 좀 더 해보니 몇가지 추가적인 설정을 해 줘야 한다.

 

sudo kubeadm init \
--apiserver-advertise-address=$(hostname -I | awk '{print $1}') \
--pod-network-cidr=192.168.0.0/16 \
--cri-socket=unix:///var/run/cri-dockerd.sock

위부터

apiserver의 주소를 고정하는 옵션

파드간의 네트워킹을 위해서 사용하는 CIDR (Classless Inter-Domain Routing) 라우팅 플러그인 calico를 위해 설정해주는 일종의 서브넷

그리고 도커 런타임을 사용하겠다는 명시 (이건 안해줘도 된다.)

 

그래도 타임아웃의 문제가 해결되지 않는다...

혹시나 해서 kubectl, kubelet, kubeadm 모두의 버전을 확인해 보았다.

 

kubeadm version
kubelet --version
kubectl version --client


apt-cache policy kubelet | grep Candidate
apt-cache policy kubeadm | grep Candidate
apt-cache policy kubectl | grep Candidate

위의 명령으로 내 현재 버전들을 볼 수 있고

아래의 명령으로 설치 가능한 최신 버전들을 볼 수 있다.

모두 1.28 이었지만 kubectl 만 1.27이었다.

 

sudo apt-get install -y kubelet=<VERSION> kubeadm=<VERSION> kubectl=<VERSION>

이 명령어를 통해 버전을 모두 일치시켜 주었다.

 

이것도 안돼서 더 디깅을 해 보았다...

 

https://stackoverflow.com/questions/67256430/kubeadm-init-error-kubeadm-timed-out-waiting-for-the-condition

 

kubeadm init error: kubeadm timed out waiting for the condition

I try execute kubeadm init --apiserver-advertise-address 49.232.211.230 --pod-network-cidr=10.244.0.0/16 -v=9 print log: [wait-control-plane] Waiting for the kubelet to boot up the control plane as

stackoverflow.com

 

여기 해법으로 진행하니 타임아웃은 해결되었다.

내용은 에러가 생겼을 수 있는 모든 구간을 리셋해주는 것으로 해결하는 모양이다.

짜잔

 

잘 된다.

apiserver의 ip값을 고정해 주는 것과 파드간의 통신을 잘 지정해 주는 것이 안정적인 클러스터 운영에 핵심임을 다시 상기하게 된다.

이제 원래 하고자 했던 싱글노드 쿠버네티스 구성하기를 할 수 있다.

 

하지만 core-dns 파드가 아직도 pending 상태인걸 보면 역시 뭔가 잘못돼있다.

노드의 상태를 찍어보니 네트워크 플러그인 설치가 안돼있다고 한다.

찾아보니 kubeadm을 초기화 할 때 네트워크 플러그인이 안따라 온다고 한다.

calico를 설치해 주자.

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

calico 파드들이 뜨면 정상적으로 잘 동작하는 것을 확인할 수 있다.

 

 

 

마스터 노드는 다른 클러스터에 연결되지 않으면

스스로에게는 일반적인 파드를 생성하지 않도록 지정될 수 있다.

따라서 이 taint가 있을 때 해제해 주면 싱글노드로 사용이 가능하다.

 

kubectl taint nodes --all node-role.kubernetes.io/master-
kubectl taint nodes --all node-role.kubernetes.io/control-plane:NoSchedule-

마스터 노드는 컨트롤 플래인으로 불리기도 하므로 위의 두개 중에 오염이 설정되어 있는 쪽을 골라서 없애주면 된다.

끝에 - 로 끝나는 것이 없애겠다는 의미이다.

 

바로 그라파나를 띄워봤다.

역시 포트포워딩이 필요없이 바로 호스팅이 가능하다.

 

반응형

댓글