Cluster completamente privato EKS

eksctl supporta la creazione di cluster completamente privati che non hanno accesso a Internet in uscita e dispongono solo di sottoreti private. Gli endpoint VPC vengono utilizzati per consentire l'accesso privato ai servizi AWS.

Questa guida descrive come creare un cluster privato senza accesso a Internet in uscita.

Creazione di un cluster completamente privato

L'unico campo obbligatorio per creare un cluster completamente privato è: privateCluster.enabled

privateCluster:
  enabled: true

Dopo la creazione del cluster, i comandi eksctl che richiedono l'accesso al server API Kubernetes dovranno essere eseguiti dall'interno del VPC del cluster, da un VPC peered o utilizzando altri mezzi come AWS Direct Connect. I comandi eksctl che richiedono l'accesso a EKS non APIs funzioneranno se vengono eseguiti dall'interno del VPC del cluster. Per risolvere questo problema, crea un endpoint di interfaccia per Amazon EKS per accedere in modo privato alla gestione di Amazon Elastic Kubernetes Service (Amazon APIs EKS) dal tuo Amazon Virtual Private Cloud (VPC). In una versione futura, eksctl aggiungerà il supporto per creare questo endpoint in modo che non debba essere creato manualmente. I comandi che richiedono l'accesso all'URL del provider OpenID Connect dovranno essere eseguiti dall'esterno del VPC del cluster dopo aver abilitato AWS per PrivateLink Amazon EKS.

La creazione di gruppi di nodi gestiti continuerà a funzionare e la creazione di gruppi di nodi autogestiti funzionerà in quanto richiede l'accesso al server API tramite l'endpoint dell'interfaccia EKS se il comando viene eseguito dall'interno del VPC del cluster, da un VPC peer o utilizzando altri mezzi come AWS Direct Connect.

Nota

Gli endpoint VPC vengono addebitati su base oraria e in base all'utilizzo. Ulteriori dettagli sui prezzi sono disponibili nella pagina dei PrivateLink prezzi di AWS

avvertimento

I cluster completamente privati non sono supportati in. eu-south-1

Configurazione dell'accesso privato a servizi AWS aggiuntivi

Per consentire ai nodi di lavoro di accedere ai servizi AWS in modo privato, eksctl crea endpoint VPC per i seguenti servizi:

• Endpoint di interfaccia per ECR (entrambi ecr.api eecr.dkr) per estrarre le immagini dei contenitori (plug-in AWS CNI ecc.)

• Un endpoint gateway per S3 per estrarre i livelli effettivi dell'immagine

• Un endpoint di interfaccia EC2 richiesto dall'integrazione aws-cloud-provider

• Un endpoint di interfaccia per STS per supportare Fargate e IAM Roles for Services Accounts (IRSA)

• Un endpoint di interfaccia per CloudWatch logging (logs) se la registrazione è abilitata CloudWatch

Questi endpoint VPC sono essenziali per un cluster privato funzionale e, come tali, eksctl non supporta la configurazione o la disabilitazione. Tuttavia, un cluster potrebbe aver bisogno dell'accesso privato ad altri servizi AWS (ad esempio, l'Autoscaling richiesto dal Cluster Autoscaler). Questi servizi possono essere specificati inprivateCluster.additionalEndpointServices, che indica a eksctl di creare un endpoint VPC per ciascuno di essi.

Ad esempio, per consentire l'accesso privato alla scalabilità automatica e alla registrazione: CloudWatch

privateCluster:
  enabled: true
  additionalEndpointServices:
  # For Cluster Autoscaler
  - "autoscaling"
  # CloudWatch logging
  - "logs"

Gli endpoint supportati in sono, e. additionalEndpointServices autoscaling cloudformation logs

Ignorare le creazioni degli endpoint

Se è già stato creato un VPC con gli endpoint AWS necessari configurati e collegati alle sottoreti descritte nella documentazione EKS, eksctl puoi saltare la creazione fornendo l'opzione in questo modo: skipEndpointCreation

privateCluster:
  enabled: true
  skipEndpointCreation: true

Questa impostazione non può essere utilizzata insieme a. additionalEndpointServices Salterà tutta la creazione degli endpoint. Inoltre, questa impostazione è consigliata solo se la topologia della <→ sottorete dell'endpoint è configurata correttamente. Se gli ID di sottorete sono corretti, vpce il routing viene impostato con indirizzi prefissi, tutti gli endpoint EKS necessari vengono creati e collegati al VPC fornito. eksctlnon altererà nessuna di queste risorse.

Gruppi di nodi

Solo i gruppi di nodi privati (gestiti e autogestiti) sono supportati in un cluster completamente privato perché il VPC del cluster viene creato senza sottoreti pubbliche. Il privateNetworking campo (e) deve essere impostato in modo esplicito. nodeGroup[].privateNetworking managedNodeGroup[ È un errore lasciare privateNetworking unset in un cluster completamente privato.

nodeGroups:
- name: ng1
  instanceType: m5.large
  desiredCapacity: 2
  # privateNetworking must be explicitly set for a fully-private cluster
  # Rather than defaulting this field to `true`,
  # we require users to explicitly set it to make the behaviour
  # explicit and avoid confusion.
  privateNetworking: true

managedNodeGroups:
- name: m1
  instanceType: m5.large
  desiredCapacity: 2
  privateNetworking: true

Accesso all'endpoint del cluster

Un cluster completamente privato non supporta la modifica durante la creazione del cluster. clusterEndpointAccess È un errore impostarlo clusterEndpoints.publicAccess oppureclusterEndpoints.privateAccess, poiché un cluster completamente privato può avere solo accesso privato, e consentire la modifica di questi campi può compromettere il funzionamento del cluster.

VPC e sottoreti forniti dall'utente

eksctl supporta la creazione di cluster completamente privati utilizzando un VPC e sottoreti preesistenti. È possibile specificare solo sottoreti private ed è un errore specificare le sottoreti. vpc.subnets.public

eksctl crea endpoint VPC nel VPC fornito e modifica le tabelle di routing per le sottoreti fornite. Ogni sottorete dovrebbe avere una tabella di routing esplicita associata perché eksctl non modifica la tabella di route principale.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: private-cluster
  region: us-west-2

privateCluster:
  enabled: true
  additionalEndpointServices:
  - "autoscaling"

vpc:
  subnets:
    private:
      us-west-2b:
        id: subnet-0818beec303f8419b
      us-west-2c:
        id: subnet-0d42ef09490805e2a
      us-west-2d:
        id: subnet-0da7418077077c5f9


nodeGroups:
- name: ng1
  instanceType: m5.large
  desiredCapacity: 2
  # privateNetworking must be explicitly set for a fully-private cluster
  # Rather than defaulting this field to true for a fully-private cluster, we require users to explicitly set it
  # to make the behaviour explicit and avoid confusion.
  privateNetworking: true

managedNodeGroups:
- name: m1
  instanceType: m5.large
  desiredCapacity: 2
  privateNetworking: true

Gestire un cluster completamente privato

Affinché tutti i comandi funzionino dopo la creazione del cluster, eksctl avrà bisogno dell'accesso privato all'endpoint del server dell'API EKS e dell'accesso a Internet in uscita (for). EKS:DescribeCluster I comandi che non richiedono l'accesso al server API saranno supportati se eksctl dispone di un accesso a Internet in uscita.

Eliminazione forzata di un cluster completamente privato

È probabile che si verifichino degli errori quando si elimina un cluster completamente privato tramite eksctl poiché eksctl non ha automaticamente accesso a tutte le risorse del cluster. --forceesiste per risolvere questo problema: forzerà l'eliminazione del cluster e continuerà quando si verificano errori.

Limitazioni

Una limitazione dell'attuale implementazione è che eksctl inizialmente crea il cluster con l'accesso agli endpoint pubblico e privato abilitato e disabilita l'accesso pubblico agli endpoint dopo che tutte le operazioni sono state completate. Ciò è necessario perché eksctl deve accedere al server API Kubernetes per consentire ai nodi autogestiti di unirsi al cluster e supportare Fargate. GitOps Una volta completate queste operazioni, eksctl imposta l'accesso agli endpoint del cluster in modalità «solo privato». Questo aggiornamento aggiuntivo significa che la creazione di un cluster completamente privato richiederà più tempo rispetto a un cluster standard. In futuro, eksctl potrebbe passare a una funzione Lambda abilitata per VPC per eseguire queste operazioni API.

Accesso in uscita tramite server proxy HTTP

eksctl è in grado di comunicare con AWS APIs tramite un server proxy HTTP (S) configurato, tuttavia dovrai assicurarti di impostare correttamente l'elenco di esclusione dei proxy.

In genere, è necessario assicurarsi che le richieste per l'endpoint VPC per il cluster non vengano instradate tramite i proxy impostando una variabile di ambiente appropriata no_proxy che includa il valore. .eks.amazonaws.com

Se il tuo server proxy esegue l' «intercettazione SSL» e utilizzi IAM Roles for Service Accounts (IRSA), dovrai assicurarti di bypassare esplicitamente SSL per il dominio. Man-in-the-Middle oidc.<region>.amazonaws.com In caso contrario, eksctl otterrà l'impronta del certificato root errata per il provider OIDC e il plugin AWS VPC CNI non si avvierà perché non è in grado di ottenere le credenziali IAM, rendendo il cluster non operativo.

Ulteriori informazioni

• Cluster privati EKS