**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 su che si trova 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 l'archivio di istanze EC2 per le disconnessioni di rete Se il collegamento del servizio AWS Outposts che collega la 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 consentono la stabilità e la continuità delle operazioni 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 il AWS Cloud, ti consigliamo di provare a ripristinare la connessione. Per istruzioni, consulta la lista di controllo [ per la risoluzione dei problemi di rete ](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html)AWS nei rack di Outposts 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 diversi 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 L'IAM richiede la connettività alla AWS Regione. | | OIDC (fornitore fornito dal cliente) | Dipende dall'ubicazione del fornitore. 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 (ruoli IAM per gli account di servizio) | No Vedere [IRSA e Pod Identity durante le disconnessioni](#eks-outposts-instance-store-network-disconnects-irsa) | | EKS Pod Identity | No Vedere [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, crea un certificato x.509 del client 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 come amministratore: ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Creane uno `kubeconfig` 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 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 dalla rete, Outpost non può raggiungere Route 53, quindi il nome host dell'endpoint del cluster non si risolve a meno che tu non abbia preparato un percorso di risoluzione locale. Tre categorie di client devono raggiungere il server API: + **Amministratori di cluster ** in esecuzione`kubectl`. + **Worker nodes ** (`kubelet`) che inviano i battiti cardiaci dei nodi e le specifiche di estrazione. + **`kube-proxy`**su ogni nodo, che imposta gli IP di 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 tuo 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: ** configurate il vostro account `kubeconfig` in modo che punti direttamente a un indirizzo IP privato ENI con più account. Trova gli ENI cercando le interfacce di rete con la descrizione `Amazon EKS {{cluster-name}} ` nel tuo account. AWS L'indirizzo IP di ciascun ENI è stabile per tutta la durata del cluster in condizioni di normale funzionamento. + **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 con 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 l'operazione di disconnessione, configura il modello di avvio del nodo di lavoro per sovrascrivere 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 imposta il tuo. `spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf` `NodeConfig` Ciò rimuove il dominio ` {{region-code}}.compute.internal` di ricerca dalla configurazione DNS del pod, impedendo che le query vengano inoltrate all'irraggiungibile resolver DNS VPC quando sono disconnesse. 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 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 ed EKS Pod Identity dipendono da AWS STS, che funziona nella regione. AWS Durante una disconnessione dalla 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. Non è consigliabile assumere dipendenze funzionali o operative dai Region-based AWS servizi per i carichi di lavoro che devono rimanere disponibili durante le disconnessioni di rete. ## `comportamento etcd durante le disconnessioni` Durante le disconnessioni di rete, non è possibile eseguire il backup delle `etcd` istantanee. Se più di un'`etcd`istanza diventa 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 mantenere alcun agente di registrazione sul piano di controllo. ## Osservabilità locale Puoi monitorare il cluster localmente durante le disconnessioni utilizzando [ Prometheus](https://prometheus.io/), [ Grafana o altre soluzioni di terze parti per analizzare l'](https://grafana.com/)endpoint delle metriche del server API Kubernetes. ## Archivio di immagini locale Per scalare le distribuzioni con repliche aggiuntive o per ripristinare gli errori del pod durante le disconnessioni, è necessario disporre di un repository di immagini del contenitore locale (ad esempio un registro Docker) oppure le immagini devono essere memorizzate nella cache sul nodo prima della disconnessione. Amazon ECR non è disponibile durante le disconnessioni di rete. ## Ottimizza il comportamento di failover dei pod Kubernetes Durante una disconnessione dalla rete, il piano di controllo di Kubernetes non può comunicare con la regione. AWS Se un nodo diventa irraggiungibile, il comportamento predefinito di Kubernetes è quello di rimuovere 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 dettagliate ed esempi, 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 avviare la produzione con il cluster locale, simula una disconnessione per verificare di poter accedere al cluster quando è disconnesso. 1. Applica le regole del firewall sui dispositivi di rete che collegano Outpost alla regione. AWS Questo disconnette il link del servizio dell'Outpost. 1. Verifica la connessione al tuo cluster locale utilizzando il certificato x.509 che hai creato: ``` kubectl --kubeconfig admin.kubeconfig get nodes ``` **Nota** Se disponi di servizi già in produzione sul tuo Outpost, non simulare una disconnessione. La disconnessione del service link ha effetto su tutti i servizi in esecuzione su Outpost.