Płaszczyzna kontrolna dla rozproszonych PaaS Kubernetes

(Ankur Singla) (15 listopada , 2019)

Autorzy : Ankur Singla , Harshad Nakil

Ten blog jest pierwszym z serii blogów, które obejmują różne aspekty tego, czego potrzebowaliśmy, aby zbudować i obsługiwać nasz Usługa SaaS :

  1. Płaszczyzna sterowania dla rozproszonych PaaS Kubernetes
  2. (Globalna siatka usług dla aplikacji rozproszonych)
  3. (Bezpieczeństwo platformy rozproszonej infrastruktury, aplikacji i danych)
  4. (Bezpieczeństwo aplikacji i sieci w klastrach rozproszonych)
  5. Obserwowalność na platformie rozproszonej globalnie
  6. Operacje i SRE globalnie rozproszonej platformy
  7. Struktura usług Golang dla rozproszonych mikrousług s

Jak opisaliśmy na naszym wcześniejszym blogu , nasi klienci tworzą złożone i zróżnicowane zestawy rozwiązań biznesowych – takich jak inteligentne produkcja, kryminalistyka wideo dla bezpieczeństwa publicznego, handel algorytmiczny, sieci telekomunikacyjne 5G – dlatego musimy zapewnić stałą, połączoną i niezawodną obsługę tych aplikacji i ich użytkowników końcowych.

Ponieważ te aplikacje może działać w wielu klastrach u dostawców chmur lub w lokalizacjach brzegowych klientów, nasz zespół platformy musiał zbudować rozproszoną płaszczyznę kontroli i usługę PaaS, aby wdrożyć, zabezpieczyć i obsługiwać wiele klastrów Kubernetes z wieloma dzierżawcami. Ta rozproszona płaszczyzna sterowania zapewnia wiele korzyści operacyjnych, związanych ze skalowaniem i wydajnością, które omówimy w naszej ( link wideo ) – np jak zarządzać tysiącami skrajnych klastrów K8 za pomocą GitOps – a także jako osobny post na blogu w nadchodzących tygodniach.

TL; DR (Podsumowanie)

  1. Nie mogliśmy znaleźć proste w użyciu rozwiązanie na rynku, które mogłoby rozwiązać problem wdrażania, zabezpieczania i obsługi wielu klastrów aplikacji, które są rozproszone między dostawcami chmury, chmurami prywatnymi lub wieloma lokalizacjami brzegowymi.
  2. Nie mogliśmy znaleźć solidnego Dystrybucja Kubernetes lub PaaS (np. OpenShift, Cloud Foundry itp.), Które zapewniały kompleksowy zestaw usług bezpieczeństwa i operacyjnych potrzebnych dla rozproszonych klastrów – na przykład tożsamość oparta na PKI, RBAC i zarządzanie dostępem użytkowników, tajemnice i zarządzanie kluczami przez dostawców chmury , multi-klastrowa siatka usług, obserwowalność i dzienniki audytu lub bezpieczeństwo aplikacji i sieci.
  3. Anthos (Google), Azure Arc (Microsoft) i Rancher to stacje zarządzania z wieloma klastrami i pakiety wielu różnych usług ; z naszej analizy wynika, że ​​nie rozwiązałyby one wymagań operacyjnych, skalowania, bezpieczeństwa i obsługi wielu dzierżawców, które mieliśmy dla usług aplikacji i infrastruktury w wielu klastrach.
  4. Musieliśmy zbudować własną rozproszoną płaszczyznę sterowania dla nasz zarządzany PaaS, który jest zbudowany na bazie Kubernetes. Zaczęliśmy od vanilla Kubernetes, a następnie wprowadziliśmy znaczące zmiany, aby zapewnić usługi platformowe potrzebne naszym zespołom DevOps i SRE. Ponadto musieliśmy zbudować płaszczyznę kontroli, aby zarządzać dużą liczbą rozproszonych klastrów i zapewniać obsługę wielu dzierżawców w heterogenicznej infrastrukturze (na brzegu, w naszej sieci i wielu dostawcach chmury).

Kubernetes do zarządzania aplikacjami: Dlaczego & Jak

Wybraliśmy Kubernetes (K8s) jako rdzeń naszej platformy do zarządzania aplikacjami rozproszonymi, ponieważ zapewnia bogaty zestaw funkcji bez zbytniego nakazu – dając nam elastyczność w wprowadzaniu innowacji w sprawach, które naszym zdaniem mają znaczenie dla naszych klientów. Wykorzystaliśmy to jako podstawę, na której zaczęliśmy budować naszą usługę, a wraz z rosnącą popularnością K8, łatwiej jest też znaleźć programistów i operatorów, którzy są z nią zaznajomieni.

To powiedziawszy, wdrażanie i zarządzanie dużą liczbą klastrów Kubernetes klasy produkcyjnej w środowisku hybrydowym (wiele chmur, sieciowych punktów POP i lokalizacji brzegowych) nie jest łatwe, ponieważ nie ma żadnych -box rozwiązania dla Kubernetes, które mogą:

  1. Harmonizować heterogeniczne zasoby infrastruktury z automatycznym klastrowaniem, skalowaniem i obsługą bezdotykową; było to szczególnie bolesne na brzegu sieci iw naszych punktach PoP sieci
  2. Zapewnij wysoką wydajność i niezawodną łączność w różnych lokalizacjach – szczególnie podczas przekraczania dostawców chmury i pochodzących z lokalizacji brzegowych
  3. Rozwiąż problemy z bezpieczeństwem problem przesyłania danych, danych w spoczynku, tajemnic, kluczy i sieci… wszystko to jest wspierane przez jednolitą tożsamość PKI, która działa na obrzeżach, sieci i chmurze
  4. Zapewnij prawdziwą obsługę wielu podmiotów – izolacja najemców i gwarancje bezpieczeństwa – z możliwością uruchamiania obciążeń produkcyjnych i programistycznych dla potrzeb wewnętrznych i klientów w tych samych klastrach
  5. Zapewnij obserwowalność i operacje w rozproszonych klastrach, które są powiązane ze scentralizowaną polityką i intencją, bez potrzeby tworzenia złożonych zbieranie dzienników i metryk

Po kilku sprawdzeniach koncepcji z wieloma dostawcami chmury i platformami open source, takimi jak GKE, AKS, EKS i RKE, a także OpenShift i Cloud Foundry – zdaliśmy sobie sprawę że żaden z nich nie był w stanie sprostać wszystkim fi ve wymagania powyżej. W rezultacie zdecydowaliśmy się zbudować własny PaaS – zaczynając od „waniliowego” Kubernetes i wprowadziliśmy kilka dodatków – pod kątem tożsamości, sieci, bezpieczeństwa, wielu dzierżawców, logowania, metryk itp. Podczas gdy używamy Kubernetes do zaspokojenia naszych wewnętrznych potrzeb, musieliśmy podjąć trudne decyzje, na przykład nie ujawniać tych klastrów Kubernetes bezpośrednio naszym wewnętrznym użytkownikom i / lub klientom w celu wykonywania ich zadań (więcej o tym później, ponieważ kluczowym celem była dla nas obsługa wielu dzierżawców).

Oprócz wielu nowych funkcji, które musieliśmy dodać, istniała również potrzeba uruchamiania naszych obciążeń / usług równolegle z obciążeniami klientów w wielu lokalizacjach na obrzeżach sieci, w naszej sieci oraz w chmurach publicznych / prywatnych. Oznaczało to, że musieliśmy stworzyć dodatkowe możliwości zarządzania wieloma klastrami w wielu środowiskach… wszystkie połączone za pomocą naszej sieci globalnej i naszych rozproszonych bram aplikacji, aby zapewnić zerowe zaufanie i łączność na poziomie aplikacji w tych klastrach.

Część trudna: Multi-Tenancy and Multi-Cluster for Kubernetes

Tworzenie i obsługa aplikacji działających w pojedynczym klastrze Kubernetes jest nietrywialnym zadaniem, nawet jeśli korzystasz z klastra zarządzanego przez dostawcę chmury. Dlatego zespoły DevOps i SRE często minimalizują swoje koszty ogólne i nie zajmują się złożonością wielu klastrów. Dość często zdarza się, że zespoły tworzą jeden duży klaster Kubernetes i umieszczają wszystkie typy zasobów w tym samym klastrze. Chociaż wydaje się to świetne, ponieważ mogą uprościć operacje i uruchomić klaster w celu uzyskania maksymalnej wydajności obliczeniowej i kosztów, nie jest to najlepszy pomysł z kilku powodów. Po pierwsze, potrzeby dotyczące obciążeń produkcyjnych są bardzo różne od obciążeń deweloperskich i tymczasowych – niestabilne obciążenia programistyczne mogą potencjalnie powodować problemy w przypadku bardziej stabilnych obciążeń produkcyjnych.

Oprócz potrzeb zróżnicowanych obciążeń, zabezpieczenia K8 i ograniczenia izolacji to kolejny czynnik wpływający na wiele klastrów. Typowym podejściem do rozwiązania kwestii bezpieczeństwa i izolacji zasobów K8 jest utworzenie niezależnych klastrów dla każdego dzierżawcy przy użyciu modelu wielu dzierżawców. Chociaż może to być wykonalne w chmurze, na brzegu nie jest możliwe uruchomienie wielu klastrów. Witryny brzegowe mają ograniczenia zasobów obliczeniowych i pamięci masowej oraz ograniczoną przepustowość sieci, aby wysyłać dzienniki i metryki dla każdego dodatkowego klastra do chmury centralnej.

Aby poradzić sobie z problemem wielu klastrów Kubernetes, oceniliśmy Rancher pod kątem scentralizowanego zarządzania nasze klastry Kubernetes (kiedy zaczynaliśmy, Anthos i Azure Arc nie istniały) i KubeFed. Dwa dostępne wówczas podejścia to (i nadal taka sama sytuacja dzisiaj):

  1. Zarządzanie wieloma klastrami (np. Rancher) z centralnej konsoli dałoby nam możliwość wdrażania wielu klastrów w dowolnej lokalizacji i wykonywać operacje zarządzania cyklem życia, takie jak aktualizacje, wycofywanie itp. Niektóre z tych systemów dawały również możliwość adresowania pojedynczego klastra z automatyzacją konfiguracji i wdrażania aplikacji.
  2. Innym podejściem jest wdrożenie Kubernetes płaszczyzna kontroli federacji klastrów (KubeFed) i może sprawić, że wiele klastrów fizycznych będzie wyglądać jak jeden klaster. Ten projekt dopiero się zaczynał w czasie, gdy patrzyliśmy, a nawet dzisiaj jest dopiero w fazie alfa.

Po niedawnym ogłoszeniu GCP Anthos i Azure Arc ponownie oceniliśmy naszą pierwotną decyzję o zbudować rozproszoną płaszczyznę sterowania i wyciągnięto wniosek, że nawet te dwie nowe oferty nie byłyby w stanie rozwiązać dwóch krytycznych problemów z rozproszonymi klastrami.Te dwie kluczowe funkcje, których potrzebowaliśmy dla naszej platformy, to:

  1. Zarządzanie wieloma klastrami jako flotą w celu rozwiązania problemu wykonywania operacji na wszystkich lub logicznej grupie klastrów – operacje takie jak konfiguracja, wdrażanie, metryki itp. Ma to kluczowe znaczenie, ponieważ chcemy zmniejszyć obciążenie operacyjne naszych zespołów SRE, poprawić możliwości debugowania dla naszych DevOps i poprawić skalowalność naszego systemu.
  2. Możliwość wydzielenia indywidualnego fizycznego Klaster Kubernetes do obsługi wielu dzierżawców bez konieczności uruchamiania klastrów fizycznych – jest to szczególnie krytyczne w środowiskach o ograniczonych zasobach, w których nie chcemy dodawać nowych klastrów fizycznych tylko do obsługi wielu podmiotów.

Aby rozwiązać te dwa problemy, musieliśmy wymyślić nową technikę – rozproszoną płaszczyznę sterowania – aby rozwiązać narzut operacyjny „Wiele” klastrów i zapewnia odpowiednik „wielu klastrów” dla wielu dzierżawców w ograniczonych zasobach d.

Distributed Control Plane: Jak osiągnęliśmy Multi-Cluster Kubernetes

Nasz zespół platformy zdecydował się zbudować rozproszoną płaszczyznę sterowania dla Kubernetes, która udostępnia interfejsy API Kubernetes do użytku naszego zespołu, jednak , te interfejsy API pochodzą z „wirtualnych” klastrów, które istnieją tylko w naszej płaszczyźnie sterowania – wirtualny serwer API K8s (vK8s) dla wirtualnego klastra K8s (jak pokazano na Rysunek 1 ). Ta płaszczyzna kontroli mapuje intencje użytkownika do wielu fizycznych klastrów Kubernetes działających na naszym brzegu, naszych sieciowych punktów POP i lokalizacji w chmurze publicznej. Te fizyczne klastry są dostępne tylko dla naszej rozproszonej płaszczyzny sterowania, a nie dla żadnego indywidualnego dzierżawcy / użytkownika.

Rysunek 1: Rozproszona płaszczyzna sterowania

Ta płaszczyzna kontroli zapewnia każdemu dzierżawcy jeden lub więcej „wirtualnych” klastrów aplikacji, w których mogą wdrażać swoje aplikacje ) iw oparciu o konfigurację płaszczyzna sterowania będzie replikować ją i zarządzać nią w wielu fizycznych klastrach Kubernetes. Oprócz operacji konfiguracyjnych i wdrożeniowych, operacje monitorowania podążają również za tym „wirtualnym” klastrem bez konieczności tworzenia narzędzi do zbierania i analizowania danych z wielu fizycznych klastrów.

Weźmy przykładową aplikację interfejsu użytkownika o nazwie Productpage, gdzie intencją użytkownika jest uruchomienie go w 3 lokalizacjach – pa2-par, ny8-nyc i ams9-ams z 2 replikami w każdej z nich. Gdy użytkownik tworzy obiekt vK8s i dołącza go do wirtualnego klastra, który natychmiast udostępnia serwer API vK8s, który może być używany ze standardowym kubectl.

W następnym kroku użytkownik pobiera kubeconfig dla tego wirtualnego klaster i tworzy standardowe yaml opisujące wdrożenie K8s dla strony produktu.

Po utworzeniu specyfikacji wdrożenia , użytkownik może przystąpić do tworzenia wdrożenia w tym wirtualnym klastrze:

Teraz, jeśli użytkownik sprawdzi jego wdrożenie widzi, że rozpoczęto 6 replik z 2 w każdej lokalizacji (pa2-par, ny8-nyc i ams9-ams).

Poniższe dane wyjściowe pokazują 2 pody działające w każdej lokalizacji z mapowaniem na określony węzeł fizyczny

Ten prosty przykład pokazuje, jak trywialne jest uzyskanie replikacji dowolnej aplikacji w wielu klastrach w ciągu minuty bez obciążeń związanych z instalacją i zarządzaniem. Oprócz odwzorowania intencji rozproszona płaszczyzna sterowania zapewnia również obserwowalność dla wirtualnego klastra, a nie dla poszczególnych klastrów.

Sterowanie rozproszone i scentralizowane zarządzanie dla wielu dzierżawców

Jak widać na Rysunku 2 , nasza scentralizowana płaszczyzna zarządzania działa w ramach dwóch dostawców chmur publicznych (po jednym regionie) – po jednym w AWS i jeden na platformie Azure (dla nadmiarowości). Ta płaszczyzna zarządzania umożliwia naszym SRE tworzenie najemców z twardą obsługą wielu podmiotów – np. zespół programistów pracujący nad naszą usługą VoltMesh może być najemcą, a zespół ds. rozwiązań dla klientów pracujący nad numerami POC klientów może być własnym dzierżawcą z własnym zestawem użytkowników.

Rysunek 2: Multi-Tenancy and Multi-Cluster

Każdy z tych najemców może utworzyć wiele przestrzenie nazw i przypisz grupę użytkowników do współpracy nad tymi przestrzeniami nazw. Te przestrzenie nazw nie są przestrzeniami nazw Kubernetes – stanowią granicę izolacji na naszej platformie z regułami RBAC i zasadami uprawnień dla użytkowników.

Gdy użytkownik w przestrzeni nazw chce utworzyć klaster aplikacji, tworzy obiekt vK8 i to z kolei tworzy serwer API vK8s w naszej płaszczyźnie zarządzania.Korzystając z tego obiektu vK8s, użytkownik może tworzyć wdrożenia, zestawy stanowe, obwody PVC itp., A płaszczyzna kontroli zapewni, że te operacje będą wykonywane w jednym lub wielu klastrach fizycznych, w oparciu o lokacje, które są powiązane z obiektem vK8s.

p> Ponieważ każdy najemca i użytkownik korzysta ze standardowych operacji K8s bez żadnych modyfikacji, pozwala to na kompatybilność systemu z wieloma narzędziami popularnymi u operatorów – np. Spinnaker, Helm, Jenkins itp.

Zyski osiągane dzięki rozproszonej płaszczyźnie sterowania

Dużą zaletą rozproszonej płaszczyzny sterowania jest to, że rozwiązuje on ogólne koszty operacyjne naszych SRE i DevOps zespoły. Mogą teraz wykonywać operacje (konfigurację, wdrażanie, monitorowanie, zasady itp.) W wirtualnym klastrze, a płaszczyzna sterowania automatycznie mapuje go w wielu klastrach fizycznych. Oprócz uproszczenia operacyjnego dla wielu klastrów, płaszczyzna kontroli rozwiązała również problem bezpieczeństwa i izolacji w przypadku wielu dzierżawców.

Ta rozproszona płaszczyzna sterowania poprawiła również produktywność programistów, którzy chcą dodać nowe funkcje do nasza platforma – nie muszą tworzyć nowej automatyzacji za każdym razem, gdy dodają nowe funkcje, które mają wpływ na konfigurację lub operacje w wielu klastrach. Używają modelu konfiguracji opartego na intencji, a płaszczyzna kontroli wie, co należy zrobić. Ponadto mogą nadal wchodzić w interakcję z tym rozproszonym i złożonym z wielu obiektów klastra – wirtualnym kubernetesem – używając kubectl, a nie kolejnego interfejsu wiersza polecenia.

Po uruchomieniu tego w naszych środowiskach deweloperskich, przejściowych i produkcyjnych, aby uzyskać więcej informacji Już od roku zdaliśmy sobie sprawę, że ta globalnie rozproszona płaszczyzna sterowania (działająca w naszych sieciach POP) zapewnia również znaczące korzyści w zakresie skalowania, wydajności i niezawodności – coś, czego nie wyobrażaliśmy sobie do końca w pierwszych dniach. Omówimy to odkrycie w naszej nadchodzącej prezentacji na KubeCon oraz jako osobny wpis na blogu w nadchodzących tygodniach.

Ciąg dalszy…

Ta seria blogów będzie dotyczyła różnych aspektów tego, co to jest zajęło nam stworzenie i obsługę naszej globalnie rozproszonej usługi SaaS z wieloma klastrami aplikacji w chmurze publicznej, punktach PoP sieci prywatnych i witrynach brzegowych. Dalej jest (Global Service Mesh for Distributed Apps)…