Jak połą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. 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”.
|
1 2 |
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.
|
1 2 |
chmod +x ./kubectl |
Kopiujmy go sobie w jakieś wygodniejsze miejsce i ułatwiemy sobie życie dodając go do przeszukiwanych miejsc.
|
1 2 |
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.
|
1 2 |
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc |
Sprawdzamy czy wszystko działa.
|
1 2 |
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.
|
1 2 |
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 |
|
1 2 3 4 5 |
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.
|
1 2 |
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
|
1 2 |
aws --version |
i ewentualnie wykonać update:
|
1 2 |
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.
|
1 2 |
aws configure |
I dodajemy w końcu nowy kontekst za pomocą polecenia:
|
1 2 |
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ć:
|
1 2 |
cat ~/.kube/config |
Możemy już spróbować jakiejś interakcji z naszym klasterm EKS. Spróbujemy pobrać listę serwisów:
|
1 2 |
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ę:
|
1 2 |
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
|
1 2 |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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:
|
1 2 |
kubectl apply -f aws-auth-cm.yaml |
Teraz polecenie
|
1 2 |
kubectl describe configmap -n kube-system aws-auth |
powinno zadziałać.
Aby dodać nowego użytkownika musimy tą mapę wyedytować. Otwieramy ją:
|
1 2 |
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.