관련링크

들어가며

최근 MSA 아키텍처의 성숙도가 올라가면서, Kubernetes 환경을 찾는 사람들이 많아지고 있습니다. 이에 따라 많은 개발자, 엔지니어 분들이 Kubernetes에 대해 깊게 들여다보고 있습니다. 이번 글에서는 Kubernetes 아키텍처를 구성할 때, 고려해 볼 만한 클라우드 벤더 사용, 오토스케일링 전략, 배포 전략 등에 대해 소개해 보겠습니다.

Amazon EKS로 Cluster 생성

일반적인 쿠버네티스의 구조는 아래 그림과 같이 Master 와 Woker Nodes로 구성이 됩니다.

Amazon EKS를 사용한다면 Master Node의 관리를 운영자가 직접 하는 것이 아닌 AWS에서 지원합니다. 즉 클러스터 업데이트 등의 복잡한 작업들도 간단하게 AWS Console 상에서 할 수 있습니다. 이뿐만이 아닌 Amazon EKS의 AutoScaler는 AWS의 Auto Scaling Group을 이용하여 Cluster Node의 개수를 동적으로 조절할 수도 있고, 모니터링과 로깅 또한 별다른 설정 없이도 가능합니다. 하지만 장점만 있는 것은 아닙니다.

Amazon EKS는 Cluster 당 관리 비용이 부과되기 때문에, 작은 규모의 클러스터나 단일 인스턴스는 EC2로 직접 클러스터와 같이 관리적 부담이 적은 경우, EC2를 활용해 직접 구축을 하는 것을 고려해 볼 수 있습니다.

https://aws.amazon.com/ko/eks/pricing/

AutoScailing

안정적인 운영을 위해서는 AutoScailing은 필수입니다. 특히 Kubernetes는 Pod에 대한 AutoScailing, Node에 대한 AutoScailing이 동시에 적용이 되어있어야 안정적으로 작동합니다. 또한 유동적인 AutoScailing은 운영비용의 감소로도 이어질 수 있습니다.

AutoScailing in Kubernetes

Pod AutoScailing - HPA

• HPA 컨트롤러를 사용하여, Pod의 매트릭 값에 따라 Pod의 개수(Replicas)를 조절합니다.

Cluster AutoScailing

• Amazone EKS에서 Cluster AutoScailing에는 AWS AutoScailingGroup을 이용한 방법과 Karpenter를 이용한 방법이 있습니다. 이번 글에서는 AWS AutoScailingGroup를 이용하는 기본적인 Cluster AutoScailing에 대해 소개하겠습니다.
• Cluster Auto Scailing - AWS Cluster Autoscaler
  리소스 부족으로 Pending이 된 Pod이 있을 경우 Auto Scaling Group 상에 Node를 추가합니다.

AutoScailing Flow

1. HPA 컨트롤러가 주기적으로 Metric Server에 쿼리를 날립니다.
2. Pod의 CPU / Memory metric 이 사전에 약속된 수치를 넘으면 Replicas를 조정합니다.
3. Deployment에 Replicas 즉 Pod의 개수를 업데이트합니다.
4. Deployment는 Replicas에 따라 Pod 생성
   

여기서 만약에 모든 노드의 리소스가 부족하다면 → Pod pending 상태가 됩니다.

Cluster Autoscaler가 pending된 Pod이 있을 경우 ACS에 Node를 추가 Pod을 해당 Node에 할당합니다.

• Pod status : pending → running

AutoScailing 전략 : Spot+Ondemand Instance로 비용 최적화

기본 전략은 다음과 같습니다

• 안정적인 서비스를 위해서 최소한의 Ondemand NodeGroup 사용
• 유동적인 트래픽 증/감에 대비하기 위해 Spot NodeGroup을 사용
  → Ondemand Node의 리소스가 고갈이 될 경우 Spot Node를 사용하게끔

Taint를 활용한다면, Ondemand에 Pod을 할당할 수 없을 때만 Spot에 할당되게 강제할 수 있습니다.

• Spot NodeGroup의 Taint를 PreferNoSchedule로 설정

Spot을 사용하는데 가장 큰 우려점은 Spot Instance는 언제든 종료될 수 있다는 점입니다. 이를 방지하기 위해서는 다음과 같은 조치가 필요합니다.

• 종료가 되는지 확인
• 곧 종료 예정이라면 Taint를 이용해 해당 Node에 Pod이 새로 할당 되지 않게함
• 해당 Node에 있는 Pod들을 Drain
• 나머지 Node에 Pod을 할당

해당 작업을 가능하게 해주는 것이 AWS Node Termination Handler입니다

IDMS 방식을 사용할 경우 DaemonSet으로 설치되어 모든 Node에 설치되어, 인스턴스의 메타데이터를 모니터링한 뒤 종료가 예정되어 있으면 이전에 안내드렸던 과정을 수행합니다. (Label을 이용하여 Spot Node에만 적용)

Deployment

EKS 상에 Cluster를 생성한 뒤, NodeGroup을 생성하고 AutoScailing 전략을 적용시켰다면 기본적인 아키텍처의 구성은 완료가 된 것입니다. 이제 해당 Kubernetes에 애플리케이션을 빌드/배포하기 위해 다음과 같은 아키텍처를 구성할 수 있습니다.

• Github : Sourcecode와, Kubernetes manifestfile 저장,
  SourceCode 변경 시 Jenkins에 웹훅 보냅니다.
  
• Jenkins : 변경된 코드를 받아와 이미지 빌드 합니다.
  → AWS ECR에 Push, Github에 있는 Kube-manifest에 버전을 수정합니다.
  
• Argo CD: Kube-manifest의 변경을 탐지 (Sync) → Canary deploy
• Canary Deploy : 가용성을 높이기 위해 소량의 Pod만 배포 후, 점진적으로 배포합니다.

마무리하며

Kubernetes 환경 자체가 Learning Curve가 높기에 실제 운영 환경에 도입을 꺼려 하는 분들이 많은 것으로 알고 있습니다. 하지만 늦었다 생각할 때는 진짜 늦은 거라는 개그맨 박명수 님의 말처럼, 더 늦기 전에 Kubernetes 흐름에 편승을 해야 될 때가 지금이라고 생각을 합니다.