Preparazione alle disconnessioni dalla rete

Se la tua rete locale ha perso la connettività con il Cloud AWS, 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.

Considerazioni sulla preparazione del cluster locale per una disconnessione di rete:

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

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

• I cluster locali utilizzano IAM come meccanismo di autenticazione predefinito tramite AWS Identity and Access Management Authenticator per Kubernetes. IAM non è disponibile durante le disconnessioni dalla 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-premise. Le istanze del piano di controllo (control-plane) 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 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 AWS Outposts. Pertanto, l'esecuzione di istanze di riserva non influisce sui costi di utilizzo di AWS.

• Durante le disconnessioni dalla rete, per consentire le operazioni di creazione, aggiornamento e dimensionamento dei carichi di lavoro, le immagini dei container dell'applicazione devono essere accessibili sulla rete locale e la capacità del cluster deve essere sufficiente. I cluster locali non ospitano un registro dei container per tuo conto. Se in precedenza i Pods sono stati eseguiti su tali nodi, le immagini di container vengono memorizzate nella cache dei nodi. Se generalmente estrai le immagini dei container dell'applicazione da Amazon ECR nel cloud, valuta l'esecuzione di una cache o 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 dalla rete, i Pods 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 pertinenti nella regione AWS (ad esempio le API per Amazon EBS o Amazon S3).

• Quando integri ALB (ingresso) con AWS Certificate Manager (ACM), i certificati vengono inviati e archiviati nella memoria dell'istanza AWS Outposts ALB Compute. Il terminale TLS corrente 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 Soluzione dei problemi del rinnovo gestito dei certificati nella Guida per l'utente AWS Certificate Manager.

• I registri del piano di controllo Amazon EKS vengono memorizzati nella cache locale sulle istanze del piano di controllo Kubernetes durante le disconnessioni dalla rete. Al momento della riconnessione, i registri vengono inviati a CloudWatch Logs in the parent. Regione 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 o soluzioni partner di Amazon EKS.

• Se stai utilizzando un AWS Load Balancer Controller su Outposts per il traffico delle applicazioni, i AWS Load Balancer Controller esistenti anticipati dal Pods continueranno a ricevere traffico durante le disconnessioni dalla rete. I nuovi Pods creati durante le disconnessioni dalla rete non ricevono traffico fino a quando l'Outpost non ristabilisce la connessione con il Cloud AWS. Puoi impostare il numero di repliche per le tue applicazioni mentre sei connesso al Cloud AWS in base alle tue esigenze di dimensionamento durante le disconnessioni dalla rete.

• L'impostazione predefinita di Amazon VPC CNI plugin for Kubernetes è 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 readmefile relativo al plugin su. GitHub Per un elenco del numero massimo di elementi Pods supportati da ciascun tipo di istanza, consultate il eni-max-pods.txtfile su GitHub.

Autenticazione al cluster locale durante una disconnessione dalla rete

AWS Identity and Access Management (IAM) non è disponibile durante le disconnessioni dalla rete. Non puoi autenticarti al 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 al 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 comandi seguenti.

   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 l'Outpost non è attualmente in produzione, puoi simulare una disconnessione dalla 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 sui dispositivi di rete che connettono il tuo Outpost alla Regione AWS. Questo disconnette il link del servizio dell'Outpost. Non puoi creare nuove istanze. Le istanze attualmente in esecuzione perdono la connettività con la Regione AWS e 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. Sostituisci 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 assistenza.