[Kubernetes] 쿠버네티스 개념과 설치 방법

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.

 

Kubernetes

---

이번 포스팅에서 부터는 쿠버네티스 시리즈 포스팅을 게시한다. 그 첫 챕터로, 쿠버네티스에 대한 개념에 대해 알아보고, 쿠버네티스를 설치하는 여러가지 방법에 대해 알아보자. 

1. 쿠버네티스는 뭘까?

지난 시간까지 도커 시리즈 포스팅으로 도커엔진에 대해 다루는 방법부터 해서 여러 호스트의 도커를 관리하는 도커 스웜, 여처 개의 컨테이너를 한 번에 관리하는 도커 컴포즈 등에 대해 배워왔다. 그런데 이러한 개념들을 한 군데로 모아 사용할 수 있는 프로젝트가 있는데, 그것이 바로 쿠버네티스이다. 

 

쿠버네티스는 도커 스웜 모드처럼 여러 대의 호스트의 도커를 하나의 클러스터로 만들어준다는 측면에서는 비슷하나, 도커 스웜보다는 더 세부적인 기능을 폭넓게 제공하고 있다는 것이 특징이다. 그래서 현업에서의 애플리케이션 서비스 운영 단계에서 대부분의 회사들이 쿠버네티스를 사용하고 있다.

 

그러면 쿠버네티스는 단순히 도커 스웜과 비슷한 역할을 하는 도구의 또 다른 종류인 걸까? 아직 스스로에게 쿠버네티스가 무엇인지 설명하라고 하면 명확히 정의 내리기가 모호하다. 따라서 좀 더 명확하게 쿠버네티스가 어떤 개념인지 알아볼 필요가 있을 듯 하다. 그 전에 앞서 우리가 지금까지 배웠던 도커엔진의 실체(?)에 대해서 짚어보아야 할 것이 있다.

1-1. 도커는 사실 컨테이너가 아니다?

도커 시리즈의 첫 포스팅에서 우리는 도커라는 것이 컨테이너의 한 종류라고 배웠던 기억이 있다. 그 때 당시에는 책에서도 그랬지만 도커라는 개념을 직관적으로 이해시키기 위해서 책의 초반부 설명에서는 도커를 OpenVZ, cri-o와 같은 컨테이너의 종류 중 하나라고 간단히 설명했었다. 사실 엄밀히 말하면 도커와 cri-o, OpenVZ와 동일한 카테고리의 개념은 아니다. 심지어 cri-o, OpenVZ도 사실은 컨테이너의 종류가 아닌 컨테이너 런타임 종류 중 하나이다. 갑자기 혼란스럽다..도커가 컨테이너가 아니라니? 이에 대해 이해하기 위해서 천천히 아래 내용을 하나씩 짚어보자.

 

우선 컨테이너 런타임이라는 것은 컨테이너를 만들거나 삭제하는 등과 같이 컨테이너를 제어할 수 있는 프로그램을 의미한다. 그리고 이렇게 컨테이너를 제어하는 프로그램 즉, 컨테이너 런타임을 웹 통신의 규칙인 HTTP처럼 일종의 프로토콜이자 규칙으로 만든 것이 바로 컨테이너 런타임 인터페이스(CRI, Container Runtime Interface)라고 부른다.

 

도커, 그 중에서도 도커 서버의 역할이자 도커의 핵심 프로세스라고 하는 도커 데몬(dockerd)이 우리는 컨테이너를 직접적으로 제어하는 즉, 컨테이너 런타임의 한 종류라고 그동안 인식하고 있었다. 하지만 실제적으로 도커 엔진에서 컨테이너 런타임의 역할을 하는 일명 '컨테이너 프로세스'라고 불리는 것은 컨테이너 런타임을 구성하는 요소 중 하나인 runC가 하게 된다. 이 runC 라는 것은 컨테이너와 1:1으로 매칭되는 것이 특징이다. 즉, 컨테이너가 2개이면 runC가 2개이고, 컨테이너가 10개면 runC가 10개가 된다. 이러한 여러 개의 runC 라는 컨테이너 프로세스를 관리하는 주체가 바로 containerd 라는 컨테이너 런타임 인터페이스(CRI)의 종류 중 하나이다. 따라서 실질적으로 컨테이너를 관리하는 주체는 CRI 종류 중 하나인 containerd 이다.

 

여기서 그러면 runC와 containerd 와의 차이점은 무엇인지 궁금할 수 있다. runC는 앞서 말한 것처럼 컨테이너와 1:1으로 매칭되는 것으로, 단일 컨테이너에 대한 작업을 수행하는 것이다. 그리고 containerd는 이러한 여러개의 runC들을 오케스트레이션 하는 CRI 종류 중 하나다. 아래 그림을 보면 좀 더 명확할 것이다. 아래 그림은 도커 엔진에서 containerd, runC, 컨테이너들이 어떤 상호작용을 하는지 보여주는 그림이다.

 

도커 엔진에서의 컨테이너를 제어하는 구조

 

위 그림을 보면 각 컨테이너마다 runC 라는 런타임이 매칭되어 있고, 이 runC를 활용해서 컨테이너를 제어하는데, 이 runC가 1개가 아니고 여러개이다 보니, 하나의 툴로 여러개의 runC를 제어함으로써 곧 여러개의 컨테이너를 제어할 수 있게 된다. 이 때 '하나의 툴' 이라는 것이 바로 CRI 종류 중 하나인 containerd 이다. 도커 엔진에서는 도커 데몬이 이 containerd와 통신하면서 컨테이너를 제어하는 구조였다.

1-2. 도커 엔진이 없어도 동작하는 쿠버네티스

이제 도커 엔진의 실체(?)에 대해 알아보았다. 위 구조와 대비해서 쿠버네티스는 그러면 어떤 구조일까? 아래 그림을 보자.

 

Kubernetes에서의 컨테이너를 제어하는 구조

 

도커 엔진 구조에서의 Docker Engine의 역할이 쿠버네티스에서는 Kubernetes(kubelet)으로 대체된 것을 알 수 있다. 여기서 핵심은 쿠버네티스에서는 도커 엔진이 없어도 컨테이너를 제어할 수 있다는 것이다. 이것이 가능한 이유는 위에서 배운 것처럼 "컨테이너를 실질적으로 제어하는 주체는 CRI(ex. containerd, cri-o, OpenVZ, LXC, 등..) 이기 때문"이다! 따라서 쿠버네티스일 때의 구조를 보면 도커 엔진이 없어도 containerd 나 cri-o와 같은 CRI 구현체만 있어도 컨테이너를 제어할 수 있는 것이다. 물론 이 때, 도커 엔진이 없기 때문에 컨테이너를 제어하기 위해 사용자는 'docker~' 라는 키워드로 시작하는 명령어를 사용할 수 없다. 대신 'crictl ~' 와 같은 키워드로 시작하는 명령어 사용이 가능하다. 물론 쿠버네티스에서는 crictl 이라는 명령어보다는 쿠버네티스의 기능을 폭넓고 다양하게 활용하기 위해 (우리가 흔히 아는) kubectl 이라는 명령어를 사용하는 것이다.

 

자, 이 정도면 쿠버네티스가 정확히 어떻게 분리되는 개념인지 이전보다 확 와닿을 것이다. 그러면 이제 간단하게 쿠버네티스가 도커 스웜과 같은 다른 오픈소스 오케스트레이션 툴보다 어떤 장점들이 있는지 살펴보자.

 

• 서버 자원 클러스터링, 마이크로서비스 구조의 컨테이너 배포, 서비스 장애 복구 등 컨테이너 기반의 서비스 운영에 필요한 여러가지 오케스트레이션 기능을 지원
• 많은 오픈소스에서 쿠버네티스의 소스 코드에 기여하고 있기 때문에 성능과 안정성 측면에서 신뢰도가 있는 소프트웨어
• 영속적 볼륨, 스케쥴링, 장애 복구, 오토 스케일링, 서비스 디스커버리 및 인그레스와 같은 컨테이너 기반의 클라우드를 운영할 때 필요한 대부분의 기능과 구성요소를 사용자가 직접 커스터마이징 할 수 있음
• 다른 클라우드 운영 도구들과 쉽게 연동이 되어 확장성이 높음

이런 것들로 보아, 쿠버네티스를 활용하면 참 많은 장점이 있는 것 같다. 하지만 그 장점이 많은 만큼 쿠버네티스를 제대로 활용하기 위해서는 그만큼 훨씬 많은 지식을 필요로 한다. 밑에서 배우겠지만, 클라우드에서 제공하는 매니지드 쿠버네티스 서비스가 아닌 직접 온프레미스 서버에서 구축하는 경우에는 훨씬 더 많은 지식을 요구하게 되고, 자칫하다간 오버 엔지니어링, 기술 부채가 될 가능성도 존재한다. 따라서 쿠버네티스를 활용하기 전에 각자의 환경을 우선적으로 고려해야 한다.

 

그러면 다음 목차부터 쿠버네티스를 설치하는 여러가지 방법과 각기 특징을 살펴보도록 하자.

2. 쿠버네티스를 설치하는 다양한 방법

쿠버네티스를 설치하기 위해서는 우선 쿠버네티스를 적용하기 위한 그 환경에 따라 방법이 약간 달라진다. 우선 크게는 아래 2가지 용도에 따라 설치할 쿠버네티스 관련 프로그램이 달라진다.

 

용도	설치할 프로그램들
개발 용도	- Minikube - Docker for Desktop for Mac/Windows에 내장된 쿠버네티스
서비스 테스트 또는 운영 용도	- kops - kubespray - kubeadm - AWS의 EKS(Elastic Kuberenetes Service) - GCP의 GKE(Google Kubernetes Engine)

 

보통은 개인이 쿠버네티스를 스터디하는 목적으로 한다면 위 표에서 개발 용도의 프로그램들을 설치해서 공부를 진행한다. 하지만 이러한 개발 용도의 쿠버네티스 프로그램들은 하나의 머신(ex. 개인 노트북, 하나의 VM) 즉 하나의 로컬 노드를 standalone 모드로 사용하기 때문에 쿠버네티스의 기능을 완벽하게 사용하기가 불가능하다. 왜냐하면 쿠버네티스의 진정한 힘은 여러 머신 즉, 여러 호스트의 컨테이너들을 관리할 때 발휘되기 때문이다.

 

또 쿠버네티스를 설치할 때 고려할 다른 측면으로는 서버 환경이 있다. 서버를 온프레미스로 구성할 것인지, AWS나 GCP와 같은 클라우드에서 제공하는 매니지드 서비스를 이용할 것인지, 클라우드의 서버를 활용하되 서버 내의 쿠버네티스는 직접 설치하는 방향으로 할 것인지가 있다. 클라우드에 종속될 수록 관리의 복잡도는 감소하긴 하지만 직접적으로 커스터마이징할 수 있는 부분은 줄어들 수 있다. 관리 복잡도와 자유도의 trade-off 관계라고 할 수 있다. 

 

다음은 쿠버네티스 버전을 선택해보는 것이다. 쿠버네티스의 기능은 매우 빠르게 업데이트 되고 있는 추세이기 때문에 사소한 버전 차이로 인해 쿠버네티스의 사용 방법이나 기능이 달라지거나 할 수 있다. 책 저자분은 쿠버네티스를 설치할 때는 너무 최신 버전이나 너무 예전 버전을 사용하지 않는 것이 좋다고 권고한다. 앞으로 책에서 설명할 모든 부분은 쿠버네티스 1.23의 버전을 기준으로 한다. 현재(2023.06.18) 기준 쿠버네티스 버전은 현재 1.27 버전까지 나온 듯 하다.

 

그러면 이제 쿠버네티스를 실제 설치하는 몇 가지 방법에 대해 알아보자.

2-1. Mac에서 쿠버네티스 설치하기

Mac OS를 사용하는 유저이면서 도커를 사용해본 유저라면 Docker for Desktop for Mac 프로그램이 이미 깔려있을 것이다. 맥에서는 해당 프로그램을 이용해서 쿠버네티스를 설치할 수 있다. 해당 프로그램 아이콘을 눌러 [Settings ➔ Kubernetes] 탭으로 이동해보면 아래와 같은 화면이 나온다. 그리고 'Enable Kubernetes' 박스를 체크해주고 Apply & Restart 버튼을 누르면 쿠버네티스가 설치된다. 

 

Docker for Desktop for Mac에서 Kubernetes 설치하기

 

다 설치된 후, 터미널에서 아래 명령어를 활용해 쿠버네티스의 클라이언트와 서버의 버전을 출력이 되면 정상적으로 설치된 것임을 알 수 있다.

 

$ kubectl version --short

 

쿠버네티스 버전 확인

2-2. 리눅스 서버에서 쿠버네티스 설치하기

다음은 리눅스 서버에서 쿠버네티스를 설치하는 방법이다. 크게 2가지 방법이 있는데, 리눅스 서버에서 가상 머신을 설치하고, 이를 이용해 Minikube를 설치하는 것이고, 다른 방법으로는 도커 엔진만으로 Minikube를 설치하는 것이다.

 

여기에서는 실제 설치 실습을 진행하지는 않았고, 설치하기 위해 필요한 명령어들만 게시하려고 한다. 우선 가상 머신을 설치한 뒤 Minikube를 설치하는 것이다. 리눅스 서버는 우분투라고 가정하였다.

 

$ apt-get install virtualbox
$ curl -Lo minukube \
https://storage.googleapis.com/minikube/releases/v1.25.2/minikube-linux-amd64 && \
chmod +x minukube && \
sudo mv minikube /usr/local/bin/
$ curl -Lo kubectl \
http://storage.googleapis.com/kubernetes-release/release/v1.23.6/bin/linux/amd64/kubectl && \
chmod +x kubect && \
sudo mv kubectl /usr/local/bin/

 

위 명령어는 리눅스 서버에서 가상머신을 설치하고, Minikube와 kubectl을 다운로드 받는 것이다. 그리고 아래 명령어를 입력해 Minikube 가상 머신을 생성해보자.

 

$ minikube start --kubernetes-version v1.23.5

 

다음 방법은 도커 엔진이 설치되어 있는 리눅스 서버에서 도커 엔진만으로 Minikube를 설치하는 것이다. 우선 아래 명렁어를 활용해 minikube와 kubectl를 설치하자.

 

$ curl -Lo minukube \
https://storage.googleapis.com/minikube/releases/v1.25.2/minikube-linux-amd64 && \
chmod +x minukube && \
sudo mv minikube /usr/local/bin/
$ curl -Lo kubectl \
http://storage.googleapis.com/kubernetes-release/release/v1.23.6/bin/linux/amd64/kubectl && \
chmod +x kubect && \
sudo mv kubectl /usr/local/bin/

 

그리고 아래 명령어를 실행하면 된다. 잘 설치되었다면 kubectl을 활용해서 버전이 잘 출력되는지 확인 하면 된다.

 

$ minikube start --vm-driver=none
$ kubectl version --short

 

만약 설치한 minikube를 삭제하려면 delete 키워드를 사용하면 된다.

 

$ minikube delete

2-3. 여러 서버로 구성된 쿠버네티스 클러스터 설치

다음은 쿠버네티스의 진정한 힘을 맛보기 위한 환경 설치가 되겠다. 바로 여러 서버(머신)로 구성된 쿠버네티스 클러스터를 설치하는 방법이다. 쿠버네티스의 기능을 제대로 활용하기 위해서는 적어도 3대 이상의 서버를 준비하는 것이 좋다. 여기 예시에서는 1개의 마스터 노드와 3개의 워커 노드로 구성된 환경을 마련했다. 단, 각 서버를 구성할 때, 아래의 사항들이 잘 지켜지는지 확인해보면 좋다.

 

• 모든 서버의 시간이 ntp를 통해 동기화되어 있는지
• 모든 서버의 맥(MAC) 주소가 다른지 확인(혹여나 가상 머신을 복사해 사용할 경우, 같은 맥 주소를 가지는 서버가 있을 수 있음)
• 모든 서버가 최소 2GB 메모리, 2 CPU 이상의 충분한 자원을 갖는지 확인
• 모든 서버에서 메모리 스왑을 비활성화하기. 메모리 스압이 활성화되어 있으면 컨테이너의 성능이 일관되지 않을 수 있기 때문에 대부분의 쿠버네티스 설치 도구는 메모리 스왑을 허용하지 않음. 메모리 스왑 비활성화는 아래 명령어를 각 서버 터미널에서 입력하면 됨

$ swapoff -a

 

필자는 클라우드를 활용해 VM 4대를 구성했고, 각 VM의 호스트 이름과 IP 주소는 아래와 같다.(IP 주소는 실제와는 다른 임의의 IP주소로 변환)

 

kube-master1 123.456.789.21
kube-worker1 123.456.789.22
kube-worker2 123.456.789.23
kube-worker3 123.456.789.24

 

쿠버네티스 클러스터를 설치하는 과정은 크게 다음과 같다.

 

1. 각 서버에 쿠버네티스 저장소를 추가
2. 각 서버에 CRI 구현체(ex. containerd, cri-o 등..)와 쿠버네티스 클러스터 도구(ex. kubeadm)를 설치
3. 클러스터를 초기화
4. 컨테이너 네트워크 애드온 설치

먼저 1번 단계를 수행하기 위해 각 서버에서 아래의 명령어를 입력해주자. 혹시 아래 명령어 중 표준 입력으로 받아들인 텍스트를 저장할 때 사용하는 cat <<EOF 에 대해 모른다면 여기를 참고하자.

 

$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
$ cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

 

다음은 2번 단계를 수행해보도록 하자. 우선 이번 예시에서는 쿠버네티스가 활용할 CRI 구현체로서, containerd를 설치할 것이다. 그리고 이 containerd는 도커를 설치하면 같이 설치되기 때문에 도커에 포함된 containerd를 쿠버네티스와 연동해보도록 하자. 아래 명령어는 도커를 설치하고 기본적으로 CRI가 비활성화되어 있는 containerd 설정 파일을 덮어씌운 뒤 containerd를 재시작하는 역할을 한다. 그리고 마지막 줄의 명령어로 쿠버네티스 클러스터의 컨테이너를 직접적으로 제어하는 kubelet, 쿠버네티스 클러스터를 초기화하고 노드 간의 통신 및 네트워크 기타 설정을 수행하는 kubadm, 쿠버네티스 클러스터를 사용자가 조작할 수 있는 CLI인 kubectl, 마지막으로 클러스터 내에서 컨테이너 네트워크를 관리하기 위한 인터페이스는 kubernetes-cni를 설치한다.

 

참고로, 현재 예시에서는 쿠버네티스 1.23.6 버전 기준이기 떄문에 kubelet, kubeadm, kubectl은 1.23.6 버전을 명시해주도록 하자.(이렇게 3가지 버전을 맞춰주지 않으면 에러가 발생하기 때문에 삽질을 많이 함..) 만약 각 라이브러리 버전이 어떤 것이 있는지 살펴보고 싶다면 'apt-cache policy [라이브러리 이름]' 형태로 버저닝을 검색해볼 수 있다.

 

$ apt-get update
$ wget -qO- get.docker.com | sh
$ containerd config default > /etc/containerd/config.toml
$ service containerd restart
$ apt-get install -y kubelet=1.23.6-00 kubeadm=1.23.6-00 kubectl=1.23.6-00 kubernetes-cni

 

다음은 쿠버네티스 클러스터를 초기화하는 것이다. 마스터 노드의 역할을 할 서버로 가서 다음 명령어로 클러스터를 초기화한다. 이 절차는 도커 스웜에서 배웠던 것과 비슷하다.

 

$ kubeadm init --apiserver-advertise-address 123.456.789.21 \
--pod-network-cidr=192.168.0.0/16 \
--cri-socket /run/containerd/containerd.sock \
--kubernetes-version 1.23.6

 

위 명령어에서 여러가지 옵션들이 붙어있는데, 이에 대해서 하나씩 살펴보자.

 

• --apiserver-advertise-address : 다른 노드가 마스터 노드에게 접근할 수 있는 IP 주소를 명시해주어야 함. 도커 스웜때와 유사
• --pod-network-cidr : 쿠버네티스에서 사용할 컨테이너들의 네트워크 대역이며, 각 서버의 네트워크 대역과 중복되지 않게 적절히 명시해주어야 함(참고로 해당 옵션 값에 명시할 때 사용한 IP 주소뒤의 숫자인 CIDR에 대한 개념을 모른다면 여기를 참고)
• --kubernetes-version : 위에서 쿠버네티스를 설치할 때 특정 버전을 명시해주어 설치해주었다면 해당 옵션에 명시해주었던 특정 버전을 명시해주어야 함
• --cri-socket : 쿠버네티스가 사용할 CRI 구현체를 명시. 만약 도커와 containerd 양쪽 모두 사용해서 컨테이너를 제어할 수 있는 환경이라면 기본적으로 먼저 도커를 활용하게 되므로, 여기에서는 containerd를 우선적으로 사용하도록 일부러 명시를 해준 것. 참고로 쿠버네티스 1.24 버전부터는 도커 엔진을 사용할 수 없게 되었다고 함. 현재 버전이 1.27이기 때문에 더이상 도커엔진을 활용한 컨테이너 제어는 쿠버네티스에서 불가능 - 출처: 공식 문서)

마스터 노드에서 초기화가 완료되면 터미널에서 표준출력으로 여러가지 내용이 나오는데, 그 표준출력에 있는 내용을 읽어보면 추가적으로 필수로 설정해주어야 하는 명령어들이 쓰여져 있다. 그 명령어들을 연속해서 마스터 노드에서 수행해주자.

 

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

 

이제 도커 스웜과 유사하게 다른 워커 노드에서 마스터 노드로 join 시킬 수 있는 명령어가 토큰과 함께 터미널에 제공되었을 것이다. 해당 명령어를 활용해서 각 워커 노드 머신으로 이동해 join 시켜주도록 하자.

 

$ kubeadm join 123.456.789.21:6443 \
--token [TOKEN] \
--cri-socket /run/containerd/containerd.sock

 

만약 쿠버네티스 1.24 버전 이후를 활용하게 된다면 위에서 --cri-socket 옵션을 사용하지 않아도 될 것이다. 왜냐하면 더 이상 도커 엔진을 활용하는 컨테이너 제어 기능이 지원되지 않기 때문이다.(공식 문서)

 

마지막으로는 쿠버네티스 클러스터 내의 컨테이너들 간에 통신을 위해 flannel, weaveNet, calico과 같은 여러 오버레이 네트워크를 사용하도록 해주는 것이다. 책 예시에서는 calico를 사용한다. 마스터 노드로 이동해서 아래 명령어를 활용해 calico 네트워크 플러그인을 설치해주자.

 

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

 

그런데 만약 쿠버네티스 클러스터를 초기화할 때 --pod-network-cidr 옵션에 192.168.0.0/16이 아닌 별도의 IP 대역을 설정했다면 calico.yaml 파일을 wget을 통해 다운로드 받은 후, 해당 파일의 CALICO_IPV4POOL_CIDR 환경 변수에 입력해준 별도의 IP 대역을 입력해주어야 한다. wget 명령어로 다운로드 받고 vim, nano 등 텍스트 편집 에디터를 이용해서 calico.yaml 파일을 수정하면 된다.

 

$ wget https://docs.projectcalico.org/v3.22/manifests/calico.yaml

 

이제 모든 설치과정이 다 끝이 났다. 정상적으로 잘 설치되었는지 살펴보기 위해, 아래 명령어로 쿠버네티스 핵심 컴포넌트들의 실행 목록을 확인한다. 전부 Running 이라는 키워드가 등장하면 잘 설치되었다는 것이다.

 

$ kubectl get pods --namespace kube-system

 

그리고 마지막으로 아까 join 시킨 노드들이 잘 있는지 보기 위해 아래 명령어를 활용해 살펴보자.

 

$ kubectl get nodes

 

 

위 화면처럼 클러스터의 구성 노드들이 잘 보여지는 것이 확인된다. 

 

추가로 kubeadm 으로 설치된 쿠버네티스는 각 노드에서 다음 명령어를 사용해 삭제할 수 있다. 또한 쿠버네티스 설치 도중 에러가 발생했거나 테스트용 쿠버네티스 클러스터를 삭제할 때 주로 사용하는 명령어는 아래와 같다.

 

$ kubeadm reset

 

그리고 필자도 설치하면서 겪었던 삽질..이였는데, 위 명령어로 설사 쿠버네티스 클러스터를 삭제해준다고 한들 해당 서버의 /etc/kubernetes/ 디렉토리에 여러가지 설정 값이 삭제한 클러스터의 기준으로 그대로 남아있어서 새롭게 클러스터를 생성할 때 에러가 발생할 수 있다. 따라서 해당 디렉터리를 삭제해주고 다시 설치하는 것도 큰 도움이 될 것이다.

 

해당 방법들 이외에 kops를 활용해서 AWS, GCP에서 제공하는 VM 서버에서 직접 쿠버네티스를 설치하는 방법도 있고, 아예 AWS의 EKS나 GCP의 GKE와 같은 매니지드 서비스를 활용해서 쿠버네티스를 설치하는 방법도 있다. 이 방법들에 대해서는 책에 자세하게 나와있으므로 궁금하신 분들은 책 원본을 확인해보도록 하자. 이 포스팅에서는 생략하도록 한다.

---

이렇게 해서 이번 포스팅을 통해 쿠버네티스의 개념이 무엇인지, 그리고 쿠버네티스를 설치하는 여러가지 방법에 대해 알아보았다. 다음 포스팅부터는 이제 본격적인 쿠버네티스 활용법에 대해 학습해보도록 하자.