1. 쿠버네티스

1.1. 컨테이너 관리의 어려움

• 수동 배포 및 확장 어려움: 수십, 수백 개의 컨테이너 → 일일이 수동으로 배포 · 확장하기가 번거롭고 오류 발생 쉬움. 장애 발생 시 복구도 어려움
• 리소스 관리 비효율: 여러 서버에 컨테이너가 분산되어 실행 → 각 컨테이너에 필요한 리소스(CPU, 메모리 등) 효유렂ㄱ으로 할당하고 관리하기 어려움
• 네트워킹 복잡함: 컨테이너 간 통신을 설정하고 관리하기가 복잡함. 컨테이너의 IP주소가 동적으로 변경 → 서비스 디스커버리 및 로드 밸런싱을 위한 추가적인 솔루션 필요
• 모니터링 및 로깅 어려움 : 분산된 컨테이너 환경 모니터링 · 로깅이 어려움 → 각 컨테이너 상태를 추적하고 문제 진단에 중앙 집중식 모니터링 · 로깅 시스템 필요
• 업데이트 및 로깅 어려움 : 애플리케이션 업데이트 · 이전 버전 롤백 → 다운타임 없이 수행하기 어려울 수 있음

위와 같은 어려움을 해결하고자 쿠버네티스(Kubernetes등장

1.2. 컨테이너 오케스트레이션

1.2.1. 오케스트레이션 (Orchestration)

• 본래 음악에서 여러 악기를 조화롭게 연주하도록 지휘하는 것.

→ 컨테이너화된 애플리케이션의 배포, 관리, 확장, 네트워킹 등을 자동화

1.2.2. 컨테이너 오케스트레이션 도구의 기능

• 컨테이너 배포/관리: 클러스터 내 서버에 컨테이커를 자동으로 배포/관리
• 자동 확장/축소: 트래픽 변화에 따라 컨테이너 수를 자동으로 늘리거나 줄임
• 로드 밸런싱: 트래픽을 여러 컨테이너에 분산 → 서비스 가용성 높임
• 자체 복구: 컨테이너가 실패하는 경우 자동으로 재시작/교체
• 롤링 업데이트/롤백: 다운타임 없이 애플리케이션 업데이트/이전 버전으로 롤백
• 서비스 디스커버리: 컨테이너 간 통신을 위해 서비스 이름을 사용 → 컨테이너 IP 주소 자동으로 찾음
• 리소스 관리: 컨테이너에 필요한 리소스 할당/관리

→ 쿠버네티스 는 이러한 컨테이너 오케스트레이션 기능을 제공 → 컨테이너 환경을 효율적으로 관리하고 운영할 수 있도록 지원

1.3. 쿠버네티스 주요 기능/장점

현대적인 애플리케이션 개발/운영에 필수적인 도구로 자리잡음.

• 자동화된 배포/롤아웃: 다운타임 없이 애플리케이션 업데이트, 문제 발생 시 롤백 간편
• 자체 복구(Self-Healing): 쿠버네티스는 컨테이너의 상태를 지속적으로 모니터링, 실패한 컨테이너를 자동으로 재시작/교체. → 애플리케이션의 가용성을 높이고 장애 발생 시 빠르게 복구
• 자동 스케일링: 트래픽 변화에 따라 자동으로 컨테이너의 수를 늘리거나 줄임. → 리소스를 효율적으로 사용하고 애플리케이션의 성능을 유지
• 로드밸런싱: 트래픽을 여러 컨테이너에 분산 → 서비스 가용성 높임.
  • 내부 로드 밸런싱: 클러스터 내부의 트래픽 효율적으로 관리
  • 외부 로드 밸런서 연동: 외부 트래픽 처리
• 서비스 디스커버리: 컨테이너 간 통신을 위해 서비스 이름을 사용하여 컨테이너의 IP주소를 자동으로 찾음 → 애플리케이션 개발자는 컨테이너 위치에 신경쓰지 않고 서비스를 개발할 수 있음
• 스토리지 오케스트레이션: 다양한 스토리지 솔루션과 연동 → 컨테이너에 필요한 스토리지를 프로비저닝하고 관리.
  • 퍼시스턴트 볼륨 Persistent Volume: 컨테이너가 재시작 되더라도 데이터를 유지
• 구성 관리: 애플리케이션 설정을 외부화하여 관리
• 확장성
  • 다양한 플러그인 → 기능 확장.
  • 사용자 정의 리소스 정의 → 쿠버네티스 API 확장/새로운 기능 추가
• 이식성: 다양한 환경 (온프레미스, 클라우드, 하이브리드)에서 실행 → 특정 환경 종속 X. 유연하게 배포

2. 쿠버네티스 아키텍처

쿠버네티스는 분산 시스템. 여러 개의 서버가 협력하여 컨테이너화된 애플리케이션 관리/실행. 쿠버네티스 클러스터는 크게 마스터 노드 Master Node 와 워커 노드 Worker Node로 구성됨. 두 종류의 노드가 협력하여 애플리케이션을 안정적으로 실행/관리하는 핵심 역할 수행. 쿠버네티스를 움직이는 두 개의 엔진이라고 볼 수 있음.

2.1. 마스터 노드 Master Node

• 클러스터 전체를 관리하고 제어하는 역할.
• 클러스터의 상태를 모니터링 / 워커 노드에 작업 할당 / 애플리케이션의 배포, 확장, 업데이트 등을 조정
• 일반적으로 고가용성을 위해 여러 개의 마스터 노드를 구성
• 각 구성 요소는 서로 협력하여 클러스터의 안정적인 운영을 보장.

2.1.1. 마스터 노드 구성 요소: API 서버, 스케줄러, 컨트롤러 매니저 (컨트롤 타워)

2.1.1.1. API 서버 : 모든 요청을 처리

• 쿠버네티스 API를 제공하는 핵심 구성 요소
• 모든 요청은 API 서버를 통해 처리
• 클러스터의 상태를 조회하고 변경하는데 사용
• kubectl CLI 같은 외부 도구 뿐만 아니라, 다른 마스터 노드 구성 요소들도 API 서버를 통해 서로 통신
• API 서버는 인증, 인가, 감사를 수행하여 클러스터의 보안을 유지

2.1.1.2. 스케줄러 (kube-scheduler) : Pod를 적절한 노드에 할당

• 새로 생성된 Pod(컨테이너 그룹)을 어떤 워커 노드에 할당할지 결정하는 역할
• 각 워커 노드의 리소스 사용량, 하드웨어 제약 조건, 정책 등을 고려하여 최적의 노드를 선택
• 스케줄링 정책은 사용자가 정의 가능 → 특정 워크로드를 특정 노드에 배치하거나, 리소스 사용량을 최적화

2.1.1.3. 컨트롤러 매니저(kube-controller-manager) : 클러스터의 상태를 지속적으로 관리

• 클러스터의 상태를 지속적으로 모니터링 / 사용자가 정의한 목표 상태를 유지하기 위해 필요한 작업을 수행
  • 예시 컨트롤러 ReplicaSet 는 지정된 개수의 Pod가 항상 실행되도록 유지, Node 컨트롤러는 노드의 상태를 모니터링, 노드가 다운되면 자동으로 다른 노드로 Pod를 재배치.
• 컨트롤러 매니저는 다양한 컨트롤러를 포함, 각 컨트롤러는 특정 리소스의 상태를 관리

2.2. 워커 노드 Worker Node

• 마스터 노드의 지시에 따라 실제로 컨테이너를 실행하는 역할
• 애플리케이션의 실행 환경 제공 / 마스터 노드와 통신하여 자신의 상태를 보고 / 필요한 작업을 요청
• 클러스터의 규모에 따라 여러 개의 워커 노드를 구성 가능

2.2.1. kubelet : API 서버와 통신하여 Pod 실팽

• 각 워커 노드에서 실행되는 에이전트
• API 서버와 통신하여 자신이 속한 노드에 할당된 Pod를 실행하고 관리
• 컨테이너의 상태를 모니터링 → 문제가 발생하면 마스터 노드에 보고
• 컨테이너 로그 수집
• 컨테이너에 필요한 볼륨 마운트

2.2.2. kube-proxy : 네트워크 트래픽 관리

• 각 워커 노드에서 실행되는 네트워크 프록시
• 쿠버네티스 서비스를 구현
• 클러스터 내부 및 외부 트래픽을 적절한 Pod로 라우팅
• iptables, ipvs, eBPF 같은 기술을 사용하여 트래픽 관리
• 로드 밸런싱, 서비스 디스커버리 등의 기능 제공

2.2.3. 컨테이너 런타임 Container Runtime : 실제로 컨테이너 실행

• 실제로 컨테이너를 실행하는 소프트웨어.
  • Docker, containerd, CRI-O 등

3. 쿠버네티스 핵심 개념

3.1 파드 Pod : 쿠버네티스 기본 단위, 컨테이너 묶음

예시 파드. 내부에서 웹 서버 컨테이너와 로그 수집 컨테이너가 함께 실행되고 있으며, 동일한 localhost를 통해 서로 통신, 공유 볼륨을 사용해서 데이터를 공유하고 있음.

• 쿠버네티스에서 배포 및 관리의 기본 단위
• 하나 이상의 컨테이너를 묶어서 함께 실행되는 논리적인 그룹
• 동일한 네트워크 네임스페이스, 스토리지 볼륨을 공유
• 서로 localhost를 통해 통신

3.1.1 파드 Pod의 특징

• 컨테이너 묶음: 하나 이상의 컨테이너를 포함할 수 있음.
  • 일반적으로 하나의 파드에는 밀접하게 관련된 컨테이너들이 함께 실행
  • 예시 웹 서버 컨테이너 + 로그 수집 컨테이너 = 하나의 파드로 묶을 수 있음
• 공유 네임 스페이스: 파드 내의 컨테이너들은 동일한 네트워크 네임스페이스 공유 → 동일한 IP주소와 포트 공간 사용
  • localhost를 통해 서로 통신 가능
• 공유 스토리지: 파드 내의 컨테이너들은 하나 이상의 볼륨을 공유할 수 있음
  • 볼륨은 데이터 저장/공유에 사용
  • 컨테이너가 재시작되더라도 데이터 유지
• 임시적인 존재: 파드는 임시적인 존재임.
  • 파드가 실패/삭제 → 쿠버네티스는 자동으로 새로운 파드를 생성하여 대체
  • 따라서 파드에 직접 데이터를 저장하는 것은 권장 X
  • 데이터를 유지하기 위해서는 볼륨을 사용해야 함

3.2. 서비스 (Service) : 파드를 연결하는 다리 (외부 노출 및 로드밸런싱)

예시 서비스. 클라이언트는 서비스의 IP주소로 접근, 서비스는 로드 밸런싱을 통해 트래픽을 여러 파드에 분산시킴.

• 파드에 접근하기 위한 추상화된 방법
• 서비스는 파드의 IP 주소와 포트를 추상화 → 고정된 IP 주소와 DNS 이름을 제공 → 파드에 안정적으로 접근할 수 있도록 해줌
• 로드밸런싱 기능 제공 → 트래픽을 여러 파드에 분산시켜 애플리케이션의 가용성을 높임

3.2.1. 서비스의 특징

• 고정 IP 주소 및 DNS 이름: 파드의 IP주소와 상관없이 고정된 IP 주소와 DNS 이름을 제공함
  • 파드가 재시작되거나 교체되더라도, 서비스의 IP주소와 DNS 이름은 변경되지 않음 → 애플리케이션은 안정적으로 서비스를 사용할 수 있음
• 로드 밸런싱; 서비스는 트래픽을 여러 파드에 분산시켜 애플리케이션의 가용성을 높임
  • 다양한 로드밸런싱 알고리즘 지원
  • 사용자는 필요에 따라 적절한 알고리즘을 선택 할 수 있음
• 서비스 디스커버리: 클러스터 내의 다른 애플리케이션이 서비스를 쉽게 찾을 수 있도록 해줌
  • 쿠버네티스는 DNS 서비스를 제공 → 서비스 이름을 IP 주소로 변환해줌

3.3. 디플로이먼트 (Deployment) : 파드 관리 및 배포 자동화 (무중단 배포)

예시. 애플리케이션의 목표 상태를 정의 → ReplicaSet는 디플로이먼트의 지시에 따라 파드를 관리함.

• 파드와 ReplicaSet를 관리하는 상위 수준의 리소스.
• 애플리케이션의 배포/업데이트/롤백 등을 자동화
• ReplicaSet를 통해 지정된 개수의 파드를 항상 실행되도록 유지, 롤링 업데이트 기능으로 다운타임 없이 애플리케이션을 업데이트

3.3.1. 주요 기능

• 선언적 업데이트: 애플리케이션의 목표 상태를 선언적으로 정의.
  • 쿠버네티스는 사용자가 정의한 목표 상태를 달성하기 위해 필요한 작업을 자동으로 수행
• 롤링 업데이트: 다운타임 없이 애플리케이션을 업데이트. 새로운 버전의 파드를 점진적으로 배포하고, 기존 버전의 파드를 점진적으로 제거하는 방식으로 진행.
• 롤백: 애플리케이션 업데이트에 실패했을 때 이전 버전으로 쉽게 롤백
• 확장: ReplicaSet 수정으로 파드의 수를 늘리거나 줄임

3.4. 리소스 관리의 핵심 도구 : 네임스페이스, 레이블, 셀렉터

쿠버네티스는 대규모 클러스터를 효율적으로 관리하기 위한 다양한 리소스 관리 도구를 제공함.

3.4.1. 네임스페이스

• 쿠버네티스 클러스터 내에서 리소스를 논리적으로 분리하는 데 사용
• 여러 팀 또는 프로젝트가 동일한 클러스터를 공유하면서도 서로의 리소스에 영향을 주지 않고 독립적으로 작업이 가능함
  • 예시 : 개발 환경, 테스트 환경, 운영 환경을 각각 다른 네임스페이스로 분리

3.4.2. 레이블

• 쿠버네티스 리소스에 임의의 키-값 쌍을 추가하는데 사용됨
• 리소스를 분류하고 검색하는 데 용이
  • 예시 : 파드에 app=my-app, version=1.0 같은 레이블을 추가

3.4.3. 셀렉터

• 레이블을 기반으로 리소스를 선택하는데 사용
• 특정 레이블을 가진 리소스를 필터링할 수 있음
  • 예시 : app=my-app 이라는 레이블을 가진 파드를 선택하는 셀렉터를 정의할 수 있음

위와 같은 도구들을 사용하면 아래와 같은 작업이 가능함.

• 특정 네임 스페이스에 속하는 모든 파드 선택
• 특정 레이블을 가진 서비스에 트래픽을 라우팅