[ AWS ] AWS EKS(Elastic Kubernetes Service)

AWS EKS(Elastic Kubernetes Service)

 

AWS EKS 란 무엇인가?

아마존 엘라스틱 쿠버네티스 서비스(Amazon Elastic Kubernetes Service) 로 완전관리형 쿠버네티스(Kubernetes) 서비스 이다.

자체 쿠버네티스 제어 플레인을 설치, 운영, 유지관리할 필요 없이 AWS에서 쿠버네티스를 쉽게 실행할 수있도록 지원 하는 관리형 쿠버네티스 서비스인 것이다.

 

근데 AWS EKS라는걸 알기 위해 쿠버네티스(Kubernetes) 라는걸 알아야한다.

쿠버네니스에 대해선 간략한 설명으로만 하고 넘어가겠다. 쿠버네티스를 많이 알지를 못하고, 조금만 알아도 AWS EKS를 사용할수있다. 쿠버네티스를 쉽게 사용하기 위해 지원하는것이 AWS EKS이기 때문이다.

 

쿠버네티스 란 무엇 인가?

컨테이너를 사용하면 서버의 자원을 효율적으로 사용할 수 있다. 근데 그런 컨테이너가 엄청나게 많아진다면 어떤 일이 발생할까?

컨테이너들의 관리와 운영이 어려워져서 오히려 운영상의 효율성이 떨어지게 된다. 이 문제를 해결해주는 도구가 바로 쿠버네티스 이다.

쿠버네티스는 컨테이너 오케스트레이션 플랫폼 중 하나로, 구글이 자사 서비스를 위해 개발했던 Borg에서 얻은 운영 노하우를 오픈소스로 공개한 것이다.

 

또 한 기초 적인 쿠버네티스 오브젝트 구조는 파드,서비스,볼륨,네임스페이스 및 등등 이며, 이 기초 오브젝트를 기반으로 제공 하는 컨트롤러에 의존 하는 보다 높은 수준의 추상 개념은 디플로이먼트, 데몬셋, 스테이트풀셋, 레플리카셋, 잡 이 있다.

 

자세한 사항은

https://kubernetes.io/docs/concepts/

참조 하면 될것이다.

 

 

본격적으로 쿠알못이 AWS EKS로 안정적인 서비스 운영하기 를 리뷰 해보겠다.

https://www.slideshare.net/awskr/amazon-eks-aws-community-day-2020

 

 

1. 왜 AWS EKS인가? 이걸 왜?

1. AWS EKS가 무엇이냐고 말했을때 완전관리형 쿠버네티스 라고 말했었다. 즉 AWS EKS 인가? 가 아니라 쿠버네티스 인가? 라는 질문이 된다.

   왜 쿠버네티스인가?

   쿠버네티스는 무중단 서비스를 제공한다. 때때로 기업의 서비스를 이용하는 사용자들은 개선을 위해 임시점검 중이라는 안내문을 보게 된다. 기업 에서는 서버 업데이트를 위해서 사용 자들이 잠든 새벽 시간을 활용하거나

   긴급 점검의 형태로 서비스를 일시 중단해왔다. 하지만! 쿠버네티스는 점진적 업데이트를 제공하기 때문에 서비스를 중단하지 않고도 애플리 케이션을 업데이트 할 수가 있다. 또 한 쿠버네티스는 자가회복 이라는 기능이

   있기 때문에 특정 컨테이너에 갑작스러운 장애가 발생하더라도 곧바로 복제 컨테이너를 생성하서 서비스를 유지할 수 가 있다.

   쿠버네티스가 이러한 큰 장점이 있는데 이 쿠버네티스 클러스터를 관리 해주는게 AWS EKS이다. 안쓸 이유가 없다는 것이다.

   쿠버네티스 제어 플레인을 설치, 운영, 유지 관리할 필요 없이 AWS에서 쿠버네티스를 쉽게 실행할 수 있도록 지원하니 굳이 직접 일일히 할 필요가 없다는 것이다.

   또 한 AWS EKS는 컨테이너 시작 및 중지, 가상 시스템에서 컨테이너 일정 수립, 클러스터 데이터 저장 및 기타 작업을 담당 하는 쿠바네티스 제어 플레인 노드의 가용성과 확장성을 자동! 으로 관리 해준다.

   그리고 각 클러스터의 비정상 제어 플레인 노드를 자동으로 탐지하여 교체도 해준다

   등등 많은 이점을 가지고 있으니 안쓸 이유가 없다.

2. 쿠버네티스 클러스터 파드 생성순서

1. 

    명령어를 날리게 되면은

2. 먼저 Deployment 가 만들어지고 ReplicaSet가 만들어 지고, ReplicaSet에 의해 Pod가 만들어 진다.

3. 

4. 

3. 쿠버네티스 클러스터 내부

1. 

2. 쿠버네티스 클러스터 내부에서의 각 컴포넌트들은 Watch 매커니즘을 가지고 있다.

   Components 는 API서버를 바라보고 API 서버는 etcd를 바라본다. API서버에서 변경이 발생하면 etcd에게 업데이트 요청을 날리고

   etcd는 업데이트 하면서 변경 사항이 발생하니 이 변경 사항을 API서버에게 알린다 API 서버는 이 변경 사항을 Compoents에게 알린다.

3. 

    명령어를 날리면 해당 클러스터 내부에서는 이렇 구조로 돌아간다

   

   run 명령어를 날리면 Deployment resources에서 변경 사항이 발생하고, Deployment Controller에게 Watch에 대한 응답을 날리면

   Deployment Controller는 ReplicaSet resources에게 ReplicaSet를 생성 하라고 한다. 그럼 변경 사항이 발생하는것이니

   Replication Controller에게 Watch에 대한 응답을 날리면 Replication Controller는 Pod resources에게 Pod를 생성하라고 한다.

   또 Pod resources는 변경 사항이 발생 하는 것이니 Scheduler에게 Watch에 대한 응답을 날린다. 그럼 Scheduler는 Pod resources에게 Worker Node에 Pod 할당하라고 하면

   Pod resurces는 Worker Node의 Kublet에게 Pod를 할당하라고 하고 Kublet는 자신의 노드에 Pod를 할당한다.

   즉 해당 컨포넌트들은 서로서로 바로보는 상하 구조를 가지고 있다.

4. AWS EKS 설치

1. 

2. 여러가지 방법이 있지만 두가지를 추천 해줬다 eksctl과 Terraform 이중 Terraform를 더 추천했다.

5. 인증 및 권한

1. 

6. 네트워크

1. 

2. 여러개의 호스트가 되어도 패킷이 잘 전달 될수있도록 각기 다른 IP를 부여해야한다.

   AWS EKS 에서 지원 해주는 쿠버네티스용 Amazon VPC CNI 플러그인을 통해 기본 VPC 네트워킹을 이용해 네트워크를 구상한다.

   IPAM이 Amazon VPC CNI플러그인의 ENI로 부터 IP를 받아 Pod에 할당한다. 이 IP들을 각각 다른 IP를 할당해줘야한다.

   하나의 클러스터에 Pod수가 많으면 ENI에서 부터 Pod 할당을 저지 받을수 있다

   https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/pod-networking.html

7. 볼륨

1. 일단 볼륨이란걸 설명 하자면 도커의 볼륨 개념과 같습니다. 반면 쿠버네티스 볼륨은 볼륨을 묶는 Pod와 동일하게 명시적인 수명을 갖는다

   즉 볼륨은 Pod 내에서 실행 되는 모든 컨테이너 보다 수명이 길고 컨테이너를 다시 직해도 데이터가 보존이 된다. 물론 Pod가 없다면 볼륨도 없다.

   쿠버네티스는 많은 유형의 볼륨을 지원하며 여러 볼륨을 동시에 사용할 수 있다.

   https://kubernetes.io/docs/concepts/storage/volumes/

2. 안정적인 데이터 관리는 어떻게 해야하나?

   안정적인 저장소를 준비하고, 컨테이너에 안정적인 저장소를 마운트 해야한다.

3. 해당 마운트 하는 부분은 AWS EBS 로 마운트 했다고 한다 그럼 EBS로 마운트 하는 방법은

   

8. 모니터링

1. Master Node의 컨포넌트들의 로그를 CloudWatch를 통해 확인 할 수 있다.

2. 

    

관련 글

저의 글을 읽어 주셔서 감사합니다. 오늘도 즐거운 하루 보내세요.

저의 글이 조금이나마 도움이 되셨다면 로그인이 필요 없는 공감♥ 한번 꾸욱 눌러주세요 하하~