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

Servizi cluster

I servizi cluster vengono eseguiti all'interno di un cluster EKS, ma non sono carichi di lavoro degli utenti. Se hai un server Linux, spesso hai bisogno di eseguire servizi come NTP, syslog e un container runtime per supportare i tuoi carichi di lavoro. I servizi cluster sono simili e supportano servizi che consentono di automatizzare e gestire il cluster. In Kubernetes questi vengono generalmente eseguiti nel namespace kube-system e alcuni vengono eseguiti come. DaemonSets

I servizi cluster dovrebbero avere un tempo di attività elevato e sono spesso fondamentali durante le interruzioni e per la risoluzione dei problemi. Se un servizio cluster di base non è disponibile, potresti perdere l'accesso ai dati che possono aiutare il ripristino o prevenire un'interruzione (ad esempio, un utilizzo elevato del disco). Dovrebbero essere eseguiti su istanze di calcolo dedicate come un gruppo di nodi separato o AWS Fargate. Ciò garantirà che i servizi di cluster non siano influenzati sulle istanze condivise da carichi di lavoro che potrebbero essere scalabili o utilizzare più risorse.

Ridimensiona CoreDNS

La scalabilità di CoreDNS prevede due meccanismi principali. Riduzione del numero di chiamate al servizio CoreDNS e aumento del numero di repliche.

Riduci le interrogazioni esterne abbassando i ndots

L'impostazione ndots specifica quanti punti (noti anche come «punti») in un nome di dominio sono considerati sufficienti per evitare di interrogare il DNS. Se l'applicazione ha un'impostazione ndots pari a 5 (impostazione predefinita) e richiedi risorse da un dominio esterno come api.example.com (2 punti), CoreDNS verrà interrogato per ogni dominio di ricerca definito in/.conf per un dominio più specifico. etc/resolv Per impostazione predefinita, verranno cercati i seguenti domini prima di effettuare una richiesta esterna.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

regionI valori namespace e verranno sostituiti dallo spazio dei nomi dei carichi di lavoro e dalla regione di calcolo. Potresti avere domini di ricerca aggiuntivi in base alle impostazioni del cluster.

Puoi ridurre il numero di richieste a CoreDNS abbassando l'opzione ndots del carico di lavoro o qualificando completamente le richieste di dominio includendo un finale. (ad esempio). api.example.com. Se il carico di lavoro si connette a servizi esterni tramite DNS, ti consigliamo di impostare ndots su 2 in modo che i carichi di lavoro non rendano superflue le query DNS del cluster all'interno del cluster. Puoi impostare un server DNS e un dominio di ricerca diversi se il carico di lavoro non richiede l'accesso ai servizi all'interno del cluster.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

Se abbassi gli ndots a un valore troppo basso o i domini a cui ti connetti non includono una specificità sufficiente (incluso il trailing), è possibile che le ricerche DNS abbiano esito negativo. Assicurati di testare l'impatto di questa impostazione sui tuoi carichi di lavoro.

Scala CoreDNS orizzontalmente

Le istanze CoreDNS possono essere scalate aggiungendo repliche aggiuntive alla distribuzione. Si consiglia di utilizzare il NodeLocal DNS o l'autoscaler proporzionale del cluster per scalare CoreDNS.

NodeLocal Il DNS richiederà l'esecuzione di un'istanza per nodo, come tale, DaemonSet che richiederà più risorse di calcolo nel cluster, ma eviterà le richieste DNS non riuscite e ridurrà il tempo di risposta per le query DNS nel cluster. L'autoscaler proporzionale del cluster scalerà CoreDNS in base al numero di nodi o core nel cluster. Questa non è una correlazione diretta con le richieste, ma può essere utile a seconda dei carichi di lavoro e delle dimensioni del cluster. La scala proporzionale predefinita prevede l'aggiunta di una replica aggiuntiva per ogni 256 core o 16 nodi del cluster, a seconda dell'evento che si verifica per primo.

Se utilizzi il componente aggiuntivo CoreDNS EKS, valuta la possibilità di abilitare l'opzione di scalabilità automatica. https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html L'autoscaler CoreDNS regola dinamicamente il numero di repliche CoreDNS monitorando il numero di nodi e i core della CPU, utilizzando una formula che richiede il numero massimo di (nodi÷16) o (core CPU ÷ 256), aumentando immediatamente quando necessario e diminuendo gradualmente per mantenere la stabilità.

Scalabilità verticale del server Kubernetes Metrics

Il Kubernetes Metrics Server supporta il ridimensionamento orizzontale e verticale. Scalando orizzontalmente il Metrics Server sarà altamente disponibile, ma non scalerà orizzontalmente per gestire più metriche del cluster. Dovrai scalare verticalmente il Metrics Server in base ai relativi consigli man mano che i nodi e le metriche raccolte vengono aggiunti al cluster.

Il Metrics Server conserva in memoria i dati che raccoglie, aggrega e fornisce. Man mano che un cluster cresce, aumenta la quantità di dati archiviati dal Metrics Server. Nei cluster di grandi dimensioni, il Metrics Server richiederà più risorse di calcolo rispetto alla riserva di memoria e CPU specificata nell'installazione predefinita. È possibile utilizzare Vertical Pod Autoscaler (VPA) o Addon Resizer per scalare il Metrics Server. L'Addon Resizer si ridimensiona verticalmente in proporzione ai nodi di lavoro e il VPA si ridimensiona in base all'utilizzo della CPU e della memoria.

Durata del lameduck CoreDNS

I pod utilizzano il Servizio per la risoluzione dei nomi. kube-dns Kubernetes utilizza il NAT di destinazione (DNAT) per reindirizzare il kube-dns traffico dai nodi ai pod backend CoreDNS. Man mano che scalate la distribuzione CoreDNS, kube-proxy aggiorna le regole e le catene di iptables sui nodi per reindirizzare il traffico DNS verso i pod CoreDNS. La propagazione di nuovi endpoint quando si esegue lo scaling up e l'eliminazione delle regole in caso di ridimensionamento CoreDNS possono richiedere da 1 a 10 secondi a seconda delle dimensioni del cluster.

Questo ritardo di propagazione può causare errori di ricerca DNS quando un pod CoreDNS viene terminato ma le regole iptables del nodo non sono state aggiornate. In questo scenario, il nodo può continuare a inviare query DNS a un pod CoreDNS terminato.

È possibile ridurre gli errori di ricerca DNS impostando una durata di lameduck nei pod CoreDNS. https://coredns.io/plugins/health/ In modalità lameduck, CoreDNS continuerà a rispondere alle richieste in volo. L'impostazione di una durata di lameduck ritarderà il processo di spegnimento di CoreDNS, concedendo ai nodi il tempo necessario per aggiornare le regole e le catene di iptables.

Consigliamo di impostare la durata di CoreDNS lameduck su 30 secondi.

Sonda di prontezza CoreDNS

Si consiglia di utilizzarla /ready al posto della sonda di prontezza di /health CoreDNS.

In linea con la precedente raccomandazione di impostare la durata di lameduck su 30 secondi, in modo da consentire l'aggiornamento delle regole iptables del nodo prima della chiusura del pod, l'utilizzo della sonda di disponibilità di CoreDNS assicura che il pod CoreDNS sia completamente pronto all'avvio /health per rispondere /ready prontamente alle richieste DNS.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

Per ulteriori informazioni sul plug-in CoreDNS Ready, consulta https://coredns.io/plugins/ready/

Agenti di registrazione e monitoraggio

Gli agenti di registrazione e monitoraggio possono aggiungere un carico significativo al piano di controllo del cluster perché interrogano il server API per arricchire i log e le metriche con i metadati del carico di lavoro. L'agente su un nodo ha accesso alle risorse del nodo locale solo per visualizzare elementi come il nome del contenitore e del processo. Interrogando il server API, può aggiungere ulteriori dettagli come il nome e le etichette della distribuzione Kubernetes. Questo può essere estremamente utile per la risoluzione dei problemi ma dannoso per la scalabilità.

Poiché ci sono così tante opzioni diverse per la registrazione e il monitoraggio, non possiamo mostrare esempi per tutti i provider. Con fluentbit consigliamo di Use_Kubelet abilitare il recupero dei metadati dal kubelet locale anziché dal server API Kubernetes e di impostare un numero che riduca le chiamate ripetute quando i dati possono essere memorizzati nella cache (Kube_Meta_Cache_TTLad esempio 60).

La scalabilità, il monitoraggio e la registrazione hanno due opzioni generali:

La disattivazione delle integrazioni spesso non è un'opzione perché si perdono i metadati del registro. Ciò elimina il problema della scalabilità delle API, ma ne introdurrà altri, in quanto la mancanza dei metadati richiesti quando necessario.

Il campionamento e il filtraggio riducono il numero di metriche e registri raccolti. Ciò ridurrà la quantità di richieste all'API Kubernetes e ridurrà la quantità di spazio di archiviazione necessaria per le metriche e i log raccolti. La riduzione dei costi di storage ridurrà il costo dell'intero sistema.

La capacità di configurare il campionamento dipende dal software dell'agente e può essere implementata in diversi punti di inserimento. È importante aggiungere il campionamento il più vicino possibile all'agente perché è probabile che sia lì che avvengono le chiamate al server API. Contatta il tuo provider per saperne di più sull'assistenza per il campionamento.

Se si utilizza CloudWatch and CloudWatch Logs, è possibile aggiungere il filtro degli agenti utilizzando i modelli descritti nella documentazione.

Per evitare di perdere log e metriche, è necessario inviare i dati a un sistema in grado di bufferizzare i dati in caso di interruzione dell'endpoint ricevente. Con fluentbit puoi utilizzare Amazon Kinesis Data Firehose per conservare temporaneamente i dati, in modo da ridurre la possibilità di sovraccaricare la posizione di archiviazione finale dei dati.