Kubernetes prakticky: integrace Azure služeb díky servisnímu katalogu

Obvykle doporučuji stavové záležitosti typu databáze nebo fronta nedávat do Kubernetes clusteru, ale využít plně spravované PaaS řešení v Azure. Je spolehlivé, bezpečné, bez práce a hlavně udržitelné (nemusím nic patchovat, upgradovat ani si stále zkoušet, že moje provisioning skripty fungují i s novější verzí). Ale mám postupovat tak, že si to v Azure naklikám a přes schránku nakopíruju do příkazu pro Kubernetes Secret? To v rámci CI/CD není tak pohodlné. A co to nějak naskriptovat? To rozhodně jde, ale musím to vymyslet a připravit. Jenže přesně na tohle už řešení je – projekt Open Service Broker, který to dělá jak pro Kubernetes, tak Cloud Foundry, Open Shift nebo Service Fabric. Pojďme se dnes podívat na kombinaci Kubernetes, Service Catalog a Open Service Broker for Azure.

Proč vznikla potřeba pro service brokering

PaaS platformy pro deployment aplikací byly vždy velmi silně zaměřené na maximální jednoduchost pro vývojáře. Vezmete svůj kód a ten do platformy jednoduše pošlete. Možná ho máte v GitHub a chcete při změnách automaticky tyto nasadit s Azure Application Services. Nebo chcete vzít Visual Studio a nasadit otevřený projekt do Service Fabric. Možná potřebujete vzít vaši Javu a Spring Boot a zavolat cf push pro nasazení do vašeho Cloud Foundry clusteru od Pivotalu v Azure. Ve všech těchto případech se vývojář nechce trápit s provozem podpůrných technologií, které jeho kód využívá. A sem patří i různé databáze nebo fronty.

Jak to tedy udělat tak, aby vývojář dostal bez dlouhého čekání svou databázi aniž by musel chodit mimo svou platformu, něco někde vytvářet a connection stringy si kopírovat k sobě? Můžete namítnou, že u některých PaaS platforem lze stejnými postupy nasadit i databázi, přecijen ta je taky ve finále kód a třeba pod OpenShift běží Kubernetes, který v tomto směru má dostatek infrastrukturních konstruktů k realizaci. Jenže vývojář nechce být specialistou na nasazování a provoz databáze v kontejnerech a řešit zásadní otázky bezpečnosti, dostupnosti, konzistence dat či zálohování a patchování. Tak jak jsou aplikační platformy v cloudu tak existují i datové platformy v cloudu. Proč tedy nesáhnout po něčem specializovaném. Třeba po Azure SQL, Azure MySQL, Azure PostgreSQL, Cosmos DB s Mongo API, Cassandra API, Azure Redis či storage technologie typu blob nebo messaging systému jako je Service Bus.

PaaS aplikační platformy tedy přinesly potřebu nabídnout vývojářům přímo z platformy samotné možnost jednoduše a rychle získat podpůrné služby s využitím existujících robustních řešení datových platforem.

Open Service Broker a jeho Azure implementace

Za projektem Open Service Broker historicky stála platforma Cloud Foundry, ale myšlenka se později začala šířit i do dalších projektů a to zejména Kubernetes (což není úplně PaaS, protože do něj nedáváte kód, ale hotový kontejner, nicméně potřeba získávat nativními Kubernetes prostředky datové zdroje třeba v cloudu tu rezonuje rovněž), OpenShift a v prototypu i Service Fabric.

Implementace Open Service Broker pro Azure služby je open source projekt. Informace o něm jsou na https://osba.sh/ a zdrojáky na https://github.com/Azure/open-service-broker-azure. Projekt je ve fázi, kdy tři základní relační databáze podporuje stabilním způsobem a to konkrétně SQL, MySQL a PostgreSQL. Zatím experimentálně (ale funguje to) nabízí další služby jako je Cosmos DB, Key Vault, Service Bus, Event Hub, Redis a blob storage.

Použití s Kubernetes Service Catalog

Pojďme si to vyzkoušet. Neprve potřebujeme do Kubernetes přidat projekt Service Catalog, což je komponenta, která pak následně bude volat OSB implementace (ty budou fungovat jako něco na způsob driveru). Protože Service Catalog ještě není nativní součástí kubectl CLI, nainstalujeme si na hraní speciální CLI (pro provoz řešení to ale není nutné, zdroje vytváříte jako Kubernetes objekty v YAML předpisech).

curl -sLO https://download.svcat.sh/cli/latest/linux/amd64/svcat
chmod +x ./svcat
sudo mv ./svcat /usr/local/bin/
svcat version --client

Projekt Service Catalog bude do AKS nejlepší nainstalovat Helm šablonou.

helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm install svc-cat/catalog --name catalog \
    --namespace services \
    --set controllerManager.healthcheck.enabled=false

Následně opět Helm šablonou nainstalujeme OSBA, tedy implementaci „driveru“ pro Azure. V tento moment musíte zadat login do Azure, tedy účet service principal (lze předpokládat, že někdy v budoucnu bude možné využít Managed Service Identity, ale v době psaní článku zadáme účet takhle ručně).

helm repo add azure https://kubernetescharts.blob.core.windows.net/azure
helm install azure/open-service-broker-azure --name azurebroker --namespace services \
  --set azure.subscriptionId=$subscription \
  --set azure.tenantId=$tenant \
  --set azure.clientId=$principal \
  --set azure.clientSecret=$client_secret

Vypište si Pody v namespace services a počkejte, až budou všechny nahoře. Pak už si můžeme vypsat brokery (máme tam osba) a v něm jednotlivé třídy.

$ svcat get brokers
  NAME   NAMESPACE                                     URL                                      STATUS
+------+-----------+--------------------------------------------------------------------------+--------+
  osba               https://azurebroker-open-service-broker-azure.services.svc.cluster.local   Ready
$ svcat get classes
              NAME                NAMESPACE             DESCRIPTION
+-------------------------------+-----------+---------------------------------+
  azure-postgresql-9-6-database               Azure Database for PostgreSQL
                                              9.6-- database only
  azure-sql-12-0-database                     Azure SQL 12.0-- database only
  azure-mysql-5-7-dbms                        Azure Database for MySQL 5.7--
                                              DBMS only
  azure-mysql-5-7-database                    Azure Database for MySQL 5.7--
                                              database only
  azure-mysql-5-7                             Azure Database for MySQL 5.7--
                                              DBMS and single database
  azure-sql-12-0-dbms                         Azure SQL 12.0-- DBMS only
  azure-postgresql-9-6                        Azure Database for PostgreSQL
                                              9.6-- DBMS and single database
  azure-postgresql-9-6-dbms                   Azure Database for PostgreSQL
                                              9.6-- DBMS only
  azure-sql-12-0                              Azure SQL Database 12.0-- DBMS
                                              and single database

Jak vidíte ve výchozím stavu máme k dispozici jen ty služby, které jsou v rámci projektu OSBA ve stavu stable. To mi ale zatím stačí.

Proč tam je třeba MySQL třikrát? Když si v Azure vytvoříte Azure Database for MySQL, vznikne platformní MySQL server a jedna databáze. Tomu odpovídá třída azure-mysql-5-7. Jenže vy také můžete na jednom serveru vytvořit databází několik s tím, že tyto sdílí zdroje. Zejména pro testovací potřeby v rámci CI/CD je to cenově efektivní varianta. Pak můžete použít azure-mysql-5-7-dbms pro vytvoření serveru a pak už jen azure-mysql-5-7-database pro přidání DB do existujícího serveru.

U třídy si můžeme vypsat plány.

$ svcat get plans --class azure-postgresql-9-6
        NAME         NAMESPACE          CLASS                    DESCRIPTION
+------------------+-----------+----------------------+--------------------------------+
  basic                          azure-postgresql-9-6   Basic Tier-- For workloads
                                                        that require light compute and
                                                        I/O performance.
  general-purpose                azure-postgresql-9-6   General Purpose Tier-- For
                                                        most business workloads that
                                                        require balanced compute
                                                        and memory with scalable I/O
                                                        throughput.
  memory-optimized               azure-postgresql-9-6   Memory Optimized Tier-- For
                                                        high-performance database
                                                        workloads that require
                                                        in-memory performance for
                                                        faster transaction processing
                                                        and higher concurrency.

V rámci konkrétní třídy a plánu je obvykle k dispozici poměrně dost různých nastavení. Třeba počet vCore, velikost nebo nastavení pravidel na firewallu. Celý seznam parametrů získáte takhle:

svcat describe plan azure-postgresql-9-6/general-purpose

Podstatně přehlednější to ale bude tady v dokumentaci: https://github.com/Azure/open-service-broker-azure/blob/master/docs/modules/postgresql.md.

Vytvořme si teď DB s využitím CLI.

svcat provision myfirstdb --class azure-postgresql-9-6 \
    --plan general-purpose \
    -p location=westeurope \
    -p resourceGroup=aksgroup

svcat get instances
    NAME      NAMESPACE          CLASS                PLAN            STATUS
+-----------+-----------+----------------------+-----------------+--------------+
  myfirstdb   default     azure-postgresql-9-6   general-purpose   Provisioning

Pohledem do portálu skutečně zjistíme, že databázový stroj i databáze jsou hotové.

Výborně. Jak se teď k databázi připojit? Service Katalog má koncept bindingu a to je o vytvoření loginu a connection stringu a uložení těchto informací do Kubernetes Secret tak, aby to třeba aplikační kontejner mohl načíst.

Vyzkoušejme si to.

$ svcat bind myfirstdb
  Name:        myfirstdb
  Namespace:   default
  Status:
  Secret:      myfirstdb
  Instance:    myfirstdb

Parameters:
  No parameters defined

Podívejme se, co v tom secret bude.

$ printf 'Host: ' && kubectl get secret myfirstdb -o json | jq -r .data.host | base64 --decode && echo && \
> printf 'DB: ' && kubectl get secret myfirstdb -o json | jq -r .data.database | base64 --decode && echo && \
> printf 'User: ' && kubectl get secret myfirstdb -o json | jq -r .data.username | base64 --decode && echo && \
> printf 'Password: ' && kubectl get secret myfirstdb -o json | jq -r .data.password | base64 --decode && echo
Host: 53f407bc-2cc4-4ead-bfad-bfb43269f0e4.postgres.database.azure.com
DB: gm1ugq4kir
User: j3quoupdwm@53f407bc-2cc4-4ead-bfad-bfb43269f0e4
Password: 6y9kUwXWigwQNdWz

Pojďme udělat druhý (jiný) binding na tu stejnou instanci.

$ svcat bind myfirstdb --name myfirstdb2 --secret-name myfirstdb2
  Name:        myfirstdb2
  Namespace:   default
  Status:
  Secret:      myfirstdb2
  Instance:    myfirstdb


Co bude v Secret?

$ printf 'Host: ' && kubectl get secret myfirstdb2 -o json | jq -r .data.host | base64 --decode && echo && \
> printf 'DB: ' && kubectl get secret myfirstdb2 -o json | jq -r .data.database | base64 --decode && echo && \
> printf 'User: ' && kubectl get secret myfirstdb2 -o json | jq -r .data.username | base64 --decode && echo && \
> printf 'Password: ' && kubectl get secret myfirstdb2 -o json | jq -r .data.password | base64 --decode && echo
Host: 53f407bc-2cc4-4ead-bfad-bfb43269f0e4.postgres.database.azure.com
DB: gm1ugq4kir
User: wzqg5lf6tj@53f407bc-2cc4-4ead-bfad-bfb43269f0e4
Password: IgLwAmgojY7rOipv

Vidíte? Stejný hostitel (DB server), stejná DB, ale jméno a heslo je jiné.

To je velmi zajímavé. Můžeme tedy vytvořit velmi elegantně nad jednou databází hned několik účtů plně automatizovaně prostřednictvím bindingu. Můžeme ale také vytvořit novou instanci a to buď ve formě další databáze v existujícím serveru nebo úplně nový server. Velmi flexibilní.

Service broker přes YAML konstrukty

Zatím jsme si ukázili nějakou příkazovou řádku, ale to není ten způsob, pro který si něco takového nasadíte. To klíčové je schopnost integrovat tuto funkcionalitu do vašeho Kubernetes ekosystému, tedy YAML předpisů.

Mějme následující YAML soubor. V něm definujeme externí DB v Azure a současně startujeme kontejner, který má mít do této DB přístup.

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: my-mysqldb-instance
  namespace: default
spec:
  clusterServiceClassExternalName: azure-mysql-5-7
  clusterServicePlanExternalName: basic
  parameters:
    location: westeurope
    resourceGroup: aksgroup
---
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: my-mysqldb-binding
  namespace: default
spec:
  instanceRef:
    name: my-mysqldb-instance
  secretName: my-mysqldb-secret
---
kind: Pod
apiVersion: v1
metadata:
  name: env
spec:
  containers:
    - name: ubuntu
      image: tutum/curl
      command: ["tail"]
      args: ["-f", "/dev/null"]
      env:
      - name: "DB_HOST"
        valueFrom:
          secretKeyRef:
            name: my-mysqldb-secret
            key: host
      - name: "DB_PORT"
        valueFrom:
          secretKeyRef:
            name: my-mysqldb-secret
            key: port
      - name: "DB_DB"
        valueFrom:
          secretKeyRef:
            name: my-mysqldb-secret
            key: database
      - name: "DB_USERNAME"
        valueFrom:
          secretKeyRef:
            name: my-mysqldb-secret
            key: username
      - name: "DB_PASSWORD"
        valueFrom:
          secretKeyRef:
            name: my-mysqldb-secret
            key: password

Pošleme to do AKS.

kubectl apply -f serviceCatalogDemo.yaml

V průběhu vytváření databáze bude náš kontejner v tomto stavu:

NAME      READY     STATUS                       RESTARTS   AGE
env       0/1       CreateContainerConfigError   0          2m

Nemůže nastartovat, protože ještě nemá potřebné údaje pro start, v našem případě heslo do hotové databáze uložené jako Secret. Jakmile bude DB připravena vytvoří se i Secret a náš kontejner se rozjede.

Ověřme si, že kontejner opravdu vidí na potřebné připojovací údaje.

$ kubectl exec env -- env | grep DB
DB_USERNAME=n0skdtgdyz@a60a7d35-ad65-424c-9afb-c8b58df2b220
DB_PASSWORD=mPJTalBm8EQGEz16
DB_HOST=a60a7d35-ad65-424c-9afb-c8b58df2b220.mysql.database.azure.com
DB_PORT=3306
DB_DB=aemumu6xam

Helm nasazení celé aplikace včetně vytvoření databáze v Azure

Tohle všechno můžeme dát dohromady a vytvořit nasazení celé aplikace, které se postará o vytvoření Podů, objektů typu Service a také získání databáze as a service z Azure. K tomu lze použít Helm šablonu.

V Azure Helm repozitáři je připraven kompletní příklad na deploymend WordPress s Azure databází.

$ helm repo add azure https://kubernetescharts.blob.core.windows.net/azure
"azure" has been added to your repositories

$ helm install azure/wordpress --name wp --set wordpressUsername=tomas \
>     --set wordpressPassword=Azure12345678 \
>     --set mysql.azure.location=westeurope

WordPress bude mít veřejnou IP.

$ kubectl get svc
NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
kubernetes                 ClusterIP      192.168.4.1     <none>          443/TCP                      12d
myweb-service-ext-public   LoadBalancer   192.168.7.232   23.97.177.196   80:30803/TCP                 4d
wp-wordpress               LoadBalancer   192.168.5.136   23.97.188.215   80:32468/TCP,443:31300/TCP   1m

Nějakou dobu také bude trvat, než se databáze v Azure nasadí.

$ svcat get instances
             NAME               NAMESPACE        CLASS             PLAN            STATUS
+-----------------------------+-----------+-----------------+-----------------+--------------+
  wp-wordpress-mysql-instance   default     azure-mysql-5-7   general-purpose   Provisioning

Pak už najede i Pod a náš WordPress s databází jako služba v Azure je připraven.

$ kubectl get pods -w
NAME                           READY     STATUS                       RESTARTS   AGE
ubuntu                         1/1       Running                      0          3d
wp-wordpress-9c5d98bdf-2ds8g   0/1       CreateContainerConfigError   0          2m
wp-wordpress-9c5d98bdf-2ds8g   0/1       Running   0         8m
wp-wordpress-9c5d98bdf-2ds8g   1/1       Running   0         11m

 

Chcete pro vývojáře plně spravovanou databázi v Azure tak, že ji mohou získat přímo Kubernetes prostředky bez nutnosti odskakovat do Azure interface? Proč se trápit s něčím takovým v kontejnerech, když jsou krásné hotové PaaS služby, které díky Service Catalog a OSBA do Kubernetes jednoduše a elegantně naintegrujete. Vyzkoušejte si to.

 

Podobné příspěvky: