처음 시작하는 마이크로서비스 + 헬름 배우기 : 쿠버네티스 정리

 

Microservices Up & Running (처음 시작하는 마이크로서비스)

(필요한 부분 먼저 읽고 요약 진행합니다. 전체적으로 실습 코드 위주의 도서라 개념 정리가 필요한 분들에게는 추천하지 않습니다.)

Learn Helm

(교보문고에서 슬쩍 읽고 구매했는데 더 좋은 책이 있으리라 믿습니다.. 번역 별로..)

 

7.1.1 Network (AWS 네트워크 관련 공식 문서)

 가용영역 (Availability zone): 별도의 분리된 데이터 센터

 VPC (Virtual Private Cloud): AWS 가상 네트워크의 상위 객체

 VPC는 여러 개의 작은 네트워크인 서브넷으로 나뉠 수 있다. 서브넷은 네트워크 트래픽을 구성하고 리소스에 대한 엑세스를 제어한다 (VPC의 ip 주소 범위 결정).

 예를 들어, 사설 서브넷(private subnet)을 통해 VPC내부의 트래픽만 허용하는 등 routing 및 보안과 관련된 설정을 할 수 있다.

(+ CIDR(사이더): 네트워크나 서브넷에서 허용하는 축약형 문자열. 예를들어 CIDR값이 10.0.0.0/16이면 VPC내에서 10.0.0.0에서 10.0.255.255사이의 모든 IP주소를 바인딩할 수 있음을 의미한다. AWS에서 각 서브넷 별로 지정한다.)

 Gateway: 네트워크를 다른 네트워크에 연결

 

7.1.2 Kubernetes

 이 전의 어플리케이션은 하나로만 구성되었다면, 현대의 어플리케이션은 여러 개의 작은 어플리케이션으로 구성되며,  각 어플리케이션은 자체적으로 개별 서비스를 할 수 있다.  처음에는 각 어플리케이션을 하나로 묶어 배포했는데 (모놀리식) 이렇게 하면 하나에 변경이 필요할 때마다 모든 하위 어플리케이션을 다 확인해야하는 등의 번거로움이 발생했기 때문에 각 어플리케이션을 독립적으로/ 동시에 개발 및 배포할 수 있는 방식이 발전하기 시작했다 (마이크로서비스).

 마이크로서비스가 각광받으면서 격리된 시스템 구성을 통해 예측 가능성을 구현하고 독립성을 보장하는 컨테이너 기술이 널리 채택되기 시작했고, 2010년대 중반, 도커는 컨테이너의 대중화에 일조하면서 그 인기를 상승시키는데 일조했다.

 하지만 어플리케이션이 점점 더 커지고 컨테이너화된 마이크로서비스가 더 많이 배포되면서 컨테이너 관리에 대한 어려움이 생기기 시작했다.

• 지금 컨테이너들이 안 죽고 잘 실행되고 있는지 어떻게 (계속) 보장할 것인가?
• 컨테이너에 장애가 생긴 경우 어떻게 조치할 것인가?
• 컴퓨팅 용량이 부족한 경우 어떻게 할 것인가?

 즉, Production 환경에서 컨테이너를 사용하기 위해서는 컨테이너가 자동으로 시작하고, 확장하고, 문제가 발생했을 때 복구하게 해야하는 요구사항이 생겨난 것이다. 또한, 수많은 컨테이너를 한번에 rollback하거나 rollout할 수 있어야했다.

 따라서 수많은 컨테이너들을 "논리적인 단위"로 "한번에" 관리하기 위해 나타난 것이 컨테이너 오케이스트레이션 툴들이고, 그 중 하나가 쿠버네티스이다.

 쿠버네티스는 컨테이너 기반 application을 배포, 확장, 관찰, 관리함으로써 대규모 컨테이너 작업에 대한 위의 requirements를 해결한다. - 구체적으로 다음과 같은 기능을 수행할 수 있다. -> 다음 기능을 자동으로 한다는 거 같음

1.  컨테이너 배포를 rollout(출시) & rollback(이전 버전으로 복구)할 수 있음
2.  수요 패턴에 따라 컨테이너를 배포하거나 제거할 수 있음
3.  Storage system mount (노드별로 volume mount가 필요한 경우), Secret 관리, Load balancing, Traffic 관리 등을 처리한다.

쿠버네티스는 다음으로 구성된다.

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

• 클러스터: 쿠버네티스 시스템의 상위 객체. 컨트롤 플레인과 노드를 포함한다.
• 컨트롤 플레인: 클러스터의 두뇌 역할을 한다. 컨테이너의 시작 및 중지, 레플리카 관리에 대한 결정을 내림으로써 시스템을 관리한다. 또한 클러스터를 관리할 수 있는 API를 제공한다.
  • API서버: 컨트롤 플레인의 프론트 엔드
  • etcd: 클러스터의 데이터 저장
  • scheduler: 노드가 배정되지 않은 새로 생성된 파드 감지, 실행할 노드 선택
  • controller-manager:
    • 노드가 다운되었을 때 통지 및 대응(노드 컨트롤러)
    • 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드 유지(레플리케이션 컨트롤러)
    • 서비스-API 엔드포인트-와 파드 연결(엔드포인트 오브젝트)
    • 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰 생성(서비스 어카운트 & 토큰 컨트롤러)
  •  cloud controller manager: 클라우드 플랫폼과 상호작용
• 노드: 컨테이너 기반 워크로드를 실행하는 물리 또는 가상 머신이다. 파드를 실행하고, 각 파드는 하나 이상의 컨테이너를 포함한다.
  • kubelet: 파드에서 컨테이너가 동작하도록 관리
  • kube proxy: 각 노드에서 실행되는 네트워크 프록시 (서비스의 구현체)
  • container runtime: 컨테이너 실행 담당 (containerd, CRI-O 등 컨테이너 런타임 인터페이스 구현체 지원)

 

 쿠버네티스가 컨테이너화된 워크로드를 관리하는데 도움이 되는 이유는 다음과 같은 기능을 수행하기 때문이다.

• 컨테이너 오케스트레이션: 가지고 있는 리소스 풀에서 특정 머신에 컨테이너를 배치하는 것이다. 
  예를 들면, 2Gi의 메모리와 1CPU 코어를 요청하는 애플리케이션이 있을 경우, 어떤 노드에 필요한 리소스가 있는 지 추적하고 해당 노드에 컨테이너를 배치한다. 클러스터를 구성하는 모든 노드에 워크로드를 실행하기 위한 리소스가 충분하지 않은 경우 ㅋ컨테이너는 배포되지 않는다.
• 고가용성(High availability): 프로그램의 다운타임(서비스 중단 시간)을 방지한다. 로드 밸런서에 의해 수행되며, 들어오는 트래픽을 애플리케이션의 여러 인스턴스로 분할한다 (-> 앱을 복사하는 이유?) . 쿠버네티스의 네트워킹 메커니즘을 서비스라고하며 이를 통해 로드 밸런싱을 지원한다.
• 확장성
  • 수평확장: 더 많은 컨테이너 인스턴스를 배포
    부하 증가가 예상되는 경우 더 많은 어플리케이션 인스턴스를 배포하도록 지시할 수 있고, 개발자는 해당 어플리케이션이 배포 될 물리 인프라에 대해 걱정할 필요가 없다 (쿠버네티스가 알아서 클러스터 내에 사용 가능한 리소스가 있는 노드를 찾아 추가 배포하기 때문)
  • 수직확장: 추가적인 메모리와 CPU를 어플리케이션에 할당
    어플리케이션이 실행되는 동안 리소스 요구사항을 수정할 수 있음. 실행 중인 인스턴스를 재배포하거나 리스케줄링 할 수 있으며, 새로운 인스턴스가 배포되는 동안 다운타인을 방지할 수 있다.

쿠버네티스의 작동방식은 굉장히 복잡하기 때문에, 쿠버네티스를 관리하기 위한 여러 매니지드 서비스들이 있다. 대표적으로 AWS에서 제공하는 EKS를 들 수 있다. EKS는 사용자 대신 클러스터를 프로비저닝(사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것)하고 관리형 서비스로 컨트롤 플레인을 제공한다. 따라서 사용자는 노드의 수와 유형을 구성하고 적절한 네트워크를 프로비저닝하면 된다.

 

 7.2.3 EKS를 위한 네트워크 구성

• EKS가 제대로 작동하려면 서로 다른 가용 영역에 서브넷이 정의되어야 한다. 그래야만 배포 시 데이터 센터 중 하나가 다운되더라도 다른 가용 영역에서 서비스가 중단 없이 작동될 수 있기 때문이다.
• 각 가용영역은 하나의 공개 서브넷과 하나의 사설 서브넷이 있는 VPC로 구성된다. 공개 서브넷은 인터넷 트래픽을 허용하고, 사설 서브넷은 VPC 내부의 트래픽만 허용한다.
• 공개 서브넷에는 로드 밸런서를 배포하여 인바운드 트래픽을 관리하고, 로드 밸런서를 통과한 트래픽은 사설 서브넷에 있는 컨테이너로 라우팅된다.
• 인터넷 게이트웨이를 통해 인터넷이 공개 서브넷에 접근할 수 있도록 하고 트래픽을 처리한다.
• NAT 게이트웨이를 통해 사설 서브넷에서 공개 서브넷에 배포한 인터넷 게이트웨이와 통신하도록 한다. 이는 쿠버네티스 파드가 EKS 서비스와 통신할 수 있도록 하기 위함이다. NAT에는 EIP(Elastic IP)라는 실제 IP주소가 할당되기 때문에 리전당 생성할 수 있는 NAT의 개수는 5개로 제한된다.

출처: https://awskrug.github.io/eks-workshop/introduction/eks/eks_high_architecture/