Skip to content
malak.cloud
  • Kontakt
  • O mnie
  • Search Icon

malak.cloud

Cloud Native na co dzień

Jak wykorzystać Anthos Config Management

Jak wykorzystać Anthos Config Management

7 października 2020

Sam nie do końca jestem zwolennikiem podejścia multi-cloud. Szczególnie na początku pracy z chmurami publicznymi. Jednak czasem jest to konieczność. Jeżeli już mamy u siebie taką sytuację, to warto wspomagać się istniejącymi możliwościami. Wsród nich są zarówno rozwiązania open source, jak i produkty od dostawców cloudowych. Jednym z nich jest Anthos od Google, którego jednym z komponentów jest Anthos Config Management.

Umożliwia on zarządzanie konfiguracjami wielu klastrów kubernetesowtych z jednego miejsca. Wszystkie deploymenty i tworzenie obiektów odbywa się poprzez automatyczne wdrożenia na klastry z repozytorium kodu, w którym przechowujemy nasze manifesty.

Wspomniałem o multi-cloud, ale Anthos pozwala oczywiście także na zarządzanie klastrami w samym GCP. Co mniej oczywiste także klastry on-premises mogę wchodzić w skład takiej floty, którą rządzi.

Pokażę jak „podłączyć” takie klastry pod Anthosa i za pomocą plików konfiguracyjnych trzymanych w GitHub-ie wykonywać automatyczne wdrożenia na wiele klastrów. 

Kubernetes

Na początek uruchomimy sobie dwa klastry Kubernetes. W naszym przypadku oba będą działały w chmurze Google, ale podobne rozwiązanie można wykorzystać także w rozwiązaniach on-premises lub uruchamiając klastry w innych chmurach.

Środowiska działają w dwóch różnych regionach. Klaster, nazwijmy go produkcyjnym, pracuje w USA. Klaster stagingowy w Europie. Wbrew pozorom, takie rozwiązania można dość często spotkać, programiści pracują w Europie, a główni klienci są w USA.

Rejestracja w Anthos

Aby móc zarządzać klastrami w Anthos, należy je zarejestrować w usłudze. 

W trakcie rejestracji tworzone jest nowe konto serwisowe. Określamy też pod jaką nazwą klaster będzie widoczny w Anthosie. To nie musi być nazwa klastra. W naszym przykładzie drugi klaster nazwiemy cluster-staging.

Dodatkowo na klastrze instalowany jest agent, który odpowiada za komunikację z Anthosem. Fajne jest to, że cała komunikacja inicjowana jest przez agenta. Upraszcza to konfigurację sieci i zabezpieczeń dla naszych klastrów.

W przypadku rejestracji klastrów spoza GKE czynności te musimy wykonać ręcznie.

Po rejestracji oba klastry powinny być widoczne w Anthosie. Zielony status informuje nas o tym, że wszystko się udało.

Kod

Konfigurację dla naszych klastrów będziemy przechowywali na GitHubie. Jeżeli chcecie się sami pobawić, udostępniam swoje pliki w repozytorium. Można zrobić forka i podpiąć swoje rozwiązania pod własne pliki konfiguracyjne.

Lokalnie na dysku utworzymy odpowiednią strukturę katalogów, która pozwoli na konfigurację klastrów. Można to zrobić ręcznie, ale można pomóc sobie także narzędziem od Google. nomos to cli umożliwiające pracę z Anthos Config Management. Wykorzystując nomos wykonujemy komendę

nomos init

i na dysku powinniśmy zobaczyć następującą strukturę katalogów.

Można w ramach jednego repozytorium utworzyć podkatalogi dla poszczególnych klastrów. My jednak wrzucimy wszystko w jedno miejsce i wykorzystamy obiekty Cluster i ClusterSelector aby zarządzać tym, co ma być wykonane na poszczególnych klastrach Kubernetes.

Za pomocą definicji obiektów Cluster zdefiniujemy, w jaki sposób Anthos ma widzieć poszczególne klastry. Tutaj pole name ustawiamy na wartość zdefiniowaną podczas rejestrowania klastra w Anthosie.

kind: Cluster
apiVersion: clusterregistry.k8s.io/v1alpha1
metadata:
  name: cluster-staging
  labels:
    env: staging

Jak widać, do naszego klastra dodaliśmy label env o wartości staging. Teraz tworzymy ClusterSelector (wszak Kubernetes selektorami stoi)

kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: selector-cluster-staging
spec:
  selector:
    matchLabels:
      env: staging

który będzie wybierał wszystkie klastry z label env o wartości staging.

Oba te pliki powinny być umieszczone w katalogu clusterregistry.

Same selektory jednak nic nie zdziałają. Musimy je wykorzystać w manifestach opisujących nasze zasoby. Robi się to za pomocą anotacji. Przykładowo, jeżeli chcemy aby jakiś namespace był utworzony tylko na konkretnym klastrze definiujemy to  następujący sposób

apiVersion: v1
kind: Namespace
metadata:
  name: service-stg
  annotations:
    configmanagement.gke.io/cluster-selector: selector-cluster-staging

W podobny sposób opisujemy pozostałe zasoby i umieszczamy je w odpowiednich podkatalogach. W naszym przypadku struktura wygląda następująco

Mamy dwa klastry, na których utworzymy namespaces z zasobami. Przestrzeń common będzie zdeployowana na oba klastry, a service-prod i service-stg na klaster produkcyjny i stagingowy. Przykładowy deployment na klaster produkcyjny także będzie zawierał odpowiednią annotację:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: "service-prod"
  name: "multitool"
  annotations:
    configmanagement.gke.io/cluster-selector: selector-cluster-prod
spec:
  replicas: 3
...

Repozytorium

Jak już wspomniałem, cała nasza konfiguracja wszystkich zasobów będzie przechowywana w repozytorium na GitHub. Zakładam, że mamy już przygotowane takie repozytorium i umieściliśmy w nim już nasz kod.

W kolejnym kroku trzeba przygotować klucze, za pomocą których Anthos będzie się uwierzytelniał w GitHub. Najlepiej utworzyć osobny klucz dla każdego klastra. My pójdziemy na łatwiznę i wykorzystamy tą samą parę kluczy dla obu serwerów.

Tworzymy więc klucze

ssh-keygen -t rsa -b 4096 \ -C "GitHub Login" \ -N '' \ -f anthos-demo

i w ustawieniach GitHuba dodajemy klucz publiczny.

Konfiguracja

Mamy przygotowane praktycznie wszystko. Teraz musimy skonfigurować Anthosa tak, aby korzystał z naszego repozytorium i wdrażał na naszych klastrach oczekiwane przez nas zmiany.

Przechodzimy do zakładki Config management, zaznaczamy oba nasze klastry i wciskamy przycisk CONFIGURE. 

W tym miejscu definiujemy połączenie do repozytorium. Możemy też określić na przykład branch, z którego ma być pobierana konfiguracja lub katalog z konfiguracjami dla konkretnego klastra.

Wciskamy DONE… I dostajemy błąd. Config Management nie może oczywiście podłączyć się do naszego repozytorium z konfiguracją. Brakuje sekretu, w którym przechowywany będzie klucz do ustanowienia połączenia ssh.

Na obu klastrach tworzymy odpowiednie sekrety. W trakcie konfiguracji Config Management na klastrach zostały utworzone namespaces config-management-system. Secrety tworzymy w tych przestrzeniach nazw:

kubectl create secret generic git-creds \
--namespace=config-management-system \
--from-file=ssh=anthos-demo

Po chwili statusy przy naszych klastrach powinny zmienić się na Synced i możemy przejść do testów.

Testy

Za pomocą kubectl sprawdźmy jakie zasoby zostały utworzone na poszczególnych klastrach. Jak widać na następnych dwóch screenach namespace common jest obecna na obu klastrach.

Na klastrze produkcyjnym mamy dostępną dodatkowo przestrzeń nazw service-prod

a na klastrze stagingowym service-stg.

Wygląda więc na to, że wszystko zostało utworzone tak jak zaplanowaliśmy.

Sprawdźmy jeszcze serwisy. Klaster produkcyjny

i wynik zapytania

oraz klaster stagingowy.

Także tu pracuje odpowiednia wersja serwisu.

Od tej pory każda zmiana, którą wrzucimy do repozytorium będzie automatycznie wdrażana na klastrach. Wygodne.

Podsumowanie

Config Management to tylko jedna z możliwości udostępnianych przez Anthos. Bardzo ułatwia jednak pracę w momencie, gdy zarządzamy wieloma klastrami. Mamy jeden „punkt styku” z wszystkimi zasobami. Zamiast wielu operacji apply na poszczególnych klastrach wykonujemy jeden commit do repozytorium, a Anthos dba o to, aby nasze zasoby zostały odpowiednio wdrożone. Każdy obiekt, którym zarządza Anthos Config Management będzie nieustannie synchronizowany z naszym repozytorium. 


GCP, k8s
GCP, k8s

Post navigation

PREVIOUS
Jak dobrać zasoby dla funkcji Lambda
NEXT
Skalujemy kontenery w usłudze Amazon ECS
Comments are closed.
Cześć. Nazywam się Przemek Malak. Dzięki za wizytę. Mam nadzieję, że to o czym piszę Cię zainteresowało. Jeżeli chcesz ze mną pogadać, najłatwiej będzie przez LinkedIn.

Losowe wpisy

  • Jak przesłać plik do S3 za pomocą API Gateway

    16 listopada 2022
  • AWS IoT ExpressLink

    22 sierpnia 2022
  • Czym jest dla mnie Cloud Native

    20 listopada 2020
  • Filtrowanie zdarzeń wyzwalających Lambdę

    27 listopada 2021
  • Domain Storytelling

    6 listopada 2022
  • Apps
  • AWS
  • CloudNative
  • Cookbook
  • Data
  • DEV
  • GCP
  • IoT
  • Istio
  • k8s
  • Security
  • Social
  • GitHub
  • LinkedIn
© 2023   All Rights Reserved.