1주차 EKS 실습 환경 배포, K8S/EKS 소개
1. 도입
운이 좋게도 @CLOUDNET에서 지원하는 스터디인 EKS Workshop Study 2기를 들을 수 있게되었다.
인프런에서도 강의를 같이 진행할 예정이었다.
인프런의 AWS 네트워킹 입문도 AWS를 사용하면서 생기는 머리아픈 시간들을 극도로 줄여줬어서 EKS도 마음을 놓고 수강을 하고 있다.
해당 스터디에서 다루게 될 지점들은 다음과 같다.
1주차(3.3): Introduction - EKS 실습 환경 배포, K8S/EKS 소개
2주차(3.10) : Networking - VPC CNI, AWS LB Ctrl, CoreDNS/ExternalDNS
3주차(3.17) : Fundamentals - Storage, Managed Node Groups, Fargate
4주차(3.24) : Observability - Prometheus, Grafana, Loki
5주차(3.31) : Autoscaling - HPA/KEDA, VPA, CA, CPA, Karpenter
6주차(4.7) : Security - EKS 인증/인가, IRSA, Pod Identity, Secrets Mgmt, Kyverno
7주차(4.14) : CI/CD - Argo CD, Argo rollouts, Flux
8주차(4.21) : Automation - ACK, Crossplane, Pulumi
그럼 거두절미하고 바로 EKS의 구성요소를 같이 알아보자
2. K8S 과 EKS
쿠버네티스의 형태를 제일 처음 보여주시고 해당 구성요소는 K8S를 배우고 사용해봤다면 알것이기 때문에 넘어가겠다.
이제 구성요소들이 AWS에서 어떻게 운영되는지 알아보자.
그림과 같이 우리는 EKS ControlPlane을 운영할 필요가 없다. 우리는 워커 노드들만 잘 운영해주면 된다.
여기서 더 편리한 점은 다른 AWS 서비스들과 깔끔하게 호환이 되고 대시보드에 나타난다. (하느님 감사합니다.)
컨테이너 이미지 저장소 ECR
로드 분산 ELB
인증 IAM
격리 VPC
3. 기본 인프라 배포
CloudFormation으로 aws EKS를 생성하게 될것이다.
작업용 ec2로 EKS에 접근할것이라서 EC2도 생성해줬다.
Terraform은 사전 지식이 필요해서 kubectl을 사용해봤다면 비슷한 eksctl로 배포는 진행이 되었다.
주어진 커맨드들은 많아서 해당 인프런 강의에서 모두 확인 하실수 있으시다!
a. 실습환경
기본 설치 툴들
kubectl
helm
aws-cli
docker
설정 필요 항목들
aws configure해서 권한 설정 및 변수만 설정해주면 확인 가능 했다.aws ec2 describe-instances-> 노드 ip 확인aws ec2 describe-vpcs -filtersEKS 배포할 VPC 정보 확인
동일 vpc 내에 public subnet 2개, private subnet 2 개 배포됐는지 확인하면된다.
eksctl create cluster —help → 옵션 보여준다 + —dry-run 으로 yaml 명세 확인 가능하다.
eksctl 사용해서 클러스터 생성 및 관리형 노드를 다 생성할 수 있다.
다음과 같은 옵션을 지정 할 수 있다.
manageNodeGroup
node—ami-group
—vpc-cidr
node-volume
b. K8S 기본 컴포넌트들 확인
kubectl krew list
플러그인 확인
dig 조회
노드 정보 조회
가용영역
라벨
ec2 인스턴스 타입 + capacity
인증정보 확인
/root/.kube/config인증관련 사항 확인
파드 정보 확인온프레미스 쿠버네티스의 파드 배치와 다른점?
파드의 ip 특징?
파드 컨테이너 이미지 확인
CNI
POLICY AGENT
COREDNS
KUBE-PROXY
ECR에서 이미지 땡겨옴
c. 워커 노드 확인
NODE IP 뽑아내기
PING 해보면 연결안됨
보안 그룹 설정 안되서 보안그룹 설정해주기
SSH로 편하게 NODE 접근 가능하다.
d. 노드 네트워크 정보 확인
VPC CNI 사용 확인
파드 IP 확인
라우팅 테이블 확인
CGROUP 버전 확인
노드 프로세스 정보 확인
STATIC 파일이 없다 -> ???? KUBELET은?
노드 설정 정보 확인
노드 스트로지 정보 확인
초기 EKSCTL로 설정한 30GB 확인했음
e. EKS내의 통신 흐름 (PUBLIC 설정시)
ENI 들을 보여주시면서 ENI 가 AWS에 속하는것을 요청자 ID 와 소유자 ID가 다른 것을 보여주셨다.
KUBCTL 시작 통신 흐름
KUBECTL → INTERNET GATEWAY → API 서버 → EKS OWNED ENI로 명령이 흐른다.
KUBECTL EXEC 와 LOG 사용시에 해당 흐름을 따른다.
워커 노드 시작 통신흐름
INTERNET GATEWAY → 공인아이피 → INTERNET GATEWAY
f. EKS 통신이 PUBLIC(IP 제한) + PRIVATE 일 경우
워커 노드에서 제어부 가는 방향이
ENI로 갔다가 제어부로 흐른다.
전부 PRIVATE IP로 변경된다
하지만 KUBECTL 쪽만 PUBLIC IP이다.
EKS 통신 다 바뀌면 proxy 랑 kubelet 재시작
g. EKS 통신을 PRIVATE 일 경우
kubectl을 타고 ENI로 가서 제어부로 감
VPC를 모두 선언해줘야하지만 가장 안전
EKS 통신 대역 통제 해는 방향으로 권장
h. 기본 eksctl 사용 및 aws에서 deployed된 리소스 확인
EKS 리소스 보기
서비스
워크로드
로드 밸런서
노드에 배포된 컨테이너 정보 확인
네임 스페이스 확인
컨테이너 리스트 확인
컨테이너 이미지 확인
태스크 리스트 확인
태스크의 PID도 확인 가능
4. EKS 기본 구성요소
컨트롤 플레인은 다음과 같은 구성요소들을 가진다.
vpc
3개의 AZ
NLB
ETCD
ELB
컨트롤 플레인
다음과 같은 3개의 AZ에 거친 구성요소들로 가용성 보장 및 백업 관리를 해준다.
ETCD는 클러스터 분산 키밸류 스토어인데 클러스터 설정을 동기화 해준다고 보면된다.
API 부하분산은 NLB를 사용하는 이유는 NLB가 성능과 가용성 제공이 휠씬 뛰어남.
KUBECTL을 이용해서 명령을 날리게되는데 EKS PUBLIC ENDPOINT로 받게 된다
워커 노드
Worker node는 유저의 VPC에 존재하게된다.
AZ를 2개에 WORKER NODE를 배치하게 된다
EKS 가 소유한 ENI를 가지고 있게 된다.
컨트롤 노드와 통신용
해당 ENI는 AWS 소유다.
관리형 노드 그룹(MANAGED NODE GROUPS)
EKS에 최적화된 AMI를 사용해서 SPOT INSTANCE 사용해서 비용 줄일수 있다.
SELF MANAGED NODES → CUSTOM AMI 사용 가능하고 ASG 직접 관리 OS 구성 고객이 관리가능하다.
FARGATE 를 사용해서 POD 별 VM 할당 가능하다.
5. 느낀점
2시간 찾아볼 구성요소들을 한번에 배웠다.
굉장히 많은 리소스들을 전달받아서 실습을 하면서 궁금증을 바로 해소 할 수 있었다.
@CLOUDNET 팀들에게 감사한 마음을 전한다.
Last updated