인프라/AWS

Amazon EKS 설치 및 기본 사용

스루나루 2024. 3. 10. 01:42
728x90
728x90

 

 

 해당 포스팅은 가시다님의 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탭의 리소스에서 전부 확인이 가능한 듯 하다. 

 

 

 

 

참고

 가시다님 자료 

 

 

 

728x90
728x90