Rete personalizzata CNI - Amazon EKS

Rete personalizzata CNI

Per impostazione predefinita, in caso di nuove interfacce di rete allocate per pod, ipamD usa la sottorete e i gruppi di sicurezza dell'interfaccia di rete elastica primaria del nodo. È possibile che i pod utilizzino un gruppo di sicurezza o una sottorete diversa all'interno dello stesso VPC del gruppo di sicurezza del piano di controllo. Ad esempio:

  • In una sottorete è disponibile un numero limitato di indirizzi IP. Ciò limita il numero di pod che possono essere creati nel cluster. L'uso di sottoreti diverse per i pod consente di aumentare il numero di indirizzi IP disponibili.

  • Per motivi di sicurezza, i pod devono usare sottoreti o gruppi di sicurezza diversi rispetto all'interfaccia di rete principale del nodo.

  • I nodi sono configurati in sottoreti pubbliche e i pod devono essere collocati in sottoreti private utilizzando un gateway NAT. Per ulteriori informazioni, consulta . Source Network Address Translation (SNAT) esterna.

Considerazioni

  • Le procedure discusse in questo argomento richiedono il plug-in CNI di Amazon VPC per Kubernetes versione 1.6.3-eksbuild.1 o successiva.

  • L'abilitazione di una rete personalizzata rimuove un'interfaccia di rete elastica disponibile (e tutti i relativi indirizzi IP disponibili per i pod) da ogni nodo che la utilizza. L'interfaccia di rete principale per il nodo non viene usata per il posizionamento dei pod quando è abilitata una rete custom.

  • La procedura descritta in questo argomento indica al plug-in CNI di Amazon VPC di associare diversi gruppi di sicurezza alle interfacce di rete secondarie rispetto a quelle associate all'interfaccia di rete primaria nell'istanza. Tutti i pod che utilizzano le interfacce di rete secondarie condividono ancora l'uso delle interfacce di rete secondarie e utilizzano tutti gli stessi gruppi di sicurezza.

    Se si desidera assegnare diversi gruppi di sicurezza ai singoli pod, è possibile utilizzare Gruppi di sicurezza per pod. I gruppi di sicurezza per i pod creano interfacce di rete aggiuntive e a ciascuna di esse è possibile assegnare a ciascuno un gruppo di sicurezza univoco. I gruppi di sicurezza per i pod possono essere utilizzati con o senza rete personalizzata.

  • Non è possibile utilizzare la rete personalizzata se il cluster è stato creato per utilizzare la famiglia IPv6. Se si prevede di utilizzare una rete personalizzata per alleviare l'esaurimento dell'indirizzo IP, è invece possibile utilizzare IPv6. Per ulteriori informazioni, consulta . Assegnazione di indirizzi IPv6 ai pod e ai servizi.

Per configurare la rete CNI personalizzata

  1. Confermare che la versione del plug-in CNI di Amazon VPC attualmente installata sia 1.6.3-eksbuild.1 o successiva.

    kubectl describe daemonset aws-node \ --namespace kube-system | grep Image | cut -d "/" -f 2

    Output:

    amazon-k8s-cni:1.6.3-eksbuild.1

    Se la versione è precedente alla 1.6.3-eksbuild.1, è necessario aggiornarla. Per ulteriori informazioni, consultare le sezioni sugli aggiornamenti di Gestione del componente aggiuntivo CNI di Amazon VPC.

  2. Associare un blocco CIDR secondario al VPC del cluster. Per ulteriori informazioni, consultare Associazione di un blocco CIDR IPv4 secondario al VPC nella Guida per l'utente Amazon VPC.

  3. Creare una sottorete nel VPC per ogni zona di disponibilità, usando il blocco CIDR secondario. Le sottoreti personalizzate devono appartenere ad un blocco CIDR del VPC diversi rispetto alla sottorete in cui i nodi di lavoro sono stati avviati. Per ulteriori informazioni, consultare Creazione di una sottorete nel VPC nella Guida per l'utente di Amazon VPC.

  4. Impostare la variabile di ambiente AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG su true nel DaemonSet aws-node:

    kubectl set env daemonset aws-node \ -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  5. Creare una risorsa personalizzata ENIConfig per ogni sottorete in cui si desidera pianificare i pod.

    1. Creare un file univoco per ogni configurazione di interfaccia di rete. Ogni file deve includere i contenuti di seguito con un valore univoco per name. Si consiglia vivamente di utilizzare un valore per name corrispondente alla zona di disponibilità della sottorete, in quanto ciò rende più semplice la distribuzione dei gruppi di Auto Scaling multi-AZ (vedere la fase 5c più avanti).

      In questo esempio viene creato un file denominato us-west-2a.yaml. Sostituire i valori di esempio con i propri valori. In questo esempio, seguiamo le best practice e impostiamo il valore per name sulla zona di disponibilità in cui si trova la sottorete. Se non si dispone di un determinato gruppo di sicurezza da collegare per i pod, è possibile lasciare vuoto il valore per ora. In seguito, sarà possibile specificare il gruppo di sicurezza del nodo di lavoro in ENIConfig.

      apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: us-west-2a spec: securityGroups: - sg-0dff111a1d11c1c11 subnet: subnet-011b111c1f11fdf11
      Nota
      • Ogni combinazione di sottorete e gruppo di sicurezza richiede una risorsa personalizzata propria. Se si dispone di più sottoreti nella stessa zona di disponibilità, utilizzare il comando seguente per annotare i nodi in ogni sottorete con il nome di configurazione corrispondente.

        kubectl annotate node \ node-name.region-code.compute.internal \ k8s.amazonaws.com/eniConfig=subnet1ConfigName
      • Se non si specifica un gruppo di sicurezza valido per il VPC e si utilizza la versione 1.8.0 o successiva del plug-in CNI VPC, vengono impiegati i gruppi di sicurezza associati all'interfaccia di rete elastica principale del nodo. Se si utilizza una versione del plug-in precedente alla 1.8.0, il gruppo di sicurezza di default per il VPC viene assegnato alle interfacce di rete elastiche secondarie.

    2. Applicare ogni file delle risorse personalizzato creato in precedenza al cluster con il comando seguente:

      kubectl apply -f us-west-2a.yaml
    3. (Facoltativo, ma consigliato per i gruppi di nodi di lavoro multi-AZ) Per impostazione predefinita, Kubernetes applica la zona di disponibilità di un nodo all'etichetta topology.kubernetes.io/zone. Se sono state denominate le risorse personalizzate ENIConfig in base alle zone di disponibilità nel VPC, come consigliato nella fase 5a, è possibile abilitare Kubernetes per applicare automaticamente le ENIConfig corrispondenti per ogni zona di disponibilità del nodo con il comando seguente.

      kubectl set env daemonset aws-node \ -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone
      Nota

      Assicurarsi che un'annotazione con la chiave k8s.amazonaws.com/eniConfig per la variabile di ambiente ENI_CONFIG_ANNOTATION_DEF non esista nelle specifiche del container per il DaemonSet aws-node. Se esiste, sovrascrive il valore ENI_CONFIG_LABEL_DEF e deve essere rimossa. È possibile verificare se la variabile è impostata con il comando kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF. Se non viene restituito alcun output, la variabile non viene impostata.

  6. Se si prevede di implementare un gruppo di nodi gestito senza un modello di avvio o con un modello di avvio in cui non è stato specificato un ID AMI, passare al passaggio 7 e utilizzare l'opzione Gestito, senza un modello di avvio o con un modello di avvio senza un ID AMI specificato. I gruppi di nodi gestiti calcolano automaticamente il valore massimo dei pod.

    Se si sta implementando un gruppo di nodi autogestito o un gruppo di nodi gestito con un modello di avvio in cui è specificato un ID AMI, è necessario determinare il numero massimo di pod consigliati da Amazon EKS per i nodi. Seguire le istruzioni riportate in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di pod, aggiungendo --cni-custom-networking-enabled al passaggio 3. Annotare l'output restituito per l'utilizzo in un passaggio successivo.

  7. Creare uno dei seguenti tipi di gruppi di nodi. Per ulteriori criteri di selezione dell'istanza, vedere Scelta di un tipo di istanza Amazon EC2. Per le opzioni che includono 20, sostituirlo con il valore del passaggio precedente (consigliato) o con il proprio valore.

    • Autogestito – Implementare il gruppo di nodi utilizzando le istruzioni contenute in Avvio di nodi Amazon Linux autogestiti. Non specificare le sottoreti specificate nelle risorseENIConfig implementate. Specificare il seguente testo per il parametro ArgomentidiBootstrap.

      --use-max-pods false --kubelet-extra-args '--max-pods=20'
    • Gestito – implementare il gruppo di nodi utilizzando una delle opzioni seguenti:

      • Senza un modello di avvio o con un modello di avvio senza un ID AMI specificato – Completare la procedura in Creazione di un gruppo di nodi gestiti. I gruppi di nodi gestiti calcolano automaticamente il valore massimo di pod consigliato da Amazon EKS.

      • Con un modello di avvio con un ID AMI specificato – nel modello di lancio, specificare un ID AMI ottimizzato per Amazon EKS o un'AMI personalizzata sviluppata con l'AMI ottimizzato Amazon EKS, quindi implementare il gruppo di nodi utilizzando un modello di avvio e fornire i seguenti dati utente nel modello di avvio. Questi dati utente passano argomenti nel file bootstrap.sh. Per ulteriori informazioni sul file bootstrap, consultare bootstrap.sh su GitHub.

        /etc/eks/bootstrap.sh my-cluster \ --use-max-pods false \ --kubelet-extra-args '--max-pods=20'

        Se si è creata un'AMI personalizzata che non è stata sviluppata con l'AMI ottimizzata Amazon EKS, bisogna creare autonomamente la configurazione.

    Nota

    Se si desidera che i nodi supportino un numero significativamente maggiore di pod, eseguire nuovamente lo script in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di pod, aggiungendo --cni-prefix-delegation-enabled l'opzione al comando. Ad esempio, 110 viene restituito per un tipo di istanza m5.large. Per abilitare questa funzionalità, vedere Aumentare la quantità di indirizzi IP disponibili per i nodi Amazon EC2. É possibile usare questa

    funzionalità con reti personalizzate.

  8. Dopo aver creato il gruppo di nodi, registrare il gruppo di sicurezza creato per la sottorete e applicarlo alla risorsa associata ENIConfig. Modificare ciascun ENIConfig con il seguente comando, sostituendo eniconfig-name con il proprio valore:

    kubectl edit eniconfig.crd.k8s.amazonaws.com/eniconfig-name

    Se sono state seguite le best practice nel passaggio 5, il eniconfig-name corrisponde al nome della zona di disponibilità.

    La sezione spec sarà simile all'esempio seguente:

    spec: securityGroups: - sg-0dff222a2d22c2c22 subnet: subnet-022b222c2f22fdf22
    Nota

    Se si utilizza il gruppo di sicurezza creato, assicurarsi che siano soddisfatte le impostazioni del gruppo di sicurezza consigliate o minime richieste per i gruppi di sicurezza del cluster, del piano di controllo e del nodo. Per ulteriori informazioni, consulta . Considerazioni relative al gruppo di sicurezza Amazon EKS.

  9. Se nel cluster sono presenti nodi con pod in esecuzione prima di passare alla funzionalità di rete CNI personalizzata, è necessario isolare ed espellere i nodi per arrestare correttamente i pod e quindi terminare i nodi. Solo i nuovi nodi registrati con l'etichetta k8s.amazonaws.com/eniConfig useranno la nuova funzionalità di rete personalizzata.