[EKS@CloudNet] Amazon EKS 설치 및 기본 사용

- CloudNet에서 주관하는 EKS 스터디 2기 내용입니다

- 매번 좋은 스터디를 진행해 주시는 CloudNet 팀 감사드립니다

 

 

1. EKS...전에 Kubernates란?

- 너무 길어서 k8s로 줄여서 많이 부른다

- k8s는 애플리케이션을 환경에 영향받지 않고 배포할 수 있게 컨테이너로 말아놓는데, 이 컨테이너들의 관리를 자동화하는 기술이다.

https://kubernetes.io/docs/concepts/architecture/

K8S의 구성 요소

- container(애플리케이션 자체) ⊂ pod(애플리케이션 런타임 묶음) ⊂ replicaset(pod의 상태/갯수 유지) ⊂ cluster

 

- master node: 클러스터에 관한 전반적인 결정 수행/이벤트 감지/반응

  master node의 구성 요소

    - ETCD: NoSQL DB와 유사한 형식으로 클러스터 내 데이터 관리

    - kube-api server: ETCD와 직접 연결된 유일한 구성요소, 다른 컴포넌트에 대한 관리

    - kube control-manager: 노드 추가/제거, replicaset 유지

    -kube-scheduler: pod에 필요한 리소스에 맞게 node를 배정

 

- worker node: pod을 돌림

   worker node의 구성 요소

    - kubelet: node에 할당된 pod 상태 체크/관리

    - kube-proxy: pod간 연결되는 네트워크 관리

 

 

 

2. 그러면 EKS란?

- Kubernate를 AWS 환경에서 쓸 수 있으며, on-prem에서는 직접 구축/설정해야 하는 k8s 구성 요소들을 지원한다.

- 고객은 node와 pod에만 집중하면 되게 해준다.

 

 

 

 

- 현재 k8s 최신 버전인 1.29까지 지원하지만, 보다 생태계가 안정된 1.28버전으로 실습을 진행한다

- 보통 분기마다 새 버전이 제공되고 14개월간 지원된다. 추가 12개월까지 연장 지원이 가능하다(유료)

- EKS는 aws의 전용 콘솔인 eksctl과 타 IaC(Terraform, CloudFormation etc) 를 지원한다

 

- 덧붙여 다른 AWS 서비스들과 연계해서 사용할 수 있다.

    - ECR: 컨테이너 이미지 저장

    - ELB: load balancer

    - IAM: 인증

    - VPC: 격리

 

3. EKS 배포해 보기

[사전 준비]

- AWS 회원 가입

- 실습용으로 administrator 권한을 가진 IAM 만들기

- ssh 접속을 위한 키 페어 로컬에 받아 놓기

 

사전 준비 과정(과 겪은 시행착오)는 아래 포스트에 더 상세히 나와 있다.

[DOIK2] 쿠버네티스 배포 및 기초 지식

 

 

1. 기본 인프라 배포 

https://console.aws.amazon.com/cloudformation/home?region=ap-northeast-2#/stacks/new?stackName=myeks&templateURL=https:%2F%2Fs3.ap-northeast-2.amazonaws.com%2Fcloudformation.cloudneta.net%2FK8S%2Fmyeks-1week.yaml

스터디장 가시다님이 배포해 주신 CloudFormation 파일 링크를 이용하여 기본 인프라를 배포한다.

위 링크를 클릭하면 스택 세부 정보 지정 페이지로 들어간다.

나머지는 그대로 사용하고 

- Region이 ap-northeast-2(서울) 인지 확인

- KeyName은 [사전 준비] 에서 생성한 키 페어를 선택해주고

- SgIngressSshCidr은 외부 공격 시도를 막기 위해 현재 로컬 ip/32로 설정해준다. 아래 명령어로 현재 ip 확인 가능

curl -s ipinfo.io/ip

 

 

 

 

다음-다음-배포 클릭해서 배포를 실행한다(15-20분 소요).

 

 

배포가 끝나면 CloudFormation 서비스에서는 CREATE_COMPLETE가 뜨지만 접속정보를 확인할 수는 없다.

 

 

 

따라서 EC2 서비스로 들어가서 퍼블릭 IPv4 주소를 확인하고 로컬 터미널을 이용해서 ssh로 접근한다.

 

 

 

위와 같이 접속됨을 확인한다.

 

 

 

#다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/myeks-1week.yaml

#배포
aws cloudformation deploy --template-file ~/Downloads/myeks-1week.yaml \
     --stack-name myeks --parameter-overrides KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2

위와 같이 접속한 EC2에서 다시 curl로 eks config yaml을 다운로드 받고 eks를 배포할 수도 있다.

- 이때 curl의 -O 옵션은 remote의 파일 이름으로 저장하게 한다.

- 배포 전에 --dry-run 태그로 확인하고 배포할 수 있다.

 

 

그러면 이제 클러스터를 배포해 보자.

- 첫번째 만난 오류: no credential

aws configure 로 진입해서 admin 권한을 가진 IAM user의 키를 입력해 준다.

여담으로 Secret key가 모자이크 되지 않는 게 좀 충격적이었음.

 

 

 

aws configure
AWS Access Key ID [None]: xxxx
AWS Secret Access Key [None]: xxxx
Default region name [None]: ap-northeast-2
Default output format [None]: json

 

- 그리고 추가로 배포에 VPCID, SubnetID가 필요하므로 export 해 준다

 

 

 

# 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

 

 

 

 

- 아무튼 오류로 스택이 만들어지다 말면 or 중간에 사용자가 정지했을 때, 다시 배포하려고 하면 이런식으로 이미 스택이 존재하기 때문에 만들 수 없다고 나오는데, 이때는 delete하고 다시 만들어줘야 한다.

 

 

 

[시행착오]

- 스택 생성에는 약 20분이 소요된다.

실습을 해 볼 때, waiting for ~stack 이 반복적으로 출력되자 불안한 마음에(ping만 계속 가고 있는 것 같은 느낌) ctrl+c를 눌러서 중지하고 다시 만들고자 했다.

 

이때는 실습 초기에 배포한 myeks와 클러스터로 배포하는 eksctl-myeks-cluster가 헷갈려서 실수로 myeks를 지웠는데, 그러니 생성 중인 eksctl-myeks-cluster에 접근할 수 있는 포인트가 없어지게 되니까 결국 eksctl-myeks-cluster도 GUI상으로 삭제하고 처음부터 둘다 새로 배포하는 시행착오를 겪었다.

 

약 1.5시간 정도가 버려졌고... 로그 쳐다보고 있으면 괜히 불안해지니까 멍하니 쳐다보고 있지는 말자는 교훈을 얻었다.

덤으로 GUI 콘솔의 CloudFormation 에서는 (터미널에서는 내가 불안해했던 대로 계속 스택 생성을 기다리고 있지만) 스택이 정상적으로 배포되고 있음을 확인할 수 있다. 혹시 불안하면 이쪽을 보시기를 추천합니다...ㅠㅠ

성공했을 때도 이렇게 stack만 생성되는 데 약 8분이 걸린다.

 

 

 

 

- 배포가 완료되면 웹 콘솔-EC2 에서 인스턴스 3개가 생성된 것을 볼 수 있다

 

 

 

while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done

- 위 코드로 터미널에서 모니터링도 가능.

 

 

 

- node는 있지만, pod는 없는 상태로 배포되었음과 cluster info에서 control plane과 coreDNS를 확인할 수 있다.

 

 

 

- kubectl get node 시에 --owide 옵션으로 전체 속성 조회, --label-columns=node.kubernetes.io/instance-type 옵션으로 인스턴스 타입을 조회할 수 있다.

kubectl cluster-info

kubectl get pod

kubectl get node

kubectl get node --label-columns=node.kubernetes.io/instance-type

kubectl get node -owide

 

 

 

- 사용자의 pod는 없는 상태로 배포되었지만, 사실 eks가 kube-system에서 coredns, kubelet, kube-proxy pod를 관리하고 있다.

 

 

+새로 배운 용어 정리

- ALB(Application Load Balancer): AWS 제공 로드밸런서, 어플리케이션 계층(layer 7) 에서 동작하며 http/https 헤더 이용.

- NLB(Network Load Balancer): AWS 제공 로드발란서, layer 4에서 동작하며 tcp/ip 헤더 이용

- CLB(Classic Load Balancer): AWS 제공 로드발란서, layer 4/7 둘다 제공. 

https://skd03052.tistory.com/250 참고

 

 

 

비록 1주차였지만, 지난번 DB operator 스터디 때보다 좀 더 내가 쉽게 받아들이는 것 같아서 기쁘다.

역시 아는 만큼 보이나보다.