가시다님 EKS 스터디 참여하고 내용을 정리합니다.
테라폼을 이용하여 설치
- 테라폼 EKS, VPC 등 모듈 이용
테라폼 EKS 설치 소스 코드 - 테라폼은 EKS 관련된 리소스(EKS, VPC, IAM 등) 설치에만 사용
이 후 쿠버네티스 내 애플리케이션은 헬름 이용 설치
설치 옵션
-
최신 버전으로 설치
-
현재 필자는 1.29 또는 1.31 사용 중
1.29 to 1.31 업그레이드 작업 중
컨트롤 플레인은 1.29 to 1.30 to 1.31 순차적으로 업그레이드 하고 데이터 플레인 노드는 한번에 1.29 to 1.31 업그레이드
표준 지원 만료 전 최신 버전 -1로 업그레이드 작업하는 것을 정책으로
4개월에 한번씩 업데이트되니 약 8개월에 한번씩 작업하는 꼴 -
실패해도 재실행 할 수 있는 1회성 작업 파드가 실행되는 노드는 Spot 노드 사용
기존에는 Dev 환경 전체 노드를 Spot 노드 사용하였으나 최근 Spot 노드가 너무 자주 교체되고 Saving Plan 사용 시 비용 절감 효과가 그리 크지 않아 Dev 환경로 On-Demand도 변경 -
Karpenter 파드는 매니지드 노드 그룹 사용하지 않고 Fargate에 설치
AWS 매니지드 노드 그룹을 사용할 수 있으나 노드 수량을 줄이고 싶어 Fargate 이용(매니지드 노드 그룹 사용해도 크게 문제는 없음) -
AMI - Amazon Linux 2023 사용
회사에서 정책이 없다면 특정 버전 지정하지 않고 Karpenter 설정에 따라 자동으로 항상 최신 버전 AMI 사용
(현재 필자는 Amazon Linux v2 사용 중) -
워커 노드는 SSH 사용하지 않고 SSM 사용
사실상 운영 중 SSH 또는 SSM 사용하여 노드에 접속할일이 거의 없음
처음에 대단한 충격이었음. 관리자가 노드에 접속 할일이 없다???
노드 레벨 문제가 별로 발생하지 않고 발생하여도 node drain 후 노드를 교체하는 것으로 대부분의 문제를 해결하였다. -
EKS API Endpoint Private 사용
현재는 Private & Public 사용 중
(접속 가능한 Public IP 제한)
다수의 AWS 계정을 사용하는데, 하나의 AWS 계정에서 VPN 생성하고 해당 계정의 VPN을 다른 계정과 연결하면 된다고 하는데 아직 검증하지 않아 작업하지 못함 -
Add-on 리스트
vpc-cni, coredns, kube-proxy, ebs-csi-controller
EKS 업그레이드 작업 시 add-on도 같이 default 버전으로 업데이트 -
Dev, Stage, Prod 환경 EKS 분리
현재는 Dev + Stage는 공통 EKS 사용 -
보안 필요에 따라 같은 서비스라도 EKS 분리
현재 AWS 계정을 분리하여 4개의 EKS 운영 중 -
Krew(df-pv, get-all, neat, view-secret 사용), 필수 3총사(kube-ps1, k ns, k ctx) 사용
-
Pod Indentity Manager 사용
-
이미지 레포
깃헙 레포 + Private ECR 사용
ECR 좀 더 선호
개선 사항
- 개인적으로 현재 환경에서 개선이 필요한 사항들
- Security Group 정리
컨트롤플레인, LB, 워커 노드 간 SG 정리를 제대로 못하고 있음 - add-on : eks-node-monitoring-agent 검토
- IRSA to POD Indentity Manager 검토
- Karpenter to 1.x 업그레이드
