Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Vereinfachen Sie die Bereitstellung von Amazon EKS-Anwendungen für mehrere Mandanten mithilfe von Flux
*Nadeem Rahaman, Aditya Ambati, Aniket Dekate und Shrikant Patil, Amazon Web Services*
## Zusammenfassung
Viele Unternehmen, die Produkte und Dienstleistungen anbieten, sind 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 (Amazon EKS) verwenden können, um eine Datenplattform aufzubauen, die eine logische und physische Isolierung zwischen Mandanten oder Benutzern erreicht, die sich einen einzigen Amazon EKS-Cluster teilen. Das Muster bietet Isolierung durch die folgenden Ansätze:
+ 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](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
+ [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) Version 0.12 oder höher ist auf Ihrem lokalen Computer installiert
+ [Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest) Version 3.0.0 oder höher
+ [Kubernetes](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) Provider Version 2.10 oder höher
+ [Helm Provider Version 2.8.0](https://registry.terraform.io/providers/hashicorp/helm/latest/docs) oder höher
+ [Kubectl Provider](https://registry.terraform.io/providers/gavinbunney/kubectl/latest/docs) 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 CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)ist ein vollständig verwalteter Build-Service, der Ihnen hilft, Quellcode zu kompilieren, Komponententests durchzuführen und Artefakte zu erstellen, die sofort einsatzbereit sind.
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)ist ein Versionskontrolldienst, mit dem Sie Git-Repositorys privat speichern und verwalten können, ohne Ihr eigenes Quellcodeverwaltungssystem verwalten zu müssen.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)hilft 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 (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) können Sie Kubernetes ausführen, AWS ohne dass Sie Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten müssen.
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)ist ein zentraler Hub, der virtuelle private Clouds () und lokale Netzwerke verbindet. VPCs
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 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](https://cilium.io/use-cases/network-policy/#:~:text=Cilium%20implements%20Kubernetes%20Network%20Policies,%2C%20Kafka%2C%20gRPC%2C%20etc.) Kubernetes L3- und L4-Netzwerkrichtlinien. Sie können mit L7-Richtlinien erweitert werden, um Sicherheit auf API-Ebene für HTTP, Kafka und gRPC sowie andere ähnliche Protokolle bereitzustellen.
+ [Flux](https://fluxcd.io/) ist ein Git-basiertes Continuous Delivery (CD) -Tool, das Anwendungsbereitstellungen auf Kubernetes automatisiert.
+ [Helm](https://helm.sh/docs/) ist ein Open-Source-Paketmanager für Kubernetes, der Sie bei der Installation und Verwaltung von Anwendungen auf Ihrem Kubernetes-Cluster unterstützt.
+ [Terraform](https://www.terraform.io/) 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 [EKS Multi-Tenancy Terraform](https://github.com/aws-samples/aws-eks-multitenancy-deployment) Solution Repository verfügbar.
## Best Practices
Richtlinien und bewährte Methoden für die Verwendung dieser Implementierung finden Sie im Folgenden:
+ [Bewährte Methoden für Amazon EKS für mehrere Mandanten](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Flux-Dokumentation](https://fluxcd.io/flux/get-started/)
## Epen
### Erstellen Sie Pipelines für die Phasen Erstellen, Testen und Bereitstellen von Terraform
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Klonen Sie das Projekt-Repository. | Klonen Sie das GitHub [EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment) 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. | 1. Ö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-RegionS3_BUCKET_NAME=""
DYNAMODB_TABLE_NAME=""
REGION=""
2. 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.](#simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux-prereqs)cd bootstrap
./bootstrap.sh
| AWS DevOps |
| Aktualisieren Sie die `locals.tf` Dateien `run.sh` und. | 1. 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=""
DYNAMODB_TABLE_NAME="
2. Fügen Sie diese Werte in das `run.sh` Skript ein, das sich im Stammverzeichnis des Projekts befindet:BACKEND_BUCKET_ID=""
DYNAMODB_ID=""
3. 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
4. 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 -t init
./run.sh -m pipeline -e demo -r -t plan
./run.sh -m pipeline -e demo -r -t apply
| AWS DevOps |
### Erstellen Sie die Netzwerkinfrastruktur
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Starten Sie die Pipeline. | 1. Vergewissern Sie sich, dass in dem `templates` Ordner für die `buildspec` Dateien die folgende Variable gesetzt ist`network`:TF_MODULE_TO_BUILD: "network"
2. Starten Sie in der [CodePipeline Konsole](https://console.aws.amazon.com/codesuite/codepipeline/home) 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](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages):+ `validate`initialisiert Terraform, führt Terraform-Sicherheitsscans mithilfe der Tools [checkov und tfsec durch und lädt](https://www.checkov.io/) [die Scanberichte in den S3-Bucket](https://github.com/aquasecurity/tfsec) hoch.
+ `plan `zeigt den Terraform-Plan an und lädt den Plan in den S3-Bucket hoch.
+ `apply`wendet die Terraform-Planausgabe aus dem S3-Bucket an und erstellt Ressourcen. AWS
+ `destroy`entfernt 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 |
| Validieren Sie die über das Netzwerkmodul erstellten Ressourcen. | Vergewissern Sie sich, dass die folgenden AWS Ressourcen nach der erfolgreichen Bereitstellung der Pipeline erstellt wurden:+ Eine Ausgangs-VPC mit drei öffentlichen und drei privaten Subnetzen, einem Internet-Gateway und einem NAT-Gateway.
+ Eine 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 die Amazon EKS-Ausgangs-VPC mit einem Ziel-CIDR-Block von. `0.0.0.0/0` Dies ist erforderlich, VPCs um allen den ausgehenden Internetzugang über die Amazon EKS-Ausgangs-VPC zu ermöglichen. | AWS DevOps |
### Erstellen Sie die Recheninfrastruktur
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Update`locals.tf`, um den Zugriff des CodeBuild Projekts auf die VPC zu ermöglichen. | Um die Add-Ons für den privaten Amazon EKS-Cluster bereitzustellen, muss das CodeBuild Projekt an die Amazon EKS-VPC angehängt werden.1. Öffnen Sie in dem `demo/pipeline` Ordner die `locals.tf` Datei und setzen Sie die `vpc_enabled` Variable auf`true`.
2. 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 -tfcmd init
./run.sh -m pipeline -env demo -region -tfcmd plan
./run.sh -m pipeline -env demo -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` bis`compute`:TF_MODULE_TO_BUILD: "compute"
| AWS DevOps |
| Aktualisieren Sie die `values` Datei für das Helm-Diagramm für die Mandantenverwaltung. | 1. Ö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
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-Dateien der Mandantenanwendung 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:+ Amazon EKS-Cluster mit privatem Endpunkt
+ Amazon EKS-Worker-Knoten
+ Amazon EKS-Add-Ons: externe Geheimnisse`aws-loadbalancer-controller`, und `metrics-server`
+ GitOps Modul, Flux-Helm-Diagramm, Cilium-Helm-Diagramm und Helm-Diagramm für die Mandantenverwaltung | AWS DevOps |
### Schauen Sie sich die Mandantenverwaltung und andere Ressourcen an
| Aufgabe | Description | 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.1. Mandanten-Namespaces wurden erstellt, wie in: `values.yaml`kubectl get ns -A
2. Jedem Mandanten-Namespace werden Kontingente zugewiesen, wie in: `values.yaml`kubectl get quota --namespace=
3. Die Angaben zu den Kontingenten sind für jeden Mandanten-Namespace korrekt:kubectl describe quota cpu-memory-resource-quota-limit -n
4. 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.1. Flux kann eine Verbindung zu dem CodeCommit Repository herstellen, das im GitOps Modul angegeben ist:kubectl get gitrepositories -A
2. Der Flux-Kustomization-Controller hat die YAML-Dateien im Repository bereitgestellt: CodeCommit kubectl get kustomizations -A
3. Alle Anwendungsressourcen werden in ihren Mandanten-Namespaces bereitgestellt:kubectl get all -n
4. Für jeden Mandanten wurde ein Ingress erstellt:kubectl get ingress -n
| |
## 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:1. Ü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.
2. 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 auf`0`:deploy = 0
Nachdem Sie den `apply` Terraform-Befehl ausgeführt haben, ändern Sie den `deploy` Parameterwert wieder in: `1`deploy = 1
3. Ü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](https://fluxcd.io/flux/cheatsheets/troubleshooting/) zur Fehlerbehebung. |
## Zugehörige Ressourcen
+ [Amazon EKS Blueprints für Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints)
+ [Amazon EKS Best Practices-Leitfäden, Abschnitt Mehrmandantenfähigkeit](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Flux-Webseite](https://fluxcd.io/)
+ [Helm-Webseite](https://helm.sh/)
## 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
```