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. 

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. 

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