[EKS] EKS v1.22 업그레이드, 작업노트 정리

 

ㅁ 들어가며

 ㅇ 운영 EKS 업그레이드 작업 시 작성한 작업절차를 정리하였다.

 

ㅁ EKS 업그레이드 테스트

EKS 업그레이드
 - 1탄: EKS, AddOn
 - 2탄: WorkNode
 - 3탄:  kubectl

위의 글은 업그레이드를 하기 전에 EKS를 현 버젼으로 구성하여 업그레이드 하는 과정을 테스트하고 그 과정을 정리하였다.

 

ㅁ 신규 Bastion 서버 부팅

 ㅇ 신규 EKS를 관리하기 위한 Bastion 서버를 사전 준비하였다.

 ㅇ [EKS] Amazon EKS 버전 업그레이드, #3 kubectl 설치 또는 업데이트
 ㅇ [kubernetes] eksctl 설치 및 zsh bash 쉘 자동 완성 활성화, eksctl 자동완성
 ㅇ eksctl 트러블슈팅:

     ㄴ bastion에서 eksctl 설치 및 자동완성도 활성화 하였는데,

     ㄴ 이게 용량이 커서 bastion 초기 접근 시 15초정도 딜레이가 있었다.

     ㄴ 그래서 신규 Bastion에서는 자동완성 기능을 사용하지 않았다.

 

ㅇ kubeconfig 파일을 사용하여 클러스터 접근 구성하기

   ㄴ 클러스터 접근 구성

 

ㅁ HPA 고도화 적용

 ㅇ 현재 운영하는 서비스는 deployment로 선언하여 HPA를 구성한 상황이다.

 ㅇ 트래픽에 따라 노드가 증설되면 HPA를 수동으로 변경하였다.

 ㅇ 이를 자동화해주는 Pod를 생성하여 노드의 갯수에 따라 HPA 설정을 자동으로 변경해 주었다.

 ㅇ 하지만 특정 node에 pod가 몰리는 경향이 있어서 리벨런싱 해야 했음.

 ㅇ 이유는 node 기동 + pod 기동이 몰리면서 신규노드가 아닌 기존 노드로 pod 스케쥴링됨.

 ㅇ 고도화는 HPA 설정 변경 시 시간적 딜레이를 주어서 HPA 구성이 급격하게 변하지 않도록 변경하였다.

 

ㅁ Launch Configuration(시작 구성) -> Lanunch Template(시작 템플릿) 변경작업

 

 ㅇ AWS 정책 변경으로 시작 템플릿으로 변경작업 수행해야했음.

 ㅇ [AWS AutoScaling] 시작 구성과 시작 템플릿의 차이점에 대해서 정리하였고, 테스트를 위한 시작구성이 필요하여 생성하는 과정을 정리하였다.

1편  [AWS AutoScaling] 시작구성 생성, AutoScalingGroup 생성
2편 [AWS AutoScaling] 시작 구성과 시작 템플릿의 차이점
3편  [AWS AutoScaling] 시작구성을 시작 템플릿으로 마이그레이션하기

 

 

ㅁ CSI Driver 설치

pod(volume) - pvc - pv를 연동하여 정적데이터를 볼륨에 저장할 수 있다. pv가 AWS와 연동하여 AWS EBS를 생성해 주기 위해서는 CSI Driver가 필요하다. 설치는 AWS Console에서 수행하였다.

 쿠버네티스에서 pv로 스토리지를 요구하면 CSI Driver를 통해 AWS EBS를 프로비저닝 할 수 있다. 이번 기회에 드라이버도 함께 증설하였다. 

  [EBS] gp2 생성, gp3 업그레이드, 포퍼먼스 테스트에서 gp3로 변경해야하는데 CSI Driver를 업데이트 할 수 없었고, 이 때문에 CSI Driver 설치 없이 AWS Console에서 gp2에서 gp3로 타입변경을 한 상태에서 포퍼먼스 테스트를 진행한 적 있다. 결론적으로 쿠버네티스에서 gp2 형태이지만 AWS EBS gp3이라도 성능상 문제는 없었다.

 

다른 관련 글

ㅇ [AWS] Amazon EBS gp2 vs gp3 비교
ㅇ [EBS] EKS 생성, MongoDB 구성, gp2에서 gp3 EBS 볼륨으로 마이그레이션

 

ㅁ 메인노드그룹

1. 신규 노드그룹 용 IAM role 생성 (사전 작업 가능)
 ㄴ 기존 Main / Sub 노드 IAM role 참고하여 동일한 권한으로 생성

 

2. 신규 Launch Template 생성 (사전 작업 가능)
 ㄴ기존 노드그룹 Launch Configuration -> Launch Template 으로 Copy
 ㄴ EBS type gp3로 수정
 ㄴ IAM 인스턴스 프로파일 지정 제외
 ㄴ 태그 Name 추가 (ASG에서 배포될 노드의 이름, 제외 시 이름없이 생성됨)
 ㄴ 리소스기반 IPv4 DNS 요청 활성화 체크
 ㄴ user data 수정 (스택관련 내용 제거)

3. EKS Managed node group 생성
 ㄴ EKS 클러스터 내 컴퓨팅 -> 노드그룹 생성 (상기 3의 Launch Template 기반 생성)
 ㄴ   desire 2, min 2, max 8 배포
 ㄴ 개발/검수망 리허설 시 초기 첫 번째 서비스 POD creating 시점에 efs 관련 일시적 에러 발생함

    해당 에러 모니터링 필요

4. 신규 Auto Scale Group 속성 수정
 ㄴ유예기간 default 15 -> 0으로 조정 (optional, 빠른 수행 목적)
 ㄴ(skip) 종료정책 가장 최신 인스턴스 종료로 변경
  -> scale-in 시 EKS에서 drain 작업을 수행하여 taint 선수행 필요없이 종료해도 무관함
 ㄴ auto scale-out 정책 추가 (신규 설정하는게 좋음)
 ㄴ 수명주기Hook 설정 (ASG) 및 event bridge 신규노드그룹 추가

5. 기존 CloudFormation 노드그룹 순차 Taint/축소 (4->0)
 ㄴ  IP부족 (rolling update 시 1대분 IP 추가로 필요하므로)으로 EKS 노드그룹 1대 증가(2->3)
 ㄴ 동시에 기존 노드그룹 1대 감소 (4->3) 순으로 진행 (기존노드는 taint 수행필요)

 

ㅁ 서브노드그룹

1. 상기 (1)메인노드그룹의 1~2 반복

2. EKS Managed node group 생성

 ㄴ EKS 클러스터 내 컴퓨팅 -> 노드그룹 생성 (상기 2의 Launch Template 기반 생성)
 ㄴ desire 2, min 2, max 2 배포

 

3. 신규 ASG 속성 수정
 ㄴ 유예기간 default 15 -> 0으로 조정 (optional)
 ㄴ 수명주기Hook 설정 (ASG) 및 event bridge 신규노드그룹 추가

4. 기존 C.F. 노드그룹 Taint/축소 (2->0)

 

 

ㅁ 기존 CF 삭제 (12/23 까지 테스트 후 정상인 경우 수행)

ㅇ TOBE 테스트 후 정상인 경우 수행

ㅇ 기존 노드인스턴스Role에 연결된 정책 선행 삭제 필요 (안하면 Role 충돌남)

ㅇ 최초 1회 삭제 실패 발생 후 SG 만 유지할 리소스 체크하고 스택삭제하면됨

 

ㅁ 후기

 1. auto-scaling-pod 변경 시 기존 POD replica 0 상태에서 진행해야함 

   ㄴ (2개 동시 동작으로 POD개수가 일시적으로 증/감 발생할 수 있음)
 2. 일반적인 scale-in 시에도 EKS 알아서 대상노드의 POD를 선행적으로 drain 해주어 매우 편리했음.

 

ㅁ 함께 보면 좋은 사이트

Amazon EKS 클러스터용 kubeconfig 파일 생성 또는 업데이트 - Amazon EKS