Jak podłączyć się do klastra Amazon EKS?

Uruchomiłeś właśnie swój pierwszy klaster Kubernetes w usłudze Amazon EKS i pewnie zastanawiasz się, co dalej. Jak się do niego podłączyć? W konsoli samej usługi nie za bardzo da się cokolwiek zrobić. Jest tam trochę informacji i praktycznie nic poza tym.

Klastrami Kubernetesa zarządzamy za pomocą narzędzia kubectl. W artykule pokażę Ci, w jaki sposób skonfigurować maszynę z Linuxem na pokładzie, aby móc zarządzać klastrem w EKS.

Na początek jedna uwaga. Wszystkie URL-e do instalowanych narzędzi są aktualne w momencie, gdy piszę ten tekst (grudzień 2019). Jeżeli będziesz czytać ten artykuł za jakiś czas, sprawdź proszę, czy nie ma dostępnych nowszych wersji.

Krok 1. Instalujemy narzędzia

Kubectl

1. Zaczynamy od instalacji kubectl. Narzędzie zainstalujemy w wersji „Amazonowej”.

curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/kubectl

2. Następnie czynimy ten plik wykonalnym:

chmod +x ./kubectl

3. Teraz kopiujmy go w jakieś wygodniejsze miejsce i ułatwiamy sobie życie, dodając go do przeszukiwanych miejsc.

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

4. Dodamy jeszcze nasz kubetcl do pliku .bashrc, dzięki czemu po ponownym uruchomieniu maszyny będzie on nadal dostępny.

echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc

5. Na koniec sprawdzamy, czy wszystko działa.

kubectl version --client --short

AWS IAM Authenticator

Jeśli wszystko jest w porządku, możemy zainstalować AWS IAM Authenticator. To narzędzie, którego Kubernetes używa do autentykacji w AWS.

Wszystkie polecania wykonujemy po kolei, podobnie jak w przypadku kubectl:

curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/
bin/linux/amd64/aws-iam-authenticator
 

chmod +x ./aws-iam-authenticator
mkdir -p $HOME/bin && cp ./aws-iam-authenticator
$HOME/bin/aws-iam-authenticator && export PATH=$HOME/bin:$PATH 
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc 

Teraz sprawdzamy oczywiście, czy authenticator działa:

aws-iam-authenticator help

Krok 2. Konfigurujemy klaster

W następnym kroku musimy stworzyć kubeconfig.

1. AWS IAM Authenticator for Kubernetes używa między innymi komendy aws sts get-caller-identity. Jest ona dostępna w CLI od wersji 1.16.156. Warto więc sprawdzić, którę wersją AWS CLI dysponujemy:

aws --version

2. I ewentualnie wykonać update:

pip install awscli --upgrade --user

3. Zakładam, że CLI jest skonfigurowane. Jeżeli nie, to teraz jest na to ostatni moment. Zakładam, że mamy nowy klaster EKS, użytkownikiem musi być więc ten, który ten klaster stworzył. To ważne.

aws configure

4. W końcu dodajemy nowy kontekst za pomocą polecenia:

aws eks --region region update-kubeconfig --name clustername

W moim przypadku wyglądało to tak:

Stworzyliśmy plik ~/.kube/config  Ciekawi mogą do niego zajrzeć:

cat ~/.kube/config

Możemy już spróbować jakiejś interakcji z naszym klasterm EKS. Spróbujemy pobrać listę serwisów:

kubectl get services --all-namespaces

Działa? Działa. 🙂

Krok 3. Dodajemy innych użytkowników klastra

Dodajmy teraz kolejnego użytkownika do naszego klastra. Ktoś musi nam przecież pomóc w codziennej pracy.

Aby to zrobić, musimy wyedytować aws-auth ConfigMap. Jest to konfiguracja, którą EKS wykorzystuje do autentykacji, zarówno dla użytkowników jak i ról.

Spróbujmy na początek podejrzeć tę konfig mapę:

kubectl describe configmap -n kube-system aws-auth

Jeżeli nie dodawałeś jeszcze do swojego klastra żadnych node’ów ani użytkowników, to wynik będzie prawdopodobnie taki:  Error from server (NotFound): configmaps “aws-auth” not found.

Jeżeli tak jest, musisz ściągnąć taką konfigurację i lekko ją zmienić

1. Ściągamy plik:

curl -o aws-auth-cm.yaml https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-02-11/aws-auth-cm.yaml

2. W pliku:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: 
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

musimy wpisać ARN do roli, którą będą przyjmowały nody naszego klastra. Przypomnę tylko, że jest to rola z następującymi politykami:

• AmazonEKSWorkerNodePolicy,
• AmazonEKSCNIPolicy,
• AmazonEC2ContainerRegistryReadOnly.

3. Po zapisaniu zmian musimy oczywiście zaaplikować je na naszym klastrze:

kubectl apply -f aws-auth-cm.yaml

Teraz polecenie

kubectl describe configmap -n kube-system aws-auth

powinno zadziałać.

4. Aby dodać nowego użytkownika musimy tę mapę wyedytować. Otwieramy ją:

kubectl edit -n kube-system configmap/aws-auth

5. W sekcji data możemy dodać naszych użytkowników. Potrzebne będą trzy dodatkowe elementy konfiguracji:

• userarn: ARN użytkownika,
• username: nazwa użytkownika wewnątrz klastra Kuberenetes,
• groups: lista grup Kubernetes, do których użytkownik będzie przydzielony.

Wszystkie te dane umieszczamy w sekcji mapUsers. Ale uwaga – może jej jeszcze nie być.

U mnie po edycji ta część konfiguracji wygląda tak:

6. Zanim zapiszę zmiany, w drugim terminalu użyję poświadczeń AWS-owych nowego użytkownika eksadmin i spróbuję pobrać listę serwisów w klastrze.

Jak widać, nic z tego.

OK, wracamy do poprzedniego terminala, zapisujemy zmiany w naszej konfiguracji i jeszcze raz oddajemy głos naszemu nowemu administratorowi:

Jak widać, po dodaniu go do konfiguracji klastra EKS nie ma on już żadnych problemów z podłączeniem się do niego.

Amazon EKS – podsumowanie

Usługa Amazon EKS jest jeszcze dość słabo powiązana z innymi usługami w Amazon Web Services. Nie ma do niej na przykład żadnych metryk w CloudWatch. Za jej pomocą możemy jednak budować standardowe klastry Kubernetesowe i przenieść do AWS swoje rozwiązania.

Początki pracy z EKS mogą być trudne, próg wejścia jest na pewno wyższy niż w przypadku ECS. Dużym plusem jest jednak to, że za całego Mastera odpowiada AWS. Mamy trzy redundantne serwery i trzy etcd. Wszystko się poza tym odpowiednio skaluje.

Warto spróbować swoich sił z Amazon EKS. Mam nadzieję, że tym artykułem Wam to ułatwiłem.