기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

신뢰성 모범 사례

이 섹션에서는 EKS에서 실행되는 워크로드를 복원력과 가용성이 높게 만드는 방법에 대한 지침을 제공합니다.

이 설명서의 사용법

이 가이드는 EKS에서 가용성과 내결함성이 뛰어난 서비스를 개발하고 운영하려는 개발자와 아키텍트를 위한 것입니다. 이 가이드는 더 쉽게 사용할 수 있도록 다양한 주제 영역으로 구성되어 있습니다. 각 주제는 간략한 개요로 시작되며, EKS 클러스터의 신뢰성을 위한 권장 사항 및 모범 사례 목록이 이어집니다.

소개

EKS의 신뢰성 모범 사례는 다음 주제로 그룹화되었습니다.

시스템을 신뢰할 수 있는 이유는 무엇입니까? 일정 기간 동안 환경이 변경되더라도 시스템이 일관되게 작동하고 수요를 충족할 수 있는 경우 신뢰할 수 있다고 할 수 있습니다. 이를 위해서는 시스템에서 장애를 감지하고 자동으로 복구하며 수요에 따라 확장할 수 있어야 합니다.

고객은 Kubernetes를 기반으로 미션 크리티컬 애플리케이션 및 서비스를 안정적으로 운영할 수 있습니다. 그러나 컨테이너 기반 애플리케이션 설계 원칙을 통합하는 것 외에도 워크로드를 안정적으로 실행하려면 안정적인 인프라도 필요합니다. Kubernetes에서 인프라는 컨트롤 플레인과 데이터 플레인으로 구성됩니다.

EKS는 가용성과 내결함성이 뛰어난 프로덕션급 Kubernetes 제어 플레인을 제공합니다.

EKS에서 AWS는 Kubernetes 컨트롤 플레인의 신뢰성을 책임집니다. EKS는 AWS 리전의 3개 가용 영역에서 Kubernetes 컨트롤 플레인을 실행합니다. Kubernetes API 서버와 etcd 클러스터의 가용성과 확장성을 자동으로 관리합니다.

데이터 영역의 신뢰성에 대한 책임은 사용자, 고객 및 AWS 간에 공유됩니다. EKS는 Kubernetes 데이터 영역을 배포하기 위한 세 가지 작업자 노드 옵션을 제공합니다. 가장 관리형 옵션인 Fargate는 데이터 영역의 프로비저닝 및 조정을 처리합니다. 두 번째 옵션인 관리형 노드 그룹은 데이터 영역의 프로비저닝 및 업데이트를 처리합니다. 마지막으로 자체 관리형 노드는 데이터 영역에 대한 최소 관리형 옵션입니다. AWS 관리형 데이터 영역을 많이 사용할수록 책임이 줄어듭니다.

관리형 노드 그룹은 EC2 노드의 프로비저닝 및 수명 주기 관리를 자동화합니다. EKS API(EKS 콘솔, AWS API, AWS CLI, CloudFormation, Terraform 또는 사용eksctl)를 사용하여 관리형 노드를 생성, 확장 및 업그레이드할 수 있습니다. 관리형 노드는 계정에서 EKS 최적화 Amazon Linux 2 EC2 인스턴스를 실행하며 SSH 액세스를 활성화하여 사용자 지정 소프트웨어 패키지를 설치할 수 있습니다. 관리형 노드를 프로비저닝하면 여러 가용 영역에 걸쳐 있을 수 있는 EKS 관리형 Auto Scaling 그룹의 일부로 실행됩니다. 관리형 노드를 생성할 때 제공하는 서브넷을 통해 이를 제어합니다. 또한 EKS는 관리형 노드에 태그를 자동으로 지정하여 Cluster Autoscaler와 함께 사용할 수 있습니다.

Amazon EKS는 관리형 노드 그룹의 CVE 및 보안 패치에 대한 공동 책임 모델을 따릅니다. 관리형 노드는 Amazon EKS 최적화 AMIs를 실행하므로 Amazon EKS는 버그 수정 시 이러한 AMIs의 패치 버전을 빌드할 책임이 있습니다. 그러나 이렇게 패치된 AMI 버전은 사용자가 관리형 노드 그룹에 배포해야 합니다.

또한 EKS는 노드 업데이트를 관리하지만 업데이트 프로세스를 시작해야 합니다. 관리형 노드 업데이트 프로세스는 EKS 설명서에 설명되어 있습니다.

자체 관리형 노드를 실행하는 경우 Amazon EKS 최적화 Linux AMI를 사용하여 작업자 노드를 생성할 수 있습니다. AMI와 노드를 패치하고 업그레이드하는 것은 사용자의 책임입니다. eksctl, CloudFormation 또는 인프라를 코드 도구로 사용하여 자체 관리형 노드를 프로비저닝하는 것이 가장 좋습니다. 이렇게 하면 자체 관리형 노드를 쉽게 업그레이드할 수 있기 때문입니다. 마이그레이션 프로세스는 이전 노드 그룹을 로 테인팅NoSchedule하고 새 스택이 기존 포드 워크로드를 수락할 준비가 된 후 노드를 드레이닝하므로 작업자 노드를 업데이트할 때 새 노드로 마이그레이션하는 것이 좋습니다. 그러나 자체 관리형 노드의 인플레이스 업그레이드를 수행할 수도 있습니다.

공동 책임 모델 - Fargate

공동 책임 모델 - MNG

이 가이드에는 EKS 데이터 영역, Kubernetes 코어 구성 요소 및 애플리케이션의 신뢰성을 개선하는 데 사용할 수 있는 권장 사항 세트가 포함되어 있습니다.

Feedback

이 가이드는 더 광범위한 EKS/Kubernetes 커뮤니티에서 직접적인 피드백과 제안을 수집하기 위해 GitHub에서 릴리스됩니다. 가이드에 포함해야 한다고 생각되는 모범 사례가 있는 경우 GitHub 리포지토리에 문제를 제기하거나 PR을 제출하십시오. 새로운 기능이 서비스에 추가되거나 새로운 모범 사례가 발전할 때 가이드를 주기적으로 업데이트하려고 합니다.