[AEKS2] 1주차 - Amzaon EKS 설치 및 기본 사용

오랜만에 아래 세 가지 이유로 가시다님 스터디에 참여하게 되었다. 아자!

1. 공부 마음 다잡기
2. 쿠버 지식이 휘발될지도 모르는 두려움
3. 회사에서 EKS 도입 가능성 대비

https://www.youtube.com/watch?v=xIc6sB77Zqs 스터디에 시작하기 전에 위 영상을 추천받았다.

EKS의 Control Plane 영역과 Data Plane 영역에 대해 전체적으로 알 수 있는 영상이라 EKS 아키텍처를 이해하는 데에 도움이 되었다.

EKS 기본

Kubernetes는 1년에 한 3번 정도 마이너 버전을 업데이트하는 것 같다. EKS는 매니지드 서비스이기 때문에 EOS(End Of Support) 기간이 있고, 보통 5~6개의 마이너 버전을 지원한다. EKS 버전이 릴리즈되고 나서는 표준 지원(standard support) 이라고 해서 14개월동안 지원한다. 그러나 추가 비용을 지불한다면 12개월을 연장하여 확장 지원(extended support) 해 준다. 참고로 표준 지원+확장 지원(총 26개월)이 끝나면 불시에 컨트롤 플레인이 최신버전으로 자동 업데이트된다. 이후 노드는 수동 업데이트해야 한다…..! https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/kubernetes-versions.html

1. Amazon EKS 책임 공유 모델

AWS에서 제공하는 리소스가 그렇듯, EKS의 책임 공유 모델에도 AWS 책임 영역과 고객 책임 영역 두 가지로 나뉜다.

컨트롤 플레인은 AWS가 관리하는 VPC에 만들어 지며, AWS 책임 영역이다. 가용성 보장을 위해 다중AZ를 사용해도, 부하에 따라 API 서버의 수가 늘어나도 고객은 이에 해당되는 비용을 지불하지 않아도 된다. 그냥 EKS 클러스터에 대해 시간당 0.1 달러만 지불하면 된다. (물론 노드 인스턴스 비용과 데이터 전송 비용 별도)

하지만 데이터 플레인에서 발생하는 서비스 영역에 대한 비용은 고객 책임 영역에 따른다. 이는 고객 VPC에 구축된다.

2. EKS 아키텍처 - Control Plane

Control Plane은 AWS가 관리하는 VPC에 생성되는데, 3개의 AZ 위에 API Server와 ETCD 서버가 있다. 두 컴포넌트는 Auto Scaling으로 구성되어 있고 API Server는 2개 이상, ETCD 서버는 3개 이상으로 가용성을 높여 준다. 게다가 CPU, 메모리 사용량에 따라 스케일 업/다운까지 하게 되는데 사용자는 이에 대한 추가 비용도 지불하지 않아도 된다. API Server 앞에는 NLB가 배치되어 있는데 이는 각 AZ마다 하나씩 배치되어 있다고 한다. 이는 ALB보다 NLB가 성능이 더 우수하다는 이유로 추정할 수 있다는데 아직 나는 정확한 이유는 모르겠다. AWS는 고가용성와 퍼포먼스에 진심인 것 같다. 이러한 점에 있어 AWS가 범용적으로 사용되는 이유를 알 수 있다.

EKS 클러스터 생성

기본 인프라는 가시다님이 클포로 공유해 주셨다. 구성도는 아래와 같다.

AZ 2, Public Subnet 2, Private Subnet 2로 구성되어 있고 작업용 EC2는 myeks-PublicSubnet1에 배치했다. 이 서버에서 eksctl로 클러스터를 생성해 볼 것이다.

감사하게도 이 서버에는 클러스터를 구성하기 위한 기본 도구들이 설치되어 있다. (kubectl, eksctl, aws, docker 등)

export로 필요한 환경변수를 구성해 준 뒤에

[root@myeks-host ~]# echo $AWS_DEFAULT_REGION
ap-northeast-2
[root@myeks-host ~]# echo $CLUSTER_NAME
myeks
[root@myeks-host ~]# echo $VPCID
vpc-0d70aab310760a33a
[root@myeks-host ~]# echo $PubSubnet1,$PubSubnet2
subnet-001255bd7b02ca5ff,subnet-08e440adb0add44cd

아래와 같이 eksctl 도구를 사용하여 버전 1.28 클러스터를 퍼블릭 존에 배포할 것이다.

eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \\
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.28 --ssh-access --external-dns-access --verbose 4

관리형 노드 그룹으로 사양을 지정하고 아까 만들어 둔 Public Subnet1,2에 생성하였다.

작업 EC2에서 노드로 접근하기 위해 ssh 접근을 허용해 줬다

그리고 external dns를 사용하기 위해 IAM Policy를 enable해 줬다.

EKS 배포는 10-15분 정도 소요되는 것 같다 AWS는 자동화가 많이 되어 있어서 eksctl로 EKS를 배포하게 되면 클라우드포메이션을 사용하게 된다. 위에서 추가해 줬던 옵션들도 각 리소스가 자동생성되게 구성되어 있는데 이는 아래에서 확인해 볼 것이다.

시간이 지나서 클러스터가 생성되면 구성도는 아래처럼 된다

클러스터 생성 확인

AWS 콘솔에서 EKS에 들어가면 잘 생성된 것을 확인할 수 있었다.

그 중에서 API 서버 엔드포인트가 보였다 사용자는 이 서버에 kubectl 도구로 API 요청을 주로 보낸다.

dig 도구로 엔드포인트를 조회해 보면 IP 두 개가 출력된다.
조회되는 바로 이 IP가 현재 Control Plane 위에서 생성된 API Server 두 대의 IP이다.

서버 주소만 curl 날려 보면 권한이 없고 version 확인은 가능하다. (두 IP 모두 결과는 같다)

이는 사실 kubectl version으로 확인한 결과값과 동일하다. kubectl 도구로 API Server에게 받아온 결과이기 때문이다.

퍼블릭 존에 구성한 클러스터의 구성도를 참고해 보면 API Server의 endpoint가 바로 저 Public IP라고 표시되어 있는 도메인 주소이다.

EKS Node Role

아까 external dns 사용을 위한 IAM Policy를 추가해 주는 부분이 있었다.

이를 확인하기 위해 생성된 노드의 IAM 역할을 보자

eksctl-myeks-nodegroup-myeks-nodeg-NodeInstanceRole-5j44alSi46Rr가 자동으로 붙어 있다.

자동으로 6개의 정책이 들어가 있는데 마지막 두 줄이 바로 아까 --external-dns-access 이 옵션으로 인해 추가 생성된 정책이다. 새롭게 추가된 거라 고객 인라인 정책으로 생성돼 있다.

내용을 확인해 보면 route53 조회 권한과 레코드 변경 권한이 들어가 있다

이렇게 자동 생성되는 부분들을 보면 AWS가 유저에게 편리함을 가져다 주는 부분이 많다고 생각된다. 이래서 AWS 쓰나보다..!

EKS SG

작업 EC2의 SG를 제외하고 클러스터에 대해 자동 생성된 SG는 위 표와 같다 아웃바운드는 다 any 오픈되어 있다.

1. eksctl-myeks-cluster-ControlPlaneSecurityGroup Controle Plane과 노드 사이의 통신을 위함인데 인바운드 설정이 없다. 클러스터가 퍼블릭존에 위치하고 있기 때문인줄 알았는데 프라이빗으로 변경해도 동일하다. 테스트해 보면서 확인해 봐야 겠다
2. eksctl-myeks-cluster-ClusterSharedNodeSecurityGroup 클러스터 내의 모든 노드끼리 통신하기 위함이다.
3. eksctl-myeks-nodegroup-myeks-nodegroup-remoteAccess SSH 허용을 해줬기 때문에 ssh 22 오픈으로 자동 생성되었다.
4. eks-cluster-sg-myeks EKS owned ENI를 통해 Controle Plane과 통신하기 위함이다.

EKS API Server Endpoint Access

클러스터 엔드포인트를 변경하면 아키텍처가 변경된다. 지금 배포한 것이 퍼블릭이고 아래 두 가지가 더 있다.

1. 퍼블릭 및 프라이빗

   

2. 프라이빗

   

이는 API Server에 요청하는 플로우랑 Control Plane과 Node 사이에 통신 플로우가 달라진다. EKS 네트워크 부분에서 더 살펴볼 예정이다!

마지막에 프라이빗으로 엔드포인트 변경해 봤다가 API Server로 요청 전달이 안되어 삭제를 못했다. 아무래도 작업 EC2에서의 IP를 보안그룹에 안넣어줬기 때문인 것 같다.

일단 비용때문에 급하게 콘솔에서 삭제했다.

출처 ) AWS 자료 출처 ) 가시다님 노션