Docker & Kubernetes 개념 총 정리 3

1. 쿠버네티스란

쿠버네티스는 컨테이너화된 애플리케이션의 자동 배포, 확장 및 관리를 해주는 오픈소스 플랫폼입니다.

쿠버네티스의 스펠링 Kubernetes 인데 고대 그리스어로 배의 조타수를 의미합니다. 첫글자 k 마지막글자 s사이에 여덞글자가 있다고 해서 쿠버네티스를 줄여서 K8s라고도 부릅니다.

쉽게 말해 쿠버네티스는 수많은 컨테이너를 관리하는 시스템입니다.  특히 다수의 서버를 운영한다면 서로 다른 서버에 작동하는 수많은 컨테이너를 한꺼번에 관리하는 것은 시간 비용이 많이 듭니다.  이런경우 쿠버네티스를 사용한다면, 여러개의 컨테이너를 쉽게 생성하고 관리할 수 있습니다.

 

 

쿠버네티스의 구조는 쿠버네티스 클러스터, 컨트롤 플레인, 노드, 워크로드, 네트워크, 스토리지로 구성되어 있습니다.

 

쿠버네티스는 다수의 노드로 구성되는 경우가 많습니다. 쿠버네티스 클러스터는 크게 마스터 노드 , 워커 노드로 구분할 수 있습니다. 개발자는 주로 마스터노드와 통신하며 사용자는 인터넷을 통해 워커 노드와 통신하는 경우가 대부분입니다.

 

 

위의 경우 마스터 노드와 워커 노드간의 유기적인 통신이 중요합니다. 이를 위해 CNI(Container Network Interface) 라는 개념이 사용됩니다. CNI는 클러스터에 존재하는 컨테이너 간의 통신을 위해 필요한 인터페이스를 의미합니다. CNI를 사용하려고 쿠버네티스 네트워크 플러그인을 제공하는데 대표적인 플러그인은 Flannel과 calico입니다. 두 플러그인 중 보안기능이 뛰어나며 다양한 기능을 제공하는 calico 사용을 권장합니다.

 

마스터 노드에서는 컨트롤 플레인 Controller Plane을 다루는데 컨트롤 플레인이란 쿠버네티스 클러스터 전반의 작업을 관리하는 역할을 합니다. 마스터 노드에서 컨트롤 플레인을 구성하는 요소는 API 서버, etcd, 스케쥴러, 컨트롤 매니저가 있습니다. 

쿠버네티스의 작업은 kubectl 명령어를 통해 마스터 노드의 kube-apiserver에게 api 요청을 보냄으로써 이루워집니다.

API 서버는 쿠버네티스 컨트롤 플레인에서의 프론트엔드 역할을 합니다. etcd는 쿠버네티스 클러스터에 존재하는 모든 데이터를 저장하는 key-value 저장소입니다. 쿠버네티스는 파드 pod라는 오브젝트를 통해 애플리케이션을 실행합니다. 파드는 쿠버네티스 클러스터를 구성하는 노드 중 하나에 실행됩니다 이때 새롭게 생성되는 파드를 어느 노드에 실행시킬지 정하는 역할을 kube-scheduler가 수행합니다. 쿠버네티스 컨트롤 매니저는 쿠버네티스 리소스를 관리하고 제어하는 역할을 합니다. 컨트롤러는 마스터 노드에서 실행되는 클러스터 상태를 모니터링합니다.

 

쿠버네티스 노드를 구성하는 구성요소에는 Kubelet, Kube-Proxy, 컨테이너 런타임, 파드가 있습니다.

쿠버네티스 클러스터를 구성하는 각 노드에는 Kubelet이 실행되는데 Kubelet은 파드 내부의 컨테이너 실행을 담당합니다.Kubelet은 파드의 상태를 모니터링하고, 파드에 이상이 발생하면 해당 파드를 재배포합니다. 

Kube-Proxy는 노드에서 네트워크 역할을 수행합니다. Kube-Proxy는 노드에 존재하는 파드들이 쿠버네티스 내부/외부와 네트워크 통신을 가능하게 합니다. 컨테이너 런타임은 컨테이너의 생명주기를 담당합니다. 이를 위해 Kubelet은 컨테이너 런타임과 통신하는데 이때 사용하는것이 컨테이너 런타임 인터페이스입니다. 쿠버네티스가 사용하는 컨테이너 런타임에는 containerd,CRI-O등이 있는데 가장 보편적으로 사용하는 런타임은 containerd입니다.

 

도커는 컨테이너가 단독으로 실행되었지만 쿠버네티스에서는 컨테이너 단독 실행이 아닌 파드내에서 실행됩니다. 파드는 컨테이너를 실행하기 위한 오브젝트인데 각 파드는 한개 혹은 여러 개의 컨테이너를 담을 수 있습니다. 즉, 파드는 컨테이너를 그룹화한 것을 의미합니다. 도커의 최소 실행 단위는 컨테이너라면 쿠버네티스의 최소 실행단위는 파드입니다. 쿠버네티스의 다수의 파드들은 여러 워커 노드에 분산되어 실행되는데, 하나의 파드에 속하는 컨테이너들은 모두 같은 노드에서 실행됩니다. 즉 서로 다른 파드는 서로 다른 노드에서 실행될 수 있지만, 하나의 파드가 분할되어 여러 노드에 실행되는 일은 없습니다. 

 

하나의 파드에 속한 컨테이너들은 하나의 목적을 위해 구성된 컨테이너들입니다. 파드는 컨테이너처럼 일시적인 존재입니다. 파드는 실행할 때마다 IP 주소를 배정받으므로 파드의 IP 주소는 실행할 때마다 변경됩니다.

워크로드(Workload)는 쿠버네티스에서 실행되는 애플리케이션을 의미합니다. 워크로드가 하나의 컴포넌트 형태로 실행하든, 다수의 컴포넌트가 함께 실행하든 쿠버네티스는 파드 내부에서 워크로드를 실행하게 됩니다. 이때 파드는 실행 중인 컨테이너의 집합을 나타냅니다. 워크노드의 종류는 레플리카셋, 디플로이먼트, 스테이트풀셋, 데몬셋, 잡과 클론잡이 있습니다.  레플리카셋(ReplicaSet)은 파드의 복제를 관리하며, 클라이언트가 요구하는 복제본 개수만큼 파드를 복제하고 모니터링 및 관리합니다. 디플로이먼트(Deployment)는  애플리케이션의 배포와 스케일링을 관리하는 역할을 담당합니다.

스테이트풀셋(StatefulSet)은 파드 사이에서 순서와 고유성이 보장되어야 하는 경우에 사용합니다.

데몬셋(DaemonSet)은 쿠버네티스를 구성하는 모든 노드가 파드의 복사본을 실행하도록 합니다. 쿠버네티스 클러스터에 새로운 노드가 추가되면 파드 역시 추가됩니다. 데몬셋은 주로 로깅, 모니터링, 스토리지 등과 같은 시스템 수준의 서비스를 실행하는데 사용됩니다. 잡(Job)과 크론잡(Cronjob)은 작업이 정상적으로 완료되고 종료되는 것을 담당합니다. 만약 파드가 정상적으로 종료되지 않는다면 재실행시킵니다. 잡은 작업이 한 번 종료되는 것을 담당하고, 크론잡은 동일한 작업이 스케쥴에 따라 여러 번 수행하는 것을 담당합니다. 크론잡은 리눅스에서 사용하는 크론 탭과 비슷한 역할을 합니다. 

 

쿠버네티스에서는 네트워크와 관련되어있는 2가지 요소인 서비스와 인그레스가 있습니다.

쿠버네티스의 서비스를 사용하면 파드를 여러 개 묶어서 클러스터 외부로 노출시킬 수 있습니다. 서비스를 사용하는 방법의 장점은 이미 실행 중인 파드를 외부로 노출시키기 위해 파드 내부를 수정할 필요가 없다는 것입니다. 쿠버네티스 서비스를 활용하면 실행 중인 파드 수정없이도 외부에 노출시켜 클라이언트와 통신 할 수 있습니다.

인그레스(Ingress)를 활용하면 쿠버네티스 내부에 존재하는 서비스를 HTTP/HTTPS 루트를 클러스터 외부로 라우팅하는 역할을 합니다.

 

컨테이너 내부에 존재하는 파일들은 수명이 짧습니다. 컨테이너 이런저런 문제가 생겨 삭제되거나 재실행되면 해당 컨테이너 내부에 존하는 파일을 모두 삭제하기 때문입니다. 하지만 쿠버네티스 스토리지를 활용하면 파드의 상태와 상관없이 파일을 보관할 수 있습니다. 

 

2. 쿠버네티스 환경설정 

쿠버네티스는 마스터노드와 워커노드라는 두 종류의 서버로 구성되어 있습니다. 편의상 서버라는 말대신 노드라는 말을 사용하겠습니다.

 

도커에서 사용한 server1을 쿠버네티스에서는 여러 가상머신이 필요하므로 복제합니다.

버츄얼박스를 실행시켜 다음과 같이 서버 복제를 합니다.

 

아래와 같이 선택 후 완료버튼을 클릭합니다.

 

동일하게 한번더 복제를 합니다. 복제가 완료되면 모두 시작합니다.

 

모든 서버의 호스트네임이 동일하여 복제한 서버의 hostname을 아래의 명령어로 변경합니다.

sudo hostnamectl set-hostname 변경할서버명
cat /etc/hostname
sudo reboot now

 

가상머신이므로 3개의 서버 모두 IP가 동일합니다. 

ifconfig
(생략)
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.4  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::a00:27ff:fefc:4e2c  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:fc:4e:2c  txqueuelen 1000  (Ethernet)
        RX packets 87  bytes 16816 (16.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 81  bytes 13724 (13.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    

아래의 명령어로 IP를 변경합니다.

cd /etc/netplan
ls -l
vi 50-cloud-init.yaml

 

서버 1 50-cloud-init.yaml

network:
    ethernets:
      enp0s3:
        addresses:
        - 10.0.2.4/24
        routes:
        - to: default
          via: 10.0.2.1 
        nameservers:
          addresses:
          - 8.8.8.8
    version: 2

 

적용 후 변경 확인

sudo netplan apply
ifconfig

 

복제서버 2

network:
    ethernets:
      enp0s3:
        dhcp4: no
        addresses:
        - 10.0.2.5/24
        routes:
        - to: default
          via: 10.0.2.1 
        nameservers:
          addresses:
          - 8.8.8.8
    version: 2

 

적용 후 변경 확인

sudo netplan apply
ifconfig

 

ssh 접속을 위해 포트포워딩 설정을 변경합니다.

 

VirtualBox를 실행 도구 > 네트워크 > 포트포워딩을 열어 설정한  IP를 적용합니다.

추가 후 적용 버튼 클릭합니다.

 

 

 

putty를 실행합니다.

 

저장 후 저장한 서버 선택 후 오픈 버튼을 눌러 정상 접속이 되는지 확인합니다.

 

나머지 복제서버도 설정합니다. 

 

 

접속 확인

쿠버네티스 클러스터를 구성하려면 3개의 서버가 서로 통신할 수 있어야합니다. 이를 위해 DNS 설정을 합니다.

복제 서버1와 기존 서버1이 통신할 수 있도록 다음과 같이 설정합니다.

 

기존서버에서 아래의 코드를 실행하여 DNS를 수정합니다.

sudo vi /etc/hosts
127.0.0.1 localhost
127.0.1.1 본인호스트명
10.0.2.4 기존서버
10.0.2.5 복제서버1
10.0.2.6 복제서버2
...생략..

 

복제서버1에서 ping을 기존서버로 테스트합니다.

복제서버1: ping 기존서버호스트명

 

복제서버1 DNS 수정

sudo vi /etc/hosts

127.0.0.1 localhost
127.0.1.1 myserver02 #본인서버호스트명

10.0.2.4 myserver01 #기존서버호스트명
10.0.2.5 myserver02 #복제서버1
10.0.2.6 myserver03 #복제서버2

 

 

복제서버2 DNS 수정

sudo vi /etc/hosts

127.0.0.1 localhost
127.0.1.1 myserver03 #본인서버호스트명

10.0.2.4 myserver01 #기존서버호스트명
10.0.2.5 myserver02 #복제서버1
10.0.2.6 myserver03 #복제서버2

 

각 노드별로 포트 통신이 원활해야합니다 . ufw 상태를 확인합니다.

sudo ufw status

 

상태가 inactive라면 아래 명령어를 생략하고 만약 active라면 아래의 명령어를 실행합니다.

sudo ufw disabled

 

모든 노드의 ufw를 정지합니다.

 

다음으로는 네트워크 설정을 합니다. 먼저 IPv4를 포워딩하여 iptables가 연결된 트래픽을 볼 수 있게 합니다.

sudo -i
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
> overlay
> br_netfilter
> EOF

 

tee 명령어를 활용하면 출력을 두 곳으로 보낼 수있는데, 한곳은 tee 다음에 명시된 파일로 출력되고 다른 한곳은 표준 출력입니다. tee 명령어를 활용하면 화면에 출력됨과 동시에 파일에 저장됩니다.

 

overlay는 리눅스 커널의 네트워크 드라이버를 가리킵니다. overlay는 서로 다른 호스트에 존재하는 파드 간의 네트워크 연결을 가능하게 하는 기술입니다. overlay를 활용하면 여러 개의 독립적인 네트워크 레이어를 겹쳐서 하나로 연결된 네트워크를 생성합니다. 즉 서로 다른 호스트에 존재하는 파드가 동일한 네트워크에 존재하는 것처럼 통신할 수 있게합니다. 따라서 overlay를 입력하면 시스템 부팅 시 overlay 네트워크 드라이버를 로드하도록 설정합니다.

br_netfilter는 네트워크 패킷 처리 관련 모듈로써 iptables/netfilter 규칙이 적용되게 합니다. 컨테이너와 호스트 간의 인터페이스 등에서 발생하는 트래픽에 대해 규칙을 적용해 트래픽을 관리한다는 의미입니다.

 

sudo modprobe overlay
sudo modprobe br_netfilter

 

modeprobe는 리눅스 커널 모듈 관리 도구입니다. 이를 이용하면 특정 모듈을 로드하거나 제거할 수 있습니다.

 

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
> net.bridge.bridge-nf-call-iptables = 1
> net.bridge.bridge-nf-call-ip6tables = 1
> net.ipv4.ip_forward = 1
> EOF

 

필요한 sysctl 매개변수를 설정하면, 재부팅 후에도 값이 유지됩니다.

브릿지 네트워크 인터페이스에 대한 ipv4 트래픽이 iptables 규칙에 의해 처리되도록 합니다.

ipv6에 대해 iptables를 처리합니다. ip_forward 값을 설정하여 커널이 처리하는 패킷에 대해 외부로 ip4 포워딩이 가능하게 만들어줍니다.

 

sudo sysctl --system

 

위 코드를 입력하면, 재부팅하지않고 sysctl 매개변수를 적용 할 수 있습니다.

 

이번에는 containerd 설정을 변경하겠습니다. 도커 설치 과정에서 containerd.io를 설치하였고 설치한 containerd는 도커 관련 작업을 할 때 사용하는데 , containerd를 쿠버네티스에서 컨테이너 런타임으로 사용할 수 있도록 설정을 변경하겠습니다. 

설정값을 저장할 디렉터리를 생성합니다.

sudo mkdir -p /etc/containerd

 

containerd config default를 통해 출력된 기본 설정값들을 tee 명령어를 통해 config.toml파일로 저장합니다.

containerd config default | sudo tee /etc/containerd/config.toml > /dev/null

 

config.toml 파일을 수정합니다. SystemdCgroup값을 false에서 true로 변경합니다.

sudo vi /etc/containerd/config.toml
...생략...
SystemdCgroup = true
...생략...

 

수정 후 containerd를 재가동하고 작동하는지 확인합니다.

sudo systemctl restart containerd
sudo systemctl enable containerd
sudo systemctl status containerd

 

 

쿠버네티스는 수많은 컨테이너를 동시에 관리합니다. 따라서 원활하게 컨테이너를 관리하려면 swap 메모리 영역을 비활성화해야하비다. 이를 위해 swap 메모리를 비활성화하겠습니다. 

 

swap 메모리를 확인합니다.

free -h

 

모두 0이라면 아래의 명령어를 생략합니다.

cat /proc/swaps

 

또한 위 명령어를 실행하여 swap메모리가 할당되어있는지 확인하고 존재하지 않는다면 비활성화되어 있는 것입니다.

 

swap 메모리를 비활성화 후 재부팅합니다.

# Swap 비활성화
sudo swapoff -a

# 부팅 시 swap이 다시 활성화되지 않도록 설정
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
shutdown -r now

 

 

3. 쿠버네티스 설치하기

공식 홈페이지를 참조하여 설치합니다.

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

kubeadm 설치하기

 

 

 

# K8s 설치를 위한 패키지 설정
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

# K8s 패키지 저장소 추가
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list  

# 패키지 업데이트
sudo apt-get update

# 설치 가능한 버전 확인
sudo apt-cache madison kubeadm

# kubeadm, kubelet, kubectl 설치
sudo apt-get install -y kubelet=1.32.0-1.1  kubeadm=1.32.0-1.1  kubectl=1.32.0-1.1

 

 

설치확인

kubelet --version
kubeadm version
kubectl version --client

 

 

인증서 상태 확인

kubeadm  certs check-expiration

 

인증이 하나도 되지 않은 것을 알 수 있습니다.

 

kubeadm이 사용할 수 있는 이미지 리스트 출력

kubeadm config images list

 

쿠버네티스 설치에 필요한 이미지를 다운로드합니다.

kubeadm config images pull

 

--cri-socket옵션을 활용해 CRI를 containerd로 설정하면 받을 수 있습니다. (pull)

 kubeadm config images pull --cri-socket /run/containerd/containerd.sock

 

쿠버네티스 초기화

https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/

kubeadm init

 kubeadm init --apiserver-advertise-address=10.0.2.4 --pod-network-cidr=192.168.0.0/16 --cri-socket /run/containerd/containerd.sock

 

 --pod-network-cidr 네트워크 대역

--apiserver-advertise-address 마스터 노드 IP

 

실행 후 가장 마지막에 나오는 값 (kubeadm join ~) 메모장에 복붙하여 저장합니다.

 

인증서 상태를 다시 확인해보면 인증이 되어있는것을 확인 할 수 있습니다.

root@myserver01:~# kubeadm certs check-expiration
[check-expiration] Reading configuration from the "kubeadm-config" ConfigMap in namespace "kube-system"...
[check-expiration] Use 'kubeadm init phase upload-config --config your-config.yaml' to re-upload it.

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Jan 10, 2026 08:18 UTC   364d            ca                      no
apiserver                  Jan 10, 2026 08:18 UTC   364d            ca                      no
apiserver-etcd-client      Jan 10, 2026 08:18 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Jan 10, 2026 08:18 UTC   364d            ca                      no
controller-manager.conf    Jan 10, 2026 08:18 UTC   364d            ca                      no
etcd-healthcheck-client    Jan 10, 2026 08:18 UTC   364d            etcd-ca                 no
etcd-peer                  Jan 10, 2026 08:18 UTC   364d            etcd-ca                 no
etcd-server                Jan 10, 2026 08:18 UTC   364d            etcd-ca                 no
front-proxy-client         Jan 10, 2026 08:18 UTC   364d            front-proxy-ca          no
scheduler.conf             Jan 10, 2026 08:18 UTC   364d            ca                      no
super-admin.conf           Jan 10, 2026 08:18 UTC   364d            ca                      no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Jan 08, 2035 08:18 UTC   9y              no
etcd-ca                 Jan 08, 2035 08:18 UTC   9y              no
front-proxy-ca          Jan 08, 2035 08:18 UTC   9y              no

 

사용자가 쿠버네티스를 활용할 수 있도록 쿠버네티스 설정을 저장할 새로운 디렉터리를 만듭니다.

새로운 디렉터리의 소유자와 그룹을 변경해 사용자가 사용할 수 있도록 합니다.

root@myserver01:~# exit
logout
user@myserver01:~$ mkdir -p $HOME/.kube
user@myserver01:~$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
user@myserver01:~$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

 

 

 

 

calico 설치하기

https://docs.tigera.io/calico/latest/getting-started/kubernetes/quickstart

Quickstart for Calico on Kubernetes | Calico Documentation

 

 

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/tigera-operator.yaml

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/custom-resources.yaml

 

설치완료 후 calico에대한 pod가 실행중인지 확인(2분소요)

watch kubectl get pods -n calico-system

 

쿠버네티스 클러스터 노드를 확인

kubectl get nodes -o wide

 

 

워커노드 설정을 하겠습니다. 

putty로 복제노드 1을 실행합니다.

user@myserver02:~$ mkdir -p $HOME/.kube
user@myserver02:~$ scp -p user@10.0.2.4:~/.kube/config ~/.kube/config
The authenticity of host '10.0.2.4 (10.0.2.4)' can't be established.
ED25519 key fingerprint is SHA256:Gg43XYu5ykdaGweqSmXm5gLlZ5J9/qVo45j9zOIJNQs.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.2.4' (ED25519) to the list of known hosts.
user@10.0.2.4's password:
config                                                                                                                                                                           100% 5652   549.6KB/s   00:00
user@myserver02:~$ cd .kube/
user@myserver02:~/.kube$ ls
config

 

scp -p는 scp 명령어의 옵션 중 하나로, 원격 서버 간 파일 전송 시 파일의 원래 타임스탬프, 권한 및 소유자 정보를 유지하는 데 사용됩니다.

 

마스터 노드인 10.0.2.4 에서 설정 파일을 그대로 가져왔습니다.

.kube 디렉터리로 이동하여 config 파일이 있는지 확인 할 수 있습니다.

 

user@myserver02:~/.kube$ sudo -i
[sudo] password for user:
root@myserver02:~# kubeadm join 10.0.2.4:6443 --token ontvah.n8kxuf6ss5kqr6o4 \
        --discovery-token-ca-cert-hash sha256:f92f87f70cdead0879884033f94eb885c775910b4a7da2e180bbca233a352af5
[preflight] Running pre-flight checks
[preflight] Reading configuration from the "kubeadm-config" ConfigMap in namespace "kube-system"...
[preflight] Use 'kubeadm init phase upload-config --config your-config.yaml' to re-upload it.
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 1.504978089s
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

 

루트권한을 획득한 후 앞서 저장했던 쿠버네티스 클러스터에 노드를 추가하는 명령어를 입력합니다. 이때 --cri-socket /run/containerd/containerd.sock은 앞서 저장한 구문에 포함되어 있지 않으므로 추가해야합니다.

컨테이너 런타임 소켓을 지정하는 것입니다.

 

마스터 서버로 가서 동작을 확인합니다.

user@myserver01:~$ kubectl get node
NAME         STATUS     ROLES           AGE   VERSION
myserver01   Ready   control-plane   56m   v1.32.0
myserver02   Ready   <none>          36m   v1.32.0
myserver03   Ready   <none>          13s   v1.32.0

 

 

Ready 상태까지 1분정도 소요됩니다.

 

쿠버네티스 설치 및 세팅까지 모두 완료하였습니다.

다음글은 쿠버네티스의 다양한 기능을 작성해보겠습니다.