[k8s] Kubernetes 주요 개념 정리

쿠버네티스를 작년에 Udemy 강의를 들은 이후에 VMware Workstation을 기반으로 Cluster를 만들어보고 사용해보질 않았더니 기본적인 개념을 많이 잊어버려서 정리하고자 이 글을 작성한다.

---

1️⃣ Docker와 Kubernetes의 차이

Docker는 컨테이너를 만들고 실행하는 도구이다. Kubernetes는 여러 서버 위에서 컨테이너를 배포하고 관리하는 오케스트레이션 도구이다.

구분	Docker	Kubernetes
주요 역할	컨테이너 생성과 실행	컨테이너 배포, 확장, 복구, 관리
관리 단위	컨테이너	Pod, Deployment, Service 등
사용 환경	개발 환경, 단일 서버	여러 서버로 구성된 운영 환경
장애 대응	사용자가 직접 처리	컨트롤러가 상태를 확인하고 복구

Docker는 컨테이너 실행 자체에 초점이 있고, Kubernetes는 여러 컨테이너를 운영 환경에서 안정적으로 관리하는 데 초점이 있다. 따라서 두 도구는 역할이 다르다고 보는 편이 자연스럽다.

2️⃣ Kubernetes의 기본 구조

ControlPlane 구성요소

구성요소	역할
API Server	Kubernetes API 요청을 받는 진입점, kubectl 명령, Controller, Scheduler, kubelet 등은 API Server를 통해 클러스터와 통신.
ETCD	Kubernetes 클러스터의 상태 정보를 저장하는 저장소. Pod, Deployment, Service 같은 리소스 정보와 클러스터 상태 저장.
Scheduler	새로 생성된 Pod를 어느 Worker Node 에 배치할지 결정. 노드의 자원 상태와 조건을 확인해 적절한 노드를 선택.
Controller Manager	현재 상태와 원하는 상태를 비교하고, 차이가 있을 경우 필요한 조치를 수행. Pod 개수가 부족하면 새 Pod가 생성되도록 조정.

Worker Node 구성요소

구성요소	역할
kubelet	각 Worker Node에서 Pod가 정상적으로 실행되도록 관리하는 에이전트. API Server로부터 Pod 실행 요청을 받고, 컨테이너 실행 상태를 확인해 보고.
kube-proxy	Service를 통한 네트워크 통신을 처리. Pod IP가 바뀌어도 Service를 통해 접근할 수 있도록 네트워크 규칙을 관리.
Container Runtime	실제 컨테이너를 실행하는 구성요소. containerd, CRI-O 등 사용 가능. kubelet의 요청에 띠라 컨테이너를 생성하고 실행.

3️⃣ Pod, ReplicaSet, Deployment, DaemonSet

Pod는 컨테이너가 실행되는 최소 단위이다. Kubernetes는 컨테이너를 직접 배포하지 않고, Pod라는 단위 안에서 컨테이너를 실행한다. 하나의 Pod에는 보통 하나의 컨테이너가 들어가지만, 서로 밀접하게 동작해야 하는 컨테이너 여러 개가 함게 들어갈 수도 있다.
ReplicaSet은 정해진 개수의 Pod가 항상 유지되도록 관리하는 리소스이다. Pod는 일시적인 객체이기 때문에 직접 Pod만 생성하면 장애 발생 시 개수를 자동으로 복구하기 어렵다. ReplicaSet은 현재 실행 중인 Pod 수를 확인하고 원하는 개수와 다르면 자동으로 조정한다.
Deployment는 애플리케이션 배포와 업데이트를 관리하는 리소스이다. 내부적으로 ReplicaSet을 사용해 Pod 개수를 유지하고 새로운 배전을 배포할 때 기존 Pod를 새 Pod로 점진적으로 교체한다. Deployment는 일반적인 애플리케이션 배포에 가장 많이 사용되는데 API 서버처럼 여러 개의 Pod로 실행하고 새 버전을 배포하거나 문제가 생겼을 때 이전 버전으로 되돌려야 하는 경우에 적합하다. ReplicaSet이 Pod 개수 유지에 초점이 있다면 Deployment는 배포 과정을 전체 관리하는 데 초점을 둔다.
DaemonSet은 모든 노드 또는 특정 조건을 만족하는 노드마다 Pod를 하나씩 실행하도록 보장하는 리소스이다. Deployment처럼 원하는 개수의 Pod를 유지하는 방식이 아니라 노드 단위로 필요한 Pod를 배치하는 데 초점을 둔다. DaemonSet은 각 노드에서 반드시 실행되어야 하는 구성 요소를 배포할 때 사용해 로그 수집기, 모니터링 에이전트, 보안 에이전트처럼 노드마다 실행되어야 하는 Pod에 적합하다.

구분	ReplicaSet	Deployment	DaemonSet
핵심 역할	Pod가 지정한 수 만큼 계속 유지되도록 관리.	애플리케이션 배포, 업데이트, 롤백을 관리.	모든 노드 또는 특정 노드마다 Pod가 실행되도록 관리.
사용하는 경우	직접 사용하기보다 Deployment가 내부적으로 관리하는 경우가 많음.	웹 서버, API 서버처럼 일반적인 Stateless 애플리케잇녀을 배포할 때 사용. 새 버전 배포와 이전 버전 롤백이 필요한 경우에 적합.	로그 수집기, 모니터링 에이전트, 보안 에이전트처럼 각 노드에서 반드시 실행되어햐 하는 구성 요소를 배포할 때 사용.

4️⃣ Service(Cluster IP, NodePort, LoadBalancer)

Service는 애플리케이션이 특정 Pod IP에 직접 접근하도록 구성하면 해당 Pod가 재생성되는 순간 연결이 끊길 수 있다. 그러므로 Pod에 접근하기 위한 고정된 네트워크 진입점을 제공한다. Service를 사용하면 Pod가 바뀌더라도 클라이언트는 Service 이름이나 Service IP를 통해 계속 접근할 수 있다.
Service는 내부 통신과 외부 노출 방식에 따라 여러 타입으로 나뉜다.

Service Type	역할	사용하는 경우
ClusterIP	클러스터 내부에서만 접근 가능	내부 API, 내부 DB 접근
NodePort	노드 IP와 특정 포트로 외부 접근	테스트용 외부 접근
LoadBalancer	외부 로드밸런서를 통해 접근	운영 환경의 외부 서비스 노출

5️⃣ Ingress, Gateway와 HTTPRoute

Ingress, Gateway, HttpRoute는 외부에서 들어오는 HTTP 요청을 Kubernetes 내부 Service로 연결하기 위해 사용된다. Service가 Pod에 접근하기 위한 고정 지점을 제공한다면 Ingress와 Gateway API는 외부 요청을 어던 Service로 보낼지 정하는 역할을 한다.

구분	Ingress	Gateway	HTTPRoute
핵심 역할	HTTP/HTTPS 요청을 도메인이나 경로 기준으로 Service에 전달하는 리소스	외부 트래픽을 받는 진입점을 정의하는 리소스	Gateway로 들어온 HTTP 요청을 어떤 Service로 보낼지 정하는 라우팅 규칙
사용하는 경우	하나의 도메인에서 /api, /admin처럼 경로별로 다른 Service에 요청을 보내야 할 때 사용. 기존 Kubernetes 환경에서 HTTP 라우팅을 구성할 때 많이 사용.	외부 트래픽을 받는 지점과 애플리케이션 라우팅 규칙을 분리해서 관리하고 싶을 때 사용. 인프라 담당자가 트래픽 진입점을 관리하는 구조에 적합.	특정 Gateway로 들어온 요청을 경로, 호스트, 조건에 따라 여러 Service로 나누어 보내야 할 때 사용. 애플리케이션 담당자가 자신의 서비스 라우팅 규칙을 관리할 때 적합.

Ingress는 비교적 단순한 HTTP 라우팅에 적합하다. Gateway와 HTTPRoute는 트래픽 진입점과 라우팅 규칙을 나누어 관리해야 할 때 적합하다.

6️⃣ ConfigMap과 Secret

ConfigMap과 Secret은 애플리케이션 설정값을 컨테이너 이미지와 분리하기 위해 사용된다. 애플리케이션 이미지는 그대로 두고, 환경에 따라 달라지는 설정값만 따로 주입할 수 있다.

구분	ConfigMap	Secret
핵심 역할	민감하지 않은 설정값을 저장하고 Pod에 전달하는 리소스	비밀번호, 토큰, 인증서 같은 민감 정보를 저장하고 Pod에 전달하는 리소스
사용하는 경우	개발, 테스트, 운영 환경마다 다른 DB 주소, 외부 API 주소, 로그 레벨, 기능 설정값 등을 관리할 때 사용	DB 비밀번호, API 토큰, 인증 키, 인증서처럼 코드나 이미지에 직접 넣으면 안 되는 값을 관리할 때 사용

ConfigMap은 일반 설정값 관리에 사용하고, Secret은 민감 정보 관리에 사용한다. 다만 Secret도 기본 설정만으로 완전한 보안을 보장하지 않으므로 접근 권한과 암호화 설정을 함께 고려해야 한다.

7️⃣ ServiceAccount와 RBAC

ServiceAccount와 RBAC는 Kubernetes 리소스 접근 권한을 제어하기 위해 사용된다. ServiceAccount는 Pod가 Kubernetes API에 접근할 때 사용하는 계정이고 RBAC는 해당 계정이나 사용자에게 어떤 권한을 줄지 정하는 방식이다.

구분	ServiceAccount	RBAC
핵심 역할	Pod가 Kubernetes API에 접근할 때 사용하는 계정	사용자나 ServiceAccount가 어떤 리소스에 어떤 작업을 할 수 있는지 제어하는 권한 관리 방식
사용하는 경우	특정 Pod가 Kubernetes API를 조회하거나 조작해야 할 때 사용. 예를 들어 모니터링 도구가 Pod 목록을 조회해야 하는 경우 ServiceAccount를 부여 가능.	사용자나 Pod에 필요한 권한만 부여하고 싶을 때 사용. 예를 들어 특정 ServiceAccount에는 Pod 조회 권한만 주고, 삭제 권한은 주지 않는 식으로 제어 가능.

ServiceAccount는 “누가 접근하는가”에 가깝고, RBAC는 “무엇을 할 수 있는가”에 가깝다. 실제 운영 환경에서는 두 개를 함께 사용해 Pod나 사용자에게 필요한 권한만 부여한다.

8️⃣ Rolling Update, Blue-Green, Canary

구분	Rollin Update	Blue-Green	Canary
핵심 역할	기존 Pod를 조금씩 새 버전의 Pod로 교체하는 배포 방식.	기존 운영 환경과 새 버전 환경을 분리한 뒤 트래픽을 한 번에 전환하는 배포 방식.	새 버전을 일부 사용자나 일부 트래픽에만 먼저 적용해 검증하는 배포 방식.
사용하는 경우	일반적인 애플리케이션을 서비스 중단 없이 점진적으로 배포하고 싶을 때 사용. Kubernetes Deployment의 기본 업데이트 방식으로 많이 사용.	새 버전 환경을 미리 준비해두고, 문제가 생기면 기존 환경으로 빠르게 되돌리고 싶을 때 사용. 빠른 전환과 롤백이 중요한 경우에 적합.	새 버전의 위험을 제한된 범위에서 먼저 확인하고 싶을 때 사용. 오류율, 응답 시간, 사용자 반응을 확인하며 점진적으로 배포 범위를 넓힐 때 적합.

Rolling Update는 기본적인 점진 배포에 적합하다. Blue-Green은 빠른 전환과 복구에 유리하다. Canary는 실제 트래픽 일부로 새 버전을 먼저 검증할 때 적합하다.

---

내용을 정리하면서 보니까 진짜 내가 너무 많은 내용을 잊어버렸다는 것을 깨달았다. 주로 실습을 많이 하다보니 개념을 잘 이해해야겠다는 생각을 많이 못했던 것 같다.