Kubernetes

Kubernetes - 설치하기

rygus 2025. 9. 14. 21:57
728x90

안녕하세요.

오늘은 쿠버네티스 설치 과정에 대해 포스팅해 보겠습니다. 

 

참고로 저는 클라우드 환경에서 IaaS 방식으로 배포하였기 때문에 따로 OS 내부 방화벽 설정은 진행하지 않았습니다.

# 마스터 워커 노드 공통으로 설치

지금부터 설명드리는 명령어들을 마스터 노드와 워커 노드 모두에 설정해주셔야합니다. 

 

sudo -i
apt-get update -y
apt-get install -y containerd

 

위 명령어는 컨테이너 런타임을 설치하는 명령어로 

컨테이너 런타임은 컨테이너를 실행하고 관리하는 소프트웨어입니다. 

저희는 `containerd`를 설치하겠습니다. 

 

`sudo -i` : 리눅스 내부 커널 등을 건드려야 하기 때문에 root 권한 필요
`apt-get update -y`  : 패키지 업데이트 진행
`apt-get install -y containerd`  : containerd 설치

mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml

 

containerd를 처음 설치하면 기본 설정 파일이 없어 기본 템플릿을 만드는 과정입니다.

 

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

 

cgroup은 쿠버네티스를 이루는 주된 기술 중 하나로 프로세스 별로 자원을 분배하는 리눅스 내부 기술입니다. 

해당 설정을 통해 containerd가 systemd의 cgroup 관리 기능을 활용할 수 있게 됩니다.

 

systemctl restart containerd
systemctl enable containerd

 

설정을 바꾸었으니 `containerd`를 재실행을 해줍니다. 

 

swapoff -a 
sed -i '/ swap / s/^/#/' /etc/fstab

 

스왑 메모리는 메모리가 부족할 때 임시적으로 디스크를 끌어와 메모리처럼 사용할 수 있게 해주는 기술입니다. 

`swapoff`는 스왑메모리를 끄는 명령어입니다. 

스왑메모리를 켜면 kubelet이 어떤 컨테이너가 스왑메모리를 사용하고 있는지 예측할 수가 없고 운영에 장애를 줄 수 있어 끄는 걸 권장하고 있습니다. 

그리고 재부팅 시에도 유지되게 `fstab`에 등록합니다.

 

cat <<EOF> /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

 

`/etc/modules-load.d` 디렉터리는 커널 모듈 설정하는 디렉터리로 해당 폴더 내에 파일을 만들어 올리고자 하는 모듈 이름을 써놓으면 알아서 해당 모듈이 시스템 부팅시 로딩된다.

 

`overlay` 모듈 : 유니온 마운트에서 사용되는 모듈로 최신 커널에는 기본적으로 포함이 되어 있는 모듈이다.

“유니온 마운트는 여러 계층으로 이루어진 디렉터리를 하나의 디렉터리로 보이게 하는 기술”

Docker 이미지는 여러 레이어로 구성되어 있으며, 컨테이너에서 이미지 자체를 직접 변경해서는 안된다.

대신, 컨테이너에서 파일을 수정하거나 새로 생성하면, OverlayFS가 새로운 계층을 만들어 변경 사항을 기록한다. 

이 덕분에 원본 이미지는 그대로 유지되면서, 컨테이너 내부에서는 이미지와 변경 사항이 합쳐진 것처럼 보이는 것이 가능하다.

(아래 참조 글이 설명이 잘되어 있어 추가적으로 궁금하신 분들은 참고 바랍니다.)

참조 : https://blog.naver.com/alice_k106/221530340759

 

168. [Linux] 투명 셀로판지 이론을 통한 Overlay FS 사용 방법과 유니온 마운트 (Union Mount) 이해하기

이번 포스트에서는 OverlayFS (오버레이 파일 시스템) 에 대해서 다룬다. 참고로, 직접 사용해 보...

blog.naver.com

 

`br_netfilter` 모듈 : 브릿지 인터페이스를 iptable에서 처리할 수 있도록 해주는 모듈로 파드를 생성하면 파드는 가상 네트워크 인터페이스를 통해 브릿지 인터페이스에 연결된다.

각 가상 네트워크 인터페이스는 각 노드의 물리적 인터페이스(브릿지 인터페이스)를 통해 통신을 하게 되는데 이때 iptable을 통하지 않는다.

근데 쿠버네티스는 기본적으로 통신을 iptable로 관리하기 때문에 각 파드 간 통신을 할 때 iptable이 필요하여 해당 설정을 통해 가상 네트워크 인터페이스도 iptable로 관리를 받을 수 있게 된다.

 

modprobe overlay
modprobe br_netfilter

 

위 명령어를 통해 재부팅 없이 설정한 모듈을 즉시 활성화할 수 있다. 

 

cat <<EOF> /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 --system

 

`/etc/sysctl.d/` 디렉터리는 커널 매개변수를 영구적으로 지정하는 디렉터리

`net.bridge.bridge-nf-call-iptables = 1` 아까 설정한 bridge 모듈을 활성화하는 매개변수

`net.bridge.bridge-nf-call-ip6tables = 1` 똑같이 bridge 모듈 활성화인데 ipv6

`net.ipv4.ip_forward = 1` 다른 인터페이스로 트래픽을 라우팅 할 수 있게됨

`sysctl --system` 지정한 커널 매개변수를 재부팅하지 않고 바로 적용하는 명령어

 

apt-get install -y apt-transport-https ca-certificates gpg

 

 

`apt-transport-https` 패키지는 apt가 https 프로토콜을 쓸 수 있도록 지원

`ca-certificates` 패키지는 https 연결 시 서버 인증서 검증을 위해 필요

`gpg` 패키지는 apt는 gpg 키를 이용하여 저장소를 검증하는데 이때 사용되는 명령어입니다.

 

mkdir -p /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

 

 

Kubernetes 패키지를 apt로 설치 시 공식적으로 서명된 것인지 확인이 필요한데 이 서명 확인에 필요한 공개키를 받아오는 명령어

 

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' > /etc/apt/sources.list.d/kubernetes.list

apt-get update

 

Kubernetes 공식 apt 저장소를 시스템에 등록하는 명령어

저장소 추가 후에는 반드시 업데이트를 진행합니다.

 

# 마스터노드에만 실행

지금부터는 마스터노드에만 실행하면 되는 명령어들입니다. 

 

apt-get install -y kubelet kubeadm kubectl

 

이제 쿠버네티스 운영에 필수적인 것들을 설치합니다. 

 

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

 

쿠버네티스 환경에서 필수적인 이미지를 미리 다운로드하는 명령어

kube-apiserver ,kube-controller-manager ,etcd.. 등

 

kubeadm init --apiserver-advertise-address=<노드의 IP> --pod-network-cidr=192.168.0.0/16 --cri-socket /run/containerd/containerd.sock

 

클러스터를 초기화하는 명령어로 API 서버, 컨트롤러 매니저, 스케줄러 등 control-plane 컴포넌트 생성 하고 API 서버가 외부 노드에 노출될 IP 주소를 지정합니다.

그리고 아까 설치한 `containerd`를 컨테이너 런타임으로 지정합니다.

IP 주소의 경우 마스터 노드 서버의 IP로 지정해야 합니다.

 

클러스터를 초기화하고 나면 위 사진과 같이 kubeadm 명령어가 나오는데요.

따로 메모장에 기록해 둡니다. 

나중에 워커 노드 추가 시 필요합니다.

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

 

이제 root에서의 볼일은 모두 끝났습니다. 

`exit` 명령어를 통해 일반 유저로 돌아옵니다.

그리고 `kubectl` 명령어를 사용하기 위해서는 인증 파일이 필요한데 해당 파일을 유저의 홈 디렉터리 밑으로 가져오고 소유자를 본인으로 변경하는 명령어입니다. 

 

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

 

Calico 공식 깃허브에서 제공하는 yaml 파일을 가져와 calico 설치의 관리자 역할을 하는 Operator를 배포합니다.

Calico는 쿠버네티스 CNI로 쿠버네티스 내에서 파드 간 네트워크를 가능하게 해주는 역할을 합니다. 

 

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

 

실제 Calico 네트워크 구성 요소를 클러스터에 배포

 

kubectl get pods -n calico-system

 

위 명령어를 통해 정상적으로 Calico 파드가 배포되어 있는지 확인합니다.

 

이렇게 모두 `Running` 중이면 파드가 정상적으로 올라간 것입니다.

 

# 워커 노드만 

kubeadm join 10.0.7.5:6443 --token 6xz43u.7knjv401oibjvk2p \
        --discovery-token-ca-cert-hash sha256:8b870b3718c0dc54448655ada935324055b9a1007af7b7c9509a644a193e528f

 

아까 저장한 명령어를 실행합니다. 

 

이제 다시 마스터 노드로 돌아와 `kubectl get nodes`를 실행합니다. 

아래와 같이 나오면 성공!

 

# 서비스

`kubectl` 명령어를 일일이 모두 치기 너무 귀찮기 때문에 `alias`를 적용하겠습니다. 

모든 유저의 홈 디렉터리 밑에는 `.bashrc`라는 런커맨드 파일이 존재하는데요. 

 

`.bashrc` 파일의 역할은 bashshell이 실행될 때 실행되는 명령어들을 모아둔 파일입니다. 

저희는 이 파일에 `alias`를 적용할 것입니다. 

 

`alias k='kubectl'` 해당 명령어를 파일 내 아무 데나 써주면 됩니다. 

`vi ./.bashrc` vi 명령어로 파일을 수정하겠습니다. 

아무 데나 써도 되긴 하지만 저는 정리를 위해 alias를 모아둔 곳에 써두겠습니다. 

저장하고 나온 뒤 `source ~/.bashrc` 명령어를 통해 적용해 줍니다. 

사실 위 명령어 없이 그냥 터미널 껐다 켜면 자동으로 적용되긴 합니다. 

 

이제 k만 쳐도 자동으로 적용됩니다.

 

감사합니다. 

 

참고

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

 

Install and Set Up kubectl on Linux

Before you begin You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.34 client can communicate with v1.33, v1.34, and v1.35 control planes. Using the latest compatible version of kubectl helps avoid

kubernetes.io