[AWS] EKS 서비스 사용법 및 예제
[AWS] EKS 서비스 사용법 및 예제
안녕하세요? 정리하는 개발자 워니즈 입니다. 요즘 제가 속한 프로젝트에서 기존 서비스들을 도커로 전환하는 작업을 하고있습니다. 아직 구체적인 아키텍처가 나온것은 아니지만, 인프라를 아마존을 사용하기에 ECS, EKS를 최대한 도입하려는 방향으로 움직이고 있습니다.
그에따라, 지난 ECS에 이어서 이번시간에는 EKS가 어떤 서비스인지, 그리고 어떻게 사용하는지 간단한 에제를 통해서 알아보도록 하겠습니다.
1. EKS란? (Amazon Elastic Kubernetes Service)
Amazon Elastic Kubernetes Service(Amazon EKS)는 Kubernetes 제어 플레인을 설치하고 운영할 필요 없이 AWS에서 Kubernetes를 손쉽게 실행하도록 하는 관리형 서비스입니다. Kubernetes는 컨테이너화된 애플리케이션의 배포, 조정 및 관리 자동화를 위한 오픈 소스 시스템입니다.
EKS는 사용자를 위해 여러 AWS 가용 영역 전체에서 Kubernetes 관리 인프라를 운영하여 단일 장애 지점을 제거 합니다.
EKS를 사용하는 가장큰 이유는 아마존에서 관리해주는 Managed 서비스 이기 때문에 Kubernetes Master를 운영자가 직접 관리하거나 신경을 쓸일이 없습니다.
장점은 아래와 같이 정리를 해볼 수 있습니다.
- 전 가용영역 내에 인프라 관리
- 비정상 노드 탐지 및 교체
- 온디맨드 업그레이드 및 패치
- 마스터노드와 워커(데이터)노드 사이에 암호화된 보안 통신 채널이 자동으로 설정되어 보안강화
필자가 직접 사용해보니, 무엇보다도 아마존에서 제공해주는 ELB, IAM, VPC등 특정 기능들과 상호작용하며 사용할 수 있어 무척 간편합니다.
2. 작동 방식
위의 그림에서 보듯이 다음의 순서로 진행이 됩니다.
- EKS 클러스터 프로비저닝
우선 AWS Management 콘솔이나 AWS CLI 또는 AWS SDK 중 하나를 사용하여 Amazon EKS 클러스터를 생성합니다.
- 워커 노드 배포
작업자 노드를 시작하여 Amazon EKS 클러스터를 등록합니다. 노드를 자동으로 구성하는 AWS CloudFormation 템플릿이 제공됩니다.
- EKS 와 연결
클러스터가 준비되면 원하는 Kubernetes 도구(예: kubectl)를 사용하여 클러스터와 통신할 수 있습니다.
- 애플리케이션 실행
다른 Kubernetes 환경에서와 마찬가지로 Amazon EKS 클러스터에 애플리케이션을 배포 및 관리합니다.
3. 실습 예제
EKS 도 결국에는 클러스터링을 지원해주고, 손쉽게 배포, 관리, 운영을 할 수 있는 것입니다.
필자가 생각하기에는 ECS 와 크게 다르지는 않지만, Kubernetes를 사용 할 수 있다는 장점이 있습니다.
3-1. 역할 생성
EKS는 IAM을 통해서 권한을 부여받지 않은 경우 다른 클러스터 또는 다른 AWS 계정의 통신을 보거나 수신할 수 없습니다.
IAM>Roles>Create role의 서비스 목록에서 EKS를 선택하고 사용사례에 “EKS에서 사용자를 대신하여 클러스터를 관리하도록 허용”을 선택하고 마지막 단계에서 역할이름에 “eksrole”을 입력하고 역할생성을 합니다.
3-2. 클러스터 용 VPC 생성
아마존에서 제공하는 쿠버네티스 구성은 CloudFormation을 이용하여 생성합니다.
- VPC
- Subnet
- Security Group
- Cloud Formation>Create stack>템플릿 선택: Amazon S3 템플릿 URL 지정을 선택하고 아래 URL을 붙여 넣습니다.
https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-01-09/amazon-eks-vpc-sample.yaml
주의! 2019-01-09 이전 날짜의 템플릿파일을 서울리전에서 사용시 오류가 있습니다. (3번째 AZ가 없는 관계로)
- 세부정보지정 페이지에서 스택이름 예:”first-eks-stack”를 입력합니다. VPC주소범위나 Subnet 주소범위도 여기서 지정할 수 있습니다.
-
마지막 단계에서 Create를 선택하면, 자동으로 VPC, Subnet, Security Group이 생성됩니다.
3-3. kubectl 설치 및 설정
- Amazon EKS용 kubectl 설치
여기서는 관리자용 클라이언트로 별도의 EC2를 생성하여 설치하도록 하겠습니다.
별도의 계정이나 VPC에서 Amazon Linux 2 AMI로 저사양의 EC2를 먼저 생성하고 SSH접속 후 아래 과정대로 진행합니다.
필자 같은 경우는 EC2를 신규로 생성하되, Amazon에서 제공해주는 EKS 용 ami를 이용해서 생성하였습니다.
amazon-eks-node-1.11-v20190220 (ami-07fdc9272ce5b0ce5)
만약, 신규 ec2를 생성하고 직접 Kubernets를 설치시에는 다음의 과정이 필요합니다.
- Linux 환경에서 kubectl 설치
# curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.11.5/2018-12-06/bin/linux/amd64/kubectl
# chmod +x kubectl
# mv kubectl /usr/bin/
# kubectl version –short –client
Client Version: v1.11.5
- aws-iam-authenticator 설치
# curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.11.5/2018-12-06/bin/linux/amd64/aws-iam-authenticator
# chmod +x aws-iam-authenticator
# mv aws-iam-authenticator /usr/bin/
# aws-iam-authenticator help
Kubernetes 버전 1.10부터 Kubernetes용 AWS IAM Authenticator를 설치하고 인증에 사용할 kubectl 구성 파일을 사용하여 Amazon EKS를 사용할 kubectl 클라이언트를 구성할 수 있습니다.
3-4. Amazon EKS 클러스터 생성
AWS CLI로도 생성이 가능하지만 여기서는 Amazon콘솔의 Service>EKS에서 [Create cluster]를 선택합니다. 여기서 생성되는 EKS Control Plane는 시간 당 $0.20(약 $150/월) 비용이 발생합니다.
주의! EKS 클러스터 생성시 반드시 쿠버네티스 버전은 master 노드에 설치된 쿠버네티스 버전과 맞추어 줍니다.
클러스터 생성은 약 5-10분 정도 소요되는데, 생성이 완료되어도 사용자의 콘솔에서는 EKS Control Plane을 구성하는 리소스들이 보이지 않습니다.
다만, 클러스터의 Worker Node에 attach될 ENI가 각 AZ마다 1개 생성된 것은 볼 수 있습니다.
3-5. Amazon EKS용 kubectl 구성
초기에 kubectl 을 설치했던 EC2로 접속해서 configuration 셋팅을 해주어야 합니다.
aws cli를 통해서 kubeconfig를 셋팅해주기때문에 aws cli가 정상적으로 셋팅되어있어야합니다.
앞에서 준비한 관리자용 클라이언트 EC2에서 AWS CLI의 버전을 확인해 봅니다. 1.16.18버전 이상이 설치되어 있지 않다면, 아래 명령어로 설치 혹은 최신 버전으로 업그레이드합니다.
# aws –version
aws-cli/1.15.83 Python/2.7.14 Linux/4.14.77-70.59.amzn1.x86_64 botocore/1.10.82
# pip install awscli –upgrade –user
# aws –version
aws-cli/1.16.91 Python/2.7.14 Linux/4.14.77-70.59.amzn1.x86_64 botocore/1.12.81
클러스터를 생성한 계정의 IAM유저의 보안자격증명을AWS CLI에 설정합니다.
# aws configure
AWS Access Key ID [None]: AKIAIHE#########FELA
AWS Secret Access Key [None]: uqm8MSDK######################Ddz29PcAz5
Default region name [ap-northeast-2]:
Default output format [None]:
# aws sts get-caller-identity
{
“Account”: “4952894#####”,
“UserId”: “AIDAJU5LO##########LQ”,
“Arn”: “arn:aws:iam::4952894#####:user/[username]”
}
AWS CLI update-kubeconfig 명령을 사용하여 클러스터에 대한 kubeconfig를 생성하거나 업데이트합니다.
# aws eks update-kubeconfig –-name first-eks-cluster
Added new context arn:aws:eks:ap-northeast-2:49528#######:cluster/first-eks-cluster to /root/.kube/config
# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 1m
config 업데이트 부분에서 상당히 애를 먹었습니다.
계속해서 다음과 같은 메시지가 나왔습니다.
ould not get token: AccessDenied: Access denied
status code: 403, request id: 6ceac161-ff2f-11e8-b263-2b0e32831969
Unable to connect to the server: getting token: exec: exit status 1
/root/.kube/config 컨피그 파일에서 아래의 내용을 주석 처리 하여 인증이 안타도록 임시 조치 하였습니다.
#- -r
#- arn:aws:iam::XXXXXXXXX:role/eks-dev-role (the role you made for eks)
command: aws-iam-authenticator
3-6. Amazon EKS작업자 노드 구성
클러스터용 VPC와 Kubernetes 제어 플레인이 생성되었고 kubectl이 설치 및 구성이 되었으므로 이제 Worker Node를 구성할 수 있습니다. Worker Node를 구성하면 EC2인스턴스들이 생성되므로, 제어 플레인 $0.20/hours 비용 외에 추가로 EC2 인스턴스 비용이 청구됩니다.
Cloud Formation>스택>[Create stack]을 선택합니다.
https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-01-09/amazon-eks-nodegroup.yaml
파라미터들을 입력해주되, 중요한것은 초기에 생성했던 EKS 클러스터 네임을 정확하게 젂어 주어야 한다. 위의 이미지에서는 나오지 않았지만, 입력란에 first-eks-cluster라는 필자가 생성했던 네임을 정확하게 입력해주었습니다.
스택이 생성된 후 출력 탭을 선택하여 NodeInstanceRole을 메모하여 나중에 Amazon EKS 작업자 노드를 구성할 때 사용합니다.
3-7. 워커노드를 클러스터에 조인
지금까지 된 작업은
- vpc, subnet, itgw, router, security group 생성
- 제어 플레인 생성 kubectl 설치 및 configuration
- EKS cluster 생성(빈껍데기)
- worker node 생성
이제 cluster 쪽으로 worker node들을 join 시켜 클러스터링을 구성하면된다.
# curl -O https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-01-09/aws-auth-cm.yaml
# vi aws-auth-cm.yaml <- 위에서 메모한 NodeInstanceRole를 rolearn의 값으로 교체 후 저장
# kubectl apply -f aws-auth-cm.yaml
configmap/aws-auth created
# kubectl get nodes –watch
NAME STATUS ROLES AGE VERSION
ip-192-168-122-60.ap-northeast-2.compute.internal Ready 2m v1.11.5
ip-192-168-132-24.ap-northeast-2.compute.internal Ready 2m v1.11.5
ip-192-168-177-2.ap-northeast-2.compute.internal Ready 2m v1.11.5
잠시 후, 노드의 상태가 Ready가 되면 정상적으로 적용된 것입니다.
최종적인 아키텍처는 위와 같습니다.
- EKS Control Plane
- Worker Node
위의 2가지가 중요하고 중간에 kubectl-kublet 을 통해서 제어를 합니다.
3-8. 샘플 애플리케이션 시작해 보기
샘플 게스트 북 애플리케이션을 생성해서 생성한 클러스터를 확인해 봅니다. 아래 명령을 차례로 진행합니다.
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/v1.10.3/examples/guestbook-go/redis-master-controller.json
replicationcontroller/redis-master created
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/v1.10.3/examples/guestbook-go/redis-master-service.json
service/redis-master created
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/v1.10.3/examples/guestbook-go/redis-slave-controller.json
replicationcontroller/redis-slave created
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/v1.10.3/examples/guestbook-go/redis-slave-service.json
service/redis-slave created
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/v1.10.3/examples/guestbook-go/guestbook-controller.json
replicationcontroller/guestbook created
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/v1.10.3/examples/guestbook-go/guestbook-service.json
service/guestbook created
# kubectl get services -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
guestbook LoadBalancer 10.100.110.135 a5baba20e22cf11e9845d0a50976ac11-468761890.ap-northeast-2.elb.amazonaws.com 3000:31955/TCP 30s app=guestbook
kubernetes ClusterIP 10.100.0.1 443/TCP 5h
redis-master ClusterIP 10.100.125.201 6379/TCP 1m app=redis,role=master
redis-slave ClusterIP 10.100.169.153 6379/TCP 47s app=redis,role=slave
위의 yml 파일중에서 guestbook-service.json은 Load Balancer 타입의 service를 생성하고 이는 aws의 ELB를 생성하고 동적으로 port를 매핑해서 서비스를 합니다.
4. 마치며..
지난시간의 ECS에 이어서 이번시간에는 EKS를 알아봤습니다. 사실 실습을 진행하면서 아직도 의문인 부분이 몇가지 있습니다. 왜 Control Plane을 직접 EC2를 생성해서 설치해야되는지, 그리고 EKS에서 클러스터링을 구성할때 왜 ECS처럼 한번에 생성하게 끔 만들어두지는 않았는지 하는 생각들이 많이 듭니다.
개인적으로 편의성 면에서는 ECS가 좀더 안정화되어 있는것 같습니다. 초기 셋팅이 아무래도 좀더 편한것 같습니다.
다만, EKS는 쿠버네티스로 운영을 할 수 있다는 장점이 있는것 같습니다. 단순히 쿠버네티스를 사용하는것이 아니라, 쿠버네시트에서 제공해주는 스케쥴러, configMap, secret등 다양한 Object들을 연계해서 사용하면 각 서비스들을 좀더 안정적으로 운영 할 수 있다는 생각이 듭니다.
다음시간에는 kubernets에 대해서 좀더 알아보는 시간을 갖도록 하겠습니다.
