Kubernetes

Kubernetes는 여러 컴퓨터에서 컨테이너 애플리케이션을 운영하기 위한 오픈 소스 플랫폼이다. 사용자는 실행 명령의 순서를 일일이 지정하기보다 필요한 복제본 수와 자원, 연결 방법을 선언한다. 제어기는 관측한 상태를 선언과 비교하며 차이를 줄인다. 공식 개요는 이 선언형 제어와 확장 가능한 구조를 설명한다.

Kubernetes
종류	컨테이너 오케스트레이션 플랫폼
관리 방식	선언한 원하는 상태를 제어 루프로 유지
주요 구성	컨트롤 플레인 · 워커 노드
애플리케이션 단위	Pod · 워크로드 · Service
공식 자료	Kubernetes 공식 문서
이미지 출처	Kubernetes 공식 로고 · The Kubernetes Authors · CC-BY-4.0

어떻게 동작하는가

API 서버는 클러스터 객체를 다루는 진입점이다. 스케줄러는 아직 배치되지 않은 Pod가 실행될 노드를 고르고, 각 노드의 kubelet은 컨테이너 런타임과 협력해 Pod를 실행한다. etcd는 제어면의 상태를 보존한다. Pod는 함께 배치되고 네트워크를 공유하는 컨테이너의 실행 단위이며, 영구적인 서버 이름과 동일하지 않다.

Deployment는 보통 상태를 자체 보관하지 않는 애플리케이션의 복제본과 업데이트를 관리한다. Service는 교체되는 Pod 앞에 안정적인 접근 지점을 제공한다. 데이터의 영속성은 별도의 볼륨·저장소 설계가 필요하다. Deployment 문서에서 복제본과 롤아웃의 관계를 확인할 수 있다.

장점과 한계

장점은 배치·복구·서비스 발견을 공통 API로 다루고, 설정을 파일로 검토·재현할 수 있다는 점이다. 요청량 변화에 맞춰 복제본을 조정하거나 새 버전을 단계적으로 배포하기도 쉽다. 다만 여러 복제본을 같은 장애 영역에 두면 물리 장애에 대한 보호는 제한된다.

작은 프로그램 하나를 실행하는 데에는 클러스터·인증서·네트워크·저장소 관리 비용이 과할 수 있다. Kubernetes가 이미지를 빌드하거나 데이터베이스를 자동 백업해 주는 것도 아니다. 자원 요청, 상태 확인, 접근 권한, 관측 도구를 애플리케이션 특성에 맞게 설계해야 한다.

도서 검색 서비스 예시

다음은 준비된 연습 클러스터에서 읽을 수 있는 Deployment 예시다. registry.example.test는 가상의 레지스트리이며 이미지를 별도로 준비해야 한다. 실행 명령이 아니라 선언 구조를 설명하는 예제다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: book-search
  namespace: library-lab
spec:
  replicas: 2
  selector:
    matchLabels:
      app: book-search
  template:
    metadata:
      labels:
        app: book-search
    spec:
      containers:
        - name: api
          image: registry.example.test/library/search:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

replicas: 2는 두 Pod를 원하는 상태라는 뜻이다. 두 Pod가 서로 다른 노드에 배치됨을 보장하지는 않으며, 외부에서 접속할 주소도 이 선언만으로 생기지 않는다. CPU 100m는 CPU 한 개의 10분의 1에 해당하는 요청량이다. 이 값은 부하 시험을 대신하는 성능 보증이 아니다.

자주 생기는 오해

Running은 프로세스 실행 상태이고 서비스 응답이 올바르다는 증거는 아니다. Ready 조건과 실제 요청 결과를 함께 본다. Pod를 직접 고친 뒤 Deployment가 그 변경을 보존할 것이라고 기대하거나, 임시 컨테이너 파일을 영구 데이터로 사용하는 실수도 피해야 한다.

참고 자료