Merge pull request #22303 from crixo/translate/control-plane-node-communication
upgrade translation for control-plane-node-communication
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
98cfcca5ff
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
title: Comunicazione Control Plane - Nodo
|
||||
content_type: concept
|
||||
weight: 20
|
||||
aliases:
|
||||
- master-node-communication
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Questo documento cataloga le connessioni tra il piano di controllo (_control-plane_), in realtà l'apiserver, e il cluster Kubernetes. L'intento è di consentire agli utenti di personalizzare la loro installazione per rafforzare la configurazione di rete affinché il cluster possa essere eseguito su una rete pubblica (o su IP completamente pubblici resi disponibili da un fornitore di servizi cloud).
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Dal Nodo al control-plane{#dal-nodo-al-control-plane}
|
||||
Kubernetes adotta un pattern per le API di tipo _"hub-and-spoke"_. Tutte le chiamate delle API eseguite sui vari nodi sono effettuate verso l'apiserver (nessuno degli altri componenti principali è progettato per esporre servizi remoti). L'apiserver è configurato per l'ascolto di connessioni remote su una porta HTTPS protetta (443) con una o più forme di [autenticazioni client](/docs/reference/access-authn-authz/authentication/) abilitate. Si dovrebbero abilitare una o più forme di [autorizzazioni](/docs/reference/access-authn-authz/authorization/), in particolare nel caso in cui siano ammesse [richieste anonime](/docs/reference/access-authn-authz/authentication/#anonymous-requests) o [_token_ legati ad un account di servizio (_service account_)](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
|
||||
|
||||
Il certificato pubblico (_public root certificate_) relativo al cluster corrente deve essere fornito ai vari nodi di modo che questi possano connettersi in modo sicuro all'apiserver insieme alle credenziali valide per uno specifico _client_. Ad esempio, nella configurazione predefinita di un cluster [GKE](https://cloud.google.com/kubernetes-engine?hl=it), le credenziali del client fornite al kubelet hanno la forma di un certificato client. Si veda
|
||||
[inizializzazione TLS del kubelet TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) per la fornitura automatica dei certificati client al _kubelet_.
|
||||
|
||||
I Pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando un account di servizio in modo che Kubernetes inserisca automaticamente il certificato pubblico di radice e un token valido al portatore (_bearer token_) all'interno Pod quando questo viene istanziato.
|
||||
In tutti i namespace è configurato un _Service_ con nome `kubernetes` con un indirizzo IP virtuale che viene reindirizzato (tramite _kube-proxy_) all'endpoint HTTPS dell'apiserver.
|
||||
|
||||
Anche i componenti del piano d controllo comunicano con l'apiserver del cluster su di una porta sicura esposta da quest'ultimo.
|
||||
|
||||
Di conseguenza, la modalità operativa predefinita per le connessioni dai nodi e dai Pod in esecuzione sui nodi verso il _control-plane_ è protetta da un'impostazione predefinita
|
||||
e può essere eseguita su reti non sicure e/o pubbliche.
|
||||
|
||||
## Dal control-plane al nodo{#dal-control-plane-al-nodo}
|
||||
|
||||
Esistono due percorsi di comunicazione principali dal _control-plane_ (apiserver) verso i nodi. Il primo è dall'apiserver verso il processo _kubelet_ in esecuzione su ogni nodo nel cluster. Il secondo è dall'apiserver a ciascun nodo, Pod, o servizio attraverso la funzionalità proxy dell'apiserver.
|
||||
|
||||
### Dall'apiserver al _kubelet_
|
||||
|
||||
Le connessioni dall'apiserver al _kubelet_ vengono utilizzate per:
|
||||
|
||||
* Prendere i log relativi ai vari Pod.
|
||||
* Collegarsi (attraverso kubectl) ai Pod in esecuzione.
|
||||
* Fornire la funzionalità di _port-forwarding_ per i _kubelet_.
|
||||
|
||||
Queste connessioni terminano all'endpoint HTTPS del _kubelet_. Di default, l'apiserver non verifica il certificato servito dal _kubelet_, il che rende la connessione soggetta ad attacchi _man-in-the-middle_, e tale da essere considerato **non sicuro (unsafe)** se eseguito su reti non protette e/o pubbliche.
|
||||
|
||||
Per verificare questa connessione, si utilizzi il parametro `--kubelet-certificate-authority` al fine di fornire all'apiserver un insieme di certificati radice da utilizzare per verificare il
|
||||
il certificato servito dal _kubelet_.
|
||||
|
||||
Se questo non è possibile, si usi un [tunnel SSH](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) tra l'apiserver e il _kubelet_, se richiesto, per evitare il collegamento su una rete non protetta o pubblica.
|
||||
|
||||
In fine, l'[autenticazione e/o l'autorizzazione del kubelet](/docs/admin/kubelet-authentication-authorization/) dovrebbe essere abilitate per proteggere le API esposte dal _kubelet_.
|
||||
|
||||
### Dall'apiserver ai nodi, Pod, e servizi{#dal-apiserver-ai-nodi-pod-servizi}
|
||||
|
||||
Le connessioni dall'apiserver verso un nodo, Pod o servizio avvengono in modalità predefinita su semplice connessione HTTP e quindi non sono né autenticate né criptata. Queste connessioni possono essere eseguite su una connessione HTTPS sicura mediante il prefisso `https:` al nodo, Pod o nome del servizio nell'URL dell'API, ma non valideranno il certificato fornito dall'endpoint HTTPS né forniranno le credenziali del client così anche se la connessione verrà criptata, non fornirà alcuna garanzia di integrità. **Non è attualmente sicuro** eseguire queste connessioni su reti non protette e/o pubbliche.
|
||||
|
||||
### I tunnel SSH
|
||||
|
||||
Kubernetes supporta i _tunnel_ SSH per proteggere la comunicazione tra il _control-plane_ e i nodi. In questa configurazione, l'apiserver inizializza un tunnel SSH con ciascun nodo del cluster (collegandosi al server SSH in ascolto sulla porta 22) e fa passare tutto il traffico verso il _kubelet_, il nodo, il Pod, o il servizio attraverso questo tunnel. Questo tunnel assicura che il traffico non sia esposto al di fuori della rete su cui sono in esecuzioni i vari nodi.
|
||||
|
||||
I tunnel SSH sono al momento deprecati ovvero non dovrebbero essere utilizzati a meno che ci siano delle esigenze particolari. Il servizio `Konnectivity` è pensato per rimpiazzare questo canale di comunicazione.
|
||||
|
||||
### Il servizio _Konnectivity_
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
Come rimpiazzo dei tunnel SSH, il servizio _Konnectivity_ fornisce un proxy a livello TCP per la comunicazione tra il _control-plane_ e il cluster. Il servizio _Konnectivity_ consiste in due parti: il _Konnectivity_ server e gli agenti _Konnectivity_, in esecuzione rispettivamente sul _control-plane_ e sui vari nodi. Gli agenti _Konnectivity_ inizializzano le connessioni verso il server _Konnectivity_ e mantengono le connessioni di rete. Una volta abilitato il servizio _Konnectivity_, tutto il traffico tra il _control-plane_ e i nodi passa attraverso queste connessioni.
|
||||
|
||||
Si può fare riferimento al [tutorial per il servizio _Konnectivity_](/docs/tasks/extend-kubernetes/setup-konnectivity/) per configurare il servizio _Konnectivity_ all'interno del cluster
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
---
|
||||
draft: True
|
||||
title: Comunicazione Master-Node
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- 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).
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- 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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue