Wdrażaj swoje klastry Amazon EKS Locally w placówkach AWS

Autorzy z przyjemnością ogłaszają dostępność lokalnych klastrów dla usługi Amazon Elastic Kubernetes Service (Amazon EKS) w AWS Outposts. Oznacza to, że od dzisiaj możesz wdrożyć swój klaster Amazon EKS całkowicie na Outposts: zarówno na płaszczyźnie kontrolnej Kubernetes, jak i na węzłach.

Amazon EKS to zarządzana usługa Kubernetes, która ułatwia uruchamianie Kubernetes w AWS i lokalnie. AWS Outposts to rodzina w pełni zarządzanych rozwiązań dostarczających infrastrukturę i usługi AWS do praktycznie dowolnej lokalizacji lokalnej lub brzegowej, zapewniając prawdziwie spójne wrażenia hybrydowe.

Abyś w pełni mógł zrozumieć zalety lokalnych klastrów dla Amazon EKS w Outposts, autorzy muszą najpierw podzielić się pewnym opisem.

Niektórzy klienci używają Outposts do wdrażania węzłów i zasobników klastra Kubernetes w pobliżu reszty infrastruktury lokalnej. Dzięki temu ich aplikacje mogą korzystać z dostępu do lokalnych usług i danych o małych opóźnieniach podczas zarządzania klastrem i cyklem życia węzłów przy użyciu tego samego interfejsu AWS API, CLI lub konsoli AWS, jak w przypadku klastrów opartych na chmurze.

Do dzisiaj, gdy wdrażałeś aplikacje Kubernetes w Outposts, zwykle zaczynałeś od utworzenia klastra Amazon EKS w chmurze AWS. Następnie wdrożyłeś węzły klastra na maszynach Outposts. W tym scenariuszu klastra hybrydowego płaszczyzna kontroli Kubernetes działa w nadrzędnym regionie Twoich placówek, a węzły działają w lokalnych placówkach. Usługa Amazon EKS komunikuje się przez sieć z węzłami działającymi na maszynie Outposts.

Jednak pamiętaj: wszystko cały czas zawodzi. Klienci powiedzieli twórcom AWS, że głównym wyzwaniem, z jakim mają do czynienia w tym scenariuszu, jest zarządzanie odłączeniami lokacji. To jest coś, czego nie da się kontrolować, zwłaszcza gdy rozmieszczasz Outposts na nierównych krawędziach: obszary o słabych lub przerywanych połączeniach sieciowych. Gdy obiekt lokalny jest tymczasowo odłączony od Internetu, płaszczyzna kontroli Amazon EKS działająca w chmurze nie może komunikować się z węzłami i zasobnikami. Chociaż węzły i zasobniki działają doskonale i nadal obsługują aplikację w lokalnej sieci, Kubernetes może uznać je za uszkodzone i zaplanować ich wymianę po ponownym nawiązaniu połączenia. Może to prowadzić do przestojów aplikacji po przywróceniu łączności.

Podczas przygotowywania tego tekstu autorzy rozmawiali z Chrisem, Product Managerem i ekspertem Kubernetes. Powiedział on, że istnieje co najmniej siedem różnych opcji konfiguracji sposobu, w jaki płaszczyzna kontrolna łączy się ponownie ze swoimi węzłami. Jeśli nie opanujesz wszystkich tych opcji, stan systemu przy ponownym połączeniu jest nieprzewidywalny.

Aby to uprościć, twórcy AWS dają Ci możliwość hostowania całego klastra Amazon EKS w Outposts. W tej konfiguracji zarówno płaszczyzna kontrolna Kubernetes, jak i węzły robocze działają lokalnie na maszynie Outposts. W ten sposób klaster będzie nadal działał nawet w przypadku tymczasowego zerwania połączenia z usługą. Podczas rozłączeń sieci z chmurą można wykonywać operacje klastra, takie jak tworzenie, aktualizowanie i skalowanie aplikacji.

Klastry lokalne są identyczne z Amazon EKS w chmurze i automatycznie wdrażają najnowsze poprawki zabezpieczeń, aby ułatwić utrzymanie aktualnego, bezpiecznego klastra. Możesz użyć tych samych narzędzi, których używasz z Amazon EKS w chmurze i AWS Management Console, aby uzyskać pojedynczy interfejs dla swoich klastrów działających w Outposts i AWS Cloud.

Działanie rozwiązania w akcji

Pora sprawdzić, jak możesz wykorzystać tę nową funkcję. W tym demo autorzy wdrożą płaszczyznę kontroli Kubernetes na instancjach Amazon Elastic Compute Cloud (Amazon EC2), które działają lokalnie na Outposts.

Użyj już skonfigurowanego stojaka Outposts. Jeśli chcesz dowiedzieć się, jak zacząć korzystać z Outposts, możesz przeczytać instrukcje zawarte na stronie Pierwsze kroki z Outposts AWS.

To demo składa się z dwóch części. Najpierw autorzy tworzą klaster. Potem łączą się z klastrem i tworzą węzły.

Tworzenie klastra

Przed wdrożeniem lokalnego klastra Amazon EKS w Outposts upewnij się, że utworzyłeś rolę klastra IAM i dołączyłeś politykę zarządzaną AmazonEKSLocalOutpostClusterPolicy. Ta rola klastra uprawnień będzie używana podczas tworzenia klastra.

Następnie przejdź do pulpitu nawigacyjnego Amazon EKS i wybierz Dodaj klaster, a potem Utwórz.

Na następnej stronie wybierz lokalizację płaszczyzny kontrolnej Kubernetes: AWS Cloud lub AWS Outposts. Wybierz AWS Outposts i określ Outposts ID.

Płaszczyzna kontroli Kubernetes w Outposts została wdrożona w trzech instancjach EC2 w celu zapewnienia wysokiej dostępności. Dlatego widzISZ trzy Repliki. Następnie wybierz typ instancji zgodnie z liczbą węzłów roboczych potrzebnych do obciążeń. Na przykład, aby obsłużyć 0–20 węzłów roboczych, zaleca się użycie instancji m5d.large EC2.

Na tej samej stronie określ wartości konfiguracyjne dla klastra Kubernetes, takie jak nazwa, wersja Kubernetes i utworzona wcześniej rola usługi klastra.

Na następnej stronie skonfiguruj opcje sieciowe. Ze względu na to, że Outposts jest rozszerzeniem regionu AWS, musisz użyć VPC i podsieci używanych przez Outposts, aby umożliwić komunikację między płaszczyzną kontroli Kubernetes a węzłami roboczymi. Dla grup bezpieczeństwa Amazon EKS tworzy grupę bezpieczeństwa dla klastrów lokalnych, która umożliwia komunikację między moim klastrem a moim VPC. Możesz również zdefiniować dodatkowe grupy bezpieczeństwa zgodnie z wymaganiami mojej aplikacji.

Uruchamiasz płaszczyznę kontrolną Kubernetes w Outposts, stąd dostęp do punktu końcowego klastra można uzyskać tylko prywatnie. Oznacza to, że możesz uzyskać dostęp do klastra Kubernetes tylko za pośrednictwem maszyn wdrożonych w tym samym środowisku VPC lub w sieci lokalnej za pośrednictwem lokalnej bramy Outposts z bezpośrednim routingiem VPC.

Na następnej stronie zdefiniuj logowanie. Logowanie jest domyślnie wyłączone i możesz je włączyć w razie potrzeby. Więcej informacji na temat rejestrowania znajdziesz w dokumentacji rejestrowania płaszczyzny sterowania Amazon EKS.

Ostatni ekran pozwala przejrzeć wszystkie opcje konfiguracyjne. Gdy jesteś zadowolony z konfiguracji, wybierz Utwórz, aby utworzyć klaster.

Tworzenie klastra zajmuje kilka minut. Aby sprawdzić stan utworzenia klastra, możesz użyć konsoli lub terminala za pomocą następującego polecenia:

Bash

$ aws eks describe-cluster \ 
--region <REGION_CODE> \ 
--name <CLUSTER_NAME> \ 
--query "cluster.status"

Sekcja Status poinformuje Cię, kiedy klaster jest utworzony i aktywny.

Oprócz korzystania z Konsoli Zarządzania AWS możesz również stworzyć klaster lokalny za pomocą AWS CLI. Oto fragment polecenia umożliwiający utworzenie lokalnego klastra za pomocą interfejsu AWS CLI:

Bash

$ aws eks create-cluster \

--region <REGION_CODE> \

--name <CLUSTER_NAME> \

--resources-vpc-config subnetIds=<SUBNET_ID>\

--role-arn <ARN_CLUSTER_ROLE> \

--outpost-config controlPlaneInstanceType=<INSTANCE_TYPE> \

--outpostArns=<ARN_OUTPOST>

Łączenie z klastrem

Dostęp do punktu końcowego dla lokalnego klastra jest prywatny; dlatego możesz uzyskać do niego dostęp z lokalnej bramy z bezpośrednim routingiem VPC lub z maszyn, które są w tej samej sieci VPC. Aby dowiedzieć się, jak korzystać z lokalnych bramek z Outposts, możesz zapoznać się z informacjami dostępnymi na stronie Praca z lokalnymi bramami. W tym demo używa się instancji EC2 jako hosta bastionu i zarządza klastrem Kubernetes za pomocą polecenia kubectl.

Pierwszą rzeczą, którą należy zrobić, jest edytowanie grup zabezpieczeń, aby otworzyć dostęp do ruchu z hosta bastionu. Przejdź do strony szczegółów klastra Kubernetes i wybierz kartę Sieć. Następnie wybierz łącze w grupie bezpieczeństwa klastra.

Kolejny krok: dodaj reguły ruchu przychodzącego i zapewnij dostęp do hosta bastionu, określając jego adres IP.

Po zezwoleniu na dostęp utwórz kubeconfig w hoście bastionu, uruchamiając polecenie:

Bash

$ aws eks update-kubeconfig --region <REGION_CODE> --name <CLUSTER_NAME>

Na koniec użyj kubectl do interakcji z serwerem API Kubernetes, tak jak zwykle.

Bash

$ kubectl get nodes -o wide

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME

ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 10h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket

ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 10h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket

ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 9h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket

Lokalne klastry Kubernetes działające na AWS Outposts działają na trzech instancjach EC2. Na powyższym wyjściu widzisz, że stan trzech węzłów to NotReady. Dzieje się tak, ponieważ są one używane wyłącznie przez control plane i nie możesz ich używać do planowania podów.

Na tym etapie możliwe jest wdrożenie samozarządzanych grup węzłów przy użyciu lokalnego klastra Amazon EKS.

Dostępność i ceny

Lokalne klastry Amazon EKS są rozliczane w tej samej cenie, co tradycyjne klastry EKS. Zaczyna się od 0,10 USD za godzinę. Instancje EC2 wymagane do wdrożenia płaszczyzny kontrolnej Kubernetes i węzłów w placówkach są wliczone w cenę placówek. Jak zwykle, strona z cennikiem zawiera szczegóły niezbędne szczegóły.

Lokalne klastry Amazon EKS są dostępne w następujących regionach AWS: wschodnie stany USA (Ohio, płn. Wirginia), zachodnie stany USA (płn. Kalifornia, Oregon), region Azji i Pacyfiku (Seul, Tokio), Europa (Frankfurt, Londyn), Bliski Wschód (Bahrajn) i Ameryka Południowa (São Paulo).

Rozpocznij tworzenie swojego pierwszego klastra EKS już dziś!

Źródło: AWS