쿠버네티스와 컨테이너 오케스트레이션 정리

1. 쿠버네티스(Lubernetes, k8s)

 1-1. 쿠버네티스란?

• 컨테이너 오케스트레이션 (plan and organize) 도구
• 행성 규모의 확장성
  • 컨테이너가 수백개일 경우에 유용함
• 클라우드 사업자에 종속되지 않은 사설 클라우드 인프라 우녕ㅇ
• MLOps에서 대중적으로 사용

 

• 오픈소스로 만들어진 컨테이너 오케스트레이션 도구
• 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공
  • 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응 가능

 1-2. 쿠버네티스의 목적

• 소프트웨어를 안정적으로 운영하기 위해 다음을 제공한다
  • 잘 만들어진 API
  • 자체 복구
  • 다운타임 없는 롤 아웃 기능 
    • (roll out : 이전버전을 새 버전으로 배포하는 것)

 1-3. 쿠버네티스의 핵심

• 컨테이너를 오케스트레이션 하는것
• 파드 장애시 자동 복구하거나, 복제하거나 하는 등의 일을 자동으로 처리하는 것에 포커스되있음
• 파드는 디플로이먼트, 스테이트풀셋, 데몬셋을 이용해 관리하는 것이 바람직함
• 컨테이너의 로드 밸런싱과 오토 스케일링과 같은 일을 담당한다 ( == AWS ECS )

 

2. 컨테이너 오케스트레이션(Container Orchestration)

컨테이너 오케스트레이션 도구는, 수십~수백개의 컨테이너를 관리하고자 할 때 사용함

단, 컨테이너가 적을 경우 docker-compose로 충분함

  2-1. 수십 ~ 수백개의 컨테이너가 존재하는 이유?

1. 모놀리식 -> 마이크로서비스로 인한 컨테이너 증가

2. 확장성을 위해 스케일링까지 더했을때 증가

(한팀당 5개의 마이크로서비스에 총 3팀, 듀블리카(복제본)을 2개싹 가지고 있을 때, 5x3x2 = 30개의 컨테이너가 존재)

 

  2-2. 어떻게 쿠버네티스를 사용하는가?

• 쿠버네티스를 이용해 온프레미스 상에서 (사설) 클라우드 인프라를 구성하고,
• 저렴한 클라우드 서비스의 일부분을 도입하여 하이브리드 형태로 구성하기도 하며,
• 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 마이그레이션 한다. (이식성)
  • 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원한다. 예) AWS EKS

 

3. 쿠버네티스 작동 원리

https://kubernetes.io/ko/docs/concepts/overview/components/

 3-1. 주요 개념

• 무엇을 배포할 것인가?
  • 파드
• 어떻게 노출할 것인가?
  • 서비스
• 어떻게 배포할 것인가?
  • 디플로이먼트
    • 롤링/블루-그린
    • 롤백
• 어떻게 운영할 것인가
  • Health Check
• Stateless 앱 배포를 염두하고 만들었지만, Stateful도 지원하기 위해서는?
  • 스테이트 풀셋
• 스토리지 관리?
  • 볼륨 (AWS EC2에서 쓴는 볼륨은? EBS)
  • 볼륨 동적 할당

 

 3-2. 파드란?

• 쿠버네티스의 배포 가능한 가장 작은 컴퓨팅 유닛
  • 하나 이상의 애플리케이션 컨테이너
  • IP주소
  • 불륨과 같은 공유 스토리지
• 애플리케이션이 파드 안에 들어가있다는 의미?
  • 애플리케이션을 이미지화 시켜서 도커로 띄우는 것처럼,
    파드라는 개념을 하나 더 만들어서 파드 안에 이미지를 정의하고,
    그 안에 컨테이너화된 앱이 실행될 수 있게 만든다
  • 파드 안에는 로컬호스트가 있어서, 각각의 파드에 IP가 존재한다 (별도의 독립된 IP를 가진다)
  • voulme : 데이터를 저장할 수 있는 공간
• 파드안에 컨테이너가 여러개가 들어갈 수 있다
• 보통은 파드안에 컨테이너가 한개가 들어간다 (파드안에 서로 다른 목적을 가진 컨테이너를 넣지 않는다)

 

 3-3. 디플로이먼트

• 다운타임 없는 롤 아웃 기능을 도와줌
• 디플로이먼트가 하는 일
  • 파드를 복제 (레플리카셋을 통해 이뤄짐)
    • 파드를 복제하는 이유? - 스케일아웃(수평확장)을 하기 위해서
      • 쿠버네티스 클러스터는 여러대의 컴퓨터를 거쳐 하나의 클러스터를 형성할 수 있다.
        그래서 하나의 클러스터를 생성해놓고 곳곳에 파드를 실행시키는데, 파드가 복제되면 실질적인 논리적인 컴퓨터가 여러대가 생긴다.(파드마다 하나의 로컬호스트를 가지고 있기 때문)
        따라서, 파드를 복제한다는 것은 스케일아웃을 한다는 의미
      • 디플로이먼트가 스케일아웃을 할 수 있게 만드는데, 레플리카셋을 통해서 복제를 한다
  • 버전 관리
  • 단계적 롤아웃(roll-out)

 3-4. 레플리카셋

• 수평 확장을 관장하는 리소스
• 디플로이먼트에 spec.replicas를 써주면, 알아서 레플리카셋이 만들어짐 (수동으로 안만들어도 됨)

https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset/

 

 3-5. 서비스

• 서비스의 종류
  • ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName
• 서비스가 하는 일
  • 클러스터 안에 파드는 각각 고유의 IP를 가지고 있지만, 직접 우리가 내부망에 접속할 수 없다
    그래서 파드에 접근할 수 있는 서비스를 하나 만든다
    서비스는 파드를 참조할 수 있도록 연결되고 외부로 연결할 수 있도록 통로를 열여준다
    그럼 서비스를 통해 파드로 접근할 수 있다.

 

4. minikube 설치

https://minikube.sigs.k8s.io/docs/start/

minikube start

미니큐브를 설치하면 kubucli을 사용할 수 있다

 

5. 업데이트는 2가지 종류가 있다

• 롤링업데이트
• Recreate(재생성)
  • 서비스 성능의 저하 없이 레플리카셋의 모든 파드를 중단할 수 있는 경우에 적합
  • 새로운 설정으로 새로운 레플리카셋을 생성하고, 새로운 파드가 온라인으로 전환되기 전에 이전 레플리카셋 삭제
    • 다운타임이 생길 수 있음

6. 블루/그린 및 카나리 배포를 할려면?

• 디플로이먼트를 새로 하나 만들어야 한다
• 블루/그린은 디플로이먼트에서 할 수 있는게 아니라, 서비스에서 해야한다 (트래픽 라우팅)

 

블루/그린 배포 시나리오 

서비스 --> 디플로이먼트 v1 -> 파드v1

 

서비스 -100%트래픽-> 디플로이먼트 v1 -> 파드v1

           -0%트래픽-> 디플로이먼트 v2 -> 파드v2

 

서비스 -0%트래픽-> 디플로이먼트 v1 -> 파드v1

           -100%트래픽-> 디플로이먼트 v2 -> 파드v2

 

카나리 배포 시나리오 (점진적인 트래픽 분산)

서비스 -90%트래픽-> 디플로이먼트 v1 -> 파드v1

           -10%트래픽-> 디플로이먼트 v2 -> 파드v2

 

서비스 -50%트래픽-> 디플로이먼트 v1 -> 파드v1

           -50%트래픽-> 디플로이먼트 v2 -> 파드v2

 

서비스 -20%트래픽-> 디플로이먼트 v1 -> 파드v1

           -80%트래픽-> 디플로이먼트 v2 -> 파드v2

 

서비스 -0%트래픽-> 디플로이먼트 v1 -> 파드v1

           -100%트래픽-> 디플로이먼트 v2 -> 파드v2