AWS EKS - POD 유지 관리 tip

---

AWS EKS - POD 유지 관리 tip

 

 

 

 

 

오토 스케일 아웃이 실행된 후 다시 스케일 인이 되었을때 워커노드에 실행중인 파드는 서비스 연속성을 보장 하는지?

파드의 서비스 연속성에 대해서 Pod HealthCheck 설정(Liveness, Readiness 그리고 Startup Probes) 뿐만 아니라, 
어플리케이션이 종료될 때에 graceful 하게 종료될 수 있도록 설정 작업이 필요합니다. 
관련되어서 아래 Pod HealthCheck, Graceful shutdown of SpringBoot Pod, 그리고 Kubernetes Pod Lifecycle 관련 링크를 참고해주시면 감사하겠습니다. 

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://yashwanth-nimmala.medium.com/kubernetes-graceful-shutdown-73bb23af2abd
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

 

 

EKS 버전 업데이트 시에 운영중인 서비스에 영향이 없는지 , 최소한의 영향이라면 어떤 서비스 유형이 영향이 있는지?

EKS 업그레이드에는 Control Plane 과 Date Plane 2개로 나뉩니다. 
Control Plane 경우, 업그레이드에 약 15분 내외로 소요되고, Kubernetes API Deprecation 에 대해서 유의를 해주셔야 합니다. 
Date Plane 경우, Pod 들이 올라가는 Computing 자원 (EC2, Fargate)으로 작업 시 어플리케이션의 유형에 따라 순단이 발생할 수 있습니다. 
그리고 업그레이드 정책을 어떻게 가져가냐에 따라서 순단 시간은 달라질 수 있습니다. 
EKS 업그레이드에 추천 방법은 Route53 이나 Proxy 를 이용하는 Blue / Green 업그레이드를 추천 드립니다.

https://aws.amazon.com/blogs/containers/kubernetes-cluster-upgrade-the-blue-green-deployment-strategy/
https://aws.amazon.com/blogs/containers/blue-green-or-canary-amazon-eks-clusters-migration-for-stateless-argocd-workloads/
https://aws.amazon.com/blogs/containers/planning-kubernetes-upgrades-with-amazon-eks/
https://aws.amazon.com/blogs/containers/preparing-for-kubernetes-api-deprecations-when-going-from-1-15-to-1-16/

 

 

EKS 워커노드 그룹의 인스턴스 스펙을 조정 방법, 조정하는 방법이 없다면 새롭게 워커노드 그룹을 생성해야 하는지?

EKS Worker Node Group에는 Self 와 Managed 2가지로 나뉩니다. 
Self 경우 Auto Scaling Group 를 이용하기 때문에 해당 설정을 변경하여 인스턴스 타입 변경이 가능합니다. 
Managed 경우 아직 공식적으로 인스턴스 타입 변경에 대해서 지원을 안하고 있습니다. 
Managed Node Group를 사용하시는 경우, 인스턴스 스펙 조정은 신규 그룹을 생성하여 넘기는 형태로 하는 것이 현재까지 방법입니다.

https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html
https://www.porter.run/blog/guide-updating-instance-type-on-aws-eks

 

 

EKS node version upgrade 시에 EKS node group 에 PV로 연결되어 있는 EBS 볼륨은 업그레이된 노드 그룹에 랜덤으로 연결 되는 것인지?

하단 캡처한 그림은 AZ a, b, c를 사용하는 Managed Node Group에 StatefulSet으로 EBS를 이용하여 PV와 PVC를 생성하였고, 
해당 PVC를 이용하여 mysql pod가 올라간 상태에서, Managed Node Group AMI 업그레이드를 하였을 때 부분입니다. 
pod에는 어떤 PVC를 사용하는지 명시된 상태에서 작업이 되었고, PV의 AZ와 같은 EC2 인스턴스 (Node)가 올라올 때까지는 연결에 지연이 됩니다. 
업그레이드 완료 후에는 정상적으로 서비스가 올라오는 것을 확인할 수 있습니다. 자세한 내용은 하단에 워크샵 링크를 참고해주시기 바랍니다.

https://www.eksworkshop.com/docs/fundamentals/storage/ebs/statefulset-with-ebs

 

 

EKS node version upgrade 를 rolling update 로 진행할때 pv로 연결된 ebs 볼륨이 있을 경우 업데이트가 실패 하는지?

위와 동일

 

 

EKS 업데이트 할때 다른 문제는 없을까요?

일반적으로 EKS 를 사용하시는 경우 업그레이드에 따른 영향은 없습니다. 
다만, Worker Node 에서 직접 docker 관련 보안 작업이나 튜닝, 그리고 명령어 사용 등이 있는 경우 이 부분은 확인이 필요합니다. 
그리고, 아래 flag 관련하여 유의해주시기 바랍니다.

https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-kubernetes-version-1-24/ 
https://marcincuber.medium.com/amazon-eks-upgrade-journey-from-1-23-to-1-24-b7b0b1afa5b4

 

 

 

---

by mkdir-chandler

---