Concetti Kubernetes

Distribuisci le applicazioni su più macchine (utilizzando contenitori distribuiti nei pod)

Monitora lo stato dei container e riavvia i container guasti

Aumenta e riduci i contenitori in base al carico

Aggiorna i contenitori con nuove versioni

Alloca le risorse tra i contenitori

Bilancia il traffico tra le macchine

Containerizzato: Kubernetes è uno strumento di orchestrazione dei container. Per utilizzarloKubernetes, devi prima avere le tue applicazioni containerizzate. A seconda del tipo di applicazione, potrebbe trattarsi di un insieme di microservizi, di processi in batch o in altre forme. Le applicazioni possono quindi trarre vantaggio da un Kubernetes flusso di lavoro che comprende un enorme ecosistema di strumenti, in cui i contenitori possono essere archiviati come immagini in un registro di contenitori, distribuiti in un Kubernetescluster ed eseguiti su un nodo disponibile. È possibile creare e testare singoli contenitori sul computer locale utilizzando Docker o un altro container runtime, prima di distribuirli nel cluster. Kubernetes

Scalabile: se la richiesta delle applicazioni supera la capacità delle istanze in esecuzione di tali applicazioni, Kubernetes è in grado di scalare verso l'alto. Se necessario, Kubernetes è in grado di stabilire se le applicazioni richiedono più CPU memoria e rispondere espandendo automaticamente la capacità disponibile o utilizzando una maggiore capacità esistente. La scalabilità può essere eseguita a livello di Pod, se è disponibile una quantità di calcolo sufficiente per eseguire solo più istanze dell'applicazione (scalabilità automatica orizzontale dei Pod), oppure a livello di nodo, se è necessario attivare più nodi per gestire l'aumento della capacità (Cluster Autoscaler o Karpenter). Poiché la capacità non è più necessaria, questi servizi possono eliminare i Pod non necessari e chiudere i nodi non necessari.

Disponibile: se un'applicazione o un nodo non sono integri o non sono disponibili, Kubernetes possono spostare i carichi di lavoro in esecuzione su un altro nodo disponibile. Puoi forzare il problema semplicemente eliminando un'istanza in esecuzione di un carico di lavoro o di un nodo che esegue i tuoi carichi di lavoro. La conclusione è che i carichi di lavoro possono essere trasferiti in altre posizioni se non possono più essere eseguiti dove si trovano.

Dichiarativo: Kubernetes utilizza la riconciliazione attiva per verificare costantemente che lo stato dichiarato per il cluster corrisponda allo stato effettivo. Applicando Kubernetesoggetti a un cluster, in genere tramite file YAML di configurazione formattati, puoi, ad esempio, chiedere di avviare i carichi di lavoro che desideri eseguire sul cluster. Successivamente puoi modificare le configurazioni per fare qualcosa come utilizzare una versione successiva di un contenitore o allocare più memoria. Kubernetesfarà ciò che deve fare per stabilire lo stato desiderato. Ciò può includere l'attivazione o la disattivazione dei nodi, l'arresto e il riavvio dei carichi di lavoro o l'estrazione di contenitori aggiornati.

Componibile: poiché un'applicazione è in genere composta da più componenti, è necessario essere in grado di gestire insieme un insieme di questi componenti (spesso rappresentati da più contenitori). Sebbene Docker Compose offra un modo per farlo direttamente conDocker, il comando Kubernetes Kompose può aiutarti a farlo con. Kubernetes Vedi Translate a Docker Compose File to Kubernetes Resources per un esempio di come eseguire questa operazione.

Estensibile: a differenza del software proprietario, il Kubernetes progetto open source è progettato per essere aperto all'utente e può essere esteso in Kubernetes qualsiasi modo si desideri per soddisfare le proprie esigenze. APIse i file di configurazione sono suscettibili di modifiche dirette. Le terze parti sono incoraggiate a scrivere i propri controller, per estendere sia l'infrastruttura che le funzionalità dell'utente finale. Kubernetes I webhook consentono di configurare le regole dei cluster per applicare le politiche e adattarsi alle mutevoli condizioni. Per altre idee su come estendere i Kubernetes cluster, consulta Extending. Kubernetes

Portatile: molte organizzazioni hanno standardizzato le proprie operazioni Kubernetes perché ciò consente loro di gestire tutte le esigenze applicative nello stesso modo. Gli sviluppatori possono utilizzare le stesse pipeline per creare e archiviare applicazioni containerizzate. Queste applicazioni possono quindi essere distribuite in Kubernetes cluster in esecuzione in locale, nel cloud, sui point-of-sales terminali dei ristoranti o su IOT dispositivi distribuiti tra i siti remoti dell'azienda. La sua natura open source consente alle persone di sviluppare queste Kubernetes distribuzioni speciali, insieme agli strumenti necessari per gestirle.

Hardware: se non disponi di hardware disponibile Kubernetes per l'esecuzione in base alle tue esigenze, un provider di servizi cloud come AWS Amazon EKS può farti risparmiare sui costi iniziali. Con AmazonEKS, ciò significa che puoi utilizzare le migliori risorse cloud offerte da AWS, tra cui istanze di computer (Amazon Elastic Compute Cloud), il tuo ambiente privato (AmazonVPC), la gestione centralizzata di identità e autorizzazioni (IAM) e lo storage (Amazon). EBS AWS gestisce i computer, le reti, i data center e tutti gli altri componenti fisici necessari per l'esecuzione. Kubernetes Allo stesso modo, non è necessario pianificare il data center per gestire la capacità massima nei giorni di maggiore richiesta. Per Amazon EKS Anywhere o altri Kubernetes cluster locali, sei responsabile della gestione dell'infrastruttura utilizzata nelle tue Kubernetes distribuzioni, ma puoi comunque contare su di te AWS per tenerti Kubernetes aggiornato.

Gestione del piano di controllo: Amazon EKS gestisce la sicurezza e la disponibilità del piano di Kubernetes controllo AWS ospitato, che è responsabile della pianificazione dei container, della gestione della disponibilità delle applicazioni e di altre attività chiave, in modo che tu possa concentrarti sui carichi di lavoro delle applicazioni. In caso di guasto del cluster, AWS dovresti disporre dei mezzi per ripristinarlo in uno stato di esecuzione. Per Amazon EKS Anywhere, gestiresti tu stesso il piano di controllo.

Upgrade testati: quando aggiorni i tuoi cluster, puoi fare affidamento su Amazon o EKS Amazon EKS Anywhere per fornire versioni testate delle loro Kubernetes distribuzioni.

Componenti aggiuntivi: esistono centinaia di progetti progettati per estenderli e utilizzarli, Kubernetes che puoi aggiungere all'infrastruttura del cluster o utilizzare per facilitare l'esecuzione dei tuoi carichi di lavoro. Invece di creare e gestire autonomamente questi componenti aggiuntivi, AWS fornisce EKScomponenti aggiuntivi Amazon che puoi utilizzare con i tuoi cluster. Amazon EKS Anywhere fornisce pacchetti curati che includono versioni di molti progetti open source popolari. Quindi non è necessario creare il software da soli o gestire patch di sicurezza, correzioni di bug o aggiornamenti critici. Allo stesso modo, se le impostazioni predefinite soddisfano le vostre esigenze, è normale che sia necessaria una configurazione minima di tali componenti aggiuntivi. Vedi Extend Clusters per i dettagli sull'estensione del cluster con componenti aggiuntivi.

Piano di controllo gestito: AWS assicura che il EKS cluster Amazon sia disponibile e scalabile perché gestisce il piano di controllo per te e lo rende disponibile in tutte le zone di AWS disponibilità.

Gestione dei nodi: invece di aggiungere nodi manualmente, puoi fare in modo che Amazon EKS crei i nodi automaticamente secondo necessità, utilizzando Managed Node Groups o Karpenter. I Managed Node Groups hanno integrazioni con Kubernetes Cluster Autoscaling. Utilizzando gli strumenti di gestione dei nodi, puoi sfruttare i risparmi sui costi, ad esempio le istanze Spot e il consolidamento dei nodi, e la disponibilità, utilizzando le funzionalità di pianificazione per impostare la modalità di distribuzione dei carichi di lavoro e la selezione dei nodi.

Rete in cluster: utilizzando CloudFormation modelli, eksctl configura la rete tra i componenti del piano di controllo e del piano dati (nodo) nel cluster. Kubernetes Configura inoltre gli endpoint attraverso i quali possono avvenire le comunicazioni interne ed esterne. Per maggiori dettagli, consulta Demistifying cluster networking for Amazon EKS Worker Nodes. Le comunicazioni tra i Pod in Amazon EKS vengono effettuate utilizzando Amazon EKS Pod Identities, che consente ai Pod di attingere ai metodi AWS cloud per la gestione di credenziali e autorizzazioni.

Componenti aggiuntivi: Amazon ti EKS evita di dover creare e aggiungere componenti software comunemente usati per supportare i Kubernetes cluster. Ad esempio, quando crei un EKS cluster Amazon dalla console di AWS gestione, vengono aggiunti automaticamente Amazon EKS kube-proxy, il VPC CNI plug-in Amazon per e i componenti aggiuntivi Kubernetes Core. DNS Consulta EKSi componenti aggiuntivi di Amazon per ulteriori informazioni su questi componenti aggiuntivi, incluso un elenco dei componenti aggiuntivi disponibili.

Comunicazione con i componenti del cluster (APIserver): il API server (kube-apiserver) espone il sistema in Kubernetes API modo che le richieste al cluster possano essere effettuate sia dall'interno che dall'esterno del cluster. In altre parole, le richieste di aggiunta o modifica degli oggetti di un cluster (Pods, Services, Nodes e così via) possono provenire da comandi esterni, come le richieste di esecuzione di un Pod. kubectl Allo stesso modo, è possibile effettuare richieste dal API server ai componenti all'interno del cluster, ad esempio una richiesta al kubelet servizio per lo stato di un Pod.

Archivia dati sul cluster (etcdkey value store): il etcd servizio svolge il ruolo fondamentale di tenere traccia dello stato attuale del cluster. Se il etcd servizio diventasse inaccessibile, non sarebbe possibile aggiornare o interrogare lo stato del cluster, anche se i carichi di lavoro continuerebbero a funzionare per un po'. Per questo motivo, i cluster critici in genere dispongono di più istanze del etcd servizio con bilanciamento del carico in esecuzione contemporaneamente ed eseguono backup periodici del etcd Key Value Store in caso di perdita o danneggiamento dei dati. Tieni presente che, in AmazonEKS, tutto questo viene gestito automaticamente per te per impostazione predefinita. Amazon EKS Anywhere fornisce istruzioni per il backup e il ripristino di etcd. Consulta il modello di etcd dati per scoprire come etcd gestisce i dati.

Schedule Pods to nodes (Scheduler): le richieste di avvio o arresto di un Pod in Kubernetes vengono indirizzate allo KubernetesScheduler (kube-scheduler). Poiché un cluster può avere più nodi in grado di eseguire il Pod, spetta allo Scheduler scegliere su quale nodo (o nodi, nel caso delle repliche) eseguire il Pod. Se la capacità disponibile non è sufficiente per eseguire il Pod richiesto su un nodo esistente, la richiesta avrà esito negativo, a meno che non siano state prese altre disposizioni. Tali disposizioni potrebbero includere l'abilitazione di servizi come Managed Node Groups o Karpenter in grado di avviare automaticamente nuovi nodi per gestire i carichi di lavoro.

Mantieni i componenti nello stato desiderato (Controller Manager): Kubernetes Controller Manager viene eseguito come processo daemon (kube-controller-manager) per monitorare lo stato del cluster e apportare modifiche al cluster per ristabilire gli stati previsti. In particolare, esistono diversi controller che controllano diversi Kubernetes oggetti, tra cui astatefulset-controller, endpoint-controllercronjob-controller, node-controller e altri.

Gestione delle risorse cloud (Cloud Controller Manager): le interazioni tra Kubernetes e il provider cloud che esegue le richieste per le risorse del data center sottostanti vengono gestite da Cloud Controller Manager () cloud-controller-manager. I controller gestiti da Cloud Controller Manager possono includere un controller di percorso (per configurare i percorsi di rete cloud), un controller di servizio (per l'utilizzo dei servizi di bilanciamento del carico nel cloud) e un controller del ciclo di vita dei nodi (per mantenere i nodi sincronizzati con Kubernetes per tutto il loro ciclo di vita).

Gestisci ogni nodo (kubelet): il API server comunica con il servizio kubelet in esecuzione su ciascun nodo per assicurarsi che il nodo sia registrato correttamente e che i Pod richiesti dallo Scheduler siano in esecuzione. Il kubelet può leggere i manifest dei Pod e configurare volumi di archiviazione o altre funzionalità necessarie ai Pod sul sistema locale. Può anche verificare lo stato dei container in esecuzione localmente.

Esegui contenitori su un nodo (runtime del contenitore): il Container Runtime su ciascun nodo gestisce i contenitori richiesti per ogni Pod assegnato al nodo. Ciò significa che può estrarre le immagini del contenitore dal registro appropriato, eseguire il contenitore, interromperlo e rispondere alle domande sul contenitore. Il runtime predefinito del contenitore è containerd. A partire dalla Kubernetes 1.24, la speciale integrazione di Docker (dockershim) che poteva essere utilizzata come runtime del contenitore è stata eliminata. Kubernetes Sebbene sia ancora possibile Docker utilizzarlo per testare ed eseguire contenitori sul sistema locale, per utilizzarlo Docker con ora Kubernetes è necessario installare Docker Engine su ciascun nodo con Kubernetes cui utilizzarlo.

Gestione della rete tra contenitori (kube-proxy): per poter supportare la comunicazione tra Pod tramite i Servizi, era Kubernetes necessario un modo per configurare le reti Pod per tenere traccia degli indirizzi IP e delle porte associate a tali Pod. Il servizio kube-proxy funziona su ogni nodo per consentire la comunicazione tra i Pod.

Un'immagine di base: un'immagine contenitore di base è un contenitore che viene in genere creato da una versione minima del file system di un sistema operativo (come Red Hat Enterprise Linux o Ubuntu) o da un sistema minimale migliorato per fornire software per eseguire tipi specifici di applicazioni (come nodejs o app python).

Software applicativo: puoi aggiungere il tuo software applicativo al tuo contenitore più o meno nello stesso modo in cui lo aggiungeresti a un sistema Linux. Ad esempio, nel tuo Dockerfile puoi eseguire npm e yarn installare un'applicazione Java o yum dnf installare RPM pacchetti. In altre parole, utilizzando un RUN comando in un Dockerfile, è possibile eseguire qualsiasi comando disponibile nel file system dell'immagine di base per installare software o configurare software all'interno dell'immagine contenitore risultante.

Istruzioni: il riferimento a Dockerfile descrive le istruzioni che è possibile aggiungere a un Dockerfile durante la configurazione. Queste includono le istruzioni utilizzate per creare ciò che è contenuto nel contenitore stesso (ADDo nei COPY file dal sistema locale), identificare i comandi da eseguire quando il contenitore viene eseguito (CMDoENTRYPOINT) e connettere il contenitore al sistema su cui viene eseguito (identificando il contenitore da USER eseguire, un locale da montare o le VOLUME porte su cui eseguire). EXPOSE

Archiviazione: quando un contenitore in esecuzione viene interrotto ed eliminato, l'archiviazione dei dati in quel contenitore scompare, a meno che non si configuri uno spazio di archiviazione più permanente. Kubernetessupporta molti tipi di storage diversi e li riassume sotto l'egida di Volumes. I tipi di storage includono CephFS NFS, i e altri. SCSI È anche possibile utilizzare un dispositivo a blocchi locale dal computer locale. Con uno di questi tipi di archiviazione disponibili nel cluster, è possibile montare il volume di archiviazione su un punto di montaggio selezionato nel file system del contenitore. Un volume persistente è quello che continua a esistere dopo l'eliminazione del Pod, mentre un volume temporaneo viene eliminato quando il Pod viene eliminato. Se l'amministratore del cluster ne ha creati diversi StorageClassesper il cluster, potreste avere la possibilità di scegliere gli attributi dello storage da utilizzare, ad esempio se il volume viene eliminato o recuperato dopo l'uso, se si espanderà se è necessario più spazio e anche se soddisfa determinati requisiti di prestazioni.

Segreti: rendendo disponibili Secrets ai contenitori nelle specifiche di Pod, puoi fornire le autorizzazioni necessarie a tali contenitori per accedere a file system, database o altre risorse protette. Chiavi, password e token sono tra gli elementi che possono essere archiviati come segreti. L'uso dei segreti consente di non dover memorizzare queste informazioni nelle immagini dei contenitori, ma è sufficiente rendere i segreti disponibili ai contenitori in esecuzione. Simili a Secrets lo sono ConfigMaps. A ConfigMap tende a contenere informazioni meno critiche, come coppie chiave-valore per la configurazione di un servizio.

Risorse del contenitore: gli oggetti per un'ulteriore configurazione dei contenitori possono assumere la forma di configurazione delle risorse. Per ogni contenitore, puoi richiedere la quantità di memoria CPU che può utilizzare, nonché porre limiti alla quantità totale di tali risorse che il contenitore può utilizzare. Vedi Gestione delle risorse per pod e contenitori per esempi.

Interruzioni: i pod possono essere interrotti involontariamente (un nodo non funziona) o volontariamente (è necessario un aggiornamento). Configurando un budget per le interruzioni dei Pod, puoi esercitare un certo controllo sulla disponibilità dell'applicazione in caso di interruzioni. Per alcuni esempi, vedi Specificazione di un budget per le interruzioni per la tua applicazione.

Namespace: Kubernetes offre diversi modi per isolare Kubernetes componenti e carichi di lavoro l'uno dall'altro. L'esecuzione di tutti i Pod per una particolare applicazione nello stesso namespace è un modo comune per proteggere e gestire tali Pod insieme. È possibile creare spazi dei nomi personalizzati da utilizzare o scegliere di non indicare uno spazio dei nomi (il che comporta l'utilizzo dello spazio dei nomi). Kubernetes default Kubernetesi componenti del piano di controllo in genere vengono eseguiti nello spazio dei nomi. kube-system

Applicazioni stateless: un'applicazione stateless non salva i dati della sessione di un client, quindi un'altra sessione non deve fare riferimento a ciò che è accaduto a una sessione precedente. In questo modo è più semplice sostituire i Pod con altri nuovi se non funzionano bene o spostarli senza salvarne lo stato. Se stai eseguendo un'applicazione stateless (come un server web), puoi utilizzare un Deployment per distribuire Pods e. ReplicaSets A ReplicaSet definisce quante istanze di un Pod vuoi che vengano eseguite contemporaneamente. Sebbene sia possibile eseguire ReplicaSet direttamente un Pod, è normale eseguire le repliche direttamente all'interno di un Deployment, per definire quante repliche di un Pod devono essere eseguite contemporaneamente.

Applicazioni con stato: un'applicazione con stato è un'applicazione in cui l'identità del Pod e l'ordine in cui i Pod vengono avviati sono importanti. Queste applicazioni necessitano di uno storage persistente che sia stabile e che debba essere distribuito e scalato in modo coerente. Per distribuire un'applicazione stateful inKubernetes, puoi usare. StatefulSets Un esempio di applicazione che in genere viene eseguita come un database StatefulSet . All'interno di a StatefulSet, è possibile definire le repliche, il Pod e i relativi contenitori, i volumi di archiviazione da montare e le posizioni nel contenitore in cui vengono archiviati i dati. Vedi Run a Replicated Stateful Application per un esempio di database distribuito come. ReplicaSet

Applicazioni per nodo: a volte è necessario eseguire un'applicazione su ogni nodo del cluster. Kubernetes Ad esempio, il data center potrebbe richiedere che ogni computer esegua un'applicazione di monitoraggio o un particolare servizio di accesso remoto. Ad Kubernetes esempio, è possibile utilizzare DaemonSeta per garantire che l'applicazione selezionata venga eseguita su ogni nodo del cluster.

Le applicazioni vengono eseguite fino al completamento: ci sono alcune applicazioni che si desidera eseguire per completare una determinata attività. Ciò potrebbe includere uno che esegue report mensili sullo stato o elimina i vecchi dati. Un oggetto Job può essere utilizzato per configurare un'applicazione per l'avvio e l'esecuzione, quindi uscire al termine dell'attività. Un CronJoboggetto consente di configurare un'applicazione in modo che venga eseguita a un'ora, un minuto, un giorno del mese, del mese o del giorno della settimana specifici, utilizzando una struttura definita dal crontabformato Linux.

Servizi: poiché un Pod può spostarsi su nodi e indirizzi diversi, un altro Pod che deve comunicare con il primo Pod potrebbe avere difficoltà a trovare dove si trova. Per risolvere questo problema, Kubernetes consente di rappresentare un'applicazione come servizio. Con un servizio, è possibile identificare un Pod o un set di Pod con un nome particolare, quindi indicare quale porta espone il servizio di quell'applicazione dal Pod e quali porte potrebbe utilizzare un'altra applicazione per contattare quel servizio. Un altro Pod all'interno di un cluster può semplicemente richiedere un servizio per nome e Kubernetes indirizzare la richiesta alla porta appropriata per un'istanza del Pod che esegue quel servizio.

Ingress: Ingress è ciò che può rendere disponibili le applicazioni rappresentate dai Kubernetes Servizi ai client che si trovano all'esterno del cluster. Le funzionalità di base di Ingress includono un bilanciamento del carico (gestito da Ingress), il controller Ingress e regole per il routing delle richieste dal controller al Servizio. Esistono diversi controller di ingresso tra cui scegliere. Kubernetes

Crea un cluster semplice

Crea un cluster più complesso

Implementa un'applicazione di esempio

Esplora i modi per gestire il tuo cluster