Semplifica la distribuzione di applicazioni multi-tenant Amazon EKS utilizzando Flux - Prontuario AWS

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

Creato da Nadeem Rahaman (AWS), Aditya Ambati (AWS), Aniket Dekate (AWS) e Shrikant Patil (AWS)

Archivio del codice: aws-eks-multitenancy-deployment

Ambiente: PoC o pilota

Tecnologie: DevOps; Contenitori e microservizi

Servizi AWS: AWS CodeBuild; AWS CodeCommit; AWS CodePipeline; Amazon EKS; Amazon VPC

Riepilogo

Molte aziende che offrono prodotti e servizi sono settori regolamentati dai dati e sono tenute 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

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 ai servizi. AWS

Architettura

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:

Infrastruttura di pipeline per l'architettura multi-tenant di Amazon EKS

Architettura di rete:

Infrastruttura di rete per l'architettura multi-tenant di Amazon EKS

Architettura di calcolo:

Infrastruttura di elaborazione per l'architettura multi-tenant di Amazon EKS

Strumenti

Servizi AWS

  • AWS CodeBuildè 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è 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 CodePipelineti 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 AWS Kubernetes senza dover installare o gestire il tuo piano di controllo o i tuoi nodi Kubernetes.

  • AWS Transit Gateway: hub centrale che collega i cloud privati virtuali (VPC) e le reti on-premise.

  • Amazon Virtual Private Cloud (Amazon VPC) 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 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 è uno strumento di distribuzione continua (CD) basato su Git che automatizza le implementazioni delle applicazioni su Kubernetes.

  • Helm è un gestore di pacchetti open source per Kubernetes che ti aiuta a installare e gestire le applicazioni sul tuo cluster Kubernetes.

  • Terraform è 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 Solution.

Best practice

Per le linee guida e le migliori pratiche per l'utilizzo di questa implementazione, consulta quanto segue:

Epiche

AttivitàDescrizioneCompetenze richieste

Clona il repository del progetto.

Clona il repository GitHub EKS Multi-Tenancy Terraform Solution 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 AWS

    S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME>" REGION="<AWS_REGION>"
  2. Eseguire lo script bootstrap.sh. Lo script richiede il AWS CLI, che hai installato come parte dei prerequisiti.

    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="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME"
  2. Incolla questi valori nello run.sh script, che si trova nella directory principale del progetto:

    BACKEND_BUCKET_ID="<SAME_NAME_AS_S3_BUCKET_NAME>" DYNAMODB_ID="<SAME_NAME_AS_DYNAMODB_NAME>"
  3. Carica il codice del progetto in un CodeCommit repository. Puoi creare automaticamente questo repository tramite Terraform impostando la seguente variabile 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 <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
AttivitàDescrizioneCompetenze 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, 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:

  • validateinizializza Terraform, esegue le scansioni di sicurezza Terraform utilizzando gli strumenti checkov e tfsec e carica i report di scansione nel bucket S3.

  • plan mostra il piano Terraform e carica il piano nel bucket S3.

  • applyapplica l'output del piano Terraform dal bucket S3 e crea risorse. AWS

  • destroyrimuove 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.

  • VPC Tenant 1 e Tenant 2 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 i VPC di avere accesso a Internet in uscita tramite il VPC di uscita di Amazon EKS.

AWS DevOps
AttivitàDescrizioneCompetenze 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 <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

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
AttivitàDescrizioneCompetenze 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=<tenant_namespace>
  3. I dettagli delle quote sono corretti per ogni spazio dei nomi dei tenant:

    kubectl describe quota cpu-memory-resource-quota-limit -n <tenant_namespace>
  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 <tenant_namespace>
  4. È stato creato un ingresso per ogni tenant:

    kubectl get ingress -n <tenant_namespace>

Risoluzione dei problemi

ProblemaSoluzione

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 l'archivio delle applicazioni 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.

Risorse correlate

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