Servizi cluster

I servizi cluster vengono eseguiti all'interno di un cluster EKS, ma non sono carichi di lavoro degli utenti. Se disponi di un server Linux, spesso devi 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 nello spazio dei nomi del sistema Kube e alcuni vengono eseguiti come. DaemonSets

Si prevede che i servizi cluster abbiano 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, si rischia di perdere l'accesso ai dati che possono aiutare a ripristinare o prevenire un'interruzione (ad esempio un elevato utilizzo del disco). Dovrebbero essere eseguiti su istanze di calcolo dedicate come un gruppo di nodi separato o AWS Fargate. Ciò garantirà che i servizi del cluster non vengano influenzati sulle istanze condivise da carichi di lavoro che potrebbero aumentare o utilizzare più risorse.

Scalare CoredNS

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

Riduci le interrogazioni esterne abbassando gli ndots

L'impostazione ndots specifica quanti punti (noti anche come «punti») in un nome di dominio sono considerati sufficienti per evitare l'interrogazione del DNS. Se l'applicazione ha un'impostazione ndots pari a 5 (impostazione predefinita) e si richiedono risorse da un dominio esterno come api.example.com (2 punti), CoredNS verrà interrogato per ogni dominio di ricerca definito in /etc/resolv.conf per un dominio più specifico. 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 and verranno sostituiti con lo spazio dei nomi dei carichi di lavoro e l'area di calcolo. Potresti avere domini di ricerca aggiuntivi in base alle impostazioni del cluster.

È possibile ridurre il numero di richieste a CoredNS abbassando l'opzione ndots del carico di lavoro o qualificando completamente le richieste di dominio includendo un trailing. (ad es.). 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. 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 riduci ndots a un valore troppo basso o i domini a cui ti stai connettendo non includono una specificità sufficiente (incluso il termine finale), è possibile che le ricerche DNS abbiano esito negativo. Assicurati di testare l'impatto di questa impostazione sui tuoi carichi di lavoro.

Scalabilità orizzontale di CoredNS

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 a sé, il DaemonSet che richiede più risorse di elaborazione 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 alle query di richiesta, 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.

Ridimensiona verticalmente il server Kubernetes Metrics

Il Kubernetes Metrics Server supporta il ridimensionamento orizzontale e verticale. Scalando orizzontalmente il Metrics Server sarà altamente disponibile, ma non verrà scalato 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 i dati raccolti, aggregati e serviti in memoria. 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 elaborazione rispetto alla memoria e alla prenotazione della CPU specificate nell'installazione predefinita. È possibile utilizzare Vertical Pod Autoscaler (VPA) o Addon Resizer per ridimensionare il Metrics Server. L'Addon Resizer si ridimensiona verticalmente in proporzione ai nodi di lavoro e alle scale VPA in base all'utilizzo della CPU e della memoria.

Durata CoredNS lameduck

I pod utilizzano il servizio per la risoluzione dei nomi. kube-dns Kubernetes utilizza il NAT di destinazione (DNAT) per reindirizzare il traffico kube-dns dai nodi ai pod di backend CoredNS. Man mano che scalate la distribuzione di CoreDNSkube-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 durante la scalabilità verticale e l'eliminazione delle regole quando si ridimensiona 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 CoredNS Pod terminato.

Puoi ridurre gli errori di ricerca DNS impostando una durata lameduck nei tuoi pod CoredNS. In modalità lameduck, CoredNS continuerà a rispondere alle richieste in volo. L'impostazione di una durata lameduck ritarderà il processo di spegnimento di CoredNS, dando ai nodi il tempo necessario per aggiornare le regole e le catene di iptables.

Si consiglia di impostare la durata di CoredNS lameduck su 30 secondi.

Sonda di prontezza CoredNS

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

In linea con la precedente raccomandazione di impostare la durata del lameduck su 30 secondi, garantendo un tempo sufficiente per aggiornare le regole iptables del nodo prima della chiusura del pod, l'utilizzo /ready invece della sonda di preparazione CoreDNS assicura che il pod CoredNS sia completamente pronto all'avvio /health per rispondere tempestivamente alle richieste DNS.

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

Per ulteriori informazioni sul plugin CoredNS Ready, fare riferimento a 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 solo alle risorse del nodo locale per visualizzare elementi come il contenitore e il nome del processo. Interrogando il server API, può aggiungere ulteriori dettagli come il nome e le etichette della distribuzione Kubernetes. Ciò può essere estremamente utile per la risoluzione dei problemi, ma compromettere la scalabilità.

Poiché esistono così tante opzioni diverse per la registrazione e il monitoraggio, non possiamo mostrare esempi per ogni provider. Con fluentbit consigliamo di abilitare Use_Kubelet per recuperare i 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).

Il monitoraggio e la registrazione della scalabilità hanno due opzioni generali:

• Disattiva le integrazioni

• Campionamento e filtraggio

La disabilitazione delle integrazioni spesso non è un'opzione perché si perdono i metadati di registro. Ciò elimina il problema della scalabilità delle API, ma introdurrà altri problemi in quanto non si dispone 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 archiviazione 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é è probabilmente lì che avvengono le chiamate al server API. Contatta il tuo provider per saperne di più sul supporto per il campionamento.

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

Per evitare la perdita di log e metriche, è consigliabile inviare i dati a un sistema in grado di memorizzare i dati nel buffer in caso di interruzione sull'endpoint ricevente. Con fluentbit puoi usare Amazon Kinesis Data Firehose per conservare temporaneamente i dati, il che può ridurre la possibilità di sovraccaricare la posizione di archiviazione finale dei dati.