Kubernetes란? 개념·작동 원리·도입 판단 기준
Kubernetes(K8s)의 정의와 선언적 작동 방식, Pod·Node·Control Plane의 관계, Docker와의 차이, 자동화할 수 있는 범위와 도입 전 확인할 조건을 공식 자료에 근거해 설명합니다.
Kubernetes란 컨테이너화된 워크로드와 서비스를 관리하는 이식 가능하고 확장 가능한 오픈소스 플랫폼입니다. 사용자가 원하는 상태를 선언하면 Kubernetes의 여러 제어 기능이 현재 상태를 계속 확인하고 그 차이를 줄이도록 동작합니다. 다만 컨테이너 이미지를 만들어 주거나 애플리케이션 코드를 고치는 도구는 아니며, Pod가 준비 상태라고 해서 업무 결과와 사용자 경험까지 정상이라는 뜻도 아닙니다.
발행자와 출처를 먼저 밝힙니다
이 글의 발행자는 옵저버빌리티 플랫폼을 제공하는 Guance입니다. Guance는 Kubernetes 또는 Cloud Native Computing Foundation(CNCF)을 대표하지 않으며, 이 글도 독립적인 인증 보고서가 아닙니다. Kubernetes의 정의와 작동 범위는 Kubernetes 한국어 개요와 현재 영어 개요를 함께 확인했고, 프로젝트 소속은 CNCF의 Kubernetes 프로젝트 페이지를 기준으로 했습니다. Guance 제품 링크는 다음 학습·평가 경로를 안내할 때만 사용하며, Kubernetes 자체의 기술 사실을 증명하는 자료로 사용하지 않습니다.
한국 검색 결과에 노출되는 cncf.co.kr은 CNF(Cloud Native Forum)의 도메인이며 공식 CNCF 도메인인 cncf.io와 다릅니다. 이 글은 cncf.co.kr을 Kubernetes 또는 CNCF의 일차 출처로 인용하지 않습니다.
자료 확인일은 2026년 8월 1일입니다. Kubernetes 한국어 문서는 번역이 영어 원문보다 늦을 수 있다는 안내가 있으므로, 핵심 사실은 현재 영어 원문과 교차 확인했습니다.
먼저 알아둘 5가지
- Kubernetes는 컨테이너 런타임 그 자체가 아니라, 여러 워크로드와 서비스를 원하는 상태에 가깝게 유지하도록 조정하는 플랫폼입니다.
- 핵심은 “한 번 명령하고 끝”이 아니라
spec에 적은 기대 상태와status에 나타난 현재 상태의 차이를 지속적으로 조정하는 데 있습니다. - Pod, Node, Control Plane은 같은 것이 아닙니다. Pod는 배포 단위, Node는 Pod가 실행되는 머신, Control Plane은 클러스터 상태를 관리하는 계층입니다.
- 자동 복구, 스케줄링, 롤아웃 같은 메커니즘은 조건이 맞을 때 동작합니다. 애플리케이션의 비즈니스 로직, 데이터 정확성, 전체 사용자 경험을 자동으로 보장하지 않습니다.
- Kubernetes의 운영 복잡성을 감당할 이유가 분명하지 않다면 관리형 컨테이너나 PaaS처럼 더 단순한 선택이 적합할 수 있습니다.
관련 가이드Kubernetes Architecture: 구성 요소·제어 흐름·장애 지점→
Kubernetes는 왜 필요한가요?
컨테이너가 몇 개뿐이고 한 대의 서버에서 수동으로 운영할 수 있다면 별도의 오케스트레이션 계층이 반드시 필요한 것은 아닙니다. 그러나 서비스 수와 배포 빈도가 늘고, 여러 머신에 워크로드를 배치하며, 실패한 실행 단위를 교체하고, 동일한 구성을 여러 환경에서 유지해야 한다면 사람의 수동 작업만으로는 상태 차이를 일관되게 관리하기 어려워집니다.
Kubernetes 공식 개요는 Kubernetes가 서비스 디스커버리, 부하 분산, 스토리지 오케스트레이션, 자동화된 롤아웃과 롤백, 자동 빈 패킹, 자동 복구, 시크릿과 구성 관리 같은 메커니즘을 제공한다고 설명합니다. 이 목록은 “설치하면 운영 문제가 모두 사라진다”는 약속이 아닙니다. 각 메커니즘은 올바른 리소스 정의, 프로브, 용량, 네트워크, 스토리지와 외부 의존성이 갖춰져야 의도한 결과를 낼 수 있습니다.
Kubernetes는 Google이 2014년에 오픈소스로 공개한 프로젝트이며, 현재 CNCF의 Graduated 프로젝트입니다. K8s는 Kubernetes의 가운데 여덟 글자를 숫자 8로 줄인 표현입니다. 이 이력은 프로젝트의 소속을 설명할 뿐, 특정 조직이나 산업에서의 시장 점유율 또는 “유일한 표준”을 증명하지 않습니다.
선언적 관리의 핵심: 원하는 상태와 현재 상태
Kubernetes 오브젝트 공식 문서는 대부분의 Kubernetes 오브젝트가 spec과 status를 가진다고 설명합니다.
spec은 사용자가 원하는 상태를 표현합니다. 예를 들어 실행할 이미지와 필요한 복제본 수를 선언할 수 있습니다.status는 Kubernetes가 관찰한 현재 상태를 나타냅니다.- 컨트롤러는 API를 통해 두 상태를 비교하고 현재 상태가 원하는 상태에 가까워지도록 반복해서 조정합니다.
이 과정을 reconciliation, 즉 조정이라고 부릅니다. 조정은 중앙의 단일 프로세스가 모든 단계를 고정된 순서로 지시하는 작업 흐름이 아닙니다. 여러 컨트롤러와 구성 요소가 각자의 책임 범위에서 API 상태를 관찰하고 비동기적으로 동작합니다. 자세한 구성 요소와 제어 흐름은 별도 글인 Kubernetes 아키텍처: Control Plane부터 Pod까지에서 다룹니다.
선언적 상태는 매우 유용하지만 범위가 있습니다. replicas: 3이라는 선언은 세 개의 복제본을 유지하려는 의도를 나타낼 수 있지만, 각 요청의 계산 결과가 맞는지, 데이터가 손상되지 않았는지, 결제 과정이 성공했는지까지 설명하지는 않습니다. 플랫폼 오브젝트의 상태와 애플리케이션·사용자 상태를 따로 확인해야 하는 이유입니다.
핵심 개념을 한눈에 보기
다음 표는 입문을 위한 역할 구분입니다. 세부 구성과 통신 경로는 아키텍처 글의 소유 범위이므로 여기서는 확장하지 않습니다.
| 개념 | 무엇인가 | 이 정보만으로 알 수 없는 것 | 공식 자료 |
|---|---|---|---|
| Cluster | Control Plane과 하나 이상의 worker Node로 구성되는 실행·관리 경계 | 실제 물리 배치, 관리형 서비스 내부 구현, 애플리케이션 가용성 | Cluster Architecture |
| Control Plane | 클러스터 상태를 관리하고 API, 조정, 스케줄링 등의 책임을 수행하는 계층 | 모든 장애의 단일 원인 또는 애플리케이션의 정상 여부 | Kubernetes Components |
| Node | Pod를 실행하는 물리 머신 또는 가상 머신 | 그 위의 모든 Pod와 애플리케이션이 정상인지 여부 | Nodes |
| Pod | Kubernetes에서 만들고 관리할 수 있는 가장 작은 배포 가능한 컴퓨팅 단위 | 비즈니스 요청의 성공, 외부 의존성의 상태 | Pods |
| Deployment | ReplicaSet과 Pod의 선언적 업데이트를 관리하는 워크로드 리소스 | 모든 배포의 무중단 또는 자동 업무 롤백 | Deployments |
| Service | 변할 수 있는 Pod 집합에 안정적인 네트워크 추상화를 제공하는 리소스 | 각 endpoint의 업무 응답이 올바른지 여부 | Service |
Pod는 영구적인 서버처럼 다루는 단위가 아닙니다. 공식 Pod 문서에 따르면 Pod는 비교적 일시적이며, 일반적으로 Deployment 같은 워크로드 리소스가 Pod 생성을 관리합니다. Pod 하나를 수동으로 유지하는 방식과 워크로드 컨트롤러가 원하는 복제본을 관리하는 방식은 운영 의미가 다릅니다.
Kubernetes가 할 수 있는 것과 할 수 없는 것
아래 표는 Kubernetes 공식 메커니즘과 운영팀의 책임을 같은 줄에 놓기 위해 Guance 편집팀이 구성한 경계표입니다. Kubernetes/CNCF의 공식 선택표가 아니며, 게시 전 Kubernetes 엔지니어의 행별 검토가 필요합니다.
| 메커니즘 | 직접 관리하는 범위 | 필요한 조건 | 단독으로 증명하거나 해결하지 못하는 것 | 첫 확인 지점 |
|---|---|---|---|---|
| Replica와 self-healing | kubelet의 restartPolicy 기반 컨테이너 재시작과 workload controller의 Pod 교체·복제본 유지 |
올바른 restartPolicy, controller, probe, 이미지, 자원과 의존성 |
애플리케이션 코드 수정, 데이터 복구, 업무 응답의 정확성 | 오브젝트 status, container state, Pod 조건, Events, 프로브 결과 |
| Scheduling | 아직 Node에 바인딩되지 않은 Pod의 배치 | 충분한 Node, resource request, constraint와 스케줄링 정책 | 배치 뒤의 처리 성능, 외부 서비스 용량, 코드 정확성 | Pod 조건과 스케줄링 Events |
| Service discovery | Service와 endpoint 집합 사이의 안정적인 접근 추상화 | selector 또는 endpoint 정의, DNS와 네트워크 경로 | 각 endpoint의 업무 의미와 사용자 여정 | Service, EndpointSlice, 실제 요청 결과 |
| Rollout | Deployment가 ReplicaSet과 Pod를 점진적으로 교체하도록 관리 | 적절한 strategy, probe, 여유 용량과 애플리케이션 호환성 | 모든 변경의 무중단, 데이터 스키마 호환성, 자동 업무 롤백 | Deployment 상태, ReplicaSet, Events, 서비스 지표 |
| Scaling | 선언·정책에 따라 워크로드 복제본이나 일부 자원을 조정 | 정확한 측정값, 정책, quota, Node 용량 | 비용 절감, 성능 개선 또는 의존성 확장을 자동 보장 | 목표와 실제 복제본, 제한, 포화도, 사용자 지연 |
Self-healing의 공식 범위는 Kubernetes Self-Healing 문서에서 확인할 수 있습니다. 이 메커니즘은 실패한 컨테이너를 다시 시작하거나 관리 중인 Pod를 교체할 수 있지만, “모든 장애를 자동으로 진단하고 근본 원인을 제거한다”는 기능이 아닙니다.
Kubernetes Observability 문서와 공식 개요를 함께 보면 Kubernetes는 상태와 텔레메트리를 위한 여러 기반을 제공하지만, 완성된 형태의 애플리케이션 로그·모니터링·알림 체계를 기본 제공하는 플랫폼으로 설명되지 않습니다. 어떤 신호를 수집하고, 얼마나 보존하며, 누가 어떤 기준으로 대응할지는 운영 환경에 맞게 별도로 설계해야 합니다.
Docker, VM, 관리형 Kubernetes와 어떻게 다른가요?
이 네 가지는 같은 문제를 푸는 동의어가 아닙니다.
| 항목 | 주된 책임 | Kubernetes와의 관계 | 확인할 경계 |
|---|---|---|---|
| Container image/runtime | 애플리케이션과 의존성을 이미지로 묶고 컨테이너를 실행 | Kubernetes는 호환 runtime을 통해 컨테이너 실행을 요청하고 상태를 관리 | 이미지 공급망, runtime 지원, 실행 보안은 별도 검토 |
| Docker | 이미지와 컨테이너를 다루는 도구·생태계 | Kubernetes 그 자체가 아니며 Kubernetes의 유일한 runtime도 아님 | Docker 사용 여부와 클러스터 runtime을 구분 |
| VM | 게스트 운영체제를 포함하는 가상 머신 경계 | Kubernetes Node가 VM일 수 있지만, Kubernetes는 VM 가상화 계층의 대체어가 아님 | 하이퍼바이저·VM 가용성과 Pod 운영을 분리 |
| Managed Kubernetes | 공급자가 클러스터 운영 책임의 일부를 맡는 서비스 형태 | Kubernetes API와 워크로드 모델을 사용하더라도 책임 범위는 공급자·상품에 따라 다름 | Control Plane, Node, 업그레이드, 네트워크, 보안, 백업의 책임 계약 |
Kubernetes Container Runtimes 문서는 Kubernetes가 CRI(Container Runtime Interface)를 통해 호환 container runtime과 연동한다고 설명합니다. 따라서 “Kubernetes가 Docker를 완전히 대체했다”거나 “Docker가 Kubernetes의 유일한 실행 엔진”이라고 단정하는 것은 정확하지 않습니다.
관리형 Kubernetes를 선택하더라도 애플리케이션 배포, resource request, 네트워크 정책, 데이터 보호, 계측과 사고 대응까지 모두 공급자가 맡는다고 가정하면 안 됩니다. 정확한 경계는 해당 서비스의 현재 공식 문서와 계약을 확인해야 합니다.
우리 팀에 Kubernetes가 맞는지 판단하는 방법
다음은 Guance 편집팀의 조건식 검토 목록입니다. Kubernetes 또는 CNCF의 공식 권고가 아니며, 점수나 보편적인 도입 임계값을 제공하지 않습니다. 한 항목의 “예”만으로 도입을 결정하지 말고, 얻는 운영 능력과 새로 떠안을 복잡성을 함께 검토하십시오.
관련 가이드쿠버네티스(K8s) 모니터링 시작하기 — 4계층 지표와 알람 설정→
| 확인 질문 | Kubernetes가 유용할 가능성이 커지는 조건 | 더 단순한 선택을 먼저 볼 조건 |
|---|---|---|
| 워크로드 형태 | 여러 컨테이너화된 서비스와 배포 단위를 지속적으로 조정해야 함 | 소수의 단순한 워크로드를 한 환경에서 안정적으로 운영 |
| 변경과 확장 | 빈번한 배포, 복제본 조정, 다중 환경 일관성이 중요함 | 변경이 드물고 수동 운영의 실패 비용이 낮음 |
| 장애 대응 | 실패한 실행 단위 교체와 선언 상태 복구를 자동화할 필요가 있음 | 애플리케이션 자체가 단순하고 PaaS의 복구 기능으로 충분함 |
| 팀 역량 | 업그레이드, 네트워크, 스토리지, 보안, 용량과 옵저버빌리티를 맡을 owner가 있음 | 클러스터 자체가 새로운 단일 장애 지점과 인력 부담이 됨 |
| 공급자 선택 | 관리형 서비스가 운영 부담을 줄이면서 지역·네트워크·규정 요건을 충족함 | 더 단순한 관리형 컨테이너/PaaS가 같은 요구를 충족함 |
| 조사 가능성 | 플랫폼 상태, 애플리케이션 신호와 사용자 영향을 분리해 볼 수 있음 | Pod 수와 CPU만 수집하고 업무 오류를 확인할 경로가 없음 |
도입 판단은 “컨테이너를 쓰는가?”보다 넓습니다. 플랫폼 운영팀이 감당할 업그레이드와 보안 책임, 애플리케이션 팀이 지킬 배포 규칙, 데이터를 보존·복구할 책임, 장애 때 사용할 증거 경로를 함께 정해야 합니다. 예상 트래픽이나 직원 수만으로 “규모가 X 이상이면 무조건 Kubernetes”라는 공식을 만들 수는 없습니다.
Pod가 정상처럼 보여도 서비스가 실패할 수 있는 이유
Kubernetes는 구성한 상태 확인과 오브젝트 상태를 기준으로 플랫폼이 관찰할 수 있는 사실을 기록합니다. Kubernetes Self-Healing 문서가 설명하는 복구 메커니즘은 컨테이너·Pod와 구성한 상태 확인의 범위에서 동작합니다. 그러나 상태 확인이 다루지 않는 업무 규칙, 잘못된 계산, 외부 결제 오류 또는 일부 사용자만 겪는 프런트엔드 실패는 Pod 상태만으로 알 수 없습니다.
예를 들어 /health가 성공하더라도 주문 API가 잘못된 결과를 반환할 수 있습니다. 이것은 이번 초안에서 실행해 얻은 결과가 아니라, 플랫폼 건강 신호와 업무 정확성을 분리해 설계해야 한다는 경계 설명입니다. 실제 환경에서는 Service 요청, 애플리케이션 로그·Trace, SLO와 사용자 측 신호로 가설을 검증해야 합니다.
계획된 경계 실습 — 아직 실행하지 않음
| 항목 | 상태 | 계획 |
|---|---|---|
| 환경 | 공개 자료에 명시되지 않음 | 비프로덕션 kind 클러스터에서 Kubernetes patch, kind, runtime, OS/architecture와 이미지 digest를 고정할 예정 |
| 시나리오 A | 공개 자료에 명시되지 않음 | 존재하지 않는 image digest/tag를 사용해 desired replicas, Pod 상태와 Events를 기록할 예정 |
| 시나리오 B | 공개 자료에 명시되지 않음 | process와 health endpoint는 응답하지만 업무 endpoint는 고정 5xx를 반환하는 테스트 이미지를 만들어 플랫폼 상태와 실제 요청 결과를 분리할 예정 |
| 공개 자료 | 공개 자료에 명시되지 않음 | manifest, 이미지 소스·digest, 명령, stdout/stderr, exit code, UTC 시각, cleanup과 두 번째 엔지니어 재실행 기록을 탈민감화해 보존할 예정 |
실습 전에는 “검증했다”, “실측했다”, “몇 초 만에 복구됐다” 같은 결과 표현을 사용할 수 없습니다. kubeconfig, token, 내부 hostname·IP·도메인과 고객 데이터는 어떤 공개 결과에도 포함하지 않습니다.
다음에는 무엇을 읽어야 하나요?
목적에 따라 다음 경로를 선택하십시오.
- 표준 개념과 최신 동작은 Kubernetes 한국어 개요와 현재 영어 아키텍처 문서에서 확인합니다.
- Guance 수집 구현을 평가하려면 Container 통합 문서(영문), 현재 KubernetesPrometheus discovery 문서(영문), 그리고 ServiceMonitor / PodMonitor 지원 필드 문서(영문)를 먼저 확인합니다. 각 문서의 현재 버전, 권한, 지원 범위와 제한을 실제 환경에 맞게 검증해야 합니다.
- 제품 관점의 생산 환경 모니터링 경로를 평가하려면 Guance 한국어 Kubernetes 모니터링 솔루션을 참고할 수 있습니다. 이 링크는 Guance의 자체 설명이며 독립적인 성능 검증이 아닙니다.
정의 페이지의 목적은 Kubernetes를 선택하도록 밀어붙이는 것이 아니라, 무엇을 자동화하고 무엇을 팀이 계속 책임져야 하는지 구분할 수 있게 하는 것입니다. 설치 명령, 세부 구성, 제품 비교와 구매 판단은 각각 별도의 문서와 owner가 맡아야 합니다.
공식 일차 자료
- Kubernetes 한국어 개요 / 현재 영어 개요
- Kubernetes Cluster Architecture
- Kubernetes Objects
- Kubernetes Pods
- Kubernetes Deployments
- Kubernetes Service
- Kubernetes Self-Healing
- Kubernetes Observability
- Kubernetes Container Runtimes
- CNCF Kubernetes project