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à.
Configurazione avanzata del piano di controllo Kubernetes
Panoramica di
Amazon EKS gestisce il piano di controllo Kubernetes per il tuo cluster, inclusi il server API, lo scheduler e il controller manager. EKS esegue questi componenti con impostazioni Kubernetes upstream predefinite che funzionano bene per la maggior parte dei carichi di lavoro e non è necessario modificarle per la maggior parte dei cluster. Tuttavia, alcuni carichi di lavoro traggono vantaggio da diverse impostazioni del piano di controllo. Potresti volere che lo scheduler raggruppi i pod su un numero inferiore di nodi per ridurre i costi di elaborazione, conservare gli eventi Kubernetes per un periodo più breve per limitare la crescita dei database cluster (ecc.) o valutare più frequentemente le decisioni relative alla scalabilità automatica.
Con la configurazione avanzata del piano di controllo di Kubernetes, puoi impostare questi parametri direttamente sul tuo cluster. EKS li applica al piano di controllo e il cluster continua a funzionare con le stesse caratteristiche di disponibilità e prestazioni.
Si tratta di configurazioni avanzate. Ogni parametro di configurazione modifica il comportamento di un componente principale del piano di controllo di Kubernetes per i carichi di lavoro in esecuzione sul cluster e il valore giusto dipende dal carico di lavoro. Prima di modificare un parametro, leggi le considerazioni relative alle sezioni seguenti e verifica la modifica in un cluster non di produzione.
È possibile impostare i parametri di configurazione avanzati del piano di controllo quando si crea un cluster o aggiornarli su un cluster esistente in qualsiasi momento. Questa funzionalità utilizza le UpdateClusterConfig operazioni CreateCluster e le operazioni esistenti con nuovi parametri, quindi puoi impostarla tramite AWS CLI, AWS SDK o. Console di gestione AWS AWS CloudFormation EKS convalida ogni configurazione prima di applicarla e registra le modifiche. AWS CloudTrail
I parametri avanzati del piano di controllo si applicano all'intero cluster e a tutti i carichi di lavoro in esecuzione su di esso. Non è possibile applicarli a singoli namespace o carichi di lavoro. EKS vincola ogni parametro a un intervallo convalidato. I valori supportati per ogni parametro sono elencati insieme a tale parametro nella sezione seguente.
Parametri del piano di controllo Kubernetes supportati
Amazon EKS supporta i seguenti parametri. Ogni parametro appartiene a un componente del piano di controllo e viene impostato tramite il campo di configurazione relativo a quel componente:kubeSchedulerConfig,kubeControllerManagerConfig, okubeApiServerConfig.
| Componente | Parametro | Valori supportati | Predefinita | Richiede un piano di controllo fornito |
|---|---|---|---|---|
|
kube-scheduler |
|
|
|
No |
|
kube-controller-manager |
|
Da |
|
Sì |
|
kube-controller-manager |
|
Da |
|
Sì |
|
server kube-api |
|
Da |
|
No |
|
server kube-api |
|
|
|
No |
I valori predefiniti e supportati in questo argomento si applicano alla versione di Kubernetes (EKS v1.31 e successive) disponibile al momento della pubblicazione e potrebbero cambiare nelle versioni successive. L'DescribeClusterVersionsoperazione riporta i valori predefiniti e supportati correnti per ogni parametro e versione di Kubernetes, quindi usala come fonte di verità se gestisci cluster su più versioni o automatizzi la configurazione dei cluster. Per ulteriori informazioni, consulta Configurazione dei parametri avanzati del piano di controllo Kubernetes.
Le sezioni seguenti descrivono ogni parametro, quando modificarlo e cosa considerare prima di procedere.
Scheduler: le risorse del nodo si adattano
Lo scheduler assegna i pod ai nodi in due fasi. Prima filtra i nodi che possono eseguire un pod, quindi assegna un punteggio ai candidati rimanenti e posiziona il pod nel nodo con il punteggio più alto. Il nodeResourcesFit plugin verifica se un nodo dispone delle risorse richieste da un pod e assegna un punteggio ai nodi in base a una strategia di punteggio.
| Campo | Description | Valori supportati | Predefinita |
|---|---|---|---|
|
|
La strategia utilizzata per assegnare un punteggio ai nodi in base all'allocazione delle risorse. |
|
|
|
|
Le risorse considerate per l'assegnazione del punteggio, ciascuna con un peso relativo. |
|
|
LeastAllocatedprivilegia i nodi con una minore allocazione delle risorse, distribuendo i pod tra i nodi del cluster e lasciando spazio a ciascun nodo. Questo è il comportamento predefinito di Kubernetes ed è una buona scelta quando si desidera la capacità disponibile su ogni nodo per assorbire la crescita dei pod esistenti.
MostAllocatedprivilegia i nodi che dispongono già di una maggiore allocazione delle risorse, il che raggruppa i pod su un numero inferiore di nodi. Poiché i carichi di lavoro occupano una capacità totale inferiore, puoi eseguirli su un numero inferiore di nodi e ridurre la spesa di elaborazione. Nel tempo, questo comportamento di impacchettamento mantiene i nodi poco utilizzati liberi da nuovi carichi di lavoro, in modo che i pool di nodi che supportano il consolidamento possano rimuoverli.
EKS supporta le strategie LeastAllocated e. MostAllocated La RequestedToCapacityRatio strategia Kubernetes upstream non è supportata.
Ponderazione delle risorse
È possibile specificare facoltativamente un resources array con pesi personalizzati per determinare quali risorse sono più importanti nelle decisioni relative al punteggio. Ciò è utile quando una risorsa specifica è il vincolo del cluster. Ad esempio, nei cluster in cui gli acceleratori (GPU) sono la risorsa più scarsa, un peso nvidia.com/gpu superiore a CPU e memoria concentra i pod che richiedono acceleratori su nodi già parzialmente occupati.
I pesi sono relativi, non assoluti. L'impostazione cpu: 100 e memory: 1 non fa sì che lo scheduler ignori la memoria. Pesa la CPU 100 volte di più della memoria nella formula di punteggio. Se tutti i nodi candidati hanno una disponibilità di CPU identica, la CPU non li distingue più e il punteggio viene effettivamente assegnato alla memoria.
Omettere una risorsa è diverso dall'attribuirle un peso ridotto. Quando si specifica un resources array, vengono valutate solo le risorse elencate. Una risorsa tralasciata viene completamente esclusa dal calcolo. Ad esempio, cpu: 100 se non vengono memory assegnati punteggi ai nodi, la sola CPU e la disponibilità di memoria non influiscono sul risultato. Per mantenere una risorsa nel calcolo riducendone l'influenza, elencala con un peso ridotto anziché ometterla.
La ponderazione di una risorsa acceleratrice, ad esempio, influisce nvidia.com/gpu solo sul punteggio dei pod che dichiarano effettivamente tale risorsa. resources.requests I pod che non richiedono acceleratori non sono influenzati dal peso dell'acceleratore.
Le tre risorse dell'acceleratore sono risorse estese di Kubernetes, ossia risorse a livello di nodo pubblicizzate a Kubernetes da un plugin anziché integrate. Vengono valutate solo quando un plug-in del dispositivo le pubblicizza su kubelet tramite l'API del plug-in del dispositivo. Le risorse rese disponibili su un nodo da un solo driver di dispositivo non sono visibili al nodeResourcesFit plug-in e non vengono valutate. Le risorse gestite tramite Dynamic Resource Allocation (DRA) sono pianificate da un plug-in separato e non fanno parte del nodeResourcesFit punteggio, pertanto l'attivazione del DRA non modifica il comportamento di questo parametro. Per ulteriori informazioni sulla configurazione dei plug-in dei dispositivi NVIDIA, vedere NVIDIA DRA e plug-in del dispositivo. https://docs.aws.amazon.com/eks/latest/userguide/device-management-nvidia-dra-device-plugin.html Per ulteriori informazioni sulla configurazione dei dispositivi Neuron, vedi Gestione dei dispositivi Neuron. https://docs.aws.amazon.com/eks/latest/userguide/device-management-neuron.html
La strategia di punteggio è uno dei numerosi input utilizzati dallo scheduler per calcolare un punteggio per ciascun nodo. Per ulteriori informazioni su come lo scheduler filtra e valuta i nodi, vedi Scheduling Framework
Considerazioni per la strategia di punteggio
-
I pod funzionanti non vengono spostati. Lo scheduler Kubernetes non riposiziona mai un pod già in esecuzione. La modifica della strategia di punteggio influisce solo sulle decisioni di pianificazione future e il posizionamento dei pod esistenti è permanente. Per ribilanciare i pod già in esecuzione, sfrattali o riavviali.
-
Il comportamento di filtraggio non cambia. La strategia di punteggio influisce solo sulla fase di punteggio, in cui lo scheduler classifica i nodi in base alle preferenze. La fase di filtraggio, che determina se un pod può essere eseguito su un nodo, rimane invariata. Un pod che non si adatta a un nodo non è ancora programmato in nessuna delle due strategie.
-
MostAllocatedconcentra il raggio di esplosione. L'impacchettamento dei carichi di lavoro su un numero inferiore di nodi significa che più pod vengono colpiti contemporaneamente se un nodo diventa malsano, un'istanza viene ritirata o una zona di disponibilità viene interrotta. In presenza di un elevato tasso di abbandono dei pod, anche i nodi densamente impacchettati si riempiono più velocemente, il che può lasciare i pod in stato mentre viene fornita nuova capacità.Pending -
Lo scheduler e la gestione dei nodi operano a diversi livelli. La strategia di punteggio influenza la posizione dei pod tra i nodi che possono già eseguirli. Non cambia il modo in cui EKS Auto Mode o Karpenter forniscono o rimuovono i nodi. Convalida il comportamento combinato per il tuo carico di lavoro prima di modificare la configurazione.
Controller manager: periodo di sincronizzazione Horizontal Pod Autoscaler
Il controller manager esegue i controller Kubernetes che indirizzano lo stato del cluster verso lo stato desiderato, incluso il controller Horizontal Pod Autoscaler (HPA). In ogni ciclo, il controller HPA recupera le metriche per ogni HorizontalPodAutoscaler oggetto, calcola il numero di repliche desiderato e aggiorna il carico di lavoro di destinazione se il conteggio è cambiato.
| Campo | Description | Valori supportati | Predefinita |
|---|---|---|---|
|
|
Con quale frequenza il controller HPA valuta le decisioni di scalabilità. |
Da |
|
Riducendo il periodo di sincronizzazione, i carichi di lavoro si scalano subito dopo l'aumento del carico, anziché attendere un ciclo completo prima di aggiungere capacità.
Per configurare questo parametro, il cluster deve trovarsi su Amazon EKS Provisioned Control Plane. La riduzione dell'intervallo aumenta la velocità con cui il controller HPA riconcilia tutti gli HorizontalPodAutoscaler oggetti del cluster, generando più richieste API. Ogni riconciliazione consuma almeno una richiesta API e una riconciliazione che modifica il numero di repliche ne consuma altre due. I cluster Control Plane con provisioning preallocano la capacità del piano di controllo che è sempre pronta per carichi di lavoro impegnativi, quindi sono dimensionati per assorbire quel carico aggiuntivo. Per ulteriori informazioni, consulta Piano di controllo predisposto di Amazon EKS.
Influenza sul numero di oggetti HPA supportati dal cluster
-
La riduzione del periodo di sincronizzazione riduce il numero di
HorizontalPodAutoscaleroggetti che il piano di controllo può riconciliare nei tempi previsti, poiché il controller ha meno tempo per lavorare sulla stessa coda. Riducendo il periodo da15sa si10sriduce il numero di oggetti supportati di circa un terzo. Prima di abbreviare il periodo di sincronizzazione, conta gliHorizontalPodAutoscaleroggetti nel cluster e conferma che il periodo più breve supporti ancora quel conteggio nel tuo livello di scalabilità:kubectl get hpa --all-namespaces --no-headers | wc -l -
EKS non convalida il periodo di sincronizzazione rispetto al numero di oggetti HPA. La modifica della configurazione ha esito positivo anche se il cluster ha già più
HorizontalPodAutoscaleroggetti di quelli supportati dal periodo più breve. Verifica tu stesso il conteggio prima di apportare la modifica. -
Il superamento del conteggio supportato degrada automaticamente la scalabilità automatica in modo silenzioso. Se il controller non è in grado di elaborare tutti gli oggetti entro il periodo, alcuni oggetti non vengono riconciliati nei tempi previsti. EKS non emette un allarme o un evento Kubernetes per questa condizione e il sintomo è la scalabilità automatica che risponde più lentamente del previsto, l'opposto dell'effetto previsto. Se osservi un ridimensionamento ritardato dopo aver ridotto il periodo di sincronizzazione, riporta il parametro al valore predefinito di.
15s -
Il periodo di sincronizzazione si applica a tutti gli oggetti HPA nel cluster. Non puoi impostare periodi di sincronizzazione diversi per oggetti o namespace diversi.
Controller manager: soglia di raccolta dei rifiuti nei pod terminata
Il controller manager esegue il pod garbage collector terminato (il controller pod GC). Questo controller elimina i pod terminati, ovvero i pod in Failed fase Succeeded or, dopo che il numero di pod terminati nel cluster supera una soglia. Il parametro imposta tale terminatedPodGcThreshold soglia.
| Campo | Description | Valori supportati | Predefinita |
|---|---|---|---|
|
|
Il numero di pod terminati che possono esistere prima che il Garbage Collector dei pod terminati inizi a eliminare i pod terminati. |
Da |
|
Il garbage collector funziona con un ciclo fisso di 20 secondi. Quando si abbassa la soglia, il raccoglitore inizia a eliminare forzatamente i pod terminati più vecchi nel ciclo successivo fino a quando il conteggio non raggiunge la nuova soglia.
Per configurare questo parametro, il cluster deve trovarsi su Amazon EKS Provisioned Control Plane. L'abbassamento della soglia aumenta il lavoro di garbage collection eseguito dal controller sul database del cluster (ecc.). Ogni pass di raccolta diventa idoneo per interrogare, elaborare ed eliminare altri pod terminati. I cluster Provisioned Control Plane preallocano la capacità del piano di controllo che è sempre pronta per carichi di lavoro impegnativi, in modo da poter assorbire quel carico aggiuntivo. Per ulteriori informazioni, consulta Piano di controllo predisposto di Amazon EKS.
Considerazioni sulla soglia terminata per la raccolta dei rifiuti nei pod
-
L'abbassamento della soglia elimina immediatamente i pod terminati in eccesso. Se si abbassa la soglia (ad esempio, da
12500a10000), il Garbage Collection Controller avvia l'eliminazione forzata dei pod terminati più vecchi nel ciclo successivo. Il controller continua finché il numero di pod terminati non raggiunge la nuova soglia. La riduzione non è graduale. -
La soglia si applica a tutti i pod terminati indipendentemente dal proprietario. Influisce sui pod in
FailedfaseSucceededo indipendentemente dal fatto che siano di proprietà di un Job CronJob, o Deployment o siano autonomi. In pratica, Job e CronJob pod sono i responsabili più comuni del numero di pod terminati. -
L'abbassamento della soglia riduce la finestra di debug. I pod completati e falliti scompaiono
kubectl get podsekubectl logsprima. L'automazione che ispeziona i codici di uscita o i log dei Job pod finiti ha una finestra operativa più piccola. -
La soglia è un'impostazione globale del cluster. Non è possibile configurarlo per namespace o per Job. Per controllare il ciclo di vita dei pod di un singolo Job, usali su quel Job.
ttlSecondsAfterFinished
Server API: conservazione degli eventi
Il server API è il front-end per il piano di controllo di Kubernetes. Serve l'API Kubernetes e mantiene lo stato del cluster nel database del cluster (etcd). Kubernetes registra gli eventi per descrivere ciò che accade nel cluster, ad esempio decisioni sulla pianificazione dei pod, prelievi di immagini, errori nei controlli di integrità e azioni di ridimensionamento.
| Campo | Description | Valori supportati | Predefinita |
|---|---|---|---|
|
|
Per quanto tempo il server API conserva gli eventi Kubernetes prima di eliminarli. |
Da |
|
I cluster che eseguono carichi di lavoro ad alto tasso di abbandono, come lavori batch su larga scala, carichi di lavoro AI, pipeline e frequenti, accumulano rapidamente migliaia di eventi. CI/CD CronJobs Ogni evento conservato consuma uno spazio del database del cluster che compete con gli oggetti necessari per l'esecuzione del cluster e un'ampia raccolta di eventi rende le operazioni relative agli elenchi dei server API più costose da gestire.
La riduzione della conservazione degli eventi consente di cancellare più rapidamente questi dati diagnostici di breve durata, riducendo la pressione sullo storage del database del cluster e migliorando i tempi di risposta del server API per le query che richiedono un numero elevato di eventi.
Un periodo di conservazione più breve è una buona soluzione quando:
-
Il cluster esegue batch CI/CD, AI o CronJob carichi di lavoro che generano un volume elevato di eventi.
-
Osservi lo storage del database del cluster crescere verso il limite.
-
Ti affidi a un sistema esterno per acquisire gli eventi in modo duraturo e non dipendi da esso
kubectl get eventsper il debug cronologico.
Considerazioni sulla conservazione degli eventi
-
Una modifica si applica solo ai nuovi eventi. Kubernetes imposta la scadenza di un evento quando l'evento viene creato. Gli eventi già esistenti mantengono il periodo di conservazione in vigore al momento della loro creazione e scadono in base a tale pianificazione. La riduzione
eventTtlnon riduce la durata degli eventi già presenti nel database del cluster, pertanto la riduzione dello spazio di archiviazione ha effetto gradualmente man mano che gli eventi esistenti scadono. -
Gli eventi eliminati non possono essere recuperati. Dopo che Kubernetes ha rimosso un evento, questo viene eliminato definitivamente. Se riduci la conservazione oltre il previsto e perdi la cronologia degli eventi, non c'è modo di ripristinarla. Verifica che tutto ciò da cui dipendi per la risoluzione dei problemi venga acquisito all'esterno del cluster prima di abbreviare questo valore.
-
Gli eventi possono persistere leggermente oltre il periodo configurato. In alcune condizioni, la scadenza di un evento può essere estesa oltre il valore configurato a causa del rinnovo del leasing etcd che potrebbe avvenire durante l'elezione del leader del piano di controllo.
-
Finestra di debug ridotta. Un periodo di conservazione più breve restringe la finestra mostrata da
kubectl get eventsekubectl describe. Gli strumenti di monitoraggio che raccolgono gli eventi dal cluster hanno meno dati disponibili. Scegli un valore che bilanci l'efficienza dello storage con il flusso di lavoro di debug. -
L'impostazione è a livello di cluster. La conservazione si applica a tutti gli eventi, inclusa la pianificazione dei pod, le condizioni dei nodi e gli eventi di scalabilità, in ogni namespace. Non è possibile impostare periodi di conservazione diversi per namespace.
Server API: intervallo di porte del nodo di servizio
Kubernetes assegna una porta da questo intervallo su ogni nodo per ogni servizio che ne ha bisogno. Ciò include i servizi di tipo NodePort e, per impostazione predefinita, i servizi di tipo. LoadBalancer
| Campo | Description | Valori supportati | Predefinita |
|---|---|---|---|
|
|
La porta più bassa dell'intervallo. |
Da |
|
|
|
La porta più alta dell'intervallo. |
Da |
|
minPortdeve essere minore o uguale amaxPort. Amazon EKS rifiuta una configurazione in cui minPort è maggiore dimaxPort.
Modificando l'intervallo, puoi allineare l'allocazione delle porte dei nodi con le politiche di rete e firewall già applicate dalla tua organizzazione. L'ampliamento dell'intervallo aumenta anche il numero di servizi che un singolo cluster è in grado di supportare. Questo parametro è particolarmente utile durante le migrazioni. Le applicazioni che passano ad Amazon EKS e i client che le chiamano spesso si aspettano servizi su porte fisse specifiche. Quando tali porte non rientrano nell'intervallo predefinito, le opzioni usuali sono modificare l'applicazione o posizionarla davanti a un proxy. L'allineamento dell'intervallo con le porte già utilizzate dalle applicazioni elimina il lavoro, quindi è possibile spostare i carichi di lavoro su EKS senza riscriverli o aggiungere componenti di rete da mantenere.
Perché l'intervallo è limitato a 10260 e 32767
Il limite inferiore di 10260 mantiene l'NodePortallocazione libera dalle porte già utilizzate dai componenti del sistema Kubernetes sui nodi, tra cui kubelet health port (10248) e kube-proxy health check port (). 10256
Il limite superiore di 32767 mantiene l'intervallo libero dall'intervallo di porte temporanee di Linux, che in genere inizia alle. 32768 Se a NodePort rientrasse nell'intervallo temporaneo, il kernel potrebbe selezionare quella porta per una connessione in uscita dal nodo e entrare in conflitto con il servizio.
Considerazioni sull'intervallo di porte del nodo di servizio
-
I servizi esistenti mantengono le porte assegnate. Se riduci l'intervallo, i servizi che hanno già una porta al di fuori del nuovo intervallo continuano a funzionare e kube-proxy continua a indirizzare il traffico verso di essi. Amazon EKS non riassegna le porte per i servizi esistenti quando l'intervallo cambia.
-
La ricreazione di un servizio ne rialloca la porta. Se un servizio che contiene una porta fuori portata viene eliminato e ricreato, tale porta non può più essere assegnata. Pianificate questa operazione prima di restringere l'intervallo da cui dipendono i servizi esistenti, in particolare se il processo di distribuzione ricrea i servizi anziché aggiornarli.
-
Le nuove allocazioni al di fuori dell'intervallo vengono rifiutate. La creazione o l'aggiornamento di un servizio che richiede una porta al di fuori dell'intervallo configurato non riesce con un errore di convalida dal server API.
-
Anche le porte specificate in modo esplicito vengono convalidate. Se un servizio specifica direttamente un
nodePortvalore anziché lasciare che Kubernetes ne assegni uno, quella porta deve rientrare nell'intervallo configurato. Una richiesta di porta statica al di fuori dell'intervallo viene rifiutata, anche se la stessa porta era valida in un intervallo più ampio configurato in precedenza. -
L'intervallo è esteso a tutto il cluster. Non è possibile configurare intervalli diversi per namespace diversi.
Prima di modificare questo parametro, verificate che i gruppi di sicurezza e gli ACL di rete consentano il traffico sul nuovo intervallo e che l'intervallo non sia in conflitto con le porte utilizzate da altri software sui nodi.
Considerazioni
Prima di configurare i parametri avanzati del piano di controllo, consulta quanto segue.
-
Cluster-wide ambito: i parametri del piano di controllo si applicano all'intero cluster e a tutti i carichi di lavoro in esecuzione su di esso. Non è possibile applicarli a singoli namespace o carichi di lavoro. Verifica le modifiche ai parametri in un cluster non di produzione prima di applicarle alla produzione.
-
Il Provisioned Control Plane è necessario per il periodo di sincronizzazione di Horizontal Pod Autoscaler e la soglia di garbage collection del pod è terminata. I
terminatedPodGcThresholdparametrihorizontalPodAutoscalerSyncPeriodand sono disponibili solo sui cluster che utilizzano Amazon EKS Provisioned Control Plane. Amazon EKS limita i parametri che aumentano sostanzialmente il consumo di risorse del piano di controllo ai cluster con capacità del piano di controllo preallocata. L'impostazione di uno dei due parametri su un cluster in modalità piano di controllo standard non riesce. Per utilizzarli, sposta innanzitutto il cluster su un livello di scalabilità del Provisioned Control Plane. Per ulteriori informazioni, consulta Piano di controllo predisposto di Amazon EKS. -
Restrizione di uscita per il periodo di sincronizzazione di Horizontal Pod Autoscaler e termine della soglia di garbage collection del pod: se
horizontalPodAutoscalerSyncPeriodoterminatedPodGcThresholdè impostato su un valore diverso da quello predefinito, non puoi spostare il piano di controllo del cluster dalla modalità Provisioned alla modalità Standard. Per tornare alla modalità Standard, prima imposta entrambi i parametri sui valori predefiniti (15se12500), quindi modifica il livello di scala del piano di controllo su.standard -
Ritorno ai valori predefiniti: Amazon EKS non fornisce un'operazione di ripristino dedicata e l'omissione di un campo da un aggiornamento ne mantiene il valore corrente anziché cancellarlo. Per riportare un parametro ai valori predefiniti, impostalo esplicitamente sul valore predefinito. Recupera il valore predefinito con la versione
DescribeClusterVersionsdi Kubernetes eseguita dal cluster. Per ulteriori informazioni, consulta Configurazione dei parametri avanzati del piano di controllo Kubernetes. -
Semantica degli aggiornamenti: gli aggiornamenti si fondono con la configurazione esistente. Solo i campi specificati vengono modificati e i campi omessi mantengono i valori correnti. Ciò vale sia per tutti i componenti che all'interno di un singolo componente. Ad esempio, un aggiornamento che specifica solo la configurazione dello scheduler lascia invariata la configurazione del controller manager e del server API.
-
Visualizzazione della configurazione corrente: l'
describe-clusteroperazione restituisce la configurazione completa in esecuzione sul piano di controllo, inclusi i parametri non personalizzati e i relativi valori predefiniti. -
I valori predefiniti e supportati possono cambiare tra le versioni di Kubernetes: i valori documentati in questo argomento si applicano alle versioni di Kubernetes disponibili al momento della pubblicazione.
DescribeClusterVersionsDa utilizzare per recuperare i valori predefiniti e supportati correnti per ogni parametro e versione di Kubernetes. Consulta Configurazione dei parametri avanzati del piano di controllo Kubernetes. -
I cluster esistenti sono invariati: Amazon EKS non modifica il comportamento dei cluster esistenti. Tutti i cluster continuano a funzionare con i valori dei parametri predefiniti finché non si imposta esplicitamente un parametro.
-
Le modifiche non vengono applicate istantaneamente: una modifica della configurazione non è effettiva al momento
UpdateClusterConfigdella restituzione. Amazon EKS applica la nuova configurazione tramite un aggiornamento continuo del piano di controllo, quindi aspettati alcuni minuti prima che la modifica abbia effetto completo. Il cluster ritorna alloACTIVEstato una volta completato l'aggiornamento. È possibile tenere traccia dei progressi utilizzando l'DescribeUpdateoperazione o bloccarla fino al completamento della modifica utilizzando.aws eks wait cluster-active -
Verificabilità: Amazon EKS convalida ogni configurazione prima di applicarla e registra le modifiche alla configurazione. AWS CloudTrail
-
Supporto per gli strumenti: la configurazione avanzata del piano di controllo Kubernetes è disponibile tramite eksctl, AWS CLI Console di gestione AWS, API Amazon EKS e CDK al momento del lancio. AWS CloudFormation AWS Il supporto per AWS Controllers for Kubernetes (ACK) e Terraform sarà presto disponibile.
-
Supporto della versione Kubernetes: la configurazione avanzata del piano di controllo Kubernetes è supportata su cluster nuovi ed esistenti che eseguono Kubernetes versione 1.31 o successiva.
-
AWS Supporto per regione: la configurazione avanzata del piano di controllo Kubernetes è disponibile in tutte le regioni AWS commerciali, nelle regioni (Stati Uniti) e nelle regioni della Cina in cui è disponibile Amazon EKS. AWS GovCloud AWS
-
Prezzi: non sono previsti costi aggiuntivi per la configurazione dei parametri del piano di controllo. L'utilizzo
horizontalPodAutoscalerSyncPeriodrichiede il Provisioned Control Plane, che viene fatturato alla tariffa oraria per il livello di scalabilità. Per ulteriori informazioni, consultare Prezzi di Amazon EKS.
Fasi successive
-
Configurazione dei parametri avanzati del piano di controllo Kubernetes— Imposta e visualizza i parametri del piano di controllo utilizzando la AWS CLI e. Console di gestione AWS
-
Piano di controllo predisposto di Amazon EKS— capacità Pre-allocate del piano di controllo per prestazioni prevedibili e elevate.
