1. 쿠버네티스는 어떻게 컨테이너를 실행하고 관리하는가?
컨테이너는 일반적으로 하나의 가상화된 환경을 가리킨다. 또한 다양한 런타임을 가질 수 있다. 쿠버네티스에서는 런타임에 관계없이 인터페이스를 통해 컨테이너를 관리하며, 컨테이너 자체를 또 다른 가상 환경인 파드로 감싸서 관리한다. 파드란 컴퓨팅의 단위로, 클러스터를 이루는 노드 중 하나에서 실행된다. 파드는 대게 하나의 컨테이너를 포함하지만, 설정에 따라 하나의 파드가 여러개의 컨테이너를 포함할 수도 있다. 노드와 팟, 컨테이너의 관계는 아래 그림과 같다.

kubectl run hello-kiamol --image=kiamol/ch02-hello-kiamol
kubectl get pods
kubectl describe pod hello-kiamol
위 Run 명령을 사용하게 되면, 클러스터에 Pod 리소스가 생성되고 그 안에서 컨테이너가 실행된다. 단순히 로컬에 컨테이너만 띄우는 게 아니라, Kubernetes API 서버에 Pod 생성 요청을 보내어 실제로 스케줄링되는 Pod가 만들어지는 것이다. 파드를 생성할 때, 한 노드에 배정되는데 이때 컨테이너를 실행하는 책임 또한 노드에 맡겨진다. 노드마다 런타임이 다를 수 있지만, CRI(Container Runtime Interface)라는 공통 API를 사용하여 컨테이너 런타임과 연동된다.
1-1. 컨테이너 복원
컨테이너는 파드로 한번 더 감싸서 실행되고 있다. 이때 컨테이너가 사라지면 파드는 사라진 파드에 대해서 새로운 컨테이너를 추가하여 파드 상태를 복원한다. 이는 뒤에 다룰 디플로이먼트도 마찬가지이다.
1-2. 네트워크 트래픽 포워딩
kubectl에는 네트워크 트래픽을 노드에서 파드로 전달할 수 있는 기능이 있다.
# 로컬 컴퓨터의 8080포트로 들어오는 트래픽을 80번 포트로 전달한다.
kubectl port-forward pod/hello-kimaol 8080:80
이렇게 하면 localhost:8080으로 접속하면, 해당 팟의 80번 포트에서 실행되는 웹 애플리케이션을 볼 수 있다.
2. 컨트롤러 객체와 함께 파드 실행하기
컨트롤러 객체는 다른 객체를 다시 추상화한 것이다. 파드는 직접 사용하기에는 너무 단순한 객체다. 파드는 고립된 한 벌의 애플리케이션이며, 각 파드는 서로 다른 노드에 배정된다. 어떤 노드가 고장을 일으킨다면 유실되고, 쿠버네티스는 유실된 파드를 새 파드로 대체하지 않는다. 여러 파드를 실행하며, 고가용성을 확보하려고 해도 모든 파드가 다른 노드에 흩어져서 실행된다는 보장이 없다. 억지로 서로 다른 노드에 실행되도록 사람이 직접 관리해야 한다면 오케스트레이션 도구를 사용하는 의미가 없다. 컨트롤러 객체가 바로 이런 불편함을 해결해준다. 컨트롤러 객체는 다른 리소스를 관리하는 쿠버네티스 리소스이다. 그 중 파드를 관리하는 객체는 디플로이먼트이고, 여러 노드에 걸쳐 필요한 수만큼 파드를 실행해준다.

파드는 하나에 노드에서 실행될 수 있기 때문에, 위의 경우 복제본을 두어 서로 다른 노드에서 실행가능하지만, 아래의 경우 하나의 노드에서 실행된다. 이를 디프롤이먼트가 관리하는 것이다. 쿠버네티스가 디플로이먼트를 생성하면, 디플로이먼트가 파드를 생성한다.

디플로이먼트를 생성하여 디플로이먼트가 팟을 생성하고 있는 모습이다.
2-1. Label을 통한 Pod 관리
디플로이먼트는 그러면 어떻게 생성한 pod을 관리할까? 그 방법은 라벨에 있다. 디플로이먼트는 '~~' 라벨을 가진 팟을 관리하겠다는 정보를 가지고 있고, 해당 디플로이먼트가 생성한 pod들에는 해당 라벨이 부착돼어있다. 따라서 해당하는 라벨을 가진 팟이 사라지면 디플로이먼트는 해당하는 라벨을 가진 팟을 재생성한다. 이걸 desired state를 보장해준다고 한다.
2-2. 네트워크 트래픽 포워딩
pod과 마찬가지로 kubectl의 port-forward 명령을 통해 네트워크 트래픽을 파드로 전달할 수 있다. 디플로이먼트에 연결된 파드가 많다면, 디플로이먼트가 자신이 가진 파드 중 하나를 트래픽 전달 대상으로 삼는다.
kubectl port-forward deploy/hello-kiamol-2 8080:80
3. 애플리케이션 매니페스트에 배포 정의하기
애플리케이션 매니페스트란 yaml 파일을 작성하여 리소스의 스펙을 작성하는 것이다. 매니페스트를 작성하게 되면 주석을 달 수 있다는 점과, 선언적 스크립트를 통해 최종적 결과를 전달할 수 있다는 점이 장점으로 다가온다.
간단한 pod을 만드는 매니페스트 파일이다.
apiVersion: v1
kind: Pod
metadata:
name: hello-kiamol-3
spec:
containers:
- name: web
image: kiamol/ch02-hello-kiamol
앞서 명령형으로 pod과 deployment를 만들 때는, run 명령어를 사용했지만, yaml 파일을 사용할 때는 apply 명령어를 사용해준다.
kubectl apply -f pod.yaml
kubectl get pods
3-1. 공개된 url을 통한 kubectl 배포
매니페스트 파일을 로컬 컴퓨터에 따로 복사하지 않아도 kubectl로 배포가 가능하다. 공개된 url만 있으면 된다. 깃허브에서 배포되는 같은 내용의 매니페스트 파일로 파드를 배포할 수 있다.
kubectl apply -f https://raw.githubusercontent.com/sixeyed/kiamol/master/ch02/pod.yaml
4. 쿠버네티스 리소스 삭제하기
kubectl get pods
kubectl delete pods --all
지금 명령어를 보면 pod들을 삭제했다. 그러면 과연 deployment를 통해서 생성된 pod들은 어떻게 될까? 우선 삭제되는 것이 맞다. 그러나 deployment 의 매니페스트 파일에서 정의해놓은 desired state가 있기 때문에 해당 desired state에 맞게 팟이 새롭게 생성될 것이다. 따라서 deployment에서 관리하는 pod을 삭제하려면 해당 deployment를 삭제해주어야 한다.
kubectl get pods
kubeetl delete deploy --all
'Infra' 카테고리의 다른 글
| ArgoCD UI Permission Error 해결 (3) | 2025.08.24 |
|---|---|
| EKS 클러스터 및 노드 그룹 생성, Kubectl 설치 및 연결 (0) | 2025.06.24 |
| 모니터링 환경 설정 - 배포 포트가 변경될 때 8080...8081,, switching (0) | 2025.05.26 |
| 모니터링 환경을 구축 Promtail, Loki, Prometheus, Grafana, Logback (0) | 2025.05.26 |
| Terraform으로 NCP 구축하기(4) - Object Storage 구성하기 (0) | 2025.05.08 |