Płaszczyzna sterowania EKS i węzły robocze

Amazon Elastic Kubernetes Service (EKS) to w pełni zarządzana usługa Kubernetes, która eliminuje konieczność instalowania, obsługiwania i utrzymywania płaszczyzny sterowania Kubernetes. AWS uruchamia, skaluje i aktualizuje płaszczyznę sterowania w wielu strefach dostępności, zapewniając wysoce dostępną końcówkę klastra. Mogą się Państwo skupić wyłącznie na wdrażaniu i zarządzaniu obciążeniami aplikacji.

EKS control plane składa się z serwera API, etcd, menedżera kontrolerów i harmonogramu — wszystkie te elementy są zarządzane przez AWS. Działają one na kontach należących do AWS, co oznacza, że nie można łączyć się z nimi przez SSH. AWS gwarantuje 99.95% SLA dla końcówki API EKS i automatycznie zastępuje niesprawne węzły płaszczyzny sterowania. Za płaszczyznę sterowania płacą Państwo stałą opłatę za klaster i godzinę.

Klaster EKS można utworzyć za pomocą AWS Console, eksctl lub CloudFormation. Klaster wymaga VPC z podsieciami w co najmniej dwóch AZ oraz roli IAM, która nadaje płaszczyźnie sterowania Kubernetes uprawnienia do wywoływania interfejsów API AWS. Po utworzeniu klaster udostępnia końcówkę w postaci adresu HTTPS, który należy skonfigurować w kubeconfig.

Po utworzeniu klastra należy zaktualizować lokalny plik kubeconfig, aby kubectl wiedział, jak połączyć się z serwerem API EKS. AWS CLI automatycznie generuje wymagany wpis. Serwer API EKS używa AWS IAM for authentication — użytkownik lub rola IAM są mapowane na tożsamość Kubernetes RBAC za pośrednictwem obiektu ConfigMap aws-auth.

Managed node groups pozwalają AWS w Państwa imieniu aprowizować, rejestrować i zarządzać cyklem życia roboczych węzłów EC2. Po zażądaniu aktualizacji lub wymiany EKS automatycznie opróżnia pody, zastępuje instancję i ponownie ją rejestruje — wszystko bez ręcznej ingerencji. Zarządzane grupy węzłów korzystają wewnętrznie z Auto Scaling Groups, zapewniając kontrolę nad minimalną, maksymalną i docelową pojemnością oraz integrację z Cluster Autoscaler.

W przypadku self-managed node groups uruchamiają Państwo instancje EC2 samodzielnie (za pomocą CloudFormation lub Terraform), a następnie rejestrują je w klastrze EKS, uruchamiając skrypt bootstrap. Zapewnia to maksymalną elastyczność — można używać custom AMIs, typów instancji z GPU lub wysoce dostosowanych konfiguracji jądra — ale pełna odpowiedzialność za aktualizowanie poprawek, opróżnianie i wymianę węzłów spoczywa na Państwu.

Każdy węzeł roboczy musi działać z użyciem EC2 instance profile zawierającego trzy zasady zarządzane przez AWS: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy oraz AmazonEC2ContainerRegistryReadOnly. Umożliwiają one węzłowi dołączenie do klastra, zarządzanie siecią podów za pomocą wtyczki VPC CNI oraz pobieranie obrazów z ECR. Bez tych zasad węzły nie zarejestrują się poprawnie.

EKS używa obiektu aws-auth ConfigMap w przestrzeni nazw kube-system do mapowania użytkowników i ról IAM na nazwy użytkowników oraz grupy Kubernetes. Po utworzeniu klastra tylko tożsamość IAM twórcy otrzymuje automatycznie uprawnienia administratora. Aby umożliwić innym użytkownikom lub rolom CI/CD dostęp do klastra, należy dodać do tej ConfigMap wpisy z odpowiednimi kluczami mapRoles lub mapUsers.

EKS add-ons to wyselekcjonowane i zweryfikowane przez AWS komponenty programowe — takie jak VPC CNI, CoreDNS i kube-proxy — które EKS może instalować i aktualizować w Państwa imieniu. Podczas aktualizacji wersji Kubernetes klastra najpierw aktualizują Państwo płaszczyznę sterowania, a następnie każdą zarządzaną grupę węzłów do zgodnej wersji. EKS obsługuje różnicę maksymalnie jednej wersji pomniejszej (N-1) między płaszczyzną sterowania a węzłami w okresie wdrażania.

Końcówkę serwera API EKS można skonfigurować jako public only, private only lub oba warianty jednocześnie. Publiczne końcówki są zabezpieczone uwierzytelnianiem IAM, a końcówki dostępne wyłącznie prywatnie wymagają, aby kubeconfig łączył się z VPC przez VPN lub Direct Connect. Można również włączyć envelope encryption zapisanych sekretów Kubernetes za pomocą klucza AWS KMS, zapewniając dodatkową warstwę ochrony wrażliwych danych konfiguracyjnych.

Cluster Autoscaler to pod Kubernetes, który monitoruje niemożliwe do zaplanowania pody i automatycznie dostosowuje rozmiar grup Auto Scaling Group zarządzanych grup węzłów. Gdy nie można zaplanować podów z powodu niewystarczających zasobów, Cluster Autoscaler zwiększa skalę. Gdy węzły są niedostatecznie wykorzystywane, a ich pody można ponownie zaplanować w innych miejscach, zmniejsza skalę. Wymaga uprawnień IAM do wywoływania interfejsu API EC2 Auto Scaling za pośrednictwem IRSA.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji poznali Państwo: AWS zarządza płaszczyzną sterowania EKS zgodnie z umową SLA na poziomie 99,95%, zarządzane grupy węzłów pozwalają AWS obsługiwać cykl życia węzłów, podczas gdy grupy zarządzane samodzielnie zapewniają maksymalne możliwości dostosowania, a ConfigMap aws-auth mapuje tożsamości IAM na Kubernetes RBAC w celu kontroli dostępu do klastra. Następnie omówimy profile Fargate przeznaczone do bezserwerowego uruchamiania podów.