-
쿠버네티스가 뭐길래카테고리 없음 2025. 12. 23. 20:52
Kubernetes Infrastructure Engineer 과정을 듣고 이해한 바를 정리하였습니다.
왜 K8s?
😅 VM을 사용하는 경우
[ Operator / Admin ] | ┌────────────────┼────────────────┐ | | | SSH SSH SSH | | | ┌────────────┐ ┌────────────┐ ┌────────────┐ │ VM1 │ │ VM2 │ │ VM3 │ │ (Service) │ │ (Service) │ │ (Service) │ │ │ │ │ │ │ │ - App │ │ - App │ │ - App │ │ - Config │ │ - Config │ │ - Config │ │ - Restart │ │ - Restart │ │ - Restart │ └────────────┘ └────────────┘ └────────────┘대규모 분산 환경이 되면, 개별 VM들을 제어하기 어려움
각 VM간의 환경이 달라질 위험(mutable, ❄️서버..)
😊 K8s 사용하는 경우
[ Operator / Admin ] | kubectl | ┌─────────────────┐ │ K8s API Server │ (Control Plane) └────────┬────────┘ | ┌────────────────┼────────────────┐ | | | ┌────────────┐ ┌────────────┐ ┌────────────┐ │ Node1 │ │ Node2 │ │ Node3 │ │ (VM1) │ │ (VM2) │ │ (VM3) │ │ │ │ │ │ │ │ Pod │ │ Pod │ │ Pod │ │ Pod │ │ │ │ Pod │ └────────────┘ └────────────┘ └────────────┘대규모 VM들을 하나의 환경인 것 처럼 관리 가능
K8s 특징
1️⃣ 선언적 구성 (Declarative Configuration)
Kubernetes를 이해할 때 운영자가 가장 먼저 받아들여야 할 패러다임 변화는
바로 선언적 구성(Declarative Configuration)What — 무엇을 할지 정의한다
Kubernetes에서는 운영자가 “어떻게(How)” 작업할지를 지시하지 않는다.
대신 “무엇을(What)” 원하는지, 즉 최종 상태(Desired State) 를 정의한다.예를 들면:
- “이 애플리케이션을 3개 실행하고 싶다”
- “항상 실행 중이어야 한다”
- “이 설정을 유지해야 한다”
이 내용을 YAML 파일로 선언하면,
Kubernetes가 그 상태를 만족시키기 위한 방법은 스스로 결정
Why — 운영자에게 왜 중요한가
기존 VM 기반 운영에서는 보통 다음과 같은 방식
- 1번 서버에 SSH 접속
- 애플리케이션 설치
- 서비스 실행
- 장애 나면 다시 접속해서 복구
이 방식은 절차적(Imperative) 명령에 의존함
즉, 사람이 “순서”와 “방법”을 기억하고 실행해야 한다.하지만 Kubernetes에서는:
- “서버 1번에 A 설치” ❌
- “A가 항상 3개 떠 있어야 한다” ✅
운영자는 개별 서버를 직접 만지지 않고,
원하는 상태만 선언한다.Kubernetes는 현재 상태(Current State)를 지속적으로 감시하며,
선언된 상태와 다르면 자동으로 복구하거나 조정운영자는 더 이상 ‘명령’을 관리하지 않는다.
Kubernetes에서는 ‘상태(State)’를 관리한다.
2️⃣ 자동화된 복구 (Self-Healing)
Kubernetes의 Self-Healing은 운영자의 밤잠을 지켜주는 가장 강력한 기능 중 하나
What — 스스로 회복하도록 설계된 시스템
Kubernetes는 장애를 예외 상황으로 취급하지 않음
컨테이너나 노드의 실패를 언젠가는 발생하는 정상적인 사건으로 보고,
시스템이 스스로 복구하도록 설계되어 있음
Why — 운영자에게 왜 중요한가
컨테이너가 응답하지 않거나 종료되면
(예: liveness / readiness probe 실패)- Kubernetes는 이를 감지하고 자동으로 컨테이너를 재시작
- 이는 선언된 상태(Desired State)와 현재 상태(Current State)가 어긋났기 때문이다.
더 나아가,
- 노드(서버) 자체가 다운되면
- 해당 노드에서 실행 중이던 컨테이너들을
- 다른 정상 노드로 자동 재배치한다.
운영자가 SSH로 들어가서
- 프로세스를 확인하거나
- 서버를 교체하고
- 서비스를 다시 띄울 필요가 없다.
운영자의 역할은 ‘장애 대응’이 아니라
Kubernetes가 스스로 복구할 수 있도록 ‘장애 패턴과 복구 정책’을 설계하는 것이다.
3️⃣ 손쉬운 확장과 부하 분산 (Scalability & Load Balancing)
Kubernetes는 비즈니스 요구 변화에 민첩하게 대응할 수 있는 운영 환경을 제공한다.
What — 자동 확장과 트래픽 분산
Kubernetes에서는 트래픽 증가나 리소스 사용량 변화에 따라
애플리케이션 인스턴스(Pod) 수를 쉽게, 혹은 자동으로 조절할 수 있음
Why — 운영자에게 왜 중요한가
운영자는 다음과 같은 방식으로 확장을 제어할 수 있다.
- kubectl scale 명령으로 즉시 인스턴스 수 조정
- HPA(Horizontal Pod Autoscaler) 를 통해
CPU, 메모리 등 지표 기반 자동 확장
새로 생성된 Pod들은:
- 자동으로 서비스 디스커버리에 등록되고
- Kubernetes의 Service(내장 로드밸런싱) 를 통해
- 별도 설정 없이 트래픽이 자연스럽게 분산됨
즉,
- 로드밸런서에 수동으로 서버를 추가하거나
- 설정 파일을 직접 수정할 필요가 없다.
트래픽 증가에 대응하기 위해
새벽에 VM을 만들고 LB에 수동 등록하던 시대는 끝남
4️⃣ 이식성 (Portability) & 확장성 (Extensibility)
Kubernetes는 특정 인프라 환경에 종속되지 않으면서,
필요하다면 플랫폼 자체를 확장할 수 있는 구조를 제공What — 어디서든 동일하게, 필요하면 더한다
Kubernetes는 “어디서든 동일하게 동작”하도록 설계되었고,
기본 기능만으로 부족하다면 확장할 수 있는 여지를 열어두고 있음
Why — 운영자에게 왜 중요한가
🔹 이식성 (Portability)
Kubernetes에서는
- On-premise
- Google Cloud (GKE)
- AWS (EKS)
- Azure (AKS)
어떤 환경이든 동일한 YAML 설정으로 애플리케이션을 배포하고 운영할 수 있다.
인프라가 바뀌어도 운영 방식은 바뀌지 않는다.이는 곧:
- 벤더 종속성 감소
- 멀티 클라우드 / 하이브리드 환경 대응
- 인프라 이전 비용 최소화
로 이어진다.
🔹 확장성 (Extensibility)
Kubernetes는 기본 제공 리소스(Pod, Service 등)에 그치지 않는다.
- CRD(Custom Resource Definition) 로 새로운 리소스를 정의하고
- Operator 패턴을 통해
Kubernetes가 기본으로 관리하지 않는 대상까지
K8s 방식으로 제어할 수 있다.
예를 들면:
- 데이터베이스
- 메시지 큐
- 사내 플랫폼 리소스
까지도 Kubernetes API의 일부처럼 관리할 수 있다.
인프라가 바뀌어도 운영 방식은 유지되고,
조직에 필요한 자동화 로직은 Kubernetes 위에 확장할 수 있음cf.
CRD (Custom Resource Definition)
→ Kubernetes에 새로운 리소스 타입을 정의해서, 우리만의 리소스를 Pod처럼 다루게 만드는 기능Operator
→ 특정 리소스(CRD 포함)의 생명주기와 운영 로직을 코드로 자동화하는 Kubernetes 컨트롤러 패턴
출처 : https://kubernetes.io/docs/concepts/overview/components/ 
출처 : https://phoenixnap.com/kb/understanding-kubernetes-architecture-diagrams?utm_source=chatgpt.com
🧠 Kubernetes Control Plane노드에는 Control Plane(Master Node)와 Data Plane(Worker Node)가 있다.
Kubernetes의 Control Plane은
클러스터 전체를 보고, 판단하고, 지시하는 중앙 두뇌다.운영자는 더 이상 각 노드를 직접 관리하지 않고,
Control Plane 하나와만 통신하며 클러스터를 제어한다.
하는 일 한 줄 요약
- 원하는 상태(Desired State)를 저장하고
- 현재 상태를 감시하며
- 둘이 다르면 조정 명령을 내린다
강사님 💬 :
- 고가용성을 위해 주로 3개를 만든다.
- 홀수인 이유는 선거의 용이함을 위해
핵심 구성 요소 (개념 수준)
- API Server: 모든 요청의 단일 진입점 (kubectl이 여길 본다)
- Scheduler: 새 Pod를 어디 노드에 띄울지 결정
- Controller Manager: 상태가 어긋나면 복구하도록 조정
- etcd: 클러스터의 “정답지” (상태 저장소)
구성요소 이름을 외우는 게 목적이 아니라,
“판단과 제어는 중앙에서, 실행은 노드에서” 라는 구조를 이해하는 게 중요하다.
Key Point
Control Plane은 직접 일을 하지 않는다.
대신, 클러스터가 ‘원하는 상태’로 가도록 지시만 한다.
🧠 Master Node(= Control Plane) 구성요소
한 문장 요약
“요청을 받고(API), 상태를 저장하고(etcd), 결정을 내리고(Scheduler), 그 결정을 유지한다(Controller)”
1️⃣ kube-apiserver (중앙 관문)
역할
- 모든 요청의 단일 진입점
- kubectl, CI/CD, 다른 컴포넌트 전부 여기로 들어옴
- 인증(AuthN), 인가(AuthZ), Validation 담당
강사님 💬 :
- 모든 요청은 JSON over HTTP 형식의 Restful API 요청으로,
`kubectl get pods`와 같은 명령어를 실행하면 `GET /api/v1/pods` 요청이 kube-apiserver로 전달됨
- 고유한 HTTP Endpoint를 가짐
운영 포인트
- Master 중 유일하게 외부 노출
- 죽으면?
- 👉 클러스터 변경 불가
- 👉 기존 Pod는 계속 실행됨
💡 “클러스터가 멈춘 것 같을 때, 실제로는 apiserver만 죽어있는 경우 많음”
2️⃣ etcd (상태의 진실 저장소)
역할
- 클러스터 모든 상태의 단일 진실(Single Source of Truth)
- Pod, Node, ConfigMap, Secret, Endpoint 전부 저장
운영 포인트
- IO/디스크 성능 매우 중요
- 장애 시:
- 읽기/쓰기 불가 → apiserver도 사실상 무력화
- 백업 필수 (스냅샷)
💡 “k8s 장애의 절반은 etcd 이슈에서 시작”
3️⃣ kube-scheduler (배치 결정자)
역할
- “이 Pod를 어느 Node에 올릴지” 결정
- 기준:
- 리소스
- taint / toleration
- affinity / anti-affinity
운영 포인트
- Scheduler가 죽어도:
- 기존 Pod는 정상 동작
- 새 Pod만 Pending
- Pending Pod 많으면 Scheduler 로그 먼저 확인
💡 “Pod Pending = 스케줄링 문제일 가능성 큼”
4️⃣ kube-controller-manager (상태 유지 관리자)
역할
- “원하는 상태(desired) ↔ 현재 상태(current) 비교
- 차이가 나면 계속 조정
예:
- Pod 3개 원함 → 2개면 → 1개 더 생성
- Node 죽음 → Pod 재배치
- ReplicaSet, Deployment, Node Controller 등 포함
강사님 💬 :
- Node 컨트롤러 : 클러스터의 노드 상태 감시, 장애 발생한 노드 감지
- ReplicaSet 컨트롤러 : 특정 수 pod 항상 실행되도록 보장
그 외 컨트롤러 존재
운영 포인트
- 느려지면:
- 복구가 늦어짐
- 장애 체감 시간 증가
- “자동 복구 안 되는 느낌” 나면 의심
💡 “k8s가 알아서 복구 안 한다면, controller 문제”
5️⃣ cloud-controller-manager (선택)
역할
- 클라우드 연동 전용
- LoadBalancer
- Volume
- Node lifecycle
운영 포인트
- On-prem이면 없음
- 클라우드 환경(AWS/GCP/Azure)에서는 중요
강사님 💬 :
- Node 컨트롤러 : 클라우드 인프라의 Node 상태를 감지하여, K8s Node 리소스와 동기화. (ex. 클라우드 VM 종료되면, K8s Node도 Unreachable 상태로 변경)
`kubectl get pods`와 같은 명령어를 실행하면 `GET /api/v1/pods` 요청이 kube-apiserver로 전달됨
- 고유한 HTTP Endpoint를 가짐
장애 시 감 잡는 법
증상의심 컴포넌트kubectl 안 됨 apiserver Pod 상태 이상 etcd Pod Pending scheduler 자동 복구 안 됨 controller 외부 LB 안 붙음 cloud-controller
⚙️ Kubernetes Worker Node
Worker Node는
Kubernetes 클러스터에서 실제 애플리케이션이 실행되는 곳이다.Control Plane이 “무엇을 해야 하는지”를 결정하면,
Worker Node는 그 지시에 따라 컨테이너를 실행하고 상태를 보고한다.
하는 일 한 줄 요약
- Pod를 실행하고
- 리소스를 할당하며
- 현재 상태를 Control Plane에 보고한다
핵심 구성 요소 (개념 수준)
- kubelet: Control Plane의 지시를 받아 Pod를 실행·관리
- Container Runtime: 컨테이너를 실제로 실행 (containerd 등)
- kube-proxy: 네트워크 규칙을 설정해 트래픽 전달
Worker Node는 스스로 판단하지 않는다.
결정은 Control Plane, 실행은 Worker Node다.
Key Point
Worker Node는 ‘두뇌’가 아니라 ‘손과 발’이다.
이 구조 덕분에:
- 노드는 자유롭게 추가·제거할 수 있고
- 장애가 나면 교체 대상이 되며
- 운영자는 개별 노드보다 클러스터 전체 상태에 집중할 수 있다.
실습 환경
[ Google Cloud Shell ] | | SSH / kubectl | ┌──────────────────────────────────────────────────────────┐ │ 동일 네트워크 (VPC / Subnet) │ │ │ │ ┌───────────────────────┐ ┌───────────────────────┐ │ │ │ VM1 │◀──▶│ VM2 │ │ │ │ (Master Node) │ │ (Slave Node) │ │ │ └───────────────────────┘ └───────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘