🥇Przedstawiamy Kubernetes CCM (menedżer kontrolera chmury) dla Yandex.Cloud

Kontynuacja niedawnego Wydanie sterownika CSI dla Yandex.Cloud publikujemy kolejny projekt Open Source dla tej chmury - Menedżer kontrolera chmury. CCM jest wymagany nie tylko dla klastra jako całości, ale także dla samego sterownika CSI. Szczegóły dotyczące jego celu i niektórych funkcji implementacyjnych są okrojone.

Wprowadzenie

Dlaczego to?

Motywy, które skłoniły nas do opracowania CCM dla Yandex.Cloud, całkowicie pokrywają się z tymi opisanymi już w zapowiedź Kierowcy CSI. Utrzymujemy wiele klastrów Kubernetes od różnych dostawców usług chmurowych, dla których wykorzystujemy jedno narzędzie. Wdraża liczne udogodnienia „omijające” zarządzane rozwiązania tych dostawców. Tak, mamy dość specyficzny przypadek i potrzeby, ale powstałe dzięki nim zmiany mogą przydać się innym użytkownikom.

Czym właściwie jest CCM?

Zwykle przygotowujemy otoczenie wokół nas na klaster z zewnątrz - na przykład za pomocą Terraform. Czasami jednak zachodzi potrzeba zarządzania otaczającym nas środowiskiem chmurowym z klastra. Taka możliwość jest zapewniona i właśnie ona jest realizowana CCM.

W szczególności Cloud Controller Manager zapewnia pięć głównych typów interakcji:

Instancje – implementuje relację 1:1 pomiędzy obiektem węzła w Kubernetesie (Node) i maszynę wirtualną u dostawcy chmury. W tym celu:
- wypełnij pole spec.providerID w obiekcie Node. Na przykład dla OpenStack CCM to pole ma następujący format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Możesz zobaczyć nazwę dostawcy chmury i unikalny UUID serwera (maszyny wirtualnej w OpenStack) obiektu;
- komplement nodeInfo w obiekcie Node informacje o maszynie wirtualnej. Na przykład podajemy typ instancji w AWS;
- Sprawdzamy obecność maszyny wirtualnej w chmurze. Na przykład, jeśli obiekt Node wszedł w stan NotReady, możesz sprawdzić, czy maszyna wirtualna w ogóle istnieje u dostawcy chmury za pomocą providerID. Jeśli go tam nie ma, usuń obiekt Node, które w przeciwnym razie pozostałyby w klastrze na zawsze;
strefy – ustawia domenę awarii dla obiektu Node, aby osoba planująca mogła wybrać węzeł dla Poda zgodnie z regionami i strefami u dostawcy chmury;
Load Balancer – podczas tworzenia obiektu Service z typem LoadBalancer tworzy swego rodzaju balanser, który będzie kierował ruch z zewnątrz do węzłów klastra. Na przykład w Yandex.Cloud możesz użyć NetworkLoadBalancer и TargetGroup do tych celów;
Trasa – buduje sieć pomiędzy węzłami, ponieważ Zgodnie z wymaganiami Kubernetes każdy pod musi mieć swój własny adres IP i mieć możliwość połączenia się z dowolnym innym podem. W tym celu można skorzystać z sieci nakładkowej (VXLAN, GENEVE) lub ustawić tablicę routingu bezpośrednio w sieci wirtualnej dostawcy chmury:
objętość – Umożliwia dynamiczne zamawianie PV przy użyciu PVC i SC. Początkowo funkcjonalność ta była częścią CCM, jednak ze względu na jej dużą złożoność została przeniesiona do osobnego projektu Container Storage Interface (CSI). O CSI rozmawialiśmy nie raz napisał i, jak już wspomniano, nawet wydany Kierowca CSI.

Wcześniej cały kod wchodzący w interakcję z chmurą znajdował się w głównym repozytorium Git projektu Kubernetes pod adresem k8s.io/kubernetes/pkg/cloudprovider/providers, ale postanowili porzucić to ze względu na niedogodności związane z pracą z dużą bazą kodu. Wszystkie stare implementacje zostały przeniesione do osobne repozytorium. Dla wygody dalszego wsparcia i rozwoju, wszystkie wspólne komponenty również zostały przeniesione osobne repozytorium.

Podobnie jak w przypadku CSI, wielu dużych dostawców usług w chmurze zaprojektowało już swoje CCM w celu wykorzystania chmur w Kubernetes. Jeśli dostawca nie posiada CCM, ale wszystkie niezbędne funkcje są dostępne poprzez API, to możesz samodzielnie wdrożyć CCM.

Aby napisać własną implementację CCM wystarczy wdrożyć wymagane interfejsy Go.

И to jest to, co otrzymaliśmy.

realizacja

Jak do tego doszedłeś

Zaczęliśmy programować (a raczej nawet używać) od gotowy(!) CCM dla Yandex.Cloud rok temu.

Jednak w tej realizacji zabrakło nam:

uwierzytelnianie poprzez token JWT IAM;
Wsparcie kontrolera usług.

W porozumieniu z autorem (dlisin) w Telegramie rozwidliśmy yandex-cloud-controller-manager i dodaliśmy brakujące funkcje.

Najważniejsze cechy

Obecnie CCM obsługuje następujące interfejsy:

Instancje;
strefy;
Load Balancer.

W przyszłości, gdy Yandex.Cloud zacznie pracować z zaawansowanymi możliwościami VPC, dodamy interfejs trasy.

LoadBalanacer jako główne wyzwanie

Początkowo próbowaliśmy, podobnie jak inne wdrożenia CCM, stworzyć parę LoadBalancer и TargetGroup dla wszystkich Service z typem LoadBalancer. Jednak Yandex.Cloud odkrył jedno interesujące ograniczenie: nie można z niego korzystać TargetGroups z przecięciem Targets (para SubnetID - IpAddress).

Dlatego wewnątrz utworzonego CCM uruchamiany jest kontroler, który w przypadku zmiany obiektów Node zbiera informacje o wszystkich interfejsach na każdej maszynie wirtualnej, grupuje je według przynależności do określonych NetworkID, tworzy przez TargetGroup na NetworkID, a także monitoruje trafność. Następnie podczas tworzenia obiektu Service z typem LoadBalanacer po prostu załączamy wstępnie utworzony TargetGroup do nowych NetworkLoadBalanacer'jestem.

Jak zacząć z niego korzystać?

CCM obsługuje Kubernetes w wersji 1.15 i nowszej. W klastrze, aby działało, wymagana jest flaga --cloud-provider=external było ustawione true dla kube-apiserver, kube-controller-manager, kube-scheduler i wszystkich kubeletów.

Wszystkie niezbędne kroki dotyczące samej instalacji opisano w README. Instalacja sprowadza się do tworzenia obiektów w Kubernetesie z manifestów.

Do korzystania z CCM potrzebne będą również:

wskazać w manifeście identyfikator katalogu (folder-id) Yandex.Cloud;
konto usługi do interakcji z API Yandex.Cloud. W manifeście Secret musi przenieść autoryzowane klucze z konta usługi. W dokumentacji opisane, jak założyć konto w serwisie i zdobyć klucze.

Będziemy szczęśliwi, jeśli otrzymamy Twoją opinię i nowe problemyjeśli napotkasz jakiekolwiek problemy!

Wyniki

Przez ostatnie dwa tygodnie korzystaliśmy z wdrożonego CCM w pięciu klastrach Kubernetes, a w nadchodzącym miesiącu planujemy zwiększyć ich liczbę do 20. Obecnie nie zalecamy używania CCM w przypadku dużych i krytycznych instalacji K8.

Podobnie jak w przypadku CSI, będzie nam miło, jeśli programiści Yandex zajmą się rozwojem i wsparciem tego projektu - jesteśmy gotowi przenieść repozytorium na ich prośbę, aby zająć się ważniejszymi dla nas zadaniami.

PS

Przeczytaj także na naszym blogu:

Źródło: www.habr.com

Przedstawiamy Kubernetes CCM (Cloud Controller Manager) dla Yandex.Cloud