[Cloud] 컨테이너 오케스트레이션과 쿠버네티스 (1)

 

*본 포스트는 성신여자대학교 [클라우드 컴퓨팅] 강의 기반으로 작성됨을 알립니다.

 
 

목차

1. 컨테이너의 한계
2. 컨테이너 오케스트레이션
3. 쿠버네티스 개요 및 특징
4. 쿠버네티스의 오브젝트

---

 1️⃣컨테이너의 한계 (배포, 접근 및 노출, 장애 및 모니터링)

배포(deployment)의 문제점

1. 모든 서버에 직접 접속해서 하나하나 docker stop, run을 실행하는 것이 번거롭고 불편하다.
2. 도커 컨테이너 실행에 있어서 유휴 자원 관리나 모니터링 시스템이 필요하다. (배포 측면에서 불편)
3. 버전이 여러 개 있는 경우 다시 roll back을 하는 상황과 같이 신속한 장애 대처가 어렵다.

 

서비스 접근 및 노출의 문제점

컨테이너 환경에서 서비스에 접근하기 어려울 수 있다. 컨테이너는 가상화된 환경 안에서 실행되기 때문에 외부에서 접근하기 위해서는 네트워크 설정이나 포워딩과 같은 추가적인 작업이 필요하다.

 

서비스 장애, 부하 모니터링의 문제점

어떤 서비스에서 장애가 발생하였는지 신속하게 확인이 가능해야 되며, 로드가 한 쪽에 몰리는 것을 방지하기 위해서 모니터링 시스템으로 부하 분산과 같은 대처가 필요할 수 있다. → 하지만 도커 컨테이너로는 한계가 있다.

 

---

 2️⃣컨테이너 오케스트레이션

컨테이너 오케스트레이션이란?

→ 복잡한 컨테이너 환경을 한 번에 중앙에서 관리하고 자동화하기 위한 도구이다.

 

기능 (cluster, state, scheduling, rollout/rollback, service discovery, volume)

• Cluster
  • 중앙제어 : master와 같은 노드가 따로 있다.
  • 네트워킹 : cluster 내 컨테이너 간 네트워킹. 자동화가 될 수 있도록
  • 노드 스케일 : 컨테이너를 1,000배로 확장하여도 잘 작동이 되어야 한다,

Cluster - 중앙제어, 네트워킹, 노드스케일

• State
  • 상태 관리 : replica를 3개로 설정하였다고 가정하였을 때, 하나의 노드에서 장애가 발생하여도 자동으로 상태를 유지되도록 해주어야 한다.

state - 상태관리

• Scheduling
  • 배포 관리 : CPU 스케줄링과 같이 어느 서버에 app을 배치를 할 지 스케줄링을 할 지 결정하는 역할도 한다.

• Rollout & Rollback
  • Rollout : 최신의 버전 업데이트
  • Rollback : 거꾸로. 예전 버전으로 업데이트
• Service Discovery
  • 서비스 등록 및 조회 : 웹 서버가 확장되거나 축소될 때 동적으로 조정을 해주는 역할을 한다. (IP, port 번호 등 따로 수동적으로 조정할 필요가 없이, 알아서 해준다.)

• Volume
  • 불륨 스토리지 : 컨테이너가 데이터를 영구적으로 저장하고 관리하는 데 사용되는 저장소 (컨테이너가 종료가 되어도 영구적으로 보존이 가능하도록 컨테이너와 별도로 관리가 된다.)
  • NFS (Network File System), AWS EBS (Cloud Stroage), GCE PD

 

---

 3️⃣쿠버네티스 개요 및 특징

쿠버네티스 개요

• 컨테이너 오케스트레이션의 업계 표준이 "쿠버네티스"이다. 
  • 쿠버네티스(K8s) = 그리스어로 조타수, 캡틴 등을 의미한다.
  • 컨테이너 개수, CPU 사용률, 메모리 사용량이 설정 가능하며, 저장공간(불륨 스토리지), 네트워크 접근 제어, 로드밸런싱 기능을 설정할 수 있기 때문에 → "배포 계획에 맞춰서 신속하게 app 배포가 가능하다"
  • "가동 중"인 app을 동적으로 조정 가능
    • 요청이 많을 때는 처리량을 늘리기 위해 컨테이너 수를 늘려서 Scale-out
    • 요청이 적을 때는 컨테이너 수를 줄여 자원 점유율 및 요금을 줄이기 위해 Scale-in
  • 무정지 업그레이드 가능 & HW 가동률을 높여 자원 낭비를 줄인다.
• Scale-out vs. Scale-up

 

쿠버네티스의 특징

• 다양한 환경에서 쿠버네티스 사용 가능
  • 다양한 환경 => 퍼블릭, 프리이빗, 멀티, 하이브리드 클라우드, 온프레미스(=기업이 자체적으로 인프라 유지보수)
  • 일관된 인터페이스를 제공하여 인프라의 복잡성을 추상 (온프레미스, 클라우드 환경 둘 다 동일한 인터페이스)
  • Kubectl → 이 키워드로 쿠버네티스에서 대부분을 control한다.
• 높은 유연성과 확장성
  • MSA 최적합 → 느슨한 결합이니까 서버 교체, 정지, 추가, 제거가 용이 (즉, 독립적이여서 MSA 간 다른 걸로 변경해도 무상관)
  • 다양한 스펙(heterogenous)의 서버의 클러스터 구성 가능
  • 저장소나 로드밸런서의 동적 프로비저닝 (필요한 것들을 동적으로 마련되도록 할 수 있다)
  • 퍼블릭 클라우드 API와 연동이 가능한 점이 업계 표준이 될 수 있었던 점이다. (AWS, GCP, Azure 등 K8s 지원)
• 고가용성과 성능관리
  • 고가용성 : 서버 정지 시 재배포 자동화가 가능, 서버 종료 시 자동 재가동
  • 성능 관리 : 필요한 인스턴스 개수 유지, 높은 부하에서 자동 스케일 (부하 모니터링 하여 부하 분산)

 

---

 4️⃣쿠버네테스의 오브젝트

컨테이너, 파드, 서비스, 컨트롤러

 

컨테이너

• 컨테이너만을 독자적으로 실행하는 것은 불가능하고 반드시 파드 내에서 실행해야 한다.
• 파드 내에서 컨테이너를 실행하였다면 설정 가능한 것들
  • 이미지 이름 / 실행 명령어 / 실행 인자 / 환경 변수 / 불륨 / CPU 사용시간, 메모리 크기의 요청값 및 상한값

파드

• 파드란
  • 컨테이너를 실행하는 최소 단위이다. 파드 내에 한 개 이상의 컨테이너를 담을 수 있다.
  • 파드 내 컨테이너(들)은 같은 노드에서 실행이 된다.
• 파드의 특징 (재사용, 일시적, 상태관리, 초기화전용)
  • 컨테이너 재사용 촉진을 위한 플랫폼 (컨테이너 간 통신 및 공유를 통해 여러 자원을 재사용)
    • 파드 내부 컨테이너는 서로 IP 주소와 포트번호를 공유하고 localhost로 서로 통신이 가능하다.
    • 파드 내부 컨테이너는 파드의 볼륨을 마운트해서 파일 시스템 공유가 가능하다.
    • 파드 내부 컨테이너들은 "System V 프로세스 통신" 및 "POSIX 공유메모리"로 서로 통신
      • System V 프로세스 통신 : 리눅스 시스템에서 프로세스 간 통신을 위한 메커니즘 중 하나로 메시지 큐, 세마포어, 공유 메모리 등의 기능을 제공한다. 
      • POSIX 공유 메모리 : Protable OS interface로 POSIX 표준에 따라 공유 메모리를 사용하는 방법을 제공한다. 이를 통해 여러 프로세스가 메모리를 공유하고 데이터를 공유할 수 있다.
  • 파드는 일시적인 존재
    • 파드 내의 컨테이너는 이미지로부터 매번 생성되기 때문에 매번 초기 상태에서 시작
    • IP 주소는 파드 종료 시 회수 → 고정적이지 않다
    • 파드에 요청을 보내고 싶으면 서비스 오브젝트를 사용하면 된다.
  • 파드는 컨테이너 실행 상태를 관리
    • 파드가 정지? 당담 컨트롤러가 재기동
    • 파드 내 컨테이너가 정지? 파드가 정지 컨테이너 재시작
    • 활성상태인지 준비상태인지 프로브를 설정하여 app 상태 감시
      • 활성 프로브 : 멈춤 상태 감지? → 강제 종료
      • 준비 프로브 : 파드가 준비 안되면 서비스는 요청을 전송하지 않는다.
  • 파드는 초기화 전용 컨테이너를 실행
    • 초기화만을 담당하는 컨테이너 설정 가능 (1. 초기화 컨테이너 실행 2. 핵심 기능 컨테이너 실행)
    • 다른 오브젝트들과 같이 사용될 때 진가를 발휘한다.

서비스

• 파드와 클라이언트 연결하는 역할
• 서비스는 대표 IP주소를 가지고 있어서 요청 트래픽이 들어오면 여러 개의 서버 파드에 부하 분산 및 전송 역할을 한다. (로드밸런서)

컨트롤러

• 파드의 실행을 제어하는 오브젝트이다.
• 여러 종류의 컨트롤러가 있고 각 컨트롤러의 기능은 목적에 맞게 사용하면 된다.