Amazon EKS 설치 및 기본 사용

 

 

 해당 포스팅은 가시다님의 AWES 2기 스터디 내용을 토대로 작성했습니다.

 

EKS 아키텍쳐 

 

 

출처 ㅣ https://aws.github.io/aws-eks-best-practices/reliability/docs/controlplane/

 

 

 컨트롤 플레인 영역은 AWS의 VPC에서 관리하고 있고 해당 영역이 마스터 쪽이니까 마스터가 나의 워커노드에 명령을 내리거나 모니터링을 하려면 내 VPC랑도 연결이 필요하다. 그렇기 때문에 EKS에서는 가용 영역 마다 EKS owned ENI( 내 소유가 아니라 AWS 소유 )라는 네트워크 인터페이스를 통해서 가용영역 내에 있는 워커노드와 AWS VPC에 있는 api-server와 통신을 한다. 

 

 

 위 그림도 확인해보면 가용영역 마다 EKS owned ENI가 있고 이를 통해 API서버랑 통신을 할 수 있다. 

 관리형 노드 그룹 내에 있는 경우 EKS 최적화의 AMI( OS ) 를 사용할 수 있어서 사용에 최적화가 되어 있음 

 

  On-Demand 와 Spot 

 1) On-Demand 
 - 사전 약정 없이 쓴 시간만큼 과금되는 인스턴스 
 - 언제든지 쓰고, 삭제하고 가능 
 - spot 보다는 비싸다

 2) Spot 
 - aws의 미사용 ec2용량을 경매 형식으로 구매하는 형식 
 - On-Demand 보다 저렴하지만 AWS가 마음대로 사전 통지 후 회수할 수 있음 : 중요한 실시간 서비스에 부적합 

 

 

실습 구성도 

 

 

 1) 작업용 EC2에 ssh접속

  - ec2에 가서 작업용 ec2의 공인 아이피를 복사 후 루트 계정으로 ssh 접속을 실행  

 

 

 2) IAM User 자격 증명 설정 및 VPC 확인 및 변수 지정 

# 자격 구성 설정 없이 확인
aws ec2 describe-instances

# IAM User 자격 구성 : 실습 편리를 위해 administrator 권한을 가진 IAM User 의 자격 증명 입력
aws configure
AWS Access Key ID [None]: AKIA5...
AWS Secret Access Key [None]: CVNa2...
Default region name [None]: ap-northeast-2
Default output format [None]: json

# 자격 구성 적용 확인 : 노드 IP 확인
aws ec2 describe-instances

# EKS 배포할 VPC 정보 확인
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq Vpcs[]
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq Vpcs[].VpcId
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].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

# EKS 배포할 VPC에 속한 Subnet 정보 확인
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPCID" --output json | jq
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPCID" --output yaml

## 퍼블릭 서브넷 ID 확인
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
echo $PubSubnet2

 

- EKS 배포할 VPC정보 확인 

 1) 배포하는 네트워크 대역 : 192.168.0.0/16

 2) VPC : vpc-08fed4a852346fa51

 

 

 

 - 퍼블릿 서브넷 ID확인 

 

 

# 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.28 --ssh-access --external-dns-access --dry-run | yh

# eks 클러스터 & 관리형노드그룹 배포: 총 15분 소요
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.28 --ssh-access --external-dns-access --verbose 4

 

 

---

 EKS 배포 후 결과

 

 1) EC2에 워커 노드 2개가 생김 

 

 

  2) EKS 화면에 배포된 클러스터 확인 가능 

 

 3) 오토 스케일 그룹에 워커 노드의 상태가 설정되어 있음 : 2 

 

 

---

 

배포된 EKS 클러스터 정보 확인 

 

 1) 노드 정보 확인 

 

 보통 kubetcl get node하면 기본적인 거만 나오는데 EKS에 적용된 라벨을 붙여서 질의하면 보다 세세한 부분까지 노드의 정보가 나온다 .

 

 2) 파드 정보 확인 

 - 보면 전체 네임스페이스에서 존재하는 파드가 몇 개 되지 않는다.  

 - 또 보통 워커노드의 ip 대역을 파드에 할당하지 않는데 EKS에는 보면 192.168.1.0 , 192.168.2.0 대역을 pod에 할당하고 있다. : aws vpc cni 때문 

 

출처 : https://learn.microsoft.com/ko-kr/azure/azure-monitor/containers/container-insights-livedata-metrics

- 보통 위의 결과처럼 많은 파드가 확인 되어야하지만 EKS에서는 컨트롤 플레인에 있는 파드가 나오지 않음 AWS관리라서 그럴지도? 

 

 

워커 노드 상세 정보 

 

1) 노드 IP 및 PrivateIP 확인 

 

 

 2) 노드 핑 테스트 

 - 원래는 작업용 EC2의 대역인 192.168.1.100/32가 클러스터에 포함되지 않아서 접근이 불가능했는데 EKS에 설정된 보안 그룹에 설정을 변경해서 ping테스트 확인 

보안 그룹에 규칙하나 추가로 생김

 

 

 

배포된 EKS 클러스터의 API서버 - 퍼블릭

 

 

현재 퍼블릭으로 API서버가 퍼블릭으로 밖에서 접근이 가능한 상태이다. 설정된 EKS를 확인해보자.

 

 위의 API 서버 앤드포인트가 있는데 이 쪽이 컨트롤 플레인에 있는 API서버에 접근하기 위한 주소다. 해당 주소는 EKS 네트워킹 탭에서 확인해보면 퍼블릭으로 설정되어 있다. 

 

 즉 어디서든 해당 클러스터의 api서버에 접근이 가능하다는 뜻이 됨 

 

 1) 워커노드 -> ( 퍼블릭 도메인 ) 제어부 

컨트롤 플레인 주소가 API서버 앤드포인트 주소랑 같다

API서버 주소 보면 다 공인 IP 주소로 나와있음

API서버 엔드포인트 주소로 직접 쿼리 날리면 응답이 온다

 

 

 2) 제어부 -> EKS owned ENI -> 워커노드 kubelet && 사용자 -> kubectl -> ( 퍼블릭 도메인 ) 제어부 

 

 kubelet과 kube-proxy 통신 peer address 확인 : API 서버 엔드포인트 주소

 

 

 워커노드에 파드 하나를 실행시키고 다시 각 노드의 통신 정보를 확인 

 못 보던 192.168.2.14 라는 주소가 생김 

 

 해당 주소가 무슨 주소냐 네트워크 인터페이스에서 확인을 해보면 아래와 같다. 

소유자랑 요청자가 다르다

 

 EKS owned ENI 해당 네트워크 인터페이스의 소유자가 AWS라서 요청자와 다르다 . 

 

 흐름을 살펴보면 아래와 같다. 

 퍼블릭으로 들어가서 API서버 접근 후 해당 노드의 EKS owned ENI로 가서 노드 접근 

 

 

배포된 EKS 클러스터의 API서버 - 퍼블릭 & 프라이빗 

 

퍼블릿으로 되어 있는 부분을 변경

 

60.70.80.82

지금 퍼블릭인 API서버 엔드포인트를 가리키고 있음

 

---

 업데이트가 완료되면 아래와 같은 결과가 나옴 

사설 ip로 변경

 

API 엔드포인트 주소가 프라이빗으로 변경됨

 

위의 그림과 같은 구성으로 변경됨 노드에서 밖으로 빠지는 게 삭제

 

 

 

 

마리오 실습

# 터미널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 }'

 

배포된 거 확인 후 CLB 주소로 접속해서 마리오 되는지 확인 

 

 

EKS에서 사용되는 리소스들은 EKS탭의 리소스에서 전부 확인이 가능한 듯 하다. 

 

 

 

 

참고

 가시다님 자료