Kubernetes 1.18 è qui e questi sono i suoi miglioramenti e le novità

Il team di sviluppo di Kubernetes è stato recentemente rilasciato attraverso un annuncio il rilascio di la nuova versione "Kubernetes 1.18" in cui il team di sviluppo menziona che si tratta di una versione "adatta e finita".

In questa nuova versione è stato fatto un lavoro significativo per migliorare la funzionalità beta e stabile per garantire a migliore esperienza utente. È stato fatto lo stesso sforzo per aggiungere nuovi sviluppi e nuove entusiasmanti funzionalità che promettono di migliorare ulteriormente l'esperienza dell'utente.

Per chi non lo sa Kubernetes, dovrebbero saperlo è un sistema open source da automatizzare l'implementazione, il ridimensionamento e la gestione di applicazioni containerizzate.

Era originariamente progettato da Google, sebbene il suo sviluppo sia stato successivamente affidato alla Open Source Cloud Computing Foundation (CNCF), che oggi ha permesso alla tecnologia di orchestrazione dei container di maturare rapidamente, grazie al contributo dei colossi della tecnologia.

Cosa c'è di nuovo in Kubernetes 1.18?

Questa nuova versione si distingue per avere l'estensione capacità di utilizzare i token dell'account di servizio come metodo di autenticazione generale. Ad esempio, se desideri che un pod gestisca altre risorse Kubernetes, come una distribuzione o un servizio, può essere associato a un account di servizio e creare i ruoli e le associazioni di ruoli necessari.

Gli account di servizio Kubernetes (KSA) inviano token Web JSON (JWT) al server API per l'autenticazione. Ciò rende il server API l'unica fonte di autenticazione per gli account di servizio.

Kubernetes 1.18pfornisce funzionalità che consente al server API di fornire un documento di rilevamento OpenID Connect A contenente le chiavi pubbliche del token oltre ad altri metadati.

Un altro cambiamento che si distingue da Kubernetes 1.81 è il possibilità di configurare HPA Velocity per pod specifici. È stato utilizzato il programma di scalabilità automatica pod orizzontale (HPA)a per consentire a un cluster Kubernetes di rispondere automaticamente al traffico alto / basso. Con HPA, l'utente può chiedere al controller di creare più moduli in risposta a picchi della CPU, altre misurazioni o misurazioni fornite dall'applicazione.

Kubernetes 1.18 offre una panoramica dei profili per eseguire più configurazioni del pianificatore. In generale, ci sono due tipi di carichi di lavoro in Kubernetes: servizi a lungo termine (ad esempio, server web, API, ecc.) E attività che vengono eseguite fino al completamento (meglio noto come il nome Lavori).

A causa delle ovvie differenze tra i tipi di carico di lavoro, alcuni utenti ricorrono alla creazione di cluster completi per esigenze diverse. Ad esempio, un cluster per gestire il data mining e un altro per servire le API dell'applicazione.

Il motivo è che hanno bisogno che il processo decisionale sia diverso. Ad esempio, le impostazioni dello scheduler predefinito promuovono la disponibilità elevata.

D'altra parte, possiamo anche trovare il file capacità di definire una regola di pod broadcast a livello di cluster, come ha reso possibile garantire che i pod vengano pianificati nelle zone di disponibilità (a condizione che si utilizzi un cluster multizona) per garantire la massima disponibilità e utilizzo delle risorse.

La funzionalità abilita la specifica topologySpreadConstraints, che identifica le aree cercando i nodi con lo stesso tag topologyKey. I nodi con lo stesso tag TopologyKey appartengono alla stessa area. La configurazione era di distribuire i pod in modo uniforme nelle diverse aree. Tuttavia, lo svantaggio è che questa impostazione deve essere applicata a livello di pod. I pod che non dispongono della configurazione non verranno distribuiti in modo uniforme tra i domini di errore.

Ultimo, ma non per importanza, possiamo anche trovare la possibilità di ignorare la modifica nella proprietà del volume. Per impostazione predefinita, quando un volume viene montato in un contenitore su un cluster Kubernetes, la proprietà di tutti i file e le directory all'interno di questo volume viene modificata nel valore fornito tramite fsGroup.

Tutto questo per consentire a fsGroup di leggere e scrivere il volume. Tuttavia, questo comportamento si è dimostrato indesiderabile in alcuni casi.

Questa nuova versione di Kubernetes include una serie di modifiche e abbiamo menzionato solo alcune delle più importanti. Se vuoi conoscere l'elenco completo puoi farlo visitando il seguente link


Lascia un tuo commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

*

*

  1. Responsabile dei dati: Miguel Ángel Gatón
  2. Scopo dei dati: controllo SPAM, gestione commenti.
  3. Legittimazione: il tuo consenso
  4. Comunicazione dei dati: I dati non saranno oggetto di comunicazione a terzi se non per obbligo di legge.
  5. Archiviazione dati: database ospitato da Occentus Networks (UE)
  6. Diritti: in qualsiasi momento puoi limitare, recuperare ed eliminare le tue informazioni.