Artykuł ukazał się pierwotnie na blogu Chmurowiska.

Uruchomiłeś właśnie swój pierwszy klaster Kubernetes w usłudze Amazon EKS i pewnie zastanawiasz się co dalej. W konsoli samej usługi nie za bardzo można coś zrobić. Jest tam trochę informacji i praktycznie nic poza tym.

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

Instalujemy narzędzia

Na początek jedna uwaga. Wszystkie urle do instalowanych narzędzi są aktualne w momencie gdy piszę ten tekst. Jeżeli będziecie czytali ten artykuł za jakiś czas, sprawdźcie proszę czy nie ma dostępnych nowszych wersji

Narzędzie kubectl 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

Czynimy nasz plik wykonywalnym.

chmod +x ./kubectl

Kopiujmy go sobie w jakieś wygodniejsze miejsce i ułatwiemy sobie życie dodając go do przeszukiwanych miejsc.

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

Dodamy go sobie jeszcze do pliku .bashrc, dzięki temu, po ponownym uruchomieniu maszyny, będzie nadal dostępny.

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

Sprawdzamy czy wszystko działa.

kubectl version --client --short

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

Polecania wykonujemy po kolei, podobnie do instalacji 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

Sprawdzamy oczywiście, czy authenticator działa.

aws-iam-authenticator help

Konfigurujemy

W następnym kroku musimy stworzyć kubeconfig.

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

i ewentualnie wykonać update:

pip install awscli --upgrade --user

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

I dodajemy w końcu 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. 🙂

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 dodawaliście jeszcze do swojego klastra żadnych nodów ani użytkowników to wynik będzie prawdopodobnie taki: Error from server (NotFound): configmaps „aws-auth” not found.

Jeżeli tak jest, to musimy ściągnąć taką konfigurację i lekko ją wyedytować. Ś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

W pliku

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      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.

Po zapisaniu zmian, musimy oczywiście zaaplikować zmiany na naszym klastrze:

kubectl apply -f aws-auth-cm.yaml

Teraz polecenie

kubectl describe configmap -n kube-system aws-auth

powinno zadziałać.

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

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

W sekcji data możemy dodać naszych użytkowników. Potrzebne będą trzy dodatkowe rzeczy w 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. Może jej jeszcze nie być.

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

Zanim zapiszę zmiany, w drugim terminalu użyję poświadczeń awsowych 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.

Podsumowanie

Amazon EKS jest jeszcze dość słabo powiązany z innymi usługami w Amazon Web Services. Nie ma do niej na przykład żadnych metryk w CloudWatch.

Za pomocą EKS 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 3 redundantne serwery i 3 etcd. Wszystko się poza tym odpowiednio skaluje.

Warto spróbować i mam nadzieję, że tym artykułem Wam to ułatwiłem.