EKS 확장성 모범사례¶
이 가이드에서는 EKS 클러스터 확장에 대한 조언을 제공합니다. EKS 클러스터를 확장하는 목적은 단일 클러스터가 수행할 수 있는 작업량을 최대화하는 것입니다. 하나의 대규모 EKS 클러스터를 사용하면 여러 클러스터를 사용하는 것에 비해 운영 부하를 줄일 수 있지만 멀티 리전 배포, 테넌트 격리, 클러스터 업그레이드 등의 측면에서 단점이 있습니다. 이 문서에서는 단일 클러스터로 확장성을 극대화하는 방법에 초점을 맞출 것입니다.
가이드 사용법¶
해당 가이드는 AWS에서 EKS 클러스터를 생성하고 관리하는 개발자 및 관리자를 대상으로 합니다. 이 백서는 몇 가지 일반적인 쿠버네티스 확장 사례를 중점적으로 다루지만, 자체 관리형 쿠버네티스 클러스터 또는 EKS Anywhere를 사용하여 AWS 리전 외부에서 실행되는 클러스터에 대한 구체적인 내용은 디루지 않습니다.
각 주제에는 간략한 개요가 포함되며, EKS 클러스터를 대규모로 운영하기 위한 권장 사항 및 모범 사례가 이어집니다. 주제를 특정 순서로 읽을 필요는 없으며 클러스터에서 작동하는지 테스트하고 검증하지 않고는 권장 사항을 적용해서는 안 됩니다.
크기 조정 요소에 대한 이해¶
확장성은 성능 및 안정성과 다르므로 클러스터 및 워크로드 요구 사항을 계획할 때는 이 세 가지를 모두 고려해야 합니다. 클러스터가 확장되면 모니터링이 필요하지만 이 가이드에서는 모니터링 모범 사례를 다루지 않습니다. EKS는 대규모로 확장할 수 있지만, 클러스터를 300개 노드 또는 5000개 이상의 파드로 확장할 방법을 계획해야 합니다. 절대적인 수치는 아니지만 이 가이드를 여러 사용자, 엔지니어 및 서포트 전문가와 공동으로 작업한 결과입니다.
쿠버네티스의 확장은 다차원적이며 모든 상황에 맞는 특정 설정이나 권장 사항은 없습니다. 확장에 대한 지침을 제공할 수 있는 주요 영역은 다음과 같습니다.
쿠버네티스 컨트롤 플레인은 EKS 클러스터에는 AWS가 실행하고 사용자를 위해 자동으로 확장되는 모든 서비스 (예: 쿠버네티스 API Server) 가 포함됩니다. 컨트롤 플레인을 확장하는 것은 AWS의 책임이지만 컨트롤 플레인을 책임감 있게 사용하는 것은 사용자의 책임입니다.
쿠버네티스 데이터 플레인 규모 조정은 클러스터 및 워크로드에 필요한 AWS 리소스를 다루지만 EKS 컨트롤 플레인을 벗어납니다. EC2 인스턴스, kublet, 스토리지를 비롯한 모든 리소스는 클러스터 확장에 따라 확장해야 합니다.
클러스터 서비스는 클러스터 내에서 실행되며 클러스터 및 워크로드에 기능을 제공하는 쿠버네티스 컨트롤러 및 애플리케이션입니다. 여기에는 EKS 애드온이 포함될 수 있으며 규정 준수 및 통합을 위해 설치하는 기타 서비스 또는 헬름 차트도 포함될 수 있습니다. 이런 서비스는 워크로드에 따라 달라지는 경우가 많으며 워크로드가 확장됨에 따라 클러스터 서비스도 함께 확장해야 합니다.
워크로드는 클러스터가 있는 이유이며 클러스터와 함께 수평으로 확장되어야 합니다. 클러스터 확장에 도움이 될 수 있는 쿠버네티스의 워크로드 통합 및 설정이 있습니다. 네임스페이스 및 서비스와 같은 쿠버네티스 추상화에 대한 아키텍처 고려 사항도 있습니다.
초대형 스케일링¶
단일 클러스터를 1,000개 노드 또는 50,000개 이상의 파드로 확장하려는 경우 문의하고 싶습니다. 지원 팀이나 기술 계정 관리자에게 문의하여 이 가이드에 제공된 정보 이상으로 계획하고 확장하는 데 도움을 줄 수 있는 전문가에게 문의하는 것이 좋습니다.