**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 cluster Amazon EKS locali su AWS Outposts configurati con EC2 instance store per le disconnessioni di rete Se il collegamento al servizio AWS Outposts che collega la tua rete locale al AWS Cloud ha perso la connettività, puoi continuare a utilizzare il cluster Amazon EKS locale su un Outpost. Questo argomento spiega come preparare il cluster locale per le disconnessioni di rete e le relative considerazioni. + 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 disconnessione della rete tra Outpost e il 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](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) nella Guida per l'utente di 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](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) nella Guida per l'utente di Outposts AWS .* ## Autenticazione durante le disconnessioni di rete I cluster locali supportano più meccanismi di autenticazione. La loro disponibilità durante le disconnessioni di rete varia: | Meccanismo di autenticazione | Disponibile durante la disconnessione? | | --- | --- | | AWS IAM (voci di accesso, `aws-auth` ConfigMap) | No. IAM richiede la connettività alla AWS regione. | | OIDC (fornitore fornito dal cliente) | Dipende dall'ubicazione del provider. Se il provider OIDC è raggiungibile dalla rete locale di Outpost, l'autenticazione continua a funzionare. | | certificati client x.509 | Sì. I certificati vengono convalidati localmente dal server API Kubernetes. | | IRSA (IAM Roles for Service Accounts) | No Vedi[IRSA e Pod Identity durante le disconnessioni](#eks-outposts-instance-store-network-disconnects-irsa). | | EKS Pod Identity | No. Vedi[IRSA e Pod Identity durante le disconnessioni](#eks-outposts-instance-store-network-disconnects-irsa). | ### certificati client x.509 Per mantenere `kubectl` l'accesso durante le disconnessioni di rete, create un certificato client x.509 prima che avvenga la disconnessione. Per creare un certificato di amministrazione: 1. Genera una chiave privata e una richiesta di firma del certificato (CSR): ``` openssl req -new -newkey rsa:4096 -nodes \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Crea una `CertificateSigningRequest` risorsa Kubernetes e approvala: ``` cat admin.csr | base64 | tr -d '\n' > admin.csr.b64 ``` ``` apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: request: signerName: kubernetes.io/kube-apiserver-client usages: - client auth ``` ``` kubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr ``` 1. Recupera il certificato firmato: ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Crea un file `ClusterRoleBinding` per concedere l'accesso da amministratore: ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Crea un `kubeconfig` file che utilizzi il certificato: ``` 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 ``` ### Risoluzione DNS degli endpoint del cluster durante le disconnessioni L'endpoint del server dell'API Kubernetes per un cluster locale è ospitato in Amazon Route 53 e si risolve negli indirizzi IP privati delle interfacce di rete elastiche (ENI) tra account che Amazon EKS crea nelle tue sottoreti. Questi ENI hanno indirizzi IP privati statici che non cambiano durante il normale funzionamento del cluster. Durante una disconnessione di rete, Outpost non può raggiungere la Route 53, quindi il nome host dell'endpoint del cluster non si risolve a meno che non sia stato preparato un percorso di risoluzione locale. Tre categorie di client devono raggiungere il server API: + **Amministratori del cluster** in esecuzione`kubectl`. + **Worker nodes** (`kubelet`) invia i battiti cardiaci dei nodi ed estrae le specifiche. + **`kube-proxy`**su ogni nodo, che configura gli IP del servizio del cluster. #### Opzione 1: soluzione DNS locale (consigliata) AWS consiglia di implementare una soluzione DNS locale che memorizzi nella cache i record degli endpoint del cluster e li serva mentre Outpost è disconnesso. È possibile eseguire il proprio server DNS nell'ambiente locale che memorizza nella cache i record degli endpoint del cluster. Se utilizzi una soluzione DNS locale, ti consigliamo di indirizzare le tue AMI `kubeconfig` e quelle del nodo di lavoro al nome host dell'endpoint del cluster (non agli indirizzi IP ENI) in modo che la risoluzione sia coerente con la soluzione DNS locale. #### Opzione 2: accesso statico IP-based Se non desideri eseguire una soluzione DNS locale, puoi utilizzare l' IP-based accesso statico. + **Amministratori:** configura il tuo indirizzo IP privato ENI `kubeconfig` che punta direttamente a un indirizzo IP privato ENI tra account diversi. Trova gli ENI cercando le interfacce di rete con la descrizione `Amazon EKS {{cluster-name}} ` nel tuo account. AWS Ogni indirizzo IP di ENI è stabile per tutta la durata del cluster in condizioni di funzionamento normale. + **Nodi di lavoro (AMI ottimizzate per Amazon EKS):** quando avvii nodi di lavoro da un'AMI ottimizzata per Amazon EKS, lo script bootstrap aggiunge l'endpoint del cluster `/etc/hosts` agli indirizzi IP ENI. Non è necessaria alcuna configurazione aggiuntiva. + **Nodi di lavoro (AMI personalizzate):** aggiungi il nome host dell'endpoint del cluster e gli indirizzi IP ENI `/etc/hosts` nel tuo bootstrap personalizzato. In caso contrario, `kubelet` non è `kube-proxy` possibile raggiungere il server API durante una disconnessione. **Importante** Se un ENI su più account viene eliminato o il suo indirizzo IP cambia, ad esempio se lo elimini o lo modifichi in modo da impedire ad Amazon EKS di ricollegarlo, ogni nodo e ogni amministratore che utilizza IP-based l'accesso statico devono essere aggiornati manualmente. Con una soluzione DNS locale, non è richiesto alcun intervento manuale. ### Risoluzione DNS del pod durante le disconnessioni Per evitare errori DNS durante il funzionamento disconnesso, configura il modello di avvio del nodo di lavoro in modo da ignorare l'impostazione. `kubelet’s `resolvConf` Nei tuoi dati utente, crea un `resolv.conf` file personalizzato (ad esempio,`/etc/kubernetes/resolv.conf`) contenente solo `nameserver 10.0.0.2` (senza il dominio di ricerca VPC), quindi `spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf` imposta il tuo. `NodeConfig` Ciò rimuove il dominio ` {{region-code}}.compute.internal` di ricerca dalla configurazione DNS del pod, impedendo che le query vengano inoltrate al resolver DNS VPC irraggiungibile quando si è disconnessi. L'esempio seguente mostra i dati utente del nodo di lavoro: ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash mkdir -p /etc/kubernetes echo "nameserver [.replaceable]``10.0.0.2``" > /etc/kubernetes/resolv.conf --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster ... kubelet: config: resolvConf: /etc/kubernetes/resolv.conf --BOUNDARY-- ``` ### IRSA e Pod Identity durante le disconnessioni **Importante** IRSA e EKS Pod Identity dipendono da AWS STS, che funziona nella regione. AWS Durante una disconnessione di rete, i carichi di lavoro che utilizzano IRSA o Pod Identity non possono ottenere nuove credenziali. Le credenziali esistenti scadono dopo un certo periodo di tempo. Si sconsiglia di fare affidamento sulla funzionalità o sull'operatività Region-based AWS dei servizi per i carichi di lavoro che devono rimanere disponibili durante le disconnessioni di rete. ## `comportamento di etcd durante le disconnessioni` Durante le disconnessioni di rete, non è possibile eseguire il backup delle `etcd` istantanee. Se più di un'`etcd`istanza non è disponibile durante una disconnessione, `etcd` perde il quorum e le operazioni dell'API Kubernetes non sono disponibili finché Outpost non si riconnette e il quorum non viene ripristinato. `etcd` I carichi di lavoro già in esecuzione continuano a funzionare. ## Registrazione del piano di controllo durante le disconnessioni Durante le disconnessioni di rete, i log del piano di controllo vengono memorizzati nella cache locale sulle istanze del piano di controllo. Quando la connettività viene ripristinata, i log vengono inviati ad Amazon CloudWatch Logs nella regione principale AWS . Non è necessario installare o gestire alcun agente di registrazione sul piano di controllo. ## Osservabilità locale Puoi monitorare il cluster localmente durante le disconnessioni utilizzando [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) o altre soluzioni di terze parti per eseguire lo scraping dell'endpoint delle metriche del server dell'API Kubernetes. ## Archivio di immagini locale Per scalare le distribuzioni con repliche aggiuntive o per ripristinare i guasti dei pod durante le disconnessioni, è necessario disporre di un archivio locale di immagini del contenitore (ad esempio un registro Docker) oppure le immagini devono essere memorizzate nella cache del nodo prima della disconnessione. Amazon ECR non è disponibile durante le disconnessioni di rete. ## Ottimizza il comportamento di failover dei pod Kubernetes Durante una disconnessione di rete, il piano di controllo di Kubernetes non può comunicare con la regione. AWS Se un nodo diventa irraggiungibile, il comportamento predefinito di Kubernetes consiste nell'eliminare i pod dopo un periodo di timeout. Puoi regolare questo comportamento utilizzando le tolleranze e le specifiche del tuo pod per controllare la velocità con cui i pod `tolerationSeconds` vengono riprogrammati durante le partizioni. 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*. ## Simula una disconnessione di rete Prima di entrare in produzione con il cluster locale, simula una disconnessione per verificare di poter accedere al cluster quando si trova in uno stato 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. 1. Verifica la connessione al cluster locale utilizzando il certificato x.509 che hai creato: ``` kubectl --kubeconfig admin.kubeconfig get nodes ``` **Nota** Se hai già dei servizi in produzione sul tuo Outpost, non simulare una disconnessione. La disconnessione del collegamento di servizio influisce su tutti i servizi in esecuzione su Outpost.