Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Semplifica la distribuzione di applicazioni multi-tenant Amazon EKS utilizzando Flux
*Nadeem Rahaman, Aditya Ambati, Aniket Dekate e Shrikant Patil, Amazon Web Services*
## Riepilogo
Molte aziende che offrono prodotti e servizi sono settori regolamentati dai dati, tenuti a mantenere le barriere relative ai dati tra le loro funzioni aziendali interne. Questo modello descrive come utilizzare la funzionalità multi-tenancy di Amazon Elastic Kubernetes Service (Amazon EKS) per creare una piattaforma dati che consenta l'isolamento logico e fisico tra tenant o utenti che condividono un singolo cluster Amazon EKS. Il modello fornisce l'isolamento attraverso i seguenti approcci:
+ Isolamento dello spazio dei nomi Kubernetes
+ Controllo degli accessi basato sui ruoli (RBAC)
+ Policy di rete
+ Quote delle risorse
+ AWS Identity and Access Management ruoli (IAM) per gli account di servizio (IRSA)
Inoltre, questa soluzione utilizza Flux per mantenere immutabile la configurazione del tenant durante la distribuzione delle applicazioni. È possibile distribuire le applicazioni tenant specificando il repository tenant che contiene il file Flux nella configurazione. `kustomization.yaml`
Questo modello implementa quanto segue:
+ Un AWS CodeCommit repository, AWS CodeBuild progetti e una AWS CodePipeline pipeline, creati distribuendo manualmente gli script Terraform.
+ Componenti di rete e di calcolo necessari per ospitare i tenant. Questi vengono creati tramite CodePipeline e CodeBuild utilizzando Terraform.
+ Namespace dei tenant, politiche di rete e quote di risorse, configurati tramite un grafico Helm.
+ Applicazioni che appartengono a tenant diversi, distribuite utilizzando Flux.
Ti consigliamo di pianificare e creare attentamente la tua architettura per la multi-tenancy in base ai tuoi requisiti unici e alle tue considerazioni di sicurezza. Questo modello fornisce un punto di partenza per l'implementazione.
## Prerequisiti e limitazioni
**Prerequisiti**
+ Un attivo Account AWS
+ AWS Command Line Interface [(AWS CLI) versione 2.11.4 o successiva, [installata](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e configurata](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
+ [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) versione 0.12 o successiva installata sul computer locale
+ [Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest) versione 3.0.0 o successiva
+ [Kubernetes Provider versione 2.10 o successiva](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs)
+ [Helm Provider versione 2.8.0](https://registry.terraform.io/providers/hashicorp/helm/latest/docs) o successiva
+ [Kubectl](https://registry.terraform.io/providers/gavinbunney/kubectl/latest/docs) Provider versione 1.14 o successiva
**Limitazioni**
+ **Dipendenza dalle distribuzioni manuali di Terraform:** la configurazione iniziale del flusso di lavoro, inclusa la creazione di CodeCommit repository, CodeBuild progetti e pipeline, si basa sulle implementazioni manuali di Terraform. CodePipeline Ciò introduce una potenziale limitazione in termini di automazione e scalabilità, poiché richiede un intervento manuale per le modifiche all'infrastruttura.
+ **CodeCommit dipendenza dal repository:** il flusso di lavoro si basa sui CodeCommit repository come soluzione di gestione del codice sorgente ed è strettamente associato a. Servizi AWS
## Architecture
**Architetture di destinazione**
Questo modello implementa tre moduli per creare la pipeline, la rete e l'infrastruttura di calcolo per una piattaforma dati, come illustrato nei diagrammi seguenti.
*Architettura della pipeline:*
*Architettura di rete:*
*Architettura di calcolo:*
## Tools (Strumenti)
**Servizi AWS**
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)è un servizio di compilazione completamente gestito che ti aiuta a compilare codice sorgente, eseguire test unitari e produrre artefatti pronti per la distribuzione.
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)è un servizio di controllo delle versioni che consente di archiviare e gestire in modo privato gli archivi Git, senza dover gestire il proprio sistema di controllo del codice sorgente.
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)ti aiuta a modellare e configurare rapidamente le diverse fasi di una versione del software e ad automatizzare i passaggi necessari per rilasciare continuamente le modifiche al software.
+ [Amazon Elastic Kubernetes Service (Amazon EKS) ti aiuta a eseguire Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) su AWS Kubernetes senza dover installare o gestire il tuo piano di controllo o i tuoi nodi Kubernetes.
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)è un hub centrale che collega cloud privati virtuali () e reti locali. VPCs
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) ti aiuta a lanciare AWS risorse in una rete virtuale che hai definito. Questa rete virtuale è simile a una comune rete da gestire all'interno del proprio data center, ma con i vantaggi dell'infrastruttura scalabile di AWS.
**Altri strumenti**
+ Le [politiche di rete Cilium supportano le politiche di rete](https://cilium.io/use-cases/network-policy/#:~:text=Cilium%20implements%20Kubernetes%20Network%20Policies,%2C%20Kafka%2C%20gRPC%2C%20etc.) Kubernetes L3 e L4. Possono essere estesi con policy L7 per fornire sicurezza a livello di API per HTTP, Kafka e gRPC e altri protocolli simili.
+ [Flux](https://fluxcd.io/) è uno strumento di distribuzione continua (CD) basato su Git che automatizza le implementazioni delle applicazioni su Kubernetes.
+ [Helm](https://helm.sh/docs/) è un gestore di pacchetti open source per Kubernetes che ti aiuta a installare e gestire le applicazioni sul tuo cluster Kubernetes.
+ [Terraform](https://www.terraform.io/) è uno strumento di infrastruttura come codice (IaC) HashiCorp che ti aiuta a creare e gestire risorse cloud e locali.
**Archivio di codici**
Il codice per questo pattern è disponibile nel repository GitHub [EKS Multi-Tenancy Terraform](https://github.com/aws-samples/aws-eks-multitenancy-deployment) Solution.
## Best practice
Per le linee guida e le migliori pratiche per l'utilizzo di questa implementazione, consulta quanto segue:
+ [Best practice per la multi-tenancy di Amazon EKS](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Documentazione Flux](https://fluxcd.io/flux/get-started/)
## Epiche
### Crea pipeline per le fasi di costruzione, test e distribuzione di Terraform
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Clona il repository del progetto. | Clona il repository GitHub [EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment) eseguendo il seguente comando in una finestra di terminale:git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
| AWS DevOps |
| Avvia il bucket Terraform S3 e Amazon DynamoDB. | 1. Nella `bootstrap` cartella, apri il `bootstrap.sh` file e aggiorna i valori delle variabili per il nome del bucket S3, il nome della tabella DynamoDB e: Regione AWSS3_BUCKET_NAME=""
DYNAMODB_TABLE_NAME=""
REGION=""
2. Eseguire lo script `bootstrap.sh`. [Lo script richiede il AWS CLI, che hai installato come parte dei prerequisiti.](#simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux-prereqs)cd bootstrap
./bootstrap.sh
| AWS DevOps |
| Aggiorna i `locals.tf` file `run.sh` and. | 1. Una volta completato correttamente il processo di bootstrap, copia il bucket S3 e il nome della tabella DynamoDB dalla sezione dello script: `variables` `bootstrap.sh`# Variables
S3_BUCKET_NAME=""
DYNAMODB_TABLE_NAME="
2. Incolla questi valori nello `run.sh` script, che si trova nella directory principale del progetto:BACKEND_BUCKET_ID=""
DYNAMODB_ID=""
3. Carica il codice del progetto in un CodeCommit repository. Puoi creare automaticamente questo repository tramite Terraform impostando la seguente variabile su `true` nel file: `demo/pipeline/locals.tf`create_new_repo = true
4. Aggiorna il `locals.tf` file in base alle tue esigenze per creare risorse di pipeline. | AWS DevOps |
| Implementa il modulo pipeline. | Per creare risorse di pipeline, esegui manualmente i seguenti comandi Terraform. Non esiste alcuna orchestrazione per l'esecuzione automatica di questi comandi../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 |
### Crea l'infrastruttura di rete
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Avvia la pipeline. | 1. Nella `templates` cartella, assicuratevi che per i `buildspec` file sia impostata la seguente variabile su: `network`TF_MODULE_TO_BUILD: "network"
2. Sulla [CodePipeline console](https://console.aws.amazon.com/codesuite/codepipeline/home), nella pagina dei dettagli della pipeline, avvia la pipeline scegliendo **Release** change.Dopo questa prima esecuzione, la pipeline si avvia automaticamente ogni volta che esegui una modifica al ramo principale del CodeCommit repository.
[La pipeline include le seguenti fasi:](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages)+ `validate`inizializza Terraform, esegue le scansioni di sicurezza Terraform utilizzando gli strumenti [checkov e [tfsec](https://github.com/aquasecurity/tfsec) e carica](https://www.checkov.io/) i report di scansione nel bucket S3.
+ `plan `mostra il piano Terraform e carica il piano nel bucket S3.
+ `apply`applica l'output del piano Terraform dal bucket S3 e crea risorse. AWS
+ `destroy`rimuove le AWS risorse create durante la fase. `apply` Per abilitare questa fase opzionale, imposta la seguente variabile su `true` nel `demo/pipeline/locals.tf` file:enable_destroy_stage = true
| AWS DevOps |
| Convalida le risorse create tramite il modulo di rete. | Verifica che le seguenti AWS risorse siano state create dopo la corretta implementazione della pipeline:+ Un VPC in uscita con tre sottoreti pubbliche e tre private, gateway Internet e gateway NAT.
+ Un VPC Amazon EKS con tre sottoreti private.
+ Tenant 1 e Tenant 2 VPCs con tre sottoreti private ciascuna.
+ Un gateway di transito con tutti gli allegati VPC e i percorsi verso ogni sottorete privata.
+ Un gateway di transito statico per il VPC di uscita Amazon EKS con un blocco CIDR di destinazione di. `0.0.0.0/0` Ciò è necessario per consentire a tutti di accedere VPCs a Internet in uscita tramite il VPC di uscita di Amazon EKS. | AWS DevOps |
### Crea l'infrastruttura di elaborazione
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Aggiorna `locals.tf` per consentire l'accesso del CodeBuild progetto al VPC. | Per distribuire i componenti aggiuntivi per il cluster privato Amazon EKS, il CodeBuild progetto deve essere collegato al VPC Amazon EKS.1. Nella `demo/pipeline` cartella, apri il `locals.tf` file e imposta la `vpc_enabled` variabile su. `true`
2. Esegui lo `run.sh` script per applicare le modifiche al modulo pipeline: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 |
| Aggiorna i `buildspec` file per creare il modulo di calcolo. | Nella `templates` cartella, in tutti i file `buildspec` YAML, imposta il valore della `TF_MODULE_TO_BUILD` variabile da a: `network` `compute`TF_MODULE_TO_BUILD: "compute"
| AWS DevOps |
| Aggiorna il `values` file per il diagramma Helm di gestione dei tenant. | 1. Aprire il `values.yaml` file nella seguente posizione:cd cfg-terraform/demo/compute/cfg-tenant-mgmt
Il file ha il seguente aspetto:---
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. Nelle `tenants` sezioni `global` e, aggiorna la configurazione in base alle tue esigenze:`tenantCloneBaseUrl`— Percorso del repository che ospita il codice per tutti i tenant (utilizziamo lo stesso repository Git per tutti i tenant)`repoSecret`— Segreto Kubernetes che contiene le chiavi SSH e gli host noti per l'autenticazione nel repository Git dei tenant globali`quotas`— Quote di risorse Kubernetes da applicare a ciascun tenant`flux path`— Percorso dei file YAML dell'applicazione tenant nel repository globale dei tenant | AWS DevOps |
| Convalida le risorse di calcolo. | Dopo aver aggiornato i file nei passaggi precedenti, si CodePipeline avvia automaticamente. Verifica che abbia creato le seguenti AWS risorse per l'infrastruttura di elaborazione:+ Cluster Amazon EKS con endpoint privato
+ Nodi di lavoro Amazon EKS
+ Componenti aggiuntivi Amazon EKS: segreti esterni `aws-loadbalancer-controller` e `metrics-server`
+ GitOps modulo, diagramma Flux Helm, diagramma Cilium Helm e tabella Helm per la gestione degli inquilini | AWS DevOps |
### Controlla la gestione dei tenant e altre risorse
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Convalida le risorse di gestione dei tenant in Kubernetes. | Esegui i seguenti comandi per verificare che le risorse di gestione dei tenant siano state create correttamente con l'aiuto di Helm.1. I namespace dei tenant sono stati creati, come specificato in: `values.yaml`kubectl get ns -A
2. Le quote vengono assegnate a ogni spazio dei nomi dei tenant, come specificato in: `values.yaml`kubectl get quota --namespace=
3. I dettagli delle quote sono corretti per ogni spazio dei nomi dei tenant:kubectl describe quota cpu-memory-resource-quota-limit -n
4. Le politiche di rete Cilium sono state applicate a ogni spazio dei nomi dei tenant:kubectl get CiliumNetworkPolicy -A
| AWS DevOps |
| Verifica le distribuzioni delle applicazioni tenant. | Esegui i seguenti comandi per verificare che le applicazioni tenant siano state distribuite.1. Flux è in grado di connettersi al CodeCommit repository specificato nel modulo: GitOps kubectl get gitrepositories -A
2. Il controller di personalizzazione Flux ha distribuito i file YAML nel repository: CodeCommit kubectl get kustomizations -A
3. Tutte le risorse dell'applicazione vengono distribuite nei relativi namespace dei tenant:kubectl get all -n
4. È stato creato un ingresso per ogni tenant:kubectl get ingress -n
| |
## risoluzione dei problemi
| Problema | Soluzione |
| --- | --- |
| Viene visualizzato un messaggio di errore simile al seguente:
`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.` | Segui questi passaggi per risolvere il problema:1. Verifica l'archivio delle applicazioni tenant: un repository vuoto o configurato in modo errato potrebbe causare l'errore. Assicurati che il repository dell'applicazione tenant contenga il codice richiesto.
2. Ridistribuisci il `tenant_mgmt` modulo: nel file di configurazione del `tenant_mgmt` modulo, individua il `app` blocco, quindi imposta il parametro su: `deploy` `0`deploy = 0
Dopo aver eseguito il `apply` comando Terraform, modifica nuovamente il valore del `deploy` parametro in: `1`deploy = 1
3. Ricontrolla lo stato: dopo aver eseguito i passaggi precedenti, utilizza il seguente comando per verificare se il problema persiste: kubectl get gitrepositories -A
[Se il problema persiste, valuta la possibilità di approfondire i log di Flux per maggiori dettagli o consulta la guida generale alla risoluzione dei problemi di Flux.](https://fluxcd.io/flux/cheatsheets/troubleshooting/) |
## Risorse correlate
+ [Progetti Amazon EKS per Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints)
+ [Guide alle best practice di Amazon EKS, sezione Multi-tenancy](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Sito web Flux](https://fluxcd.io/)
+ [Sito web Helm](https://helm.sh/)
## Informazioni aggiuntive
Ecco un esempio di struttura di repository per la distribuzione di applicazioni tenant:
```
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
```