Translated architecture to Italian (#13399)
This commit is contained in:
Michele Berardi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
48d5e74984
commit
5a7d1f6c39
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Architettura di Kubernetes"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
@@ -0,0 +1,267 @@
|
||||
---
|
||||
title: Concetti alla base del Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Il concetto CCM (cloud controller manager) (da non confondere con il binario) è stato originariamente creato per consentire al codice del fornitore specifico del cloud e al core Kubernetes di evolversi indipendentemente l'uno dall'altro. Il gestore del controller cloud viene eseguito insieme ad altri componenti principali come il controller controller di Kubernetes, il server API e lo scheduler. Può anche essere avviato come addon di Kubernetes, nel qual caso viene eseguito su Kubernetes.
|
||||
|
||||
Il design del gestore del controller cloud è basato su un meccanismo di plug-in che consente ai nuovi provider cloud di integrarsi facilmente con Kubernetes utilizzando plug-in. Sono in atto piani per l'acquisizione a bordo di nuovi provider di cloud su Kubernetes e per la migrazione dei provider di cloud dal vecchio modello al nuovo modello CCM.
|
||||
|
||||
Questo documento discute i concetti alla base del gestore del controller cloud e fornisce dettagli sulle funzioni associate.
|
||||
|
||||
Ecco l'architettura di un cluster Kubernetes senza il gestore del controller cloud:
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Design
|
||||
|
||||
Nel diagramma precedente, Kubernetes e il provider cloud sono integrati attraverso diversi componenti:
|
||||
|
||||
* Kubelet
|
||||
* Kubernetes controller manager
|
||||
* Kubernetes API server
|
||||
|
||||
|
||||
CCM consolida tutta la logica dipendente dal cloud dai tre componenti precedenti per creare un singolo punto di integrazione con il cloud. La nuova architettura con il CCM si presenta così:
|
||||
|
||||
|
||||
|
||||
## Components of the CCM
|
||||
|
||||
CCM interrompe alcune funzionalità di Kubernetes controller manager (KCM) e lo esegue come processo separato. In particolare, elimina i controller in KCM dipendenti dal cloud. KCM ha i seguenti loop del controller dipendenti dal cloud:
|
||||
|
||||
* Node controller
|
||||
* Volume controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
|
||||
Nella versione 1.9, CCM esegue i seguenti controller dall'elenco precedente:
|
||||
|
||||
* Node controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
|
||||
Inoltre, esegue un altro controller chiamato controller PersistentVolumeLabels. Questo controller è responsabile dell'impostazione delle etichette delle zone e delle regioni su PersistentVolumes creati nei cloud GCP e AWS.
|
||||
|
||||
{{< note >}}
|
||||
Il controller del volume è stato deliberatamente scelto per non far parte di CCM. A causa della complessità e degli sforzi già esistenti per estrapolare la logica del volume specifica del fornitore, è stato deciso che il controller del volume non verrà spostato su CCM.
|
||||
{{< /note >}}
|
||||
|
||||
Il piano originale per supportare i volumi utilizzando CCM era di utilizzare i volumi Flex per supportare volumi collegabili. Tuttavia, è in programma uno sforzo concorrente noto come CSI per sostituire la logica Flex.me, è stato deciso che il controller del volume non verrà spostato su CCM.
|
||||
|
||||
Considerando queste dinamiche, abbiamo deciso di adottare una misurazione dell'interruzione intermedia finché il CSI non è pronto.
|
||||
|
||||
## Functions of the CCM
|
||||
|
||||
Il CCM eredita le sue funzioni da componenti di Kubernetes che dipendono da un provider di cloud. Questa sezione è strutturata in base a tali componenti.
|
||||
|
||||
### 1. Kubernetes controller manager
|
||||
|
||||
La maggior parte delle funzioni del CCM è derivata dal KCM. Come menzionato nella sezione precedente, CCM esegue i seguenti cicli di controllo:
|
||||
|
||||
* Node controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
* PersistentVolumeLabels controller
|
||||
|
||||
#### Node controller
|
||||
|
||||
Il controller del nodo è responsabile per l'inizializzazione di un nodo ottenendo informazioni sui nodi in esecuzione nel cluster dal provider cloud. Il controller del nodo esegue le seguenti funzioni:
|
||||
|
||||
1. Inizializzare un nodo con etichette zona / regione specifiche per il cloud.
|
||||
2. Inizializzare un nodo con dettagli di istanza specifici del cloud, ad esempio, tipo e dimensione.
|
||||
3. Ottenere gli indirizzi di rete del nodo e il nome host.
|
||||
4. Nel caso in cui un nodo non risponda, controlla il cloud per vedere se il nodo è stato cancellato dal cloud.
|
||||
Se il nodo è stato eliminato dal cloud, elimina l'oggetto Nodo Kubernetes.
|
||||
|
||||
#### Route controller
|
||||
|
||||
Il controller di instradamento è responsabile della configurazione delle rotte nel cloud in modo appropriato in modo che i contenitori su nodi diversi nel cluster Kubernetes possano comunicare tra loro. Il controller di percorso è applicabile solo ai cluster di Google Compute Engine.
|
||||
|
||||
#### Service Controller
|
||||
|
||||
Il responsabile del servizio è responsabile dell'ascolto del servizio di creazione, aggiornamento ed eliminazione di eventi. In base allo stato attuale dei servizi in Kubernetes, configura i bilanciatori del carico cloud (come ELB o Google LB) per riflettere lo stato dei servizi in Kubernetes. Inoltre, assicura che i back-end di servizio per i servizi di bilanciamento del carico del cloud siano aggiornati.
|
||||
|
||||
#### PersistentVolumeLabels controller
|
||||
|
||||
Il controllore PersistentVolumeLabels applica le etichette sui volumi AWS EBS / GCE PD al momento della creazione. Ciò elimina la necessità per gli utenti di impostare manualmente le etichette su questi volumi.
|
||||
|
||||
Queste etichette sono essenziali per la pianificazione dei pod in quanto questi volumi sono costretti a funzionare solo all'interno della regione / zona in cui si trovano. Qualsiasi pod che utilizza questi volumi deve essere pianificato nella stessa zona / zona.
|
||||
|
||||
Il controller PersistentVolumeLabels è stato creato appositamente per CCM; cioè, non esisteva prima della creazione del CCM. Ciò è stato fatto per spostare la logica di etichettatura fotovoltaica nel server API Kubernetes (era un controller di ammissione) al CCM. Non funziona su KCM.
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
Il controller del nodo contiene la funzionalità dipendente dal cloud di kubelet. Prima dell'introduzione del CCM, il kubelet era responsabile dell'inizializzazione di un nodo con dettagli specifici del cloud come indirizzi IP, etichette regione / zona e informazioni sul tipo di istanza. L'introduzione del CCM ha spostato questa operazione di inizializzazione dal kubelet al CCM.
|
||||
|
||||
In questo nuovo modello, kubelet inizializza un nodo senza informazioni specifiche del cloud. Tuttavia, aggiunge un disturbo al nodo appena creato che rende il nodo non programmabile finché CCM non inizializza il nodo con informazioni specifiche del cloud. Rimuove quindi questa macchia.
|
||||
|
||||
|
||||
### 3. Kubernetes API server
|
||||
|
||||
Il controller Persistent Volume Labels sposta la funzionalità dipendente dal cloud del server API di Kubernetes sul CCM come descritto nelle sezioni precedenti
|
||||
|
||||
## Plugin mechanism
|
||||
|
||||
Il gestore del controller cloud utilizza le interfacce Go per consentire l'implementazione di implementazioni da qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui] (https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud. go # L42-L62).
|
||||
|
||||
L'implementazione dei quattro controller condivisi evidenziati sopra e alcuni scaffolding con l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i fornitori di cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core.
|
||||
|
||||
Per ulteriori informazioni sullo sviluppo di plug-in, consultare [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
||||
## Authorization
|
||||
|
||||
Questa sezione suddivide l'accesso richiesto su vari oggetti API da CCM per eseguire le sue operazioni.
|
||||
|
||||
### Node Controller
|
||||
|
||||
Il controller del nodo funziona solo con oggetti nodo. Richiede l'accesso completo per ottenere, elencare, creare, aggiornare, applicare patch, guardare ed eliminare oggetti nodo.
|
||||
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Create
|
||||
- Update
|
||||
- Patch
|
||||
- Watch
|
||||
- Delete
|
||||
|
||||
### Route controller
|
||||
|
||||
Il controllore del percorso ascolta la creazione dell'oggetto Nodo e configura le rotte in modo appropriato. Richiede l'accesso agli oggetti Nodo.
|
||||
|
||||
v1/Node:
|
||||
|
||||
- Get
|
||||
|
||||
### Service controller
|
||||
|
||||
Il controller del servizio ascolta Service object crea, aggiorna ed elimina eventi e quindi configura gli endpoint per tali Servizi in modo appropriato.
|
||||
|
||||
Per accedere ai Servizi, è necessario un elenco e controllare l'accesso. Per aggiornare i servizi, richiede la patch e l'accesso agli aggiornamenti.
|
||||
|
||||
Per impostare gli endpoint per i Servizi, richiede l'accesso per creare, elencare, ottenere, guardare e aggiornare.
|
||||
|
||||
v1/Service:
|
||||
|
||||
- List
|
||||
- Get
|
||||
- Watch
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
### PersistentVolumeLabels controller
|
||||
|
||||
Il controller Persistent Volume Labels ascolta su Persistent Volume (PV) crea eventi e quindi li aggiorna. Questo controller richiede l'accesso per ottenere e aggiornare PV.
|
||||
|
||||
v1/PersistentVolume:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Watch
|
||||
- Update
|
||||
|
||||
### Others
|
||||
|
||||
L'implementazione del core di CCM richiede l'accesso per creare eventi e per garantire operazioni sicure richiede l'accesso per creare ServiceAccounts.
|
||||
|
||||
v1/Event:
|
||||
|
||||
- Create
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
v1/ServiceAccount:
|
||||
|
||||
- Create
|
||||
|
||||
RBAC ClusterRole per il CCM ha il seguente aspetto:
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: cloud-controller-manager
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- events
|
||||
verbs:
|
||||
- create
|
||||
- patch
|
||||
- update
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes
|
||||
verbs:
|
||||
- '*'
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes/status
|
||||
verbs:
|
||||
- patch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- services
|
||||
verbs:
|
||||
- list
|
||||
- patch
|
||||
- update
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- serviceaccounts
|
||||
verbs:
|
||||
- create
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- persistentvolumes
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- update
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- endpoints
|
||||
verbs:
|
||||
- create
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
- update
|
||||
```
|
||||
|
||||
## Vendor Implementations
|
||||
|
||||
I seguenti fornitori di cloud hanno implementato CCM:
|
||||
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
|
||||
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
|
||||
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
|
||||
## Cluster Administration
|
||||
|
||||
Sono fornite le istruzioni complete per la configurazione e l'esecuzione del CCM
|
||||
[qui](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: Comunicazione Master-Node
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Questo documento cataloga i percorsi di comunicazione tra il master (in realtà il
|
||||
apiserver) e il cluster Kubernetes. L'intento è di consentire agli utenti di
|
||||
personalizzare la loro installazione per rafforzare la configurazione di rete in questo modo
|
||||
il cluster può essere eseguito su una rete non affidabile (o su IP completamente pubblici su a
|
||||
fornitore di servizi cloud).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Cluster to Master
|
||||
|
||||
Tutti i percorsi di comunicazione dal cluster al master terminano in
|
||||
apiserver (nessuno degli altri componenti principali è progettato per esporre il telecomando
|
||||
Servizi). In una distribuzione tipica, l'apiserver è configurato per l'ascolto
|
||||
connessioni remote su una porta HTTPS protetta (443) con una o più forme di
|
||||
client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
|
||||
One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/)
|
||||
dovrebbe essere abilitato, specialmente se [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
|
||||
o [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
sono ammessi.
|
||||
|
||||
I nodi devono essere forniti con il certificato di root pubblico per il cluster
|
||||
in modo tale che possano connettersi in modo sicuro all'apiserver insieme al client valido
|
||||
credenziali. Ad esempio, in una distribuzione GKE predefinita, le credenziali del client
|
||||
fornito al kubelet hanno la forma di un certificato client. Vedere
|
||||
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
per il provisioning automatico dei certificati client kubelet.
|
||||
|
||||
I pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando a
|
||||
account di servizio in modo che Kubernetes inserisca automaticamente la radice pubblica
|
||||
certificato e un token al portatore valido nel pod quando viene istanziato.
|
||||
Il servizio `kubernetes` (in tutti gli spazi dei nomi) è configurato con un IP virtuale
|
||||
indirizzo che viene reindirizzato (tramite kube-proxy) all'endpoint HTTPS sul
|
||||
apiserver.
|
||||
|
||||
I componenti master comunicano anche con l'apiserver del cluster sulla porta sicura.
|
||||
|
||||
Di conseguenza, la modalità operativa predefinita per le connessioni dal cluster
|
||||
(nodi e pod in esecuzione sui nodi) sul master è protetto per impostazione predefinita
|
||||
e può funzionare su reti non sicure e / o pubbliche.
|
||||
|
||||
## Master to Cluster
|
||||
|
||||
Esistono due percorsi di comunicazione principali dal master (apiserver) al
|
||||
grappolo. Il primo è dal processo apiserver al processo kubelet su cui gira
|
||||
ogni nodo nel cluster. Il secondo è dall'Apiserver a qualsiasi nodo, pod,
|
||||
o servizio attraverso la funzionalità proxy dell'apiserver.
|
||||
|
||||
### apiserver to kubelet
|
||||
|
||||
Le connessioni dall'apiserver al kubelet vengono utilizzate per:
|
||||
|
||||
* Recupero dei log per i pod.
|
||||
* Allegare (tramite kubectl) ai pod in esecuzione.
|
||||
* Fornire la funzionalità di port forwarding di kubelet.
|
||||
|
||||
Queste connessioni terminano all'endpoint HTTPS di kubelet. Di default,
|
||||
l'apiserver non verifica il certificato di servizio di Kubelet,
|
||||
che rende la connessione soggetta ad attacchi man-in-the-middle, e
|
||||
** non sicuro ** da eseguire su reti non sicure e / o pubbliche.
|
||||
|
||||
Per verificare questa connessione, utilizzare il flag `--kubelet-certificate-authority` su
|
||||
fornire all'apiserver un pacchetto di certificati radice da utilizzare per verificare il
|
||||
il certificato di servizio di kubelet.
|
||||
|
||||
Se questo non è possibile, usa [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
btra l'apiserver e il kubelet se richiesto per evitare il collegamento su un
|
||||
rete non attendibile o pubblica.
|
||||
|
||||
Finalmente, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
dovrebbe essere abilitato per proteggere l'API kubelet.
|
||||
|
||||
### apiserver to nodes, pods, and services
|
||||
|
||||
Le connessioni dall'apiserver a un nodo, pod o servizio predefinito su semplice
|
||||
Connessioni HTTP e quindi non sono né autenticate né crittografate. Essi
|
||||
può essere eseguito su una connessione HTTPS sicura mediante il prefisso `https:` al nodo,
|
||||
pod o nome del servizio nell'URL dell'API, ma non convalideranno il certificato
|
||||
fornito dall'endpoint HTTPS né fornire le credenziali del client così mentre il file
|
||||
la connessione verrà crittografata, non fornirà alcuna garanzia di integrità.
|
||||
Queste connessioni ** non sono attualmente al sicuro ** da eseguire su non attendibili e / o
|
||||
reti pubbliche.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,285 @@
|
||||
---
|
||||
title: Nodi
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Un nodo è una macchina worker in Kubernetes, precedentemente noto come `minion`. Un nodo
|
||||
può essere una VM o una macchina fisica, a seconda del cluster. Ogni nodo contiene
|
||||
i servizi necessari per eseguire [pods](/docs/concepts/workloads/pods/pod/) ed è gestito dal master
|
||||
componenti. I servizi su un nodo includono il [container runtime](/docs/concepts/overview/components/#node-components), kubelet e kube-proxy. Vedere
|
||||
[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) sezione in
|
||||
documento di progettazione dell'architettura per maggiori dettagli.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Node Status
|
||||
|
||||
Lo stato di un nodo contiene le seguenti informazioni:
|
||||
|
||||
* [Addresses](#addresses)
|
||||
* [Condition](#condition)
|
||||
* [Capacity](#capacity)
|
||||
* [Info](#info)
|
||||
|
||||
Ogni sezione è descritta in dettaglio di seguito.
|
||||
|
||||
### Addresses
|
||||
|
||||
L'utilizzo di questi campi varia a seconda del provider cloud o della configurazione bare metal.
|
||||
|
||||
* HostName: il nome host riportato dal kernel del nodo. Può essere sovrascritto tramite il parametro kubelet `--hostname-override`.
|
||||
* ExternalIP: in genere l'indirizzo IP del nodo che è esternamente instradabile (disponibile dall'esterno del cluster).
|
||||
* InternalIP: in genere l'indirizzo IP del nodo che è instradabile solo all'interno del cluster.
|
||||
|
||||
|
||||
### Condition
|
||||
|
||||
l campo `conditions` descrive lo stato di tutti i nodi` Running`.
|
||||
|
||||
|
||||
| Condizione del nodo | Descrizione |
|
||||
| ---------------- | ------------- |
|
||||
| `OutOfDisk` | `True` se lo spazio disponibile sul nodo non è sufficiente per aggiungere nuovi pod, altrimenti` False` |
|
||||
| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod,` False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
|
||||
| `MemoryPressure` | `Vero` se la pressione esiste sulla memoria del nodo, ovvero se la memoria del nodo è bassa; altrimenti `False` |
|
||||
| `PIDPressure` | `True` se la pressione esiste sui processi, ovvero se ci sono troppi processi sul nodo; altrimenti `False` |
|
||||
| `DiskPressure` | `True` se esiste una pressione sulla dimensione del disco, ovvero se la capacità del disco è bassa; altrimenti `False` |
|
||||
| `NetworkUnavailable` | `True` se la rete per il nodo non è configurata correttamente, altrimenti` False` |
|
||||
|
||||
La condizione del nodo è rappresentata come un oggetto JSON. Ad esempio, la seguente risposta descrive un nodo sano.
|
||||
|
||||
```json
|
||||
"conditions": [
|
||||
{
|
||||
"type": "Ready",
|
||||
"status": "True"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Se lo stato della condizione Ready rimane `Unknown` o` False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller] (/ docs / admin / kube-controller- manager /) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
|
||||
|
||||
Nelle versioni di Kubernetes precedenti alla 1.5, il controllore del nodo [forzerebbe la cancellazione] (/ docs/concepts/workloads/pods/pod/ # force-deletion-of-pods)
|
||||
questi pod non raggiungibili dall'apiserver. Tuttavia, in 1.5 e versioni successive, il controller del nodo non impone l'eliminazione dei pod finché non lo è
|
||||
confermato che hanno smesso di funzionare nel cluster. Puoi vedere i pod che potrebbero essere in esecuzione su un nodo irraggiungibile
|
||||
lo stato `Terminating` o` Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
|
||||
lasciato permanentemente un cluster, potrebbe essere necessario che l'amministratore del cluster elimini manualmente l'oggetto nodo. Cancellare l'oggetto nodo da
|
||||
Kubernetes fa sì che tutti gli oggetti Pod in esecuzione sul nodo vengano eliminati dal server apis e libera i loro nomi.
|
||||
|
||||
|
||||
Nella versione 1.12, la funzione `TaintNodesByCondition` è promossa in versione beta, quindi il controller del ciclo di vita del nodo crea automaticamente
|
||||
[taints] (/ docs / concepts / configuration / taint-and-toleration /) che rappresentano le condizioni.
|
||||
Allo stesso modo lo schedulatore ignora le condizioni quando si considera un nodo; anziché
|
||||
guarda le tinte del Nodo e le tolleranze di un Pod.
|
||||
|
||||
Ora gli utenti possono scegliere tra il vecchio modello di pianificazione e un nuovo modello di pianificazione più flessibile.
|
||||
Un pod che non ha tolleranze viene pianificato in base al vecchio modello. Ma un baccello quello
|
||||
tollera che i nodi di un nodo particolare possano essere programmati su quel nodo.
|
||||
|
||||
{{< caution >}}
|
||||
ESe si disabilita questa funzione si crea un leggero ritardo tra il
|
||||
tempo in cui una condizione viene osservata e quando viene creata una contaminazione. Questo ritardo è in genere inferiore a un secondo, ma può aumentare il numero di pod pianificati correttamente ma rifiutati dal kubelet.
|
||||
{{< /caution >}}
|
||||
|
||||
### Capacity
|
||||
|
||||
|
||||
Descrive le risorse disponibili sul nodo: CPU, memoria e il massimo
|
||||
numero di pod che possono essere programmati sul nodo.
|
||||
|
||||
### Info
|
||||
|
||||
Informazioni generali sul nodo, come la versione del kernel, la versione di Kubernetes
|
||||
(versione kubelet e kube-proxy), versione Docker (se utilizzata), nome del sistema operativo.
|
||||
Le informazioni sono raccolte da Kubelet dal nodo.
|
||||
|
||||
## Management
|
||||
|
||||
Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/),
|
||||
a node is not inherently created by Kubernetes: it is created externally by cloud
|
||||
providers like Google Compute Engine, or it exists in your pool of physical or virtual
|
||||
machines. So when Kubernetes creates a node, it creates
|
||||
an object that represents the node. After creation, Kubernetes
|
||||
checks whether the node is valid or not. For example, if you try to create
|
||||
a node from the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Node",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "10.240.79.157",
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Kubernetes crea un oggetto nodo internamente (la rappresentazione), e
|
||||
convalida il nodo tramite il controllo dello stato in base al campo `metadata.name`. Se il nodo è valido - cioè, se necessario
|
||||
i servizi sono in esecuzione, è idoneo per l'esecuzione di un pod. Altrimenti, lo è
|
||||
ignorato per qualsiasi attività del cluster finché non diventa valido.
|
||||
|
||||
{{<note>}}
|
||||
Kubernetes mantiene l'oggetto per il nodo non valido e continua a verificare se diventa valido.
|
||||
È necessario eliminare esplicitamente l'oggetto Nodo per interrompere questo processo.
|
||||
{{</ note>}}
|
||||
|
||||
Attualmente, ci sono tre componenti che interagiscono con il nodo di Kubernetes
|
||||
interfaccia: controller del nodo, kubelet e kubectl.
|
||||
|
||||
### Node Controller
|
||||
|
||||
Il controller del nodo è un componente master di Kubernetes che gestisce vari
|
||||
aspetti dei nodi.
|
||||
|
||||
Il controller del nodo ha più ruoli nella vita di un nodo. Il primo sta assegnando a
|
||||
Blocco CIDR sul nodo quando è registrato (se l'assegnazione CIDR è attivata).
|
||||
|
||||
Il secondo è mantenere aggiornato l'elenco interno dei nodi del controller del nodo
|
||||
l'elenco delle macchine disponibili del provider cloud. Quando si corre in una nuvola
|
||||
ambiente, ogni volta che un nodo non è sano, il controller del nodo chiede al cloud
|
||||
fornitore se la VM per quel nodo è ancora disponibile. Altrimenti, il nodo
|
||||
controller cancella il nodo dalla sua lista di nodi.
|
||||
|
||||
Il terzo è il monitoraggio della salute dei nodi. Il controller del nodo è
|
||||
responsabile dell'aggiornamento della condizione NodeReady di NodeStatus a
|
||||
Condizione Notata quando un nodo diventa irraggiungibile (ad esempio, il controller del nodo si arresta
|
||||
ricevere heartbeat per qualche motivo, ad es. a causa del fatto che il nodo si trova in basso), e poi in seguito sfratto
|
||||
tutti i pod dal nodo (usando una terminazione elegante) se il nodo continua
|
||||
essere irraggiungibile. (I timeout predefiniti sono 40 secondi per iniziare la segnalazione
|
||||
ConditionUnknown e 5m dopo di ciò per iniziare a sfrattare i pod.) Il controller del nodo
|
||||
controlla lo stato di ogni nodo ogni `--node-monitor-period` secondi.
|
||||
|
||||
Nelle versioni di Kubernetes precedenti alla 1.13, NodeStatus è l'heartbeat di
|
||||
nodo. A partire da Kubernetes 1.13, la funzionalità di lease del nodo viene introdotta come un
|
||||
funzione alfa (porta caratteristica `NodeLease`,
|
||||
[KEP-0009] (https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
Quando la funzione di lease del nodo è abilitata, ogni nodo ha un oggetto `Lease` associato in
|
||||
spazio dei nomi `kube-node-lease` che viene rinnovato periodicamente dal nodo ed entrambi
|
||||
NodeStatus e lease del nodo vengono considerati heartbeat dal nodo. Locazioni di nodi
|
||||
si rinnovano frequentemente mentre NodeStatus viene segnalato solo dal nodo al master
|
||||
quando c'è qualche cambiamento o è passato abbastanza tempo (il default è 1 minuto, che
|
||||
è più lungo del timeout predefinito di 40 secondi per i nodi non raggiungibili). Da
|
||||
il lease del nodo è molto più leggero di NodeStatus, questa caratteristica rende nodo
|
||||
battito cardiaco significativamente più economico sia per la scalabilità che per le prestazioni
|
||||
prospettive.
|
||||
|
||||
In Kubernetes 1.4, abbiamo aggiornato la logica del controller del nodo per gestire meglio
|
||||
casi in cui un numero elevato di nodi ha problemi con il raggiungimento del master
|
||||
(ad esempio perché il master ha problemi di rete). A partire da 1.4, il nodo
|
||||
controller controlla lo stato di tutti i nodi nel cluster quando si effettua un
|
||||
decisione sullo sfratto del pod.
|
||||
|
||||
Nella maggior parte dei casi, il controller del nodo limita il tasso di sfratto a
|
||||
`--node-eviction-rate` (default 0.1) al secondo, il che significa che non eliminerà i pod
|
||||
da più di 1 nodo per 10 secondi.
|
||||
|
||||
Il comportamento di sfratto del nodo cambia quando un nodo in una determinata zona di disponibilità
|
||||
diventa malsano. Il controller del nodo controlla quale percentuale di nodi nella zona
|
||||
sono malsani (la condizione NodeReady è ConditionUnknown o ConditionFalse) a
|
||||
lo stesso tempo. Se la frazione di nodi malsani è almeno
|
||||
`--unhealthy-zone-threshold` (default 0.55) quindi il tasso di sfratto è ridotto:
|
||||
se il cluster è piccolo (cioè ha meno o uguale a
|
||||
`--large-cluster-size-threshold` nodes - default 50) quindi gli sfratti sono
|
||||
fermato, altrimenti il tasso di sfratto è ridotto a
|
||||
`--secondary-node-eviction-rate` (default 0.01) al secondo. La ragione per cui
|
||||
le politiche sono implementate per zona di disponibilità è perché una zona di disponibilità
|
||||
potrebbe divenire partizionato dal master mentre gli altri rimangono connessi. Se
|
||||
il tuo cluster non si estende su più zone di disponibilità del provider cloud, quindi
|
||||
c'è solo una zona di disponibilità (l'intero cluster).
|
||||
|
||||
Un motivo chiave per diffondere i nodi tra le zone di disponibilità è che
|
||||
il carico di lavoro può essere spostato in zone sane quando un'intera zona viene interrotta.
|
||||
Pertanto, se tutti i nodi in una zona non sono sani, il controller del nodo viene sottratto a
|
||||
la normale frequenza `--node-eviction-rate`. Il caso d'angolo è quando tutte le zone sono
|
||||
completamente malsano (cioè non ci sono nodi sani nel cluster). In tale
|
||||
caso, il controller del nodo presuppone che ci sia qualche problema con il master
|
||||
connettività e interrompe tutti gli sfratti fino a quando non viene ripristinata la connettività.
|
||||
|
||||
A partire da Kubernetes 1.6, il NodeController è anche responsabile della rimozione
|
||||
i pod che sono in esecuzione sui nodi con `NoExecute`, quando i pod non tollerano
|
||||
i taints. Inoltre, come caratteristica alfa che è disabilitata per impostazione predefinita, il
|
||||
NodeController è responsabile per l'aggiunta di taints corrispondenti ai problemi del nodo come
|
||||
nodo irraggiungibile o non pronto. Vedi [questa documentazione] (/docs/concepts/configuration/taint-and-toleration/)
|
||||
per i dettagli su `NoExecute` taints e la funzione alpha.
|
||||
|
||||
partire dalla versione 1.8, il controller del nodo può essere reso responsabile della creazione di taints che rappresentano le condizioni del nodo.
|
||||
Questa è una caratteristica alfa della versione 1.8.
|
||||
|
||||
### Self-Registration of Nodes
|
||||
|
||||
Quando il flag kubelet `--register-node` è vero (il default), il kubelet tenterà di farlo
|
||||
registrarsi con il server API. Questo è il modello preferito, utilizzato dalla maggior parte delle distro.
|
||||
|
||||
Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
|
||||
|
||||
- `--kubeconfig` - Percorso delle credenziali per autenticarsi sull'apiserver.
|
||||
- `--cloud-provider` - Come parlare con un provider cloud per leggere i metadati su se stesso.
|
||||
- `--register-node` - Si registra automaticamente con il server API.
|
||||
- `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola` <chiave> = <valore>: <effetto> `). No-op se `register-node` è falso.
|
||||
- `--node-ip` - Indirizzo IP del nodo.
|
||||
- `--node-labels` - Etichette da aggiungere quando si registra il nodo nel cluster (vedere le restrizioni dell'etichetta applicate dal [plugin di accesso NodeRestriction] (/ docs / reference / access-authn-authz / admission-controller / # noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Specifica la frequenza con cui kubelet invia lo stato del nodo al master
|
||||
|
||||
Quando [Node authorization mode](/docs/reference/access-authn-authz/node/) e
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) sono abilitati,
|
||||
kubelets è autorizzato solo a creare / modificare la propria risorsa nodo.
|
||||
|
||||
#### Manual Node Administration
|
||||
|
||||
Un amministratore di cluster può creare e modificare oggetti nodo.
|
||||
|
||||
Se l'amministratore desidera creare manualmente oggetti nodo, imposta il flag kubelet
|
||||
`--Register nodo = false`.
|
||||
|
||||
L'amministratore può modificare le risorse del nodo (indipendentemente dall'impostazione di `--register-node`).
|
||||
Le modifiche includono l'impostazione di etichette sul nodo e la marcatura non programmabile.
|
||||
|
||||
Le etichette sui nodi possono essere utilizzate insieme ai selettori di nodo sui pod per controllare la pianificazione,
|
||||
per esempio. vincolare un pod per poter essere eseguito solo su un sottoinsieme di nodi.
|
||||
|
||||
Contrassegnare un nodo come unschedulable impedisce a nuovi pod di essere programmati per quello
|
||||
nodo, ma non ha alcun effetto sui pod esistenti sul nodo. Questo è utile come
|
||||
fase preparatoria prima del riavvio del nodo, ecc. Ad esempio, per contrassegnare un nodo
|
||||
unschedulable, esegui questo comando:
|
||||
|
||||
```shell
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
I pod creati da un controller DaemonSet bypassano lo scheduler di Kubernetes
|
||||
e non rispettare l'attributo unschedulable su un nodo. Questo presuppone che i demoni appartengano
|
||||
la macchina anche se viene scaricata dalle applicazioni mentre si prepara per un riavvio.
|
||||
{{< /note >}}
|
||||
|
||||
### Node capacity
|
||||
|
||||
La capacità del nodo (numero di cpu e quantità di memoria) è parte dell'oggetto nodo.
|
||||
Normalmente, i nodi si registrano e segnalano la loro capacità durante la creazione dell'oggetto nodo. Se
|
||||
stai facendo [amministrazione manuale del nodo] (# manual-node-administration), quindi devi impostare il nodo
|
||||
capacità quando si aggiunge un nodo.
|
||||
|
||||
Lo scheduler di Kubernetes garantisce che ci siano risorse sufficienti per tutti i pod su un nodo. esso
|
||||
controlla che la somma delle richieste di container sul nodo non sia maggiore della capacità del nodo. esso
|
||||
include tutti i contenitori avviati da kubelet, ma non i contenitori avviati direttamente dal [contenitore runtime] (/docs/concepts/overview/components/ # node-components) né qualsiasi processo eseguito all'esterno dei contenitori.
|
||||
|
||||
Se si desidera riservare esplicitamente risorse per processi non Pod, seguire questo tutorial su
|
||||
[riserva risorse per i demoni di sistema] (/docs/tasks/administration-cluster/reserve-compute-resources/ # system-reserved).
|
||||
|
||||
|
||||
## API Object
|
||||
|
||||
Il nodo è una risorsa di livello superiore nell'API REST di Kubernetes. Maggiori dettagli su
|
||||
L'oggetto API può essere trovato a:
|
||||
[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user