Google Kubernetes Engine Enterprise
Umwege vermeiden
Veröffentlicht in Ausgabe 11/2024 - SCHWERPUNKT
Die Google Kubernetes Engine (GKE) in der Enterprise-Ausprägung definiert eine konsistente Plattform, mit deren Hilfe IT-Verantwortliche bestehende Anwendungen und Infrastrukturen über ein einheitliches Cloudbetriebsmodell von zentraler Stelle modernisieren.
Dies schließt insbesondere Governance- und Security-Features ein, die auf der Ebene der sogenannten Flotten ihr Werk verrichten (Bild 1). Um dies zu ermöglichen, bietet GKE Enterprise eine Reihe von Tools:
- Konfigurations- und Richtlinienverwaltung zur automatischen Verteilung von identischen Einstellungen auf alle Cluster.
Die Google Kubernetes Engine (GKE) in der Enterprise-Ausprägung definiert eine konsistente Plattform, mit deren Hilfe IT-Verantwortliche bestehende Anwendungen und Infrastrukturen über ein einheitliches Cloudbetriebsmodell von zentraler Stelle modernisieren.
Dies schließt insbesondere Governance- und Security-Features ein, die auf der Ebene der sogenannten Flotten ihr Werk verrichten (Bild 1). Um dies zu ermöglichen, bietet GKE Enterprise eine Reihe von Tools:
- Konfigurations- und Richtlinienverwaltung zur automatischen Verteilung von identischen Einstellungen auf alle Cluster.
- Netzwerk-Features lassen sich ebenfalls für alle Cluster einheitlich setzen und müssen nicht mehr auf Clusterebene konfiguriert werden.
- Identitäts- und Teamverwaltung auf Flottenebene.
- Observability über ein gemanagtes Services Mesh auf Basis von Istio.
Die GKE-Distribution steht dabei nicht nur für die Google-Cloud zur Verfügung, sondern lässt sich auch in AWS und Azure betreiben. Zudem ist das Deployment im eigenen Rechenzentrum auf Basis von VMware vSphere unterstützt. Relativ neu ist die Möglichkeit, GKE in Edge-Umgebungen einzusetzen.
Die Nutzung von GKE Enterprise wird durch Google dediziert berechnet und ist additiv zu GKE. Zum aktuellen Zeitpunkt verlangt Google für alle Enterprise-Features eine Gebühr von 6 US-Dollar pro Monat – unabhängig davon, wo diese in der Cloud laufen. Eine Abweichung besteht bei der Installation von GKE in eine lokale Umgebung mit vSphere, dafür verlangt der Anbieter 24 US-Dollar pro vCPU und Monat. Sollten Sie also noch keine lokale Kubernetes-Distribution im Unternehmen installiert haben, lohnt sich hier auf alle Fälle ein Preisvergleich mit anderen Anbietern.
GKE Enterprise aktivieren
Der Start mit GKE Enterprise geht schnell von der Hand und erfolgt über die Aktivierung der API. Dazu wählen Sie zunächst das Projekt, für das Sie GKE Enterprise aktivieren wollen und wechseln auf die Kubernetes-Übersichtsseite. Hier klicken Sie auf "Lernen und Aktivieren" und erhalten so Zugang zur Seite "Informationen", wo Sie mehr zur GKE-Enterprise-Plattform erfahren. Anschließend klicken Sie auf "GKE Enterprise aktivieren". Dadurch erzeugen Sie im Projekt eine GKE-Flotte, die als Basis zur weiteren Administration dient.
Jetzt stehen allerdings noch nicht alle GKE-Enterprise-Features zur Verfügung – Sie müssen die Funktionen noch in Ihre Cluster installieren. Ein beliebtes Feature ist dabei das "Cloud Service Mesh". Ein Kubernetes Service Mesh ist eine dedizierte Infrastrukturschicht, die dazu dient, die Kommunikation zwischen Services in einer Mikroservice-Architektur zu steuern und zu optimieren. Dabei stellt ein Service Mesh sicher, dass die Kommunikation zwischen den verschiedenen Teilen einer Anwendung zuverlässig, sicher und effizient abläuft. Es gibt verschiedene Implementierungen, zu den bekanntesten gehören Linkerd, Consul Connect und schließlich Istio, auf dessen Basis das Service Mesh von Google arbeitet.
Die Installation des Service Mesh gelingt über die GUI oder per CLI. Zuerst erzeugen Sie eine einfach Manifest-Datei, mit deren Hilfe Sie die Aktivierung steuern:
echo "management: automatic" > mesh.yaml
Jetzt aktivieren Sie Cloud Service Mesh für Ihre Flotte:
gcloud container fleet mesh enable --project <Fleet-Project-ID> \ --fleet-default-member-config mesh.yaml
Jeder neu erstellte Cluster hat nun das Cloud Service Mesh aktiviert. Um Anwendungen mit Istio-Unterstützung bereitzustellen, müssen Sie nur noch die Namespaces in Kubernetes entsprechend labeln:
kubectl label namespace <Namespace> istio.io/rev- istio-injection=enabled --overwrite
Um Istio zu testen, nutzen Sie einfach die "Bookinfo"-Beispiel-Applikation [1], die Sie von GitHub downloaden und dann installieren:
kubectl apply -f samples/bookinfo/ platform/kube/bookinfo.yaml
Nun installieren Sie das Ingress-Gateway, damit die Applikation von außen erreichbar ist:
kubectl apply -f samples/bookinfo/ networking/bookinfo-gateway.yaml
Der Abruf der IP-Adresse gelingt dann wie folgt:
kubectl get svc istio-ingressgateway -n istio-system
Sobald die Installation und Konfiguration der Applikation abgeschlossen ist, können Sie innerhalb der Google-Konsole die Istio-Informationen via abrufen.
Sichere Änderungen dank Config Sync
Ein weiteres beliebtes Feature von GKE Enterprise ist Config Sync. Damit ist es möglich, Kubernetes-Anwendungen mittels eines GitOps-Ansatzes bereitzustellen und zu betreiben. Aus der Nutzung von GitOps ergibt sich eine Reihe von Vorteilen: erstens die deklarative Konfiguration, die erlaubt, den gewünschten Zustand der Infrastruktur und der Anwendungen in Form von Code zu hinterlegen. Zweitens unterliegt jeglicher Code der Versionskontrolle mit Git und dient als Single-Source-of-Truth. Sollen Änderungen erfolgen, geschieht dies durch Pull Requests (PR) bei GitHub oder Merge Resquest (MR) bei GitLab und der anschließenden Übernahme in den Main-Branch.
Darüber hinaus stellt der GitOps-Config-Sync-Agent, der in GKE Enterprise läuft, eine ständige Automatisierung und Synchronisation sicher. Dafür beobachtet der Agent den aktuellen Stand des Git-Repositories und wendet Änderungen automatisch auf dem Cluster an. Dies alles fördert die Transparenz und die Rückverfolgbarkeit. Da Änderungen nicht direkt auf dem Livesystem, sondern in Git erfolgen, können Sie jegliche Änderungen leicht zurückverfolgen.
Die Config-Sync-Architektur sehen Sie in Bild 2: In der Regel kümmert sich ein Admin um die Cluster-Bereitstellung sowie um die clusterweite Konfiguration. Unterschiedliche Operatoren und Teams können jeweils einen eigenen Namespace erhalten und dort mittels Config Sync aus ihren Repos Änderungen in den Namespace einbringen.
Um Config Sync für den Betrieb einzurichten, wechseln Sie auf die Seite "Kubernetes Engine / Konfiguration". Ist der Dienst auf dem Cluster noch nicht installiert, erledigen Sie dies im Feature-Manager. Diesen erreichen Sie in der Konsole unter "Kubernetes Engine / Feature Manager". Dort wählen Sie unter "Fleet-level Feature Management" den Punkt "Config Sync" aus und klicken "Configure". Im folgenden Dialog aktivieren Sie den Dienst.
Config Sync muss in der Lage sein, sich bei Git zu authentifizieren. Am einfachsten definieren Sie dies mit einem SSH-Schlüsselpaar – es sind aber auch ein Cookiefile, Token, Google-Dienstkonten oder das standardmäßige Google-Compute-Engine-Dienstkonto unterstützt. Config Sync supportet GitHub, GitLab, BitBucket oder Google-Cloud-Repositories. Alle Cloud-Repositories im aktuellen Projekt zeigt Ihnen der folgende Befehl:
gcloud source repos list <Repo-Name Project-ID URL> my-repo my-project https://source.developers.google.com/p/my-project/r/my-repo-csr
Ein SSH-Schlüsselpaar erzeugen Sie über
ssh-keygen -t rsa -b 4096 \-C "<Git-Repository-Username>" \ -N '' \ -f </Pfad/zum/Keyrepair-Filenamen>
An dieser Stelle müssen Sie den öffentlichen Schlüssel in Ihr Git hochladen. Dafür legen Sie einen User an und uploaden das Secret dann in den Profileinstellungen dieses Benutzers. Den privaten Schlüssel fügen Sie anschließend mittels eines Secrets dem Cluster hinzu:
kubectl create ns config-management-system && \ kubectl create secret generic git-creds \
--namespace=config-managementsystem \ --from-file=ssh=</Pfad /zum/Keyrepair-Privater-Key-Filename>
Erste Pakete ausrollen
Nun können Sie beginnen, Packages zu deployen. Dazu müssen Sie Config Sync so einrichten, dass ein Lesezugriff auf ein Repository möglich ist. Dies erreichen Sie im Menü rechts mit einem Klick auf "Config" und wählen dann oben "Deploy Package". Jetzt navigieren Sie zu Ihrem Cluster und wählen "Continue". Nun gilt es, den zu installierenden "Package Source Type" zu definieren – Config Sync unterstützt Git- und OCI-Repositories. In unserem Beispiel wählen wir "Git" und dann "Continue".
Nun müssen Sie das Package konfigurieren: Als Source-Typ wählen Sie diesmal "Git" und vergeben einen Sync-Namen. Als "Source" hinterlegen Sie Ihre Repository-URL. Diese kopieren Sie am besten aus dem Git Repository (zum Beispiel bei GitLab "Code / Clone with SSH"). Zum Abschluss müssen Sie noch eine Reihe von Konfigurationen vornehmen. Bei Bedarf an etwa einem alternativen Branch es ist zudem möglich, Manifeste aus einem Unterverzeichnis zu laden. Für Deployments basierend auf SSH-Secrets müssen Sie noch das vorher definierte Secret referenzieren. Zu guter Letzt prüfen Sie sämtliche Einstellungen und können bei Erfolg das Deployment starten.
Zentrale Richtlinien mit dem Policy Controller
Der Policy Controller ist ein Teil von GKE Enterprise und basiert auf dem Open Policy Agent (OPA). Die Funktionalität wird durch einen dediziert installierten Enterprise Policy Controller auf Basis der Gatekeeper-Erweiterung von OPA sichergestellt. Damit ist es möglich, auf einzelnen Clustern beziehungsweise allen Mitgliedern einer GKE-Flotte zentral Richtlinien hinsichtlich Compliance und Security deklarativ zu definieren und durchzusetzen. Dabei erfolgt eine fortlaufende Prüfung dieser Richtlinien und Sie erhalten als Cluster-Betreiber einen kontinuierlichen Überblick, ob alle Ressourcen den definierten Richtlinien entsprechen.
Hier ist zudem eine automatisierte Richtliniendurchsetzung möglich, die alle Aktionen, die den Policies widersprechen, blockiert oder protokolliert. So lässt sich beispielsweise das Deployen von Images aus nicht gestatteten Quellen untersagen. Auch in Sachen Auditing und Berichterstellung hilft der GKE Enterprise Policy Controller, indem er Protokolle mit Detailinformationen zu nicht konformen Ressourcen und Vorgängen bereitstellt. Für die Definition von Richtlinien ist es nicht notwendig, alle OPA-Regeln selbst zu schreiben – vielmehr bietet Google bereits entsprechende Vorlagen und Richtlinien an.
Das Aktivieren des Policy Controllers gelingt wieder am einfachsten über den Feature-Manager. Dazu klicken Sie auf der Übersichtsseite innerhalb des Policy-Feldes auf "Configure". Im daran anschließenden Wizard können Sie sich die durchzuführenden Schritte noch mal anzeigen lassen und klicken anschließend unten erneut auf "Configure" – gegebenenfalls wird vor der Installation noch die API "anthospolicycontroller.googleapis. com" aktiviert. Sobald die Installation abgeschlossen ist, gelangen Sie zurück zum Feature-Manager und müssen nur noch Ihren Cluster hinzufügen.
Wie bereits erwähnt, hält Google eine Reihe von fertigen Richtlinien-Bundles bereit. Diese umfassen gängige Industriestandards wie zum Beispiel den CIS-Kubernetes-Benchmark, den NSA CISA Kubernetes Hardening Guide, aktuelle Pod-Security-Policies, die NIST-SP-800-Standards, PCI DSS in der Version 3.2.1 und auch "Cost and Reliability"-Bundles. Die Aktivierung einer solchen Policy gelingt im Feature Manager in der "Policy Section" über den Knopf "Customize Fleet Settings". Hier aktivieren Sie auf der rechten Seite die gewünschten Richtlinien.
Falls die vorbereiteten Richtlinien nicht für Sie passen, erstellen Sie einfach ein eigenes Bundle. Dazu müssen Sie im ersten Schritt ein "Constraint" definieren. Listing 1 zeigt beispielhaft, wie Sie mittels der Policy-Sprache Rego das Bereitstellen von Ressourcen unterbinden, die einen verbotenen Ressourcennamen haben.
Listing 1: Ressourcen mit verbotenem Namen unterbinden
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8sdenyname
spec:
crd:
spec:
names:
kind: K8sDenyName
validation:
# Schema for the `parameters` field
openAPIV3Schema:
properties:
invalidName:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8sdenynames
violation[{"msg": msg}] {
input.review.object.metadata.name
== input.parameters.invalidName
msg := sprintf("The name %v is not
allowed", [input.parameters.inva
lidName])
}
Das Constraint selbst speichern Sie als YAML-Manifest ab und installieren es im Kubernetes-Cluster. Dies bewerkstelligen Sie entweder über einen GitOps-Mechanismus wie beispielsweise GKE Config Sync oder manuell wie im folgenden Beispiel per CLI:
kubectl apply -f constraint.yaml
Nach der Installation des Constraints steht im Kubernetes-Cluster eine neue CRD (K8sDenyName) zur Verfügung, die Sie mittels einer Richtlinie zur Anwendung bringen. Auch dies geschieht über eine Kubernetes Manifest-Datei (Listing 2).
Listing 2: CRD mittels Policy anwenden
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDenyName
metadata:
name: no-policy-violation
spec:
parameters:
invalidName: "policy-violation"
Hochverfügbarkeitund Skalierung
Auch in Sachen Hochverfügbarkeit, Skalierbarkeit und Disaster Recovery kann GKE Enterprise punkten. Eine Schlüsselkomponente dafür ist der Multi-Cluster-Ingress. Dahinter verbirgt sich eine Funktion, die es erlaubt, eingehenden Netzwerkverkehr über mehrere Kubernetes-Cluster zu verteilen. Dies ist besonders interessant, um Anwendungen georedundant zu betreiben und dergestalt den Ausfall einer ganzen Region abzufedern.
Im Gegensatz zu anderen Konzepten wie etwa einem DNS-basierten Failover mit Health-Check erlaubt der Google-Ansatz eine einfache und zentrale Verwaltung von Ingress-Regeln, die Sie automatisch auf alle Gruppenmitglieder einer GKE-Flotte anwenden können.
Multi-Cluster-Ingress ist dabei eng mit dem Google-Loadbalancer verknüpft und ermöglicht so ein globales Skalieren der Anwendung. Technisch basiert Ingress auf dem global verteilten "Application Load Balancer" von Google mit Proxies, die an über 100 Standorten von Google bereitstehen und externe IP-Adressen nutzen, die über Anycast zur Verfügung stehen. Dabei wandern Anfragen an die Clustern weiter zu den GKE-Clustern in den Regionen, die ihren Clients am nächsten sind.
Wie die anderen GKE-Enterprise-Dienste aktivieren Sie GKE-Multi-Cluster-Ingress über den Feature Manager. Sobald dies geschehen ist, starten Sie mit der Konfiguration. Damit das Deployment über Clustergrenzen hinweg bekannt ist, stellt Google einen dedizierten Multi-Cluster-Service-Ressource-Typ bereit, mit dessen Hilfe Sie einen gemeinsamen Dienst für alle Cluster erzeugen. Dieser Service nutzt einen zentralen API-Server für die Cluster-Konfiguration. Das Beispielmanifest aus Listing 3 zeigt einen Multi-Cluster-Service für eine Anwendung namens "foo", das auf jedem Knoten einen Service mit dem Selektor "app:foo" bereitstellt.
Listing 3: Beispielmanifest für Multi-Cluster-Service
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: foo
namespace: blue
spec:
template:
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
Anschließend lässt sich Multi-Cluster-Ingress bereitstellen. Das erste Manifest gleicht in vielerlei Hinsicht einem normalen Ingress, Listing 4 zeigt einen Ingress, der Traffic abhängig vom Host-Header an die Backends "foo" und "bar" weiterleitet.
Listing 4: Beispielmanifest für Ingress mit Traffic-Weiterleitung
apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
name: foobar-ingress
namespace: blue
spec:
template:
spec:
backend:
serviceName: default-backend
servicePort: 80
rules:
- host: foo.example.com
backend:
serviceName: foo
servicePort: 80
- host: bar.example.com
backend:
serviceName: bar
servicePort: 80
GKE Identity Service
In den letzten Jahren sind Multicloud-Umgebungen immer beliebter geworden. Eine große Hürde bei der Implementierung ist jedoch die Identitätsverwaltung, die möglichst zentral erfolgen sollte. In der Konsequenz bedeutet dies, dass dieselben Identitäten in jeder Cloud nutzbar sein sollen. Auf dieses Szenario zieht GKE Identity Service ab, mit dessen Hilfe User existierende Credentials behalten können und sich mit diesen im GKE-Cluster authentifizieren.
Dafür unterstützt Google OIDC, SAML und LDAP. Die Konfiguration selbst erfolgt auf Ebene der Flotte oder für einzelne Cluster und besteht aus zwei Schritten. Zuerst registrieren Sie den GKE Identity Service in Ihrem Zielanbieter und anschließend erledigen Sie das Einrichten auf Flotten- beziehungsweise Clusterebene.
Fazit
GKE Enterprise schafft mit dem Flotten-Mechanismus ein mächtiges Feature, mit dessen Hilfe IT-Verantwortliche einfach Enterprise Features über Clustergrenzen hinweg nutzen. Das Konzept ist durchdacht und bietet einen deutlichen Mehrwert hinsichtlich Verwaltbarkeit gegenüber den reinen Open-Source-Werkzeugen.
(jp)
Link-Codes
[1] Beispielanwendung Bookinfo: https://github.com/istio/istio/tree/master/samples/bookinfo