Kubernetes 관리 도구

Kubernetes를 관리하는 도구 중 대표적인 것은 다음과 같이 존재한다.

kubectl: 쿠버네티스 API 서버와 상호작용하여 클러스터의 상태를 조회하거나 리소스를 관리하는데 사용하는 도구
1. Pod, Service, Deployment, ReplicaSet 등 다양한 리소스를 생성, 조회, 업데이트, 삭제할 수 있음
kubeadm: 쿠버네티스 클러스터를 설정하고 관리하는 도구
1. 쿠버네티스 클러스터의 초기화 및 설정
2. 마스터 노드 및 워커 노드의 설정
3. 클러스터 업그레이드 및 유지 관리
kubelet: 쿠버네티스 클러스터에서 각 노드에 설치되어 실행되는 에이전트
1. 노드에서 실행되는 모든 Pod와 컨테이너의 상태를 지속적으로 관리
2. 컨테이너 런타임 (Docker, containerd, cri-o등)과 상호 작용하여 컨테이너를 실행하고 관리
3. 노드의 리소스를 모니터링 하고, 필요한 경우 리소스 제한을 적용

Kubernetes 관련 도구 설치

필수로 설치를 해야 하는 도구는 kubectl, kubeadm, kubelet이다. 이 도구들은, 각각 적절한 위치 (Host PC, WSL System)에 설치를 진행한다. (설치 위치는 아래 상세 설명을 참고)

kubectl, kubeadm, kubelet

해당 도구는 API 서버와 상호작용하여 클러스터의 상태를 조회하거나, 리소스를 관리하는데 사용하는 도구이므로, 설치 위치는 Host PC, WSL System 어디든 상관없다.

하지만, WSL 상태에서 Docker를 설치하였고, Windows (Host PC)와 WSL System에서 동일한 실행 환경을 구성하려면, WSL System에 설치한 후, Host PC에서는 wsl 명령을 통해 접근하는 것이 효율적인 것이다.

Linux 상의 설치

참고 내용 : https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

자세한 설치는 위 내용을 참고하고, Ubuntu 기준으로 설치는 아래와 같이 진행하면 된다.

저장소 등록에 필요한 패키지 설치

# sudo apt-get update

# sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
저장소 접근에 필요한 공개 서명 키 등록

# curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg –dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # allow unprivileged APT programs to read this keyring
저장소 추가

# 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 chmod 644 /etc/apt/sources.list.d/kubernetes.list # helps tools such as command-not-found to work correctly
업데이트 후, 패키지 설치

# sudo apt-get update

# sudo apt-get install -y kubelet kubeadm kubectl

# sudo apt-mark hold kubelet kubeadm kubectl
(선택사항) kubelet 서비스 활성화

# sudo systemctl enable –now kubelet

CGroup 사용 설정

기본 Containerd 설정은 SystemdCgroup 설정이 비활성화 되어 있다. 아래 명령을 통해 해당 옵션을 활성화 시켜 준다.

Containerd 의 SystemdCgroup을 활성화 하는 이유는 주로 리소스 관리와 시스템 안정성을 향상시키기 위함에 있다.

CGroup은 Linux의 중요한 기능으로, 컨테이너가 사용하는 시스템 자원을 효율적으로 관리하고, 여러 프로세스나 서비스 간의 자원의 격리 기능을 제공한다.

CGroup을 활성화 하면, QoS를 통해 Pod나 컨테이너 리소스 품질을 관리하는 Kubernetes 시스템이 리소스 요청을 보다 정확히 관리하고, 우선순위에 따라 컨테이너가 필요한 리소스를 효과적으로 할당할 수 있도록 할 수 있다.

기본 설정 파일을 추출하여 기본 설정 파일에 덮어씀 (설정 파일에는 기본값을 쓰는 설정들은 제외되어 있으므로, 모두 추출)

# containerd config default | sudo tee /etc/containerd/config.toml
SystemdCgroup 설정을 활성화 하여 적용

# sudo sed -I ‘s/SystemdCgroup = false/SystemdCgroup = true/’ /etc/containerd/config.toml
컨테이너 재 시작

# systemctl restart containerd

Kubernetes 노드 구성

Master 노드 구성

아래 명령을 이용하여, 마스터 노드를 구성한다. network 구성도 같이 설정한다.

# sudo kubeadm init –pod-network-cidr=10.244.0.0/16

아래와 같은 명령과 같이 종료되면서, 노드가 정상적으로 생성된다.

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -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:

kubeadm join 172.31.202.166:6443 –token f2j7v0.3gbrthjw4w1035is \

–discovery-token-ca-cert-hash sha256:8c278d276ee5dca56e97b76a79fede37a05004d23c0ea7c8cefc88e301fd8748

위 마지막 구문이 Worker노드들이 Worker 노드들을 추가하는 명령이다.

또한 설정이 완료된 후, 설명 문구에 따라 환경 설정파일을 추가해 줘야 한다.

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

마스터 노드는, Kubernetes의 중앙 제어 지점으로 클러스터와 외부 간의 통신을 담당하며 모든 Kuberentes리소스에 대한 요청을 처리한다. 또한 클러스터의 상태를 관리하고, 사용자나 시스템이 보낸 요청을 처리한다. 마스터 노드에서는 애플리케이션이 직접 실행되지 않고, 위와 같은 상태와 관리 기능만을 수행한다.

워커 노드는, 실제 애플리케이션 컨테이너가 실행되는 노드이다. 이 노드는 Pod를 포함하는 컨테이너를 실행하고, 클러스터 내에서 애플리케이션이 실행될 수 있도록 하는 역할을 수행한다.

두가지 노드들은 부하 분산 및 가용성을 위하여 각각 최소 3대의 실행을 권장한다.

Node 설정 Reset 방법

설정이 잘못되었으면, Reset하고 다시 시도해보자.

# kubeadm reset
# rm $HOME/.kube/config
# rm –rf /etc/cni/net.d

Master Node 추가 방법

노드 생성 시 출력된 토큰을 이용하여 Master Node를 추가할 수 있다.

# kubeadm join <your-control-plane-ip>:6443 –token <token> –discovery-token-ca-cert-hash sha256:<hash> –control-plane

kubelet, kube-proxy 상태 확인

Node에 추가되면, 자동으로 kubelet과 kube-proxy 서비스가 시작된다. 해당 서비스 상태를 보고, Node 추가를 확인할 수 있다.

# systemctl status kubelet
# systemctl status kube-proxy

마지막으로 노드 상태를 확인하여 최종적으로 등록된 노드를 확인한다.

# kubectl get pods –n kube-system

Worker Node 추가 방법

Init 시 출력되는 마지막 명령어를 활용한다. Master Node추가 때와는 달리 –control-plane 인자를 제외하고 실행하면 된다.

# kubeadm join <your-control-plane-ip>:6443 –token <token> –discovery-token-ca-cert-hash sha256:<hash>

인증키를 통한 Node 보안

TLS인증서를 활용하여, Node에 접근을 인가할 수 있다.

TLS인증서를 생성한 후, init 시에, –upload-certs 인자를 통해 해당 키를 제공하고, join시 –certificate-key 인자를 통해 제공하여, 인가되지 않은 노드의 접근을 차단할 수 있다.

Master Node에서 Worker Node의 기능 설정

부하 분산 및 가용성을 위해 3대씩 역할을 분리하여 노드 구성하는 것이 좋지만, 개발 환경이거나 싱글 서버 상태로 테스트를 위해 구성을 할 때는, 굳이 역할을 분리하지 않고, 마스터 노드에서 워커 노드의 역할을 수행하도록 설정하는 것이 효과적이다.

아래 명령을 통해 마스터 노드에 워커 노드의 역할을 추가할 수 있다. (taint 제거)

# kubectl taint nodes –all node-role.kubernetes.io/master- (kubernetes 1.21 미만 버전)

# kubectl taint nodes –all node-role.kubernetes.io/control-plane- (kubernetes 1.21 이후 버전)

설정된 노드 상태를 다음 명령어로 확인한다.

# kubectl describe node <node-name>

원복

아래 명령으로 더 이상 Worker노드의 기능을 수행하지 않도록 원복 할 수도 있다.

# kubectl taint nodes –all node-role.kubernetes.io/congrol-plain=:NoSchedule

Join 명령 재 출력

만약 join 명령을 분실하여 토큰 값과 키 값을 알 수 없다면, 아래 명령을 통해 재 출력할 수 있다.

# kubeadm token create –print-join-command

CNI (Container Network Interface) 설정

CNI는 Kubernetes와 같은 컨테이너 오케스트레이션 시스템에서 컨테이너 네트워크 연결을 관리하는 표준 인터페이스다. CNI는 여러 컨테이너 간의 네트워크 통신을 가능하게 하고, 네트워크 플러그인 시스템을 통해 네트워크 설정을 처리한다.

CNI의 기본 개념

컨테이너 네트워크 연결

CNI는 각 컨테이너에 대한 네트워크 연결을 설정하고, 네트워크 인터페이스를 생성한다. 이를 통해 컨테이너가 외부 네트워크와 통신할 수 있게 해준다.

플러그인 기반 아키텍처

CNI는 플러그인 시스템을 기반으로 설계되어 있다. 따라서 네트워크 플러그인 (Calico, Flannel, Weave등)을 선택하여 다양한 네트워크 모델과 기능을 구현할 수 있다.

각 플러그인은 CNI 사양을 따르며, 네트워크 연결을 설정하는데 필요한 작업을 처리한다.

CNI플러그인

여러 CNI 플러그인이 있으며, 이들은 네트워크 모델에 따라 다르다. 예를 들어, Calico는 네트워크 보안 및 라우팅 기능을 제공하는 플러그인 이고, Flannel은 간단한 네트워크 관리 및 IP 주소 할당을 담당한다.

CNI플러그인은 Kubernetes 클러스터의 노트에 설치되며, 클러스터 내의 Pod와 컨테이너 간의 네트워크를 설정한다.

CNI 구성 파일

CNI 플러그인은 JSON형식의 구성 파일을 통해 설정된다. 이 파일은 플러그인이 어떻게 네트워크를 구성할지, 어떤 네트워크 모델을 사용할지 등을 정의한다.

CNI 플러그인 예시

Calico

Calico는 고급 네트워크 정책을 지원하며, IP 라우팅 및 네트워크 보안을 제공한다. 보안 및 네트워크 정책을 Kubernetes 네이티브 네트워크 정책과 통합할 수 있다.

Flannel

Flannel은 간단한 오버레이 네트워크 플러그인으로, 각 Pod에 IP 주소를 할당하고, Pod 간에 통신할 수 있도록 한다.

Weave

Weave는 클러스터 간에 네트워크를 연결하는 오버레이 네트워크 솔루션으로, 분산 환경에서 클러스터 간의 네트워크 연결을 쉽게 설정할 수 있다.

Cilium

Cilium은 eBPF(Extended Berkeley Packet Filter)를 기반으로 하여 고급 네트워크 보안 및 정책 기능을 제공한다. Kubernetes와 통합되어 네트워크 성능과 보안을 강화한다.

CNI의 작동 방식

Pod 생성 시

Kubernetes는 새로운 Pod이 생성되면 해당 Pod에 네트워크를 할당하기 위해 CNI를 호출한다.

CNI 플러그인 실행

CNI 플러그인은 네트워크 인터페이스를 생성하고, Pod에 IP 주소를 할당한다. 이때 플러그인은 Kubernetes의 CNI 구성 파일을 사용하여 어떤 네트워크를 사용할지 결정한다.

네트워크 설정

CNI 플러그인은 설정된 네트워크에 맞춰 Pod 간 통신을 가능하게 하거나, 네트워크 정책을 적용한다.

Pod 종료 시

Pod가 종료되면 CNI 플러그인은 해당 Pod의 네트워크 인터페이스를 삭제하고, 관련 리소스를 정리한다.

설정

해당 Kubernetes환경에서는 Calico를 사용하여 설정을 진행한다. 플러그인은 아래 명령을 통해 설치가 가능하다. CNI 플러그인은 Master Node에 설치하여 자동으로 Worker Node에 전파되게 하거나, 개별 Worker Node에 설치할 수 있다.

이렇게 CNI 설정까지 마치면 Worker노드는 “Ready” 상태가 되고, Pod가 Worker노드에서 생성되어 실행될 수 있는 상태가 된다.

Calico 설치

# kubectl apply –f https://docs.projectcalico.org/manifests/calico.yaml

아래 명령을 통해 설치 상태 확인한다. clico-node-*, calico-kube-*, clico-cni-* 관련 pod 들이 정상적으로 수행되고 있는지 확인한다.

# kubectl get pods –n cube-system

Containerd 를 통해 실행상태를 확인해 볼 수도 있다.

# crictl ps | grep calico/node

Calico 삭제

# kubectl delete –f https://docs.projectcalico.org/manifests/calico.yaml

flannel 설치 (권장 – 설정이 간편)

혹은 flannel을 설치해도 무방하다.

# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

설치된 이후, 아래 설정 파일을 수정하여 적절한 네트워크 구성을 설정하면 된다.

/etc/cni/net.d/10-flannel.conf

설정이 적용되는 데는 잠시 시간이 필요 하다… 만약 정상적으로 동작하지 않는다면 시스템을 재 시작 해보자.

클러스터와 CNI플러그인의 통합

CNI 플러그인이 Kubernetes에서 정상 동작 하도록 하려면, kubelet이 CNI를 인식하고 클러스터 내에서 네트워크를 설정할 수 있도록 해야 한다.

kubelet설정

kubelet이 CNI 플러그인을 인식하도록 –network-plugin-cni 옵션을 활성화 해야한다. 보통 해당 설정은 Kubernetes 설정에서 자동으로 처리하게 되지만, 직접 설정을 수정하려면, kubelet을 실행할 때, 해당 옵션을 추가해야 한다.

kubelet –network-plugin-cni

네트워크 정책 설정

Calico나 Cilium을 사용하게 되면, Kubenetes 네트워크 정책을 지원하게 된다. 이때는 적절하게 네트워크 정책을 수정해 주면 된다.

CNI플러그인 적용 확인

Pod상태를 통한 확인: 아래 명령을 이용하여 네트워크 정보를 확인할 수 있다.

# kubectl get pods -o wide

CNI플러그인 로그 확인

아래 명령을 통해서, CNI플러그인의 로그를 직접 확인할 수도 있다.

# kubectl logs -n kube-system <flannel-pod-name>

외부 접근 설정

이제 생각해 볼 것은, 내부에 생성된 Deployment나 Pod를 외부로 어떻게 연결시킬 것인가 이다.

Cluster IP (외부 접속 불가)

Cluster IP 타입은 기본적으로 외부 접근이 불가능 하고, 클러스터 내부에서만 접근이 가능한 상태이다.

NodePort (특정 포트로 외부 접속 가능) – 권장

첫번째로 생각해 볼 수 있는 것은 NodePort 서비스를 생성하여 외부로 노출 시키는 방법이다. NodePort 서비스는, 외부에서 특정 포트를 통해 Pod에 접근할 수 있도록 하는 가장 간단한 방법이다.

다음과 같은 명령어로 간단하게 서비스를 생성할 수 있고, 이렇게 설정된 포트를 통해 외부에서, 해당 Pod 나 deployment에 직접 접속 할 수 있게 된다.

# kubectl expose deployment [대상 Deployment 이름] –type=NodePort –name=[생성될 서비스 이름] –port=[노출시킬 포트] –target-port=[Deployment의 대상 포트]

이렇게 노출된 Deployment에 Pod들(1개 이상의 Pod 복제 본이 존재할 경우)은 서비스의 동작 방식에 따라 적절하게 Load Balancing 되어 서비스된다.

LoadBalancing (외부 접근 가능)

클라우드 환경에서 외부 로드 밸런서를 자동으로 프로비저닝 하고, 이를 통해 외부에서 클러스터 내 서비스로 트래픽을 배분하는 방식이다. 별도로, Load Balancing 장비를 구축하여야 한다.

서비스를 위한 운영 환경이 아니라면, 굳이 LB를 사용해서 외부 아이피를 직접 받는 것 보다는, NodePort를 사용하여 외부에 맵핑된 Port로 서비스를 제공하는 것이 좀 더 효율적일 것이다.

LB 설정

Kubernetes시스템에는 기본적으로 LoadBalancing을 수행하는 기능이 없다. 따라서, 해당 기능을 수행하는 모듈을 설치해 주어야 한다.

여기서는 MetalLB를 사용하여 LB를 구축하려고 한다. MetalLB를 설치하기 위해서는 Helm명령을 설치해야 한다.

Helm 명령 설치

Keyring추가

# curl https://baltocdn.com/helm/signing.asc | gpg –dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
저장소 추가

# echo “deb [arch=$(dpkg –print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main” | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
Helm 명령 설치

# sudo apt update
# sudo apt install helm

LoadBalancing을 위한 MetalLB 설치

Helm 저장소를 추가한다.

# helm repo add metallb https://metallb.github.io/metallb
설정 파일을 생성한 후,

# vi Config.yaml

apiVersion: v1

kind: ConfigMap

metadata:

namespace: metallb-system

name: metallb-config

data:

config: |

address-pools:

– name: default

protocol: layer2

addresses:

– 10.245.0.1-10.245.255.255
해당 설정 파일을 이용하여 설치

# heml install metallb metallb/metallb -n metallb-system –create-namespace -f config.yaml

Kubernetes 관리 도구 (OS GUI – Lens)

Kubernetes 관리 도구를 이용하면 Kubernetes 의 상세 정보와 관리를 좀 더 편리하게 운영할 수 있다.

무료 오픈 소스 기반의 Lens는 Window나 Mac, Linux 등에 설치되어, 여러 클러스터를 동시에 관리하고, 실시간 로그 스트리밍, 리소스 모니터링, 대시보드 등을 제공하는 기능을 갖추고 있다. 다만, 멀티 클러스터 관리, 팀 협업 기능 등의 일부 고급 기능을 사용하려면 프리미엄 기능을 활용해야 하는 단점도 존재한다.

다운로드 및 설치

아래 링크로 이동하여 OS에 맞는 설치 파일을 다운로드 하여 설치를 진행한다.

https://docs.k8slens.dev/getting-started/install-lens/

설정 파일 추출

kubectl 실행 환경에서, 해당 노드로 접속할 수 있는 정보를 가진 파일을 아래 명령을 통해 생성한다.

# kubectl config view –minify –raw

출력되는 내용을 config파일로 저장 한다.

추출된 파일 Import

Lens 어플리케이션으로 돌아와, 설정 파일을 이용하여 Kubernetes Cluster 접속 정보를 생성한다.

Metric 정보 활성화

Lens에서는 Metric정보에 쉽게 접근하기 위한 도구를 제공해 준다.

추가된 Kubernetes Cluster에서 오른쪽 버튼으로 Settings 창으로 이동한 후, “Lens Metrics” 로 이동하여, Metrics 관련 스택들을 모두 활성화 한 후, Apply를 눌러준다. 위 과정을 통해 Lens는 관리 대성의 클러스터에 Metric 정보를 수집할 수 있는 Pod들을 자동으로 설치하고 데이터를 수집하여 보여준다.

Kebernetes 관리 도구 (CLI – k9s)

커맨드 라인에서 구현된 GUI를 통해 관리 기능을 제공하는 k9s는 WSL에 해당 파일을 설치한 후, 실행하면 자동으로 설정된 클러스터를 감지하여 관리 기능을 제공해 준다.

brew를 통해 설치를 권장하지만, 아래 저장소에서 배포되는 패키지 파일을 통해 설치도 가능하다. (brew로 설치하려면, brew 명령 설치하는 것이 k9s설치하는 것보다 어려움)

# dpkg -i [package_file.deb]

CGroup V2 설정

CGroup 은 Linux 커널 기능중의 하나로, 시스템의 프로세스나 태스크 그룹을 리소스 별로 제한하고 관리할 수 있는 기능이다. 이는 Container 기반의 시스템을 구축하는데 있어 핵심적인 기능이다.

Cgroup 은 V1과 V2로 두가지 버전이 존재하며 버전 별로 기능이 조금 다르다.

CGroup V1

CGroup V1은 여러 종류의 리소스(예: CPU, 메모리, I/O 등)를 각 리소스 별로 별도의 계층으로 관리한다.
각 리소스 종류가 독립적인 서브시스템(controller)으로 존재하며, 리소스 관리를 위한 인터페이스가 다르다.
분리된 controller를 사용하여 리소스를 관리하기 때문에 설정이 복잡할 수 있다.

CGroup V2

CGroup V2는 V1에서 개선된 버전으로, 단일 계층 모델을 제공한다. 즉, 모든 리소스를 하나의 계층에서 관리하게 된다.
모든 리소스가 하나의 control group 안에 들어가며, 이를 통해 리소스 관리와 설정이 더 직관적이고 통합적이다.
통합된 인터페이스를 제공하여 설정 및 관리를 더 간단하게 만들어 준다.
또한, 메모리 관리와 cpu 사용 제한 등에서 더 정교한 기능을 제공한다.
CGroup V2는 커널 4.5 이상부터 사용 가능하며, 리소스 관리에서 보다 높은 효율성과 안정성을 제공한다.

WSL 상에서의 확인 방법

Docker를 사용중이라면, Docker 명령을 통해 CGroup 버전을 확인할 수 있다.

# docker info | grep Cgroup

Kubernetes Cluster System 은 Docker의 Cgroup 버전을 그대로 상속 받아 사용하게 된다.

또한 최근에는 Kubernetes 시스템에서도 CGroup V1을 사용하고 있으면, 업데이트 하라는 경고 메시지를 출력하고 있으므로, 이를 통해 버전을 확인하는 것도 방법일 것이다.

CGroup V2 사용 설정

WSL – Config 설정

Config 설정 파일을 수정하여 CGroupV2를 활성화 할 수 있다. /etc/wsl.conf

[boot]
system=true

WSL 재시작

C:\> wsl –shutdown
C:\> wsl

설정 확인

# mount | grep cgroup2

cgroup2 내용이 확인되면 정상 설정된 것이다.

Docker 설정

/etc/docker/daemon.json을 열고, 다음과 같이 설정함

{
“exec-opts”: [“native.cgroupdriver=systemd”]
}

이후 서비스 재 시작

# sudo service docker restart

Kubectl 설정

/etc/system/system/kubelet.service.d/10-kubeadm.conf 파일을 열고, 다음 구문을 추가하거나 수정함

Environment=”KUBELET_CGROUP_DRIVER=systemd”

Kubernetes 재 시작

# sudo systemctl daemon-reload
# sudo systemctl restart kubelet

테스트

테스트 파드 생성

# kubectl run nginx-pod-01 –image=nginx –restart=Never
# kubectl run nginx-pod-02 –image=nginx –restart=Never

파드 상태 확인

# kubectl get pods

파드의 상세 상태 확인

# kubectl describe pod nginx-pod-01 / 02

테스트

내부 통신 테스트

파드에 접근

# kubectl exec -it nginx-pod-01 — /bin/bash

Ping을 통한 접근 확인 (Pod 내부)

# ping <nginx-pod-01 ip>

Pod 주소 확인 (외부)

# apt install iputils-ping
# kubectl get pod -o wide

파드 로그 확인

# kubectl logs nginx-pod-01 / 02

확인 후 삭제

# kubectl delete pod nginx-pod-01
# kubectl delete pod nginx-pod-02