개요

유데미  Certified Kubernetes Administrator (CKA) with Practice Tests 강의에서 제공되는 영상과 Vagrantfile을 이용하여 K8S를 구축하였다.

구축한 과정과 트러블 슈팅 내역을 기록하기 위해 글을 작성하였다.

강의에서 제공되는 Vagrantfile을 이용해 virtualBox에서 2 개의 Workernode와 1개의 Control plane을 생성하고 Vagrant ssh를 이용하여 node에 접속한 뒤 환경을 구축하였다.

K8S Cluster

• 버전 1.31.3
• containerd, flannel 사용
• ubuntu 22.4 사용

아래 1번부터 5번까지의 과정은 모든 노드에서 진행해주어야 한다.

1. IP Forwarding 활성화

쿠버네티스의 네트워크 플러그인(CNI, 예: Flannel, Calico 등)은 여러 노드 간 패킷 전달 및 포워딩을 전제로 설계되었기 때문에 사전에 몇 개의 설정이 필요하다. 

먼저 IPV4 Forwarding을 활성화 해준다.

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

sysctl net.ipv4.ip_forward

위 명령어의 결과가 1이면 활성화 된 것이다.

2. br_netfilter 활성화

br_netfilter 모듈이 없으면 브리지 네트워크를 통해 전달되는 패킷이 iptables 규칙을 적용받지 않게 되어 네트워크 정책이 올바르게 작동하지 않을 수 있다.

다음과 같은 명령어로 br_netfilter 모듈을 활성화하고 추가적인 설정을 한다.

sudo modprobe br_netfilter

sudo sysctl net.bridge.bridge-nf-call-iptables=1
sudo sysctl net.bridge.bridge-nf-call-ip6tables=1

echo "net.bridge.bridge-nf-call-iptables=1" | sudo tee -a /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-ip6tables=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

echo "br_netfilter" | sudo tee /etc/modules-load.d/br_netfilter.conf

3. Container Runtime 설치

Kubernetes와 같은 오케스트레이션 시스템에서 컨테이너를 실행하려면, 컨테이너 런타임이 필수적으로 필요하다. 

• Docker:
  • 가장 널리 사용되는 컨테이너 런타임으로, 컨테이너의 빌드, 배포, 실행을 위한 도구를 제공한다.
• containerd:
  • Docker에서 분리된 런타임으로, 컨테이너의 실행, 이미지 관리 등을 담당, Kubernetes와 함께 사용할 수 있다.
• CRI-O:
  • Kubernetes와의 호환성을 중시하는 경량화된 컨테이너 런타임으로 Docker의 대신 Kubernetes 클러스터에서 컨테이너를 실행하는 데 사용된다.

이 글에서는 containerd를 Container Runtime으로 사용하였다.

https://docs.docker.com/engine/install/ubuntu/

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

#  Install containerd
sudo apt-get install containerd.io

systemctl status containerd

위 명령어로 실행 확인 가능하다. 

4. Cgroup driver 설정

cgroupfs 드라이버는 kubelet의 기본 cgroup 드라이버이다. 

cgroupfs 드라이버가 사용될 때, kubelet과 컨테이너 런타임은 직접적으로 cgroup 파일시스템과 상호작용하여 cgroup들을 설정한다.

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

sudo vi /etc/containerd/config.toml

vi 에디터를 통해 containerd가 systemd의 cgroup 관리 기능을 사용할 수 있도록 해당 부분을 수정해준다.

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

sudo systemctl restart containerd

그 후에 containerd를 재시작한다.

5. kubeadm, kubelet, kubectl 설치

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

sudo apt-get update

# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

# If the directory `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

sudo systemctl enable --now kubelet

6. kubeadm init

 kubernetes에서 pod-network-cidr default 값이 10.244.0.0/16이기에 추가적인 설정을 피하려면 default 값을 사용해준다. 

ip address값은 ip add 명령어를 통해 확인할 수 있으며 동일한 과정을 따라왔다면 enp0s8이 해당 값이 되겠다.

kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address={control plane node ip}

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

kubectl get node, po, ns 어떤 명령으로도 정상 동작을 확인할 수 있다.

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

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

sudo kubeadm join 172.30.1.96:6443 --token udr7l0.hu1o5801ove1jnns \
        --discovery-token-ca-cert-hash sha256:d0f0941ac6c28bbf051d552358d8260b7ed1f7c0a2dceb48f2ec80f31799a26e

정상적으로 init이 성공하였다면 위와 같이 결과가 나올텐데 'sudo kubeadm join {controlplane ip}:6443 -token {token} 
--discovery-token-ca-cert-hash sha256:{hash} ' 해당 내용을 기록해두었다가 후에 worker node에서 join할 때 사용해야 한다.

7. Network cni 설치

https://github.com/flannel-io/flannel#deploying-flannel-manually

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

다음 명령어를 통해 실행하며 정상적으로 실행이 되었다면 아래와 같은 결과를 얻을 수 있다.

만약 이와 같이 error, crashloopbackoff가 발생한다면 1~4번까지의 단계 중 안한 것이 있는지 체크를 해야 한다. 

나 또한 구축하던 도중 아래와 같은 오류를 확인했고 2번 과정을 해주었더니 정상적으로 실행이 되었다.

8.  worker node 추가

kubectl 명령어가 길기에 alias를 통해 축약해서 사용하겠다.

alias k='kubectl'

앞서 복사해둔 명령어로 정상적으로 조인이 되었다면 다음과 같이 모든 node들이 ready인 것을 확인할 수가 있다.

만약 Not Ready 상태의 노드가 있다면 해당 노드에서 sudo systemctl restart kubelet을 실행하거나, flannel이 정상 작동중인지 확인해본다.

정상 작동 확인

kubectl run nginx --image=nginx

정상적으로 nginx pod가 worker node 2에 배치가 된 것을 확인할 수 있다.

트러블 슈팅

dns와 flannel 정상 작동하지 않는 경우

control plane에서 각 worker node 위의 뜬 pod 간 통신이 안되고 pod들이 coredns를 통해 dns 시스템에 접근하지 못하는 문제가 발생함 

node에 ip가 2개 있었는데 더 작은 ip인 enp0s3가 모두 같아서 생긴 문제라 해석했다.

아래와 같은 명령어로 vi editor로 들어간 다음 --node-ip={구분 가능한 노드 ip}를 추가한다.

sudo vi /var/lib/kubelet/kubeadm-flags.env

그 후 flannel 데이터와 pod를 삭제한 후 다시 생성한다. 

개요

Kubernetes 환경에서 ETCD를 구성하는 방식에는 크게 두 가지가 있다.

1. 내부(Stacked) ETCD

Kubernetes 마스터 노드에 ETCD를 Static pod로 직접 올리는 방식이다. 

Kubernetes 설치와 함께 자동으로 구성되므로, 설정이 간단하고 Kubernetes와 ETCD가 같은 환경에 있으므로 네트워크 지연이 적고 또 별도의 관리가 필요 없어 유지보수가 편리하다.

하지만 마스터 노드가 동시에 데이터 저장소 역할을 수행하므로, 대규모 클러스터에서는 병목 현상이 발생해 속도가 느려질 수 있고 마스터 노드에 장애가 발생하면 ETCD에 저장된 데이터 또한 악영향을 받을 수 있다.

2. 외부(External) ETCD

Kubernetes 클러스터 외부에 별도로 구성된 ETCD이다.

ETCD가 독립된 노드에서 실행되므로 마스터 노드에 장애가 발생하더라도 ETCD 데이터가 보호가 되며 

ETCD 데이터가 안전하게 유지되므로 고가용성을 보장하기 쉽다.

하지만 외부 ETCD는 별도로 설치 및 관리가 필요하므로 초기 설정이 복잡하다.

Kubernetes와 ETCD 간의 네트워크 통신이 필요하므로, 네트워크 환경에 따라 성능이 영향을 받을 수 있다.

또 ETCD 서버를 별도로 모니터링하고 유지보수 해야 한다.

실습

ETCD Server 확인

실습환경에서 ETCD가 Service 형태로 ETCD 서버에 구축되어 있는 것을 확인할 수 있다.

ETCD Backup 

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/etcd/pki/ca.pem \
  --cert=/etc/etcd/pki/etcd.pem \
  --key=/etc/etcd/pki/etcd-key.pem \
  snapshot save ./cluster2.db

ETCD Restore

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/etcd/pki/ca.pem \
  --cert=/etc/etcd/pki/etcd.pem \
  --key=/etc/etcd/pki/etcd-key.pem \
  --data-dir /var/lib/etcd-data-new snapshot restore ./cluster2.db

Restore 후에 --data-dir에 명시된 위치를 바꿔주어야 정상적으로 복원된다.

vi /etc/systemd/system/etcd.service

마지막으로 복원한 etcd data 폴더의 권한을 조정한 후 etcd 서비스를 재시작한다. 

chown -R etcd:etcd /var/lib/etcd-data-new

systemctl daemon-reload
systemctl restart etcd

개요

ETCD는 Kubernetes 환경에서 쓰이는 모든 정보를 저장하는 일종의 DB이다.

key=value 형태의 데이터 저장소이기에 Snapshot을 저장하여 별도의 파일로 백업이 가능하다. 

ETCD 또한 Pod로 동작하며 주로 MasterNode에 static pod로 띄워지게 된다. 따라서 yaml파일은 /etc/kubernetes/manifasts 아래에 위치한다. 

이 ETCD를 Backup하고 Restrore하는 것이 CKA 시험에 자주 나오기에 직접 실습해보았다.  

전체적인 실습은 다음 공식문서를 보면서 따라갔다. 실제 시험에서도 공식문서를 볼 수 있기에 익숙해지면 좋다.

https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

ETCD Backup

ETCDCTL_API=3 etcdctl --endpoints=https://[127.0.0.1]:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /opt/snapshot-pre-boot.db

ETCD Restore

ETCDCTL_API=3 etcdctl --data-dir /var/lib/etcd-new snapshot restore /opt/snapshot-pre-boot.db

그 후 controlplane yaml 파일을 수정한다. 수정 후 pod가 자동 재생성된다.

vi /etc/kubernetes/manifests/etcd.yaml

volumes:
  - hostPath:
      path: /var/lib/etcd-new
      type: DirectoryOrCreate
    name: etcd-data

개요

쿠버네티스는 몇 달에 한 번씩 소규모 릴리스를 통해 새로운 피처와 기능을 발표한다.

kubectl get nodes 명령어로 현재 사용중인 kubernetes 버전이 확인 가능하며 만약 새로운 버전으로 업그레이드 하고 싶다면 공식문서를 참조해야 한다. 

CKA 시험 도중에도 공식문서 참조가 가능하니 공식문서를 따라가면서 하는 것이 공부에도 용이하다. 

https://kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

위 공식문서를 토대로 kubernetes 버전 1.30 -> 1.31로의 버전 업그레이드를 시도한다. 

버전 호환성 규칙

쿠버네티스 버전은 주 버전(major), 부 버전(minor), 패치 버전(patch)으로 구성된다. 예를 들어 v1.30.0에서는 

주가 1이고 부가 30이고 패치가 0이다. 

이러한 버전들 사이에는 호환성이 중요하기 떄문에 버전을 업데이트 하는 것에 있어서 제한을 가진다. 

가장 핵심적으로 봐야할 것은 kube-apiserver 버전이다. kube-apiserver가 쿠버네티스의 핵심 컴포넌트로, 클러스터의 상태를 관리하고 클러스터 내 모든 구성 요소가 상호작용하는 API 엔드포인트 역할을 하기 때문에 다른 구성요소들보다 높은 버전을 유지할 필요가 있다. 

이외에도 지켜야 할 규칙이 있다.

1. 부 버전(minor) 업그레이드는 한 단계씩만 가능하다.

ControlPlane 그리고 WorkerNode의 부 버전(minor version) 차이는 한 단계까지만 허용된다.

예를 들어, v1.29에서 v1.30으로는 업그레이드가 가능하지만, v1.29에서 바로 v1.31로는 업그레이드할 수 없다.

따라서 중간 버전을 건너뛰는 업그레이드는 불가능하므로, 반드시 순차적으로 한 단계씩 업그레이드해야 한다.

실제로 AWS EKS 또한 순차적으로 부 버전(minor)를 업그레이드하게끔 구성되어 있다.  

2. kubeadm이 가장 먼저 업그레이드되어야 한다.

kubeadm을 가장 먼저 업그레이드 해야 하며, 이후에 kubelet과 kubectl을 업그레이드 해야 한다.

앞서 얘기한 kube-apiserver나 controller-manager와 같은 핵심 컴포넌트들이 kubeadm을 업그레이드하면서 종속적으로 같이 업그레이드되기 때문에  kubeadm을 가장 먼저 업그레이드 해야 한다.

kubelet은 kubeadm과 같은 버전이거나 한 단계 낮은 버전만 지원한다.

예를 들어, kubeadm v1.30을 사용한다면 kubelet v1.30 또는 v1.29을 사용할 수 있다.

3. kubelet과 kubeadm의 버전 차이는 한 단계까지 허용한다.

kubeadm이 먼저 업그레이드되기 때문에, kubelet은 한 단계 이전 버전이어도 동작하지만, 반드시 이후에 kubelet도 업그레이드하여 버전을 같게 해줘야 한다.

4. kubectl 버전은 클러스터 버전과 일치해야 한다.

kubectl은 반드시 kube-apiserver 버전과 호환되어야 하며, API 서버의 버전과 동일하거나, 한 단계 상위/하위 마이너 버전일 때만 안정적으로 동작합니다.

예를 들어, API 서버가 v1.26이라면, kubectl은 v1.25, v1.26, 또는 v1.27을 사용할 수 있다.

업그레이드 전략

먼저 kubernetes를 업그레이드 하는 방법은 어느 환경에서 kubernetes를 사용하느냐에 따라 다르다 

1. CSP 

GKE (Google Kubernetes Engine), EKS (Elastic Kubernetes Service), AKS (Azure Kubernetes Service) 와 같은 CSP에서 제공하는 쿠버네티스 서비스는 자체 제공되는 관리 도구를 사용해 클러스터 업그레이드를 진행할 수 있다. 

2. Kubeadm

kubernetes 커뮤니티에서 직접 제공하고 관리되는 도구로 기본적으로 오픈소스이기 때문에 개인이 가장 많이 사용한다. 

따라서 Kubeadm을 이용한 업그레이드를 진행하였다.

Kubeadm

앞에서 얘기한 규칙대로 업그레이드를 진행한다. 

1. MasterNode 업그레이드

MasterNode가 업그레이드되는 동안 MasterNode에 떠있는 kubernetes 핵심 컴포넌트(kube-apiserver, kube-scheduler, controller-manger 등)들이 잠시 다운되게 된다. 

하지만 WorkerNode들에 떠있는 Service Pod들은 이에 영향을 받지 않고 정상 작동을 한다.

하지만 핵심 컴포넌트들이 죽었기에 새로운 pod들을 배포, 삭제, 수정 하는 것은 불가하고 kubectl을 통한 kubeapi-server 상호작용 또한 불가능하다. 

2. WorkerNode 업그레이드

MasterNode와 달리 WorkerNode 업그레이드에는 세 가지의 방식이 존재한다. 

1. 모든 WorkerNode 한번에 업그레이드

모든 worker node가 다운되며 업그레이드가 완료되면 node가 복원되는 동시에 deployment나 replicaset으로 배포가 되었던 pod들이 복원되기 시작한다. 

가장 간단하지만 client가 service에 접근하지 못한다는 단점을 가지고 있으며 node의 다운타임이 5분을 넘어간다면 모든 pod의 정보가 소실되며 그 후에는 복원되지 않는다. 

2. WorkerNode 한 개씩 업그레이드

drain 명령어를 이용하여 진행하며 업그레이드하려는 node에 존재하는 pod를 다른 WorkerNode들에게 분배해 service를 다운되지 않게끔 한다. 

3. 새로운 node를 생성한다. 

주로 클라우드에서 제공하는 kubernetes service를 쓸 떄 용이한 방법이다. 새로운 버전의 WorkerNode를 프로비저닝하고 pod를 옮긴 후 오래된 버전의 WorkerNode를 삭제한다. 

모든 WorkerNode에 위 방법을 적용한다. 

위의 경우들은 여러 개의 WorkerNode들이 있을 경우의 시나리오이므로 만약 WorkerNode가 한 개일 경우 MasterNode의 taint를 해제하여 WorkerNode에 있는 pod들을 일시적으로 옮겨줄 필요가 있다. 

업그레이드 실습 

1. Master Node 업그레이드

1) Master Node drain

해당 실습환경에서는 WorkerNode가 한 개이기 때문에 MasterNode의 taint가 해제되어있다. 

따라서 service pod를 계속 유지하기 위해 drain을 적용한다.

kubectl drain controlplane --ignore-daemonsets

2) kubeadm 패키지 버전 업그레이드

vim /etc/apt/sources.list.d/kubernetes.list

deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /

apt-cache madison kubeadm

apt-get install kubeadm=1.31.0-1.1

3) kubeadm 업그레이드 준비

업그레이드를 시작하기 전에 클러스터의 상태를 확인한다.

업그레이드 가능한 버전을 확인할 수 있고 또 호환성을 확인할 수 있다.

kubeadm upgrade plan v1.31.0

4) kubeadm 업그레이드 

kubeadm upgrade apply v1.31.0

5) kubelet 업그레이드 후 서비스 재시작

apt-get install kubelet=1.31.0-1.1

systemctl daemon-reload

systemctl restart kubelet

6) drain 해제

kubectl uncordon controlplane

2. Worker Node 업그레이드

0) worker node ssh 접속

ssh node01

1) Worker Node drain

service pod를 계속 유지하기 위해 drain을 적용한다.

kubectl drain node01 --ignore-daemonsets

2) kubeadm 패키지 버전 업그레이드

vim /etc/apt/sources.list.d/kubernetes.list

deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /

apt-cache madison kubeadm

apt-get install kubeadm=1.31.0-1.1

3) kubeadm 업그레이드 

kubeadm upgrade node

4) kubelet 업그레이드 후 서비스 재시작

apt-get install kubelet=1.31.0-1.1

systemctl daemon-reload

systemctl restart kubelet

5)  drain 해제

kubectl uncordon node01

6) 결과 확인

사진을 uncordon을 적용하지 않고 캡처해 SchedulingDisabled이지만 정상 작동한다.

쿠버네티스의 drain, cordon, uncordon 명령어는 클러스터의 노드 상태를 제어하고 유지 관리 작업을 할 때 유용하게 사용된다.

이 명령어들을 사용하여 특정 노드를 클러스터에서 일시적으로 격리하거나, 해당 노드에서 실행 중인 모든 Pod를 안전하게 다른 노드로 옮길 수 있습니다.

이러한 명령어들은 worker 노드의 OS나 kubelet 버전 업데이트 등을 위해 활용된다.

Drain

Drain 명령어는 특정 노드에서 실행 중인 모든 Pod를 안전하게 다른 노드로 이동시킨다.

Pod는 중단되거나 종료되지 않고, 다른 가용한 노드로 이동(스케줄링)된다. 이 명령은 노드에서 유지보수 작업을 수행할 때 유용하다.

Drain 명령어는 해당 노드를 Cordon 상태로 만들고, 그 후에 모든 Pod를 다른 노드로 이동시킵니다. 노드에서 서비스가 중단되지 않도록 안전하게 작업을 진행할 수 있다.

또한, Drain이 적용된 노드는 SchedulingDisabled 상태가 되며, 이후 새롭게 생성되는 어떤 Pod도 해당 노드에 생성되지 않는다.

Drain 실습

Drain을 하기 전 모습이다. 

Drain 이후의 모습

kubectl drain <node name> --ignore-daemonsets

--ignore-daemonsets 옵션으로 daemonset으로 만들어진 pod를 무시하고 drain을 진행할 수 있다. 즉 해당 pod들은 계속 drain 하려는 node에 남아있다. 

node01이 성공적으로 SchedulingDisabled가 된 것을 확인 가능하다. 또한 기존에 node01에 있던 pod들이 Controlplane으로 이동한 것을 볼 수가 있다. 

현재 Controlplane에 taint가 걸려있지 않기 때문에 가능했다. 

Drain 특징

또 알아둬야할 점이 Drain을 한 후에도 Static Pod들은 사라지지 않는다.

Static Pod들은 노드에서 바로 정의되기 때문에 자세히는 노드의 특정 디렉터리에 있는 파일을 기반으로 실행되기 때문에쿠버네티스 API 서버에서 조회하거나 제어할 수 없으며, 일반적인 Pod와는 다르게 ReplicaSet, Deployment 같은 컨트롤러의 영향을 받지 않는다.

drain 명령은 노드에서 API 서버가 관리하는 Pod들만 대상으로 하기 때문에, Kubelet이 관리하는 Static Pod는 영향을 받지 않고 계속 실행된다.

drain 명령 자체가 node가 1개인 kubernetes 환경에서는 사용하기가 어렵다. 2개 이상의 node를 가진 환경에서 사용할 수 있겠다.

Replicaset, DaemonSet, StatefulSet 등에 의해 관리되고 있는 Pod만 새로운 노드에 스케쥴링된다. 따라서, Standalone Pod은 다른 노드에 배포되지 않고 그냥 사라지게 된다. 만약 중요한 Pod가 Standalone으로 띄워져 있다면 사용에 주의해야한다.

Cordon

Cordon 명령어는 특정 노드를 스케줄링에서 제외시킨다.

즉, 해당 노드에 더 이상 새로운 Pod가 스케줄링되지 않게 된다. 이미 노드에 배치된 기존 Pod는 그대로 실행되지만, 추가적인 Pod는 배치되지 않는다.

Drarin 과정에 Cordon이 포함되어 있는 것이다. 

Cordon 실습

hr-app StandAlone pod가 Node가 SchedulingDisabled 되어도 Node에 남아있고 또 정상 작동하는 것을 확인할 수 있다.

UnCordon

UnCordon 명령어는 Cordon으로 스케줄링에서 제외된 노드를 다시 스케줄링 가능 상태로 되돌린다. 이 명령어를 실행하면 해당 노드는 다시 새로운 Pod를 받을 수 있다.

UnCordon 실습

InitContainer란

일반적으로 다중 컨테이너 Pod에서는 각 컨테이너가 Pod의 생명주기 동안 지속적으로 실행된다.

예를 들어, 웹 애플리케이션 컨테이너와 로그 에이전트 컨테이너가 함께 실행되는 경우, 두 컨테이너 모두 Pod의 수명 동안 계속 살아 있어야 하며, 하나라도 실패하면 Pod가 재시작된다.

때로는 특정 작업이 Pod의 주 컨테이너가 실행되기 전에 단 한 번만 실행되고 완료되어야 할 때가 있다.

예를 들어, 웹 애플리케이션이 실행되기 전에 코드나 바이너리를 git과 같은 저장소에서 가져오는 작업이 필요할 수 있다.

또는 외부 서비스나 데이터베이스가 준비될 때까지 대기하는 작업이 필요할 수도 있다. 이런 경우에 InitContainer가 사용된다.

InitContainer의 특징

1. 완료 후에 주 컨테이너가 실행된다. 

InitContainer는 일반 컨테이너와 유사하게 구성되지만, Pod의 initContainers 섹션에 명시된다. InitContainer가 완료될 때까지 주 컨테이너는 실행되지 않으며, InitContainer가 여러 개 있을 경우 순차적으로 실행된다.

2. InitContainer가 실패하면 주 컨테이너는 실행되지 않는다.

만약 InitContainer가 실패할 경우, 쿠버네티스는 Pod를 반복해서 재시작하며, InitContainer가 성공할 때까지 주 컨테이너가 실행되지 않는다. Pod는 pending 상태로 멈춰있게 된다.

InitContainer 실습

정상적으로 InitContainer가 실행되었을 때 

다음과 같은 yaml 파일로 multi container pod를 실행시킨다.

apiVersion: v1
kind: Pod
metadata:
  name: blue
  namespace: default
spec:
  containers:
  - command:
    - sh
    - -c
    - echo The app is running! && sleep 3600
    image: busybox:1.28
    name: green-container-1
  initContainers:
  - command:
    - sh
    - -c
    - sleep 5
    image: busybox
    name: init-myservice

정상적으로 Running 되는 것을 확인 가능하다.

kubectl  describe po blue

다음 명령어로 Init container 상태 확인 시 정상적으로 실행이 완료된 후에 바로 Terminated로 바뀌는 것을 확인할 수 있다.

InitContainer가 아직 끝나지 않았을 때

InitContainer 부분을 다음과 같이 설정할 경우 sleep을 30분동안 진행한다. 

의도적으로 주 컨테이너가 실행이 되는지 안 되는지 확인이 가능하다. 

initContainers:
  - command:
    - sh
    - -c
    - sleep 600
    image: busybox:1.28
    imagePullPolicy: IfNotPresent
    name: warm-up-1
    
   - command:
    - sh
    - -c
    - sleep 1200
    image: busybox:1.28
    imagePullPolicy: IfNotPresent
    name: warm-up-2

예상대로 다른 Pod들과 달리 아직 Init으로 멈춰있는 것을 확인 가능하다. 

InitContainer가 정상 실행되지 않았을 때

의도적으로 command를 sleeeep으로 오류로 줘 정상적인 실행이 불가하게끔 해주었다.

initContainers:
  - command:
    - sh
    - -c
    - sleeeep 600
    image: busybox:1.28
    imagePullPolicy: IfNotPresent
    name: warm-up-1

상태를 확인할 경우 purple과 다르게 CrashLoopBackOff 오류가 반환되는 것을 확인 가능하다. 

환경 변수 설정

개별 환경 변수 설정

Kubernetes에서 환경변수(ConfigMap과 Secret)는 애플리케이션 구성 및 비밀 정보를 관리하는 두 가지 핵심 리소스이다. 이 두 리소스는 애플리케이션 컨테이너에서 환경 변수를 설정하거나, 파일 시스템에 매핑하거나, 명령줄 인자로 제공할 수 있는 데이터를 저장하는 데 사용된다.

Kubernetes 환경에선 Pod를 생성할 때 Pod내에서 사용할 환경변수를 미리 지정해줄 수 있다. 

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
    - name: redis
      image: redis
      env:
        - name: DATABASE_HOST
          value: "redis.example.com"
        - name: DATABASE_PORT
          value: "6379"

단일 Pod를 구성할 때에는 추가적인 리소스를 필요하지 않기 때문에 해당 방법은 간단함 측면에서 좋을 수 있다.

하지만 여러 Pod 또는 애플리케이션에서 동일한 환경 변수를 설정해야 할 때 각 Pod 정의마다 중복해서 작성해야 하고, 또 변경이 있다면 제각각 적용해줘야 한다. 즉 유연성과 재사용성이 떨어질 수 있다. 또 가독성 측면에서 yaml 파일 자체의 길이가 길어질 수 있으므로 좋지 못하다. 

그럴 떄 사용할 수 있는게 바로 Configmap이다.

Configmap을 이용한 환경 변수 설정

ConfigMap은 환경 설정 값을 중앙에서 관리할 수 있는 쿠버네티스 리소스이다. 여러 Pod나 컨테이너가 ConfigMap에서 값을 가져와 사용할 수 있으므로, 관리 효율성이 높아진다.

ConfigMap은 YAML 파일을 통해 정의하거나 kubectl 명령어로 생성할 수 있다.

YAML 파일을 통한 Configmap 생성

먼저 redis_config.yaml 파일을 작성한다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: redis_config
data:
  DATABASE_HOST: "redis.example.com"
  DATABASE_PORT: "6379"

그 다음 YAML 파일을 사용하여 Configmap Resource를 생성해준다.

kubectl apply -f redis_config.yaml

Kubectl command로 Configmap 생성

--from-literal 옵션을 사용하여 키=값 쌍을 설정한다.

kubectl create configmap redis_config --from-literal=DATABASE_HOST=redis.example.com --from-literal=DATABASE_PORT=6379

위 두 방식으로 만든 Configmap은 모두 다음 명령어로 확인 가능하다.

kubectl get configmap

Pod에서 Configmap 사용

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
    - name: redis
      image: redis
      envFrom:
        - configMapRef:
            name: redis_config

Configmap과 개별 환경 변수 설정 비교

Secrets

앞의 환경변수 예제에서는 노출되어도 상관없는 정보를 저장한다. db open port, db name 등 하지만 외부에 노출되어선 안되는 정보를 어떻게 환경변수처럼 사용할 수 있을까? 그 때 사용되는 것이 바로 Secret이다. 

Secret은 비밀번호, API 키, 인증서와 같은 민감한 정보를 저장하는 데 사용된다. Secret은 기본적으로 Base64로 인코딩되며, 암호화된 방식으로 저장될 수 있다. 

YAML 파일을 통한 Secret 생성

먼저 redis_secret.yaml 파일 작성한다. 

다만 직접 value 값을 base64로 인코딩해서 저장해야 한다는 번거로움이 존재한다. 

apiVersion: v1
kind: Secret
metadata:
  name: redis-secret
type: Opaque
data:
  redis-password: c29tZXBhc3N3b3Jk  # "somepassword"를 base64로 인코딩한 값

그 후 kubectl 명령어로 secret resource를 생성한다.

kubectl apply -f redis-secret.yaml

Kubectl command로 Secret 생성

kubectl create secret generic redis-secret --from-literal=redis-password=somepassword

위 명령어는 redis-password라는 키에 "somepassword" 값을 저장한 Secret을 생성한다. 이 값은 자동으로 Base64로 인코딩되어 저장된다. 

Pod에서 Secret 사용

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
    - name: redis
      image: redis
      envFrom:
        - secretRef:
            name: redis-secret

개요

모니터링을 위한 Metrics Server 구축 과정이다.

Node와 Pod의 CPU, Memory 사용량을 모니터링 할 수 있다.

Git Clone

유데미 강의에서 제공하는 소스 사용 

git clone https://github.com/kodekloudhub/kubernetes-metrics-server.git

cd kubernetes-metrics-server
ls

생성

kubectl create -f .

결과 확인

kubectl get po -n kube-system

사용 가이드 

Node와 pod 사용량만 확인 가능한 것을 볼 수 있다.

Node 사용량 확인 

kubectl top node

Pod 사용량 확인

kubectl top pod

Kubernetes 환경에서 모니터링을 구축하려면, 기본적인 리소스 사용량을 모니터링할 수 있는 Metrics Server와 함께 다양한 오픈소스 모니터링 도구를 구축하여 환경을 구성하는 것이 일반적이다.

Metrics Server

Metrics Server는 Kubernetes 클러스터에서 CPU와 메모리 사용량과 같은 기본적인 메트릭을 수집하는 역할을 한다.

이는 Pod의 오토스케일링(Horizontal Pod Autoscaling) 및 리소스 모니터링을 위해 사용된다.

그러나 Metrics Server는 Persistent Storage, 네트워크 트래픽, 애플리케이션 수준의 메트릭 등은 제공하지 않습니다.

따라서 보통 여기서 위의 기능들을 구현하기 위해 추가적인 오픈소스 모니터링 도구를 구축한다. 

추가 모니터링 도구

Prometheus + Grafana

Prometheus와 Grafana는 Kubernetes 클러스터에서 모니터링 및 시각화를 위한 가장 널리 사용되는 오픈소스 도구이다.

이 두 도구를 함께 사용하면 리소스 모니터링, 애플리케이션 성능 추적, 경고(alerting) 등 다양한 모니터링 요구 사항을 충족할 수 있다. Prometheus는 데이터를 수집하고 저장하며, Grafana는 그 데이터를 시각화한다.

Prometheus 

Kubernetes 모니터링에서 가장 많이 사용되는 오픈소스로 시계열 데이터를 수집하고, 사용자의 요구에 따라 Custom Metrics를 모니터링할 수 있다.

따라서 Metrics Server가 제공하지 못하는  다양한 모니터링이 가능합니다.

Grafana

Prometheus로 수집한 데이터를 시각화하는 오픈소스로,  사용자 정의 대시보드를 만들어 실시간으로 클러스터와 애플리케이션의 상태를 모니터링한다.

EFK Stack (Elasticsearch, Fluentd, Kibana)

EFK 스택은 로그 모니터링을 위한 솔루션이다.

EFK 스택은 다음 4단계로 작동한다. 

1. Kubernetes 클러스터에서 각 Pod나 노드에서 생성되는 애플리케이션 로그, 시스템 로그 등을 Fluentd가 수집한다.

2. Fluentd는 수집된 로그를 특정 형식으로 변환하고, 필요에 따라 필터링을 적용하여 Elasticsearch로 전달한다.

3. Elasticsearch는 Fluentd로부터 전달받은 로그를 인덱스로 저장하고, 이를 빠르게 검색할 수 있도록 준비한다.

4. Kibana를 통해 Elasticsearch에 저장된 로그 데이터를 다양한 차트와 대시보드로 시각화한다.

Elasticsearch

로그 데이터를 저장하고 검색할 수 있는 강력한 검색 엔진이다.

Fluentd

로그 수집기 역할을 하며, 클러스터에서 발생하는 로그를 Elasticsearch로 전달한다.

Kibana

Elasticsearch에서 수집한 로그 데이터를 시각화하고 분석하는 도구이다.

Loki + Grafana + Promtail

ELK 스택처럼 로그 모니터링을 제공하지만 보다 경량적으로 서비스를 제공한다.

ELK 스택의 Elasticsearch는 로그 내용을 완전히 인덱싱하여 검색할 수 있는 구조이기에 많은 리소스를 소모하고 비용이 많이 든다.

반면에, Loki는 메타데이터만 인덱싱하여 훨씬 가볍게 동작한다. 

Loki

경량 로그 모니터링 도구로, Promtail과 함께 Kubernetes 환경에서 발생하는 로그를 수집한다.

Grafana

Prometheus와 함께 사용되던 것과 똑같이 Loki와 함께 로그 데이터를 시각화하고 분석하는 데 사용된다.

Promtail

Loki에 로그를 보내는 로그 수집 에이전트로, 각 노드의 컨테이너 로그를 수집하고 Loki에 전달한다.

추후 목표

지난 번 프로젝트에서 EKS 환경에서 Monitoring을 구축하기 위해 Prometheus와 Loki 그리고 Grafana을 사용했었다.

하지만 Monitoring 부분을 다른 팀원이 담당하였고, 따라서 이론적으로 각각의 도구들이 어떠한 역할을 하는지는 알고 있지만 직접 구축을 하는 부분은 경험하지 못하였다.

따라서 추후 Local Kubernetes 환경에서 Prometheus와 Loki 그리고 Grafana를 구축하여 직접 메트릭을 작성하고 대시보드를 그려보고자 한다.