Narzędzia, które ułatwią Ci development w Kubernetes

Skupimy się tutaj na narzędziach Kubernetesa, które ułatwią deployment, zabezpieczanie i monitorowanie klastrów. Poprzednim razem pisałem o technologiach i narzędziach, które warto obserwować w 2021, co spotkało się z przychylnością ze strony społeczności DevOps i SRE. Dzisiaj więc skupię się na najlepszych, moim zdaniem, narzędziach do testów i developmentu. 

Lens

Przez jakiś czas używałem tylko GKE - wydaje mi się, że rozpieściła mnie jego prostota i zarządzanie z poziomu konsoli GCP. Jeśli chodzi o lokalny development, to uruchamianie Kubernetes Dashboard zarządzanego przez społeczność zdawało się zadowalać większość moich potrzeb. 

Ale w momencie, w którym zacząłem zarządzać środowiskami multi- i hybrid-cloud, to potrzebowałem jednego narzędzia do interakcji z GKE, EKS i z lokalnymi klastrami Minikube. Lens to otwarte IDE Kubernetesa, które sprawa, że przechodzenie pomiędzy wieloma klastrami oraz interakcja z aplikacjami po deploymencie jest niezwykle prosta.

Aqua Security również posiada rozszerzenie dla Starboard, które integruje szukanie luk w zabezpieczeniach - ułatwia to zarządzanie przepływem pracy DevSecOps.  

Lens

Narzędzia od Fairwinds

Fairwinds i Aqua Security dostarczają kilka przydatnych narzędzi Kubernetesa do walidacji, skanowania i optymalizacji aplikacji:

• Polaris: jest to dashboard, kontroler dostępu lub wiersz poleceń do kontroli i walidacji najlepszych praktyk deploymentu (np. czy Twój deployment ma zdefiniowane health checks lub, czy żądania o zasoby i limity są skonfigurowane)
• Kube-hunter: szuka słabych stron w bezpieczeństwie uruchomionych klastrów
• Kube-bench: uruchamia CIS Kubernetes Benchmark i flaguje konfiguracje, które się nie powiodły
• Trivy: narzędzie poszukujące luk w zabezpieczeniach i przeznaczone dla kontenerów, które można zintegrować z potokiem CI
• Goldilocks: wysyła zapytania o wykorzystanie zasobów w każdej przestrzeni nazw przy użyciu Kubernetes vertical-pod autoscaler w trybie rekomendacji. Aby uzyskać więcej informacji, zobacz „Ultimate Kubernetes Resource Planning Guide”.

Fairwinds

Kyverno

Kyverno to projekt CNCF, którego celem jest uproszczenie zarządzania polityką Kubernetesa. Pomimo że Kubernetes ma PodSecurityPolicies i NetworkPolicies, które administratorzy i operatorzy mogą konfigurować, ciężko jest czasami poprawnie skonfigurować i przetestować politykę oraz zweryfikować zasoby.

Kyverno rozwiązuje powyższe problemy, tworząc ClusterPolicy CRD do walidacji i narzucenia pewnych zasad. Oto przykłady:

• Odrzucanie kontenerów głównych i uprzywilejowanych
• Odrzucanie hostNetwork, hostPort, hostPIID, i hostIPC
• Odrzucanie ostatniego obrazu
• Narzucanie etykiet w deploymencie

Narzędzia wiersza poleceń

Istnieje naprawdę sporo narzędzi wiersza poleceń dla Kubernetesa, ale poniższe wydają mi się najlepsze:

• kube-ps1: dodaje aktualny kontekst Kubernetesa i przestrzenie nazw do znaków zachęty bash/zsh w celu unikania interakcji z nieprawidłowym klastrem
• kubectx + kubens: kubectx pomaga w przechodzeniu między klastrami, podczas gdy kubens przydaje się przy przechodzeniu między przestrzeniami nazw
• krew: menedżer pakietów dla wtyczek kubectl (odpowiednik brew i apt)
• kubectl-neat: usuwa niepotrzebne informacje dodane przez Kubernetesa podczas uruchamiania kubectl get. Pomaga to w debugowaniu manifestów Kubernetesa bez zbędnych linii kodu (np. creationTimestamp, uid, dnsPolicy, czy terminationMessagePolicy)
• kube-no-trouble: wykrywa użycie przestarzałych API znajdujących się w klastrze. Mocno przydaje się do uruchamiania sanity checks przed aktualizacją klastra 
• helm-mapkubeapis: aktualizuje release'y Helm, które zawierają stare lub usunięte API Kubernetesa. Połącz to z kube-no-trouble, aby naprawiać zarówno Twoje aplikacje, jak i zewnętrzne pakiety chart Helma.
• kube-diffi helm-diff: umożliwia porównywanie zmian między kolejnymi wersjami manifestów Kubernetes po deploymencie lub między różnymi wydaniami Helm

Kube Forwarder

Może się zdarzyć i tak, że w klastrze znajdą się bazy danych po deploymencie, których nie dostarcza Kubernetes service (np. NodePort, Ingress). Kubectl pozwala na port-forwarding do mapowania tych serwisów w localhost dla interakcji lokalnej. Ma to sens przy jednej, czy dwóch aplikacjach, ale gdy jest ich więcej, to Kube Forwarder staje się o wiele lepszy, niż używanie wielu zakładek terminala. 

Obsługuje również auto-reconnect i multiklastry, co przydaje się przy przechodzeniu pomiędzy klastrami Dev i QA podczas testów.  

Kube Forwarder

Kubecost

Uruchomienie Kubernetesa w AWS/GCP/Azure może szybko stać się kosztowne, podobnie zresztą, jak w przypadku jakiegokolwiek rodzaju cloud computingu. 

Nawet po dostosowaniu klastra przy pomocy instancji spot/pre-emptible i korzystaniu z narzędzi do automatycznego skalowania w celu zredukowania ilości nieużywanych zasobów, łatwo jest pominąć zasoby bezczynne lub over-provisioned. 

Kubecost monitoruje wydatki Kubernetesa i zapewnia ciągły raport na temat przydziału kosztów. Przy dużych projektach już pewnie pracuje zespół monitorujący koszty, ale w przypadku pracy w pojedynkę Kubecost pozwoli Ci uniknąć korzystania z narzędzi rozliczeniowych w chmurze.

Kubecost

Kubespy

Kubespy to narzędzie od Pulumi, które służy do obserwowania, jak zmieniają się zasoby używane przez Kubernetesa. Używa ono do tego Kubernetes API. Kubespy zapewnia bardziej szczegółowe informacje od kubectl get -w. Co więcej, wszystkie zmiany pokazują się w wierszu poleceń. 

Okazało się, że narzędzie to przydaje się przy debugowaniu problemów z menedżerem certyfikatów i certyfikacją TLS. Jestem jednak pewny, że można go używać we wszystkich innych przypadkach debugowania w Kubernetesie.

Kubespy

Czy znacie jeszcze jakieś inne przydatne narzędzia? Dajcie znać w komentarzach.

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.