Vereinfachen Sie die Bereitstellung von Amazon EKS Multi-Tenant-Anwendungen mithilfe von Flux

PDF

Erstellt von Nadeem Rahaman (AWS), Aditya Ambati (), Aniket Dekate () und Shrikant Patil (AWS) AWS AWS

Übersicht

AWS CodeCommit Hinweis: ist für Neukunden nicht mehr verfügbar. Bestandskunden von AWS CodeCommit können den Service weiterhin wie gewohnt nutzen. Weitere Informationen

Bei vielen Unternehmen, die Produkte und Dienstleistungen anbieten, handelt es sich um datenregulierte Branchen, die Datenbarrieren zwischen ihren internen Geschäftsfunktionen aufrechterhalten müssen. Dieses Muster beschreibt, wie Sie die Multi-Tenancy-Funktion in Amazon Elastic Kubernetes Service (AmazonEKS) verwenden können, um eine Datenplattform aufzubauen, die eine logische und physische Isolierung zwischen Mandanten oder Benutzern erreicht, die sich einen einzigen Amazon-Cluster teilen. EKS Das Muster sorgt mit den folgenden Ansätzen für Isolierung:

• Isolierung des Kubernetes-Namespaces

• Rollenbasierte Zugriffskontrolle () RBAC

• Netzwerkrichtlinien

• Ressourcenkontingente

• AWS Identity and Access Management (IAM) Rollen für Dienstkonten () IRSA

Darüber hinaus verwendet diese Lösung Flux, um die Mandantenkonfiguration bei der Bereitstellung von Anwendungen unveränderlich zu halten. Sie können Ihre Mandantenanwendungen bereitstellen, indem Sie in Ihrer Konfiguration das Mandanten-Repository angeben, das die kustomization.yaml Flux-Datei enthält.

Dieses Muster implementiert Folgendes:

• Ein AWS CodeCommit Repository, AWS CodeBuild Projekte und eine AWS CodePipeline Pipeline, die durch manuelles Bereitstellen von Terraform-Skripten erstellt werden.

• Netzwerk- und Rechenkomponenten, die für das Hosting der Mandanten erforderlich sind. Diese werden durch CodePipeline und mithilfe CodeBuild von Terraform erstellt.

• Mandanten-Namespaces, Netzwerkrichtlinien und Ressourcenkontingente, die anhand eines Helm-Diagramms konfiguriert werden.

• Anwendungen, die verschiedenen Mandanten gehören und mithilfe von Flux bereitgestellt werden.

Wir empfehlen Ihnen, Ihre eigene Architektur für Mehrmandantenfähigkeit auf der Grundlage Ihrer individuellen Anforderungen und Sicherheitsüberlegungen sorgfältig zu planen und zu erstellen. Dieses Muster bietet einen Ausgangspunkt für Ihre Implementierung.

Voraussetzungen und Einschränkungen

Voraussetzungen

• Ein aktiver AWS-Konto

• AWS Command Line Interface (AWS CLI) Version 2.11.4 oder höher, installiert und konfiguriert

• Terraform Version 0.12 oder höher ist auf Ihrem lokalen Computer installiert

• Terraform AWS Provider Version 3.0.0 oder höher

• Kubernetes Provider Version 2.10 oder höher

• Helm Provider Version 2.8.0 oder höher

• Kubectl Provider Version 1.14 oder höher

Einschränkungen

• Abhängigkeit von manuellen Terraform-Bereitstellungen: Die anfängliche Einrichtung des Workflows, einschließlich der Erstellung von CodeCommit Repositorys, CodeBuild Projekten und CodePipeline Pipelines, basiert auf manuellen Terraform-Bereitstellungen. Dies führt zu potenziellen Einschränkungen in Bezug auf Automatisierung und Skalierbarkeit, da bei Infrastrukturänderungen manuelle Eingriffe erforderlich sind.

• CodeCommit Abhängigkeit von Repositorys: Der Workflow stützt sich auf CodeCommit Repositorien als Lösung für die Quellcodeverwaltung und ist eng mit AWS-Services diesen verknüpft.

Architektur

Zielarchitekturen

Dieses Muster setzt drei Module zum Aufbau der Pipeline-, Netzwerk- und Recheninfrastruktur für eine Datenplattform ein, wie in den folgenden Diagrammen dargestellt.

Pipeline-Architektur:

Netzwerkarchitektur:

Rechenarchitektur:

Tools

AWS-Services

• AWS CodeBuildist ein vollständig verwalteter Build-Service, der Ihnen hilft, Quellcode zu kompilieren, Komponententests durchzuführen und Artefakte zu erstellen, die sofort einsatzbereit sind.

• AWS CodeCommitist ein Versionskontrolldienst, mit dem Sie Git-Repositorys privat speichern und verwalten können, ohne Ihr eigenes Quellcodeverwaltungssystem verwalten zu müssen.

• AWS CodePipelinehilft Ihnen dabei, die verschiedenen Phasen einer Softwareversion schnell zu modellieren und zu konfigurieren und die Schritte zu automatisieren, die für die kontinuierliche Veröffentlichung von Softwareänderungen erforderlich sind.

• Mit Amazon Elastic Kubernetes Service (AmazonEKS) können Sie Kubernetes ausführen, AWS ohne dass Sie Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten müssen.

• AWS Transit Gatewayist ein zentraler Hub, der virtuelle private Clouds () und lokale Netzwerke verbindet. VPCs

• Amazon Virtual Private Cloud (AmazonVPC) hilft Ihnen dabei, AWS Ressourcen in einem von Ihnen definierten virtuellen Netzwerk bereitzustellen. Dieses virtuelle Netzwerk entspricht einem herkömmlichen Netzwerk, wie Sie es in Ihrem Rechenzentrum betreiben würden, mit den Vorteilen der Verwendung der skalierbaren Infrastruktur von AWS.

Andere Tools

• Die Cilium-Netzwerkrichtlinien unterstützen die Kubernetes L3- und L4-Netzwerkrichtlinien. Sie können um L7-Richtlinien erweitert werden, um Sicherheit auf API Ebene für Kafka und G HTTP und andere ähnliche Protokolle zu gewährleisten. RPC

• Flux ist ein Git-basiertes Continuous Delivery (CD) -Tool, das Anwendungsbereitstellungen auf Kubernetes automatisiert.

• Helm ist ein Open-Source-Paketmanager für Kubernetes, der Sie bei der Installation und Verwaltung von Anwendungen auf Ihrem Kubernetes-Cluster unterstützt.

• Terraform ist ein IaC-Tool (Infrastructure as Code), mit dem Sie Cloud- und lokale HashiCorp Ressourcen erstellen und verwalten können.

Code-Repository

Der Code für dieses Muster ist im GitHub EKSMulti-Tenancy Terraform Solution Repository verfügbar.

Bewährte Methoden

Richtlinien und bewährte Methoden für die Verwendung dieser Implementierung finden Sie im Folgenden:

• Bewährte Methoden EKS für Mehrmandantenfähigkeit bei Amazon

• Flux-Dokumentation

Epen

Erstellen Sie Pipelines für die Phasen Erstellen, Testen und Bereitstellen von Terraform

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Klonen Sie das Projekt-Repository.	Klonen Sie das GitHub EKSMulti-Tenancy Terraform Solution Repository, indem Sie den folgenden Befehl in einem Terminalfenster ausführen: git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git	AWS DevOps
Bootstrap für den Terraform S3-Bucket und Amazon DynamoDB.	Öffnen Sie in dem bootstrap Ordner die bootstrap.sh Datei und aktualisieren Sie die Variablenwerte für den S3-Bucket-Namen, den DynamoDB-Tabellennamen und: AWS-Region S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME>" REGION="<AWS_REGION>" Führen Sie das bootstrap.sh-Skript aus. Für das Skript ist der erforderlich AWS CLI, den Sie als Teil der Voraussetzungen installiert haben. cd bootstrap ./bootstrap.sh	AWS DevOps
Aktualisieren Sie die locals.tf Dateien run.sh und.	Nachdem der Bootstrap-Vorgang erfolgreich abgeschlossen wurde, kopieren Sie den Namen des S3-Buckets und der DynamoDB-Tabelle aus dem variables Abschnitt des Skripts: bootstrap.sh # Variables S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME" Fügen Sie diese Werte in das run.sh Skript ein, das sich im Stammverzeichnis des Projekts befindet: BACKEND_BUCKET_ID="<SAME_NAME_AS_S3_BUCKET_NAME>" DYNAMODB_ID="<SAME_NAME_AS_DYNAMODB_NAME>" Laden Sie den Projektcode in ein CodeCommit Repository hoch. Sie können dieses Repository automatisch über Terraform erstellen, indem Sie die folgende Variable true in der demo/pipeline/locals.tf Datei auf setzen: create_new_repo = true Aktualisieren Sie die locals.tf Datei gemäß Ihren Anforderungen, um Pipeline-Ressourcen zu erstellen.	AWS DevOps
Stellen Sie das Pipeline-Modul bereit.	Führen Sie die folgenden Terraform-Befehle manuell aus, um Pipeline-Ressourcen zu erstellen. Es gibt keine Orchestrierung für die automatische Ausführung dieser Befehle. ./run.sh -m pipeline -e demo -r <AWS_REGION> -t init ./run.sh -m pipeline -e demo -r <AWS_REGION> -t plan ./run.sh -m pipeline -e demo -r <AWS_REGION> -t apply	AWS DevOps

Erstellen Sie Pipelines für die Phasen Erstellen, Testen und Bereitstellen von Terraform

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Klonen Sie das Projekt-Repository.	Klonen Sie das GitHub EKSMulti-Tenancy Terraform Solution Repository, indem Sie den folgenden Befehl in einem Terminalfenster ausführen: git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git	AWS DevOps
Bootstrap für den Terraform S3-Bucket und Amazon DynamoDB.	Öffnen Sie in dem bootstrap Ordner die bootstrap.sh Datei und aktualisieren Sie die Variablenwerte für den S3-Bucket-Namen, den DynamoDB-Tabellennamen und: AWS-Region S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME>" REGION="<AWS_REGION>" Führen Sie das bootstrap.sh-Skript aus. Für das Skript ist der erforderlich AWS CLI, den Sie als Teil der Voraussetzungen installiert haben. cd bootstrap ./bootstrap.sh	AWS DevOps
Aktualisieren Sie die locals.tf Dateien run.sh und.	Nachdem der Bootstrap-Vorgang erfolgreich abgeschlossen wurde, kopieren Sie den Namen des S3-Buckets und der DynamoDB-Tabelle aus dem variables Abschnitt des Skripts: bootstrap.sh # Variables S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME" Fügen Sie diese Werte in das run.sh Skript ein, das sich im Stammverzeichnis des Projekts befindet: BACKEND_BUCKET_ID="<SAME_NAME_AS_S3_BUCKET_NAME>" DYNAMODB_ID="<SAME_NAME_AS_DYNAMODB_NAME>" Laden Sie den Projektcode in ein CodeCommit Repository hoch. Sie können dieses Repository automatisch über Terraform erstellen, indem Sie die folgende Variable true in der demo/pipeline/locals.tf Datei auf setzen: create_new_repo = true Aktualisieren Sie die locals.tf Datei gemäß Ihren Anforderungen, um Pipeline-Ressourcen zu erstellen.	AWS DevOps
Stellen Sie das Pipeline-Modul bereit.	Führen Sie die folgenden Terraform-Befehle manuell aus, um Pipeline-Ressourcen zu erstellen. Es gibt keine Orchestrierung für die automatische Ausführung dieser Befehle. ./run.sh -m pipeline -e demo -r <AWS_REGION> -t init ./run.sh -m pipeline -e demo -r <AWS_REGION> -t plan ./run.sh -m pipeline -e demo -r <AWS_REGION> -t apply	AWS DevOps

Erstellen Sie die Netzwerkinfrastruktur

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Starten Sie die Pipeline.	Vergewissern Sie sich, dass in dem templates Ordner für die buildspec Dateien die folgende Variable gesetzt istnetwork: TF_MODULE_TO_BUILD: "network" Starten Sie in der CodePipeline Konsole auf der Seite mit den Pipeline-Details die Pipeline, indem Sie Änderung veröffentlichen auswählen. Nach dieser ersten Ausführung wird die Pipeline automatisch gestartet, wenn Sie eine Änderung an den Hauptzweig des CodeCommit Repositorys übertragen. Die Pipeline umfasst die folgenden Phasen: validateinitialisiert Terraform, führt Terraform-Sicherheitsscans mithilfe der Tools checkov und tfsec durch und lädt die Scanberichte in den S3-Bucket hoch. plan zeigt den Terraform-Plan an und lädt den Plan in den S3-Bucket hoch. applywendet die Terraform-Planausgabe aus dem S3-Bucket an und erstellt Ressourcen. AWS destroyentfernt die während der Phase erstellten AWS Ressourcen. apply Um diese optionale Phase zu aktivieren, setzen Sie die folgende Variable true in der demo/pipeline/locals.tf Datei auf: enable_destroy_stage = true	AWS DevOps
Überprüfen Sie die über das Netzwerkmodul erstellten Ressourcen.	Vergewissern Sie sich, dass die folgenden AWS Ressourcen nach der erfolgreichen Bereitstellung der Pipeline erstellt wurden: Ein Ausgang VPC mit drei öffentlichen und drei privaten Subnetzen, einem Internet-Gateway und NAT einem Gateway. Ein Amazon EKS VPC mit drei privaten Subnetzen. Mandant 1 und Mandant 2 VPCs mit jeweils drei privaten Subnetzen. Ein Transit-Gateway mit allen VPC Anhängen und Routen zu jedem privaten Subnetz. Eine statische Transit-Gateway-Route für den EKS Amazon-Ausgang VPC mit einem CIDR Zielblock von0.0.0.0/0. Dies ist erforderlich, VPCs um allen den ausgehenden Internetzugang über den Amazon-Ausgang zu ermöglichenEKS. VPC	AWS DevOps

Erstellen Sie die Netzwerkinfrastruktur

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Starten Sie die Pipeline.	Vergewissern Sie sich, dass in dem templates Ordner für die buildspec Dateien die folgende Variable gesetzt istnetwork: TF_MODULE_TO_BUILD: "network" Starten Sie in der CodePipeline Konsole auf der Seite mit den Pipeline-Details die Pipeline, indem Sie Änderung veröffentlichen auswählen. Nach dieser ersten Ausführung wird die Pipeline automatisch gestartet, wenn Sie eine Änderung an den Hauptzweig des CodeCommit Repositorys übertragen. Die Pipeline umfasst die folgenden Phasen: validateinitialisiert Terraform, führt Terraform-Sicherheitsscans mithilfe der Tools checkov und tfsec durch und lädt die Scanberichte in den S3-Bucket hoch. plan zeigt den Terraform-Plan an und lädt den Plan in den S3-Bucket hoch. applywendet die Terraform-Planausgabe aus dem S3-Bucket an und erstellt Ressourcen. AWS destroyentfernt die während der Phase erstellten AWS Ressourcen. apply Um diese optionale Phase zu aktivieren, setzen Sie die folgende Variable true in der demo/pipeline/locals.tf Datei auf: enable_destroy_stage = true	AWS DevOps
Überprüfen Sie die über das Netzwerkmodul erstellten Ressourcen.	Vergewissern Sie sich, dass die folgenden AWS Ressourcen nach der erfolgreichen Bereitstellung der Pipeline erstellt wurden: Ein Ausgang VPC mit drei öffentlichen und drei privaten Subnetzen, einem Internet-Gateway und NAT einem Gateway. Ein Amazon EKS VPC mit drei privaten Subnetzen. Mandant 1 und Mandant 2 VPCs mit jeweils drei privaten Subnetzen. Ein Transit-Gateway mit allen VPC Anhängen und Routen zu jedem privaten Subnetz. Eine statische Transit-Gateway-Route für den EKS Amazon-Ausgang VPC mit einem CIDR Zielblock von0.0.0.0/0. Dies ist erforderlich, VPCs um allen den ausgehenden Internetzugang über den Amazon-Ausgang zu ermöglichenEKS. VPC	AWS DevOps

Erstellen Sie die Recheninfrastruktur

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Aktualisieren Sielocals.tf, um den Zugriff des CodeBuild Projekts auf die zu ermöglichenVPC.	Um die Add-Ons für den EKS privaten Amazon-Cluster bereitzustellen, muss das CodeBuild Projekt an Amazon angehängt werden EKSVPC. Öffnen Sie im demo/pipeline Ordner die locals.tf Datei und setzen Sie die vpc_enabled Variable auftrue. Führen Sie das run.sh Skript aus, um die Änderungen auf das Pipeline-Modul anzuwenden: demo/pipeline/locals.tf ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd init ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd plan ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd apply	AWS DevOps
Aktualisieren Sie die buildspec Dateien, um das Rechenmodul zu erstellen.	Setzen templates Sie im Ordner in allen buildspec YAML Dateien den Wert der TF_MODULE_TO_BUILD Variablen von network biscompute: TF_MODULE_TO_BUILD: "compute"	AWS DevOps
Aktualisieren Sie die values Datei für das Helm-Diagramm für die Mandantenverwaltung.	Öffnen Sie die values.yaml Datei am folgenden Speicherort: cd cfg-terraform/demo/compute/cfg-tenant-mgmt Die Datei sieht wie folgt aus: --- global: clusterRoles: operator: platform-tenant flux: flux-tenant-applier flux: tenantCloneBaseUrl: ${TEANT_BASE_URL} repoSecret: ${TENANT_REPO_SECRET} tenants: tenant-1: quotas: limits: cpu: 1 memory: 1Gi flux: path: overlays/tenant-1 tenant-2: quotas: limits: cpu: 1 memory: 2Gi flux: path: overlays/tenant-2 Aktualisieren Sie in den tenants Abschnitten global und die Konfiguration entsprechend Ihren Anforderungen: tenantCloneBaseUrl— Pfad zum Repository, das den Code für alle Mandanten hostet (wir verwenden dasselbe Git-Repository für alle Mandanten) repoSecret— Kubernetes-Secret, das die SSH Schlüssel und bekannten Hosts für die Authentifizierung beim globalen Mandanten-Git-Repository enthält quotas— Kubernetes-Ressourcenkontingente, die Sie für jeden Mandanten beantragen möchten flux path— Pfad zu den YAML Mandantenanwendungsdateien im globalen Mandanten-Repository	AWS DevOps
Validieren Sie die Rechenressourcen.	CodePipeline Startet automatisch, nachdem Sie die Dateien in den vorherigen Schritten aktualisiert haben. Vergewissern Sie sich, dass die folgenden AWS Ressourcen für die Recheninfrastruktur erstellt wurden: EKSAmazon-Cluster mit privatem Endpunkt EKSAmazon-Worker-Knoten EKSAmazon-Add-Ons: externe Geheimnisseaws-loadbalancer-controller, und metrics-server GitOps Modul, Flux-Helm-Diagramm, Cilium-Helm-Diagramm und Mandantenmanagement-Helm-Diagramm	AWS DevOps

Erstellen Sie die Recheninfrastruktur

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Aktualisieren Sielocals.tf, um den Zugriff des CodeBuild Projekts auf die zu ermöglichenVPC.	Um die Add-Ons für den EKS privaten Amazon-Cluster bereitzustellen, muss das CodeBuild Projekt an Amazon angehängt werden EKSVPC. Öffnen Sie im demo/pipeline Ordner die locals.tf Datei und setzen Sie die vpc_enabled Variable auftrue. Führen Sie das run.sh Skript aus, um die Änderungen auf das Pipeline-Modul anzuwenden: demo/pipeline/locals.tf ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd init ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd plan ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd apply	AWS DevOps
Aktualisieren Sie die buildspec Dateien, um das Rechenmodul zu erstellen.	Setzen templates Sie im Ordner in allen buildspec YAML Dateien den Wert der TF_MODULE_TO_BUILD Variablen von network biscompute: TF_MODULE_TO_BUILD: "compute"	AWS DevOps
Aktualisieren Sie die values Datei für das Helm-Diagramm für die Mandantenverwaltung.	Öffnen Sie die values.yaml Datei am folgenden Speicherort: cd cfg-terraform/demo/compute/cfg-tenant-mgmt Die Datei sieht wie folgt aus: --- global: clusterRoles: operator: platform-tenant flux: flux-tenant-applier flux: tenantCloneBaseUrl: ${TEANT_BASE_URL} repoSecret: ${TENANT_REPO_SECRET} tenants: tenant-1: quotas: limits: cpu: 1 memory: 1Gi flux: path: overlays/tenant-1 tenant-2: quotas: limits: cpu: 1 memory: 2Gi flux: path: overlays/tenant-2 Aktualisieren Sie in den tenants Abschnitten global und die Konfiguration entsprechend Ihren Anforderungen: tenantCloneBaseUrl— Pfad zum Repository, das den Code für alle Mandanten hostet (wir verwenden dasselbe Git-Repository für alle Mandanten) repoSecret— Kubernetes-Secret, das die SSH Schlüssel und bekannten Hosts für die Authentifizierung beim globalen Mandanten-Git-Repository enthält quotas— Kubernetes-Ressourcenkontingente, die Sie für jeden Mandanten beantragen möchten flux path— Pfad zu den YAML Mandantenanwendungsdateien im globalen Mandanten-Repository	AWS DevOps
Validieren Sie die Rechenressourcen.	CodePipeline Startet automatisch, nachdem Sie die Dateien in den vorherigen Schritten aktualisiert haben. Vergewissern Sie sich, dass die folgenden AWS Ressourcen für die Recheninfrastruktur erstellt wurden: EKSAmazon-Cluster mit privatem Endpunkt EKSAmazon-Worker-Knoten EKSAmazon-Add-Ons: externe Geheimnisseaws-loadbalancer-controller, und metrics-server GitOps Modul, Flux-Helm-Diagramm, Cilium-Helm-Diagramm und Mandantenmanagement-Helm-Diagramm	AWS DevOps

Sehen Sie sich die Mieterverwaltung und andere Ressourcen an

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Validieren Sie die Ressourcen für die Mandantenverwaltung in Kubernetes.	Führen Sie die folgenden Befehle aus, um zu überprüfen, ob die Ressourcen für die Mandantenverwaltung erfolgreich mit Hilfe von Helm erstellt wurden. Mandanten-Namespaces wurden erstellt, wie in: values.yaml kubectl get ns -A Jedem Mandanten-Namespace werden Kontingente zugewiesen, wie in: values.yaml kubectl get quota --namespace=<tenant_namespace> Die Angaben zu den Kontingenten sind für jeden Mandanten-Namespace korrekt: kubectl describe quota cpu-memory-resource-quota-limit -n <tenant_namespace> Die Cilium-Netzwerkrichtlinien wurden auf jeden Mandanten-Namespace angewendet: kubectl get CiliumNetworkPolicy -A	AWS DevOps
Überprüfen Sie die Bereitstellungen von Mandantenanwendungen.	Führen Sie die folgenden Befehle aus, um zu überprüfen, ob die Mandantenanwendungen bereitgestellt wurden. Flux kann eine Verbindung zu dem CodeCommit Repository herstellen, das im GitOps Modul angegeben ist: kubectl get gitrepositories -A Der Flux-Kustomization-Controller hat die YAML Dateien im CodeCommit Repository bereitgestellt: kubectl get kustomizations -A Alle Anwendungsressourcen werden in ihren Mandanten-Namespaces bereitgestellt: kubectl get all -n <tenant_namespace> Für jeden Mandanten wurde ein Ingress erstellt: kubectl get ingress -n <tenant_namespace>

Sehen Sie sich die Mieterverwaltung und andere Ressourcen an

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Validieren Sie die Ressourcen für die Mandantenverwaltung in Kubernetes.	Führen Sie die folgenden Befehle aus, um zu überprüfen, ob die Ressourcen für die Mandantenverwaltung erfolgreich mit Hilfe von Helm erstellt wurden. Mandanten-Namespaces wurden erstellt, wie in: values.yaml kubectl get ns -A Jedem Mandanten-Namespace werden Kontingente zugewiesen, wie in: values.yaml kubectl get quota --namespace=<tenant_namespace> Die Angaben zu den Kontingenten sind für jeden Mandanten-Namespace korrekt: kubectl describe quota cpu-memory-resource-quota-limit -n <tenant_namespace> Die Cilium-Netzwerkrichtlinien wurden auf jeden Mandanten-Namespace angewendet: kubectl get CiliumNetworkPolicy -A	AWS DevOps
Überprüfen Sie die Bereitstellungen von Mandantenanwendungen.	Führen Sie die folgenden Befehle aus, um zu überprüfen, ob die Mandantenanwendungen bereitgestellt wurden. Flux kann eine Verbindung zu dem CodeCommit Repository herstellen, das im GitOps Modul angegeben ist: kubectl get gitrepositories -A Der Flux-Kustomization-Controller hat die YAML Dateien im CodeCommit Repository bereitgestellt: kubectl get kustomizations -A Alle Anwendungsressourcen werden in ihren Mandanten-Namespaces bereitgestellt: kubectl get all -n <tenant_namespace> Für jeden Mandanten wurde ein Ingress erstellt: kubectl get ingress -n <tenant_namespace>

Fehlerbehebung

Problem

Lösung

Sie erhalten eine Fehlermeldung, die der folgenden ähnelt: Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.

Gehen Sie wie folgt vor, um das Problem zu beheben: Überprüfen Sie das Mandantenanwendungs-Repository: Ein leeres oder falsch konfiguriertes Repository könnte den Fehler verursachen. Stellen Sie sicher, dass das Mandantenanwendungs-Repository den erforderlichen Code enthält. Stellen Sie das tenant_mgmt Modul erneut bereit: Suchen Sie in der tenant_mgmt Modulkonfigurationsdatei nach dem app Block und setzen Sie den deploy Parameter auf0: deploy = 0 Nachdem Sie den apply Terraform-Befehl ausgeführt haben, ändern Sie den deploy Parameterwert wieder in: 1 deploy = 1 Überprüfen Sie den Status erneut: Nachdem Sie die vorherigen Schritte ausgeführt haben, überprüfen Sie mit dem folgenden Befehl, ob das Problem weiterhin besteht:  kubectl get gitrepositories -A Wenn das Problem weiterhin besteht, sollten Sie sich eingehender mit den Flux-Protokollen befassen, um weitere Informationen zu erhalten, oder lesen Sie den allgemeinen Flux-Leitfaden zur Fehlerbehebung.

Zugehörige Ressourcen

• Amazon EKS Blueprints für Terraform

• Amazon EKS Best Practices Guides, Abschnitt Multi-Tenancy

• Flux-Webseite

• Helm-Webseite

Zusätzliche Informationen

Hier ist ein Beispiel für eine Repository-Struktur für die Bereitstellung von Mandantenanwendungen:

applications
sample_tenant_app
├── README.md
├── base
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── ingress.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
    ├── tenant-1
    │   ├── configmap.yaml
    │   ├── deployment.yaml
    │   └── kustomization.yaml
    └── tenant-2
        ├── configmap.yaml
        └── kustomization.yaml