Brain핵심 인사이트
- 본질: Kubernetes (K8s)는 컨테이너화된 애플리케이션의 배포·스케일링·자가 치유(Self-Healing)를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼으로, 선언형(Declarative) 상태 관리가 핵심 철학이다.
- 가치: K8s는 수백~수천 개의 컨테이너를 수동으로 관리하는 운영 부담을 자동화로 해결하며, HPA (Horizontal Pod Autoscaler, 수평 파드 자동 확장)를 통해 트래픽 변화에 즉시 대응하는 탄력적 운영을 실현한다.
- 판단 포인트: 기술사 시험에서는 K8s의 핵심 오브젝트(Pod·Deployment·Service·Ingress) 역할, 마스터-워커 노드 아키텍처, HPA/VPA 차이, 고가용성 설계 방안을 체계적으로 서술해야 한다.
Ⅰ. 개요 및 필요성
마이크로서비스 아키텍처가 확산되면서 수십~수백 개의 컨테이너를 관리하는 문제가 대두되었다. Docker만으로는 컨테이너의 배포·장애 복구·스케일링·로드 밸런싱을 자동화할 수 없었고, 이를 해결하기 위해 Google이 내부 시스템(Borg)의 노하우를 바탕으로 2014년 Kubernetes를 오픈소스로 공개하였다. 현재 CNCF (Cloud Native Computing Foundation)가 관리하며, 전 세계 컨테이너 오케스트레이션의 사실상 표준(De facto Standard)이 되었다.
K8s의 핵심 철학은 선언형(Declarative) 관리다. "현재 상태를 어떻게 변경하라"고 명령하는 대신, "원하는 최종 상태(Desired State)가 무엇인지"를 선언하면 K8s가 현재 상태와의 차이를 계속 감지하고 자동으로 수렴시킨다. 이 메커니즘이 자가 치유(Self-Healing)·자동 스케일링·무중단 배포를 가능하게 하는 근본 원리다.
📢 섹션 요약 비유: K8s는 공연장의 무대 감독이다. "무대에 배우 3명이 항상 있어야 해"라고 선언하면, 한 명이 쓰러져도 즉시 다른 배우를 투입하고, 공연이 바뀌면 자동으로 배우를 교체한다. 감독이 직접 다 지시하지 않아도 된다.
Ⅱ. 아키텍처 및 핵심 원리
2-1. K8s 클러스터 아키텍처
┌──────────────────────────────────────────────────────────────────────┐
│ Kubernetes Cluster 구조 │
├─────────────────────────────┬────────────────────────────────────────┤
│ Control Plane (마스터) │ Worker Nodes │
│ │ │
│ ┌──────────────────────┐ │ ┌─────────────┐ ┌─────────────┐ │
│ │ API Server │◄──┤ │ Worker #1 │ │ Worker #2 │ │
│ │ (모든 통신 허브) │ │ │ │ │ │ │
│ └──────────┬───────────┘ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ │ │ │ Pod A │ │ │ │ Pod C │ │ │
│ ┌──────────┴───────────┐ │ │ └───────┘ │ │ └───────┘ │ │
│ │ etcd (클러스터 DB) │ │ │ ┌───────┐ │ │ ┌───────┐ │ │
│ │ (상태 저장소) │ │ │ │ Pod B │ │ │ │ Pod D │ │ │
│ └──────────────────────┘ │ │ └───────┘ │ │ └───────┘ │ │
│ ┌──────────────────────┐ │ │ kubelet │ │ kubelet │ │
│ │ Scheduler │ │ │ kube-proxy │ │ kube-proxy │ │
│ └──────────────────────┘ │ └─────────────┘ └─────────────┘ │
│ ┌──────────────────────┐ │ │
│ │ Controller Manager │ │ │
│ └──────────────────────┘ │ │
└─────────────────────────────┴────────────────────────────────────────┘
2-2. 핵심 K8s 오브젝트
| 오브젝트 | 역할 | 핵심 특징 |
|---|---|---|
| Pod | 컨테이너 실행 최소 단위 | 1개 이상의 컨테이너, 동일 네트워크·스토리지 공유 |
| Deployment | Pod 복제·업데이트 관리 | 롤링 업데이트, 롤백 지원 |
| ReplicaSet | 지정된 Pod 복제본 수 유지 | Deployment가 내부적으로 사용 |
| Service | Pod 집합에 대한 안정적 네트워크 엔드포인트 | ClusterIP·NodePort·LoadBalancer 유형 |
| Ingress | 외부 HTTP/HTTPS 트래픽 라우팅 규칙 | URL 경로·호스트 기반 라우팅 |
| ConfigMap | 환경 설정 데이터 분리 저장 | 12-Factor App Factor 3 구현 |
| Secret | 민감 데이터(비밀번호·토큰) 관리 | Base64 인코딩, etcd 저장 |
| PersistentVolume | 영구 스토리지 연결 | Pod 재시작 후에도 데이터 유지 |
| HPA | Horizontal Pod Autoscaler, 수평 자동 확장 | CPU/메모리 메트릭 기반 Pod 수 조절 |
📢 섹션 요약 비유: K8s 오브젝트는 레스토랑 운영 시스템이다. Pod은 요리사 한 명, Deployment는 요리사 팀장, Service는 안내 데스크, Ingress는 입구의 안내판이다. 각자 역할이 명확하고, 모두 협력하여 손님(트래픽)을 처리한다.
Ⅲ. 비교 및 연결
3-1. HPA vs. VPA vs. Cluster Autoscaler 비교
| 구분 | HPA (수평 확장) | VPA (수직 확장) | Cluster Autoscaler |
|---|---|---|---|
| 전체 명칭 | Horizontal Pod Autoscaler | Vertical Pod Autoscaler | Cluster Autoscaler |
| 확장 방향 | Pod 수 증가/감소 | Pod의 CPU·메모리 할당 조정 | 워커 노드 수 증가/감소 |
| 응답 속도 | 빠름 (수 초~수 분) | 중간 (Pod 재시작 필요) | 느림 (노드 프로비저닝 시간) |
| 적합 워크로드 | 무상태(Stateless) 서비스 | 메모리 집약적 단일 프로세스 | 전체 클러스터 용량 관리 |
| 한계 | 단일 Pod 처리 한계 존재 | Pod 재시작으로 잠시 중단 | 노드 추가 시간 지연 |
3-2. K8s Service 유형 비교
| Service 유형 | 접근 범위 | 사용 사례 |
|---|---|---|
| ClusterIP | 클러스터 내부만 | 마이크로서비스 간 내부 통신 |
| NodePort | 외부 → 노드 IP:Port | 개발·테스트 환경 |
| LoadBalancer | 클라우드 LB를 통한 외부 접근 | 프로덕션 외부 트래픽 |
| ExternalName | 외부 DNS 이름으로 라우팅 | 외부 데이터베이스 연결 |
3-3. 고가용성(HA) 설계 방안
K8s 클러스터 고가용성을 위해 Control Plane을 3개 이상의 홀수 노드로 구성하여 etcd 쿼럼(Quorum)을 보장한다. Pod AntiAffinity 정책으로 동일 서비스의 Pod들이 서로 다른 워커 노드에 분산 배치되도록 하며, PodDisruptionBudget (PDB)으로 유지보수 중에도 최소 가용 Pod 수를 보장한다.
📢 섹션 요약 비유: K8s HA는 항공기 엔진을 여러 개 달아두는 것과 같다. 엔진 하나가 꺼져도 나머지 엔진으로 비행이 계속된다. K8s는 장애가 생겨도 자동으로 다른 서버에 서비스를 다시 띄운다.
Ⅳ. 실무 적용 및 기술사 판단
4-1. 운영 환경 K8s 배포 전략
| 배포 전략 | 설명 | 장점 | 단점 |
|---|---|---|---|
| Rolling Update | 구버전 Pod를 점진적으로 신버전으로 교체 | 무중단, 단순 | 롤백 시간 소요 |
| Blue/Green | 신버전 환경 완전 준비 후 트래픽 일괄 전환 | 즉시 롤백 가능 | 리소스 2배 필요 |
| Canary | 신버전에 소량(예: 5%) 트래픽만 우선 인가 | 위험 최소화 | 설정 복잡 |
4-2. 보안 강화 방안
- RBAC (Role-Based Access Control, 역할 기반 접근 제어): 최소 권한 원칙으로 서비스 계정 권한 제한
- Network Policy: Pod 간 허용 트래픽 화이트리스트 방식으로 통제
- Pod Security Admission: 특권(Privileged) 컨테이너 실행 제한
- Image Scanning: CI/CD에서 취약점 스캔(Trivy) 후 신뢰된 이미지만 배포
- Secrets 관리: HashiCorp Vault + External Secrets Operator 연동
4-3. 모니터링 및 관찰 가능성
Prometheus로 K8s 메트릭을 수집하고, Grafana 대시보드로 시각화한다. 알림은 Alertmanager가 처리하여 Slack·PagerDuty로 전송한다. 분산 추적은 Jaeger 또는 OpenTelemetry를 사용하며, 이 세 가지(메트릭·로그·추적)가 K8s 운영의 관찰 가능성 삼각형을 구성한다.
📢 섹션 요약 비유: Canary 배포는 광산에 카나리아 새를 먼저 보내는 것처럼, 새 기능을 소수 사용자에게만 먼저 보내서 문제가 없는지 확인한 뒤 전체로 확장하는 안전한 배포 방식이다.
Ⅴ. 기대효과 및 결론
Kubernetes는 컨테이너 기반 애플리케이션의 운영 복잡성을 자동화로 해결하여, 엔지니어가 인프라 관리 대신 비즈니스 가치 창출에 집중할 수 있게 한다. HPA를 통한 자동 스케일링은 예상치 못한 트래픽 급증에도 SLA (Service Level Agreement, 서비스 수준 계약)를 유지하고, Self-Healing은 장애 탐지·복구 자동화로 운영 비용을 절감한다.
기술사 시험에서는 ① K8s 마스터-워커 아키텍처의 컴포넌트 역할, ② 핵심 오브젝트(Pod·Deployment·Service·Ingress) 간 관계, ③ HPA·VPA·Cluster Autoscaler 차이, ④ Blue/Green·Canary 배포 전략을 체계적으로 서술하고, 고가용성 설계 방안까지 포함해야 완성도 높은 답안이 된다.
📢 섹션 요약 비유: K8s는 "절대 쉬지 않는 자동화 공장 관리자"다. 직원(컨테이너)이 쓰러지면 즉시 새 직원을 투입하고, 주문(트래픽)이 늘면 자동으로 직원을 더 뽑고, 새 작업 방식(버전)으로 교체할 때도 공장을 멈추지 않는다.
📌 관련 개념 맵
| 개념 | 설명 | 연관 키워드 |
|---|---|---|
| Kubernetes (K8s) | 컨테이너 오케스트레이션 플랫폼 | CNCF, Google Borg |
| Pod | K8s 배포 최소 단위 | 컨테이너, 공유 네트워크 |
| Deployment | Pod 선언형 관리·업데이트 오브젝트 | 롤링 업데이트, 롤백 |
| Service | Pod 집합의 안정적 네트워크 엔드포인트 | ClusterIP, LoadBalancer |
| Ingress | 외부 HTTP 트래픽 라우팅 규칙 | URL 경로, 호스트 기반 |
| HPA | Horizontal Pod Autoscaler, 수평 자동 확장 | CPU 메트릭, 스케일링 |
| etcd | K8s 클러스터 상태 저장 분산 KV 스토어 | 쿼럼, 고가용성 |
| RBAC | Role-Based Access Control, 역할 기반 접근 제어 | 최소 권한, ServiceAccount |
| Canary 배포 | 소량 트래픽 신버전 선 테스트 배포 방식 | 위험 최소화, Istio |
👶 어린이를 위한 3줄 비유 설명
- K8s는 "로봇 공장 감독"이야. 로봇(컨테이너) 하나가 고장 나면 즉시 새 로봇을 투입하고, 주문이 많아지면 자동으로 로봇을 더 만들어. 감독이 항상 깨어있어서 공장이 절대 멈추지 않아.
- Pod는 로봇 한 팀, Deployment는 팀장, Service는 고객 안내 창구야. 고객(트래픽)은 창구에 요청하면 되고, 어떤 팀이 처리하는지는 K8s가 알아서 결정해.
- HPA는 "손님이 많아지면 자동으로 직원을 더 뽑는 스마트 인사팀"이야. 손님이 줄면 인력도 자동으로 줄여서 비용 낭비도 없어.