$ kubectl apply -f sample-service.yaml
Service/nlb-sample-service created
4. 서비스 확인
$ kubectl get svc nlb-sample-service -n nlb-sample-app
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sample-service LoadBalancer 10.100.240.137 k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com 80:32400/TCP 16h
여기까지 진행하였으면, AWS 관리콘솔에서 [로드밸런서] 와 [대상 그룹] 이 정상적으로 구동되었는지 확인한다.
로드밸런서 : DNS 이름 / network 유형 / internet-facing 체계
대상그룹 : 80 port / TCP protocal / IP target / Health status
5. 결과 확인
상단 EXTERNAL-IP 의 DNS 주소로 curl 이나 browser 를 사용하여 nginx 첫 페이지를 확인한다.
AWS 로드 밸런서 컨트롤러는 k8s ingress 를 생성할 때 ALB(Application Load Balancer) / NLB(Network Load Balancer) 를 생성해 주고 관리한다. ALB / NLB 가 필요하다면 배포해야 하는데 EKS 와 k8s 간에 로드 밸런서 관리 권한을 연결해야 한다. eksctl + cloudFormation 으로 자동 생성할 수도 있지만, aws 관리콘솔 + awscli + kubectl 을 사용하여 수동 설정했다.
여기까지의 작업으로 쿠버네티스의 ServiceAccount 는 AWS 의 AmazonEKSLoadBalancerControllerRole 역할을 얻게 되었고, ingress 와 loadbalancer 에 대하여 AWS 에 ALB 와 NLB 를 각각 생성/관리할 수 있게 되었다.
Load Balancer Controller 설치
Fargate 에 컨트롤러를 배포할 때는 cert-manager 에 의존하지 않기 때문에 Helm차트를 사용하여 설치한다. Helm 은 Kubernetes 클러스터에서 사용하는 패키지 관리자로 yum, apt 와 흡사하며, 흔히 나오는 차트라는 단어는 helm 패키지라고 이해하면 된다.
컨트롤러 설치시 account 를 accountId 로 착각해 주소가 다르다는 오류를 발생시켰었다. AWS Load Balancer Controller, Amazon VPC CNI, kube-proxy, CoreDNS 등의 ECR 저장소를 이용할 때 주소가 리전마다 다르므로 주의한다.
$ helm install aws-load-balancer-controller...
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: ClusterRole "aws-load-balancer-contro
ller-role" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kuber
netes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "aws-load-balancer-controll
er"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"
Kubernetes manifest 를 적용하여 설치했다가 이미 필요한 설정값들이 달라 발생한 오류. 재설치 하면서 발생하는 기존 리소스들 전부 찾아서 삭제하고 OK 떨어질때까지 반복하면서 해결.
EKS(Elastic Kubernetes Service) 는 Kubernetes 를 실행해주는 프로덕션 환경의 관리형 서비스로, 사용자를 대신해 제어 플레인 또는 노드 설치, 작동 및 유지 관리를 한다. 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 커뮤니티의 모든 기존 플러그인과 도구도 사용할 수 있다. AWS 서비스들과의 통합이 쉽지만 기본적으로 IAM, VPC, ECR, ALB 등이 함께 사용되기 때문에 사전 숙지가 필요하다. 가장 중요한 쿠버네티스 사용법 역시 공식 사이트를 보면 자세하게 설명이 잘 되어 있지만, 분량도 많고, 테스트 환경 기반이다보니 막상 프로덕션 환경에서 사용하려고 하면 머릿속이 하얘지는... 사실 ECS/EKS 의 큰 차이는 모르겠다. ECS 를 잘 써왔는데 굳이 EKS 를 쓰려는 이유는 그냥 한번 써볼라꼬. 난 그저 컨테이너 자동 복구, 무중단 배포, 오토 스케일링만 잘되면 된다. 쿠버네티스를 모르더라도 EKS 를 잘 쓸 수 있는지 EKS 가이드를 참고하여 Fargate 위주로 제가 한번 먹어보겠습니다.
주의해야 할 것은 AWS 문서는 한글판에만 의존해서는 안된다. 영문판보다 버전도 낮고 번역이 정반대인 경우도 있고, 예제의 경우 시나리오 중간중간 버전이 혼용되는가 하면... 등의 이유로 영문판과 함께 보기를 권장한다. 덕분에 예상치 못한 에러들이 발생해서 도움이 많이 됐다...;
클러스터
EKS 를 시작할 때, 가장 먼저 해야할 일이 클러스터를 생성하는 것이다. 이 안에 제어영역(Control Plane) 과 해당 노드가 포함된다.
생략된 옵션이 매우 많다. 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 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 화면을 브라우저에서 확인하기?
3년만인가. 드디어 ECS 에서 EKS 로 넘어왔다. 그 때도 ECS 보다는 조금 더 핫했던 쿠버네티스를 써보고 싶었지만 아마 아시아 리전에는 없었던 것으로 기억한다. 그리하여 이래저래 문서들 보고 헤딩하며 클러스터를 만들었는데 무언가 deployment 가 이상 작동을 하는 듯 했다. 안그래도 헤딩 중인데 되는 것 같기도 하고 안되는거 같기도 하고, 한참 삽질 끝에 Fargate 노드가 2개 까지만 만들어지는 현상을 발견했다. 이벤트 로그 메시지:
"Your AWS account has reached the limit on the number of Fargate pods it can run concurrently" 당신의 AWS 계정이 동시에 실행할 수 있는 Fargate 포드 수 제한에 도달했습니다.
내 계정은 이제 막 새로 판지 얼마 안된 새삥인데, 계정에도 뭔 종류가 있나. 뭔 업그레이드를 해야 하나 싶었다. 일단 구글에서는 저 메시지로 검색된 결과가 거의 없었다. 그나마 증상이 유사한 글에서, 몇몇 제한이 있는 리전이 있어서 리전을 바꾸던지 EC2 를 써야 한다는 글을 보았다. 우선 리전에서 fargate 할당량 체크를 했다.
[Service Quotas] - [Fargate On-Demand resource count] 사용률 4% / 적용된 할당량 값 50 / AWS 기본 할당량 값 1,000
개널널. 아직 48개 더 만들 수 있는데 나한테 왜그러는지... 혹시나 해서 도쿄 리전에도 만들어 봤으니 똑같은 메시지. 어쩔 수 없이 [지원센터] 찬스를 이용했다. 간결하게 물었다.
Q. eks 를 사용중이다. Fargate Pod 수가 2가 되면 더 이상 Pod 를 추가할 수 없다.
그랬더니 답변이 정말 개허접스럽게 왔다.
A. Fargate 동시 작업 제한 문제가 발생하지 않도록 EC2 인스턴스를 시작하시겠습니까?
ㅋㅋㅋ Basic 이라고 답변을 이딴 식으로 하면 돼, 안돼? Fargate 써볼라고 하는 사람한테 할 소리? 장사 안하겠다는건데 진짜 수준 개실망. Basic 은 기술문의도 막혀있네. 우와~ 처음 알았음. 답변도 거의 반나절 걸리고 내가 진짜 웬만하면 저기 글 안올리는데 이거 너무 이상해서 올렸더니만 역시나네. 사실 내 질문은 저기서 끝나지 않았음. '이것도 안된다. 저것도 안된다.' 그랬더니 그 때부터는 모든 질문을 기술팀에 넘겼다며 답변이 오는대로 바로 전달하겠다는 말을 남겼고, 난 며칠동안 답변이 오기전 그 모든 현상들을 해결했다.
사실 위 문제의 해결은 그들이 할당량을 100 으로 늘리자마자 해결됐다. 이걸로 해결된게 더 어이가 없다. 이 할당량은 리전에서 생성할 수 있는 Farget 의 최대치인데 기존에도 널널했는데 이제서 됐다는게 이상하다. 위에 나타난 에러는 내 AWS 계정의 제한을 얘기했다. 그들이 내 계정의 제한을 풀어준 것이라면 이해가 가겠지만... 또, 신규 계정의 fargate 제한이 2라면 그것도 말이 안된다. 이에 대해 구체적으로도 문의를 했지만, 과다 청구를 막기 위한 제한이니 안될 경우 할당량 증가 요청을 하라는 ㄱ소리... 불이익을 받지 않기 위해 별 다섯개를 투척하긴 했다만...
내 결론은 Fargate 적용된 할당량 기본값은 2임. 화면에 보여진 50은 아마도 버그일 것임. 아니면 x < 50 ? 50 이던가. 그래서 할당량 값을 새로 업데이트만 시켜줘도 50 이상의 값이 설정되는 것임. 아마 나 역시 51로만 업데이트 했어도 됐을 것임. 이것이 바로 내 소설이다. 만약 이런 문제가 발생하면 바로 할당량 요청 ㄱㄱ
Amazon EKS 는 AWS 에서 Kubernetes 를 손쉽게 실행하도록 하는 관리형 서비스이다. EKS 는 여러 가용 영역에서 Kubernetes 제어 플레인 인스턴스를 실행하고 관리하여 고가용성을 보장한다. 또한 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 의 모든 기존 플러그인과 도구를 사용할 수 있다. EKS 는 ECR, ELB, IAM, VPC 등의 AWS 서비스와도 통합되어 확장성과 보안을 제공한다. 아래는 EKS 를 사용하여 어플리케이션을 배포하는 일련의 플로우이다.
클러스터의 VPC / IAM / Security Groups 생성
로컬에 AWS CLI / kubectl / IAM Authenticator 설치
EKS 클러스터 생성
kubeconfig 파일 생성 / 설정
Node 생성 및 클러스터에 등록
kubectl 로 클러스터와 통신
EKS 클러스터에 어플리케이션 배포 및 관리
우선 EKS 는 EC2 등으로 쿠버네티스 마스터 노드를 따로 띄우지 않고 AWS 에서 관리해 준다. 물론 유료지만 마스터 노드 설정이 따로 필요 없고 단지 클러스터만 생성하면 된다. 그럼에도 불구하고 추가로 해야할 일이 꽤나 많은 것처럼 보여진다. 하지만 살펴보면 기존 EC2 같은 컴퓨팅에도 사용했던 것들이니 혼란스러울 것은 없다. Hello EKS 를 만들어보기 전에 일단 EKS 가 어떻게 돌아가는지를 위 플로우와 함께 설명해 보려 한다.
먼저 클러스터를 생성할 때 지정해야 할 항목들로 VPC, SG(Security Group), IAM 이 있다. 그렇기 때문에 미리 생성해 놓아야 한다. VPC 와 SG 는 원하는 구성이 있다면 미리 생성하여 사용해도 좋고, aws 에서 샘플로 제공하는 기본 사양을 그대로 사용하거나 수정하여 사용할 수 있다. 일반적으로 EKS 의 VPC 구성은 public 서브넷에 마스터 노드, private 서브넷에 워커 노드를 배치하는 형태를 가진다. 또한 클러스터의 제어 플레인에 리소스 권한을 부여하기 위해 IAM role 을 미리 생성해 놓고 클러스터 생성시 지정해야 한다. 일단 이렇게 하면 클러스터 및 제어 플레인이 생성된다. 그리고 바로 제어 플레인 사용 과금이 시작된다.^^ 여기까지가 1,3번 과정.
이제 노드를 추가해보자. EKS 콘솔에 들어가보면 알겠지만 관련 메뉴가 [클러스터 리스트] 하나 달랑 있다. EKS 콘솔에서 할 수 있는건 클러스터 생성/설정까지만... EKS 에서 노드는 일반적으로 EC2를 가리킨다. 그렇다면 노드 생성은 일반적인 EC2 생성하듯 하면 될 것 같지만 그 외에도 설정해야 할게 상당히 많다. AutoScalingGroup 설정, 연결할 클러스터 세부 설정 등 꽤나 복잡하다. 하지만 AWS 에서는 CloudFormation 에서 미리 정의된 소스들을 사용하여 노드 생성/설정 및 클러스터 등록을 간편하게 할 수 있다. 클러스터 등록할 때 부터는 kubectl 을 사용하게 되는데 특정 클러스터와의 연결을 위해 IAM 인증이 필요하므로 둘다 로컬에 미리 설치해 놓도록 한다. 여기까지가 2,4,5,6번 과정.
7번 과정은 배포 방식에 따라 설정은 다르겠지만 기본적으로 어플리케이션을 컨테이너 이미지로 생성하여 업로드하고 yaml/json 파일로 deployment, service 등을 설정하여 배포할 수 있다. 그 뒤 유지보수는 대시보드 등으로...
