01 쿠버네티스

1. Note

1. Note

• 구분
  • 마스터노드는 워커노드의 설정과 전체 흐름에 관여하는 노드
  • 워커노드는 실제 AP와 AP와 관련된것이 올라가는 노드
• 전체적인 흐름
  • 마스터노드를 설정하고
  • 워커노드에서 마스터노드에 붙이는 느낌
  • 그러면 마스터노드에서 설정한 것을 바탕으로 워커노드가 생성 및 관리됨.
• 전체적으로
  • 모든 작업에 있어서는 쿠버네티스 설치는 필요하고,
  • 이 전체를 구성하는 쿠버네티스는 존재 X
  • 개념적으로 전체 쿠버네티스가 존재하고,
  • 마스터노드에 워커노드를 붙이면, 전체 쿠버네티스처럼 보이게됨.

2. 쿠버네티스

1. 쿠버네티스 정의

• 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리해주는 오케스트레이션 플랫폼
  • 여러 서버(노드)에 컨테이너를 자동 배치
  • 장애 발생 시 자동 복구
  • 트래픽 증가 시 자동 확장(스케일 아웃)
• 컨테이너(Docker 등)를 운영 환경에서 효율적으로 관리해주는 시스템

2. 쿠버네티스 배경

1. 기존 서버 운영 방식의 한계

• 과거에는 애플리케이션을 물리 서버에 직접 배포 또는 VM(가상 머신) 기반 운영
  • 서버 자원 활용이 비효율적 (낭비 발생)
  • 배포 과정이 수동적이고 복잡함
  • 장애 발생 시 대응이 느림
  • 트래픽 증가 시 확장이 어려움
• 운영이 “사람 손에 너무 많이 의존”하는 구조

2. 컨테이너 기술의 등장

• Docker 같은 컨테이너 기술이 등장함.
  • 애플리케이션 + 실행 환경을 하나로 패키징
  • 어디서든 동일하게 실행 가능
  • VM보다 가볍고 빠름
  • 배포 속도 향상
• 개발과 배포가 훨씬 쉬워짐

3. 새로운 문제 발생

• 운영 복잡도 증가
• 컨테이너 수가 폭발적으로 증가
• 여러 서버(클러스터)에 분산 실행
• 컨테이너 IP가 계속 변경됨
• 장애/확장/배포를 수동으로 관리 불가능

3. 쿠버네티스 특징

• 자동 배포 (Deployment)
  • 애플리케이션을 원하는 상태로 정의해두면, 쿠버네티스가 그 상태를 유지하면서 자동으로 배포
    • 예시) “Pod 3개를 항상 유지”
    • 기존 방식처럼 서버에 직접 접속해서 배포할 필요 없음
    • 업데이트 시에도 중단 없이 순차적으로 반영 가능
  • 결과적으로 배포 작업을 자동화하고 안정성을 높입니다.
• 자동 확장 (Auto Scaling)
  • 트래픽 변화에 따라 애플리케이션이 자동으로 확장되거나 축소
    • CPU 사용량이 증가하면 Pod 수 증가
    • 트래픽이 줄면 Pod 수 감소
    • 필요 시 노드 자체도 자동으로 추가 가능
  • 비용 효율성과 성능을 동시에 확보할 수 있음
• 자가 치유 (Self-healing)
  • 실행 중인 컨테이너에 문제가 생기면 자동으로 복구
    • 컨테이너가 죽으면 자동 재시작
    • 응답이 없는 Pod는 제거 후 재생성
    • 장애가 발생해도 서비스가 유지됨
  • 운영자가 직접 개입하지 않아도 시스템이 스스로 복구
• 서비스 디스커버리 & 로드밸런싱
  • Pod는 계속 생성/삭제되며 IP도 바뀌지만, 쿠버네티스는 이를 추상화해서 안정적인 접근을 제공
    • 서비스 이름으로 Pod 접근 가능 (DNS 기반)
    • 여러 Pod로 트래픽 자동 분산
    • 특정 Pod에 장애가 있어도 다른 Pod로 자동 전환
  • 사용자 입장에서는 항상 하나의 안정된 서비스처럼 보임
• 선언형 관리 (Declarative Configuration)
  • “어떻게 만들지”가 아니라 “어떤 상태로 유지할지”를 정의
    • YAML 파일로 상태 정의
    • 쿠버네티스가 지속적으로 실제 상태와 비교
    • 차이가 있으면 자동으로 맞춤
  • 인프라를 코드처럼 관리할 수 있어 재현성과 안정성이 높아짐
• 롤링 업데이트 & 롤백
  • 서비스를 중단하지 않고 새로운 버전으로 안전하게 교체함
    • 일부 Pod씩 순차적으로 업데이트
    • 문제가 없으면 전체 반영
    • 문제가 생기면 즉시 이전 버전으로 복구
  • 무중단 배포와 안정적인 버전 관리가 가능함.

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

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

• 컨테이너들을 자동으로 “배치하고, 연결하고, 관리하는 것”

2. 역할

1. 배치 (Scheduling)

• 컨테이너를 “어느 서버에서 실행할지” 자동으로 결정하는 역할
  • 서버마다 CPU, 메모리 상황이 다름
  • 오케스트레이션이 이를 실시간으로 판단
  • 가장 적절한 노드에 컨테이너를 배치

• 상황

   - A 서버가 과부하되면 다른 서버로 자동 배치
   - 특정 서버는 GPU 필요하면 해당 서버에만 배치
    
   # 결과적으로 자원을 효율적으로 사용하게 됨  
  

2. 실행 관리 (Lifecycle Management)

• 컨테이너의 생명주기를 전체적으로 관리
  • 컨테이너 시작 (Start)
  • 정상 종료 (Stop)
  • 비정상 종료 감지
  • 자동 재시작
• 포인트
  • 장애가 발생하면 사람이 개입하기 전에 자동 복구
  • “항상 살아있는 상태를 유지”하는 것이 목표

3. 확장 관리 (Scaling)

• 트래픽 변화에 따라 컨테이너 수를 자동으로 조절
  • 요청 증가 → 컨테이너 수 증가 (Scale-out)
  • 요청 감소 → 컨테이너 수 감소 (Scale-in)
• 그외 확인 포인트
  • CPU 사용률, 메모리 사용률 같은 지표 기반으로 판단
  • 특정 시간대 트래픽 패턴도 대응 가능
  • 성능과 비용을 동시에 최적화

4. 서비스 연결 (Service Discovery & Networking)

• 컨테이너는 생성될 때마다 IP가 바뀌므로 오케스트레이션이 처리함.
  • 컨테이너 간 자동 연결
  • 서비스 이름 기반 접근 (DNS)
  • 로드밸런싱 적용

• 예시

   “user-service”라는 이름으로 접근하면
    - 내부에서 살아있는 컨테이너로 자동 연결
    - 사용자는 고정된 주소처럼 안정적으로 접근 가능
  

5. 상태 유지 (Desired State Reconciliation)

• 사용자가 원하는 상태를 정의하면 유지해줌

• 예시

   # 상태 설정
    - 컨테이너 3개 유지
    - 항상 최신 버전 실행
    
   # 작업
    - 부족하면 생성
    - 많으면 제거
    - 문제 있으면 교체
  

4. 쿠버네티스 구성요소

1. 주요 구성요소

• 마스터 노드는 클러스터의 전체적인 관리 및 조정을 담당하며, 클러스터의 상태를 중앙에서 제어
• 워커 노드는 실제 컴퓨팅 작업을 수행하며, 애플리케이션 컨테이너의 실행을 담당

2. MasterNode

1. API 서버 (kube-apiserver)

• 클러스터와의 모든 통신이 이루어지는 허브
• 사용자 명령을 받아 처리하고, 해당 결과를 클라이언트에 반환함

2. 클러스터 스토어 (etcd)

• 모든 클러스터 데이터를 저장하는 경량, 분산형 키-값 저장소
• 클러스터의 상태 정보, 설정, 메타데이터 등을 저장함

3. 컨트롤러 매니저 (kube-controller-manager)

• 다양한 컨트롤러를 실행
• 이 컨트롤러들은 오브젝트의 상태를 감시하고, 필요한 경우 적절한 변경을 수행하여 원하는 상태를 유지
• 예를 들어, 레플리케이션 컨트롤러는 지정된 수의 파드 복제본이 항상 실행되도록 보장함

4. 스케줄러 (kube-scheduler)

• 새로 생성된 파드를 대상 노드에 할당함
• 파드 요구 사항과 노드의 리소스 가용성을 고려하여 최적의 노드를 선택함

3. WorkNode

1. kubelet

• 각 노드에서 실행되는 주요 에이전트로, 마스터 노드의 지시를 받아 컨테이너의 실행 및 관리를 담당
• 파드 사양에 정의된 대로 컨테이너가 올바르게 실행되고 있는지 모니터링

2. 컨테이너 런타임

• 컨테이너 실행을 위한 환경을 제공
• Docker, containerd, CRI-O 등 다양한 컨테이너 런타임을 지원

3. kube-proxy

• 네트워크 프록시로서, 워커 노드의 네트워크 규칙을 관리하고, IP 주소나 포트 번호를 사용하여 클라이언트의 요청을 파드로 전달
• 서비스 추상화를 제공하여 외부에서 파드의 네트워크 서비스에 접근할 수 있도록함.