TestForge | Aidevops | 📊 Plogger ✍️ Blog 📚 Docs
plogger

AI DevOps Korea

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다

aidevops.kr에서 LLMOps, RAG, AI Agent, 관측성, 평가, 비용-성능 최적화를 실전 운영 관점으로 정리합니다.

Kubernetes 기초 설계 가이드

· 수정 4월 16일
Kubernetes 기초 설계 가이드 다이어그램
이 그림은 인그레스, 서비스 디스커버리, 파드 실행, 리컨실리에이션을 하나의 흐름으로 연결해 Kubernetes를 개별 개념이 아닌 하나의 시스템으로 이해하도록 돕습니다.
Kubernetes를 처음 접할 때는 오브젝트 이름이 많아 복잡해 보이지만, 핵심은 몇 가지로 압축됩니다. 컨테이너를 안정적으로 실행하고, 원하는 상태를 선언하며, 네트워크와 설정을 추상화하고, 장애가 나면 복구 가능한 구조를 만드는 것입니다. 기초를 잘 이해하면 이후의 HPA, ingress, operator, service mesh도 더 자연스럽게 이어집니다.

Pod는 실행 단위지만 운영 단위는 아니다

Pod는 컨테이너가 실제로 돌아가는 최소 단위입니다. 하지만 직접 Pod를 다루기보다 대부분은 Deployment 같은 상위 리소스로 관리합니다. Pod는 죽고 다시 생길 수 있는 존재이기 때문에, IP 고정이나 로컬 상태 의존 설계는 위험합니다.

Deployment는 원하는 상태를 유지한다

Deployment의 핵심은 현재 상태를 선언한 원하는 상태로 맞춰 간다는 점입니다. 버전 롤아웃, 롤백, replica 수 조정이 모두 이 모델 위에서 동작합니다.

Service는 네트워크 불안정을 숨긴다

Pod는 계속 바뀌지만 Service는 안정적인 접근 지점을 제공합니다. 앱끼리 직접 Pod IP를 바라보지 않고 Service 이름을 통해 통신하는 이유가 여기에 있습니다.

ConfigMap과 Secret은 설정 경계를 만든다

애플리케이션 이미지에 환경별 값을 박아 넣지 않고 외부 설정으로 분리하면, 같은 이미지를 여러 환경에 배포하기 쉬워집니다. 다만 Secret은 base64 인코딩일 뿐 암호화 그 자체는 아니라는 점을 기억해야 합니다.

YAML보다 더 중요한 것은 운영 질문

Kubernetes를 쓴다는 것은 단순 배포 스크립트 교체가 아닙니다. readiness probe를 어떻게 둘지, 자원 요청과 제한을 어떻게 잡을지, 장애 시 재시작만으로 충분한지, 로그와 메트릭은 어디서 볼지 같은 질문이 따라옵니다.

자주 하는 실수

Pod를 VM처럼 생각해 ssh 접속과 로컬 파일 상태에 의존하는 경우가 많습니다. 또 requests/limits 없이 배포하거나, liveness/readiness를 같은 의미로 설정해 장애를 키우는 경우도 흔합니다.

마무리

Kubernetes 기초의 핵심은 리소스 종류를 외우는 것이 아니라, 선언형 운영 모델을 이해하는 것입니다. Pod, Deployment, Service, ConfigMap이 각각 어떤 문제를 해결하는지 알면 복잡한 클러스터도 훨씬 읽기 쉬워집니다.

운영 환경에서 어려워지는 지점

  • 쿠버네티스 기본기는 pod, service, deployment를 단순 YAML 객체로만 보면 쉽게 오용되기 때문에 중요하다.
  • 초기 고통의 대부분은 스케줄링, 네트워킹, 헬스 관리에 대한 정신 모델 부족에서 나온다.
  • 컨트롤 플레인은 운영을 자동화하지만 애플리케이션 규율까지 대신해주지는 않는다.

중요한 아키텍처 결정

  • pod는 내구 서버가 아니라 일시적인 실행 단위로 본다.
  • resource request, probe, rollout 동작을 처음부터 의도적으로 선언한다.
  • 클러스터 관심사와 애플리케이션 관심사를 분리해 YAML을 읽기 가능하게 유지한다.

실무 예시

운영을 고려한 최소 배포는 헬스와 자원 기대치를 명시적으로 적는다.

resources:
  requests:
    cpu: 100m
    memory: 256Mi
livenessProbe:
readinessProbe:

피해야 할 안티패턴

  • readiness나 liveness 전략 없이 컨테이너를 배포하는 것.
  • stateless deployment 안에 stateful 가정을 넣는 것.
  • 스케줄링 결과를 이해하지 않고 manifest를 복사해 쓰는 것.

운영 체크리스트

  • 실사용량과 비교해 request/limit를 검토한다.
  • rollout과 rollback 경로를 테스트한다.
  • pod 재시작 패턴과 probe 실패를 관찰한다.
  • manifest를 버전 관리하고 환경 차이를 분명히 한다.

최종 판단

쿠버네티스 기본기는 객체 이름이 아니라 런타임 동작을 이해하는 일이다. 실행 모델을 초기에 익힌 팀이 피할 수 있는 장애를 훨씬 많이 피한다.

Continue Reading

다음으로 읽기 좋은 글

다음 탐색

이 주제를 시스템 관점으로 더 이어서 보기