Concetti su Kubernetes Engine (OKE) e Kubernetes

Un cluster Kubernetes è un gruppo di nodi (macchine che eseguono applicazioni). Ogni nodo può essere una macchina fisica o una macchina virtuale. La capacità del nodo (numero di CPU e quantità di memoria) viene definita quando il nodo viene creato. Un cluster comprende:

• Nodi del piano di controllo (precedentemente denominati "nodi principali"). In genere, ci saranno tre nodi del piano di controllo per l'alta disponibilità.
• Nodi di lavoro organizzati in pool di nodi.

Quando si crea un cluster mediante Kubernetes Engine, è possibile creare il nuovo cluster come cluster di base o come cluster avanzato.

Quando si crea un nuovo cluster con Kubernetes Engine, è necessario specificare il tipo di cluster da creare. È possibile specificare:

• Cluster avanzato: i cluster avanzati supportano tutte le funzioni disponibili, incluse quelle non supportate dai cluster di base (ad esempio, nodi virtuali, gestione dei componenti aggiuntivi del cluster, identità del carico di lavoro e nodi di lavoro aggiuntivi per cluster). I cluster avanzati sono dotati di un Service Level Agreement (SLA) supportato finanziariamente.
• Cluster di base: i cluster di base supportano tutte le funzionalità di base fornite da Kubernetes e Kubernetes Engine, ma nessuna delle funzionalità avanzate offerte da Kubernetes Engine. I cluster di base sono dotati di un service level objective (SLO), ma non di un service level agreement (SLA) supportato finanziariamente.

Tenere presente quanto riportato di seguito durante la creazione dei cluster.

• Quando si utilizza la console per creare un cluster, se non si selezionano funzioni avanzate durante la creazione del cluster, è possibile creare il nuovo cluster come cluster di base. Un nuovo cluster viene creato come cluster avanzato per impostazione predefinita, a meno che non si scelga esplicitamente di creare un cluster di base.
• Quando si utilizza l'interfaccia CLI o l'API per creare un cluster, è possibile specificare se creare un cluster di base o avanzato. Se non si specifica in modo esplicito il tipo di cluster da creare, per impostazione predefinita viene creato un nuovo cluster come cluster di base.

La creazione di un nuovo cluster come cluster avanzato consente di aggiungere facilmente funzionalità avanzate in un secondo momento, anche se inizialmente non è stata selezionata alcuna funzione avanzata. Se si sceglie di creare un nuovo cluster come cluster di base, è comunque possibile scegliere di aggiornare il cluster di base a un cluster avanzato in un secondo momento. Non è tuttavia possibile eseguire il downgrade di un cluster avanzato a un cluster di base.

Vedere Confronto tra cluster avanzati e cluster di base.

Tenere presente che tutti i riferimenti ai 'cluster' nella documentazione di Kubernetes Engine fanno riferimento sia ai cluster avanzati che ai cluster di base, a meno che non sia indicato diversamente.

Il piano di controllo del cluster Kubernetes implementa la funzionalità Kubernetes di base. Viene eseguito sulle istanze di computazione (noti come 'nodi del piano di controllo') nella tenancy del servizio Kubernetes Engine. Il piano di controllo cluster è completamente gestito da Oracle.

Il piano di controllo cluster esegue una serie di processi, tra cui:

• kube-apiserver per supportare le operazioni API Kubernetes richieste dallo strumento della riga di comando Kubernetes (kubectl) e da altri strumenti della riga di comando, nonché da chiamate REST dirette. Il kube-apiserver include controller di ammissione necessari per le operazioni Kubernetes avanzate.
• kube-controller-manager per gestire diversi componenti Kubernetes (ad esempio, controller di replica, controller degli endpoint, controller dello spazio di nomi e controller di serviceaccounts)
• kube-scheduler per controllare dove nel cluster eseguire i job
• etcd per memorizzare i dati di configurazione del cluster
• cloud-controller-manager consente di aggiornare ed eliminare i nodi di lavoro (utilizzando il controller del nodo), di creare load balancer quando vengono creati i servizi Kubernetes di type: LoadBalancer (utilizzando il controller del servizio) e di impostare gli instradamenti di rete (utilizzando il controller di instradamento). OCI-cloud-controller-manager implementa anche un container-storage-interface, un driver flexvolume e un provisioninger flexvolume (per ulteriori informazioni, consultare la documentazione di OCI Cloud Controller Manager (CCM) su GitHub).

L'API Kubernetes consente agli utenti finali di eseguire query e manipolare le risorse Kubernetes (ad esempio pod, spazi di nomi, mappe di configurazione ed eventi).

Puoi accedere all'API Kubernetes sul piano di controllo del cluster tramite un endpoint ospitato in una subnet della tua VCN. Questa subnet dell'endpoint API Kubernetes può essere una subnet privata o pubblica. Se si specifica una subnet pubblica per l'endpoint API Kubernetes, è possibile esporre facoltativamente l'endpoint a Internet assegnando un indirizzo IP pubblico all'endpoint (così come l'indirizzo IP privato). Puoi controllare l'accesso alla subnet dell'endpoint API Kubernetes utilizzando le regole di sicurezza definite per i gruppi di sicurezza di rete (consigliato) o le liste di sicurezza.

I nodi di lavoro costituiscono il piano dati del cluster. I nodi di lavoro consentono di eseguire le applicazioni distribuite in un cluster.

Ogni nodo di lavoro esegue una serie di processi, tra cui:

• kubelet per comunicare con il piano di controllo cluster
• kube-proxy per gestire le regole di rete

I processi del piano di controllo cluster monitorano e registrano lo stato dei nodi di lavoro e distribuiscono le operazioni richieste tra di essi.

Un pool di nodi è un subset di nodi di lavoro all'interno di un cluster che hanno tutti la stessa configurazione. I pool di nodi consentono di creare pool di computer all'interno di un cluster con configurazioni diverse. Ad esempio, è possibile creare un pool di nodi in un cluster come virtual machine e un altro pool di nodi come computer Bare Metal. Un cluster deve avere almeno un pool di nodi, ma un pool di nodi non deve contenere nodi di lavoro.

I nodi di lavoro in un pool di nodi sono connessi a una subnet di nodi di lavoro nella VCN.

Quando si crea un pool di nodi, è necessario specificare che i nodi di lavoro nel pool di nodi vengano creati tutti come nodi virtuali o tutti come nodi gestiti.

Quando si crea un pool di nodi con Kubernetes Engine, è necessario specificare che i nodi di lavoro nel pool di nodi devono essere creati come uno o più dei seguenti:

• Nodi virtuali, completamente gestiti da Oracle. I nodi virtuali offrono un'esperienza Kubernetes 'serverless', che ti consente di eseguire applicazioni containerizzate su larga scala senza il sovraccarico operativo derivante dall'upgrade dell'infrastruttura del piano dati e dalla gestione della capacità dei cluster. È possibile creare solo nodi virtuali nei cluster avanzati.
• Nodi gestiti, in esecuzione su istanze di computazione (bare metal o virtual machine) nella tenancy e almeno in parte gestiti dall'utente. Poiché sei responsabile della gestione dei nodi gestiti, hai la flessibilità di configurarli per soddisfare i tuoi requisiti specifici. Sei responsabile dell'upgrade di Kubernetes sui nodi gestiti e della gestione della capacità del cluster. È possibile creare nodi gestiti sia nei cluster di base che nei cluster avanzati.

Vedere Confronto di nodi virtuali con nodi gestiti.

Tutti i riferimenti a 'nodi' e 'nodi di lavoro' nella documentazione di Kubernetes Engine fanno riferimento sia ai nodi virtuali che ai nodi gestiti, a meno che non sia esplicitamente indicato diversamente.

Per ulteriori informazioni, vedere Utilizzo dei nodi gestiti automaticamente.

Tenere presente che tutti i riferimenti a 'nodi' e 'nodi di lavoro' nella documentazione di Kubernetes Engine riguardano i nodi autogestiti, a meno che non sia esplicitamente indicato diversamente.

Quando un'applicazione in esecuzione su un nodo di lavoro comprende più container, Kubernetes raggruppa i container in un'unica unità logica denominata pod per semplificare la gestione e la ricerca automatica. I contenitori nel pod condividono lo stesso spazio di nomi di rete e lo stesso spazio di storage e possono essere gestiti come un singolo oggetto dal piano di controllo del cluster. Un certo numero di pod che forniscono la stessa funzionalità possono essere raggruppati in un singolo set logico noto come servizio.

I cluster Kubernetes utilizzano i plugin CNI (Container Network Interface) per implementare la connettività di rete per i pod in esecuzione sui nodi di lavoro. I plugin CNI configurano le interfacce di rete, eseguono il provisioning degli indirizzi IP e mantengono la connettività.

Per ulteriori informazioni sui pod, consultare la documentazione di Kubernetes.

In Kubernetes, un servizio è un'astrazione che definisce un set logico di pod e un criterio mediante il quale accedervi. Il set di pod mirati da un servizio è in genere determinato da un selettore.

Per alcune parti di un'applicazione, ad esempio i frontend, è possibile esporre un servizio su un indirizzo IP esterno a un cluster.

Kubernetes ServiceTypes ti consente di specificare il tipo di servizio che desideri esporre. Un LoadBalancer ServiceType crea un load balancer Oracle Cloud Infrastructure sulle subnet del load balancer nella tua VCN.

Per ulteriori informazioni sui servizi in generale, consulta la documentazione di Kubernetes. Per ulteriori informazioni sulla creazione dei servizi del load balancer con Kubernetes Engine, vedere Definizione dei servizi Kubernetes di tipo LoadBalancer.

Kubernetes ha adottato la specifica CNI (Container Network Interface) per la gestione delle risorse di rete. Il CNI è costituito da una specifica e librerie per la scrittura di plugin per configurare interfacce di rete in contenitori Linux, insieme a una serie di plugin supportati.

I cluster Kubernetes utilizzano i plugin CNI (Container Network Interface) per implementare la connettività di rete per i pod in esecuzione sui nodi di lavoro. I plugin CNI configurano le interfacce di rete, eseguono il provisioning degli indirizzi IP e mantengono la connettività.

Per ulteriori informazioni, vedere la documentazione CNI su GitHub.

Un file manifesto Kubernetes comprende istruzioni in un file yaml o json che specificano come distribuire un'applicazione sul nodo o sui nodi in un cluster Kubernetes. Le istruzioni includono informazioni sulla distribuzione di Kubernetes, sul servizio Kubernetes e su altri oggetti Kubernetes da creare nel cluster. Il file manifesto viene comunemente indicato anche come specifica pod o come file deployment.yaml (anche se sono consentiti altri nomi di file). I parametri da includere in un file manifest Kubernetes sono descritti nella documentazione di Kubernetes.

Un controller di ammissione Kubernetes intercetta le richieste autenticate e autorizzate al server API Kubernetes prima di ammettere un oggetto (ad esempio un pod) al cluster. Un controller di ammissione può convalidare un oggetto, modificarlo o entrambi. Molte funzioni avanzate in Kubernetes richiedono un controller di ammissione abilitato. Per ulteriori informazioni, consulta la documentazione di Kubernetes.

La versione Kubernetes selezionata quando si crea un cluster utilizzando Kubernetes Engine determina i controller di ammissione supportati da tale cluster. Per conoscere i controller di ammissione supportati, l'ordine in cui vengono eseguiti nel server API Kubernetes e le versioni Kubernetes in cui sono supportati, vedere Controller di ammissione supportati.

Un cluster Kubernetes può essere organizzato in spazi dei nomi per dividere le risorse del cluster tra più utenti. Inizialmente, un cluster dispone dei seguenti spazi di nomi:

• predefinito per le risorse senza altri spazi di nomi
• kube-system, per le risorse create dal sistema Kubernetes
• kube-node-lease, per un oggetto di leasing per nodo per determinare la disponibilità del nodo
• kube-pubblico, di solito utilizzato per le risorse che devono essere accessibili in tutto il cluster

Per ulteriori informazioni sugli spazi di nomi, consultare la documentazione di Kubernetes.