Docker Containers Management on AWS

• Amazon Elastic Container Service (Amazon ECS) : Amazon의 container 플랫폼
• Amazon Elastic Kubernetes Service (Amazon EKS) : Amazon에서 관리되는 Kubernetes
• Amazon Fargate : Amazon의 서버리스 Container 플랫폼, ECS/EKS와 함께 동작 가능
• Amazon ECR : Container Image 저장
  
  
  

Amazon ECS

• AWS에서 docker container 실행 = ECS Cluster에서 ECS task 실행 (task = container, 생성된 task로 서비스를 배포하는 작업이 추가로 진행되어야 함 -> cluster에서 server 생성 후 맞는 type을 선택하고 Family로 사전 생성한 task를 선택하면 됨 -> 사전에 서비스 배포가 되었기 때문에 해당 task의 갯수가 늘어나면, container의 갯수도 늘어나게됨)
  
  
  

• ECS Cluster의 Launch Type (task 생성 시, 선택)

1. EC2 인스턴스
   • infra를 직접 provisioning하고 유지해야함
   • EC2 인스턴스는 각각 ECS Agent를 실행해야 함 -> ECS 클러스터 등록
   • ECS task가 실행되면 AWS가 container를 실행하거나 중단시킴 -> 새로운 Docker Container가 생성되면 임의로 ECS Cluster에 등록된 EC2 인스턴스를 선택하여 배포함

2. Fargate
   • AWS에서 docker container를 실행하는데, infra를 provisioning 하지않아서 관리할 EC2인스턴스는 없음 -> 서버리스 (서버를 관리하지 않아서)
   • ECS task 정의만 생성하면 필요한 CPU/RAM에 맞게 ECS task를 AWS가 대신 실행 (관리자는 어느 서버에서 실행되는지 모름)
   • 확장이 필요하면 ECS task만 더 생성하면 됨

• IAM Roles

1. EC2 인스턴스 profile
   • EC2 type에만 활용됨
   • ECS Agent만 EC2 인스턴스의 profile을 관리하고, 이를 활용하여 ECS API 호출 -> ECS 서비스가 CloudWatch log에 API 호출하여 Container log를 보냄 -> ECR로부터 docker image 수신
   • Secret Manager나 SSM Parameter Store에서 민감 데이터를 참고하기도 함
2. ECS Task Role
   • ECS task는 Task Role을 가짐
   • EC2 및 Fargate type에 모두 활용됨
   • 만약 두 개의 task가 있다면, 각각에 특정 Role을 만들 수 있음
   • ECS task role은 각자 다른 ECS 서비스를 이용할 수 있음 (ex. task A는 S3 API 호출, task B는 DynamoDB에 API 호출)
   • task를 정의하여 생성할 때, Role을 정의할 수 있음

• Load Balancer Integrations

1. EC2 및 Fargate type 모두 가능
2. ECS 클러스터 내부에 많은 ECS task가 실행됨
3. 많은 ECS task는 HTTP/HTTPS endpoint로 활용되길 원함 -> ALB 활용 -> 사용자는 ALB를 경유하여 ECS task에 연결될 수 있음
4. ALB대신 NLB가 사용될 수도 있는데, 해당 경우는 처리량이 많거나 높은 성능이 요구될 때 권장 (AWS Private Link와 사용할 때 권장)

• Data Volumes (EFS)

1. EC2 task에 File System을 마운트하여 데이터 공유 원함 -> EFS 활용
2. EFS는 EC2 및 Fargate 모두에 호환됨
3. EFS를 마운트한다면, 가용영역이 달라도 데이터를 공유할 수 있음 (EFS의 특징)
4. EFS를 활용하여 다른 task와도 연결 가능
5. EFS내부의 Fargate를 쓸 때 좋음 (EFS도 서버리스이기 때문)
6. Use case : Multi-AZ에 걸쳐 배포된 Container의 영구적인 Storage
7. Amazon S3는 ECS에 의해 마운트될 수 없음

ECS Auto Scaling

• ECS Auto Scaling : ECS task의 수를 자동으로 늘려주고 줄여줌
  
  
  

• Scaled Metrics

1. ECS의 CPU 사용률
2. ECS의 RAM 사용률
3. ALB의 target당 요청 수
   
   
   

• Scaling Types

1. Target Tracking : CloudWatch의 특정 값 기준
2. Step Scaling : CloudWatch의 특정 알람 기반
3. Scheduled Scaling : 트래픽의 변화가 예측되는 정해진 시간 기준
   
   
   

• ECS Auto Scaling (task level) != EC2 Auto Scaling (EC2 Instance level) -> EC2 Auto Scaling 기능이 없다면, Fargate로 전환 후 ECS Auto Scaling을 쓰는 것이 좋음 -> 서버리스
  
  
  

• EC2 Instance Auto Scaling 방법 (launch type이 EC2일 때)

1. EC2 Auto Scaling Group
2. ECS Cluster Capacity Provider : 새 task를 실행할 용량이 부족하면, 자동으로 ASG 확장 (with ASG, ECS Cluster CPU/RAM사용량 기반)
   
   
   

• Example : ECS Cluster Capacity Provider를 활용하는 Service의 트래픽이 증가할 경우, CloudWatch가 CPU사용량 증가를 인식하고 Alarm을 발생시킴 -> CloudWatch Alarm은 scale out 요청을 하게되고, Capacity Provider는 희망용량을 증가시켜 task가 자동으로 증가됨 -> task가 증가됨에 따라 EC2인스턴스가 증가됨

• Event Bridge에 의한 ECS
  : EventBridge는 수신된 Event를 전달하는 역할 -> Event를 받으면 ECS task를 실행시키기 위한 rule이 설정되어 있을 경우, ECS task 실행에 대한 요청을 ECS Cluster에 보냄 -> ECS task Role에 따라 처리

• Event Bridge Schedule에 의한 ECS
  : 1시간마다 스케줄링되는 EventBridge에 의해 특정 ECS Task가 실행됨 -> 생성되는 task Role에 맞는 작업 진행 -> 서버리스

• SQS Queue에 의한 ECS
  : 서비스가 SQS Queue로부터 메세지를 직접 가져와 처리

• Intercept StoppedTasks using EventBridge
  : EventBridge를 통한 ECS Cluster내에서 Event를 가로채는 방식 -> ECS Cluster내에서 task에 관한 Event가 발생될 경우, EventBridge에 트리거됨 (json형태의 데이터 전송) -> 해당 트리거를 이용하여 SNS topic에 메세지를 전송하고, 관리자에게 메일을 전송하는 등의 case에 활용될 수 있음

Amazon ECR

• Amazon ECR : Elastic Container Registry, AWS에 Docker image를 저장하고 관리하는데 사용
  
  
  

• 계정에 한해 image를 비공개로 저장 -> 여러 계정으로 권한 확대할 수 있음

• public으로 image를 저장할 수도 있음

• image는 background에서 S3에 저장됨

• ECS Cluster내 EC2 IAM Role을 통해 ECR로부터 Docker image를 가져올 수 있음 (ECR에 대한 모든 접근은 IAM이 보호)

• image의 단순 저장뿐만 아니라 image 취약점 스캐닝, versioning, tag 및 life cycle 확인 지원

Amazon EKS

• Amazon EKS : Elastic Kubernetes Service, AWS에서 kubernetes를 실행할 수 있는 service
  
  
  

• Amazon ECS와 비슷하지만, 사용하는 API가 다름

• EKS Launch Modes

1. EC2 Instance : EC2에 Worker Node 배포
2. Fargate : EKS Cluster에 서버리스 Container 배포
   
   
   

• 특징

1. kuberentes는 모든 Cloud에서 지원 (Azure, Google Cloud 등) -> 클라우드간 마이그레이션에 유용
2. Use Case : 회사가 온프레미스나 클라우드에서 Kubernetes or Kuberentes API를 사용중일 때, 해당 Kubernetes를 관리하기 위해 Amazon EKS를 활용

• Node Types

1. Managed Node Groups : AWS로 노드(EC2 Instance)를 생성하고 관리
   • 노드는 EKS로 관리되는 ASG의 일부
   • 온디맨드 인스턴스와 Spot 인스턴스를 지원
2. Self-Managed Nodes : 노드를 직접 생성하고 EKS Cluster에 등록하여 Cluster내 ASG에 의해 관리
   • 사용자 지정사항 or 제어대상이 많은 경우 사용
   • 최적화된 Amazon EKS AMI를 사용하면 부팅시간을 줄일 수 있음
   • 온디맨드 인스턴스와 Spot 인스턴스를 지원
3. Fargate
   • 노드를 원하지 않는 경우 사용
   • 유지관리 필요 없음
     
     
     

• Data Volumes

1. EKS Cluster에 Storage Class manifest를 지정해야 함
2. CSI (Container Storage Interface)라는 규격의 드라이버 사용 -> Cluster 설정의 Add-ons에서 해당 드라이버 설정 필요
3. Amazon EBS, Fargate모드를 지원하는 유일한 유형인 Amazon EKS, Amazon FSx for Lustre, Amazon FSx NetAPP ONTAP 지원
   
   
   

AWS App Runner

• AWS App Runner : 인프라나 소스코드를 알 필요 없이 누구나 AWS에 배포할 수 있음

• 완전 관리형 서비스로 서비스 규모에 따라 Web Application, API 배포를 지원
  
  
  

• 배포 방법

1. Docker image or Source code를 가지고 원하는 구성 설정 -> CPU/RAM 설정, ASG여부 등
2. 설정을 기반으로 Container에 자동 배포
3. URL이 생성되면 해당 URL로 접근 가능

• 장점

1. Auto Scaling 가능
2. 고가용성
3. Load Balancing
4. 암호화 기능 지원
5. custom VPC 배포 지원
6. DB, 캐시, 메세징 서비스 등에 연결 가능
   
   
   

• Use case : 웹앱 application의 신속한 배포가 필요한 경우

👉이전글에서 Container환경과 Kubernetes와 같은 Container Ochestration툴이 뭔지 알아봤습니다.

그리고 이번글에서는 Container Ochestration툴 중 가장 대중적인 툴인 Kubernetes의 클러스터에 대해 알아보겠습니다.

Kubernetes 클러스터

Kubernetes 클러스터는 오토스케일링, 버전관리 등과 같은 Container Ochestration의 다양한 기능들을 제공하기 위해 배포된 Kubernetes 환경이라고 보면 될 것 같습니다.

위 사진과 같은 Kubernetes 클러스터의 구조를 통해 Kubernetes(k8s)기반의 애플리케이션을 안정성있고 확장성있게 운영할 수 있습니다.
k8s클러스터는 크게 Control Plane과 Application Node로 구분할 수 있습니다.

• Control Plane : k8s클러스터 내부에서 발생하는 이벤트는 실시간으로 감지하거나 배포관리 등과 같은 클러스터 전반의 관리를 수행하기 위한 컴포넌트
• Application Node : 실제 application이 배포되는 컴포넌트
  
  

위 두 개의 컴포넌트는 하나의 노드상에 같이 배포되거나 개별 노드로 배포될 수 있습니다. (한 개의 노드는 한 개의 VM이라고 생각하면 이해하기 쉬움)
이제 클러스터를 구성하는 컴포넌트들을 세부적으로 살펴보겠습니다.

Control Plane

kube-apiserver

kube-apiserver는 application node를 제어하기 위한 여러 동작을 호출하는 Control Plane의 프론트엔드 api server입니다. (application node 입장에서는 endpoint api server)

Control Plane의 CLI(Command Line Interface) 환경에서 사용자가 직접 kuber-apiserver를 호출할 수도 있습니다. (명령어 : kubectl)
해당 명령어는 실습을 진행할 때 자주 활용될 것입니다. (다음글)

etcd

k8s클러스터 내부에 application을 어떤 방식으로 배포할지? scaling은 어떻게 진행할지? 등과 같은 클러스터 정보들을 key-value 형태로 저장하는 저장소입니다. 해당 정보들은 사용자가 yaml파일 형태로 작성하여 적용될 수 있는데, 이 또한 실습에서 작성해볼 것입니다. (다음글)

kube-scheduler

application node가 배정되지 않아 미배포 상태인 pod를 실시간으로 감지하고, 해당 pod를 실행시키기 위해 application node를 선택하는 기능을 가진 컴포넌트입니다. pod가 배포될 application node는 컴퓨팅 리소스나 pod의 리소스 요구사항 등과 같은 기준에 따라 결정됩니다.

• pod : k8s에서의 배포 최소단위, application이 동작하는 여러개의 Container를 k8s에서의 최소단위로 묶어놓은 컴포넌트 (다음글에서 다룰 예정)
  
  

kube-controller-manager

k8s클러스터에서 실행되는 여러 개의 컨트롤러를 통합 관리하는 프로세스입니다. 해당 컨트롤러들은 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되는데, 클러스터 내의 리소스를 감시하고 사용자가 정의한 상태로 클러스터를 유지하기 위해 조치를 취하는 역할을 수행합니다.

해당 컨트롤러들은 대표적으로 아래를 포함합니다.

• node controller : Node를 실시간으로 모니터링합니다. Node에 문제가 발생하였을 경우, 이상이 있는 pod를 종료시켜 node를 정상화합니다.
  
  

• replication controller : kube-apiserver를 통해 각 노드의 상태를 받아오고, 사용자가 설정한 Replica의 수에 일치하도록 노드상에 배포된 pod를 생성하거나 삭제하는 역할을 수행합니다.
• job controller : 일회성 작업을 수행하는 오브젝트를 실시간으로 모니터링하고, 수행이 필요한 작업이 있을 경우 해당 작업을 위한 일회성 pod를 생성합니다.
  
  

이외에도 아래 사진과 같은 다양한 컨트롤러가 포함됩니다.

cloud-controller-manager

k8s클러스터가 AWS와 같은 public cloud에 배포되어 있을 경우, application node를 제어하기 위한 controller-manager입니다. 해당 컴포넌트는 클라우트 플랫폼(ex. AWS, Azure 등)별 전용 cloud-controller-manager를 실행합니다.

Application Node

kubelet

kubelet은 각 application node에서 실행되는 Agent 프로세스입니다. control plane으로부터 명령을 받아 수행하거나, node내 파드들의 상태를 실시간 감시하고 control plane으로 보고하는 application node내 중추적인 역할을 수행합니다.

주요기능은 아래와 같습니다.

1. 파드관리 : Control Plane으로부터 할당된 파드를 노드에 배치하고 실행합니다. 해당 파드에 문제가 발생한 경우, 파드를 재시작하거나 재스케줄링하여 안정성을 유지합니다.
2. 컨테이너 실행 : 컨테이너 런타임(ex. docker 등)을 사용하여 파드에 정의된 컨테이너를 실행하고 관리합니다.
3. 리소스 모니터링 : node의 리소스 사용량을 파악하여 Control Plane에 보고합니다.
4. 상태 보고 : node내 배포된 파드의 상태와 노드의 상태를 주기적으로 Control Plane에 보고합니다.
5. 노드의 자동복구 : 노드가 비정상적으로 종료되었을 때, 자동으로 복구를 시도합니다.
   
   

kube-proxy

kube-proxy는 각 application node에서 실행되고, node간 네트워크를 관리하고 클러스터 바깥에서 접근할 수 있도록 해주는 컴포넌트입니다.

해당 컴포넌트는 node나 pod의 교체가 쉬운 k8s클러스터 환경에서의 원활한 통신을 보장합니다.
문제가 생겨 node나 pod가 새로 교체되는 경우가 발생할 수도 있는데, 이 때 ip가 교체되어 통신이 안되는 상황을 방지하기 위해
pod가 새로 생성될 때 별도 node iptable에 신규 생성된 pod의 네트워크 정보를 현행화합니다.

reference

• kubernetes conponents : https://kubernetes.io/ko/docs/concepts/overview/components/
• kube scheduler : https://velog.io/@gun_123/Kubernetes-Scheduler
• kube controller manager : https://m.blog.naver.com/ijoos/222125981319
• kube proxy : https://velog.io/@squarebird/Worker-Node-Kube-Proxy
• kubelet : https://velog.io/@gun_123/Kubernetes-Kubelet

Kubernetes 개요

Kubernetes는 컨테이너를 쉽고 빠르게 배포/확장하고, 관리 또한 자동화해주는 오픈소스 플랫폼입니다. 대량의 컨테이너를 관리해주는 플랫폼을 통칭하는 말인 Container Ochestration중 하나죠. (약칭 : k8s)

Kubernetes를 처음 접하신 분들은 여기서 Container는 무엇이고, Container Ochestration가 뭔지도 궁금해하실 것 같습니다.
먼저, Container에 대해 짚고 넘어가겠습니다.

Container

Container는 애플리케이션 실행 시 필요한 모든 파일을 포함한 전체 실행(runtime) 환경에서 애플리케이션을 패키징하고 격리할 수 있는 기술입니다. 각 애플리케이션당 독립된 실행환경을 제공하기 때문에 애플리케이션간 영향도를 최소화하여 안정성을 확보할 수 있습니다.

또한, 하나의 application이 실행되는 각각의 Container들은 한 개의 VM내에서 서로 Host OS를 공유하기 때문에,
Container환경 배포 시에는 VM에 배포하는 것처럼 OS를 별도 배포하지 않아도 되고, alpine-linux 등과 같은 경량 OS를 활용하게 됩니다.
이를 통해 빠른 배포가 가능하여 확장성을 보장할 수 있습니다.

결론적으로 Container 기술을 활용하면,

1. 애플리케이션간 독립된 환경을 보장받기 때문에 애플리케이션간 영향도 최소화를 통한 안정성
2. 애플리케이션 배포 시, 별도 OS의 배포는 필요하지 않기 때문에 빠른 배포를 통한 확장성

위 두 가지 이점을 챙길 수가 있게 됩니다.

그렇다면... Container 기술의 원리가 무엇일까?

Container 기술은 아래 두 가지 linux 기능을 활용하게 됩니다.

1. namespaces : 프로세스마다 독립적인 공간을 제공하고, 서로가 충돌하지 않게끔 namespaces를 만들어 프로세스를 실행시킬 수 있습니다.
2. cgroups : 각 컨테이너가 공유 컴퓨팅자원에 대한 제어권을 가질 수 있도록 하는 리눅스 커널의 기능입니다.
   
   

본 글에서 Container 기술의 원리까지는 딥하게 다루지 않겠습니다.
자세한 내용은 아래 링크를 참고바랍니다.
https://tech.ssut.me/what-even-is-a-container/

Container Ochestration

Container Ochestration은 Container가 많아짐에 따라 발생하는 관리의 복잡성을 해소하기 위한 플랫폼들을 통칭하는 말입니다. 본 글에서 다룰 kubernetes와 Docker Swarm 등이 이에 해당합니다.

Container Ochestration은 기본적으로 아래와 같은 기능을 제공합니다.

1. cluster : 관리자가 컨테이너 서버들을 cluster 단위로 추상화시켜 놓고, master 서버를 통해 해당 cluster 내부를 관리합니다.
2. state : 특정 애플리케이션이 동일하게 실행되는 container의 갯수를 자동으로 유지시켜줍니다.
3. scheduling : 여러 노드, 여러 컨테이너 서버에 어떤 프로그램이 있는지 확인한 후에 특정 프로그램을 적절한 공간에 넣어줍니다.
4. Rollout Rollback : 자동 버전관리가 가능합니다.
5. Service Discovery : 특정 컨테이너 서버의 정보(ex. host name 등)가 바뀌면 자동으로 확인하고 등록해주는 proxy가 있습니다.
6. Volume : 데이터를 container 서버의 업/다운과 관계없이 영구히 관리하기 위해 별도 공간을 활용하여 container서버에 자동으로 연결시켜 줍니다.
   
   

kubernetes는 위 Container Ochestration의 특징을 모두 갖습니다.

이어서

다음 글에서 Kubernetes cluster에 대해 알아보겠습니다.