[k8s] Deployment 배포와 파드 간 통신 테스트

이번 포스팅에서는 쿠버네티스 클러스터의 상태 점검부터 배포, 그리고 내부 네트워크 확인까지 알아본다.

 

1. 클러스터 초기 상태 및 구성 요소 점검

작업 전, 마스터 노드에서 클러스터가 정상적으로 통신하고 있는지, 제어부(Control Plane)의 주요 컴포넌트들이 건강한지 확인해야 한다.

# 클러스터 마스터 및 서비스(CoreDNS) 정보 확인
kubectl cluster-info

 

• Control Plane: 클러스터의 두뇌 역할을 하며, kubectl cluster-info를 통해 API 서버의 엔드포인트를 확인할 수 있다.

• Kubernetes control plane is running at...  :쿠버네티스의 핵심부인 컨트롤 플레인(특히 API 서버)이 192.168.57.100이라는 IP의 6443번 포트에서 돌아가고 있음.
• CoreDNS is running at... : 클러스터 내부에서 서비스들의 이름을 IP 주소로 번역해주는 CoreDNS가 정상 작동 중.

 

 

• 지휘본부(API Server)의 주소: https://192.168.57.100:6443은 클러스터의 모든 명령이 집결되는 입구다. 사용자가 kubectl을 통해 내리는 모든 명령은 가장 먼저 이 주소의 API 서버로 전달된다.
• 서비스 프록시(Proxy) 구조: 뒤에 붙은 긴 경로는 API 서버를 거쳐서 CoreDNS 서비스에 접근할 수 있는 프록시(Proxy) 경로 다. CoreDNS의 주소가 API 서버 주소 뒤에 길게 붙어 있는 이유는, 외부에서 CoreDNS에 직접 접근하는 것이 아니라 API 서버가 중간에서 연결을 대행(Proxy)해주고 있기 때문이다.
• CoreDNS의 역할: CoreDNS는 클러스터 내부의 "전화번호부" 역할을 하며, 파드들이 서로의 이름을 IP로 변환할 수 있게 해준다.

 

# 컨트롤 플레인 구성 요소(etcd, scheduler, controller-manager) 상태 확인
kubectl get componentstatus

• ComponentStatus: Healthy 상태가 아닐 경우 파드 스케줄링이나 상태 유지가 불가능하므로 가장 먼저 체크해야 할 항목이다.

 

 

2. YAML 정의를 통한 Deployment 배포

쿠버네티스는 사용자가 원하는 상태(Desired State)를 정의하면 시스템이 이를 유지하는 선언적 방식을 사용한다.

# 1. 실제 생성 없이 YAML 템플릿 파일만 추출
kubectl create deploy nginx --image=nginx:1.14 --dry-run=client -o yaml > nginx.yml

 

이 명령어는 '템플릿 굽기'라고도 불리는데, 단순히 명령을 실행하는 게 아니라 앞으로 관리할 인프라의 '설계도(YAML)'를 뽑아내는 과정이라고 할 수 있다.

🛠 명령어 구성 요소 

구성 요소	역할	설명
kubectl create deploy nginx	객체 정의	nginx라는 이름의 Deployment(배포 관리자)를 만들겠다는 선언.
--image=nginx:1.14	재료 지정	이 배포판 안에서 실행될 컨테이너의 이미지를 특정 버전(1.14)으로 지정.
--dry-run=client	가상 실행	실제로 클러스터(서버)에 명령을 보내지 않고, 내 컴퓨터(클라이언트) 선에서 실행 결과만 미리 계산해봄.
-o yaml	출력(output) 형식	결과를 단순히 "만들어짐"이라는 문구가 아니라, 상세한 YAML 문서 형식으로 보여달라는 뜻.
> nginx.yml	파일 저장	화면에 출력될 내용을 nginx.yml이라는 파일로 리다이렉션(저장)함.

 

☑️ Dry run 실행 후 yml 파일 저장 과정

 

 

# 2. 파일 생성 확인 및 내용 수정 (replicas: 3 등)
nano nginx.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3 
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14
        name: nginx
        resources: {}
status: {}


# 3. 설정 파일을 클러스터에 반영
kubectl apply -f nginx.yml

• Deployment: 파드(Pod)의 개수와 버전을 관리하는 객체다. YAML 파일에 replicas: 3을 명시하면, 클러스터는 어떤 상황에서도 해당 파드를 3개 유지하려고 시도한다.

 

3. 파드 배치 현황 및 네트워크 정보 확인

 

배포된 객체(파드)들이 어느 노드에서 어떤 IP를 할당받았는지 상세히 확인한다.

# Deployment 상태 확인
kubectl get deploy

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           110s


# 파드의 상세 정보 확인
kubectl get po -o wide

nginx-55c89cc9dc-8dm7r   1/1     Running   0             3m11s   10.244.1.11   k8s-worker-1   <none>           <none>
nginx-55c89cc9dc-hqvwl   1/1     Running   0             3m11s   10.244.2.11   k8s-worker-2   <none>           <none>
nginx-55c89cc9dc-sk678   1/1     Running   0             3m11s   10.244.1.12   k8s-worker-1   <none>           <none>

 

 

• kubectl get deploy : 결과에서 READY 3/3은 "사용자가 3개를 요청했고, 현재 3개가 정상 작동 중"이라는 요청와 결과의 일치 여부를 보여준다.
• kubectl get po -o wide : 각 파드의 고유 이름(nginx-55c89cc9dc-8dm7r 등)과 실제 할당된 IP(10.244.x.x), 그리고 어느 워커 노드에 배정되었는지 같은 물리적 현황을 보여준다. -o wide 옵션을 사용하면 파드가 배포된 워커 노드의 이름과 할당된 내부 IP를 확인할 수 있다.

쿠버네티스 스케줄러는 가용 리소스를 고려하여 파드를 여러 노드(k8s-worker-1, k8s-worker-2)에 골고루 배치한다.

위 명령의 출력 결과에서 IP 항목은 클러스터 내부에서 파드들이 서로를 식별하는 유일한 주소다.

 

🌀Deployment와 Pod의 관계

쿠버네티스에서 Deployment와 Pod은 독립적인 개체가 아니라 부모-자식과 같은 계층 구조를 가진다.

Deployment (관리자)

Deployment는 파드를 직접 실행하지 않는다. 대신 "어떤 이미지를 몇 개나 유지할 것인가"에 대한 전략을 정의한다. 파드가 죽으면 새로운 파드를 살려내고, 버전 업데이트가 필요하면 파드를 교체하는 명령을 내리는 주체다.

Pod (실행 주체)

파드는 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위다. 하나 이상의 컨테이너가 실행되는 공간이며, 실제로 트래픽을 처리하는 worker이다. 파드는 언제든 죽고 재생성될 수 있는 '일시적인(Ephemeral)' 존재다.

 

Deployment는 직접 파드를 관리하지 않고 중간에 ReplicaSet이라는 관리자를 두어 파드의 개수를 맞춘다.

 

kubectl get po를 했을 때 나타나는 파드의 이름은 부모의 이름을 물려받는다.

예: nginx-55c89cc9dc-8dm7r

1. nginx: Deployment의 이름.
2. 55c89cc9dc: ReplicaSet의 해시값 (버전을 의미).
3. 8dm7r: 각 파드를 식별하는 고유 난수.

이 구조 덕분에 파드가 삭제되어 다시 생성되어도, 이름의 앞부분을 보고 어떤 Deployment에 속한 worker인지 즉시 알 수 있다.

 

4. 쿠버네티스 네트워크와 3가지 IP 주소 체계

쿠버네티스 환경에는 통신 범위와 목적에 따라 세 가지 종류의 주소가 공존한다. 

IP 유형	주소 대역 예시	용도
노드 주소	192.168.56.x	물리적/가상 노드 간 통신 시 사용
외부 파드 주소	10.244.x.x	타 노드의 파드에서 해당 파드로 접근할 때 사용하는 주소
내부 파드 주소	172.18.x.x	동일 노드 내 파드끼리 통신할 때 사용되는 내부 주소

 

외부에서 파드에 접근하려면 고정 IP를 가진 Service(ClusterIP) 객체를 생성해야 한다.

Service는 내부적으로 연결된 파드들에게 로드 밸런싱(Round Robin) 방식으로 트래픽을 배분한다.

서비스와 로드 밸런싱에 대한 내용은 이전 포스팅에 자세히 정리해 두었다. 

 

5. 파드 간 통신 테스트

쿠버네티스 네트워크의 핵심 원칙 중 하나는 "모든 파드는 서로 NAT(Network Address Translation, 네트워크 주소 변환) 없이 직접 통신이 가능하다"는 것이다.

이를 확인하기 위해 별도의 테스트용 파드를 실행하고 다른 파드에 접속해본다.

# 1. 테스트용 파드(bash01) 실행 및 진입
kubectl run -it bash01 --image=alicek106/ubuntu:curl

# 2. bash01 내부에서 다른 노드에 있는 nginx 파드로 접속 시도
# (bash01은 worker-2에, 대상 nginx는 worker-1에 있는 상황)
curl 10.244.1.11
curl 10.244.2.11