AWS CLI 구성/ eksctl/ kubectl 설치/ 클러스터 구축/ EKS/ 클러스터 생성 순서/ NLB 생성

AWS CLI

AWS CLI 구성

아이피는 211.183.3.99/24

호스트네임은 aws-cli

 

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

apt-get -y install unzip

unzip awscliv2.zip

./aws/install

 

 

<본인 iam사용자 로그인링크> + ?region=ap-northeast-2

- 바로가기 추가해 두면 편함.

- 액세스 키 - 시크릿 키 - 리전을 메모장에 저장하고 아래에 내용 넣기 

eksctl

- EKS 클러스터 구축, 관리에 필요한 명령어. kubeadm과 비슷한 느낌임

- EKS 클러스터를 쉽고 빠를게 생성하고 관리할 수 있게 도와주는 CLI 도구

 

kubeadm이란?

- 로컬이나 자체 서버에서 쿠버네티스 클러스터를 직접 설치하고 구성할 때 사용하는 CLI도구

 

보면 eksctl과 kubeadm은 둘 다 쿠버네티스 클러스터를 빠르고 쉽게 설치할 수 있게 도와주는 도구라는 점이고

차이점은 eksctl은 AWS용, kubeadm은 직접 서버를 쓰는 환경용임

curl --silent --location \

"https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

#eksctl 명령어를 /tmp에 다운로드

 

mv /tmp/eksctl /usr/local/bin

# 다운로드한 파일을 실행경로로 이동.

 

root@aws-cli:~# eksctl version
0.207.0

kubectl 설치

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.32.0/2024-12-20/bin/linux/amd64/kubectl

- kubectl  명령어 설치 파일

- curl -O: 파일 다운로드 명령어. 여기서 -O는 원래 이름 그대로 파일을 저장하라는 뜻

- 이 명령은 AWS가 배포한  Amazon EKS용 kubectl 바이너리를 직접 다운로드하는 것

 

install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

- 소유권 바꿔서 설치

-  /usr/local/bin/kubectl  경로를 복사하면서 실행 권한을 부여해 주는 명령어 

- -o root: 소유자를 root로 지정

- -g root: 그룹을 root로 지정

-m 0755: 실행 가능한 권한을 줌/ 소유자는 읽기/ 쓰기/ 실행, 나머지는 읽기/ 실행 가능

 

root@aws-cli:~# kubectl version --client
Client Version: v1.32.0-eks-5ca49cb
Kustomize Version: v5.5.0

- EKS용 커스터마이즈도 함께 포함됐다는 의미임

 

echo 'complete -C "$(which aws_completer)" aws' >> ~/.bashrc

- AWS CLI명령 자동완성 기능을 ~/.bashrc에 추가한다는 의미

- "$(which aws_completer)"는 aws_completer 파일의 정확한 경로를 찾아서 자동 완성에 연결해 주는 역할

 

eksctl completion bash | sudo tee /etc/bash_completion.d/eksctl > /dev/null

- eksctl은  EKS클러스터를 명령한 줄로 쉽게 만들 수 있는 도구임

 

eksctl completion bash >> ~/.bash_completion

- 개인 사용자 영역에 자동완성을 추가하는 것

- 위의 명령어를 사용하면 시스템/ 사용자 둘 다 자동 완성 지원이 됨

 

source ~/.bash_completion

- 자동완성 설정을 즉시 적용한다는 의미임

클러스터 구축 

EKS의 특징

- 컨트롤플레인(master)과 노드그룹(worker)들로 구성됨

1. 컨트롤플레인은 aws에서 제공

2. 가격이 상대적으로 높음

3. 노드 그룹 - 관리형 노드 그룹(Managed Node Group) - 쿠버네티스 버전을 자동으로 업그레이드.

- failover도 해주는 대신, 가격이 조금 비싸다.

 

클러스터 생성 순서

1. 클러스터 생성(eksctl create cluster...)

- 그냥 eksctl을 통해 생성을 하면, cloudformation에서 스크립트를 통해 클러스터를 생성해 줌

-> 여기서 cloudformation이란 AWS에서 제공하는 (IaC:코드로 인프라를 만드는 기술) 도구임

-> 사실은 우리가 생성해야 하는 인프라 및 설정들을 자기들이 이미 구성해 놓은 스크립트를 통해 생성해 줌

eksctl create cluster --name my-cluster --region ap-northeast-2 --nodes 2

 

예를 들어 이런 코드들이 eksctl은 내부에서 cloudformation 템플릿을 만들어서 AWS에 전달하고, 그 결과로 인프라가 자동으로 만들어지는 것을 말함

 

- 클러스터를 생성하다가 실패 시(서브넷 관련) - cloudformation에 가서 스크립트를 지워주는 게 좋음

- 만약에 내가 나중에 terraform으로 EKS클러스터를 구성한다면 당연히 cloudformation은 따로 생성되지 않음

 

2. 노드그룹을 만들어서 워커 노드들을 노드그룹에 포함시킨 다음

- 노드 그룹과 컨트롤 플레인이 통신이 되는지를 확인 후에 클러스터가 활성화

주의) 클러스터를 생성했는데, 잘 안 되는 경우가 있다면 10분 경과해도 클러스터가 생성이 안되면, 대부분 워커노드와 컨트롤플레인의 통신 문제일 확률이 큼

 

- nat gw을 잘 설정하고 클러스터를 생성해야 시간 낭비가 없음

- 생성했다가 지워도 흔적이 남아서 또 안될 수도 있으니까 설정을 잘하고 하는 것이 중요

 

eks 설치 및 사용 시 필요한 도구

- aws cli: 내 EKS 클러스터를 특정하기 위해 필요. 특히, kubeconfig를 가져올 때도 필요함

- eksctl: 클러스터 생성 및 삭제 관리에 필요한 도구

- kubectl

 

인스턴스 유형에 따른 파드 제한 확인 하는 방법

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/choosing-instance-type.html#determine-max-pods

최적의 Amazon EC2 노드 인스턴스 유형 선택 - Amazon EKS

클러스터를 구성하기 위한 VPC 생성

 중요 

- vpc에 ig연결

- 아래와 같이 서브넷 설정

가용영역 a / eks-vpc-pub-sub1 10.10.1.0/24

가용영역 c / eks-vpc-pub-sub2 10.10.11.0/24

 

가용영역 a / eks-vpc-pri-sub1 10.10.2.0/24

가용영역 c /  eks-vpc-pri-sub2 10.10.12.0/24

 

가용영역 a / eks-vpc-db-sub1 10.10.3.0/24

가용영역 c / eks-vpc-db-sub2 10.10.13.0/24

 

- 퍼블릭 자동 할당 ip설정

- 프라이빗 자동 할당 ip 하면 안 됨

- 로 된 건 pri으로 변경

퍼블릭 서브넷에 EKS 클러스터를 구축/ 삭제 방법

eksctl create cluster --vpc-public-subnets <퍼블릭서브넛1>,<퍼블릭서브넛2> --name <클러스터이름> --region <리전명> --version <쿠버네티스버전> --nodegroup-name 노드그룹이름 --node-type <인스턴스유형> --nodes <원하는 노드개수> --nodes-min <최소노드수> --nodes-max <최대노드수>

 

eksctl create cluster --vpc-public-subnets subnet-03d9fbec5fd7cd2f4,subnet-0ee99bdcec340f05e --name myc2 --region ap-northeast-2 --version 1.32 --nodegroup-name mycng --node-type t3.small --nodes 1 --nodes-min 1 --nodes-max 3

혹시 잘못 생성하면 eksctl delete cluster <클러스터명>으로 삭제해 보세요

 스택도 잘 생기는 걸 확인할 수 있음

 aws에 대한 권한을 클러스터로 가져와서 쿠버네티스에서 서비스를 만들었을 때 aws에도 잘 적용되는 걸 확인할 수 있음

이렇게 점점 하나씩 생성이 됨

- 잠시 후에 EC2에 워커노드가 추가된 걸 확인 가능

 

aws eks update-kubeconfig --region ap-northeast-2 --name <클러스터이름>

- ~/.kube/config에 kubeconfig파일을 가져오는 명령어. aws-cli가 잘 구성되어 있어야 가능.

 

root@aws-cli:~# aws eks update-kubeconfig --region ap-northeast-2 --name myc

- 설치한 곳에서 자동으로 구성해 주지만 매번 해주는 것도 나쁘지 않음

 

aws eks update-kubeconfig --region ap-northeast-2 --name myc

- 클러스터를 설치한 곳에서는 자동으로 가져올 수 있음

실습 1)

kubectl create deploy (deployment 생성)

kubectl expose (svc 생성) 명령만 사용하여 oolralra/ipnginx를 NodePort로 배포하고 접속이 잘 되는 걸 확인해 보세요. 

curl이나 브라우저로 확인.

root@aws-cli:~# kubectl create deploy ipnginx-deploy --image=oolralra/ipnginx
deployment.apps/ipnginx-deploy created

root@aws-cli:~# kubectl expose deploy ipnginx-deploy --type=NodePort --port=80
service/ipnginx-deploy exposed

- 현재 보안 그룹은 "EKS 내부 통신만 허용" 하고 있고, 외부 클라이언트 요청은 차단되고 있어서 curl이 안 가는 걸 확인할 수 있음

- 그래서 내 포트번호 30364를 허용해 줘야 됨 그래서 나는 30364 또는 30000-32767 이 범위로 허용해 주겠음

- 위에 보안 그룹을 허용해 주면 curl이 되는 걸 확인할 수 있음

- 참고로 위에 있는 아이피는 워커노드 인스턴스임 

- 보안 그룹 밑에 있는 두 개는 워커노드로 서로의 ip를 허용해주고 있음?

sg와 sgr은 무엇인가?

sg-

- sg-는 보안 그룹 자체를 식별하는 고유한 ID임

- 인스턴스, 로드밸런서, 노드 그룹 등에 할당됨

- ec2, eks 노드, ALB, ELB 등에 연결할 때 쓰는 그룹 단위 식별자

sgr-

- sgr-은 보안 그룹 안의 한 줄 한 줄 인바운드 또는 아웃바운드 규칙을 식별하는 ID

- 특정 인바운드 규칙만 삭제하거나 수정할 때 CLI 또는 Terraform으로 타겟팅할 수 있음

실습 2)

kubectl edit svc <서비스이름>으로 해당 서비스의 타입을 수정이 가능하다. 노드포트로 되어있는 svc type을 LoadBalancer로 수정 후 로드밸런서가 잘 띄워지는지, 접속은 잘 되는지 확인해 보세요. 안된다면 왜 안 되는 지도 describe를 통해 문제점을 찾아보세요.

kubectl edit svc ipnginx-deploy

vi 편집 화면에 진입하면 아래와 같이 수정해 주면 됨

spec:
  type: LoadBalancer  # ← NodePort → LoadBalancer로 수정

- 로드밸런서 AWS ELB주소가 생기는 걸 확인할 수 있음

- 로드 밸런서가 클래식이라 생각보다 빠르게 생성되는 걸 확인할 수 있음

- 보안 그룹 한 번 확인해 보는 것도 좋음

- curl이 잘 가는 걸 확인할 수 있음

- 없어진 걸 확인할 수 있음

NLB생성

- 기존의 deploy에 NLB를 연결시켜 보자

- 온프레미스 클러스터에서는 MetaILB를 설치해야 LB가 생성가능했지만, aws 같은 클라우드 경우, 이미 클라우드  공급자가 기능을 구현을 해놨음

 

root@aws-cli:~# kubectl describe pod ipnginx-deploy | grep -i label

- svc에서 label 명시하기 위해 labels확인

apiVersion: v1
kind: Service
metadata:
  name: svc-test
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: ipnginx-deploy
  ports:
  - port: 80
    targetPort: 80

  annotations:

    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"을 명시 안 하면 클래식으로 저장됨

- annotations을 통해 헬스체크도 결정할 수 있음.

kubectl delete svc svc-test

클러스터 삭제 전에는 꼭 aws의 리소스를 생성하는 svc 같은 건 지워주자.

eksctl delete cluster myc

- 24시간 클러스터를 띄워 놓으면 컨트롤플레인비용만 거의 10달러 가까이 나오는 걸 확인할 수 있음

실습 3)

이번에는 private 서브넷에 pric라는 eks 클러스터를 구성해서, oolralra/ipnginx를 NLB로 배포해서 접속이 되도록 만들어보세요. VPC는 절대 지우지 마시고 재활용하세요!

클러스터를 생성할 때 추가옵션(--node-private-networking)이 필요합니다.

oolralra/ipnginx를 NLB로 배포

- 프라이빗서브넷에 노드그룹(워커노드들)을 구성하려면, 워커노드들이 공인대역에 있는 컨트롤플레인과 아웃바운드로 통신이 가능해야하기 때문에 natgw가 필요

프라이빗 클러스터 생성하는 명령

 

- private 서브넷에 pric라는 eks 클러스터를 구성

--vpc-private-subnets: 퍼블릭이 아닌 프라이빗 서브넷 ID만 입력

--node-private-networking: 노드에 퍼블릭 IP를 부여하지 않음

외부 인터넷 연결은 NAT GW sk VPC Endpoint를 통해 이루어져야 함

export SUBNET1_ID=<본인 프라이빗서브넷1>
export SUBNET2_ID=<본인 프라이빗서브넷2>

eksctl create cluster --name pric --node-private-networking --region ap-northeast-2 --version 1.32 --nodegroup-name pring --node-type t3.small --nodes 1 --nodes-min 1 --nodes-max 3 --vpc-private-subnets SUBNET1_ID,SUBNET2_ID

- 내가 만약 프라이빗서브넷에 존재하는 워커노드에 접근해야 하는 경우가 있다면(노드포트로 테스트를 해보고 싶은 경우) bastion을 통해 워커 노드와 통신할 수 있는 상황을 만들어야 함

kubectl create deploy test --image=oolralra/ipnginx --replicas=1

kubectl expose deploy test --type LoadBalancer --port 80 --target-port=80