진정한 QA가 되기 위해
쿠버네티스를 다시 공부해본다..
도커가 나오고
도커를 통해 컨테이너라는 개념으로 배포가 되자
이 컨테이너들을 위한 일종의 운영체제(?)가 필요해졌음.
컨테이너 운영환경을 제공하는 오픈소스 플랫폼이 바로 쿠버네티스.
도커에만 국한되는 것은 아니고
- 다양한 컨테이너 엔진 지원 (docker, hyper container, rkt)
또한 특징으로는
- Cluster: 중앙 제어 (master-node), 네트워킹, 노드 스케일
- Self-healing (상태 관리): 자동으로 문제가 발생한 노드의 컨테이너 대체
- Auto Scheduling: 리소스 사용과 제약 사항을 기준으로 자동으로 컨테이너 스케줄링
- Auto Scaling: 사용자가 정의한 주기 / 이벤트에 따라 서버(컨테이너)를 자동으로 생성 & 삭제
- Load Balancing: 트래픽을 여러 대의 서버가 분산 처리
- Cloud Controller: 클라우드 연동 확장 가능
- Automatic rollouts and rollbacks: 서비스 중지 없이, 어플리케이션의 새로운 버전 및 설정에 대한 업데이트 가능
쿠버네티스 구조
클러스터 구조 (마스터-노드)
- 마스터: 전체 클러스터를 관리하는 컨트롤러
- 노드: 실제 컨테이너가 배포되는 머신
- kubectl: 클러스터를 제어하기 위한 커멘드 라인 도구

마스터
- API Server: 노드 및 다른 모듈과 직접 통신하여 요청을 처리하는 마스터 모듈
- etcd: 분산 저장소, 클러스터의 모든 설정, 상태 데이터 저장
- Scheduler: 할당 되지 않는 컨테이너를 조건에 따라 적절한 노드에 할당
- kube-controller: 클러스터 상태 관리
- cloud-controller: 클라우드를 통해 node를 추가 / 삭제
노드
: 실제 컨테이너가 배포되는 장소
- proxy: 노드의 네트워크 규칙 유지 및 관리
- kubelet: Pod에서 컨테이너가 확실하게 동작하도록 관리, 주기적으로 컨테이너 상태를 마스터에게 보고

오브젝트
: 클러스터의 리소스를 정의하고 구성
- Spec: 오브젝트를 생성할 때 리소스에 원하는 스펙에 해당
- Status: 오브젝트의 현재 상태
- Yaml 파일을 통해 오브젝트 선언 및 생성
오브젝트 종류
- Pod
- 쿠버네티스에서 배포할 수 있는 가장 작은 단위
- 한 개 이상의 컨테이너와 스토리지, 네트워크 속성 보유
- Pod의 컨테이너는 스토리지와 네트워크 공유
- ReplicaSet
- Pod를 한 개 이상 복제하여 관리하는 오브젝트
- 복제할 개수, 생성할 Pod의 설정값 보유
- Deployment
- 쿠버네티스가 어플리케이션을 어떻게 생성하고 업데이트 해야 하는지에 대한 지시 사항
- ReplicaSet의 상위 추상화 개념
- 롤링 업데이트를 위해 사용
- Service
- 네트워크 관련 오브젝트
- 내부 로드 밸런서를 생성할 때 사용
- Volume
- 저장소 관련 오브젝트
- 다양한 저장 방식을 지원
- 호스트 디렉토리를 그대로 사용하거나 다양한 스토리지를 동적으로 생성 가능
Pod 생성 과정
- kubectl: ReplicaSet Spec 정의 후 API Server에 명령 전달
- controller: ReplicaSet의 Spec을 보고 새로운 Pod 생성 후 API Server에 전달
- scheduler: 노드에 할당되지 않은 Pod가 있으면, 조건에 맞는 노드를 찾아 할당
- kubelet: 자신에게 할당된 Pod를 생성, 주기적으로 상태를 API Server에 전달
- API Server: 각 모듈에게 받은 정보를 etcd에 저장

롤링 업데이트
: 새 버전을 배포하면서 새 인스턴스를 하나씩 늘려가고 기존 버전을 하나씩 줄여가는 방식.
시스템을 중지하지 않고 업데이트 시킬 수 있다.
https://www.redhat.com/ko/topics/containers/what-is-kubernetes
쿠버네티스 클러스터란?
작동 중인 쿠버네티스 배포를 클러스터라고 하며, 클러스터는 Linux® 컨테이너를 실행하는 호스트 그룹입니다. 쿠버네티스 클러스터는 컨트롤 플레인과 컴퓨팅 머신(또는 노드)의 2개 부분으로 시각화할 수 있습니다.
각 노드는 자체 Linux 환경이며 물리 또는 가상 머신일 수 있습니다. 각 노드는 컨테이너로 이루어진 포드를 실행합니다.
1. 핵심 개념과 역할
-
마스터 노드 (Control Plane)
- 역할: 클러스터를 관리하고 조정하는 "두뇌"입니다.
- 구성 요소:
- API 서버: 클러스터와의 모든 요청을 처리하는 엔드포인트.
- 스케줄러: Pod를 적절한 워커 노드에 할당.
- 컨트롤러 관리자: 오브젝트 상태를 관리하고 클러스터의 이상 상태를 감지.
- etcd: 클러스터의 상태 데이터를 저장하는 키-값 저장소.
-
노드 (Worker Node)
- 역할: 컨테이너가 실행되는 물리적/가상 머신입니다.
- 구성 요소:
- Kubelet: 마스터와 통신하며, Pod 실행을 관리.
- Kube-proxy: 네트워크 라우팅 및 서비스 디스커버리를 지원.
- 컨테이너 런타임: Docker, containerd 같은 컨테이너 실행 도구.
-
Pod
- 역할: 하나 이상의 컨테이너가 실행되는 최소 단위.
- 특징:
- 동일한 네트워크 네임스페이스를 공유.
- 하나의 Pod 안에 컨테이너들이 협력(예: 앱 + 로깅 컨테이너).
-
Object
- 역할: Kubernetes에서 리소스를 정의하는 추상화된 단위.
- 주요 오브젝트:
- Deployment: 애플리케이션 배포를 관리.
- Service: Pod 간의 네트워크 통신을 노출.
- ConfigMap/Secret: 설정값과 민감한 데이터를 관리.
- Namespace: 리소스 그룹화를 위한 논리적 구분.
2. Kubernetes의 동작 흐름
Kubernetes가 애플리케이션을 배포하고 관리하는 과정을 단계별로 살펴보겠습니다:
-
애플리케이션 정의 및 배포
- 사용자가 YAML 파일로 Deployment, Service 등을 정의.
kubectl apply 명령을 통해 API 서버에 전달.
-
스케줄링 및 배치
- API 서버는 YAML 파일의 정의를 etcd에 저장.
- 스케줄러가 클러스터 내 가용 노드를 평가하고 Pod 배치.
-
Pod 생성 및 실행
- 선택된 노드의 Kubelet이 Pod를 생성.
- 컨테이너 런타임(Docker 등)이 컨테이너를 실행.
-
서비스 및 네트워킹
- Service를 통해 Pod 간 통신 또는 외부 클라이언트와 통신.
- Kube-proxy가 네트워크 라우팅과 로드 밸런싱 처리.
-
모니터링 및 관리
- 컨트롤러 매니저가 Pod 상태를 지속적으로 확인.
- 장애가 발생하면 자동으로 재배치하거나 복구.
Kubernetes와 QA의 연계
-
클러스터 관리와 QA
- 테스트 환경 자동화: Kubernetes를 사용하여 여러 테스트 환경을 손쉽게 생성 및 제거.
- 확장성 테스트: 클러스터를 스케일 업/다운하여 부하 테스트 수행.
-
CI/CD와의 연계
- Jenkins/GitLab과 같은 CI/CD 도구와 Kubernetes 통합:
- 새 코드가 커밋될 때, Kubernetes 클러스터에 자동 배포.
- QA 과정에서 Pod 상태, 로그, 성능을 자동으로 검증.
-
QA 작업에서 Kubernetes의 활용
- 컨테이너 기반 테스트: 각각의 테스트 케이스를 별도의 Pod로 실행.
- 네트워크 시뮬레이션: Kube-proxy를 활용하여 네트워크 장애를 시뮬레이션.
- 로깅과 모니터링: Prometheus/Grafana로 Pod 및 클러스터 상태를 시각화.