SW 전공

SW 전공 이론 학습

이론 목록으로 돌아가기

컨테이너와 Kubernetes 기초

컨테이너 이미지·레지스트리·런타임과 Kubernetes의 Pod·Deployment·Service·Config·Secret·오토스케일을 학습한다.

예상 읽기 9분

1. 컨테이너의 개념

컨테이너는 애플리케이션과 필요한 라이브러리·설정을 이미지로 묶고, 호스트 운영체제 커널을 공유하면서 격리된 프로세스로 실행하는 방식이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
물리 서버
   ↓
Host OS Kernel
   ↓
Container Runtime
┌────────┬────────┬────────┐
│App A   │App B   │App C   │
│libs A  │libs B  │libs C  │
└────────┴────────┴────────┘

컨테이너는 독립 커널을 기본 포함하는 VM보다 일반적으로 가볍고 시작이 빠르다.

2. VM과 컨테이너 비교

기준VM컨테이너
격리 단위가상 하드웨어·게스트 OS프로세스·네임스페이스·자원제한
커널VM별 게스트 커널호스트 커널 공유
시작 속도상대적으로 느림상대적으로 빠름
이미지 크기큼작음
격리 강도일반적으로 강함설정·런타임 보안 중요
OS 다양성서로 다른 게스트 OS 가능커널 계열 제약

컨테이너가 VM을 완전히 대체하는 것이 아니라 목적에 따라 조합한다.

3. 이미지와 컨테이너

  • 이미지: 변경하지 않는 실행 템플릿
  • 컨테이너: 이미지를 실행한 인스턴스
  • 레지스트리: 이미지 저장·배포
  • 레이어: 이미지 구성 파일 계층
  • 런타임: 이미지에서 격리 프로세스를 실행
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Dockerfile·빌드 정의
      ↓ build
   Image v1
      ↓ push
   Registry
      ↓ pull
   Container 실행

컨테이너 내부를 수동 수정하는 대신 이미지와 설정을 변경해 다시 배포하는 재현 가능한 방식을 사용한다.

4. 이미지 작성 원칙

DOCKERFILE코드 영역 안에서 좌우로 이동할 수 있습니다.
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY app.jar /app/app.jar
USER 10001
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

원칙:

  • 필요한 파일만 포함
  • 작은 신뢰 이미지 사용
  • 버전 고정과 취약점 점검
  • 비밀정보를 이미지에 포함하지 않음
  • root가 아닌 사용자
  • 빌드·실행 단계 분리
  • 이미지 서명·출처·SBOM 관리 가능

특정 이미지가 작다고 항상 더 안전한 것은 아니다. 업데이트와 출처도 중요하다.

5. 컨테이너 상태와 데이터

컨테이너 파일시스템은 교체될 수 있으므로 영구 데이터는 외부 볼륨이나 관리형 저장소에 둔다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Container
   ├─ 임시 실행 파일
   └─ /data ─────► Persistent Volume

로그도 컨테이너 내부 파일에만 남기지 않고 표준 출력이나 중앙 로그 시스템으로 수집하는 것이 일반적이다.

6. Kubernetes의 목적

Kubernetes는 다수 노드에서 컨테이너 애플리케이션의 배포·스케줄링·복구·확장·서비스 연결을 관리하는 오케스트레이션 플랫폼이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Control Plane
├─ API·상태 관리
├─ Scheduler
└─ Controller
       │
┌──────┴───────────┐
Worker Node A     Worker Node B
├─ Pod            ├─ Pod
└─ Runtime        └─ Runtime

사용자가 원하는 상태를 선언하면 컨트롤러가 실제 상태를 맞추려고 반복한다.

7. Pod

Pod는 Kubernetes에서 스케줄링하는 기본 실행 단위이다. 하나 이상의 컨테이너가 네트워크와 일부 저장자원을 공유한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Pod
├─ App Container
├─ Sidecar Container
├─ shared network namespace
└─ shared volume

Pod 자체는 교체될 수 있으므로 고정 IP나 로컬 상태에 의존하지 않는다.

8. Deployment와 ReplicaSet

Deployment는 상태 없는 애플리케이션의 복제 수와 배포 버전을 선언적으로 관리한다.

YAML코드 영역 안에서 좌우로 이동할 수 있습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: example/api:1.2
          ports:
            - containerPort: 8080
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Deployment
   ↓
ReplicaSet
   ↓
Pod 1  Pod 2  Pod 3

Pod가 사라지면 원하는 복제 수를 맞추기 위해 새 Pod를 생성한다.

9. Service와 Ingress

Pod IP는 바뀔 수 있으므로 Service가 안정된 접근점과 부하분산을 제공한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Client → Service
          ├─ Pod A
          ├─ Pod B
          └─ Pod C

Ingress·Gateway 계층은 외부 HTTP 요청을 여러 Service로 라우팅할 수 있다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Internet → Ingress
            ├─ /api → API Service
            └─ /web → Web Service

10. ConfigMap과 Secret

  • ConfigMap: 일반 설정
  • Secret: 비밀값을 위한 별도 객체

설정과 이미지를 분리하면 환경별 재빌드를 줄일 수 있다. 그러나 Secret 객체가 존재한다고 자동으로 완전한 암호화·안전한 접근이 보장되는 것은 아니다. 저장 암호화, RBAC, 외부 비밀관리, 로그 노출 방지가 필요하다.

11. 상태 확인과 자원관리

  • Liveness Probe: 재시작이 필요한 비정상 상태 확인
  • Readiness Probe: 트래픽을 받을 준비가 되었는지 확인
  • Startup Probe: 느린 기동이 끝났는지 확인
  • requests: 스케줄링에 필요한 최소 자원
  • limits: 컨테이너가 사용할 수 있는 자원 상한
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Pod 시작
   ↓ Startup 성공
Readiness 성공 → Service 트래픽 수신
   │
Liveness 실패 반복 → 컨테이너 재시작

readiness 실패를 liveness 실패처럼 처리하면 일시적 의존 서비스 지연 때문에 불필요한 재시작이 반복될 수 있다.

12. 배포·확장

  • Rolling Update
  • Rollback
  • Horizontal Pod Autoscaler
  • 노드 자동확장
  • Pod Disruption Budget
  • Anti-affinity·Topology 분산
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
v1 Pod 3개
   ↓ 1개씩 교체
v2 1개 + v1 2개
   ↓
v2 3개

확장 기준은 CPU뿐 아니라 요청량·큐 길이·업무 지표가 될 수 있다.

13. 보안·운영 주의

  • root·특권 컨테이너 최소화
  • 호스트 경로 마운트 제한
  • 이미지 취약점·서명
  • 네트워크 정책
  • ServiceAccount·RBAC 최소권한
  • 비밀정보 분리
  • 자원제한
  • 감사로그
  • 백업과 상태 저장소 보호

14. namespace·cgroup과 이미지 안전성

컨테이너는 namespace로 프로세스·네트워크·마운트 등을 격리하고 cgroup으로 CPU·메모리 같은 자원을 계측·제한한다. VM처럼 별도 커널을 가지지 않으므로 커널 취약점과 과도한 capability를 주의한다.

DOCKERFILE코드 영역 안에서 좌우로 이동할 수 있습니다.
FROM builder AS build
RUN make app
FROM distroless
COPY --from=build /out/app /app
USER 10001
ENTRYPOINT ["/app"]

multi-stage build, 작은 base image, digest 고정, 서명·SBOM, non-root 실행, 읽기 전용 filesystem을 사용한다.

15. Deployment·Service 상태 판독

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Deployment → ReplicaSet → Pods
Service(selector) → Ready Pod endpoints
Ingress/Gateway → Service

Deployment의 desired replicas가 4인데 Ready가 2라면 Service는 일반적으로 준비된 endpoint만 대상으로 한다. selector·label 불일치면 Pod가 정상이어도 endpoint가 0개일 수 있다.

16. Probe의 역할

  • startupProbe: 느린 시작 동안 liveness/readiness 판단을 유예
  • readinessProbe: 트래픽 수신 대상 포함 여부
  • livenessProbe: 비정상 프로세스 재시작 필요 여부

외부 DB가 잠시 느리다고 liveness를 실패시키면 재시작 폭풍이 날 수 있다. readiness와 liveness의 실패 의미를 분리한다.

17. requests·limits와 QoS

scheduler는 Pod의 request를 기준으로 배치 가능 노드를 찾는다. request는 사용량을 예약 판단하는 값이지 애플리케이션에 항상 보장되는 절대 최소 처리량과 동일하지 않다. CPU limit은 throttling, memory limit 초과는 OOM kill로 이어질 수 있다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Guaranteed: 모든 container가 CPU·memory request=limit
Burstable: 일부 request/limit 설정
BestEffort: request/limit 없음

18. 상태 저장·확장

PV는 저장 자원, PVC는 사용자 요구, StorageClass는 동적 프로비저닝 정책을 표현한다. 안정된 이름·순차 배포가 필요한 상태 저장 워크로드는 StatefulSet을 고려한다. HPA는 측정 metric과 request를 기준으로 비율을 계산하므로 request 누락이 문제를 만들 수 있다.

19. 보안·운영 판독

  • Secret은 기본적으로 단순 base64 표현일 수 있으므로 etcd 암호화·RBAC·외부 secret 관리가 필요
  • NetworkPolicy는 지원 CNI와 ingress/egress 양방향 정책을 확인
  • Pod Security, service account 최소권한, capability drop, seccomp 적용
  • immutable image와 declarative desired state를 사용하고 수동 컨테이너 수정 금지

확인 문제

  1. Kubernetes scheduler가 기본적으로 배치에 사용하는 자원값은?
  2. Deployment 4개 중 Ready 2개면 Service endpoint는 일반적으로?
  3. startupProbe가 필요한 경우는?
  4. memory limit을 넘으면 대표적으로?
  5. Secret의 base64가 암호화가 아닌 이유는?