EKS 스터디 1주차 (Introduction)

최종 수정일: 2023-04-28

안녕하세요. 가시다님 스터디에 참여하게 되었습니다.

 

가시다님 블로그 링크

CloudNet@ Blog

 

스터디를 어떻게 참여하게 되었나 ?

 

• 평소 친분이 있던 늑대양님께서 가시다님의 스터디를 적극 추천함
• 기존에는 쿠버네티스의 이점보다는 복잡도가 높아질 거라 생각해서 도입하지 않았으나 서비스가 늘어남에 따라 고려하게 되었고, 가시다님의 스터디로 입문하면 낮은 러닝커브로 빠르게 진입할 수 있을거라 판단했습니다.

 

1주차 스터디 요약

 

EKS 개념 설명

 

먼저, 가시다님이 Amazon EKS(Amazon Elastic Kubernetes Service, 이하 "eks")에 대해 설명해주셨습니다. 

eks는 AWS에서 Kubernetes(이하 "쿠버네티스") Control Plane의 설치, 운영 및 유지관리를 해주는 관리형 서비스(Managed Service) 입니다.

여기서 Control Plane은 아래 그림과 같은 구성을 하고 있습니다.

 

Component	Description
kube-apiserver	쿠버네티스 컨트롤플레인의 프론트엔드
etcd	클러스터 동작을 위한 리소스 구성정보, 명세정보등을 key-value로 저장하는 저장소
kube-scheduler	새로 생성된 파드를 감지하여 노드에 배치하는 작업
kube-controller-manager	다운된 노드가 없는지, 파드가 의도한 복제(Replicas) 숫자를 유지하고 있는지, 서비스와 파드는 적절하게 연결되어 있는지, 네임스페이스에 대한 기본 계정과 토큰이 생성되어 있는지를 확인하고 적절하지 않다면 적절한 수준을 유지하기 위해 조치하는 역할

참고: 쿠버네티스 알아보기 3편: 쿠버네티스를 이루고 있는 여러 가지 구성 요소

쿠버네티스 알아보기 3편: 쿠버네티스를 이루고 있는 여러 가지 구성 요소 | 인사이트리포트 | 삼

 

쿠버네티스는 Control Plane과 더불어 Data Plane이라는 영역이 있습니다. 어플리케이션이 바로 이 Data Plane에 올라가는데요. 

Data Plane에는 관리형 노드 그룹들이 있습니다. 이 노드들은 실제로 EC2(나중에 실습때 또 나와요, 기억해주세요.)를 말합니다. 

여기서 예전부터 갖고 있던 의문이 하나 풀렸습니다. EKS에서 Node 그룹이 변경되면 (신규 서비스의 배포, 기존 서비스의 이관 등) 과연 어디에 있는 컴퓨팅 리소스를 가져올까 생각했는데 그냥 EC2를 만드는 거였습니다.

-> 그럼 EC2를 만들려면 VPC도 관리해야하고, Subnet, Route Table, NACL, SG, 등등 많은 서비스가 활용되고 있었습니다. 

-> 결국, EKS는 AWS VPC와 밀접한 관계가 있다는 점을 이해했습니다. (역시 가시다님... 스터디 다시 한 번 감사합니다.)

-> 현재까지 EKS에 대한 제 생각은, 조금 복잡한 도커라고 생각됩니다.

 

그런데 또 다시 궁금한 점이 더 생겼습니다.

Q. 클러스터 외부에서 특정 컨테이너까지 네트워크가 어떻게 연결되어 있을까 ?

- 클러스터 외부에서 컨트롤 플레인까지의 네트워크

- 컨트롤 플레인에서 노드 그룹까지 네트워크

- 노드 그룹간에 네트워크

- 외부에서 하나의 컨테이너까지 네트워크

- 실제로 컨테이너 안에서, 클러스터 외부에서 확인하려면 어떻게 해야할까 ?

저는 이 질문에 대한 답을 당장 얻기는 어렵다고 보았고, 쿠버네티스에 대해 더 많이 알고 싶은 동기가 되었습니다.

추후에 답을 얻게되면 이 글을 업데이트 하거나 새로운 글로 작성해 링크 남기겠습니다.

 

EKS 실습

실습은 가시다님께서 준비해주신 AWS CloudFormation template로 진행되었습니다. 

실습 전 준비물

• 내 아이피 알아둘 것 (내 아이피 확인하기)
• key pair 만들기 (문서, ap-northeast-2 region)
• 터미널
• IAM Role (실습 편의상 AdministratorAccess 정책을 포함)

 

준비된 CloudFormation 템플릿을 가져옵니다.

파라미터를 변경해줍니다.

앞서 만들었던 key-pair 를 지정해줍니다.

SSH Session 접속을 위한 IP 대역을 입력해줍니다.

CloudFormation이 EKS를 구성할 수 있는 권한을 가진 IAM Role을 지정해줍니다.

 

마지막으로, 모든 항목을 검토한 다음 전송합니다.

이후 CloudFormation 화면에서, 템플릿으로부터 정의된 리소스가 provisioning 되는 것을 확인할 수 있습니다.

마지막으로, provisioning이 마치면 출력 탭을 눌러 접속할 노드의 IP 정보를 확인할 수 있습니다.

이 IP가 어디서 왔는지 확인을 해봅시다.

EC2 서비스에 가봅시다.

인스턴스가 하나 실행되어 있고, 인스턴스의 퍼블릭 IPv4가 CloudFormation의 출력과 동일한 것을 확인할 수 있습니다.

그럼 다른 리소스도 잘 생성되었는지 한 번 확인해보겠습니다.

 

VPC 정보

 

 

다 잘 되어 있네요. 그럼 다시 돌아가서, EC2에 접속해보겠습니다.

aws cli를 사용하기 위해 AdministratorAccess 정책을 할당한 IAM User를 만들어주고 액세스키, 시크릿키를 할당해줍니다.

cli configuration을 확인해줍니다. 

aws sts get-caller-identity

 

미리 선언된 환경 변수를 확인해봅시다. CLUSTER_NAME이 있네요.  VPC 정보를 확인해봅시다.

여기서 VpcId를 확인할 수 있겠네요. 

 

export VPCID=$(aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].VpcId)
echo "export VPCID=$VPCID" >> /etc/profile
echo $VPCID
>> vpc-0b617dd3e1d57c780

 

 

서브넷 아이디도 확인해보겠습니다.

aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" | jq
aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text
export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
echo "export PubSubnet1=$PubSubnet1" >> /etc/profile
echo "export PubSubnet2=$PubSubnet2" >> /etc/profile
echo $PubSubnet1
>> subnet-0d6492e174b5f0914
echo $PubSubnet2
>> subnet-07f3f826f7a8f15aa

 

앞서 콘솔에서 확인한 내용과 동일하네요. 자 그럼 이제 eksctl을 사용해서 클러스터를 생성하고 배포까지 해보겠습니다.

 

eks 클러스터 생성

(eksctl 설치 후) eksctl을 사용하기 전에, 버전을 확인하겠습니다.

eks 클러스터를 생성했습니다. 

eksctl create cluster \
  --name $CLUSTER_NAME \
  --region=$AWS_DEFAULT_REGION \
  --nodegroup-name=$CLUSTER_NAME-nodegroup \
  --node-type=t3.medium \
  --node-volume-size=30 \
  --vpc-public-subnets "$PubSubnet1,$PubSubnet2" \
  --version 1.24 
  --ssh-access 
  --external-dns-access 
  --verbose 4

클러스터 생성이 완료되었습니다.

클러스터 생성이 완료된 후 Amazon EKS 콘솔에서는 API 서버 엔드포인트를 확인할 수 있습니다.

 

 

아래 명령어로 노드그룹 정보를 확인할 수 있습니다.

eksctl get nodegroup --cluster $CLUSTER_NAME --name $CLUSTER_NAME-nodegroup

아래 명령어로 노드 정보와 파드 정보를 확인할 수 있습니다.

kubectl get node

kubectl get pod -n kube-system

실제로 만들어진 클러스터에서, 노드그룹에 해당하는 인스턴스와 어떻게 통신하는 지 봅시다.

aws cli를 이용해서 노드 목록을 가져올 수 있습니다.

192.168.2.12 노드를 N1, 192.168.1.170노드를 N2 변수로 할당하겠습니다.

ping test가 안되네요. 콘솔에서 한 번 확인해볼까요 ?

N1, N2 인스턴스(myeks-myeks-nodegroup-Node) 둘 다 동일한 보안그룹을 갖습니다.

- SSH 접속 (22번 포트)

- 같은 노드끼리의 통신

위와 같은 인바운드 설정이 되어있어서 ping test (ICMP 를 활용)가 안되었던 게 확인되었네요. 

다시 터미널로 돌아가서 보안그룹을 설정해봅시다.

# 노드그룹의 보안그룹 아이디 확인
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*nodegroup* --query "SecurityGroups[*].[GroupId]" --output text)

# 노드그룹의 보안그룹 인바운드규칙에 ICMP 추가
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32

 

이제 다시 ping test를 해볼까요 ?

잘 되네요. 역시나 보안그룹에 설정된 것과 같이 ssh 연결도 잘 되는 것을 확인할 수 있네요.

eks 배포 실습

# 터미널1 (모니터링)
watch -d 'kubectl get pod,svc'

# 수퍼마리오 디플로이먼트 배포
curl -s -O <https://raw.githubusercontent.com/gasida/PKOS/main/1/mario.yaml>
kubectl apply -f mario.yaml
cat mario.yaml | yh

# 배포 확인 : CLB 배포 확인
kubectl get deploy,svc,ep mario

# 마리오 게임 접속 : CLB 주소로 웹 접속
kubectl get svc mario -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Maria URL = http://"$1 }'

 

maria.yaml을 배포해봅시다.

조금 지나면, CLB 접속 주소가 나옵니다. 

CLB 접속 주소로 들어가보면 아래와 같이 마리오 게임을 즐길 수 있습니다.

하지만...

 

쿠버네티스... 생각보다 더 어렵네요.

배울 게 많다는 건 좋은 것 같습니다. 머리아프지만 하고나면 성취감이 분수처럼 터져나오기 때문에 앞으로 기대가 됩니다.

 

마지막으로... 리소스 삭제 꼭 꼭 꼭 !!!!

이 게시글에서 추가로 업데이트 할 목록

 

개인적으로 목표가 있으면 언제가 되었든 완료해야하기에 1주차 스터디에서 나왔던 언제가 되었든 하나씩 완료하여 이 게시글에 업데이트 하도록 하겠습니다.

• [1] EKS Cluster Endpoint - Public Private 
• [2] EKS Cluster Endpoint - Private
• [3] EKS Cluster를 YAML 파일로 만들어서 배포해보기
• [4] EKS Cluster를 관리형노드그룹을 Spot 인스턴스로 배포해보기
• [5] EKS Cluster를 노드를 **AWS Fargate(서버리스)**로 배포해보기
• [6] EKS Cluster를 관리형노드그룹에 Bottlerocket AMI 사용해보고, Amazon Linux2 AMI와 차이점을 알아보기
• [7] Private ECR Repo 생성 및 이미지 업로드 및 파드 사용(이미지 다운로드)해보기

 

그밖에, 궁금한(했던) 부분
 답을 알게 되면 그때그때 수정하겠습니다.

 

Q. 처음 EKS를 접한 다음, 구글링을 하면서 제일 헷갈렸던 부분은 Control Plane, Data Plane으로 설명하는 것과 Master, Nodes로 설명하는 게 다른건가 하는 의문이 있었습니다.

-> 그냥 각각을 부르는 명칭이 바뀌어 온거라고 한다.(정확하지 않음) 예전에는 Master, Nodes 로 불렀다면 현재는 Control Plane, Data Plane으로 부르는 것 같습니다.

-> 무튼 공식 문서에서는 Control Plane, Data Plane으로 부르는 것 같으니 최소한 제 블로그에서는 이러한 표기를 사실상의 표준(de-facto)으로 삼겠습니다.

 

Q. 하나의 EKS 클러스터에서는 얼마나 많은 트래픽을 감당할 수 있는가 ? 

-> 노드와의 트래픽, 외부와의 트래픽 등... 규모가 커지면 컨트롤 플레인에 하나 이상의 노드가 들어가고 그와 더불어 api-server, controller-manager, etcd, scheduler가 2개 이상으로 늘어나고 그러면서 데이터 정합성이나 트래픽 과부하가 어떻게 처리될지 궁금합니다. 추후에 쿠버네티스를 직접 올려가면서 각기 컴포넌트들이 HA를 유지하기 위한 로직이나 eks에서는 어떻게 동작하는지 다뤄보겠습니다. (아시는 분은 댓글 부탁드립니다.)

 

Q. 버전 변경을 무중단으로(물론 비용최적화) 하려면 어떻게 해야하나...?