View a markdown version of this page

Prepara i cluster Amazon EKS locali su AWS Outposts per le disconnessioni di rete - Amazon EKS
Ottimizza il comportamento di failover dei pod KubernetesAutenticazione al cluster locale durante una disconnessione dalla rete

Contribuisci a migliorare questa pagina

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à.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

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à.

Prepara i cluster Amazon EKS locali su AWS Outposts per le disconnessioni di rete

Se la tua rete locale ha perso la connettività con il AWS cloud, puoi continuare a utilizzare il cluster Amazon EKS locale su un Outpost. Questo argomento illustra come preparare il cluster locale per le disconnessioni di rete e le considerazioni correlate.

  • I cluster locali garantiscono stabilità e operatività continua durante le disconnessioni di rete temporanee e non pianificate. AWS Outposts rimane un'offerta completamente connessa che funge da estensione del AWS Cloud nel tuo data center. In caso di disconnessioni di rete tra Outpost e AWS Cloud, ti consigliamo di provare a ripristinare la connessione. Per istruzioni, consulta l'elenco di controllo per la risoluzione dei problemi della rete rack AWS Outposts nella Guida per l'utente di Outposts AWS . Per informazioni su come risolvere i problemi con i cluster locali, consulta Risolvi i problemi relativi ai cluster Amazon EKS locali su Outposts AWS.

  • Gli Outpost emettono un parametro ConnectedStatus che puoi utilizzare per monitorare lo stato di connettività del tuo Outpost. Per ulteriori informazioni, consulta Outposts Metrics nella Guida per l'utente di Outposts AWS .

  • I cluster locali utilizzano IAM come meccanismo di autenticazione predefinito tramite AWS Identity and Access Management authenticator for Kubernetes. IAM non è disponibile durante le disconnessioni di rete. Pertanto, i cluster locali supportano un meccanismo di autenticazione alternativo basato sui certificati x.509 che puoi utilizzare per connetterti al cluster durante le disconnessioni dalla rete. Per informazioni su come ottenere e utilizzare un certificato x.509 per il tuo cluster, consulta Autenticazione al cluster locale durante una disconnessione dalla rete.

  • Se non riesci ad accedere a Route 53 durante le disconnessioni dalla rete, prendi in considerazione l’utilizzo dei server DNS locali nel tuo ambiente on-premises. Le istanze del piano di controllo (control-plane) di Kubernetes utilizzano indirizzi IP statici. Puoi configurare gli host che utilizzi per connetterti al cluster con il nome host e gli indirizzi IP dell'endpoint anziché utilizzare i server DNS locali. Per ulteriori informazioni, consulta DNS nella Guida per l'utente di AWS Outposts.

  • Se prevedi un aumento del traffico delle applicazioni durante le disconnessioni dalla rete, puoi allocare capacità di elaborazione di riserva nel tuo cluster quando sei connesso al cloud. Le istanze Amazon EC2 sono incluse nel prezzo di Outposts. AWS Pertanto, l'esecuzione di istanze di riserva non influisce sui costi di utilizzo. AWS

  • Durante le disconnessioni dalla rete, per consentire le operazioni di creazione, aggiornamento e dimensionamento dei carichi di lavoro, le immagini di container dell'applicazione devono essere accessibili sulla rete locale e il cluster deve disporre di una capacità sufficiente. I cluster locali non ospitano un registro dei container per tuo conto. Se i pod in precedenza sono stati eseguiti su tali nodi, le immagini di container vengono memorizzate nella cache dei nodi. Se in genere estrai le immagini dei container dell'applicazione da Amazon ECR nel cloud, prendi in considerazione l'esecuzione di una cache o di un registro locale. Una cache o un registro locale è utile se hai bisogno di creare, aggiornare e dimensionare le risorse del carico di lavoro durante le disconnessioni dalla rete.

  • I cluster locali utilizzano Amazon EBS come classe di archiviazione predefinita per i volumi persistenti e il driver Amazon EBS CSI per gestire il ciclo di vita dei volumi persistenti di Amazon EBS. Durante le disconnessioni di rete, i pod supportati da Amazon EBS non possono essere creati, aggiornati o dimensionati. Questo perché queste operazioni richiedono chiamate all'API Amazon EBS nel cloud. Se stai implementando carichi di lavoro stateful su cluster locali e hai bisogno di creare, aggiornare o dimensionare le operazioni durante le disconnessioni dalla rete, prendi in considerazione l’utilizzo di un meccanismo di archiviazione alternativo.

  • Gli snapshot di Amazon EBS non possono essere creati o eliminati se AWS Outposts non può accedere alle API locali pertinenti ( AWS come le API per Amazon EBS o Amazon S3).

  • Quando si integra ALB (Ingress) con AWS Certificate Manager (ACM), i certificati vengono inviati e archiviati nella memoria dell'istanza AWS Outposts ALB Compute. L'attuale terminazione TLS continuerà a funzionare in caso di disconnessione dalla regione. AWS La modifica delle operazioni in questo contesto non riuscirà (ad esempio nuove definizioni di ingresso, nuove operazioni dell'API su certificati ACM, dimensionamento del calcolo ALB o rotazione dei certificati). Per ulteriori informazioni, consulta Risoluzione dei problemi relativi al rinnovo gestito dei certificati nella Guida per l'utente di AWS Certificate Manager.

  • I registri del piano di controllo (control-plane) di Amazon EKS vengono memorizzati nella cache locale sulle istanze del piano di controllo (control-plane) di Kubernetes durante le disconnessioni dalla rete. Al momento della riconnessione, i registri vengono inviati ai CloudWatch registri nella regione principale. AWS Per monitorare il cluster in locale utilizzando l’endpoint dei parametri del server API Kubernetes o Fluent Bit per i log, puoi utilizzare Prometheus, Grafana e le soluzioni partner di Amazon EKS.

  • Se utilizzi il AWS Load Balancer Controller su Outposts per il traffico delle applicazioni, i Pod esistenti gestiti dal Load AWS Balancer Controller continuano a ricevere traffico durante le disconnessioni di rete. I nuovi Pod creati durante le disconnessioni di rete non ricevono traffico finché Outpost non viene ricollegato al Cloud. AWS Valuta la possibilità di impostare il numero di repliche per le applicazioni connesse al AWS cloud per soddisfare le tue esigenze di scalabilità durante le disconnessioni di rete.

  • Il plug-in della CNI di Amazon VPC per Kubernetes utilizza per impostazione predefinita la modalità IP secondaria. È configurato con WARM_ENI_TARGET=1, che consente al plug-in di mantenere disponibile “un’interfaccia di rete completamente elastica” degli indirizzi IP disponibili. Puoi modificare i valori WARM_ENI_TARGET, WARM_IP_TARGET e MINIMUM_IP_TARGET in base alle tue esigenze di scalabilità durante uno stato di disconnessione. Per ulteriori informazioni, consultate il file readme relativo al plugin. GitHub Per un elenco del numero massimo di Pod supportato da ogni tipo di istanza, consultate il file eni-max-pods.txt su. GitHub

Ottimizza il comportamento di failover dei pod Kubernetes

Durante le disconnessioni di rete, il controller del ciclo di vita del nodo Kubernetes contrassegna i nodi irraggiungibili con effetto. node.kubernetes.io/unreachable NoExecute Per impostazione predefinita, i pod senza una tolleranza corrispondente vengono eliminati dopo 300 secondi (5 minuti). È possibile regolare questo comportamento utilizzando DaemonSets, configurandolo, tolerationSeconds su pod applicativi o implementando un controller personalizzato, in modo da consentire ai pod di rimanere sui propri nodi durante le disconnessioni temporanee senza sfratti inutili. Per indicazioni ed esempi dettagliati, consulta https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html # tune_kubernetes_pod_failover_behavior [Tune Kubernetes pod failover behavior] nella _Amazon EKS Best Practices Guide.

Autenticazione al cluster locale durante una disconnessione dalla rete

AWS Identity and Access Management (IAM) non è disponibile durante le disconnessioni di rete. Non puoi autenticarti nel cluster locale utilizzando le credenziali IAM durante una disconnessione. Tuttavia, durante la disconnessione, potrai connetterti al cluster tramite la rete locale utilizzando i certificati x509. È necessario scaricare e archiviare un certificato X509 client da utilizzare durante le disconnessioni. In questo argomento viene illustrato come creare e utilizzare il certificato per autenticarsi nel cluster quando è disconnesso.

  1. Creare una richiesta di firma del certificato.

    1. Genera una richiesta di firma del certificato.

      openssl req -new -newkey rsa:4096 -nodes -days 365 \
    -keyout admin.key -out admin.csr -subj "/CN=admin"

    2. Crea una richiesta di firma del certificato in Kubernetes.

      BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: admin-csr
spec:
  signerName: kubernetes.io/kube-apiserver-client
  request: ${BASE64_CSR}
  usages:
  - client auth
EOF

  2. Crea una richiesta di firma del certificato utilizzando kubectl.

    kubectl create -f admin-csr.yaml

  3. Controlla lo stato della richiesta di firma del certificato.

    kubectl get csr admin-csr

    Di seguito viene riportato un output di esempio.

    NAME       AGE   REQUESTOR                       CONDITION
admin-csr  11m   kubernetes-admin                Pending

    Kubernetes ha creato la richiesta di firma del certificato.

  4. Approva la richiesta di firma del certificato.

    kubectl certificate approve admin-csr

  5. Controlla nuovamente lo stato della richiesta di firma del certificato per l'approvazione.

    kubectl get csr admin-csr

    Di seguito viene riportato un output di esempio:

    NAME       AGE   REQUESTOR                     CONDITION
admin-csr  11m   kubernetes-admin              Approved

  6. Recupera e verifica il certificato.

    1. Recupera il certificato.

      kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt

    2. Verifica il certificato.

      cat admin.crt

  7. Crea un'associazione di ruoli del cluster per un utente admin.

    kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
    --user=admin --group=system:masters

  8. Genera un kubeconfig con ambito utente per uno stato disconnesso.

    Puoi generare un file kubeconfig utilizzando il certificati admin scaricati. Sostituisci my-cluster e apiserver-endpoint nei seguenti comandi.

    aws eks describe-cluster --name my-cluster \
    --query "cluster.certificateAuthority" \
    --output text | base64 --decode > ca.crt
    kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
    --certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
    kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
    --client-certificate=admin.crt --client-key=admin.key --embed-certs
    kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
    --cluster my-cluster --user admin
    kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster

  9. Visualizza il file kubeconfig.

    kubectl get nodes --kubeconfig admin.kubeconfig

  10. Se disponi di servizi già in produzione sul tuo Outpost, salta questo passaggio. Se Amazon EKS è l’unico servizio in esecuzione sul tuo Outpost e quest’ultimo non è attualmente in produzione, puoi simulare una disconnessione di rete. Prima di entrare in produzione con il cluster locale, puoi simulare una disconnessione per assicurarti di riuscire ad accedere al cluster quando è in uno stato disconnesso.

    1. Applica le regole del firewall ai dispositivi di rete che collegano Outpost alla AWS regione. Questo disconnette il link del servizio dell'Outpost. Non puoi creare nuove istanze. Le istanze attualmente in esecuzione perdono la connettività alla AWS regione e a Internet.

    2. Puoi testare la connessione al cluster locale durante una disconnessione tramite il certificato x509. Assicurati di modificare la kubeconfig con il admin.kubeconfig che hai creato in una fase precedente. Sostituiscilo my-cluster con il nome del cluster locale.

      kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig

    Se riscontri problemi con i cluster locali mentre sono disconnessi, ti consigliamo di inviare una richiesta di supporto.