AWS

[aws summit seoul 2023] Amazon EKS, 중요한 건 꺾이지 않는 안정성

한크크 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 정상 실행했는데 응답을 제대로 받을 수 없는 상황 , 비정상 감지 시 컨테이너 재시작
    • 장애 전파 되지 않도록 영향 범위 최소화 
      • 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)
    • 대규모 트래픽에도 빠르게 확장하여 안정성 유지 
      • 트래픽 부하 급증 시 
        • 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

 

반응형