AWS 2022 summit - 3 (AWS CDK를 사용하여 모범사례 기반 Amazon EKS 클러스터 구축하기)

목차

AWS CDK 살펴보기

AWS CDK로 Amazon EKS 클러스터를 구축할 때 고려해야 될 모범 사례

요약 및 마무리

 

AWS CDK : AWS에서 제공하는 IaC 툴.

IaC를 사용하면 사용자는 구성 파일 또는 코드를 사용하여 원하는 인프라를 정의하고 일관성 및 반복성을 제공하기 위해 프로그래밍 방식으로 인프라를 생성할 수 있다.

그리고 IaC를 통해 인프라의 라이프 사이클을 더 쉽게 관리할 수 있다.

 

ex. 고객은 리포지토리를 이용해 인프라 구성 버전을 관리할 수 있고, 변경 사항을 이전 버전으로 손쉽게 롤백할 수도 있다.

또한 구성 파일의 변경은 애플리케이션 코드와 함께 CI/CD를 활용하여 개발, 테스트, 프로덕션 환경을 IaC 코드 변경과 동기화된 상태로 유지할 수 있다.

 

타입 스크립트로 IaC 구성

 

개발자들은 자신들에게 익숙한 언어를 사용하여 비즈니스 로직 뿐만 아니라 인프라 선언도 할 수 있다.

또한 코드로 인프라 자원을 추상화해서 작성했기 때문에, 다양한 인프라 환경을 빠르게 정의 및 배포할 수 있다.

 

(EKS를 생성하는 코드는 9-11, 단 3줄에 불과하다)

물론 커스텀 코드를 작성할 수 있지만, default 값이 있기 때문에 추가적으로 입력하지 않아도 오른쪽과 같은 인프라가 생성된 것이다.

CDK의 경우, AWS 모범 사례를 녹여서 작성되었기 때문에 EKS Cluster의 Worker Node가 Private Subnet에 존재하는 것을 알 수 있다.

 

Terraform을 CDK 언어로 작성할 수 있다.

-> 최대한 재사용 가능하게 만드는게 핵심 포인트다. 하드 코딩 대신 환경 변수를 이용한다든가, 라이브러리/프레임워크를 만든다는가.

 

---

애플리케이션 모범 사례

 

하나의 애플리케이션을 서비스 단위로 분리하는 것이 중요하다.

 

Liveness : Unhealthy한 Pod 제거

Readiness : 일시적으로 사용할 수 없는 상태 탐지

Startup : 처음 부팅 시간이 수 분 이상 걸리는 pod의 경우, startup probe를 사용해 liveness, readiness probe의 개시를 늦춤

 

EKS의 경우, 컨트롤 플레인은 AWS가 관리하기 때문에 고객은 API 서버, ETCD 클러스터와 같은 컴포넌트, 혹은 해당 노드들에 대한 운영 버든을 줄일 수 있다.

하지만 때에 따라 컨트롤 플레인이 제대로 작동하고 있는지, 클러스터에 문제가 생겼는데 컨트롤 플레인 단에서 발생한 문제인지를 확인하기 위해서 매트릭 값을 모니터링하거나 로그값을 수집할 필요가 있다.

 

* 활성화 가능한 컨트롤 플레인 로그 유형

- API : API 서버 로그

- Audit : 클러스터에 영향을 주는 개체들을 기록

- Authenticator : IAM 자격 증명에 기반한 RBAC 인증에 사용하는 컨트롤 플레인 요소들

- Controller manager : 병목 현상 및 에러와 같은 컨트롤 플레인의 문제를 진단하는 데 도움

- Scheduler : 

 

필요한 로그 유형을 선택하면 컨트롤 플레인 로깅을 통해 EKS 컨트롤 플레인에서 CloudWatch Logs로 진단 로그가 전송된다.

그리고 이러한 로그들은 CloudWatch Logs에서 가공이 될 수 있다.

 

ex. metric filters의 경우, 로그 데이터를 그래프로 표시하거나 알람을 설정할 수 있는 매트릭으로 변환 가능한 기능이다.

 

 

 

VPA는 뭘 말하는거지?

 

CAS의 경우, worker node가 올라오는 시간에 따라 지연이 발생할 수 있다.

이 지연시간을 감소시키기 위해 추가적으로 검토하는 매커니즘이 Overprovisioning이다.

우선 순위가 낮은 임시 pod를 미리 생성하고, 클러스터의 특정 공간을 차지하고 있다가, 새로 만든 pod가 unschedulable하고 우선 순위가 높을 때, 미리 만들어 놓은 임시 pod의 공간을 내준다. 그리고 이 임시 pod는 scale out을 trigger하는 원리로 작동한다.

 

(Azure의 Virtual Node와 개념이 좀 다른 것 같은데?)

 

Cluster Autoscaler말고 Karpenter라는게 있는데, 이게 더 좋다네..?

적절한 크기의 노드를 프로비저닝하고, 그 위에 pod을 올린대.

그리고 pod 없는 노드 발생하면, 노드 정지.

 

** 네임 스페이스를 활용한 자원 쿼터를 설정하는 것도 쿠버네티스 모범 사례이다.

-> 네임 스페이스로 할당량을 제한함으로써, 쿠버네티스 운영자들은 리소스로 인한 장애가 전체 클러스터로 전파되는 것을 막을 수 있다.

 

 

네트워크 모범 사례

- IP를 효율적으로 관리하는 방법?

 

 

EKS 클러스터의 경우, 디폴트로 AWS VPC CNI가 설정되어 있다.

VPC CNI의 경우, pod의 네트워크 대역과 worker node의 IP 대역이 같아서 직접 통신이 가능하다.

즉, pod가 EC2 인스턴스와 같이 하나의 AWS 리소스가 된다는 의미이고, 이는 VPC 내 IP를 소비한다는 의미이기도 하다.

그래서 EKS 클러스터를 구축할 때, 사용자는 worker node와 pod가 위치할 VPC, 서브넷, 그리고 인스턴스 타입 등을 미리 고려하는 것이 중요하다.

시스템의 현재 상태를 기반으로 타이트하게 설계하는 것이 아니고, 추우 확장할 때에도 충분한 IP를 확보할 수 있는지 미리 염두해야 한다.

 

그리고 IP 주소 인벤토리를 확인하기 위해, CNI Metrics Helper와 같은 툴을 사용하면 CloudWatch Alarms를 설정하여 서브넷의 IP 주소가 부족할 경우 알림을 받을 수 있다.

 

쿠버네티스는 인프라, 쿠버네티스 플랫폼, 애플리케이션 이렇게 세 가지 레이어에서 접근할 필요가 있다.

 

인프라 및 EKS 클러스터는 CDK를 이용하여 구축할 수 있다.

이때, 코드별 용도에 따라 디렉토리를 구분하고, 인프라 측면에서 EKS 모범 사례를 커스텀한 옵션에 넣을 수 있다.

그리고 VPC, Storage처럼 변동이 거의 없는 리소스는 별도의 CDK 스택에 정의하는 것이 모범 사례이고, 참조 값들은 환경 변수를 이용하는 것의 코드의 재사용을 높일 수 있다.

 

참고 자료