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

최근 흥미로운 주제가 생겨서 이 시리즈를 적어 본다.

 

싱글 노드 쿠버네티스를 구성하는 방법은 여러가지가 있다.

쿠버네티스 연습이 필요한 경우 혹은

회사에서 쿠버네티스 환경을 구축해야하는데 서버컴퓨터가 한대인 경우에는

싱글노드 쿠버네티스를 선택하게 된다.

하지만 굉장히 쉬운 방법으로 설치할 수 있는 많은 싱글노드 쿠버네티스들이 가지는 한계들이 분명히 있다.

 

예를 들면 포트포워딩을 해 줘야만 쿠버네티스에 배포된 환경에 접근할 수 있다던지

레지스트리를 거쳐야만 로컬의 도커 이미지를 사용할 수 있다던지 하는 부분들이다.

 

당연, 싱글노드 쿠버네티스는 배포를 목적으로 개발된 것이 아닐 것이므로

배포를 하기 위해서는 일정 수준의 노가다를 해 줘야 한다.

 

하지만 가상머신이나 컨테이너를 노드로 활용하는 방식 외에도

물리적인 컴퓨터를 직접 노드로 만들고 스스로를 워커노드로 사용하게 등록함으로 

직접 싱글노드 쿠버네티스를 구성하는 것이 가능하다.

 

이 부분에 대해서 다뤄볼 것이다.

 

1. kubeadm 설치하기

항상 이런 새로운 단어를 보면 어떻게 읽어야하는가가 문제다..

쿠베어드민? 큐브아담? 잘 모르겠다.

 

kubeadm은 본 블로그의 "쿠버네티스 찍어 먹어 보기"에서도 사용한 적이 있는 것으로 기억하는데

직접 쿠버네티스를 구성할 수 있게 해주는 툴킷으로 잘 알려진 도구다.

 

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

Installing kubeadm

공홈의 인스톨로 가본다.

 

스왑 메모리를 사용하는 경우에 반드시 꺼줘야한다는 부분이 아니면 크게 특별한 사항은 없다.

스왑 메모리를 사용중이라면 반드시 꺼주자.

 

노드간에 정확한 구분이 가능한지 이야기하고 있지만 우리는 싱글노드를 목표함으로 이 부분도 사실상 건너뛴다.

맥주소에 관한 내용은 본 블로그의 "자취방 워크스테이션 네트워크 세팅편"을 참고하길 바란다.

2020.12.15 - [Backend MLOps/개인 환경 구축 기록] - [ 자취방 워크스테이션 ] #4 포트포워딩 및 네트워크 설정

[ 자취방 워크스테이션 ] #4 포트포워딩 및 네트워크 설정

 

6443  포트를 사용중인지 점검한다.

22번 포트에서 ssh를 사용중이지만 6443 에서는 아무 응답도 없는 것을 볼 수 있다.

443에서 알 수 있듯 쿠버네티스 인증서를 사용하는 https 통신을 하게 되는데 

나중에가면 nginx 등을 이용해서 대시보드를 열거나 할 때 인증서의 위치가 중요할 수 있으니 이 점은 생각만 하고 넘어가자.

 

컨테이너 런타임을 설치하자고 한다.

컨테이너는 본디 리눅스의 기능 중 하나로 시스템을 제외한 프로세스들을 격리하여 관리하는 기능이다.

따라서 우리에게 익숙한 도커를 사용하는 컨테이너도 있지만 사실은 이 리눅스의 컨테이너 런타임이 원조라고 할 수 있다.

아래와 같은 소켓을 선택함으로 어떤 런타임 위에서 컨테이너를 다룰지 선택할 수 있다.

 

그런데 보면 도커 소켓이 좀 이상하다.

우리가 아는 그 소켓주소가 아니다.

그에 따른 설명도 나와 있는데

기본적으로 쿠버네티스는 컨테이너를 오케스트레이션하는 방식으로

그 컨테이너는 굳이 도커 런타임의 컨테이너일 필요가 없는 것이다.

하지만 또 굳이 도커 컨테이너를 쓰겠다고 한다면 위의 컨테이너 런타임 인터페이스를 사용하라는 이야기가 되시겠다.

kubelet 1.24 버전부터 도커엔진의 지원을 그만뒀다고 하는데 kubelet이 뭔지는 "쿠버네티스 찍어 먹어 보기" 에 간략히 소개하고 있다.

2023.03.01 - [Backend MLOps/On-premise setting] - [k8s] 쿠버네티스 찍먹 - 1

[k8s] 쿠버네티스 찍먹 - 1

위에서 설명했듯이 컨테이너 기능은 리눅스에서 기본적으로 제공하기 때문에

너무 가벼운 리눅스를 굳이 고르지 않았다면 다 설치되어 있을 것이고

특히 이 글에서 사용중인 우분투에는 더더욱 깔려있다.

이제 이 세가지를 깔면 쿠버네티스를 사용할 수 있다.

kubeadm을 깐다는 것에 이 세가지를 함께 깐다는 것을 절대 의미하지 않으므로

반드시 세가지를 따로 설치하고 스스로 확인해야 한다.

특히 버전을 잘 맞추는게 중요하다고 하니 주의하자.

 

 

드디어 설치 명령어가 등장한다.

사실 슥슥 내리고 여기로 바로 가는 일이 많지만 위에 글을 많이 써 둔데는 다 이유가 있다.

정말정말 급한게 아니라면 꼭 읽어보고 넘어가는 습관을 위해 노력하자.

데비안 계열을 따라가 보자.

커널 버전이 낮아서 재부팅을 권하는 문구다. 

급하지 않다면 해주자.

 

이거 안하면 큰일난다고 경고하는데

컨테이너 런타임이랑 kubelet의 버전을 맞추는 작업이라고 한다.

실재로 쿠버네티스는 굉장히 활발하게 개발이 이뤄지고 있는 툴이라

버전이 조금만 안맞아도 동작을 잘 하지 않는 경우가 있다.

다 했는데도 계속 뭔가 잘 안된다 하면 여기로 돌아와서 둘의 버전을 명시적으로 맞춰주자.

 

kubeadm init을 루트권한으로 해주고 봤더니 컨테이너 런타임을 잡을 수 없다고 한다.

 

/etc/containerd/config.toml

위 파일에 가보니 cri 플러그인이 사용할 수 없도록 처리되어 있었다.

이렇게 설정을 바꿔주고 다시 동작하도록 했다.

 

쿠버네티스가 초기화되었다.

위와 같이 친절하게 환경변수를 세팅하도록 알려주고 있다.

복사해서 실행하자.

 

watch kubectl get all -A

 

과 같은 간단한 확인 문구를 넣으면

 

돌아가고 있는 시스템 파드들을 볼 수 있다.

방금의 쿠버네티스 성공화면에서

다른 노드가 이 노드에 접근하기 위해서는 어떻게 해야하는지

토큰과 함께 안내되었을 것이다.

하지만 싱글노드 쿠버네티스를 쓰기 위해서 위와 같이 taint를 풀어주는 작업을 해야한다.

기본적으로 마스터노드는 자기 자신에게는 시스템 파드 이외에는 배포하지 않는데

그 외의 것들을 오염(taint)으로 간주하기 때문이다.

이렇게 특정 상태를 오염으로 간주함으로 설정한 상태가 유지되는데 치명적인 것들을 사전에 방지할 수 있다.

아무튼 위의 명령어로 taint를 풀어주면 배포가 가능해 진다.

 

 

그런데 이렇게 해보니 자꾸 시스템 파드가 죽고 살고 하는 문제가 있었다.

도커가 켜져있는 상태에서 다른 컨테이너 런타임을 활성화 한 것 때문인가 싶어

도커 런타임을 이용해보기로 했다.

 

https://github.com/Mirantis/cri-dockerd

GitHub - Mirantis/cri-dockerd: dockerd as a compliant Container Runtime Interface for Kubernetes

여기의 설명대로 진행한다.

진행을 위해서 go 가 반드시 깔려있어야 한다.

 

kubeadm init --cri-socket unix:///var/run/cri-dockerd.sock

위의 명령어로 진행해 주었다.

처음 시스템 파드를 구성할 때는 containerd 런타임 위에서 진행해야하는 것 같다.

도커를 통해서 시스템 파드들이 떠있는 것을 확인할 수 있다.

음
그래도 파드들이 자꾸 죽었다 살았다하는 것은 변함이 없었다.

당연하듯 api서버가 정상 동작하는 경우에만 쿠버네티스를 쓸 수 있었고 그렇지 않은 경우에는 먹통이었다.

2편에서 이 문제점을 한번 해결해 보자.