시작하며

쿠버네티스를 잘 사용하는 핵심은 YAML 파일을 잘 작성하는 것이다. 쿠버네티스는 대부분의 리소스를 오브젝트 형태로 관리하며, 아래 명령어로 사용 가능한 리소스 종류를 확인할 수 있다.

kubectl api-resources

쿠버네티스 클러스터는 크게 마스터 노드와 워커 노드로 구성된다.

  • 마스터 노드: 클러스터를 관리하는 역할. API 서버(kube-apiserver), 컨트롤러 매니저(kube-controller-manager), 스케줄러(kube-scheduler), DNS 서버(coreDNS)로 구성된다.
  • 워커 노드: 애플리케이션 컨테이너가 생성되는 노드. 모든 노드에는 오버레이 네트워크 구성을 위한 프락시(kube-proxy)와 네트워크 플러그인(calico, flannel)이 동작한다.

쿠버네티스 클러스터 구성을 위해서는 kubelet이라는 에이전트가 각 노드에 필요하다.

핵심 오브젝트

Pod — 컨테이너를 다루는 기본 단위

컨테이너 애플리케이션을 구동하기 위해 반드시 알아야 할 오브젝트는 다음과 같다.

  • Pod(포드)
  • Replica Set(레플리카셋)
  • Service(서비스)
  • Deployment(디플로이먼트)

쿠버네티스에서는 컨테이너 애플리케이션의 기본 단위를 Pod라 부르며, 1개 이상의 컨테이너로 구성된 컨테이너 집합이다. 도커 엔진은 컨테이너, 도커 스웜은 서비스, 쿠버네티스는 포드 단위로 관리한다.

포드에 정의된 부가적인 컨테이너를 사이드카(sidecar) 컨테이너라고 부른다.

그렇다면 왜 도커가 아닌 포드인가?

여러 리눅스 네임스페이스(namespace)를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위해서이다. 포드 내의 컨테이너들은 네트워크 네임스페이스와 같은 리눅스 네임스페이스를 공유하기 때문에, 컨테이너가 실행 중이 아니더라도 접속이 가능한 경우가 생길 수 있다.

쿠버네티스 YAML 구조

YAML 파일의 핵심 항목은 다음과 같다.

  • apiVersion: YAML 파일에서 정의한 오브젝트의 API 버전
  • kind: 이 리소스의 종류 (예: Pod)
  • metadata: 라벨, 주석, 이름 등
  • spec: 리소스를 생성하기 위한 자세한 정보
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
spec:
  containers:
  - name: my-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

주요 kubectl 명령어

# yaml 파일로 생성
kubectl apply -f {name_of_yaml_file}
 
# 생성 확인
kubectl get pods
 
kubectl describe pods my-nginx-pod
 
# 컨테이너 접속
kubectl exec -it my-nginx-pod bash
kubectl exec -it my-nginx-pod -c {컨테이너명} bash
 
# 로그 확인
kubectl logs my-nginx-pod
 
# 삭제
kubectl delete -f nginx-pod.yaml

Replica Set — 일정 개수의 포드를 유지하는 컨트롤러

  • 정해진 수의 동일한 포드가 항상 실행되도록 관리한다.
  • 노드 장애 등의 이유로 포드를 사용할 수 없다면 다른 노드에서 포드를 다시 생성한다.

포드와 레플리카셋의 정의 중 라벨 셀렉터(Label Selector)를 통해 느슨한 연결이 이루어진다.

정리하며

쿠버네티스의 핵심은 오브젝트 기반의 선언적 관리 방식이다. YAML 파일에 원하는 상태를 정의하면 쿠버네티스가 그 상태를 유지하도록 동작한다. Pod, ReplicaSet, Deployment, Service라는 4가지 기본 오브젝트를 이해하는 것이 쿠버네티스 학습의 출발점이다.