-
[aws summit seoul 2023] Amazon EKS, 중요한 건 꺾이지 않는 안정성AWS 2024. 3. 18. 18:58
#aws summit seoul 2023 에서 발표된 Amazon EKS, 중요한 건 꺾이지 않는 안정성 영상을 보고 정리한 내용입니다.
- EKS - 4개 버전 제공
- AWS 가 컨트롤 플레인 운영 책임을 가져간다는게 장점
- 워커노드 타입 - 셀프 매니지드 EC2, 매니지드, Fargate (서버리스)
- 안정성이란 ?
- 고가용성
- replication 을 기본으로 운영하다가 장애 발생 시 서비스 제외
- 유저 입장에서 고장 인지를 할 수 없도록 함
- 재해복구
- 천재지변 등 예측하기 어려운 극단적 상황
- 빠른 복구 , 데이터 손실 최소화가 목표
- 고가용성
- EKS 안정성이란?
- etcd, node, deploy, svc, vol, pod 등 모든 컴포넌트를 안정적으로 운영
- EKS 책임 공유 모델
- 인프라 (H/W), 컨트롤 플레인 (API 서버, 클라우드 컨트롤러, 컨트롤러 매니저, 스케줄러, etcd) - AWS
- 데이터 플레인 - 고객
- 컨트롤 플레인(AWS 계정), 데이터플레인 (사용자 계정) - 교차 계정 ENI 제공
- Kubernetes API 서버는 교차 계정 ENI를 사용하여 컨트롤 플레인과 데이터 플레인 간 통신 (kubectl)
- 컨트롤 플레인 고가용성 설계
- API Server - NLB 로 부하 분산 , 오토 스케일링 그룹 (최소 2대)
- etcd - 오토 스케일링 그룹 (최소 3대)
- CPU, MEM 사용량에 따라 인스턴스 스케일링 업/다운 → 스케일 업 되더라도 추가 비용 없음
- 데이터 플레인 안정성
- 오류 발생시에도 자가 복구
- k8s 상태 복구 메커니즘에 따라 자가 복구 기능 내장 (컨트롤 루프)
- deployment (Replicas)
- application 자가 복구 방안
- 헬스체크 - http 요청, command, tcp socket
- readinessProbe - pod 가 서비스 요청을 받을 준비가 되었는지, 비정상 감지 시 서비스 엔드포인트에서 제거
- livenessProbe - application 정상 실행했는데 응답을 제대로 받을 수 없는 상황 , 비정상 감지 시 컨테이너 재시작
- 헬스체크 - http 요청, command, tcp socket
- 장애 전파 되지 않도록 영향 범위 최소화
- pod 스케줄링 - 노드 선정 기준 (node resource, affinity, request/limit)
- podAntiAffinity
- node label 을 기준으로 app 지정 label을 가진 pod 가 실행중이라면 가급적 (preferred) or 반드시 (required) 해당 노드에 pod 를 배포하지 말 것
- topologySpreadConstraints
- app 지정 label 을 가진 Pod 가 실행될 때 노드의 가용영역 라벨 (topologyKey)을 기준으로 pod를 분산하고, 최대 1개의 pod 수 차이를 허용(maxSkew:1)
- podAntiAffinity
- pod 스케줄링 - 노드 선정 기준 (node resource, affinity, request/limit)
- 대규모 트래픽에도 빠르게 확장하여 안정성 유지
- 트래픽 부하 급증 시
- pod / node 확장 → HPA, CA
- metric server 수집 리소스 사용량에 따라 HPA 동작, pod pending 상태에 따라 CA 동작
- CA → node 확장까지 시간 소요 , 노드 스펙 별로 그룹 생성 → Karpenter 등장 ( https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider )
- pending pods 가 발생하면 karpenter 가 가장 적합한 인스턴스 유형을 선택해서 노드 생성
- 트래픽 부하 급증 시
- 중요도 높은 서비스를 안정적으로 유지하려면
- eviction
- 컴퓨팅 자원(CPU/MEM) 에 대한 정의 - Request / Limit
- QoS 클래스
- BestEffort - request/limit 미지정 → eviction 1순위
- Burstable - request/limit 지정했으나 값의 차이가 있는 경우 → eviction 2순위
- Guaranteed - request/limit 이 동일한 값으로 지정 → eviction 순위 가장 낮음
- EKS 버전 업데이트
- 3개월 단위로 마이너 버전 업데이트 → 릴리즈 버전 최대 14개월 지원 → 1년에 한번은 업데이트 해야함
- deprecated 되는 api 가 있을 수 있으므로 테스트 환경에서 꼭 먼저 수행해야 함
- 워커노드 업데이트 진행 시
- 새로운 버전의 노드 생성
- cordon 명령 실행 → 스케줄링 disabled
- drain 명령 실행 → 새로운 노드로 pod 배치
- Pod Disruption Budget - 별도 설정해야 함
- drain 명령 실행 시 다른 노드에 스케줄링 가능한지 여부를 체크하지 않음
- pod disruption budget - 최소 pod (minAvailable) 요구 replica 를 만족시킨 이후 drain 실행
- in-place 버전 우려사항
- 이전 버전 롤백 불가능 , 장애, 한단계 씩 버전 업데이트 필요
- blue-green 버전 업데이트 방식 적용
- 현재 버전 / 신규 버전 클러스터 구성하여 Route53 에서 가중치 조정하여 분배, 문제 발생 시 가중치 조정하여 롤백
- argocd, gitops 를 통한 인프라 코드화 필요
- 오류 발생시에도 자가 복구
- EKS 로드맵 - https://github.com/aws/containers-roadmap/projects/1?card_filter_query=eks
반응형'AWS' 카테고리의 다른 글
[aws summit seoul 2023] LG유플러스 IPTV 서비스, 무중단 클라우드 마이그레이션 이야기 (0) 2024.04.08 [aws summit seoul 2023] 당신만 모르고 있는 AWS 컨트롤 타워 트렌드 (0) 2024.03.28 [aws summit seoul 2023] 12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처 (0) 2024.03.15 [aws summit seoul 2023] 삼성전자/쿠팡의 대규모 트래픽 처리를 위한 클라우드 네이티브 데이터베이스 활용 (0) 2024.03.04 AWS cloudformation , codedeploy 를 활용한 프로비저닝 관리 (0) 2016.08.03