파드

배포의 최소 단위. 컨테이너 하나가 아니라 함께 사는 묶음이다.

같은 파드 안 컨테이너들은

• 네트워크 네임스페이스를 공유한다 → localhost 로 서로를 부른다
• 같은 노드에 함께 뜬다 (쪼개지지 않는다)
• 볼륨을 공유할 수 있다
• 함께 태어나고 함께 죽는다

왜 껍데기가 필요한가

컨테이너를 직접 스케줄하면 '반드시 붙어 있어야 하는 둘' 을 표현할 수 없다

• 로그 수집 사이드카 — 앱과 같은 볼륨을 봐야 한다
• 프록시 사이드카 — 앱의 localhost 를 가로채야 한다
• 설정 동기화 — 앱이 읽는 파일을 갱신해야 한다

이 관계를 표현하려면 '함께 배치되는 단위' 가 필요하다

파드는 일회용이다

파드는 고쳐지지 않는다. 문제가 생기면 지우고 새로 만든다

• IP 가 바뀐다 → 그래서 서비스가 필요하다
• 이름이 바뀐다 (web-7d4f8-x9k2l)
• 안에 쓴 데이터는 사라진다 → 그래서 볼륨이 필요하다

"파드를 고친다" 는 개념이 없다는 것이 설계의 출발점이다

initContainer 와 사이드카

spec:
  initContainers:
    - name: wait-db
      image: busybox:1.36
      command: ["sh", "-c", "until nc -z db 5432; do sleep 2; done"]
  containers:
    - name: app
      image: myapp:1.4.2

• initContainer — 앱보다 '먼저' 순서대로 실행되고 끝나야 다음이 뜬다

  • 준비 작업 — 마이그레이션 대기 · 설정 렌더링 · 권한 조정

• 사이드카 — 앱과 '함께' 도는 보조 컨테이너

  • restartPolicy: Always 를 가진 initContainer 로 선언하면
  • 앱보다 먼저 시작되고 나중에 종료된다
  • 로그 수집기가 앱보다 먼저 죽어 마지막 로그를 놓치는
    • 문제가 해결된다

파드 하나에 컨테이너를 여럿 둘 때의 기준

• 같이 둔다 — · 반드시 같은 노드에 있어야 한다

  • 같은 볼륨을 봐야 한다
  • localhost 로 통신해야 한다
  • 함께 배포·확장돼야 한다

• 따로 둔다 — · 독립적으로 확장돼야 한다

  • 배포 주기가 다르다
  • 서로 없어도 의미가 있다

"편의상 같이" 두면 확장이 묶여 버린다 사이드카가 3~4개를 넘어가면 설계를 다시 본다

파드 안에서 볼 수 있는 것

downward API 로 자기 정보를 얻는다

  env:
    - name: POD_NAME
      valueFrom: { fieldRef: { fieldPath: metadata.name } }
    - name: NODE_NAME
      valueFrom: { fieldRef: { fieldPath: spec.nodeName } }
    - name: MEM_LIMIT
      valueFrom: { resourceFieldRef: { resource: limits.memory } }

로그에 파드 이름을 넣거나, limit 에 맞춰 스레드 풀을 정할 때 쓴다

면접 함정

• ❌ "파드 = 컨테이너" → 여러 개를 담을 수 있고, 그 관계가 파드의 존재 이유다.
• ❌ "파드를 직접 만들어 운영한다" → 죽으면 아무도 안 살린다. 컨트롤러가 필요하다.