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

Le migliori pratiche per la stabilità attraverso le disconnessioni di rete

Rete ad alta disponibilità

L'approccio migliore per evitare disconnessioni di rete tra i nodi ibridi e il piano di controllo di Kubernetes consiste nell'utilizzare connessioni ridondanti e resilienti dall'ambiente locale da e verso AWS. Fai riferimento alla documentazione di AWS Direct Connect Resiliency Toolkit e AWS Site-to-Site VPN per ulteriori informazioni sull'architettura di reti ibride ad alta disponibilità con queste soluzioni.

Applicazioni ad alta disponibilità

Quando progettate le applicazioni, considerate i domini di guasto e gli effetti dei diversi tipi di interruzioni. Kubernetes fornisce meccanismi integrati per implementare e mantenere le repliche delle applicazioni su nodi, zone e domini regionali. L'uso di questi meccanismi dipende dall'architettura dell'applicazione, dagli ambienti e dai requisiti di disponibilità. Ad esempio, le applicazioni stateless possono spesso essere implementate con più repliche e possono spostarsi su host e capacità di infrastruttura arbitrari, inoltre è possibile utilizzare selettori di nodi e vincoli di diffusione della topologia per eseguire istanze dell'applicazione su domini diversi. Per informazioni dettagliate sulle tecniche a livello di applicazione per creare applicazioni resilienti su Kubernetes, consulta la EKS Best Practices Guide. https://aws.github.io/aws-eks-best-practices/reliability/docs/application/

Kubernetes valuta le informazioni zonali per i nodi disconnessi dal piano di controllo di Kubernetes per determinare se spostare i pod su altri nodi. Se tutti i nodi di una zona sono irraggiungibili, Kubernetes annulla gli sfratti dei pod per i nodi in quella zona. Come best practice, se disponi di una distribuzione con nodi in esecuzione in più data center o sedi fisiche, assegna una zona a ciascun nodo in base al data center o alla posizione fisica. Quando esegui EKS con nodi nel cloud, questa etichetta di zona viene applicata automaticamente da AWS cloud-controller-manager. Tuttavia, un cloud-controller-manager non viene utilizzato con i nodi ibridi, quindi puoi passare queste informazioni attraverso la tua configurazione kubelet. Di seguito è riportato un esempio di come configurare una zona nella configurazione del nodo per i nodi ibridi. La configurazione viene passata quando si connettono i nodi ibridi al cluster con la CLI (nodeadm) dei nodi ibridi. Per ulteriori informazioni sull'topology.kubernetes.io/zoneetichetta, consulta la documentazione di Kubernetes. Per ulteriori informazioni sulla CLI dei nodi ibridi, consulta il riferimento nodeadm di Hybrid Nodes.

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    region: my-region
  kubelet:
    flags:
       - --node-labels=topology.kubernetes.io/zone=dc1
  hybrid:
    ...

Monitoraggio della rete

Se utilizzi AWS Direct Connect o AWS Site-to-Site VPN per la tua connettività ibrida, puoi sfruttare CloudWatch allarmi, log e metriche per osservare lo stato della tua connessione ibrida e diagnosticare i problemi. Per ulteriori informazioni, consulta Monitoraggio delle risorse AWS Direct Connect e Monitoraggio di una connessione AWS Site-to-Site VPN.

Si consiglia di creare allarmi per NodeNotReady gli eventi segnalati dal node-lifecycle-controller in esecuzione sul piano di controllo EKS, che segnalino che un nodo ibrido potrebbe subire una disconnessione dalla rete. È possibile creare questo allarme abilitando la registrazione del piano di controllo EKS per il Controller Manager e creando un filtro metrico per il messaggio «Recording status change event message CloudWatch for node» con status= «». NodeNotReady Dopo aver creato un filtro metrico, è possibile creare un allarme per questo filtro in base alle soglie desiderate. Per ulteriori informazioni, consulta Alarming for logs nella documentazione. CloudWatch

Potete utilizzare le metriche integrate Transit Gateway (TGW) e Virtual Private Gateway (VGW) per osservare il traffico di rete in entrata e in uscita dal vostro TGW o VGW. È possibile creare allarmi per queste metriche per rilevare scenari in cui il traffico di rete scende al di sotto dei livelli normali, indicando un potenziale problema di rete tra i nodi ibridi e il piano di controllo EKS. Le metriche TGW e VGW sono descritte nella tabella seguente.

Puoi anche utilizzare CloudWatch Network Monitor per ottenere informazioni più approfondite sulle tue connessioni ibride per ridurre il tempo medio di ripristino e determinare se i problemi di rete hanno origine in AWS o nel tuo ambiente. CloudWatch Network Monitor può essere utilizzato per visualizzare la perdita di pacchetti e la latenza nelle connessioni di rete ibride, impostare avvisi e soglie e quindi intervenire per migliorare le prestazioni della rete. Per ulteriori informazioni, consulta Utilizzo di Amazon Network Monitor. CloudWatch

EKS offre diverse opzioni per monitorare lo stato di salute dei cluster e delle applicazioni. Per lo stato dei cluster, puoi utilizzare il dashboard di osservabilità nella console EKS per rilevare, risolvere e risolvere rapidamente i problemi. Puoi anche utilizzare Amazon Managed Service per Prometheus, AWS Distro for Open Telemetry (ADOT) e per il monitoraggio di cluster, applicazioni e infrastrutture. CloudWatch Per ulteriori informazioni sulle opzioni di osservabilità di EKS, consulta Monitorare le prestazioni del cluster e visualizzare i log. https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html

Risoluzione dei problemi locali

Per prepararsi alle disconnessioni di rete tra i nodi ibridi e il piano di controllo EKS, puoi configurare backend di monitoraggio e registrazione secondari per mantenere l'osservabilità delle applicazioni quando i servizi AWS regionali non sono raggiungibili. Ad esempio, puoi configurare il raccoglitore AWS Distro for Open Telemetry (ADOT) per inviare metriche e log a più backend. Puoi anche utilizzare strumenti locali, come la crictl CLI, per interagire localmente con pod e contenitori in sostituzione di altri client Kubernetes che in genere interrogano l'endpoint del server API kubectl API-compatible Kubernetes. Per ulteriori informazioni in merito, consulta la documentazione in cri-tools. crictl crictl GitHub Di seguito sono elencati alcuni crictl comandi utili.

Elenca i pod in esecuzione sull'host:

crictl pods

Elenca i contenitori in esecuzione sull'host:

crictl ps

Elenca le immagini in esecuzione sull'host:

crictl images

Ottieni i log di un contenitore in esecuzione sull'host:

crictl logs CONTAINER_NAME

Ottieni statistiche sui pod in esecuzione sull'host:

crictl statsp

Traffico di rete delle applicazioni

Quando si utilizzano nodi ibridi, è importante considerare e comprendere i flussi di rete del traffico delle applicazioni e le tecnologie utilizzate per esporre le applicazioni esternamente al cluster. Le diverse tecnologie per il bilanciamento del carico e l'ingresso delle applicazioni si comportano in modo diverso durante le disconnessioni di rete. Ad esempio, se si utilizza la funzionalità BGP Control Plane di Cilium per il bilanciamento del carico delle applicazioni, la sessione BGP per i pod e i servizi potrebbe non funzionare durante le disconnessioni di rete. Ciò accade perché la funzionalità degli altoparlanti BGP è integrata con l'agente Cilium e l'agente Cilium si riavvierà continuamente quando viene disconnesso dal piano di controllo di Kubernetes. Il motivo del riavvio è dovuto al fatto che il controllo dello stato di Cilium non è riuscito perché il suo stato di salute è associato all'accesso al piano di controllo di Kubernetes (vedi CFP: #31702 con un miglioramento opt-in in Cilium v1.17). https://github.com/cilium/cilium/issues/31702 Allo stesso modo, se utilizzi Application Load Balancer (ALB) o Network Load Balancers (NLB) per il traffico delle Region-originated applicazioni AWS, tale traffico potrebbe essere temporaneamente inattivo se il tuo ambiente locale perde la connettività alla regione AWS. Si consiglia di verificare che le tecnologie utilizzate per il bilanciamento del carico e l'ingresso rimangano stabili durante le disconnessioni di rete prima della distribuzione in produzione. L'esempio nel GitHub repository aws- samples/eks -hybrid-examples utilizza MetallB per il bilanciamento del carico in modalità L2, che rimane stabile durante le disconnessioni di rete tra i nodi ibridi e il piano di controllo EKS.

Esamina le dipendenze dai servizi AWS remoti

Quando utilizzi nodi ibridi, tieni presente le dipendenze che assumi dai servizi AWS regionali esterni al tuo ambiente locale o periferico. Gli esempi includono l'accesso ad Amazon S3 o Amazon RDS per i dati delle applicazioni, l'utilizzo di Amazon Managed Service per Prometheus o per metriche e log, l'utilizzo di Application and Network Load Balancer CloudWatch per il Region-originated traffico e l'estrazione di container da Amazon Elastic Container Registry. Questi servizi non saranno accessibili durante le disconnessioni di rete tra l'ambiente locale e AWS. Se il tuo ambiente locale è soggetto a disconnessioni di rete con AWS, rivedi l'utilizzo dei servizi AWS e assicurati che la perdita della connessione a tali servizi non comprometta la stabilità statica delle tue applicazioni.

Ottimizza il comportamento di failover dei pod Kubernetes

Sono disponibili opzioni per ottimizzare il comportamento di failover dei pod durante le disconnessioni di rete per le applicazioni che non sono portabili tra gli host o per gli ambienti con risorse limitate che non dispongono di capacità inutilizzata per il failover dei pod. In genere, è importante considerare i requisiti di risorse delle applicazioni e disporre di una capacità sufficiente per consentire a una o più istanze dell'applicazione di eseguire il failover su un host diverso in caso di errore di un nodo.

Di seguito è riportato un esempio di come configurare un Deployment with tolerationSeconds for the unreachable taint. Nell'esempio, tolerationSeconds è impostato su 1800 (30 minuti), il che significa che i pod in esecuzione su nodi irraggiungibili verranno eliminati solo se la disconnessione dalla rete dura più di 30 minuti.

apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 1800