Amazon EKS 란 ?

들어가며:

 

Amazon EKS 란?

• 특징
• 아키텍쳐

 

네트워크

스토리지

로깅 & 모니터링

 

---

 

들어가며:

kubernetes는 컨테이너로 애플리케이션을 배포, 관리하는 것을 자동화하는 오픈 소스 시스템

kubernetes는 aws EKS, gcp GKE, azure AKS 등 다양한 벤더 환경에서 원활히 동작하며 도커 외에도 다양한 컨테이너를 지원하여 사용량이 급격히 늘어나고 있습니다.

 

도커와 쿠버네티스에 대한 설명은 이전 포스팅을 참고 하시기 바랍니다.

 

---

 

Amazon EKS 란?

Amazon EKS 관리형 서비스는 컨트롤 플레인을 직접 구성하지 않고서 k8s를 손쉽게 사용할 수 있도록 편리함을 제공

AWS에서 제공하는 VPC, ELB, IAM  등 특정 기능들을 같이 활용하고자 할 때 유용

 

 

Amazon EKS 특징

 

VPC(Virtual Private Cloud) 와 통합

일반적으로 쿠버네티스 클러스터에서는 파드 네트워크로 워커 노드의 네트워크와는 다른 자체 네트워크 체계를 배치.

클러스터 자체 네트워크를 사용하기 때문에 명시적으로 엔드 포인트를 설정하지 않으면 클러스터 외부에서 파드에 통신이 불가능

 

Amazon EKS에서는 Amazon VPC 통합 네트워킹을 지원하고 있어 파드에서 VPC 내부 주소 대역을 사용할 수 있고 클러스터 외부와의 통신이 가능하고 심리스(Seamless)하게 구현할 수 있다.

 

cf) 심리스(Seamless): 서비스 접근을 단순하게 하는 것 혹은 복잡한 기술이나 기능을 설명하지 않아도 서비스 기능을 직관적으로 구현하는 뜻

 

 

ELB와의 연계 

k8s 클러스터 외부에서 접속할 때는 서비스를 사용해 엔드포인트를 생성할 필요가 있음

가장 전형적인 엔드포인드가 로드밸런서

 

EKS 에서는 k8s의 서비스 타입 중 하나인 LoadBalancer를 설정하면 자동적으로 AWS의 로드밸런서 서비스인 ELB가 생성

이것으로 HTTPS나 경로 기반 라우팅 등 L7 로드밸런서 기능을 AWS 서비스로 구현 가능

 

 

 

IAM 을 통한 인증과 인가

쿠버네티스 클러스터는 kubectl 이라는 명령줄 도구를 사용하여 조작.

이때 해당 조작이 허가된 사용자에 의한 것음을 올바르게 인증해야 함.

또 인증된 사용자에게 어떤 조작을 허가할지에 대한 인가 구조도 필요

 

EKS 에서는 IAM과 연결한 인증 및 인가 구조를 제공

 

 

워커 노드

EKS workflow 를 살펴보자

EKS 클러스터 컨트롤 플레인 생성 부분은 EKS에서 관리형 서비스로 제공하고 있다.

 

워커 노드에 대한 서비스도 제공. ex) AWS에서 제공하는 서비스 eksctl

반대로, 워커노드를 Customize 해서 원하는 서비스를 생성할 수 있음

 

EKS 클러스터의 유지 관리나 버전 업그레이드할 때 필요한 가상 머신 설정을 쉽게 해주는 관리형 노드 그룹 구조와 가상 머신을 의식하지 않고 파드를 배포할 수 있는 파게이트(Fargate)

하지만, 파게이트는 워커 노드 관리가 필요 없는 만큼 파드가 배포되는 호스트에 사용자 접근도 제한되며 거기에 따른 제약도 있다.

 

	Amazone EC2	Amazon Fargate
관리 부하	높음	낮음
제약	적음	많음
특징	1. Amazon EC2 KES와 별도로 EC2 관리 2. 관리형 노드 그룹 EC2임에는 변함이 없지만 EC2에 통합된 워커노드로 동작. 유지보수나 버전을 업데이트할 때 필요한 조작이나 고려 사항들을 자동적으로 실행	워커 노드도 완전히 AWS가 관리하며 사용자는 EC2를 관리하지 않아도 됌

 

 

Amazon EKS 아키텍쳐

EKS 를 배포하게 되면

왼쪽 그림처럼 가용영역별로 API Server와 etcd 와 컨테이너가 배포되게 됩니다. (고가용성 보장)

하지만, 사용자 입장에서는 하나의 마스터 엔드포인트로 보입니다.

 

AWS Side Workflow

 

EKS 클러스터를 사용자가 생성하면 AWS side에서 쿠버네티스 클러스터를 생성하기 위해 위와 같은 workflow를 거침.

 

• 쿠버네티스의 api 서버를 각 가용영역에 배포
• api 데이터, 쿠버네티스의 상태 데이터를 확인하기 위해 etcd를 같이 배포
• 쿠버네티스에서 오는 call 에 대한 IAM 구성
• 쿠버네티스 마스터 노드의 오토스케일링 설정
• 클러스터가 안정적으로 구현하도록 여기에 연결할 수 있는 로드밸런서를 구성

 

 

 

 

---

스토리지

 

3가지의 스토리지 케이스가 있음.

 

1. 컨테이너의 볼륨

• 컨테이너가 종료되면 손실
• 호스트 노드의 메모리 활용 가능 (임시 캐시)

 

2. 호스트의 볼륨

• 컨테이너가 다른 호스트 재배치되면 접근 불가
• 컨테이너 이미지를 경령화 하기 위해 사용

 

3. 네트워크 볼륨

• 호스트에 독립적
• 컨테이너가 다른 쪽으로 스케줄링 되도 문제없음

 

1,2는 호스트의 가용성에 의존되어 있음.

Stateless 애플리케이션에 적합

 

Stateful 애플리케이션은 Persistent 볼륨이 필요

 

PersistentVolume(PV)

독립적인 라이프사이클이 있는 볼륨 플러그인

NFS, iSCSI 혹은 클라우드 제공 스토리지

 

PersistentVolumeClaim(PVC)

PV를 요청하는 오브젝트

용량과 access mode 정의

 

Provisioning

Static: 미리 PV를 생성하고 PVC Claim 기반으로 특정 PV를 요청

Dynamic:  미리 정의한 StorageClass에 기반하여 PVC가 동적으로 PV를 할당

 

Temp	Host Local	Network
emptyDir	hostPath	AWS EBS gcePersistentDisk azureDisk GlusterFS gitRepo NFS ISCSI Fiber Channel VshereVolume

 

 

 

로깅 & 모니터링

로깅

아마존 EKS 에서 Fluentd 를 사용해 로그를 모을 수 있는 아키텍쳐를 제공

 

 

 

다양한 소스에 있는 fluentd 에서 모아서 JSON 형태로 모아 스토리지 영역으로 바이패싱

스토리지 영역은 ES, S3 로 사용 가능

데이터가 들어오는 시점에 Cloudwatch 를 사용해 전송 패턴을 가지고 들어오게 할 수 있음.

 

 

 

fluentd 가 데몬셋처럼 인스턴스 1개 당 배포.

인스턴스에 있는 파드에서 배포된 서비스에서 나오는 Standard Output log 들을 fluentd가 ES로 전송

ES 에 있는 데이터들은 필드형태로 kibana 에서 시각화할 수 있음

 

 

 

 

모니터링

쿠버네티스는 3가지 정도의 모니터링 리소스를 소개

 

1. Resource metircs pipeline

노드들 상태정보, 노드에서 사용하고 있는 cpu,메모리,디스크 사용정보를 마스터 노드로 전송

인스턴스에서 파드에 사용하는 전체사용량이지 각각 애플리케이션(서비스) 전체 사용량을 볼 수는 없음

 

서비스에서 사용하는 정보를 얻고 싶다면

2. Full metrics pipelines 프로메테우스를 사용

 

일반적으로 쿠버네티스에서 대시보드에서 보는 3. CronJob monitoring

전체 클러스터의 상태 정보를 폴링형태로 보여주는 것

 

 

 

 

프로메테우스 아키텍쳐 개요