[클라우드 프로그래밍] 9주차

1차시 — 파드와 디플로이먼트로 컨테이너 실행하기

쿠버네티스는 어떻게 컨테이너를 실행하고 관리하는가

컨테이너는 단독으로 동작하지 않고 **파드(Pod)**에 포함되어 동작한다. 우리는 파드를 통해 컨테이너를 관리한다.

간단한 파드라면 YAML 파일을 따로 정의하지 않고도 명령행에서 바로 실행할 수 있다.

# 컨테이너 하나를 담은 파드를 실행한다
kubectl run hello-kiamol --image=kiamol/ch02-hello-kiamol

# 파드가 준비 상태가 될 때까지 기다린다
kubectl wait --for=condition=Ready pod hello-kiamol

# 클러스터에 있는 모든 파드의 목록을 출력한다
kubectl get pods

# 파드의 상세 정보를 확인한다
kubectl describe pod hello-kiamol

파드 정보를 다양하게 출력하기

# 파드에 대한 기본적인 정보를 확인한다
kubectl get pod hello-kiamol

# 네트워크 상세 정보 중 특정 항목만 따로 출력한다
kubectl get pod hello-kiamol --output custom-columns=NAME:metadata.name,NODE_IP:status.hostIP,POD_IP:status.podIP

# JSONPath로 복잡한 출력을 구성한다 (첫 번째 컨테이너의 식별자만 출력)
kubectl get pod hello-kiamol -o jsonpath='{.status.containerStatuses[0].containerID}'

💡 모든 쿠버네티스 환경은 컨테이너 관리를 위해 동일한 **CRI(Container Runtime Interface)**를 사용한다. 그래서 도커 명령으로도 파드 안의 컨테이너를 직접 찾고 다룰 수 있다.

# 파드에 포함된 컨테이너 찾기
docker container ls -q --filter label=io.kubernetes.container.name=hello-kiamol

# 해당 컨테이너 삭제하기
docker container rm -f $(docker container ls -q --filter label=io.kubernetes.container.name=hello-kiamol)

# 파드 상태 확인 (쿠버네티스가 필요한 컨테이너 개수를 다시 유지시킨다)
kubectl get pod hello-kiamol

로컬에서 파드로 트래픽 전달하기

# 로컬 컴퓨터의 8080번 포트로 들어오는 트래픽을 파드의 80번 포트로 전달한다
kubectl port-forward pod/hello-kiamol 8080:80

# 웹 브라우저에서 http://localhost:8080 접근
# 확인이 끝나면 ctrl-c로 포트포워딩 중단

컨트롤러 객체와 함께 파드 실행하기

파드 하나만 직접 실행하면 노드 장애나 삭제 시 복구가 안 되는 불편함이 있다. 이를 해결하는 것이 컨트롤러(controller) 객체다.

컨트롤러는 다른 리소스를 관리하는 쿠버네티스 리소스다. 쿠버네티스 API와 연동하며 시스템의 현재 상태를 감시하다가 '바람직한 상태'와 차이가 생기면 필요에 따라 그 차이를 바로잡는다.

파드를 주로 관리하는 컨트롤러 객체가 **디플로이먼트(Deployment)**다.

# 웹 애플리케이션을 실행하는 디플로이먼트 'hello-kiamol-2'를 생성
kubectl create deployment hello-kiamol-2 --image=kiamol/ch02-hello-kiamol

# 파드의 목록을 출력
kubectl get pods

디플로이먼트는 자신이 관리하는 파드에 **레이블(label)**을 부여한다.

# 디플로이먼트가 부여한 파드의 레이블 출력
kubectl get deploy hello-kiamol-2 -o jsonpath='{.spec.template.metadata.labels}'

# 앞서 출력한 레이블을 가진 파드의 목록 출력
kubectl get pods -l app=hello-kiamol-2

컨트롤러 객체는 **레이블 셀렉터(label selector)**를 통해 자신이 관리하는 리소스를 식별한다. 디플로이먼트는 파드와 직접적인 관계가 아니라, 레이블을 매개로 간접적으로 연결된다.

# 모든 파드 이름과 레이블 확인
kubectl get pods -o custom-columns=NAME:metadata.name,LABELS:metadata.labels

# 디플로이먼트가 생성한 파드의 'app' 레이블을 수정
kubectl label pods -l app=hello-kiamol-2 --overwrite app=hello-kiamol-x

# 파드가 또 하나 생성된다 (레이블이 바뀌어 디플로이먼트 관리에서 벗어났기 때문)
kubectl get pods -o custom-columns=NAME:metadata.name,LABELS:metadata.labels

⚠️ 파드의 레이블을 함부로 수정하면 그 파드는 디플로이먼트의 관리 대상에서 벗어난다. 디플로이먼트는 레이블 셀렉터와 일치하는 파드 수를 유지하려 하므로, 레이블이 바뀐 파드 대신 새 파드를 또 만들어 낸다.

# 'app' 레이블이 부여된 모든 파드의 이름과 레이블 출력
kubectl get pods -l app -o custom-columns=NAME:metadata.name,LABELS:metadata.labels

# 디플로이먼트의 관리를 벗어난 파드의 'app' 레이블을 원래대로 수정
kubectl label pods -l app=hello-kiamol-x --overwrite app=hello-kiamol-2

# 디플로이먼트로 포트포워딩 설정
kubectl port-forward deploy/hello-kiamol-2 8080:80

📝 학습정리 (1차시)

컨트롤러 객체와 함께 파드 실행 컨트롤러 객체는 다른 리소스를 관리하는 쿠버네티스 리소스다. 컨트롤러는 쿠버네티스 API와 연동하며 시스템의 현재 상태를 감시하다가 '바람직한 상태'와 차이가 생기면 필요에 따라 그 차이를 바로잡는다. 쿠버네티스에는 여러 가지 컨트롤러 객체가 있고, 그중 파드를 주로 관리하는 컨트롤러 객체가 디플로이먼트다. 어떤 노드가 고장을 일으켜 파드가 유실되면 디플로이먼트가 대체 파드를 다른 노드에 실행한다. 디플로이먼트를 스케일링하고 싶다면 필요한 파드 수를 지정하면 되고, 디플로이먼트가 여러 노드에 걸쳐 필요한 수만큼 파드를 실행한다.

---

2차시 — 파드와 디플로이먼트로 컨테이너 실행하기 (매니페스트와 리소스 관리)

애플리케이션 매니페스트에 배포 정의하기

매니페스트는 JSON 또는 YAML 포맷으로 작성할 수 있다. 쿠버네티스 API의 정식 스크립트 포맷은 JSON이지만, 실제로 매니페스트를 작성할 때는 가독성이 더 뛰어나고 파일 하나에 더 많은 리소스를 정의할 수 있는 YAML을 많이 쓴다.

pod.yaml — 컨테이너 하나를 실행하는 단일 파드

# 매니페스트는 쿠버네티스 API의 버전과 정의하려는 리소스의 유형을 밝히며 시작한다
apiVersion: v1
kind: Pod
# 리소스의 메타데이터에는 이름(필수)과 레이블(비필수)이 있다
metadata:
  name: hello-kiamol-3
# 스펙은 리소스의 실제 정의 내용이다
# 파드의 경우 실행할 컨테이너를 정의해야 한다
spec:
  containers:
  - name: web
    image: kiamol/ch02-hello-kiamol

# 매니페스트 파일로 애플리케이션 배포
kubectl apply -f pod.yaml

# 실행 중인 파드 목록 확인
kubectl get pods

로컬 파일이 없어도 원격 URL로 바로 배포할 수 있다.

kubectl apply -f https://raw.githubusercontent.com/sixeyed/kiamol/master/ch02/pod.yaml

deployment.yaml — 디플로이먼트와 파드의 정의

# 디플로이먼트는 apps/v1에 속한다
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kiamol-4
spec:
  # 디플로이먼트가 자신의 관리 대상을 결정하는 레이블 셀렉터
  selector:
    matchLabels:
      app: hello-kiamol-4
  # 이 템플릿은 디플로이먼트가 파드를 만들 때 쓰인다
  template:
    # 파드의 정의에는 이름이 없다. 그 대신 레이블 셀렉터와 일치하는 레이블을 지정해야 한다
    metadata:
      labels:
        app: hello-kiamol-4
    spec:
      containers:
      - name: web
        image: kiamol/ch02-hello-kiamol

# 디플로이먼트의 매니페스트로 애플리케이션 실행
kubectl apply -f deployment.yaml

# 새로운 디플로이먼트가 만든 파드 찾기
kubectl get pods -l app=hello-kiamol-4

쿠버네티스의 리소스 관리 이해하기

kubectl로 리소스를 쉽게 삭제할 수 있지만, 삭제한 리소스가 되살아나는 경우가 있다. 컨트롤러 객체가 만든 리소스의 삭제는 해당 컨트롤러 객체의 책임이다. 컨트롤러는 자신이 관리하는 리소스의 생애 주기를 관장하며 외부 간섭을 용인하지 않는다. 우리가 컨트롤러가 관리하는 리소스를 직접 삭제하면, 이를 대체하는 새 리소스가 곧바로 생성된다.

# 실행 중인 모든 파드의 목록 출력
kubectl get pods

# 모든 파드 삭제 (디플로이먼트가 있다면 새로 재생성됨!)
kubectl delete pods --all

# 모든 파드가 삭제(혹은 재생성)되었는지 확인
kubectl get pods

파드 대신 컨트롤러 객체 자체를 삭제하면, 관리하던 리소스도 함께 삭제된다.

# 디플로이먼트 목록 확인
kubectl get deploy

# 디플로이먼트 모두 삭제
kubectl delete deploy --all

# 파드 목록 확인 (디플로이먼트가 없으니 파드도 없음)
kubectl get pods

# 모든 리소스 목록 확인
kubectl get all

📝 학습정리 (2차시)

애플리케이션 매니페스트에 배포 정의하기 매니페스트는 JSON 또는 YAML 포맷으로 작성할 수 있다. 쿠버네티스 API의 정식 스크립트 포맷은 JSON이지만, 매니페스트를 작성할 때는 가독성이 더 뛰어나고 파일 하나에 더 많은 리소스를 정의할 수 있는 YAML을 많이 쓴다.

쿠버네티스의 리소스 관리 이해하기 kubectl을 사용하면 쿠버네티스 리소스를 쉽게 삭제할 수 있지만 삭제한 리소스가 되살아나는 경우가 있다. 컨트롤러 객체가 만든 리소스의 삭제는 해당 컨트롤러 객체의 책임이다. 컨트롤러 객체는 자신이 관리하는 리소스의 생애 주기를 관장하며 이에 대한 외부 간섭을 용인하지 않는다. 컨트롤러 객체가 관리하는 리소스를 우리가 직접 삭제하면 이를 대체하는 새로운 리소스가 생성된다.

---

3차시 — 네트워크를 통해 서비스에 파드 연결

쿠버네티스 내부의 네트워크 트래픽 라우팅

파드란? 파드는 쿠버네티스에서 애플리케이션을 구성하는 기본 요소다. 대부분의 애플리케이션은 여러 구성 요소로 나뉘는데, 쿠버네티스에서는 이들 구성 요소를 각각 파드의 형태로 모델링한다. 예를 들어 웹 사이트라면 웹 사이트 파드와 API 파드 단 두 개로 구성되거나, 마이크로서비스 아키텍처를 채택해 파드 수십 개로 나뉘어 구성될 수 있다.

모든 파드는 서로 통신할 수 있어야 한다. 파드끼리 통신을 위해 쿠버네티스는 표준 네트워크 프로토콜인 TCP와 UDP를 지원한다. 다만 TCP/UDP는 IP 주소로 트래픽을 제어하는데, 파드가 대체되면 IP 주소가 바뀐다는 문제가 있다. 쿠버네티스는 **서비스(Service)**에 어드레스 디스커버리(address discovery) 기능을 제공하여 이 문제를 해결했다.

서비스는 파드에서 들고나는 통신 트래픽의 라우팅을 맡는 유연한 리소스다. 클러스터 외부에서 파드로 전달되는 트래픽과, 파드에서 클러스터 외부로 전달되는 트래픽 모두를 포함한다.

cd ch03
# 각각 파드 하나를 실행하는 두 개의 디플로이먼트를 생성한다
kubectl apply -f sleep/sleep1.yaml -f sleep/sleep2.yaml

# 파드가 완전히 시작될 때까지 기다린다
kubectl wait --for=condition=Ready pod -l app=sleep-2

# 두 번째 파드의 IP 주소를 확인한다
kubectl get pod -l app=sleep-2 --output jsonpath='{.items[0].status.podIP}'

# 같은 주소로 두 번째 파드에서 첫 번째 파드로 ping을 보낸다
kubectl exec deploy/sleep-1 -- ping -c 2 $(kubectl get pod -l app=sleep-2 --output jsonpath='{.items[0].status.podIP}')

# 파드의 현재 IP 주소를 확인한다
kubectl get pod -l app=sleep-2 --output jsonpath='{.items[0].status.podIP}'

# 디플로이먼트가 새 파드를 만들도록 현재 파드를 삭제한다
kubectl delete pods -l app=sleep-2

# 새로 대체된 파드의 IP 주소를 확인한다 (IP가 바뀌어 있다!)
kubectl get pod -l app=sleep-2 --output jsonpath='{.items[0].status.podIP}'

이 문제 때문에 서비스를 경유해서 통신해야 한다. 서비스를 통하면 파드끼리 고정된 도메인 네임으로 통신할 수 있다.

sleep2-service.yaml — 간단한 서비스 정의

apiVersion: v1 # 서비스는 코어 v1 API를 사용한다
kind: Service
metadata:
  name: sleep-2 # 서비스 이름이 도메인 네임으로 사용된다
spec:
  # 서비스 정의에는 셀렉터와 포트의 목록이 포함되어야 한다
  selector:
    app: sleep-2 # app 레이블의 값이 sleep-2인 모든 파드가 대상이다
  ports:
  - port: 80 # 80번 포트를 주시하다가 파드의 80번 포트로 트래픽을 전달한다

# YAML 파일의 정의를 사용하여 서비스를 배포한다
kubectl apply -f sleep/sleep2-service.yaml

# 서비스의 상세 정보를 출력한다 (고정 IP 주소에 대한 도메인 네임이 내부 DNS에 등록됨)
kubectl get svc sleep-2

# 파드와 통신이 잘되는지 확인 — 이 명령은 실패한다 (ping은 ICMP라 서비스가 라우팅하지 않음)
kubectl exec deploy/sleep-1 -- ping -c 1 sleep-2

파드와 파드 간 통신

서비스의 유형 중 가장 기본이 되는 것이 **클러스터IP(ClusterIP)**다.

클러스터IP는 클러스터 전체에서 통용되는 IP 주소를 생성하며, 파드가 어느 노드에 있더라도 접근이 가능하다. 다만 이 IP 주소는 클러스터 내에서만 유효하다. 클러스터IP는 파드와 파드 간 통신에서만 쓰인다. 내부에서는 접근이 가능하되 외부의 접근은 차단해야 하는 분산 시스템 컴포넌트에 딱 적합하다.

# 웹 사이트와 API를 담당할 두 개의 디플로이먼트를 실행한다
kubectl apply -f numbers/api.yaml -f numbers/web.yaml

# 파드의 준비가 끝날 때까지 기다린다
kubectl wait --for=condition=Ready pod -l app=numbers-web

# 웹 애플리케이션에 포트포워딩을 적용한다
kubectl port-forward deploy/numbers-web 8080:80
# http://localhost:8080 에서 Go 버튼을 클릭하면 오류 발생 (API 서비스가 없어서)

api-service.yaml — 무작위 숫자 생성 API에 사용할 서비스 정의

apiVersion: v1
kind: Service
metadata:
  name: numbers-api
spec:
  ports:
  - port: 80
  selector:
    app: numbers-api
  type: ClusterIP

서비스를 적용하면, API 파드는 디플로이먼트가 관리하므로 파드를 수동으로 지워도 서비스가 대체 파드를 계속 찾아간다.

# API 파드의 이름과 IP 주소를 확인한다
kubectl get pod -l app=numbers-api -o custom-columns=NAME:metadata.name,POD_IP:status.podIP

# API 파드를 수동으로 삭제한다
kubectl delete pod -l app=numbers-api

# 새로 생성된 대체 파드의 이름과 IP 주소를 확인한다 (IP는 바뀌었지만 서비스는 여전히 잘 작동)
kubectl get pod -l app=numbers-api -o custom-columns=NAME:metadata.name,POD_IP:status.podIP

서비스는 웹 애플리케이션 파드와 API 파드의 결합을 분리(decouple)하므로, API 파드가 대체되어도 서비스를 통해 문제없이 통신할 수 있다.

외부 트래픽을 파드로 전달

쿠버네티스에는 클러스터 외부에서 들어오는 트래픽을 파드에 전달하는 여러 방법이 있다. 로드밸런서는 트래픽을 받은 노드가 아닌 노드에서 실행되는 파드에도 트래픽을 전달할 수 있다.

web-service.yaml — 외부 트래픽을 전달하는 로드밸런서 서비스

apiVersion: v1
kind: Service
metadata:
  name: numbers-web
spec:
  ports:
  - port: 8080       # 서비스가 주시하는 포트
    targetPort: 80    # 트래픽이 전달될 파드의 포트
  selector:
    app: numbers-web
  type: LoadBalancer  # 외부 트래픽도 전달할 수 있는 서비스

# 로드밸런서 서비스를 배치한다 (방화벽 접근 허용 여부를 물으면 허용)
kubectl apply -f numbers/web-service.yaml

# 서비스의 상세 정보를 확인한다
kubectl get svc numbers-web

# 애플리케이션의 URL을 EXTERNAL-IP 필드로 출력한다
kubectl get svc numbers-web -o jsonpath='http://{.status.loadBalancer.ingress[0].*}:8080'

⚠️ 쿠버네티스 플랫폼의 종류(클라우드/온프레미스 등)에 따라 로드밸런서 서비스의 외부 IP 주소 부여 방식이 달라질 수 있다.

노드포트(NodePort) 서비스도 외부 트래픽을 파드로 전달하는 또 다른 방법이다.

web-service-nodePort.yaml

apiVersion: v1
kind: Service
metadata:
  name: numbers-web-node
spec:
  ports:
  - port: 8080        # 다른 파드가 서비스에 접근하기 위해 사용하는 포트
    targetPort: 80     # 대상 파드에 트래픽을 전달하는 포트
    nodePort: 30080     # 서비스가 외부에 공개되는 포트
  selector:
    app: numbers-web
  type: NodePort        # 노드의 IP 주소를 통해 접근 가능한 서비스

쿠버네티스 클러스터 외부로 트래픽 전달

쿠버네티스는 거의 모든 서버용 소프트웨어를 실행할 수 있지만, 모든 소프트웨어를 꼭 쿠버네티스에서 실행해야 하는 것은 아니다. 데이터베이스 같은 스토리지 컴포넌트가 대표적으로 쿠버네티스 외부에서 동작하는 예다 (특히 클라우드의 매니지드 데이터베이스 서비스). 애플리케이션 아키텍처와 무관하게, 클러스터 외부를 가리키는 도메인 네임 해소에도 서비스 리소스를 활용할 수 있다.

api-service-externalName.yaml — 익스터널네임 서비스의 정의

apiVersion: v1
kind: Service
metadata:
  name: numbers-api  # 클러스터 안에서 쓰이는 로컬 도메인 네임
spec:
  type: ExternalName
  externalName: raw.githubusercontent.com  # 로컬 도메인 네임을 해소할 외부 도메인

# 현재 배포된 클러스터IP 서비스를 삭제한다
kubectl delete svc numbers-api

# 익스터널네임 서비스를 새로 배포한다
kubectl apply -f numbers-services/api-service-externalName.yaml

# 서비스의 상세 정보를 확인한다
kubectl get svc numbers-api

# nslookup 명령으로 서비스의 도메인 네임을 조회한다
kubectl exec deploy/sleep-1 -- sh -c 'nslookup numbers-api | tail -n 5'

서비스는 셀렉터가 없으면 헤드리스(headless) 서비스가 되고, 별도의 Endpoints 리소스로 정적 IP를 직접 지정할 수도 있다.

api-service-headless.yaml — 명시적 주소를 담은 서비스

apiVersion: v1
kind: Service
metadata:
  name: numbers-api
spec:
  type: ClusterIP   # selector 필드가 없으므로 헤드리스 서비스가 됨
  ports:
  - port: 80
---
kind: Endpoints       # 한 파일에 두 번째 리소스의 정의
apiVersion: v1
metadata:
  name: numbers-api
subsets:
- addresses:           # 정적 IP 주소 목록
  - ip: 192.168.123.234
  ports:
  - port: 80           # 각 IP 주소에서 주시할 포트

⚠️ 서비스의 설정을 잘못하면 애플리케이션에 이상이 발생할 수 있다. (예: 헤드리스 서비스에 셀렉터를 빼먹고 엔드포인트를 잘못 지정하면 새로운 요청에서 오류 발생)

쿠버네티스 서비스의 해소 과정

쿠버네티스는 서비스 리소스를 사용할 때 필요한 대부분의 네트워크 설정을 자동으로 제공한다. 파드에서 동작하며 다른 파드와 통신하는 애플리케이션 컴포넌트도 표준 전송 프로토콜과 DNS 네임을 사용해 서로를 찾는다. 특별한 코드나 라이브러리는 필요 없으며, 애플리케이션을 물리 서버나 가상 서버에 배포했을 때와 동작 방식이 다르지 않다.

# sleep-2 서비스의 엔드포인트 목록 출력
kubectl get endpoints sleep-2

# 파드 삭제
kubectl delete pods -l app=sleep-2

# 엔드포인트가 새로운 파드의 주소로 업데이트되었는지 확인
kubectl get endpoints sleep-2

# 디플로이먼트 채로 삭제
kubectl delete deploy sleep-2

# 엔드포인트는 여전히 있지만, 가리키는 IP 주소가 없음
kubectl get endpoints sleep-2

서비스가 가리키는 엔드포인트 주소의 목록은 파드의 생애 주기에 따라 지속적으로 변화한다.

**네임스페이스(Namespace)**는 쿠버네티스 클러스터를 논리적 파티션으로 분할하는 역할을 한다.

# default 네임스페이스의 서비스 리소스 목록 확인
kubectl get svc --namespace default

# 쿠버네티스 시스템 네임스페이스의 서비스 리소스 목록 확인
kubectl get svc -n kube-system

# 완전한 도메인 네임으로 DNS 조회하기
kubectl exec deploy/sleep-1 -- sh -c 'nslookup numbers-api.default.svc.cluster.local | grep "^[^*]"'

# 쿠버네티스 시스템 네임스페이스의 완전한 도메인 네임으로 DNS 조회하기
kubectl exec deploy/sleep-1 -- sh -c 'nslookup kube-dns.kube-system.svc.cluster.local | grep "^[^*]"'

다른 네임스페이스에 속하는 리소스도 kubectl 명령을 똑같이 사용해서 다룰 수 있다. (--namespace 또는 -n 플래그로 대상 지정)

# 모든 디플로이먼트 삭제
kubectl delete deploy --all

# 모든 서비스 삭제
kubectl delete svc --all

# 남아 있는 리소스 확인
kubectl get all

⚠️ all 파라미터로 한꺼번에 모든 리소스를 지정해 삭제할 수 있지만, 의도하지 않은 리소스까지 삭제될 수 있으므로 주의해야 한다.

📝 학습정리 (3차시)

쿠버네티스 내부의 네트워크 트래픽 라우팅 — 파드란? 파드는 쿠버네티스에서 애플리케이션을 구성하는 기본 요소다. 대부분의 애플리케이션은 여러 구성 요소로 나뉘는데, 쿠버네티스에서는 이들 구성 요소를 각각 파드의 형태로 모델링한다. 모든 파드는 서로 통신할 수 있어야 한다. 파드끼리 통신을 위해 쿠버네티스는 표준 네트워크 프로토콜인 TCP와 UDP를 지원한다. TCP와 UDP는 모두 IP 주소로 트래픽을 제어하는데, IP 주소는 파드를 대체할 때 주소가 변경된다는 문제가 있다. 서비스는 파드에서 들고나는 통신 트래픽의 라우팅을 맡는 유연한 리소스다.

쿠버네티스 파드 통신 — 클러스터 통신 서비스의 유형 중 가장 기본이 되는 것을 클러스터IP(ClusterIP)라고 한다. 클러스터IP는 클러스터 전체에서 통용되는 IP 주소를 생성하는데, 이 IP 주소는 파드가 어느 노드에 있더라도 접근이 가능하다. IP 주소는 클러스터 내에서만 유효하다. 클러스터IP는 파드와 파드 간 통신에서만 쓰인다. 내부에서는 접근이 가능하되 외부의 접근은 차단해야 하는 분산 시스템의 컴포넌트에 딱 적합하다.

---

🔑 9주차 핵심 키워드 정리

키워드 한 줄 정리

파드(Pod)	쿠버네티스 애플리케이션의 기본 구성 요소, 컨테이너를 감싸는 단위
디플로이먼트(Deployment)	파드를 관리하는 컨트롤러 객체, 자가 치유와 스케일링 담당
레이블 셀렉터	컨트롤러가 관리 대상 리소스를 식별하는 방식
매니페스트	JSON/YAML로 작성하는 리소스 정의 스크립트 (실무에서는 주로 YAML 사용)
서비스(Service)	파드 IP가 바뀌어도 고정 주소로 통신하게 해주는 어드레스 디스커버리 리소스
ClusterIP	클러스터 내부 통신 전용 고정 가상 IP
LoadBalancer	외부 트래픽을 파드로 전달, 다른 노드의 파드에도 라우팅 가능
NodePort	노드의 특정 포트를 통해 외부에서 접근 가능
ExternalName	클러스터 내부 이름을 외부 도메인으로 해소(resolve)
헤드리스 서비스	셀렉터 없이 Endpoints를 직접 지정하는 서비스
네임스페이스	클러스터를 논리적으로 분할하는 파티션