[AWS] Kubernetes, Docker, EKS

📌 목차

1. Amazon EKS
2. Docker?
3. Kubernetes
4. EKS란?

01. Amazon EKS

Amazon EKS를 설명하기에 앞서 EKS의 근간이 되는 Docker와
Kubernates에 대한 부분은 간략히 짚고 넘어가는 시간을 갖겠습니다.

02. Docker?

02-1. Why we use Docker?

AWS EKS에 대한 부분을 알아보기에 앞서
도커에 대한 예시를 한 가지 알아보겠습니다.

02-2. 프로듀싱 일을 하는 ‘A씨가 있다 가정

• 프리랜서이기에 계약 건마다 일을 하러 외부로 나간다
• 매번 많고 복잡한 장비들을 새 업무환경에 옮겨서 셋팅 한다
• 매번 외부에 나갈때마다, 모든 장비를 일일이 가지고 이동 해야한다
• 이렇게 매번 일을 나갈때마다 모든 장비를 들고 움직여야 할까?

02-3. 위와 같은 문제를 해결하기 위한 기술이 도커(Docker)

• 도커는 모든 장비를을 설치된 그 상태 그대로를 복제한다
• 하나하나 복제를 하거나 연결되고 조립된 모습 그대로 복제 가능
• 이렇게 저장된 사본들은 도커 허브(Docker Hub)에 이미지화 시켜 업로드 가능
• 클라우드(Cloud)를 쓰는 것처럼 어디서든 다운받아 사용이 가능

02-4. 서버를 관리한다는 것

1번 서버 : JDK 1.7, 서버는 Nginx, DB는 MySQL 사용
2번 서버 : JDK 1.8, 서버는 Apache, DB는 MS-SQL 사용
3번 서버 : python 2.7.1 서버는 IIS WEB Server DB는 Mongo DB 사용

서버에 어떠한 부분을 설치 하고 관리한다는 것은 그렇게 쉬운 일이 아니다

• 버전(Version)
• Linux 폴더 구조, 권한
• 언어(Java, Python, Node.js)
• 웹서버(Nginx, Apache)
• 데이터베이스(MySQL, MS-SQL, Mongo)
• 자동배포툴(CI/CD Tool)

서버 환경의 변경 발생?

1. 성능이 더욱 더 좋은 서버로 이동
2. 늘어난 트래픽을 처리하기 위해 서버를 여럿 추가해야 하는 경우
3. 여태까지 설치를 해본 사람이 하는 경우 그나마 괜찮지만, 담당자가 없다면…?

02-5. Docker

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼입니다.

• Go 언어로 작성된 Linux 컨테이너 기반으로 하는 오픈소스 가상화 플랫폼
• 현실 세계의 컨테이너
  • 배에 실는 네모난 화물 수송용 박스
  • 옷, 신발, 전자제품, 술, 과일등 다양한 화물을 넣어서 규격화가 가능
  • 컨테이너선이나 트레일러 등 다양한 운송 수단으로 쉽게 옮길 수 있음
• 서버 관점에서의 컨테이너
  • 다양한 프로그램, 실행환경을 컨테이너로 추상화
  • On-premise, Cloud(AWS, Azure, Google Cloud)등 어디에서든 실행 가능

02-6. Docker 부연

하나의 운영체제(OS) 위에서 lib, bin 파일만 가지고 실행 우리는
VMware, Virtual Machine을 사용하여 서버를 가상화해본 경험이 있다.

02-7. 컨테이너(Container)

Docker는 컨테이너 기반 기술을 제공

• 격리된 공간에서 프로세스가 동작하는 기술
• 가상화 기술의 하나지만 기존 방식과는 차이가 있음
• VMware, VirtualBox같은 가상머신은 호스트 OS 위에 게스트 OS 전체를 가상화하여 사용
• 여러가지 OS를 가상화하여 사용법은 간단, 무겁고 느려서 운영 한경에서 사용 힘듬

VMware, VirtualBox와 같은 가상머신의 예시

가상 컴퓨팅(VMware, VirtualBox)은 한 물리적 컴퓨터 안에 각각 OS를 돌리는 컴퓨터들이 물리적 자원을 분리해서 사용하기에 메모리를 더 많이 잡아먹어서 성능에 한계가 생김.

도커는 실행 환경에서 메모리 자원을 공유

Docker의 경우 OS딴까지 내려가는것이 아니라, 실행 환경만 독립적으로 실행 시키는 것이기 때문에 컴퓨터에 직접 설치를 한 것과 같은 성능을 낼 수 있고 가상 컴퓨팅에 비해 훨씬 가볍고 빠르게 구동, 종료 등을 수행할 수 있다.

02-8. 도커 이미지 vs 도커 컨테이너

도커에서 중요한 개념이 되는 이미지와 컨테이너의 차이점

이미지

• 서비스 운영에 필요한 서버 프로그램, 소스코드, 컴파일된 실행파일을 묶은 형태
• 실제로 저장소에 올리고 받는 것은 이미지
• 컨테이너를 구축하기 위한 하나의 레시피

컨테이너

• 컨테이너는 이미지를 이미 실행한 하나의 형태
• 레시피를 통해 준비된 케이크, 빵, 햄버거

03. Kubernates?

Container Orchestration

대규모 컨테이너화된 애플리케이션을 배포 & 확장 & 관리하는데 사용할 수 있는 오픈소스 소프트웨어 기존 쿠버네티스를 손 쉽게 사용하기 위한 하나의 서비

03-1. 쿠버네티스

쿠버네티스 관련 정리가 잘되어 있는 자료 공유

1. 컨테이너 운영을 자동화 하기 위한 컨테이너 오케스트레이션 도구
2. 많은 수의 컨테이너를 협조적으로 연동시키기 위한 통합 시스템
3. 컨테이너를 다루기 위한 API 및 CLI(kubectl)가 함께 지원됨
4. 배포 & 확장하는 데 수동 프로세스가 필요하지 않음
   • HPA (Horizontal Pod AutoScaler)
     • 특정 매트릭(Metric)의 리소스들이 임계점을 지나면 Pod의 수를 늘려서 Scaling 하는 HPA
     • 파드의 수를 적절히 조정
   • VPA (Vertical Pod AutoScaler)
     • CPU, Memory를 자동으로 조정하여 애플리케이션의 크기를 적절히 조절하는 VPA
     • 파드의 리소스 크기를 적절히 조정
5. 컨테이너화된 애플리케이션을 관리할 수 있는 서비스 중 하나가 쿠버네티스(Kubernetes)

03-2. Kubernates 대표적인 특성

03-2-1. 애플리케이션 환경의 통일

개발 환경과 운영 환경의 동일한 환경에서 애플리케이션 구동을 보장 애플리케이션 환경의 통일성 보장.

03-2-2. 지속적인 상태 확인 및 셀프 힐링

쿠버네티스는 배포된 애플리케이션의 구성 요소와 노드를 지속적으로 모니터링 컨테이너나, 노드에 문제가 발생할 경우 문제가 없는 다른 적당한 노드로 스케쥴링하여 다시 구동을 해준다.

03-2-3. 오토 스케일링

특정 컨테이너에 부하가 급격하게 발생할 경우에 쿠버네티스는 이를 모니터링 하고 있다가 정해진 수준 이상의 부하가 발생할 경우 자동으로 스케일 아웃하여 컨테이너를 늘려서 부하 분사 처리. 후에 사용이 줄어 트래픽이 적을 경우 이전 수준으로 감소 시킨다.

03-3. Kubernetes Architecture

Kubernetes Architecture

03-4. Control Plain(제어/관리 서버)

Kubernetes control plain(master node로 볼 수 있음)

쿠버네티스 클러스터의 신경 중추

• 클러스터를 제어하는 쿠버네티스의 구성 요소
• 클러스터의 상태 및 구성에 대한 데이터
• 컨테이너가 필요한 리소스를 갖고 충분한 횟수로 실행되도록 하는 중요한 역할(Role)을 맡는다

참고 : master 서버의 경우 고가용성 유지를 위해 여러개로 구성할 수 있으며 실제 관리는 리더 마스터 서버가 하되 나머지는 후보 마스터 서버로 유지 한다. 만약 리더 마스터 서버에 장애가 발생하면 후보 마스터 서버 중 하나가 리더 마스터 서버 역할을 맡아 서비스상의 이슈가 없도록 한다.

03-4-1. kube-api-server

• 쿠버네티스 클러스터와 상호 작용을 해야하는 경우
• 쿠버네티스 컨트롤 플레인의 프론트앤드로, 내부 밑 외부 요청을 처리
• API 서버는 유효한 요청인지 판별하고 유효한 요청을 처리
• REST 호출, kubectl, kubeadm과 같은 CLI(command-line interface)를 통해 엑세스 가능

03-4-2. kube-sceduler

• 클러스터가 양호한 상태인지, 새 컨테이너가 필요하다면 어디에 적합한지 판단하는 스케쥴러 (모니터링, 컨테이너를 배치할 노드 선정)
• CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터의 상태를 고려 ****

03-4-3. kube-controller-manager

• 실제로 클러스터를 실행하고 컨테이너의 상태를 체크(리소스를 제어하는 컨트롤러 실행)
• 쿠버네티스 controller-manage에는 여러 컨트롤러 기능이 하나로 통합되어 있음
  • 하나의 컨트롤러는 스케쥴러를 참고하여, 정확한 수의 포드가 실행되게 구성
  • 포드에 문제가 발생하면 또 다른 컨트롤러가 이를 감지하고 대응
  • 컨트롤러는 서비스 포드에 연결하므로 요청이 적절한 엔드 포인트로 이동
  • 계정 및 API 엑세스 토큰 생성을 위한 컨트롤러 존재

03-4-4. etcd

• 모든 상태를 저장 및 조회할 수 있는 DB와 같은 etcd
  • 설정 데이터, 클러스터 상태 정보를 key-value 형식으로 저장

cloud-controller-manager

• 클라우드 인프라 스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행시킬 수 있다
  • 쉽게 말해 쿠버네티스를 다른 클라우드와 연동하는 방법
• 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자 API 연결, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구별할 수 있게 해줌

03-5. Worker Node(물리/가상서버)

Kubernetes node(Worker node로 볼 수 있음)

• 개인적인 생각으로는 Elasticsearch(node), Kafka(broker) 와 동일하다는 느낌을 받는다
• 쿠버네티스 클러스터에는 최소 1개 이상의 컴퓨팅 노드가 필요, 일반적으로 여러 개가 존재
• 포드는 노드에서 실행하도록 예약되고, 오케스트레이션 됨
• 클러스터의 용량을 확장해야 할 시 노드를 추가하면 됨

03-5-1. Kubernetes Pod(쿠버네티스 포드)

파드는 워커 노드(Worker node)의 파드(Pod)에 배치가 된다

kubectl CLI → master node (pod) → etcd(confirm), worker node(confirm) → ok! → pass on pod to worker node → exec pod on worker node

• 컨테이너가 모인 집합체의 단위, 적어도 하나 이상의 컨테이너로 이루어진다 (1 Pod = N Containers)
• 여기서 말하는 컨테이너는 도커(Docker) 컨테이너를 의미
• 쿠버네티스를 도커와 함께 사용한다면 파드(Pod)는 컨테이너 하나 혹은 컨테이너의 집합체가 되는 것
• yaml 형식으로 pod를 생성

03-5-2. Container Runtime Engine(컨테이너 런타임 엔진)

• 컨테이너 실행을 위해 각 노드에는 컨테이너 런타임 엔진이 존재
• 대표적인 런타임 엔진 : Docker
• rkt, CRI-O 역시 지원

03-5-3. kubelet

• 각 worker node에는 control plaing(master node)와 통신하는 애플리케이션 kubelet이 존재
• kublet은 컨테이너가 포드(Pod)에서 실행되게 함
• control plaing(master node)에서 worker node에 작업을 요청하는 경우 kubelet이 해당 작업을 수행

03-5-4. kube-proxy

• kubernetes의 네트워크 동작을 관리
• 모든 worker node에 하나씩 위치하여, DaemonSet의 형태로 배포되어 있음

  $ kubectl get daemonset --all-namespace
  

• 서로 다른 worker node의 포드(pod)들 간의 통신이 가능하도록 해줌
• Client(유저)와의 연결도 관리 해주는 것인가?

04. EKS(Elastic Kubernetes Service)

04-1. EKS란 무엇인가?

Amazon EKS(Elastic Kubernetes Service)

자체 쿠버네티스 컨트롤 플레인이나 작업자 노드를 설치 및 운영할 필요 없이
AWS에서 쿠버네티스를 손쉽게 실행할 수 있도록 지원하는 관리형 서비스

• EKS 사용 시 Kubernetes 설치부터 운영까지 EKS가 담당하기에 직접 Kubernetes Cluster를 구성하고 관리하는 것보다 쉽게 Kubernetes 사용이 가능하다
  • 하중에 따라 제어 영역 인스턴스의 크기를 자동으로 조정(Auto Scaling)
  • 비정상 제어 영역 인스턴스 감지 후 교체(Monitoring)
  • 자동화된 버전 업데이트 및 패치 제공(Auto Fetch)
• 여러 AWS 서비스와 통합, 다음 기능을 포함한 애플리케이션에 대한 확장성 및 보안 제공
  • 컨테이너 이미지에 대한 Amazon ECR
  • 로드 분산을 위한 ELB 제공
  • 인증용 IAM 제공
  • 격리를 위한 Amazon VPC 제공
• 오픈 소스 Kubernetes 최신 버전 사용
  • Kubernetes 커뮤니티에서 모든 기존 플러그인 도구 사용 가능
  • On-premise, Cloud 환경 상관없이 모든 표준 Kubernetes 환경에서 실행되는 app과 완벽 호환

04-2. AWS EKS 실행 방법

1. AWS Management Console 또는 AWS CLI를 사용하거나 AWS SDK를 사용하여 Amazon EKS를 생성
2. 관리형 또는 자체 관리형 AWS EC2 노드를 실행하거나 워크로드를 AWS Fargate에 배포
3. 클러스터 준비가 완료되면 원하는 Kubernetes 도구(kubectl)를 구성하여 클러스터와 통신
4. 다른 Kubernetes 환경에서와 마찬가지로 Amazon EKS 클러스터에 워크로드를 배포 및 관리
   • AWS Management Console을 사용하여 노드 및 워크로드에 대한 정보를 볼 수도 있습니다.

04-3. EKS를 사용할 경우

• 쿠버네티스는 안정적인 운영을 위해 3개 이상의 master node 운영을 권장
• 기존 구성 요소는 다음과 같이 구성이 되어 있다 가정
  • 3대의 master node
  • 3대의 etcd
  • 3대의 ec2 instance (worker node)

04-4. 쿠버네티스트를 직접 운영하는 경우

AWS 쿠버네티스를 직접 운영하는 경우 관리 포인트가 증가한다

• 인스턴스 정보(instance info)
• 인스턴스 애플리케이션 정보(instance application info)
• 컨테이너의 메타 데이터 정보

이러한 경우 Master Node에 문제가 발생한다는 것을 항상 염두하며 etcd, master node의 스냅샷을 항상 백업하여 문제가 생긴 master node의 인스턴스를 직접 교체해 주어야 한다는 번거로움이 발생 한다 또한 클러스터 확장 시 master node, scale up - out의 구조를 직접 만들어야 한다

04-5. EKS 사용을 통해 쿠버네티스를 운영하는 경우

AWS EKS를 사용하는 경우 관리 포인트가 적어진다

• master node, etcd를 직접 관리할 필요가 없음, AWS에서 managed
• worker node의 운영 내용만 확인하면 되기에, 포인트가 적어짐

04-6. EKS 운영 방식

1. EKS 클러스터 생성 시 하나의 엔드 포인트(master end point)가 생성이 된다.
2. master end point(AWS 구름 모양)을 기준으로 3개의 가용 역역이 생성이 된다.
3. 해당 가용 영역에서 worker node들이 분산되어 배포가 되어진다.
4. 사용자는 kubectl을 통해 master node에 접근, 컨테이너 노드 관리를 할 수 있다.

04-7. ECS vs EKS

	Amazon ECS	Amazon EKS
Open Source(오픈 소스)	No - AWS proprietary	Yes - Kuberneties
Atomic Container Term(컨테이너 단위)	Task	Pod
Deployment Effort(배포 난이도)	Easy (AWS Dashboard)	Medium (AWS plus Kubernetes knowledge required)
Security (IAM)	Comes with the service	Requires addon software and additional configuration
Per VM Container Limit	Up to 120	Up to 750 Pods (which can host multiple containers)
System Service Cost	Used resources	Used resources plus ~$75 per cluster per month
Multi-cloud Integration	No - AWS specific	Yes - Public and Private cloud Integration

04-8. EKS 클러스터 생성을 위한 VPC 고려 사항

• 2개 이상의 subnet이 필요함
  • 외부 서비스를 고려해야 하기 때문에 public, private subnet 필요
  • 2개 이상의 [public/private subnet]은 각각 서로 다른 가용영역에 존재해야 EKS 클러스터와 연동 가능
• DNS hostname, resolutions를 모두 지원해야 함
  • 모두 지원하지 않을 경우 worker node가 클러스터에 등록되지 않음
  • AWS 콘솔에 VPC에서 다음과 같이 설정되어 있어야함

    DNS resoulution  # Enabled
    DNS hostnames    # Enabled
    

04-9. AWS EKS Architecture

AWS EKS Architecture

1. EKS, Customer VPC로 분리가 되어 있기에 사용자가 별도로 VPC를 나눌 필요가 없다.
2. EKS의 컨트롤 플레인는 EKS VPC에 위치하여 앞단에 Static IPs를 가지는 Endpoint를 가진다.
3. 실제 worker node들은 EC2로 구성이 되어 Customer VPC에 위치하게 된다.
4. 노드는 public/private Endpoint를 통해 컨트롤 플레인(master node)에 API Access를 하게 된다.
5. Customer VPC에 ENI를 생성 후 해당 구간을 통해 worker node에 접근을 수행 한다.
6. 앞단에는 LB를 제공.

참고 자료

• [문서] Amazon EKS란 무엇입니까?
• [문서] EKS란? EKS 생성하기(AWS Consonle, AWS CLI사용)
• [문서] 초보를 위한 도커 안내서 - 도커란 무엇인가?
• [문서] Dockerhub
• [문서] Docker 이미지와 컨테이너 차이
• [문서] Docker의 개념 및 핵심 설명
• [문서] 초보자를 위한 EKS 맛 보기
• [문서] Kubernetes-on-AWS
• [발표] Kubernetes 네트워크 이해하기 : 서비스 개념과 동작 원리
• [영상] 도커가 뭐고 왜 쓰는건가요?
• [영상] AWS EKS를 이용하여 Kubernetes를 구축해보자
• [영상] EKS란 무엇인가. (빅챗 6화)