Capire l’architettura di Kubernetes

Impariamo in dettaglio l’architettura di Kubernetes.


Presumo che tu abbia una conoscenza di base di Kubernetes. In caso contrario, consulta i seguenti articoli di introduzione e installazione.

Introduzione a Kubernetes per principianti

Come installare Kubernetes su Ubuntu 18?

kubernetes segue l’architettura master-slave. L’architettura di Kubernetes ha un nodo principale e nodi di lavoro. Ci sono quattro componenti di a nodo principale.

  • Server API Kube
  • controllore
  • scheduler
  • etcd

E il nodo lavoratore ha tre componenti.

  • kubelet
  • Kube-proxy
  • runtime del contenitore

Ecco come appare un’architettura Kubernetes:

architettura di kubernetes

Lascia che ti spieghi in dettaglio i componenti del nodo master e dei nodi worker.

Nodo principale

Il nodo principale gestisce il cluster Kubernetes ed è il punto di ingresso per tutte le attività amministrative. È possibile parlare con il nodo principale tramite l’interfaccia della riga di comando, la GUI o l’API. Per raggiungere la tolleranza d’errore, nel cluster possono essere presenti più nodi principali. Quando avessimo più di un nodo master, ci sarebbe una modalità ad alta disponibilità e con un leader che eseguiva tutte le operazioni. Tutti gli altri nodi principali sarebbero i follower di quel nodo principale leader.

Inoltre, per gestire lo stato del cluster, Kubernetes utilizza etcd. Tutti i nodi master si connettono a etcd, che è un archivio valori-chiave distribuito.

nodo principale di kubernetes

Lascia che ti spieghi tutti questi componenti uno per uno.

Server API

Il server API esegue tutte le attività amministrative sul nodo principale. Un utente invia i comandi restanti al server API, che quindi convalida le richieste, quindi le elabora e le esegue. etcd salva lo stato risultante del cluster come archivio valori-chiave distribuito.

Scheduler

Dopodiché, abbiamo un programmatore. Come suggerisce il nome, lo scheduler pianifica il lavoro su diversi nodi di lavoro. Ha le informazioni sull’utilizzo delle risorse per ciascun nodo di lavoro. Lo scheduler considera anche i requisiti di qualità del servizio, la localizzazione dei dati e molti altri parametri simili. Quindi lo scheduler pianifica il lavoro in termini di pod e servizi.

Responsabile del controller

I loop di controllo non terminanti che regolano lo stato del cluster Kubernetes sono gestiti da Control Manager. Ora, ciascuno di questi loop di controllo conosce lo stato desiderato dell’oggetto che gestisce e quindi osserva il loro stato corrente attraverso i server API.

In un circuito di controllo, se lo stato desiderato non soddisfa lo stato corrente dell’oggetto, il circuito di controllo esegue i passaggi correttivi per portare lo stato corrente allo stesso modo dello stato desiderato. Pertanto, il controller manager si assicura che lo stato corrente sia uguale allo stato desiderato.

etcd

Etcd è un archivio valori-chiave distribuito utilizzato per archiviare lo stato del cluster. Quindi, o deve far parte del master Kubernetes, oppure è possibile configurarlo anche esternamente. etcd è scritto nel goLang e si basa su Consenso della zattera algoritmo.

La zattera consente alla raccolta di macchine di funzionare come un gruppo coerente che può sopravvivere ai fallimenti di alcuni dei suoi membri. Anche se alcuni membri non funzionano, questo algoritmo può comunque funzionare in qualsiasi momento. Uno dei nodi nel gruppo sarà il master e il resto saranno i follower.

Può esserci un solo maestro e tutti gli altri maestri devono seguire quel maestro. Oltre a memorizzare lo stato del cluster, etcd viene anche utilizzato per memorizzare i dettagli di configurazione come le sottoreti e le mappe di configurazione.

Nodo lavoratore

Un nodo di lavoro è un server virtuale o fisico che esegue le applicazioni ed è controllato dal nodo principale. I pod sono pianificati sui nodi di lavoro, che dispongono degli strumenti necessari per eseguirli e collegarli. I baccelli non sono altro che una raccolta di contenitori.

E per accedere alle applicazioni dal mondo esterno, è necessario connettersi ai nodi di lavoro e non ai nodi principali.

nodo di lavoro kubernetes

Esploriamo i componenti del nodo di lavoro.

Runtime del contenitore

Il runtime del contenitore viene sostanzialmente utilizzato per eseguire e gestire un ciclo di vita continuo sul nodo di lavoro. Alcuni esempi di runtime dei container che posso fornirti sono i container rkt, lxc, ecc. Si osserva spesso che la finestra mobile viene anche definita runtime contenitore, ma per essere precisi, lascia che ti dica che la finestra mobile è una piattaforma che utilizza i contenitori come runtime del contenitore.

Kubelet

Kubelet è fondamentalmente un agente che gira su ciascun nodo di lavoro e comunica con il nodo principale. Quindi, se hai dieci nodi worker, kubelet viene eseguito su ciascun nodo worker. Riceve la definizione del pod in vari modi ed esegue i contenitori associati a quella porta. Inoltre, assicura che i contenitori che fanno parte dei baccelli siano sempre sani.

Il kubelet si collega al runtime del contenitore usando il framework gRPC. Il kubelet si collega all’interfaccia di runtime del contenitore (CRI) per eseguire operazioni di contenitori e immagini. Il servizio di immagine è responsabile di tutte le operazioni relative all’immagine mentre il servizio di runtime è responsabile di tutte le operazioni relative a pod e container. Questi due servizi hanno due diverse operazioni da eseguire.

Lascia che ti dica qualcosa di interessante, i runtime dei container erano codificati in modo rigido in Kubernetes, ma con lo sviluppo di CRI, Kubernetes ora può utilizzare diversi runtime dei container senza la necessità di ricompilare. Pertanto, qualsiasi runtime di container che implementa CRI può essere utilizzato da Kubernetes per gestire pod, container e immagini di container. Docker shim e contenitori CRI sono due esempi di shi CRI. Con lo spessore della finestra mobile, i contenitori vengono creati utilizzando la finestra mobile installata sui nodi di lavoro, quindi la finestra mobile interna utilizza un contenitore per creare e gestire i contenitori

Kube-proxy

Il proxy Kube viene eseguito su ciascun nodo di lavoro come proxy di rete. Ascolta il server API per ogni creazione o eliminazione di punti di servizio. Per ogni punto di servizio, kube-proxy imposta i percorsi in modo che possa raggiungerlo.

Conclusione

Spero che questo ti aiuti a comprendere meglio l’architettura di Kubernetes. Le abilità di Kubernetes sono sempre richieste e se stai cercando di imparare a costruire la carriera, dai un’occhiata a questo Corso Udemy.

TAGS:

  • docker

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map