EKS 클러스터 및 노드 그룹 생성, Kubectl 설치 및 연결
간단하게 워커 노드 2대로 이루어진 eks 를 구성하고 스프링 애플리케이션을 배포하려고 한다.
1. AWS IAM USER 생성
IAM > 사용자 > 사용자 생성
root 계정으로 작업하는 것은 지양해야하기 때문에, 관리자 권한을 가진 IAM USER를 생성한다. 엄격하게 필요한 권한만 줄 수도 있지만, 우선 클러스터를 구축하고 추후에 새로운 USER로 바꿀 생각이다.
2. AWS IAM ROLE 설정
IAM > 역할 > 역할 생성
AWS 리소스 간에 서로에게 명령을 내리려면 다른 리소스를 제어하거나 접근할 수 있는 권한을 가진 ROLE이 할당 돼있어야 한다. 우선 클러스터 생성 과정에서 만들어야할 ROLE은 아래 2가지이다.
- EKS 클러스터 자체(컨트롤 플레인)가 AWS 리소스를 관리할 수 있도록 허용해 주는 역할
- EKS 워커 노드가 클러스터에 정상적으로 참여할 수 있도록 하는 역할
위 그림처럼 2가지의 역할을 미리 만들어두었고, 추후에 EKS Clutser 와 Node Group 생성 시에 연결할 예정이다.
3. EKS CLUSTER 생성
Elastic Kubernetes Service > 클러스터 생성
3-1. 클러스터 구성
신규로 생성할 시, 빠른 구성으로 선택되어 있을 텐데 과금 요소가 포함되어 상당부분 포함되어 있기 때문에, 사용자 지정 구성으로 선택해준다. 추가로 자율 모드도 선택해제 해준다.
클러스터 구성에서 클러스터 이름으 정하고, 2번 항목에서 클러스터를 위해 만들어놓은 역할을 연결해준다. 이름은 명명 법칙을 정해야 리소스를 관리할 때 편하기 때문에, 나는 {applicationName}-{AwsServicePurpose}-{AZ} 로 명명해주었다. IAM ROLE을 미리 만들어두지 않았다면, 오른쪽의 권장 역할 생성을 통해 ROLE을 하나 생성하고, 새로고침해서 연결해주면 된다.
이후 것들은 건드리지 않고 다음 설정으로 넘어가자
3-2. 네트워킹 지정
여기서는 네트워크를 지정하게 된다. 기본적으로 백엔드 서빙용 노드의 경우, private subnet안에 두어야한다. 하지만 private subnet안에 두게되면, NAT Gateway를 연결해야 외부로 통신이 가능하기 때문에, 일단 아직 개발단계여서 모두 public Subnet으로 구성된 default VPC를 할당해주었다. default VPC의 서브넷 중에 알아서 한 곳에 생성된다.
이후 모든 단계들을 기본값으로 선택하고 넘기면 된다.
3-3. 클러스터 생성 완료
클러스터는 생성된는데 5-10분 사이로 걸리는 것 같다 생성이 완료되면, 상태값이 활성 상태로 바뀌고 클릭해서 세부 정보를 확인 가능하다.
4. 노드 그룹 추가
Elastic Kubernetes Service > 생성한 클러스터 > 컴퓨팅 > 노드 그룹 > 노드 그룹 추가
이제 클러스터에서 실질적으로 일할 워커 노드들을 구성해야한다. 워커 노드를 어디서 실행할건지는 다양한 옵션이 있지만, ec2에서 실행해줄 예정이다.
4-1. 노드 그룹 구성
노드의 이름을 지정하고, 2번 단계에서 만들어둔 노드를 위한 역할을 할당한다. 여기도 마찬가지로 만들지 못하고 왔다면, 권장 역할 생성을 통해 생성하고 새로고침하여 할당하면 된다.
4-2. 컴퓨팅 및 조정 구성 설정
여기서는 인스턴스 AMI와 유형을 선택할 수 있는데, 원하는 인스턴스 유형과 이미지를 선택하면 된다. 디스크 크기도 수정 가능하다. 나의 경우는 t2.small로 만들었다.
여기서는 노드의 최소양과 최대 어디까지 스케일링될 지를 정할 수 있다. 그런데 최소 크기를 1개로 지정했다고 해서, 인스턴스가 1개만 실행되고 트래픽이 몰릴 때 2대가 되는 것이 아니라, 노드 자체는 2대가 생성이 되고 실행되고 있지만, 트래픽이 많지 않을 때는 1대만 사용한다는 것이다. 결국 과금은 노드 2대에 대해서 이루어질 것이다.
4-3. 네트워킹 지정
나는 기본 vpc를 지정했기 때문에 알아서 지정되었다.
나머지는 기본으로 두고 생성해주면 된다. 이렇게
4-4. 생성된 노드 확인
2개의 노드가 생성되고 관리중인 것을 볼 수 있다.
5. AWSCLI 설치
EKS의 클러스터를 콘솔로만 관리하려면 제한사항이 많고, 기존에 cli 기반으로 쿠버네티스를 관리하는 것이 보편적이기 때문에, 로컬의 kubectl 명령어를 위에서 생성한 클러스터에 명령이 전달될 수 있도록 설정해야한다. 이 과정에서 AWSCLI가 필요하기 때문에, AWSCL를 설치해주도록 하자.
맥북의 경우 brew를 통해 간단하게 설치 가능하다. Linux나 window의 경우도 아래 docs를 보고 설치하도록 하자.
최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface
이전 버전에서 업데이트하는 경우 unzip 명령을 실행하면 기존 파일을 덮어쓸지 묻는 메시지가 표시됩니다. 스크립트 자동화와 같은 경우에 이러한 프롬프트를 건너뛰려면 unzip에 대한 -u 업데이
docs.aws.amazon.com
awscli
Homebrew’s package index
formulae.brew.sh
5-1. AWS Configure 설정
위에서 생성해둔 어드민 권한을 가진 IAM의 시크릿 키와 엑세스 키를 등록한다. --profile 명령어를 통해 프로필로 따로 관리할 수도 있다.
AWS CLI 설정 구성 - AWS Command Line Interface
AWS에서는 모든 수신 요청이 암호화 방식으로 서명되어야 합니다. AWS CLI에서 이 작업을 수행합니다. "서명"에는 날짜/시간 스탬프가 포함됩니다. 따라서 컴퓨터의 날짜 및 시간이 올바르게 설정
docs.aws.amazon.com
6. kubectl 연결
아래 공식 docs를 참고하면 편리하다. 우리가 EKS 클러스터를 만들 때, 버전을 설정해주었기 때문에 해당 버전과의 종속성을 맞춰주어야 한다. 생성하고, AWSCLI를 설치하고 바로 대부분 버전이 맞을 것이다. 그래도 확인하자. 맥북은 brew install kubectl로도 가능하다.
kubectl 및 eksctl 설정 - Amazon EKS
Amazon EKS 클러스터 제어 영역과 마이너 버전이 하나 다른 kubectl 버전을 사용해야 합니다. 예를 들어 1.31 kubectl 클라이언트는 Kubernetes 1.30, 1.31 및 1.32 클러스터에서 작업합니다.
docs.aws.amazon.com
공식 docs의 마지막에 적혀있듯이
aws eks update-kubeconfig --region ap-northeast-2 --name test_cluster
위 명령어를 개인에 맞게 커스텀하여 적용하면 된다.
kubectl get nodes
의 명령어를 통해 잘 연결됐는지도 확인가능하다.
실제 아까 생성한 노드그룹의 노드들을 확인할 수 있다.