Prepara EKS i cluster Amazon locali AWS Outposts per le disconnessioni di rete - Amazon EKS
Autenticazione al cluster

Aiutaci a migliorare questa pagina

Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.

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 EKS i cluster Amazon locali AWS Outposts per le disconnessioni di rete

Se la tua rete locale ha perso la connettività con Cloud AWS, puoi continuare a utilizzare il tuo EKS cluster Amazon 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 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 data Cloud AWS center. In caso di disconnessioni di rete tra Outpost e 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 Risolvi i problemi relativi ai cluster Amazon locali su EKS 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 l'autenticatore per.AWS Identity and Access ManagementKubernetes 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 di rete, prendi in considerazione l'utilizzo di DNS server locali nel tuo ambiente locale. Le istanze del piano di controllo (control-plane) Kubernetes utilizzano indirizzi IP statici. Puoi configurare gli host che usi per connetterti al tuo cluster con il nome host e gli indirizzi IP dell'endpoint in alternativa all'utilizzo dei server locali. DNS Per ulteriori informazioni, consulta DNSla Guida per l'AWS Outposts utente.

  • 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. EC2Le istanze Amazon sono incluse nel prezzo di AWS Outposts. Pertanto, l'esecuzione di istanze di riserva non influisce sui costi di AWS utilizzo.

  • 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 in genere estrai le immagini dei container della tua 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 storage predefinita per i volumi persistenti e il EBS CSI driver Amazon per gestire il ciclo di vita dei volumi persistenti AmazonEBS. Durante le disconnessioni di rete, Pods quelle supportate da Amazon non EBS possono essere create, aggiornate o scalate. Questo perché queste operazioni richiedono chiamate verso Amazon EBS API 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.

  • EBSGli snapshot di Amazon non possono essere creati o eliminati se non è AWS Outposts possibile accedere all' AWS area geografica pertinente APIs (ad esempio per APIs Amazon EBS o Amazon S3).

  • Durante l'integrazione ALB (Ingress) con AWS Certificate Manager (ACM), i certificati vengono inviati e archiviati nella memoria dell'istanza Compute. AWS Outposts ALB TLSLa terminazione corrente continuerà a funzionare in caso di disconnessione da. Regione AWS Le operazioni di modifica in questo contesto falliranno (ad esempio nuove definizioni di ingresso, nuove API operazioni ACM basate sui certificati, scala di ALB calcolo 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 log del piano EKS di controllo di Amazon vengono memorizzati nella cache locale sulle istanze del piano di Kubernetes controllo durante le disconnessioni di rete. Al momento della riconnessione, i log vengono inviati a Logs in the parent. CloudWatch Regione AWS Puoi utilizzare Prometheussoluzioni EKS partner di Amazon per monitorare il cluster localmente utilizzando l'endpoint delle metriche del Kubernetes API server o utilizzando Fluent Bit per i log. Grafana

  • 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. Valuta la possibilità di impostare il numero di repliche per le applicazioni mentre sono connesse a, in modo da Cloud AWS soddisfare le tue esigenze di scalabilità durante le disconnessioni di 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. 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 di rete. Non è possibile autenticarsi nel cluster locale utilizzando le IAM credenziali quando si è disconnessi. 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. Replace (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 Outpost 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 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à a e a Internet. Regione AWS

    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. Replace (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.