EKS(Elastic Kubernetes Service) 는 Kubernetes 를 실행해주는 프로덕션 환경의 관리형 서비스로, 사용자를 대신해 제어 플레인 또는 노드 설치, 작동 및 유지 관리를 한다. 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 커뮤니티의 모든 기존 플러그인과 도구도 사용할 수 있다. AWS 서비스들과의 통합이 쉽지만 기본적으로 IAM, VPC, ECR, ALB 등이 함께 사용되기 때문에 사전 숙지가 필요하다. 가장 중요한 쿠버네티스 사용법 역시 공식 사이트를 보면 자세하게 설명이 잘 되어 있지만, 분량도 많고, 테스트 환경 기반이다보니 막상 프로덕션 환경에서 사용하려고 하면 머릿속이 하얘지는... 사실 ECS/EKS 의 큰 차이는 모르겠다. ECS 를 잘 써왔는데 굳이 EKS 를 쓰려는 이유는 그냥 한번 써볼라꼬. 난 그저 컨테이너 자동 복구, 무중단 배포, 오토 스케일링만 잘되면 된다. 쿠버네티스를 모르더라도 EKS 를 잘 쓸 수 있는지 EKS 가이드를 참고하여 Fargate 위주로 제가 한번 먹어보겠습니다.

주의해야 할 것은 AWS 문서는 한글판에만 의존해서는 안된다. 영문판보다 버전도 낮고 번역이 정반대인 경우도 있고, 예제의 경우 시나리오 중간중간 버전이 혼용되는가 하면... 등의 이유로 영문판과 함께 보기를 권장한다. 덕분에 예상치 못한 에러들이 발생해서 도움이 많이 됐다...;

클러스터

EKS 를 시작할 때, 가장 먼저 해야할 일이 클러스터를 생성하는 것이다. 이 안에 제어영역(Control Plane) 과 해당 노드가 포함된다.

클러스터 생성 방법1)

클러스터 관리가 가능한 eksctl 명령 도구를 사용하는 방법이다. 

- eksctl 설치 : https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html

$ eksctl create cluster \
--name my-cluster \
--region us-west-2

생략된 옵션이 매우 많다. eksctl 은 이런 식으로 줄줄줄 써 내려가거나 yaml 파일로 만들어서 관리할 때 유용한 툴이다. 위처럼 간단하게 명령해도 CloudFormation 을 이용한, 이미 준비된 완벽한 클러스터가 만들어진다.(약 20분 소요) 한번에 클러스터가 만들어진다는 장점은 있지만, 이 때 필요한 IAM 권한이나 VPC 등이 생성되고 연동되는 과정이 보이지 않으므로 잘 살펴보아야 한다. 오히려 초보자에게는 방법2) 가 더 유용할 수 있다. 

옵션을 나열하고 --dry-run 옵션까지 추가하면 지정한 옵션과 default 옵션으로 만들어질 항목들을 클러스터 생성없이 테스트 해볼 수 있고, yaml 파일로 만들어서 유지관리 할 수도 있다.

$ eksctl create cluster --dry-run > config.yaml

클러스터 생성 방법2)

AWS 관리콘솔로 클러스터를 생성하는 방법이다. 보기도 편하고 필수항목들이 준비되지 않으면 진행되지 않는다. IAM role(AmazonEKSClusterPolicy) / VPC / 보안그룹 등이 준비되어 있어야 한다. 보안그룹은 일단 공개, VPC 는 Fargate 의 경우 private 서브넷을 반드시 필요로 하므로 public/private 서브넷을 모두 구성한다.(약 10분 소요)

Fargate 프로파일

클러스터는 생성되었지만, 막상 클러스터를 선택해 세부정보를 보면 node 도 보이지 않고, DNS 서버인 CoreDNS 도 대기(pending) 상태임을 워크로드에서 확인할 수 있다. Fargate 에서 pod 를 실행시키려면 Fargate 프로파일을 생성해서 워크로드의 deployment 들과 매칭이 필요하다. CoreDNS 가 작동할 수 있도록 AWS 관리콘솔에서 Fargate 프로파일을 생성한다. 이 때도 AM 에서 pod 실행 역할(AmazonEKSFargatePodExecutionRolePolicy) 을 생성하고 연결해 주어야 한다. pod 를 생성할 서브넷도 선택하고, 워크로드의 coredns 에서 네임스페이스와 선택기(레이블) 을 확인하여 네임스페이스 또는 네임스페이스+선택기(레이블) 이 일치하도록 Fargate 프로파일을 생성한다.

이 단계에서는 Fargate 프로파일에 namespace: kube-system 만 생성해도 CoreDNS 와 매칭된다. 

그리고 eksctl 의 --fargate 옵션으로 클러스터를 설치하지 않으면 CoreDNS 의 기본값은 EC2 를 사용하도록 구성되기 때문에, CoreDNS deployment 의 해당 구성 부분을 삭제해 주어야 한다. 또한 그 전에 클러스터와의 통신을 위해 kubectl 툴을 사용할 수 있도록 kubeconfig(~/.kube/config) 를 구성한다.

- kubectl 설치 : https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html

앞으로의 kubectl 명령이 클러스터와 통신하도록 kubeconfig 구성

$ aws eks update-kubeconfig --region <region> --name <cluster>

coredns 설정에서 ec2 구문 제거

$ kubectl patch deployment coredns \
-n kube-system \
--type json \
-p='[{"op": "remove", "path": "/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

기존 파드를 삭제하고 다시 생성

$ kubectl rollout restart -n kube-system deployment coredns
deployment.apps/coredns restarted

coredns 배포 확인

$ kubectl get -n kube-system deployment coredns 
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
coredns   2/2     2            2           6d23h

2개의 pod가 준비 완료되면 클러스터 생성부터 CoreDNS pods 띄우는 것까지 성공한 것이다. 만약 CoreDNS 가 정상적으로 생성되지 않았다면 IAM / VPC / Fargate 프로파일을 다시 살펴보아야 한다. Fargate 프로파일은 한번 생성하면 수정할 수 없으므로, 수정이 필요하다면 새로 생성하여 업데이트한 후에 원본을 삭제해야 한다.

리소스 생성/삭제 시간이 생각보다 길어 테스트 과정이 상당히 지루했다. 앞으로 할일은 EKS 에서 nginx 화면을 브라우저에서 확인하기?

쿠버네티스에서는 배포 방법으로 블루/그린 배포, 카나리 배포, 롤링 업데이트 등을 사용할 수 있다. 롤링 업데이트 방식은 운영중인 어플리케이션의 파드 수를 하나씩 줄이고, 새로운 어플리케이션의 파드 수를 하나씩 늘려가며 변경하는 방법이다. 쿠버네티스는 어플리케이션 이미지를 업데이트 하면 롤링 업데이트 방식으로 배포를 진행할 것이다. 쿠버네티스에서 배포 업데이트는 버전으로 관리되고, 이전의 안정적인 버전으로도 복구가 가능하다.

다음 테스트는 kubernetes-bootcamp:v1 이미지를 사용 중인 서비스 환경에서 v2 이미지로 교체하였을 때 어플리케이션의 배포 진행을 파악하고, 다시 v1 이미지로 복원하는 시나리오 이다.

4개의 파드에 kubernetes-bootcamp:v1 이미지를 구동하여, 이미 서비스로 운영중임을 확인.

해당 deployment 에 어플리케이션 이미지를 교체할 때,  kubectl edit deployment  명령을 사용하거나  kubectl set image  명령을 사용할 수 있다.

위 명령은 deployment 에 다른 이미지를 사용하도록 변경하고, 롤링 업데이트를 시작하도록 한다. 업데이트 확인.

잠시 후에 서비스 ip 로 접근해 보면, 다음과 같이 새로운 v2 버전의 파드에 로드 밸런싱 되는 것을 확인할 수 있다.

그렇다면 업데이트 과정을 살펴보자.

새로 생성된 ReplicaSet(5bf4d5689b) 의 파드 수가 하나씩 늘어나고, 동시에 ReplicaSet(6bf84cb898) 의 파드 수가 줄어들며 롤링 업데이트가 진행되는 것을 확인할 수 있다. 

만약에 경우에 이전 버전의 업데이트로 돌아가려면  rollout undo  명령으로 가능하다.

여기서 또 다시 rollout undo 명령을 실행하면 v1 버전보다 더 예전의 업데이트가 아닌 바로 전인 v2 버전으로 다시 돌아가는 것에 주의하자.

파드에서 어플리케이션이 비정상 작동을 할 경우에 대비하여 Liveness/Readiness Probe 를 설정할 수 있다. Liveness Probe 는 컨테이너가 정상적으로 구동 중 인지를 체크할 수 있다. 결과가 정상이 아니면 컨테이너를 재시작한다. Readiness Probe 는 파드가 트래픽을 처리할 준비가 되어 있는지를 체크한다. 결과가 정상이 아니면 해당 파드는 로드밸런스에서 제외된다. 두가지 Probe 에 대하여 설정한 대로 노드의 kubelet 이 주기적으로 상태 체크를 하게 되며, 결과가 비정상일 경우 해당 파드는 not ready 상태로 변경된다. 

아래처럼 readiness/liveness probe 를 가진 파드를 생성해 보자.

각 Liveness/Readiness Probe 에 대해서 체크하는 방법으로는 Command / HTTP / TCP 등이 있는데 위 예제에서는 HTTP 를 사용하였다. livenessProbe 의 경우 http://ip:81/healthz 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. readinessProbe 도 마찬가지로 http://ip:81/readiness 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. initialDelaySeconds 는 컨테이너가 준비되고 probe 를 실행하기 까지의 대기 시간이다. periodSeconds 는 probe 체크를 반복할 시간 설정이다. 

Liveness 테스트

아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 컨테이너의 restart 카운팅이 늘어나며, 컨테이너가 자동으로 재시작 될 것이다.

Readiness 테스트

아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 해당 파드는 not ready 상태가 되며 로드밸런스에서 제외되는데, 로드밸런스 테스트는 생략한다 ^^;

Google Cloud Platform 에서 쿠버네티스를 운영하기 위한 방법으로 Kubernetes Engine 과 Kubernetes API 를 사용하여 어플리케이션을 배포 및 관리 할 수 있다. 간단하게 쿠버네티스를 이용하여 어플리케이션을 테스트 해보자.

GKE(Google Kubernetes Engine) 를 사용하여 쿠버네티스 클러스터 생성

kubectl 를 사용하여 Docker 컨테이너를 배포 및 관리

쿠버네티스의 Deployment 와 Service 를 사용하여 마이크로 서비스로 어플리케이션 분리

1. 구성 연결

GCP 콘솔의 APIs & services 에서 Kubernetes Engine API 와 Container Registry API 이 활성화 되어 있는지 체크하고, Cloud Shell 이나 Cloud SDK 를 사용하여 GCP 계정, 프로젝트, zone 설정 등을 확인한다.

2. 클러스터-노드 생성

위의 명령으로 클러스터(bootcamp) 와 node 가 5개 생성된다. --scopes 인수는 나중에 사용할 프로젝트 호스팅과 Google Cloud Storage API 에 대한 액세스를 제공한다.

GCP 콘솔에서 확인하고 싶다면 클러스터는 [Kubernetes Engine > Cluster], 노드는 [Compute Engine > VM Instances] 에서 확인할 수 있다. 아래 예제처럼 GCP 콘솔에서 직접 클러스터를 생성할 수도 있다.

3. 어플리케이션 배포

위 명령으로 nginx 컨테이너를 담은 파드가 생성되고 노드에 배치됐다.

4. 서비스 생성 (외부IP 노출)

위 명령으로 LoadBalancer 타입의 서비스를 생성하여 nginx 컨테이너를 외부에서 접근할 수 있게 한다. 생성된 External-IP 와 port 는 서비스가 유지되는 동안만 유효하다. (External-IP 생성에 일정 시간이 소요될 수 있음)

5. pod 수 확장

위 명령은 생성해 놓은 nginx 배포(deployment) 의 pod 수를 3 개로 늘린다. 마스터는 요청에 따라 적절한 노드를 찾아 2개의 파드를 각각 추가로 배치한다. 트래픽이 많거나 적을 경우 위와 같이 파드 수를 늘리거나 줄일 수 있다.

6. 어플리케이션 테스트

7. 삭제

파드나 서비스를 더 이상 사용하지 않을 경우 아래와 같이 삭제한다.

hello minikube 글에서 어플리케이션 배포부터 노출까지 알아봤었는데 그 때의 배포 명령이 기억 나는가?

위와 같이 kubectl create deployment 명령 다음에 배포에 관련된 정보나 상태 등의 spec 을 inline 으로 나열하였었다. 명령의 이러한 파라미터들은 JSON 형식으로 변환되어 쿠버네티스 API 로 전달된 후 처리된다. 이렇게 kubectl 명령에 inline 으로 파라미터나 플러그 등을 나열하는 것을 명령형(Imperative) 커맨드라고 하며, 주로 일회성 작업을 할 때 사용한다. 나열될 파라미터 수가 적을 때 사용하면 유용하다.

또 한가지 배포에 관련된 정보나 상태 등의 spec 을 상세하게 나열하는 대신 파일(.yaml) 안에 정의하는 방법을 사용할 수도 있는데, 이것을 명령형 오브젝트 구성(Imperative object configuration) 이라고 한다. 다음과 같이 로컬 파일이나 url 상의 파일을 지정하여 사용할 수 있다.

위 yaml 예제 파일에는 다음과 같이 3개의 nginx 파드를 생성하는 내용이 담겨 있다.

.yaml(야믈) 파일은 위처럼 공백 문자를 이용한 들여쓰기로 구조체를 구분하며, 리스트, 해시, 스칼라 데이터의 조합을 모두 표현할 수 있다. 각 항목들을 살펴보면 통신할 api 버전, 생성할 오브젝트 종류, 이름, 식별자, 파드 수, 어플리케이션 이름, 컨테이너 이미지 정보, 연결포트 등이 정의되어 있으며, 쿠버네티스 API 는 이 정의대로 Deployment 를 생성하게 된다. 운영시에는 inline 방식의 명령형 커맨드 보다는 .yaml 파일에 오브젝트를 정의하는 명령형 오브젝트 구성을 주로 사용하게 되며, 위처럼 아주 깔끔하고, 명확하게 오브젝트의 의도를 한눈에 파악할 수 있다. 물론 .yaml 파일을 작성하는 방법이나 오브젝트 정의 방법을 숙지해야 하는 것은 함정!

오브젝트 정의 방법을 간단하게 살펴보자.

쿠버네티스에서 가장 중요한 것은 무엇일까. 아마도 위에 정의한 것 처럼 사용자가 원하는 리소스 및 스펙이 계속해서 유지되는 것이 가장 중요할 것이다. 즉, 사용자가 바라는 상태(desired state) 를 계속해서 유지해야 한다. 배포될 어플리케이션(pod)의 워크로드 정보를 나타내는 클러스터 정보(namespace), 네트워크(service), 디스크 리소스(volume) 를 쿠버네티스의 기본 오브젝트라고 한다. 또한 기본 오브젝트들을 편리하게 관리하기 위한 컨트롤러들이 있다. 파드 복제 수(ReplicaSet), 배포(Deployment), 상태관리API(StatefulSet), 파드를 모든 노드에 복제(DaemonSet), 단일실행(Job) 들이 그것이다. 이러한 오브젝트들은 위와 같이 .yaml 파일에 정의하여 생성/업데이트/삭제 등의 관리를 할 수 있다.

아래는 오브젝트 정의에 필요한 필수 요소이다.

• apiVersion - 이 오브젝트를 생성하는데 사용할 API 버전
• kind - 생성할 오브젝트 종류
• metadata - 오브젝트를 식별할 수 있는 고유 이름
• spec - 오브젝트 특유의 중첩된 필드를 포함하며, 오브젝트마다 정확한 포맷이 다르므로 관리할 오브젝트의 spec 포맷을 확인한다.

위의 deployment 오브젝트 정보를 담은 .yaml 파일을 실행하면 아래와 같이 nginx 를 구동하는 3개의 파드가 생성된 것을 확인할 수 있다.