Prepara EKS i cluster Amazon locali su AWS Outposts per le disconnessioni di rete - Amazon EKS
Autenticazione al cluster locale durante una disconnessione dalla rete

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

  • 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 EKS cluster Amazon 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 l'autenticatore AWS Identity and Access Management per Kubernetes. IAMnon è 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 di rete, prendi in considerazione l'utilizzo di DNS server locali nel tuo ambiente locale. Il Kubernetes le istanze del piano di controllo utilizzano indirizzi IP statici. È possibile configurare gli host utilizzati per connettersi al cluster con il nome host e gli indirizzi IP dell'endpoint in alternativa all'utilizzo dei server locali. DNS Per ulteriori informazioni, consulta la DNSGuida 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 EC2 istanze Amazon sono incluse nel prezzo di AWS Outposts. 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 di contenitori per te. Se il file Pods sono state eseguite in precedenza su tali nodi, le immagini dei contenitori 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 che sono supportati da Amazon non EBS possono essere creati, aggiornati o scalati. Questo perché queste operazioni richiedono chiamate verso Amazon EBS API nel cloud. Se stai distribuendo carichi di lavoro stateful su cluster locali e richiedi operazioni di creazione, aggiornamento o scalabilità durante le disconnessioni di rete, prendi in considerazione l'utilizzo di un meccanismo di archiviazione alternativo.

  • EBSGli snapshot di Amazon non possono essere creati o eliminati se AWS Outposts non riesce ad accedere alla APIs regione AWS interessata (ad esempio APIs per Amazon o EBS Amazon S3).

  • Durante l'integrazione ALB (Ingress) con AWS Certificate Manager (ACM), i certificati vengono inviati e archiviati nella memoria dell'istanza Outposts AWS Compute. ALB TLSLa terminazione attuale continuerà a funzionare in caso di disconnessione dalla 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 Risoluzione dei problemi relativi al rinnovo gestito dei certificati nella Guida per l'utente di AWS Certificate Manager.

  • I log del piano EKS di controllo di Amazon vengono memorizzati nella cache locale sul Kubernetes istanze del piano di controllo durante le disconnessioni di rete. Al momento della riconnessione, i registri vengono inviati ai CloudWatch registri della regione principale. AWS Puoi utilizzare le soluzioni dei partner Prometheus, Grafana o EKS Amazon per monitorare il cluster localmente utilizzando Kubernetes APIendpoint o utilizzando le metriche del server Fluent Bit per i log.

  • Se stai usando il AWS Load Balancer Controller su Outposts per il traffico delle applicazioni, esistente Pods fronteggiato dal AWS Load Balancer Controller continuare a ricevere traffico durante le disconnessioni di rete. Novità Pods creato 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 Amazon VPC CNI plugin for Kubernetes l'impostazione predefinita è la modalità IP secondaria. È configurato con WARM_ENI_TARGET =1, che consente al plugin di mantenere disponibile «un'interfaccia di rete elastica completa» di 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, consulta il file readme per il GitHub plugin. Per un elenco del numero massimo di Pods supportato da ogni tipo di istanza, consulta il eni-max-podsfile.txt 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, imparerai come creare e utilizzare il certificato per l'autenticazione nel cluster quando si trova in uno stato 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, simula una disconnessione per assicurarti di poter accedere al cluster quando è disconnesso.

    1. Applica le regole del firewall ai dispositivi di rete che collegano 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à 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. 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 aprire un ticket di assistenza.