Artykuł przedstawia sposób wdrożenia panelu “Kubernetes Dashboard” na różnych wersjach klastra kubernetesowego. Dowiesz się, czym w ogóle jest Dashboard, do czego jest wykorzystywany i jak może pomóc w usprawnieniu pracy z klastrem k8s.
Poruszane zagadnienia:
- Czym jest Dashboard?
- Dlaczego może Ci się przydać?
- Jak przeprowadzić wdrożenie na klastrach w wersji 1.25 oraz 1.27+?
- Dwa sposoby na wdrożenie najnowszej wersji Dashborda dla klastrów 1.27+
Słów kilka o Kubernetes Dashboard
Kubernetes Dashboard jest interfejsem użytkownika opartym o przeglądarkę internetową. Można go użyć do wdrożeń skonteneryzowanych aplikacji na dany klaster, zarządzać jego poszczególnymi elementami, czy też debugować wdrożoną aplikację. Poza tym zapewnia podgląd w formie wykresów i grafik np. na obciążenie poszczególnych node’ów:
Umożliwia tworzenie i modyfikację struktury poszczególnych obiektów kubernetesowych, jak np. skalowanie czy edycja Deploymentów. Generalnie jest to bardzo przydatne narzędzie do zarządzania klastrem. Szczególnie jeśli ktoś woli interfejs graficzny od typowo czarnego okienka konsoli. 🙂
Poniżej przykładowy screen z głównego widoku interfejsu — jak widać na tym przykładzie, nie wszystko w obrębie klastra działa jak należy:
Tutaj z kolei inny przykład. Łatwość uzyskania konkretnego Secretu z poziomu Dashboarda w porównaniu do złożoności polecenia z poziomu konsoli, by dostać tę samą informację:
Przygotowanie takiego polecenia może być problematyczne, szczególnie dla początkujących.
Wdrożenie
Przede wszystkim należy się upewnić, czy instalujemy panel na właściwym klastrze k8s. Do tego celu wykorzystujemy polecenie kubectl config current-context
. Odpowiada ono za wyświetlenie aktualnie aktywnego kontekstu w konfiguracji narzędzia kubectl. Kontekst jest bardzo istotnym pojęciem, ponieważ pozwala określić, z którym klastrem działamy. Dzięki temu wiemy, na jakim klastrze będzie przeprowadzone wdrożenie. W razie potrzeby można użyć polecenia kubectl config get-contexts
w celu wyświetlenia listy klastrów, do których mamy dostęp. Jeśli chcielibyśmy przełączyć się na inny klaster, to z wyniku działania poprzedniego polecenia z kolumny NAME, bierzemy nazwę i dodajemy ją do polecenia kubectl config use-context NAZWA_KONTEKSTU_Z_NAME
.
Poniżej sposób wdrożenia dla klastrów w wersji 1.25.
1. Przede wszystkim należy zwrócić uwagę, że klaster w wersji 1.25 obsługuje Dashboard w maksymalnie wersji 2.7.0.
2. Uruchamiamy polecenie kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
. Polecenie to służy do stosowania zmian w zasobach klastra na podstawie definicji zapisanej w pliku YAML. W tym wypadku jest to plik recommended.yaml zawierający zbiór obiektów k8s niezbędnych do uruchomienia Dashboarda. To polecenie stosujemy w podejściu deklaratywnym zalecanym ze względu na większą kontrolę i przejrzystość.
3. W wyniku działania powyższego polecenia zostały utworzone obiekty:
namespace/kubernetes-dashboard created serviceaccount/kubernetes-dashboard created service/kubernetes-dashboard created secret/kubernetes-dashboard-certs created secret/kubernetes-dashboard-csrf created secret/kubernetes-dashboard-key-holder created configmap/kubernetes-dashboard-settings created role.rbac.authorization.k8s.io/kubernetes-dashboard created clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created deployment.apps/kubernetes-dashboard created service/dashboard-metrics-scraper created deployment.apps/dashboard-metrics-scraper created
4. Otwieramy dodatkową konsolę, w której wpisujemy polecenie kubectl proxy
. Uruchamia ono serwer proxy między komputerem użytkownika a serwerem API Kubernetesa. Użyteczne, gdy chcemy wchodzić w interakcję z klastrami na lokalnej maszynie. Domyślnie uruchamia proxy na porcie 8001, czyli adres wygląda następująco: http://localhost:8001.
5. Natomiast w przeglądarce wklejamy specjalnie przygotowany link → http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/, którego składowe wyjaśniam poniżej:
– http://localhost:8001 – wskazuje pod jakim adresem jesteśmy się w stanie dostać do proxy
– /api/v1 – wskazuje na endpointa API K8s oraz wersję API
– /namespaces/kubernetes-dashboard – informuje o odwoływaniu się do zasobów w określonej przestrzeni nazw, tutaj jest to “kubernetes-dashboard”
– /services/https:kubernetes-dashboard: – wskazuje serwis o nazwie kubernetes-dashboard, do którego nastąpi połączenie z wykorzystaniem protokołu https
– /proxy/ – informuje, że dostęp do danego serwisu jest przez proxy do Kubernetes API
6. Otwiera się okno logowania z dwiema opcjami logowania z poniższego zrzutu ekranu:
W opisywanym przypadku wybrana została opcja logowania tokenem. Z racji faktu, że klaster został uruchomiony w DigitalOcean, odpowiedni token API należy wygenerować na koncie klienta DigitalOcean w menu API → Tokens → Generate New Token. Token musi mieć uprawnienia do odczytu i zapisu, ponieważ za jego pomocą z poziomu Dashboarda chcemy mieć możliwość modyfikowania klastra.
Dla lokalnych klastrów działających w oparciu o np. Docker Desktop procedura uzyskania tokena jest następująca i działa dla obu wersji Dashboarda. Można utworzyć pliki yaml lub wykonać polecenia bezpośrednio z konsoli jak pokazano niżej:
1. Tworzymy Service Account o nazwie “admin-user” w namespace “kubernetes-dashboard”:
kubectl apply -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kubernetes-dashboard EOF
2. Tworzymy obiekt ClusterRoleBinding, mający na celu przypisanie do wcześniej utworzonego konta serwisowego uprawnień roli “cluster-admin”, dającej pełen dostęp administracyjny:
kubectl apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kubernetes-dashboard EOF
3. Tworzymy obiekt typu Secret, w którym będzie przechowywane powiązanie stworzonego konta użytkownika “admin-user” (sekcja “annotations”) z tokenem (sekcja “type”):
kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: admin-user namespace: kubernetes-dashboard annotations: kubernetes.io/service-account.name: "admin-user" type: kubernetes.io/service-account-token EOF
4. Uzyskujemy token poleceniem:
kubectl get secret admin-user -n kubernetes-dashboard -o jsonpath={".data.token"} | base64 -d
Wdrożenie dla klastrów w wersji 1.27+ i Dashboarda 3.0.0.
Przede wszystkim należy zwrócić uwagę na fakt, że — jak informuje dokumentacja, zmieniła się architektura bazowa i należy wykonać czystą instalację, odinstalowując najpierw dotychczas posiadaną wersję. Co więcej, Dashboard w tej wersji używa cert-managera oraz nginx-ingress-controllera. Jeśli chcemy instalować przy pomocy Helma, to nie musimy się niczym martwić, ponieważ odpowiednie zależności zostaną automatycznie zainstalowane. Natomiast w przypadku instalacji w klasyczny sposób przy pomocy kubectl apply, należy upewnić się, czy wspomniane wyżej pakiety są zainstalowane.
W opisywanym przypadku klaster miał już zainstalowane cert-manager i nginx-ingress, więc jedyne co pozostało, to — w przypadku instalacji opartej o Helm, wykonać następujące czynności:
1. Dodajemy repozytorium kubernetes-dashboard:
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
2. Instalujemy:
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard
3. Uruchamiamy wspomniany wcześniej panel logowania:
kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard 8443:443
4. Panel logowania do Dashboarda będzie dostępny pod adresem https://localhost:8443. W przeglądarce pojawi się ostrzeżenie o niezabezpieczonym połączeniu tak jak na screenie poniżej. W tym przypadku jest certyfikat typu “self-signed”, a takie są traktowane domyślnie przez przeglądarki jako niezaufane o czym dobitnie informują użytkownika.
Instalacja oparta o plik yaml wymaga wykonania nieco większej liczby poleceń:
1. Uruchamiamy polecenie:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v3.0.0-alpha0/charts/kubernetes-dashboard.yaml
2. Musimy uzyskać niezbędne informacje do uruchomienia polecenia kubectl -n <nginx-namespace> port-forward svc/<nginx-service-name> 8443:443
. W tym celu należy wykonać kubectl get namespaces
, z którego uzyskamy informację o nazwie namespace’a dla nginx-ingress. W tym wypadku “ingress-nginx”. Wykorzystujemy to w poleceniu kubectl get svc -n ingress-nginx
, z którego z kolei uzyskujemy nazwę “ingress-nginx-controller”. Finalne polecenie wygląda następująco
kubectl -n ingress-nginx port-forward svc/ingress-nginx-controller 8443:443
3. Panel logowania do Dashboarda będzie dostępny pod adresem https://localhost:8443. Reszta informacji analogicznie do opisu z pkt. 4 wyżej.
Podsumowanie
Kompleksowe zarządzanie klastrem można sobie ułatwić korzystając z narzędzia Dashboard. Z artykułu dowiedzieliśmy się, w jaki sposób go wdrożyć w zależności od wersji zarządzanego przez nas klastra (co z kolei determinuje wykorzystanie odpowiedniej wersji interfejsu). W tekście omówiony został krok po kroku każdy ze sposobów wdrożenia. Wybór zależy w zasadzie od preferencji. Natomiast podstawowa znajomość Kubernetesa, jego struktury i poleceń jest niezbędna do tego, by wdrożenie zakończyło się sukcesem.
Autor
Piotr Bracha — pracuje jako administrator systemów. Karierę zaczynał jako młodszy administrator systemów w call center, gdzie miał m.in. możliwość poznania administrowania systemem CentOS i centralą telefoniczną Asterisk. Obecnie rozwija się w technologiach kontenerowych i chmurowych. Fan automatyzacji i porządku – w kodzie, ale też w środowisku pracy. Poza pracą uwielbia motoryzację i strzelectwo. Więcej artykułów autorstwa Piotra znajdziesz w serwisie medium.com.