우분투 쿠버네티스 설치 및 환경 설정

https://fastcampus.co.kr/dev_online_devops_kubernetes

본 포스트는 「실무까지 한 번에 끝내는 DevOps를 위한 Docker & Kubernetes feat. AWS EKS 초격차 패키지 Online」 강의를 학습하며 정리한 내용을 다룹니다.

이번 포스트에서는 VitrualBox에 구축된 우분투 서버에 쿠버테니스 실습을 하기 위한 쿠버네티스 도구, 도커, 명령어 등을 설치하여, 쿠버네티스를 위한 VM서버 환경 설정을 구성해보겠습니다.

(1) Ubuntu 방화벽 비활성화

sudo ufw disable
sudo ufw status
Status: inactive

Ubuntu의 기본 방화벽인 ufw를 비활성화하고, 현재 상태를 확인합니다.

쿠버네티스 클러스터는 여러 노드가 서로 통신해야 합니다. 실습 환경에서 방화벽이 켜져 있으면 필요한 포트가 막혀 클러스터 구성이 실패할 수 있습니다. 따라서 교육용 VM 환경에서는 방화벽을 비활성화하여 네트워크 통신 문제를 줄입니다.

(2) Swap 비활성화

sudo swapoff -a
free
total used free shared buff/cache available
Mem: 4017752 1124056 137528 8236 2756168 2647400
Swap: 0 0 0

현재 실행 중인 시스템에서 Swap 사용을 즉시 비활성화합니다.

쿠버네티스는 기본적으로 노드의 메모리 상태를 기반으로 Pod를 스케줄링하고 관리합니다. 그런데 Swap이 활성화되어 있으면 실제 메모리가 부족해도 디스크 공간을 메모리처럼 사용하게 됩니다. 이 경우 kubelet이 노드의 메모리 상태를 정확하게 판단하기 어려워질 수 있습니다. 그래서 쿠버네티스 환경에서는 일반적으로 Swap을 비활성화합니다.

# fstab vim으로 열기
sudo vi /etc/fstab
...
...
#/swapfile none swap sw 0 0 -> swap 정보 주석처리

우분투는 서버를 재부팅하면 /etc/fstab 설정에 따라 Swap이 다시 활성화될 수 있습니다. 따라서 /etc/fstab 파일에서 Swap 설정을 주석 처리해야 재부팅 후에도 Swap이 자동으로 켜지지 않습니다. "/swapfile none swap sw 0 0" 부분을 주석처리합니다.

(3) 시간 동기화 설정

쿠버네티스 클러스터는 여러 개의 VM 또는 서버로 구성됩니다. 각 노드의 시간이 서로 다르면 다음과 같은 문제가 발생할 수 있습니다.

인증서 유효 시간 오류
kubelet과 API Server 간 통신 오류
로그 시간 불일치
클러스터 상태 판단 오류
토큰, 인증, TLS 관련 문제

따라서 모든 노드의 시간을 동기화하는 것이 중요합니다.

sudo apt -y install ntpsec

ntpsec(Network Time Protocol sec)를 설치합니다. 클러스터를 연결하는 모든 서버에 시간 동기화 서버 ntpsec을 설치하여, NTP 큐를 통해 시간 동기화를 서로 확인할 수 있습니다.

Ubuntu 24.04 계열에서는 ntp가 기존처럼 바로 설치되지 않고, ntpsec 또는 openntpd가 대체 패키지로 안내되는 경우가 있습니다.

$ sudo systemctl restart ntpsec

# 재부팅 이후
$ sudo systemctl status ntpsec

$ sudo ntpsec -p
     remote                                  refid      st t when poll reach   delay   offset   jitter
======================================================================================================
 0.ubuntu.pool.ntp.org                  .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 1.ubuntu.pool.ntp.org                  .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 2.ubuntu.pool.ntp.org                  .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 3.ubuntu.pool.ntp.org                  .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
-prod-ntp-4.ntp4.ps5.canonical.com      99.220.8.133     2 u  189  256  377 248.6260  -3.2637   4.1492
+121.134.215.104                        192.168.0.220    2 u   87  256  377   6.6592   2.7517   5.0459
+any.time.nl                            10.84.87.146     2 u   29  256  377  36.7210   2.1503   1.7205
+175.210.18.47                          216.239.35.0     2 u  211  256  377   7.7276   1.4381   3.8392
+ipv4.ntp3.rbauman.com                  133.243.238.164  2 u  244  256  377   6.4355   2.6836   3.1793
*211.108.117.211                        192.168.0.221    2 u   17  256  377   5.7740   2.4194   3.1895
+ec2-3-39-176-65.ap-northeast-2.compute 146.122.240.205  2 u  189  256  377   6.9027   1.6150   2.5858
+193.123.243.2                          211.108.117.211  3 u  188  256  377   5.0703   2.4477   1.4262

설치가 완료되면 위 명령어를 통해 NTP 서비스 재시작 및 상태를 확인합니다.

마지막에 "ntpsec -p" 명령어를 통해 현재 시간 동기화에 사용되는 NTP 서버 목록을 확인할 수 있습니다. ntpq -p 결과에 여러 NTP 서버가 표시되면 시간 동기화 대상 서버와 통신하고 있다는 의미입니다.

(4) IP 포워딩 활성화

다음으로 Linux 커널에서 IPv4 패킷 포워딩을 활성화하겠습니다. 일반적인 Linux 서버는 기본적으로 자기 자신에게 온 네트워크 요청만 처리합니다.

예를 들어 서버 IP가 다음과 같다고 해보겠습니다.

192.168.56.10

이 서버로 들어온 요청이 실제 목적지가 192.168.56.10이면 서버가 직접 처리합니다.

그런데 어떤 패킷의 목적지가 서버 자신이 아니라 다른 곳이라면, 기본 Linux 서버는 보통 그 패킷을 버립니다.

패킷 목적지: 10.244.1.5
현재 서버 IP: 192.168.56.10

이때 IPv4 포워딩이 꺼져 있으면 Linux는 이렇게 판단합니다.

이 패킷은 내 것이 아니네?
나는 라우터가 아니니까 버려야겠다.

IPv4 포워딩을 켜면 이렇게 동작합니다.

이 패킷은 내 것이 아니지만,
라우팅 테이블을 보고 다음 목적지로 전달해줄 수 있겠네.

쿠버네티스에서는 Pod, Service, Node 간에 네트워크 패킷이 전달되어야 합니다. 예를 들어 한 노드의 Pod가 다른 노드의 Pod와 통신하려면, Linux 커널이 패킷을 적절하게 전달할 수 있어야 합니다. 만약, IP 포워딩이 꺼져 있으면 쿠버네티스 네트워크가 정상적으로 동작하지 않을 수 있습니다.

$sudo -i
root@k8s-master:~#

먼저 root 사용자 권한으로 전환합니다. /proc/sys/net/ipv4/ip_forward 같은 커널 네트워크 설정 파일은 일반 사용자 권한으로 수정할 수 없습니다. 따라서 root 권한으로 전환한 뒤 설정을 변경합니다.

$echo '1' > /proc/sys/net/ipv4/ip_forward
$cat /proc/sys/net/ipv4/ip_forward
1

위 명령어를 입력하면 Linux 커널에서 IPv4 패킷 포워딩을 활성화합니다. 마지막에 위와 같이 출력되면 IP 포워딩이 활성화된 상태입니다.

만약, IP 포워딩을 활성화하지 않으면, kubeadm 초기화 과정에서 IP 포워딩이 활성화되어 있지 않을 때 아래와 같은 오류가 발생할 수 있습니다.

(5) containerd 사용을 위한 커널 모듈 설정

컨테이너를 실행하고, Pod 간 네트워크 통신을 처리해야 합니다. 이때 containerd는 컨테이너 이미지 레이어를 다루기 위해 overlay 기능을 사용하고, 쿠버네티스 네트워크는 브릿지 트래픽을 iptables로 제어하기 위해 br_netfilter를 사용합니다. 이게 다 무슨말일까요..

containerd 란?

containerd는 쿠버네티스에서 실제 컨테이너를 실행하는 컨테이너 런타임입니다. Kubernetes는 직접 컨테이너를 실행하지 않습니다. 아래와 같은 구조를 통해 실행이되며, Kubernetes는 kubelet에게 요청을 보내고, kubelet이 containerd에게 요청하고, containerd가 실제로 컨테이너를 실행합니다.

Kubernetes → kubelet → containerd → 컨테이너 실행

overlay 란?

overlay는 Linux의 파일시스템 기능이며, 쿠버테니스에서 이를 활용해 containerd 컨테이너의 여러 레이어를 겹쳐서 하나의 파일시스템처럼 보여줍니다.

컨테이너를 실행할 때 이 레이어들을 매번 하나로 복사해서 새 파일시스템을 만들면 너무 비효율적입니다. 그래서 overlay 또는 overlayfs는 여러 레이어를 겹쳐서 하나의 파일시스템처럼 보여줍니다.

iptables 란?

컨테이너 1 ─┐
컨테이너 2 ─┼── [ Linux Bridge ] ── 호스트 네트워크
컨테이너 3 ─┘

Linux 서버 안에는 bridge라는 가상 네트워크 스위치가 있습니다. 여러 컴퓨터를 LAN 케이블로 스위치에 연결하듯이, Linux 안에서는 여러 가상 네트워크 인터페이스를 브릿지에 연결해서 서로 통신하게 만들 수 있습니다. Kubernetes에서도 CNI 플러그인에 따라 Pod들을 연결하기 위해 브리지나 가상 네트워크 인터페이스를 사용합니다.

iptables는 Linux에서 bridge로 지나가는 패킷을 제어하는 기능입니다.

패킷을 검사하거나 허용/차단/NAT 처리하는 방화벽·라우팅 규칙 시스템입니다. 실무에서는 주로 다음 용도로 사용됩니다.

패킷 허용/차단
NAT 처리
포트 포워딩
Service IP를 실제 Pod IP로 연결

br_netfilter 란?

Kubernetes는 Linux bridge를 통과하는 네트워크 트래픽에 대해 iptables 규칙을 적용해야 하는 경우가 많습니다. 하지만 Linux bridge를 지나는 트래픽이 기본적으로 항상 iptables에서 처리되는 것은 아닙니다.

이때 필요한 것이 br_netfilter입니다. br_netfilter는 Linux 브리지 네트워크를 지나는 트래픽도 iptables가 확인하고 제어할 수 있도록 연결해주는 커널 모듈입니다. 즉, Kubernetes가 Pod 간 통신이나 Service 네트워크 트래픽을 iptables 기반으로 제어할 수 있도록 도와주는 역할을 합니다.

$ sudo cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

위 명령어를 입력하면 서버 부팅 시 overlay, br_netfilter 커널 모듈이 자동으로 로드되도록 설정합니다. _/etc/modules-load.d/containerd.conf_에 설정을 추가하면 다음 부팅부터 자동 적용됩니다.

$ sudo modprobe overlay
$ sudo modprobe br_netfilter

하지만 지금 바로 쿠버네티스 설치를 계속 진행해야 하므로 modprobe 명령어로 현재 실행 중인 시스템에 커널 모듈을 즉시 로드합니다.

$ sudo cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

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

$ 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

sudo sysctl --system

위 명령어는 Kubernetes 노드가 영구적으로 Pod 네트워크 트래픽을 정상적으로 처리하도록 커널 네트워크 파라미터를 설정하는 명령어입니다. 재부팅시에도 규칙이 적용되도록 합니다.

net.bridge.bridge-nf-call-iptables = 1 ⇒ IPv4 브리지 트래픽이 iptables 규칙을 타도록 합니다.
net.bridge.bridge-nf-call-ip6tables = 1 ⇒ IPv6 브리지 트래픽이 ip6tables 규칙을 타도록 합니다.
net.ipv4.ip_forward = 1 ⇒ IPv4 패킷 포워딩을 활성화합니다.

(6) docker & containerd 설치 및 설정

지금까지는 리눅수 서버가 Kubernetes 컨테이너를 실행할 설정을 진행했습니다. 이제 컨테이너 어플리케이션 설치를 진행하겠습니다.

sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common gnupg2

먼저 사용하기 위한 필수 패키지를 설치합니다.

apt-transport-https : apt가 HTTPS 저장소를 사용할 수 있도록 지원
ca-certificates : HTTPS 인증서 검증에 필요한 CA 인증서 제공
curl : 외부 URL에서 파일 다운로드
software-properties-common : apt 저장소 관리 기능 제공
gnupg2 : GPG 키 검증 및 등록

$ sudo install -m 0755 -d /etc/apt/keyrings

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

$ sudo chmod a+r /etc/apt/keyrings/docker.gpg

최근 Ubuntu/Debian 계열에서는 외부 저장소의 GPG 키를 /etc/apt/keyrings에 저장하는 방식을 사용하기에, GPG 키를 저장할 디렉터리 생성과 권한을 부여합니다.

그리고 Docker 공식 저장소의 GPG 키를 다운로드하고 apt에서 사용할 수 있는 형태로 저장합니다. 해당 GPC키는 apt 패키지를 설치할 때 해당 패키지가 신뢰할 수 있는 저장소에서 왔는지 검증합니다.

그리고 apt가 Docker GPG 키 파일을 읽을 수 있도록 권한을 설정합니다.

$echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list

$sudo apt-get update

Docker 공식 apt 저장소를 Ubuntu 패키지 저장소 목록에 추가합니다. Docker 및 containerd 관련 패키지를 Docker 공식 저장소에서 설치하기 위해 필요합니다.

apt 패키지 저장소에 목록이 추가됬으니, 현재 저장소에 등록된 패키지를 전부 update합니다. 여기서 아직 설치가 안된 도커가 설치됩니다.

$ apt-cache policy docker-ce
docker-ce:
  Installed: 5:29.4.2-2~ubuntu.26.04~resolute
  Candidate: 5:29.4.2-2~ubuntu.26.04~resolute
  Version table:
 *** 5:29.4.2-2~ubuntu.26.04~resolute 500
        500 https://download.docker.com/linux/ubuntu resolute/stable arm64 Packages
        100 /var/lib/dpkg/status
     5:29.4.2-1~ubuntu.26.04~resolute 500
        500 https://download.docker.com/linux/ubuntu resolute/stable arm64 Packages
     5:29.4.1-1~ubuntu.26.04~resolute 500
        500 https://download.docker.com/linux/ubuntu resolute/stable arm64 Packages
     5:29.4.0-1~ubuntu.26.04~resolute 500
        500 https://download.docker.com/linux/ubuntu resolute/stable arm64 Packages
     5:29.3.1-1~ubuntu.26.04~resolute 500
        500 https://download.docker.com/linux/ubuntu resolute/stable arm64 Packages

현재 apt 저장소에서 설치 가능한 docker-ce 버전을 확인합니다. 현재 설치된 도커의 버전은 몇버전인이 확인이 가능합니다. 저는 29.4.1 버전을 사용하고 있습니다.

$ sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

$ sudo docker version

Docker Engine, Docker CLI, containerd, Buildx, Docker Compose 플러그인을 설치합니다.

docker-ce : Docker Engine
docker-ce-cli : Docker 명령어 도구
containerd.io : 컨테이너 런타임
docker-buildx-plugin : 멀티 플랫폼 이미지 빌드 기능
docker-compose-plugin : Docker Compose 기능

설치가 완료되면 docker version 명령어를 통해 도커호출이 되는지 확인합니다.

$ sudo sh -c "containerd config default > /etc/containerd/config.toml"

다음으로 containerd의 기본 설정 파일을 생성합니다. containerd는 /etc/containerd/config.toml 파일을 통해 런타임 설정을 관리합니다. 쿠버네티스와 연동하기 위해서는 기본 설정 파일을 생성한 뒤 일부 설정을 수정해야 합니다.

$ sudo vi /etc/containerd/config.toml

...

disabled_plugins = []

...

이때, 생성된 설정 파일 내용에서 CRI 플러그인이 비활성화되어 있지 않은지 확인합니다. 쿠버네티스는 CRI(Container Runtime Interface)를 통해 containerd와 통신합니다. 만약 containerd 설정에서 CRI 플러그인이 비활성화되어 있으면 kubelet이 containerd를 사용할 수 없습니다.

$ sudo sed -i 's/ SystemdCgroup = false/ SystemdCgroup = true/' /etc/containerd/config.toml

$ sudo systemctl restart containerd.service

containerd의 cgroup driver를 systemd 방식으로 변경합니다. Ubuntu에서 systemd를 init 시스템으로 사용하기 때문에, kubelet과 containerd 모두 systemd cgroup driver를 사용하는 것이 권장됩니다.

설정이 끝났으면, 수정한 containerd 설정을 적용하기 위해 서비스를 재시작합니다.

$ sudo vi /etc/docker/daemon.json

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

Docker daemon의 cgroup driver, 로그 설정, 스토리지 드라이버를 설정합니다. Docker와 Kubernetes 관련 구성에서 cgroup driver를 systemd로 맞춰두면 런타임 충돌 가능성을 줄일 수 있습니다. 또한 로그 크기를 제한하지 않으면 컨테이너 로그가 계속 쌓여 디스크를 가득 채울 수 있습니다.

native.cgroupdriver=systemd : Docker도 systemd cgroup driver 사용
log-driver=json-file : 컨테이너 로그를 JSON 파일로 저장
max-size=100m : 로그 파일 최대 크기를 100MB로 제한
storage-driver=overlay2 : overlay2 스토리지 드라이버 사용

$sudo mkdir -p /etc/systemd/system/docker.service.d

Docker systemd 서비스의 추가 설정 파일을 둘 수 있는 디렉터리를 생성합니다. Docker 서비스를 systemd에서 관리할 때 별도 override 설정을 넣을 수 있는 경로입니다.

$sudo usermod -aG docker student

기본적으로 Docker 명령어는 root 권한이 필요합니다. 사용자를 docker 그룹에 추가하면 매번 sudo docker를 입력하지 않고도 Docker 명령어를 사용할 수 있습니다.

실습 과정에서 Remote Desktop Manager 접속하는 User를 student로 작성했기에, student 사용자를 docker 그룹에 추가합니다.

$sudo systemctl daemon-reload
$sudo systemctl enable docker
$sudo systemctl restart docker
$sudo systemctl status docker

지금까지 설정했던 옵션들은, 재부팅 후 적용됩니다. Docker 서비스를 systemd에 반영하고, 자동 실행을 활성화한 뒤 재시작 및 상태 확인을 수행합니다.

daemon-reload : systemd 설정 다시 읽기
enable docker : 부팅 시 Docker 자동 시작
restart docker : Docker 서비스 재시작
status docker : Docker 실행 상태 확인

$ sudo systemctl restart containerd.service

# 재시작 후
$ sudo systemctl status containerd.service

Warning: The unit file, source configuration file or drop-ins of containerd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
● containerd.service - containerd container runtime
     Loaded: loaded (/usr/lib/systemd/system/containerd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2026-05-03 15:07:33 KST; 4h 5min ago
 Invocation: 9529499dabb548f28d04a8c52ab663f4
       Docs: https://containerd.io
   Main PID: 1523 (containerd)
      Tasks: 9
     Memory: 93.1M (peak: 105.6M)
        CPU: 49.741s
     CGroup: /system.slice/containerd.service
             └─1523 /usr/bin/containerd

May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727054919+09:00" level=info msg="Start cni network conf syncer for default"
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727094085+09:00" level=info msg="Start streaming server"
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727147085+09:00" level=info msg="Registered namespace \"k8s.io\" with NRI"
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727181419+09:00" level=info msg="runtime interface starting up..."
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727418752+09:00" level=info msg="starting plugins..."
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727473919+09:00" level=info msg="Synchronizing NRI (plugin) with current runtime state"
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727675627+09:00" level=info msg=serving... address=/run/containerd/containerd.sock.ttrpc
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727696002+09:00" level=info msg=serving... address=/run/containerd/containerd.sock
May 03 15:07:33 k8s-master containerd[1523]: time="2026-05-03T15:07:33.727856419+09:00" level=info msg="containerd successfully booted in 0.063018s"
May 03 15:07:33 k8s-master systemd[1]: Started containerd.service - containerd container runtime.

마찬가지로 containerd 서비스를 재시작하고 상태를 확인합니다. Active: active (running)가 보이면 정상적으로 재시작된것입니다.

$ sudo reboot

서버 시스템도 재부팅합니다. VirtualBox로 구축된 서버가 재시작됩니다. 다음 설정들이 재부팅 후에도 정상 적용되는지 확인하기 위해 필요합니다.

docker 그룹 권한
kernel module 설정
sysctl 설정
Docker daemon 설정
containerd 설정
systemd 서비스 자동 실행

$ docker version
$ docker info
Cgroup Driver: systemd

재부팅이 됬다면 위 명령어를 통해 도커가 정상적으로 동작하는지 확인합니다. 위와 같이 표시되면 Docker의 cgroup driver가 systemd로 설정된 것입니다.

(7) Kubernetes 패키지 저장소 등록 및 설치

쿠버네티스에서 사용하는 도구 및 패키지를 apt 저장소에 등록하고 설치를 진행해보겠습니다.

#Kubernetes v1.28 패키지 저장소 GPG 키
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key |
sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

#Kubernetes v1.28 패키지 저장
$ echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

#apt 업데이트 및 설치
$ sudo apt update

Kubernetes v1.28 패키지 저장소의 GPG 키를 등록합니다. Docker GPC와 마찬가지로 apt가 Kubernetes 공식 저장소에서 패키지를 안전하게 설치할 수 있도록 신뢰 키를 등록하는 과정입니다.

키 등록 후, Kubernetes v1.28 패키지 저장소(kubelet, kubeadm, kubectl)를 apt 저장소 목록에 추가합니다.

그리고, 새로 추가한 Kubernetes 저장소의 패키지 목록을 가져와 설치를 진행합니다.

$ sudo apt-cache policy kubeadm

설치 가능한 kubeadm 버전을 확인합니다. Master Node와 Worker Node의 Kubernetes 주요 버전이 크게 다르면 클러스터 구성 과정에서 문제가 발생할 수 있습니다. 통일돤 버전을 사용할 수 있도록 합니다.

$ sudo apt -y install kubelet kubeadm kubectl

쿠버네티스 클러스터 구성에 필요한 핵심 도구를 설치합니다.

kubelet : 각 노드에서 실행되며 Pod와 컨테이너 상태를 관리
kubeadm : 쿠버네티스 클러스터를 초기화하고 노드를 조인하는 도구
kubectl : 쿠버네티스 클러스터에 명령을 내리는 CLI 도구

$ kubeadm version

$ kubectl version -o yaml

$ kubelet --version

설치가 완료되면 각 도구의 버전을 조회하여, 설치 상태를 확인합니다.

$ sudo apt-mark hold kubelet kubeadm kubectl

설치된 Kubernetes 패키지가 자동 업데이트되지 않도록 고정합니다. 이 과정은 굉장히 중요합니다.

Kubernetes는 버전 호환성이 중요합니다. 예를 들어 일부 노드는 1.28이고, 다른 노드는 자동 업데이트로 1.29가 되어버리면 예상하지 못한 문제가 발생할 수 있습니다. 따라서 실습 환경에서는 Kubernetes 관련 패키지를 hold 상태로 고정합니다.

$ sudo systemctl daemon-reload
$ sudo systemctl restart kubelet.service
$ sudo systemctl enable --now kubelet.service

kubelet 서비스를 재시작하고, 부팅 시 자동으로 실행되도록 설정합니다.

systemctl daemon-reload : systemd 설정 다시 읽기
restart kubelet.service : kubelet 서비스 재시작
enable --now kubelet.service : 지금 실행하면서 부팅 시 자동 실행 설정

마무리

이번 포스트는 구축된 우분투 VM 서버에서 쿠버네티스를 동작하기 위해 필요한 시스템 설정 및 도구,패키지 등을 설치해봤습니다.

쿠버네티스로 연동되는 클러스터는 버전 호환성이 굉장히 중요합니다. 때문에 다음 실습부터는 오늘 세팅된 k8s-master 서버를 복제하여 실습에 사용될 다수의 노드를 구축하고, 서로가 바라볼 수 있도록 IP를 설정해겠습니다.