diff --git a/content/it/docs/concepts/_index.md b/content/it/docs/concepts/_index.md new file mode 100644 index 0000000000..7c6f286317 --- /dev/null +++ b/content/it/docs/concepts/_index.md @@ -0,0 +1,77 @@ +--- +title: Concepts +main_menu: true +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +La sezione Concetti ti aiuta a conoscere le parti del sistema Kubernetes e le astrazioni utilizzate da Kubernetes per rappresentare il tuo cluster e ti aiuta ad ottenere una comprensione più profonda di come funziona Kubernetes. + +{{% /capture %}} + +{{% capture body %}} + +## Overview + +Per lavorare con Kubernetes, usi *gli oggetti API Kubernetes* per descrivere lo *stato desiderato del tuo cluster*: quali applicazioni o altri carichi di lavoro vuoi eseguire, quali immagini del contenitore usano, numero di repliche, quali risorse di rete e disco vuoi rendere disponibile e altro ancora. Puoi impostare lo stato desiderato creando oggetti usando l'API di Kubernetes, in genere tramite l'interfaccia della riga di comando, `kubectl`. Puoi anche utilizzare direttamente l'API di Kubernetes per interagire con il cluster e impostare o modificare lo stato desiderato. + +Una volta impostato lo stato desiderato, il *Kubernetes Control Plane* funziona per fare in modo che lo stato corrente del cluster corrisponda allo stato desiderato. Per fare ciò, Kubernetes esegue automaticamente una serie di attività, come l'avvio o il riavvio dei contenitori, il ridimensionamento del numero di repliche di una determinata applicazione e altro ancora. Il piano di controllo di Kubernetes è costituito da una raccolta di processi in esecuzione sul cluster: + +* Il **Kubernetes Master** è una raccolta di tre processi che vengono eseguiti su un singolo nodo nel cluster, che è designato come nodo principale. Questi processi sono: [kube-apiserver] (/docs/admin/kube-apiserver/), [kube-controller-manager] (/docs/admin/kube-controller-manager/) e [kube-scheduler] (/docs/admin/kube-scheduler/). +* Ogni singolo nodo non principale nel cluster esegue due processi: +  * **[kubelet](/docs/admin/kubelet/)**, che comunica con il master di Kubernetes. +  * **[kube-proxy](/docs/admin/kube-proxy/)**, un proxy di rete che riflette i servizi di rete di Kubernetes su ciascun nodo. + +## Kubernetes Objects + +kubernetes contiene una serie di astrazioni che rappresentano lo stato del tuo sistema: applicazioni e carichi di lavoro distribuiti in container, le loro risorse di rete e disco associate e altre informazioni su ciò che sta facendo il tuo cluster. Queste astrazioni sono rappresentate da oggetti nell'API di Kubernetes; guarda la [Panoramica degli oggetti di Kubernetes](/docs/concepts/abstractions/overview/) per maggiori dettagli. + +Gli oggetti di base di Kubernetes includono: + +* [Pod](/docs/concepts/workloads/pods/pod-overview/) +* [Service](/docs/concepts/services-networking/service/) +* [Volume](/docs/concepts/storage/volumes/) +* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) + + +209/5000 +Inoltre, Kubernetes contiene una serie di astrazioni di livello superiore denominate Controllori. I controller si basano sugli oggetti di base e forniscono funzionalità aggiuntive e funzionalità di convenienza. Loro includono: + +* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) +* [Deployment](/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) +* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) + +## Kubernetes Control Plane + +Le varie parti del Piano di controllo di Kubernetes, come i master Kubernetes e i processi di Kubelet, regolano il modo in cui Kubernetes comunica con il cluster. Il Piano di controllo mantiene un registro di tutti gli oggetti Kubernetes nel sistema e esegue cicli di controllo continui per gestire lo stato di tali oggetti. In qualsiasi momento, i loop di controllo di Control Plane risponderanno ai cambiamenti nel cluster e lavoreranno per fare in modo che lo stato effettivo di tutti gli oggetti nel sistema corrisponda allo stato desiderato che hai fornito. + +Ad esempio, quando si utilizza l'API di Kubernetes per creare un oggetto di distribuzione, si fornisce un nuovo stato desiderato per il sistema. Il piano di controllo di Kubernetes registra la creazione dell'oggetto e svolge le tue istruzioni avviando le applicazioni richieste e pianificandole sui nodi del cluster, in modo che lo stato effettivo del cluster corrisponda allo stato desiderato. + +### Kubernetes Master + +Il master Kubernetes è responsabile della gestione dello stato desiderato per il tuo cluster. Quando interagisci con Kubernetes, ad esempio utilizzando l'interfaccia della riga di comando `kubectl`, stai comunicando con il master di Kubernetes del cluster. + +> Il "master" si riferisce a una raccolta di processi che gestiscono lo stato del cluster. In genere questi processi vengono eseguiti tutti su un singolo nodo nel cluster e questo nodo viene anche definito master. Il master può anche essere replicato per disponibilità e ridondanza. + +### Kubernetes Nodes + +I nodi di un cluster sono le macchine (VM, server fisici, ecc.) Che eseguono i flussi di lavoro delle applicazioni e del cloud. Il master Kubernetes controlla ciascun nodo; raramente interagirai direttamente con i nodi. + +#### Object Metadata + + +* [Annotations](/docs/concepts/overview/working-with-objects/annotations/) + +{{% /capture %}} + +{{% capture whatsnext %}} + +Se vuoi scrivere una pagina concettuale, vedi +[Uso dei modelli di pagina] (/docs/home/contribute/page-templates/) +per informazioni sul tipo di pagina di concetto e il modello di concetto. + +{{% /capture %}} diff --git a/content/it/docs/concepts/architecture/_index.md b/content/it/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..0a87c18478 --- /dev/null +++ b/content/it/docs/concepts/architecture/_index.md @@ -0,0 +1,5 @@ +--- +title: "Architettura di Kubernetes" +weight: 30 +--- + diff --git a/content/it/docs/concepts/architecture/cloud-controller.md b/content/it/docs/concepts/architecture/cloud-controller.md new file mode 100644 index 0000000000..a3032c74e7 --- /dev/null +++ b/content/it/docs/concepts/architecture/cloud-controller.md @@ -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: + +![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) + +{{% /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ì: + +![CCM Kube Arch](/images/docs/post-ccm-arch.png) + +## 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 %}} diff --git a/content/it/docs/concepts/architecture/master-node-communication.md b/content/it/docs/concepts/architecture/master-node-communication.md new file mode 100644 index 0000000000..bcfabac7ee --- /dev/null +++ b/content/it/docs/concepts/architecture/master-node-communication.md @@ -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 %}} diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..c9e33ed9b5 --- /dev/null +++ b/content/it/docs/concepts/architecture/nodes.md @@ -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. + +{{}} +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. +{{}} + +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` = : `). 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 %}} diff --git a/content/it/docs/concepts/cluster-administration/_index.md b/content/it/docs/concepts/cluster-administration/_index.md new file mode 100755 index 0000000000..72af40feec --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,5 @@ +--- +title: "Cluster Administration" +weight: 100 +--- + diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..8eb2a1bc5e --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,52 @@ +--- +title: Installazione dei componenti aggiuntivi +content_template: templates/concept +--- + +{{% capture overview %}} + + +I componenti aggiuntivi estendono la funzionalità di Kubernetes. + +Questa pagina elenca alcuni componenti aggiuntivi disponibili e collegamenti alle rispettive istruzioni di installazione. + +I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine non implica uno stato preferenziale. + +{{% /capture %}} + + +{{% capture body %}} + +## Networking and Network Policy + + +* [ACI] (https://www.github.com/noironetworks/aci-containers) fornisce funzionalità integrate di networking e sicurezza di rete con Cisco ACI. +* [Calico] (https://docs.projectcalico.org/latest/getting-started/kubernetes/) è un provider di sicurezza e rete L3 sicuro. +* [Canal] (https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete. +* [Cilium] (https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento. +* [CNI-Genie] (https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. +* [Contiv] (http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source] (http://github.com/contiv). Il [programma di installazione] (http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm. +* [Flanella] (https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. +* [Knitter] (https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. +* [Multus] (https://github.com/Intel-Corp/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. +* [NSX-T] (https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. +* [Nuage] (https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza. +* [Romana] (http://romana.io) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy] (/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui] (https://github.com/romana/romana/tree/master/containerize). +* [Weave Net] (https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno. + +## Service Discovery + +* [CoreDNS] (https://coredns.io) è un server DNS flessibile ed estensibile che può essere [installato] (https://github.com/coredns/deployment/tree/master/kubernetes) come in-cluster DNS per pod. + +## Visualization & Control + +[Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) è un'interfaccia web dashboard per Kubernetes. +* [Weave Scope] (https://www.weave.works/documentation/scope-latest-installing/#k8s) è uno strumento per la visualizzazione grafica di contenitori, pod, servizi, ecc. Utilizzalo in combinazione con un [Weave Cloud account] (https://cloud.weave.works/) o ospitali tu stesso. + +## Legacy Add-ons + +qui ci sono molti altri componenti aggiuntivi documentati nella directory deprecata [cluster / addons] (https://git.k8s.io/kubernetes/cluster/addons). + +Quelli ben mantenuti dovrebbero essere collegati qui. + +{{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/certificates.md b/content/it/docs/concepts/cluster-administration/certificates.md new file mode 100644 index 0000000000..e6b8b05dd1 --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/certificates.md @@ -0,0 +1,248 @@ +--- +title: Certificati +content_template: templates/concept +weight: 20 +--- + + +{{% capture overview %}} + +Quando si utilizza l'autenticazione del certificato client, è possibile generare certificati +manualmente tramite `easyrsa`,` openssl` o `cfssl`. + +{{% /capture %}} + + +{{% capture body %}} + +### easyrsa + +** easyrsa ** può generare manualmente certificati per il tuo cluster. + +1. Scaricare, decomprimere e inizializzare la versione patched di easyrsa3. + +        curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz +        tar xzf easy-rsa.tar.gz +        cd easy-rsa-master / easyrsa3 +        ./easyrsa init-pki +1. Generare una CA. (`--batch` imposta la modalità automatica. `--req-cn` default CN da usare.) + +        ./easyrsa --batch "--req-cn = $ {MASTER_IP} @` date +% s` "build-ca nopass +1. Genera certificato e chiave del server. +    L'argomento `--subject-alt-name` imposta i possibili IP e nomi DNS del server API +    accessibile con. Il `MASTER_CLUSTER_IP` è solitamente il primo IP dal servizio CIDR +    che è specificato come argomento `--service-cluster-ip-range` per il server API e +    il componente del controller controller. L'argomento `--days` è usato per impostare il numero di giorni +    dopodiché scade il certificato. +    L'esempio sotto riportato assume anche che tu stia usando `cluster.local` come predefinito +    Nome di dominio DNS + +        ./easyrsa --subject-alt-name = "IP: $ {MASTER_IP}," \ +        "IP: $ {} MASTER_CLUSTER_IP," \ +        "DNS: kubernetes," \ +        "DNS: kubernetes.default," \ +        "DNS: kubernetes.default.svc," \ +        "DNS: kubernetes.default.svc.cluster," \ +        "DNS: kubernetes.default.svc.cluster.local" \ +        --days = 10000 \ +        build-server-full server nopass +1. Copia `pki / ca.crt`, `pki / issued / server.crt` e `pki / private / server.key` nella tua directory. +1. Compilare e aggiungere i seguenti parametri nei parametri di avvio del server API: + +        --client-ca-file =/YourDirectory/ca.crt +        --tls-cert-file =/YourDirectory/server.crt +        --tls-chiave file privato=/YourDirectory/server.key + +### openssl + +** openssl ** può generare manualmente certificati per il tuo cluster. + +1. Genera un tasto approssimativo con 2048 bit: + +         openssl genrsa -out ca.key 2048 +1. In base al tasto approssimativo, generare ca.crt (utilizzare -giorni per impostare il tempo effettivo del certificato): + +         openssl req -x509 -new -nodes -key ca.key -subj "/ CN = $ {MASTER_IP}" -days 10000 -out ca.crt +1. Genera un server.key con 2048 bit: + +         openssl genrsa -out server.key 2048 +1. Creare un file di configurazione per generare una richiesta di firma del certificato (CSR). +     Assicurati di sostituire i valori contrassegnati da parentesi angolari (ad esempio ``) +     con valori reali prima di salvarlo in un file (ad esempio `csr.conf`). +     Si noti che il valore di `MASTER_CLUSTER_IP` è l'IP del cluster di servizio per il +     Server API come descritto nella sottosezione precedente. +     L'esempio sotto riportato assume anche che tu stia usando `cluster.local` come predefinito +     Nome di dominio DNS + + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names +1. Generate the certificate signing request based on the config file: + + openssl req -new -key server.key -out server.csr -config csr.conf +1. Generare il certificato del server usando ca.key, ca.crt e server.csr: + + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf +1. Visualizza il certificato: + + openssl x509 -noout -text -in ./server.crt + +Infine, aggiungi gli stessi parametri nei parametri di avvio del server API. + +### cfssl + +** cfssl ** è un altro strumento per la generazione di certificati. + +1. Scaricare, decomprimere e preparare gli strumenti da riga di comando come mostrato di seguito. +     Si noti che potrebbe essere necessario adattare i comandi di esempio in base all'hardware +     architettura e versione di cfssl che stai utilizzando. + + curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl + chmod +x cfssl + curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson + chmod +x cfssljson + curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo +1. Create a directory to hold the artifacts and initialize cfssl: + + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json +1. Creare un file di configurazione JSON per generare il file CA, ad esempio, `ca-config.json`: + + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } +1. Creare un file di configurazione JSON per la richiesta di firma del certificato CA (CSR), ad esempio, +     `Ca-csr.json`. Assicurarsi di sostituire i valori contrassegnati da parentesi angolari con +     valori reali che si desidera utilizzare. + + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): + + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca +1. Creare un file di configurazione JSON per generare chiavi e certificati per l'API +     server, ad esempio, `server-csr.json`. Assicurati di sostituire i valori tra parentesi angolari con +     valori reali che si desidera utilizzare. `MASTER_CLUSTER_IP` è il cluster di servizio +     IP per il server API come descritto nella sottosezione precedente. +     L'esempio sotto riportato assume anche che tu stia usando `cluster.local` come predefinito +     Nome di dominio DNS + + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generare la chiave e il certificato per il server API, che sono per impostazione predefinita +     salvati nel file `server-key.pem` e` server.pem` rispettivamente: + + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + + +## Distributing Self-Signed CA Certificate + +Un nodo client può rifiutarsi di riconoscere un certificato CA autofirmato come valido. +Per una distribuzione non di produzione o per una distribuzione che viene eseguita dietro una società +firewall, è possibile distribuire un certificato CA autofirmato a tutti i client e +aggiornare l'elenco locale per i certificati validi. + +Su ciascun client, eseguire le seguenti operazioni: + +```bash +$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +$ sudo update-ca-certificates +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## Certificates API + +È possibile utilizzare l'API `certificates.k8s.io` per eseguire il provisioning +certificati x509 da utilizzare per l'autenticazione come documentato +[here](/docs/tasks/tls/managing-tls-in-a-cluster). + +{{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/cloud-providers.md b/content/it/docs/concepts/cluster-administration/cloud-providers.md new file mode 100644 index 0000000000..f21d8e1ea1 --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/cloud-providers.md @@ -0,0 +1,387 @@ +--- +title: Cloud Providers +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} +Questa pagina spiega come gestire Kubernetes in esecuzione su uno specifico +fornitore di servizi cloud. +{{% /capture %}} + + +{{% capture body %}} +### kubeadm +[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) è un'opzione popolare per la creazione di cluster di kuberneti. +kubeadm ha opzioni di configurazione per specificare le informazioni di configurazione per i provider cloud. Ad esempio un tipico +il provider cloud in-tree può essere configurato utilizzando kubeadm come mostrato di seguito: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta1 +kind: InitConfiguration +nodeRegistration: + kubeletExtraArgs: + cloud-provider: "openstack" + cloud-config: "/etc/kubernetes/cloud.conf" +--- +apiVersion: kubeadm.k8s.io/v1beta1 +kind: ClusterConfiguration +kubernetesVersion: v1.13.0 +apiServer: + extraArgs: + cloud-provider: "openstack" + cloud-config: "/etc/kubernetes/cloud.conf" + extraVolumes: + - name: cloud + hostPath: "/etc/kubernetes/cloud.conf" + mountPath: "/etc/kubernetes/cloud.conf" +controllerManager: + extraArgs: + cloud-provider: "openstack" + cloud-config: "/etc/kubernetes/cloud.conf" + extraVolumes: + - name: cloud + hostPath: "/etc/kubernetes/cloud.conf" + mountPath: "/etc/kubernetes/cloud.conf" +``` + +I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di comando +per [kube-apiserver] (/docs/admin/kube-apiserver/), [kube-controller-manager] (/docs/admin/kube-controller-manager/) e il +[Kubelet] (/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider è documentato di seguito. + +Per tutti i fornitori di servizi cloud esterni, seguire le istruzioni sui singoli repository. + +## AWS +Questa sezione descrive tutte le possibili configurazioni che possono +essere utilizzato durante l'esecuzione di Kubernetes su Amazon Web Services. + +### Node Name + +Il provider cloud AWS utilizza il nome DNS privato dell'istanza AWS come nome dell'oggetto Nodo Kubernetes. + +### Load Balancers +È possibile impostare [bilanciamento del carico esterno] (/docs/tasks/access-application-cluster/create-external-load-balancer/) +per utilizzare funzionalità specifiche in AWS configurando le annotazioni come mostrato di seguito. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example + namespace: kube-system + labels: + run: example + annotations: + service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value + service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http +spec: + type: LoadBalancer + ports: + - port: 443 + targetPort: 5556 + protocol: TCP + selector: + app: example +``` +È possibile applicare impostazioni diverse a un servizio di bilanciamento del carico in AWS utilizzando _annotations_. Quanto segue descrive le annotazioni supportate su ELB AWS: + +* `service.beta.kubernetes.io / aws-load-balancer-access-log-emit-interval`: utilizzato per specificare l'intervallo di emissione del registro di accesso. +* `service.beta.kubernetes.io / aws-load-balancer-access-log-enabled`: utilizzato sul servizio per abilitare o disabilitare i log di accesso. +* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-name`: usato per specificare il nome del bucket di log degli accessi s3. +* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-prefix`: utilizzato per specificare il prefisso del bucket del registro di accesso s3. +* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: "Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2" `. +* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o` https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o` tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e` aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP. +* `service.beta.kubernetes.io / aws-load-balancer-ssl-cert`: utilizzato nel servizio per richiedere un listener sicuro. Il valore è un certificato ARN valido. Per ulteriori informazioni, vedere [ELB Listener Config] (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN è un ARN certificato IAM o CM, ad es. `ARN: AWS: ACM: US-est-1: 123456789012: certificato / 12345678-1234-1234-1234-123456789012`. +* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-enabled`: utilizzato sul servizio per abilitare o disabilitare il drenaggio della connessione. +* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-timeout`: utilizzato sul servizio per specificare un timeout di drenaggio della connessione. +* `service.beta.kubernetes.io / aws-load-balancer-connection-idle-timeout`: utilizzato sul servizio per specificare il timeout della connessione inattiva. +* `service.beta.kubernetes.io / aws-load-balancer-cross-zone-load-bilanciamento-abilitato`: utilizzato sul servizio per abilitare o disabilitare il bilanciamento del carico tra zone. +* `service.beta.kubernetes.io / aws-load-balancer-extra-security-groups`: utilizzato sul servizio per specificare gruppi di sicurezza aggiuntivi da aggiungere a ELB creato +* `service.beta.kubernetes.io / aws-load-balancer-internal`: usato nel servizio per indicare che vogliamo un ELB interno. +* `service.beta.kubernetes.io / aws-load-balancer-proxy-protocol`: utilizzato sul servizio per abilitare il protocollo proxy su un ELB. Al momento accettiamo solo il valore `*` che significa abilitare il protocollo proxy su tutti i backend ELB. In futuro potremmo regolarlo per consentire l'impostazione del protocollo proxy solo su determinati backend. +* `service.beta.kubernetes.io / aws-load-balancer-ssl-ports`: utilizzato sul servizio per specificare un elenco di porte separate da virgole che utilizzeranno listener SSL / HTTPS. Il valore predefinito è `*` (tutto) + +Le informazioni per le annotazioni per AWS sono tratte dai commenti su [aws.go] (https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go) + +## Azure + +### Node Name + +Il provider cloud di Azure utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. +Si noti che il nome del nodo Kubernetes deve corrispondere al nome VM di Azure. + +## CloudStack + +### Node Name + +Il provider cloud CloudStack utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. +Si noti che il nome del nodo Kubernetes deve corrispondere al nome VM di CloudStack. + +## GCE + +### Node Name + +Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. +Si noti che il primo segmento del nome del nodo Kubernetes deve corrispondere al nome dell'istanza GCE (ad esempio, un nodo denominato `kubernetes-node-2.c.my-proj.internal` deve corrispondere a un'istanza denominata` kubernetes-node-2`) . + +## OpenStack +Questa sezione descrive tutte le possibili configurazioni che possono +essere utilizzato quando si utilizza OpenStack con Kubernetes. + +### Node Name + +Il provider cloud OpenStack utilizza il nome dell'istanza (come determinato dai metadati OpenStack) come nome dell'oggetto Nodo Kubernetes. +Si noti che il nome dell'istanza deve essere un nome nodo Kubernetes valido affinché kubelet registri correttamente il suo oggetto Node. + +### Services + +Il provider cloud OpenStack +implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da +la nuvola sottostante, ove disponibile: + +| Servizio | Versioni API | Richiesto | +| -------------------------- | ---------------- | ----- ----- | +| Block Storage (Cinder) | V1 †, V2, V3 | No | +| Calcola (Nova) | V2 | No | +| Identity (Keystone) | V2 ‡, V3 | Sì | +| Load Balancing (Neutron) | V1§, V2 | No | +| Load Balancing (Octavia) | V2 | No | + +† Il supporto dell'API di storage block V1 è obsoleto, il supporto dell'API di Storage Block V3 era +aggiunto in Kubernetes 1.9. + +‡ Il supporto dell'API di Identity V2 è obsoleto e verrà rimosso dal provider in +una versione futura. A partire dalla versione "Queens", OpenStack non esporrà più il file +Identity V2 API. + + +§ Il supporto per il bilanciamento del carico V1 API è stato rimosso in Kubernetes 1.9. + +La scoperta del servizio si ottiene elencando il catalogo dei servizi gestito da +OpenStack Identity (Keystone) usando `auth-url` fornito nel provider +configurazione. Il fornitore si degraderà garbatamente in funzionalità quando +I servizi OpenStack diversi da Keystone non sono disponibili e semplicemente disconoscono +supporto per le caratteristiche interessate. Alcune funzionalità sono anche abilitate o disabilitate +in base all'elenco delle estensioni pubblicate da Neutron nel cloud sottostante. + +### cloud.conf +Kubernetes sa come interagire con OpenStack tramite il file cloud.conf. È +il file che fornirà a Kubernetes le credenziali e il percorso per l'endpoint auth di OpenStack. +È possibile creare un file cloud.conf specificando i seguenti dettagli in esso + +#### Typical configuration +Questo è un esempio di una configurazione tipica che tocca i valori più +spesso devono essere impostati. Punta il fornitore al Keystone del cloud di OpenStack +endpoint, fornisce dettagli su come autenticarsi con esso e configura il +bilanciamento del carico: + +```yaml +[Global] +username=user +password=pass +auth-url=https:///identity/v3 +tenant-id=c869168a828847f39f7f06edd7305637 +domain-id=2a73b8f597c04551a0fdc8e95544be8a + +[LoadBalancer] +subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a +``` + +##### Global +Queste opzioni di configurazione per il provider OpenStack riguardano la sua globalità +configurazione e dovrebbe apparire nella sezione `[Globale]` di `cloud.conf` +file: + +* `auth-url` (obbligatorio): l'URL dell'API keystone utilizzata per l'autenticazione. Sopra +  Pannelli di controllo OpenStack, questo può essere trovato in Access and Security> API +  Accesso> Credenziali. +* `username` (obbligatorio): si riferisce al nome utente di un set utente valido in keystone. +* `password` (obbligatorio): fa riferimento alla password di un set utente valido in keystone. +* `tenant-id` (obbligatorio): usato per specificare l'id del progetto dove si desidera +  per creare le tue risorse. +* `tenant-name` (Opzionale): utilizzato per specificare il nome del progetto in cui si trova +  vuoi creare le tue risorse. +* `trust-id` (Opzionale): utilizzato per specificare l'identificativo del trust da utilizzare +  autorizzazione. Un trust rappresenta l'autorizzazione di un utente (il fidato) a +  delegare i ruoli a un altro utente (il trustee) e facoltativamente consentire al trustee +  per impersonare il fiduciario. I trust disponibili si trovano sotto +  `/v3/OS-TRUST/trust` endpoint dell'API Keystone. +* `domain-id` (Opzionale): usato per specificare l'id del dominio a cui appartiene l'utente +  a. +* `domain-name` (Opzionale): utilizzato per specificare il nome del dominio dell'utente +  appartiene a. +* `region` (Opzionale): utilizzato per specificare l'identificatore della regione da utilizzare quando +  in esecuzione su un cloud OpenStack multiregionale. Una regione è una divisione generale di +  una distribuzione OpenStack. Anche se una regione non ha una geografia rigorosa +  connotazione, una distribuzione può utilizzare un nome geografico per un identificatore di regione +  come `us-east`. Le regioni disponibili si trovano sotto `/v3/region` +  endpoint dell'API Keystone. +* `ca-file` (Opzionale): utilizzato per specificare il percorso del file CA personalizzato. + + +Quando si usa Keystone V3 - che cambia il titolare del progetto - il valore `tenant-id` +viene automaticamente associato al costrutto del progetto nell'API. + +##### Load Balancer +Queste opzioni di configurazione per il provider OpenStack riguardano il carico +bilanciamento e dovrebbe apparire nella sezione `[LoadBalancer]` di `cloud.conf` +file: + +* `lb-version` (Opzionale): usato per sovrascrivere il rilevamento automatico della versione. Valido +  i valori sono `v1` o` v2`. Dove non viene fornito alcun valore, lo sarà il rilevamento automatico +  seleziona la versione supportata più alta esposta dal sottostante OpenStack +  nube. +* `use-octavia` (Opzionale): utilizzato per determinare se cercare e utilizzare un +  Octavia LBaaS V2 endpoint del catalogo di servizi. I valori validi sono `true` o` false`. +  Dove `true` è specificato e non è possibile trovare una voce V2 Octaiva LBaaS, il +  il provider si ritirerà e tenterà di trovare un endpoint Neutron LBaaS V2 +  anziché. Il valore predefinito è `false`. +* `subnet-id` (Opzionale): usato per specificare l'id della sottorete che si desidera +  crea il tuo loadbalancer su Può essere trovato su Rete> Reti. Clicca sul +  rispettiva rete per ottenere le sue sottoreti. +* `floating-network-id` (Opzionale): se specificato, creerà un IP mobile per +  il bilanciamento del carico. +* `lb-method` (Opzionale): utilizzato per specificare l'algoritmo in base al quale verrà caricato il carico +  distribuito tra i membri del pool di bilanciamento del carico. Il valore può essere +  `ROUND_ROBIN`,` LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se +  nessuno è specificato è `ROUND_ROBIN`. +* `lb-provider` (Opzionale): utilizzato per specificare il provider del servizio di bilanciamento del carico. +  Se non specificato, sarà il servizio provider predefinito configurato in neutron +  Usato. +* `create-monitor` (Opzionale): indica se creare o meno una salute +  monitorare il bilanciamento del carico Neutron. I valori validi sono `true` e` false`. +  L'impostazione predefinita è `false`. Quando è specificato `true` quindi` monitor-delay`, +  `monitor-timeout`, e` monitor-max-retries` deve essere impostato. +* `monitor-delay` (Opzionale): il tempo tra l'invio delle sonde a +  membri del servizio di bilanciamento del carico. Assicurati di specificare un'unità di tempo valida. Le unità di tempo valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h" +* `monitor-timeout` (Opzionale): tempo massimo di attesa per un monitor +  per una risposta ping prima che scada. Il valore deve essere inferiore al ritardo +  valore. Assicurati di specificare un'unità di tempo valida. Le unità di tempo valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h" +* `monitor-max-retries` (Opzionale): numero di errori ping consentiti prima +  cambiare lo stato del membro del bilanciamento del carico in INATTIVO. Deve essere un numero +  tra 1 e 10. +* `manage-security-groups` (Opzionale): Determina se il carico è o meno +  il sistema di bilanciamento dovrebbe gestire automaticamente le regole del gruppo di sicurezza. Valori validi +  sono `true` e` false`. L'impostazione predefinita è `false`. Quando è specificato `true` +  `node-security-group` deve anche essere fornito. +* `node-security-group` (Opzionale): ID del gruppo di sicurezza da gestire. + +##### Block Storage +Queste opzioni di configurazione per il provider OpenStack riguardano lo storage a blocchi +e dovrebbe apparire nella sezione `[BlockStorage]` del file `cloud.conf`: + +* `bs-version` (Opzionale): usato per sovrascrivere il rilevamento automatico delle versioni. Valido +  i valori sono `v1`,` v2`, `v3` e` auto`. Quando `auto` è specificato automatico +  il rilevamento selezionerà la versione supportata più alta esposta dal sottostante +  Cloud OpenStack. Il valore predefinito se nessuno è fornito è `auto`. +* `trust-device-path` (Opzionale): Nella maggior parte degli scenari i nomi dei dispositivi a blocchi +  fornito da Cinder (ad esempio `/dev/vda`) non può essere considerato attendibile. Questo commutatore booleano +  questo comportamento Impostandolo su `true` risulta fidarsi dei nomi dei dispositivi a blocchi +  fornito da Cinder. Il valore predefinito di `false` risulta nella scoperta di +  il percorso del dispositivo in base al suo numero di serie e mappatura `/dev/disk/by-id` ed è +  l'approccio raccomandato +* `ignore-volume-az` (Opzionale): usato per influenzare l'uso della zona di disponibilità quando +  allegando i volumi di Cinder. Quando Nova e Cinder hanno una diversa disponibilità +  zone, questo dovrebbe essere impostato su `true`. Questo è più comunemente il caso in cui +  ci sono molte zone di disponibilità Nova ma solo una zona di disponibilità Cinder. +  Il valore predefinito è `false` per preservare il comportamento utilizzato in precedenza +  rilasci, ma potrebbero cambiare in futuro. + +Se si distribuiscono le versioni di Kubernetes <= 1.8 su una distribuzione OpenStack che utilizza +percorsi piuttosto che porte per distinguere tra endpoint potrebbe essere necessario +per impostare in modo esplicito il parametro `bs-version`. Un endpoint basato sul percorso è del +forma `http://foo.bar/ volume` mentre un endpoint basato sulla porta è del modulo +`Http://foo.bar: xxx`. + +In ambienti che utilizzano endpoint basati sul percorso e Kubernetes utilizza il precedente +logica di auto-rilevamento un errore dell'autodeterminazione della versione API BS non riuscito. Errore +restituito al tentativo di distacco del volume. Per risolvere questo problema lo è +possibile forzare l'uso dell'API di Cinder versione 2 aggiungendo questo al cloud +configurazione del provider: + +```yaml +[BlockStorage] +bs-version=v2 +``` + +##### Metadata +Queste opzioni di configurazione per il provider OpenStack riguardano i metadati e +dovrebbe apparire nella sezione `[Metadata]` del file `cloud.conf`: + +* `ricerca-ordine` (facoltativo): questo tasto di configurazione influenza il modo in cui il +  il provider recupera i metadati relativi alle istanze in cui viene eseguito. Il +  il valore predefinito di `configDrive, metadataService` risulta nel provider +  recuperare i metadati relativi all'istanza dall'unità di configurazione prima se +  disponibile e quindi il servizio di metadati. I valori alternativi sono: +  * `configDrive` - recupera solo i metadati dell'istanza dalla configurazione +    guidare. +  * `metadataService`: recupera solo i metadati dell'istanza dai metadati +    servizio. +  * `metadataService, configDrive` - Recupera i metadati dell'istanza dai metadati +    prima assistenza se disponibile, quindi l'unità di configurazione. + +  Influenzare questo comportamento può essere desiderabile come i metadati sul +  l'unità di configurazione può diventare obsoleta nel tempo, mentre il servizio di metadati +  fornisce sempre la vista più aggiornata. Non tutti i cloud di OpenStack forniscono +  sia l'unità di configurazione che il servizio di metadati e solo l'uno o l'altro +  potrebbe essere disponibile, motivo per cui l'impostazione predefinita è controllare entrambi. + +##### Router + +Queste opzioni di configurazione per il provider OpenStack riguardano [kubenet] +Il plugin di rete di Kubernetes dovrebbe apparire nella sezione `[Router]` di +File `cloud.conf`: + +* `router-id` (opzionale): se supporta la distribuzione Neutron del cloud sottostante +   l'estensione `extraroutes` quindi usa` router-id` per specificare un router da aggiungere +   percorsi per. Il router scelto deve estendersi alle reti private che contengono il tuo +   nodi del cluster (in genere esiste solo una rete di nodi e questo valore dovrebbe essere +   il router predefinito per la rete di nodi). Questo valore è necessario per utilizzare [kubenet] +   su OpenStack. + +[kubenet]: https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet + +{{% /capture %}} + +## OVirt + +### Node Name + +Il provider di cloud OVirt utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. +Si noti che il nome del nodo Kubernetes deve corrispondere al FQDN del VM (riportato da OVirt in ` ... `) +## Photon + +### Node Name + +Il provider cloud Photon utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. +Si noti che il nome del nodo Kubernetes deve corrispondere al nome VM Photon (o se "overrideIP` è impostato su true in` --cloud-config`, il nome del nodo Kubernetes deve corrispondere all'indirizzo IP della macchina virtuale Photon). + +## VSphere + +### Node Name + +Il provider cloud VSphere utilizza il nome host rilevato del nodo (come determinato dal kubelet) come nome dell'oggetto Nodo Kubernetes. + +Il parametro `--hostname-override` viene ignorato dal fornitore di cloud VSphere. + +## IBM Cloud Kubernetes Service + +### Compute nodes +Utilizzando il provider di servizi IBM Cloud Kubernetes, è possibile creare cluster con una combinazione di nodi virtuali e fisici (bare metal) in una singola zona o su più zone in una regione. Per ulteriori informazioni, consultare [Pianificazione dell'installazione di cluster e nodo di lavoro] (https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). + +Il nome dell'oggetto Nodo Kubernetes è l'indirizzo IP privato dell'istanza del nodo di lavoro IBM Cloud Kubernetes Service. + +### Networking +Il fornitore di servizi IBM Cloud Kubernetes fornisce VLAN per le prestazioni di rete di qualità e l'isolamento della rete per i nodi. È possibile configurare firewall personalizzati e criteri di rete Calico per aggiungere un ulteriore livello di sicurezza per il cluster o per connettere il cluster al data center on-prem tramite VPN. Per ulteriori informazioni, vedere [Pianificazione in-cluster e rete privata] (https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster). + +Per esporre le app al pubblico o all'interno del cluster, è possibile sfruttare i servizi NodePort, LoadBalancer o Ingress. È anche possibile personalizzare il bilanciamento del carico dell'applicazione Ingress con le annotazioni. Per ulteriori informazioni, vedere [Pianificazione per esporre le app con reti esterne] (https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning). + +### Storage +Il fornitore di servizi IBM Cloud Kubernetes sfrutta i volumi persistenti nativi di Kubernetes per consentire agli utenti di montare archiviazione di file, blocchi e oggetti cloud nelle loro app. È inoltre possibile utilizzare il componente aggiuntivo database-as-a-service e di terze parti per la memorizzazione permanente dei dati. Per ulteriori informazioni, vedere [Pianificazione dell'archiviazione persistente altamente disponibile] (https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning). + +## Baidu Cloud Container Engine + +### Node Name + +Il provider di cloud Baidu utilizza l'indirizzo IP privato del nodo (come determinato dal kubelet o sovrascritto con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. +Si noti che il nome del nodo Kubernetes deve corrispondere all'IP privato VM di Baidu. diff --git a/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md new file mode 100644 index 0000000000..5b0d5e87ce --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -0,0 +1,72 @@ +--- +title: Panoramica sull'amministrazione del cluster +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} +La panoramica dell'amministrazione del cluster è per chiunque crei o gestisca un cluster Kubernetes. +Presuppone una certa dimestichezza con i core Kubernetes [concetti] (/docs/concepts/). +{{% /capture %}} + +{{% capture body %}} +## Planning a cluster + +Consulta le guide in [Scelta della soluzione giusta] (/docs/setup/pick-right-solution/) per esempio su come pianificare, impostare e configurare i cluster di Kubernetes. Le soluzioni elencate in questo articolo sono chiamate *distros*. + +Prima di scegliere una guida, ecco alcune considerazioni: + + - Vuoi provare Kubernetes sul tuo computer o vuoi creare un cluster multi-nodo ad alta disponibilità? Scegli le distro più adatte alle tue esigenze. + - **Se si sta progettando per l'alta disponibilità**, imparare a configurare [cluster in più zone] (/docs/concepts/cluster-administration/federation/). + - Utilizzerai **un cluster di Kubernetes ospitato**, come [Motore di Google Kubernetes] (https://cloud.google.com/kubernetes-engine/) o **che ospita il tuo cluster**? + - Il tuo cluster sarà **on-premises** o **nel cloud (IaaS)**? Kubernetes non supporta direttamente i cluster ibridi. Invece, puoi impostare più cluster. + - **Se si sta configurando Kubernetes on-premises**, considerare quale [modello di rete] (/docs/concepts/cluster-administration/networking/) si adatta meglio. + - Avvierai Kubernetes su **hardware "bare metal"** o su **macchine virtuali (VM)**? + - Vuoi **solo eseguire un cluster**, oppure ti aspetti di fare **lo sviluppo attivo del codice del progetto di Kubernetes**? Se la +   Quest'ultimo, scegliere una distribuzione attivamente sviluppata. Alcune distribuzioni usano solo versioni binarie, ma +   offrire una maggiore varietà di scelte. + - Familiarizzare con i [componenti] (/docs/admin/cluster-components/) necessari per eseguire un cluster. + +Nota: non tutte le distro vengono mantenute attivamente. Scegli le distro che sono state testate con una versione recente di Kubernetes. + +## Managing a cluster + +* [Gestione di un cluster] (/docs/tasks/administration-cluster/cluster-management/) descrive diversi argomenti relativi al ciclo di vita di un cluster: creazione di un nuovo cluster, aggiornamento dei nodi master e worker del cluster, esecuzione della manutenzione del nodo (ad esempio kernel aggiornamenti) e aggiornamento della versione dell'API di Kubernetes di un cluster in esecuzione. + +* Scopri come [gestire i nodi] (/docs/concepts/nodi/node/). + +* Scopri come impostare e gestire la [quota di risorse] (/docs/concepts/policy/resource-quote/) per i cluster condivisi. + +## Proteggere un cluster + +* [Certificati](/docs/concepts/cluster-administration/certificates/) descrive i passaggi per generare certificati utilizzando diverse catene di strumenti. + +* [Kubernetes Container Environment](/docs/concepts/containers/container-environment-variables/) descrive l'ambiente per i contenitori gestiti Kubelet su un nodo Kubernetes. + +* [Controllo dell'accesso all'API di Kubernetes](/docs/reference/access-authn-authz/controlling-access/) descrive come impostare le autorizzazioni per gli utenti e gli account di servizio. + +* [Autenticazione](/docs/reference/access-authn-authz/authentication/) spiega l'autenticazione in Kubernetes, incluse le varie opzioni di autenticazione. + +* [Autorizzazione](/docs/reference/access-authn-authz/authorization/) è separato dall'autenticazione e controlla come vengono gestite le chiamate HTTP. + +* [Utilizzo dei controller di ammissione](/docs/reference/access-authn-authz/admission-controller/) spiega i plug-in che intercettano le richieste al server API Kubernetes dopo l'autenticazione e l'autorizzazione. + +* [Uso di Sysctls in un cluster Kubernetes](/docs/concepts/cluster-administration/sysctl-cluster/) descrive a un amministratore come utilizzare lo strumento da riga di comando `sysctl` per impostare i parametri del kernel. + +* [Controllo](/docs/tasks/debug-application-cluster/audit/) descrive come interagire con i log di controllo di Kubernetes. + + +### Securing the kubelet + * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) + * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) + +## Optional Cluster Services + +* [Integrazione DNS](/docs/concepts/services-networking/dns-pod-service/) descrive come risolvere un nome DNS direttamente su un servizio Kubernetes. + +* [Registrazione e monitoraggio delle attività del cluster](/docs/concepts/cluster-administration/logging/) spiega come funziona il logging in Kubernetes e come implementarlo. + +{{% /capture %}} + + diff --git a/content/it/docs/concepts/cluster-administration/controller-metrics.md b/content/it/docs/concepts/cluster-administration/controller-metrics.md new file mode 100644 index 0000000000..9cffd87f77 --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/controller-metrics.md @@ -0,0 +1,47 @@ +--- +title: Metriche del responsabile del controller +content_template: templates/concept +weight: 100 +--- + +{{% capture overview %}} +Le metriche del controller controller forniscono informazioni importanti sulle prestazioni e la salute di +il responsabile del controller. + +{{% /capture %}} + +{{% capture body %}} +## Cosa sono le metriche del controller + +Le metriche del controller forniscono informazioni importanti sulle prestazioni del controller. +Queste metriche includono le comuni metriche di runtime del linguaggio Go, come il conteggio go_routine e le metriche specifiche del controller come +latenze delle richieste etcd o latenze API Cloudprovider (AWS, GCE, OpenStack) che possono essere utilizzate +per valutare la salute di un cluster. + +A partire da Kubernetes 1.7, le metriche dettagliate di Cloudprovider sono disponibili per le operazioni di archiviazione per GCE, AWS, Vsphere e OpenStack. +Queste metriche possono essere utilizzate per monitorare lo stato delle operazioni di volume persistenti. + +Ad esempio, per GCE queste metriche sono chiamate: + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + + +## Configurazione + +In un cluster, le metriche di controller-manager sono disponibili da `http://localhost:10252/metrics` +dall'host su cui è in esecuzione il controller-manager. + +Le metriche sono emesse in [formato prometheus] (https://prometheus.io/docs/instrumenting/exposition_formats/). + +In un ambiente di produzione è possibile configurare prometheus o altri strumenti di misurazione delle metriche +per raccogliere periodicamente queste metriche e renderle disponibili in una sorta di database di serie temporali. + +{{% /capture %}} + diff --git a/content/it/docs/concepts/cluster-administration/federation.md b/content/it/docs/concepts/cluster-administration/federation.md new file mode 100644 index 0000000000..2783cfd3d0 --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/federation.md @@ -0,0 +1,186 @@ +--- +title: Federation +content_template: templates/concept +weight: 80 +--- + +{{% capture overview %}} + +{{< deprecationfilewarning >}} +{{< include "federation-deprecation-warning-note.md" >}} +{{< /deprecationfilewarning >}} + +Questa pagina spiega perché e come gestire più cluster di Kubernetes utilizzando +federazione. +{{% /capture %}} + +{{% capture body %}} +## Perché la federation + +La federation facilita la gestione di più cluster. Lo fa fornendo 2 +principali elementi costitutivi: + +  * Sincronizzare le risorse tra i cluster: la Federazione offre la possibilità di conservare +    risorse in più cluster sincronizzati. Ad esempio, è possibile garantire che la stessa distribuzione esista in più cluster. +  * Rilevamento cross cluster: Federation offre la possibilità di configurare automaticamente server DNS e load balancer con i backend di tutti i cluster. Ad esempio, è possibile garantire che un record VIP o DNS globale possa essere utilizzato per accedere ai backend da più cluster. + +Alcuni altri casi d'uso abilitati dalla federazione sono: + +* Alta disponibilità: distribuendo il carico tra i cluster e la configurazione automatica del DNS +  server e bilanciamento del carico, la federazione riduce al minimo l'impatto del cluster +  fallimento. +* Evitare il lock-in del provider: semplificando la migrazione delle applicazioni +  cluster, la federazione impedisce il lock-in del provider di cluster. + +La federazione non è utile se non si hanno più cluster. Alcuni dei motivi +perché potresti volere che più cluster siano: + +* Bassa latenza: la presenza di cluster in più regioni riduce al minimo la latenza servendo +  utenti dal cluster che è più vicino a loro. +* Isolamento dei guasti: potrebbe essere meglio avere più cluster piccoli +  di un singolo cluster di grandi dimensioni per l'isolamento dei guasti (ad esempio: multiplo +  cluster in diverse zone di disponibilità di un provider cloud). +* Scalabilità: esistono limiti di scalabilità per un singolo cluster di kubernetes (questo +  non dovrebbe essere il caso per la maggior parte degli utenti. Per ulteriori dettagli: +  [Scaling di Kubernetes e obiettivi di rendimento] (https://git.k8s.io/community/sig-scalability/goals.md)). +* [Hybrid cloud] (# hybrid-cloud-capabilities): è possibile avere più cluster su diversi provider cloud o +  data center locali. + +### Caveats + +ci sono un sacco di casi d'uso interessanti per la federazione, ci sono anche +alcuni avvertimenti: + +* Maggiore larghezza di banda e costo della rete: l'aereo di controllo della federazione controlla tutto +  cluster per garantire che lo stato attuale sia come previsto. Questo può portare a +  costo di rete significativo se i cluster sono in esecuzione in diverse regioni in +  un provider cloud o su diversi provider cloud. +* Ridotto isolamento del cluster incrociato: un errore sul piano di controllo oils può +  impatto su tutti i cluster. Questo è mitigato mantenendo la logica in federazione +  piano di controllo al minimo. In gran parte delega al piano di controllo in +  cluster di kubernetes ogni volta che può. Anche la progettazione e l'implementazione sbagliano +  dal lato della sicurezza ed evitare l'interruzione del multi-cluster. +* Maturità: il progetto di federazione è relativamente nuovo e non è molto maturo. +  Non tutte le risorse sono disponibili e molte sono ancora alfa. [Problema +  88] (https://github.com/kubernetes/federation/issues/88) enumera +  problemi noti con il sistema che il team è impegnato a risolvere. + +### Hybrid cloud capabilities + +le federation di Kubernetes Clusters possono includere cluster in esecuzione +diversi fornitori di servizi cloud (ad esempio Google Cloud, AWS) e locali +(ad esempio su OpenStack). [Kubefed](https://kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/) è il metodo consigliato per la distribuzione di cluster federati. + +Successivamente, le [risorse API](#api-risorse) possono estendersi su diversi cluster +e fornitori di cloud. + +## Setting up federation + +Per poter federare più cluster, è necessario prima impostare una federazione +piano di controllo. +Seguire la [guida di installazione] (/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per configurare il +piano di controllo della federazione. + +## API resources + +Una volta impostato il piano di controllo, è possibile iniziare a creare l'API di federazione +risorse. +Le seguenti guide illustrano alcune delle risorse in dettaglio: + +* [Cluster](/docs/tasks/administer-federation/cluster/) +* [ConfigMap](/docs/tasks/administer-federation/configmap/) +* [DaemonSets](/docs/tasks/administer-federation/daemonset/) +* [Deployment](/docs/tasks/administer-federation/deployment/) +* [Events](/docs/tasks/administer-federation/events/) +* [Hpa](/docs/tasks/administer-federation/hpa/) +* [Ingress](/docs/tasks/administer-federation/ingress/) +* [Jobs](/docs/tasks/administer-federation/job/) +* [Namespaces](/docs/tasks/administer-federation/namespaces/) +* [ReplicaSets](/docs/tasks/administer-federation/replicaset/) +* [Secrets](/docs/tasks/administer-federation/secret/) +* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) + +I [documenti di riferimento API] (/docs/reference/federation/) elencano tutti i +risorse supportate da apiserver della federazione. +## Cascading deletion + +Kubernetes versione 1.6 include il supporto per l'eliminazione a cascata di federati +risorse. Con la cancellazione a cascata, quando si elimina una risorsa dal +piano di controllo della federazione, si eliminano anche le risorse corrispondenti in tutti i cluster sottostanti. + +L'eliminazione a cascata non è abilitata per impostazione predefinita quando si utilizza l'API REST. Abilitare +it, imposta l'opzione `DeleteOptions.orphanDependents = false` quando elimini a +risorsa dal piano di controllo della federazione utilizzando l'API REST. Usando `kubectl +delete` +abilita la cancellazione a cascata per impostazione predefinita. Puoi disabilitarlo eseguendo `kubectl +cancella --cascade = false` + +Nota: la versione 1.5 di Kubernetes includeva il supporto per l'eliminazione a cascata di un sottoinsieme di +risorse federative. + +## Ambito di un singolo cluster + +Sui provider IaaS come Google Compute Engine o Amazon Web Services, esiste una VM in a +[zona] (https://cloud.google.com/compute/docs/zones) o [disponibilità +zona] (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). +Suggeriamo che tutte le VM in un cluster Kubernetes debbano essere nella stessa zona di disponibilità, perché: + +  - Rispetto ad un singolo cluster globale di Kubernetes, ci sono meno punti singoli di errore. +  - confrontato con un cluster che copre le zone di disponibilità, è più facile ragionare sulle proprietà di disponibilità di a +    cluster a zona singola. +  - quando gli sviluppatori di Kubernetes stanno progettando il sistema (ad esempio facendo ipotesi su latenza, larghezza di banda o +    errori correlati) si presuppone che tutte le macchine si trovino in un unico data center o comunque strettamente connesse. + +Si consiglia di eseguire meno cluster con più VM per zona di disponibilità; ma è possibile eseguire più cluster per zone di disponibilità. + +I motivi per preferire un minor numero di cluster per zona di disponibilità sono: + +  - Miglioramento del confezionamento dei contenitori in alcuni casi con più nodi in un cluster (minore frammentazione delle risorse). +  - riduzione delle spese generali operative (sebbene il vantaggio sia diminuito man mano che gli strumenti operativi e i processi maturano). +  - costi ridotti per i costi fissi delle risorse per gruppo, ad es. VM di apiserver (ma piccole in percentuale +    del costo complessivo del cluster per cluster di dimensioni medio-grandi). + +I motivi per avere più cluster includono: + +  - rigide politiche di sicurezza che richiedono l'isolamento di una classe di lavoro da un'altra (ma, vedi Partizionare Cluster +    sotto). +  - testare i cluster su nuove versioni di Kubernetes o su altri software cluster. + +## Selezione del numero corretto di cluster + +La selezione del numero di cluster di Kubernetes può essere una scelta relativamente statica, rivisitata solo occasionalmente. +Al contrario, il numero di nodi in un cluster e il numero di pod in un servizio possono variare di frequente in base a +carico e crescita. + +Per scegliere il numero di cluster, in primo luogo, decidere in quali regioni è necessario avere una latenza adeguata per tutti gli utenti finali, per i servizi che verranno eseguiti +su Kubernetes (se si utilizza una rete di distribuzione di contenuti, i requisiti di latenza per i contenuti ospitati da CDN non sono necessari +essere considerato). Questioni legali potrebbero influenzare anche questo. Ad esempio, un'azienda con una base clienti globale potrebbe decidere di avere cluster nelle regioni USA, UE, AP e SA. +Chiama il numero di regioni in "R". + +In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stesso tempo, pur essendo disponibili. Chiamata +il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta. + +Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora +avete bisogno almeno dei grossi `R` o` U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti +utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)` +(`U + 1` in ciascuna delle regioni` R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa. + +Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora +potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8 +cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni] (/docs/setup/cluster-large/) per maggiori informazioni. + +{{% /capture %}} + +{{% capture whatsnext %}} +* Ulteriori informazioni sulla [Federazione +   proposta] (https://github.com/kubernetes/community/blob/{{}}/contributors/design-proposal/multicluster/federation.md). +* Vedi questo [guida alla configurazione] (/ docs / tutorial / federazione / set-up-cluster-federation-kubefed /) per la federazione dei cluster. +* Vedi questo [Kubecon2016 talk on federation] (https://www.youtube.com/watch?v=pq9lbkmxpS8) +* Vedi questo [Kubecon2017 aggiornamento Europa sulla federazione] (https://www.youtube.com/watch?v=kwOvOLnFYck) +* Vedi questo [Kubecon2018 aggiornamento Europa su sig-multicluster] (https://www.youtube.com/watch?v=vGZo5DaThQU) +* Vedi questo [Kubecon2018 Europe Federation-v2 presentazione prototipo] (https://youtu.be/q27rbaX5Jis?t=7m20s) +* Vedi questo [Federation-v2 Userguide] (https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) +{{% /capture %}} + + + diff --git a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md new file mode 100644 index 0000000000..3afda3c2bf --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -0,0 +1,90 @@ +--- + +title: Configurazione della raccolta dati kubelet +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} + +La garbage collection è una funzione utile di kubelet che pulisce le immagini inutilizzate e i contenitori inutilizzati. Kubelet eseguirà la raccolta dei rifiuti per i contenitori ogni minuto e la raccolta dei dati inutili per le immagini ogni cinque minuti. + +Gli strumenti di garbage collection esterni non sono raccomandati in quanto questi strumenti possono potenzialmente interrompere il comportamento di kubelet rimuovendo i contenitori che si prevede esistano. +{{% /capture %}} + + +{{% capture body %}} + +## Image Collection + +Kubernetes gestisce il ciclo di vita di tutte le immagini tramite imageManager, con la collaborazione +di consulente. + +La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori: +`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta +attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo +soglia è stata soddisfatta. + +La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori: +`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta +attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo +soglia è stata soddisfatta. + +## Container Collection + +La politica per i contenitori di garbage collection considera tre variabili definite dall'utente. `MinAge` è l'età minima in cui un contenitore può essere raccolto dalla spazzatura. `MaxPerPodContainer` è il numero massimo di contenitori morti ogni singolo +la coppia pod (UID, nome contenitore) può avere. `MaxContainers` è il numero massimo di contenitori morti totali. Queste variabili possono essere disabilitate individualmente impostando `MinAge` a zero e impostando` MaxPerPodContainer` e `MaxContainers` rispettivamente a meno di zero. + +Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei limiti impostati dalle bandiere precedentemente menzionate. I contenitori più vecchi saranno generalmente rimossi per primi. `MaxPerPodContainer` e` MaxContainer` possono potenzialmente entrare in conflitto l'uno con l'altro in situazioni in cui il mantenimento del numero massimo di contenitori per pod (`MaxPerPodContainer`) non rientra nell'intervallo consentito di contenitori morti globali (` MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe quello di eseguire il downgrade di` MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i contenitori di proprietà dei pod che sono stati cancellati vengono rimossi una volta che sono più vecchi di "MinAge". + +I contenitori che non sono gestiti da Kubelet non sono soggetti alla garbage collection del contenitore. + +## User Configuration + +Gli utenti possono regolare le seguenti soglie per ottimizzare la garbage collection delle immagini con i seguenti flag kubelet: + +1. `image-gc-high-threshold`, la percentuale di utilizzo del disco che attiva la garbage collection dell'immagine. +Il valore predefinito è 85%. +2. `image-gc-low-threshold`, la percentuale di utilizzo del disco su cui tenta la garbage collection dell'immagine +liberare. Il valore predefinito è 80%. + +Permettiamo anche agli utenti di personalizzare la politica di raccolta dei rifiuti attraverso i seguenti flag kubelet: + +1. `minimum-container-ttl-duration`, l'età minima per un container finito prima che sia +raccolta dei rifiuti L'impostazione predefinita è 0 minuti, il che significa che ogni contenitore finito verrà raccolto. +2. `maximum-dead-containers-per-container`, numero massimo di vecchie istanze da conservare +per contenitore Il valore predefinito è 1. +3. `maximum-dead-containers`, numero massimo di vecchie istanze di container da conservare globalmente. +Il valore predefinito è -1, il che significa che non esiste un limite globale. + +I contenitori possono potenzialmente essere raccolti prima che la loro utilità sia scaduta. Questi contenitori +può contenere log e altri dati che possono essere utili per la risoluzione dei problemi. Un valore sufficientemente grande per +`maximum-dead-containers-per-container` è altamente raccomandato per consentire almeno un contenitore morto +mantenuto per contenitore previsto. Un valore più grande per "massimo-dead-containers" è anche raccomandato per a +motivo simile. +Vedi [questo problema] (https://github.com/kubernetes/kubernetes/issues/13287) per maggiori dettagli. + + +## Deprecation + +Alcune funzionalità di raccolta dei rifiuti di Kubelet in questo documento verranno sostituite da sfratti di Kubelet in futuro. + +Compreso: + +| Bandiera esistente | Nuova bandiera | Motivazione +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` o` --eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | i reclami di sfratto ottengono lo stesso comportamento | +| `--maximum-dead-containers` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore | +| `--maximum-dead-containers-per-container` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore | +| `--minimum-container-ttl-duration` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore | +| `--low-diskspace-threshold-mb` | `--eviction-hard` o` eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | lo sfratto generalizza la transizione della pressione del disco verso altre risorse | + +{{% /capture %}} + +{{% capture whatsnext %}} + +Vedi [Configurazione della gestione delle risorse esterne](/docs/tasks/administration-cluster/out-of-resource/) per maggiori dettagli. + +{{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/logging.md b/content/it/docs/concepts/cluster-administration/logging.md new file mode 100644 index 0000000000..b576bf0f52 --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/logging.md @@ -0,0 +1,258 @@ +--- +title: Log di registrazione +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +I log di applicazioni e sistemi possono aiutarti a capire cosa sta accadendo all'interno del tuo cluster. I log sono particolarmente utili per il debug dei problemi e il monitoraggio delle attività del cluster. La maggior parte delle applicazioni moderne ha una sorta di meccanismo di registrazione; in quanto tale, la maggior parte dei motori di container sono progettati allo stesso modo per supportare alcuni tipi di registrazione. Il metodo di registrazione più semplice e più accettato per le applicazioni containerizzate è scrivere sull'output standard e sui flussi di errore standard. + +Tuttavia, la funzionalità nativa fornita da un motore contenitore o dal runtime di solito non è sufficiente per una soluzione di registrazione completa. Ad esempio, se un container si arresta in modo anomalo, un pod viene rimosso, o un nodo muore, di solito vuoi comunque accedere ai log dell'applicazione. Pertanto, i registri devono avere una memoria e un ciclo di vita separati, indipendenti da nodi, pod o contenitori. Questo concetto è chiamato _cluster-logging_. La registrazione a livello di cluster richiede un back-end separato per archiviare, analizzare e interrogare i registri. Kubernetes non fornisce alcuna soluzione di archiviazione nativa per i dati di registro, ma è possibile integrare molte soluzioni di registrazione esistenti nel proprio cluster Kubernetes. + +{{% /capture %}} + + +{{% capture body %}} + +Le architetture di registrazione a livello di cluster sono descritte nel presupposto che +un back-end per la registrazione è presente all'interno o all'esterno del cluster. Se tu sei +non interessa avere la registrazione a livello di cluster, potresti ancora trovarlo +la descrizione di come i registri sono memorizzati e gestiti sul nodo per essere utile. + +## Basic logging in Kubernetes + +In questa sezione, puoi vedere un esempio di registrazione di base in Kubernetes +emette i dati sul flusso di output standard. Utilizza questa dimostrazione +una [specifica pod] (/esempi/debug/counter-pod.yaml) con +un contenitore che scrive del testo sullo standard output una volta al secondo. + +{{< codenew file="debug/counter-pod.yaml" >}} + +Per eseguire questo pod, utilizzare il seguente comando: + +```shell +$ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml +pod/counter created +``` + +Per recuperare i registri, usa il comando `kubectl logs`, come segue: + +```shell +$ kubectl logs counter +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + +You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag` --previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`] (/docs/reference/generated/kubectl/kubectl-commands # logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details. + +## Logging at the node level + +! [Node level logging] (/images/docs/user-guide/logging/logging-node-level.png) + +Tutto ciò che una applicazione containerizzata scrive su `stdout` e` stderr` viene gestito e reindirizzato da qualche parte da un motore contenitore. Ad esempio, il motore del contenitore Docker reindirizza questi due flussi a [un driver di registrazione] (https://docs.docker.com/engine/admin/logging/overview), che è configurato in Kubernetes per scrivere su un file in formato json . + +{{}} +Il driver di registrazione di Docker json considera ogni riga come un messaggio separato. Quando si utilizza il driver di registrazione di Docker, non esiste un supporto diretto per i messaggi su più righe. È necessario gestire i messaggi multilinea a livello di agente di registrazione o superiore. +{{}} + +Di default, se un container si riavvia, kubelet mantiene un container terminato con i suoi log. Se un pod viene espulso dal nodo, tutti i contenitori corrispondenti vengono espulsi, insieme ai loro log. + +Una considerazione importante nella registrazione a livello di nodo sta implementando la rotazione dei log, +in modo che i registri non consumino tutta la memoria disponibile sul nodo. kubernetes +al momento non è responsabile della rotazione dei registri, ma piuttosto di uno strumento di distribuzione +dovrebbe creare una soluzione per affrontarlo. +Ad esempio, nei cluster di Kubernetes, implementato dallo script `kube-up.sh`, +c'è un [`logrotate`] (https://linux.die.net/man/8/logrotate) +strumento configurato per funzionare ogni ora. È anche possibile impostare un runtime del contenitore su +ruotare automaticamente i registri dell'applicazione, ad es. usando il `log-opt` di Docker. +Nello script `kube-up.sh`, quest'ultimo approccio viene utilizzato per l'immagine COS su GCP, +e il primo approccio è usato in qualsiasi altro ambiente. In entrambi i casi, da +la rotazione predefinita è configurata per essere eseguita quando il file di registro supera 10 MB. + +Ad esempio, puoi trovare informazioni dettagliate su come `kube-up.sh` imposta +up logging per l'immagine COS su GCP nello [script] [cosConfigureHelper] corrispondente. + +Quando esegui [`kubectl logs`] (/docs/reference/generated/kubectl/kubectl-commands#logs) come in +l'esempio di registrazione di base, il kubelet sul nodo gestisce la richiesta e +legge direttamente dal file di log, restituendo il contenuto nella risposta. + +{{}} +Attualmente, se un sistema esterno ha eseguito la rotazione, +sarà disponibile solo il contenuto dell'ultimo file di registro +`log di kubectl`. Per esempio. se c'è un file da 10 MB, esegue `logrotate` +la rotazione e ci sono due file, uno da 10 MB e uno vuoto, +`kubectl logs` restituirà una risposta vuota. +{{< /note >}} + +[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh + +### System component logs + +Esistono due tipi di componenti di sistema: quelli che vengono eseguiti in un contenitore e quelli +che non funziona in un contenitore. Per esempio: + +* Lo scheduler di Kubernetes e il proxy kube vengono eseguiti in un contenitore. +* Il kubelet e il runtime del contenitore, ad esempio Docker, non vengono eseguiti nei contenitori. + +Sulle macchine con systemd, il kubelet e il runtime del contenitore scrivono su journal. Se +systemd non è presente, scrive nei file `.log` nella directory`/var/log`. +I componenti di sistema all'interno dei contenitori scrivono sempre nella directory `/var/log`, +bypassando il meccanismo di registrazione predefinito. Usano il [klog] [klog] +biblioteca di registrazione. È possibile trovare le convenzioni per la gravità della registrazione per quelli +componenti nel [documento di sviluppo sulla registrazione](https://git.k8s.io/community/contributors/devel/logging.md). + +Analogamente ai log del contenitore, i log dei componenti di sistema sono in /var/log` +la directory dovrebbe essere ruotata. Nei cluster di Kubernetes allevati da +lo script `kube-up.sh`, quei log sono configurati per essere ruotati da +lo strumento `logrotate` al giorno o una volta che la dimensione supera i 100 MB. + +[klog]: https://github.com/kubernetes/klog + +## Cluster-level logging architectures + +Sebbene Kubernetes non fornisca una soluzione nativa per la registrazione a livello di cluster, esistono diversi approcci comuni che è possibile prendere in considerazione. Ecco alcune opzioni: + +* Utilizzare un agente di registrazione a livello di nodo che viene eseguito su ogni nodo. +* Includere un contenitore sidecar dedicato per l'accesso a un pod di applicazione. +* Invia i registri direttamente a un back-end dall'interno di un'applicazione. + +### Using a node logging agent + +![Using a node level logging agent](/images/docs/user-guide/logging/logging-with-node-agent.png) + +È possibile implementare la registrazione a livello di cluster includendo _un agente di registrazione a livello_ node su ciascun nodo. L'agente di registrazione è uno strumento dedicato che espone i registri o trasferisce i registri a un back-end. Comunemente, l'agente di registrazione è un contenitore che ha accesso a una directory con file di registro da tutti i contenitori delle applicazioni su quel nodo. + +Poiché l'agente di registrazione deve essere eseguito su ogni nodo, è comune implementarlo come una replica DaemonSet, un pod manifest o un processo nativo dedicato sul nodo. Tuttavia, questi ultimi due approcci sono deprecati e altamente scoraggiati. + +L'utilizzo di un agent di registrazione a livello di nodo è l'approccio più comune e consigliato per un cluster Kubernetes, poiché crea solo un agente per nodo e non richiede alcuna modifica alle applicazioni in esecuzione sul nodo. Tuttavia, la registrazione a livello di nodo funziona _solo per l'output standard delle applicazioni e l'errore standard_. + +Kubernetes non specifica un agente di registrazione, ma due agenti di registrazione facoltativi sono impacchettati con la versione di Kubernetes: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) da utilizzare con Google Cloud Platform e [Elasticsearch](/docs/user-guide/logging/elasticsearch). Puoi trovare ulteriori informazioni e istruzioni nei documenti dedicati. Entrambi usano [fluentd](http://www.fluentd.org/) con configurazione personalizzata come agente sul nodo. + +### Using a sidecar container with the logging agent + +Puoi utilizzare un contenitore sidecar in uno dei seguenti modi: + +* Il contenitore sidecar trasmette i log delle applicazioni al proprio `stdout`. +* Il contenitore sidecar esegue un agente di registrazione, che è configurato per raccogliere i registri da un contenitore di applicazioni. + +#### Streaming sidecar container + +![Sidecar container with a streaming container](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) + +Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e` stderr` +flussi, è possibile sfruttare il kubelet e l'agente di registrazione che +già eseguito su ciascun nodo. I contenitori del sidecar leggono i log da un file, un socket, +o il diario. Ogni singolo contenitore sidecar stampa il log nel proprio `stdout` +o flusso `stderr`. + +Questo approccio consente di separare diversi flussi di log da diversi +parti della tua applicazione, alcune delle quali possono mancare di supporto +per scrivere su `stdout` o` stderr`. La logica dietro il reindirizzamento dei registri +è minimo, quindi non è un sovraccarico significativo. Inoltre, perché +`stdout` e` stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati +come `log di kubectl`. + +Considera il seguente esempio. Un pod esegue un singolo contenitore e il contenitore +scrive su due file di registro diversi, utilizzando due formati diversi. Ecco un +file di configurazione per il pod: + +{{}} + +Sarebbe un disastro avere voci di registro di diversi formati nello stesso registro +stream, anche se si è riusciti a reindirizzare entrambi i componenti al flusso `stdout` di +Il container. Invece, potresti introdurre due container sidecar. Ogni sidecar +contenitore potrebbe accodare un particolare file di registro da un volume condiviso e quindi reindirizzare +i registri al proprio flusso `stdout`. + +Ecco un file di configurazione per un pod con due contenitori sidecar: + +{{}} + +Ora quando si esegue questo pod, è possibile accedere separatamente a ciascun flusso di log +eseguendo i seguenti comandi: + +```shell +$ kubectl logs counter count-log-1 +0: Mon Jan 1 00:00:00 UTC 2001 +1: Mon Jan 1 00:00:01 UTC 2001 +2: Mon Jan 1 00:00:02 UTC 2001 +... +``` + +```shell +$ kubectl logs counter count-log-2 +Mon Jan 1 00:00:00 UTC 2001 INFO 0 +Mon Jan 1 00:00:01 UTC 2001 INFO 1 +Mon Jan 1 00:00:02 UTC 2001 INFO 2 +... +``` + +L'agente a livello di nodo installato nel cluster preleva tali flussi di log +automaticamente senza alcuna ulteriore configurazione. Se ti piace, puoi configurare +l'agente per analizzare le righe di registro in base al contenitore di origine. + +Si noti che, nonostante il basso utilizzo della CPU e della memoria (ordine di un paio di millesimi +per cpu e ordine di diversi megabyte per memoria), scrivere registri su un file e +quindi il loro streaming su `stdout` può raddoppiare l'utilizzo del disco. Se hai +un'applicazione che scrive in un singolo file, è generalmente meglio impostare +`/dev/stdout` come destinazione piuttosto che implementare il sidecar streaming +approccio contenitore. + +I contenitori del sidecar possono anche essere usati per ruotare i file di log che non possono essere +ruotato dall'applicazione stessa. [Un esempio](https://github.com/samsung-cnct/logrotate) +di questo approccio è un piccolo contenitore che esegue periodicamente logrotate. +Tuttavia, si raccomanda di usare `stdout` e` stderr` direttamente e lasciare la rotazione +e politiche di conservazione al kubelet. + + +#### Sidecar container with a logging agent + +![Sidecar container with a logging agent](/images/docs/user-guide/logging/logging-with-sidecar-agent.png) + +Se l'agente di registrazione a livello di nodo non è abbastanza flessibile per la tua situazione, tu +puoi creare un container sidecar con un logger separato che hai +configurato specificamente per essere eseguito con la tua applicazione. + +{{}} +Può essere utilizzato un agente di registrazione in un container sidecar +al consumo significativo di risorse. Inoltre, non sarai in grado di accedere +quei log usando il comando `kubectl logs`, perché non sono controllati +dal kubelet. +{{}} + +Ad esempio, è possibile utilizzare [Stackdriver] (/docs/tasks/debug-application-cluster/logging-stackdriver/), +che utilizza fluentd come agente di registrazione. Qui ci sono due file di configurazione +puoi usare per implementare questo approccio. Il primo file contiene +a [ConfigMap] (/docs/tasks/configure-pod-container/configure-pod-configmap/) per configurare fluentd. + +{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} + +{{< note >}} +La configurazione di fluentd esula dallo scopo di questo articolo. Per +informazioni sulla configurazione di fluentd, vedere il +[documentazione fluentd ufficiale] (http://docs.fluentd.org/). +{{< /note >}} + +Il secondo file descrive un pod con un contenitore sidecar in esecuzione fluentd. +Il pod monta un volume dove fluentd può raccogliere i suoi dati di configurazione. + +{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} + +Dopo un po 'di tempo è possibile trovare i messaggi di registro nell'interfaccia Stackdriver. + +Ricorda che questo è solo un esempio e puoi effettivamente sostituire fluentd +con qualsiasi agente di registrazione, leggendo da qualsiasi fonte all'interno di un'applicazione +contenitore. + +### Exposing logs directly from the application + +![Exposing logs directly from the application](/images/docs/user-guide/logging/logging-from-application.png) + +È possibile implementare la registrazione a livello di cluster esponendo o spingendo i registri direttamente da +ogni applicazione; tuttavia, l'implementazione di un tale meccanismo di registrazione +è al di fuori dello scopo di Kubernetes. + +{{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/manage-deployment.md b/content/it/docs/concepts/cluster-administration/manage-deployment.md new file mode 100644 index 0000000000..35ca237dbe --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/manage-deployment.md @@ -0,0 +1,406 @@ +--- +title: Gestione delle risorse +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +Hai distribuito la tua applicazione e l'hai esposta tramite un servizio. Ora cosa? Kubernetes fornisce una serie di strumenti per aiutarti a gestire la distribuzione delle applicazioni, compreso il ridimensionamento e l'aggiornamento. Tra le caratteristiche che discuteremo in modo più approfondito ci sono [file di configurazione] (/docs/concepts/configuration/overview/) e [labels] (/docs/concepts/overview/working-with-objects/labels/). + +{{% /capture %}} + + +{{% capture body %}} + +## Organizzazione delle configurazioni delle risorse + +Molte applicazioni richiedono la creazione di più risorse, ad esempio una distribuzione e un servizio. La gestione di più risorse può essere semplificata raggruppandole nello stesso file (separate da `---` in YAML). Per esempio: + +{{< codenew file="application/nginx-app.yaml" >}} + +Multiple resources can be created the same way as a single resource: + +```shell +$ kubectl create -f https://k8s.io/examples/application/nginx-app.yaml +service/my-nginx-svc created +deployment.apps/my-nginx created +``` + +Le risorse verranno create nell'ordine in cui appaiono nel file. Pertanto, è meglio specificare prima il servizio, poiché ciò assicurerà che lo scheduler possa distribuire i pod associati al servizio man mano che vengono creati dal / i controller, ad esempio Deployment. + +`kubectl create` accetta anche più argomenti` -f`: + +```shell +$ kubectl create -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +``` + +E una directory può essere specificata piuttosto che o in aggiunta ai singoli file: +```shell +$ kubectl create -f https://k8s.io/examples/application/nginx/ +``` + +`kubectl` leggerà tutti i file con suffissi` .yaml`, `.yml` o` .json`. + +Si consiglia di inserire nello stesso file risorse correlate allo stesso livello di microservice o di applicazione e di raggruppare tutti i file associati all'applicazione nella stessa directory. Se i livelli dell'applicazione si associano tra loro tramite DNS, è quindi possibile distribuire in massa tutti i componenti dello stack. + +Un URL può anche essere specificato come origine di configurazione, utile per la distribuzione direttamente dai file di configurazione controllati in github: + +```shell +$ kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml +deployment.apps/my-nginx created +``` + +## Bulk operations in kubectl + +La creazione di risorse non è l'unica operazione che `kubectl` può eseguire alla rinfusa. Può anche estrarre i nomi delle risorse dai file di configurazione per eseguire altre operazioni, in particolare per eliminare le stesse risorse che hai creato: + +```shell +$ kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml +deployment.apps "my-nginx" deleted +service "my-nginx-svc" deleted +``` + +Nel caso di due sole risorse, è anche facile specificare entrambi sulla riga di comando usando la sintassi risorsa / nome: + +```shell +$ kubectl delete deployments/my-nginx services/my-nginx-svc +``` + +Per un numero maggiore di risorse, troverai più semplice specificare il selettore (query etichetta) specificato usando `-l` o` --selector`, per filtrare le risorse in base alle loro etichette: + +```shell +$ kubectl delete deployment,services -l app=nginx +deployment.apps "my-nginx" deleted +service "my-nginx-svc" deleted +``` + +130/5000 +Poiché `kubectl` restituisce i nomi delle risorse nella stessa sintassi che accetta, è facile concatenare le operazioni usando` $ () `o` xargs`: + +```shell +$ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s +``` + +Con i suddetti comandi, prima creiamo le risorse sotto `examples/application/nginx/` e stampiamo le risorse create con il formato di output `-o name` +(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con` kubectl get`. + +Se si organizzano le risorse su più sottodirectory all'interno di una particolare directory, è possibile eseguire ricorsivamente anche le operazioni nelle sottodirectory, specificando `--recursive` o` -R` accanto al flag `--filename, -f`. + +Ad esempio, supponiamo che ci sia una directory `project/k8s/development` che contiene tutti i manifesti necessari per l'ambiente di sviluppo, organizzati per tipo di risorsa: + +``` +project/k8s/development +├── configmap +│   └── my-configmap.yaml +├── deployment +│   └── my-deployment.yaml +└── pvc + └── my-pvc.yaml +``` + +Per impostazione predefinita, l'esecuzione di un'operazione bulk su `project/k8s/development` si interromperà al primo livello della directory, senza elaborare alcuna sottodirectory. Se avessimo provato a creare le risorse in questa directory usando il seguente comando, avremmo riscontrato un errore: + +```shell +$ kubectl create -f project/k8s/development +error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin) +``` + +Invece, specifica il flag `--recursive` o` -R` con il flag `--filename, -f` come tale: + +```shell +$ kubectl create -f project/k8s/development --recursive +configmap/my-config created +deployment.apps/my-deployment created +persistentvolumeclaim/my-pvc created +``` + +Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag` --filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .` + +Il flag `--recursive` funziona anche quando sono forniti più argomenti` -f`: + +```shell +$ kubectl create -f project/k8s/namespaces -f project/k8s/development --recursive +namespace/development created +namespace/staging created +configmap/my-config created +deployment.apps/my-deployment created +persistentvolumeclaim/my-pvc created +``` + +Se sei interessato a saperne di più su `kubectl`, vai avanti e leggi [Panoramica di kubectl] (/docs/reference/kubectl/overview/). + +## Usare le etichette in modo efficace + +Gli esempi che abbiamo utilizzato fino ad ora si applicano al massimo una singola etichetta a qualsiasi risorsa. Esistono molti scenari in cui è necessario utilizzare più etichette per distinguere i set l'uno dall'altro. + +Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook] (https://github.com/kubernetes/examples/tree/ {{}} / guestbook /), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette: +```yaml + labels: + app: guestbook + tier: frontend +``` + +while the Redis master and slave would have different `tier` labels, and perhaps even an additional `role` label: + +```yaml + labels: + app: guestbook + tier: backend + role: master +``` + +and + +```yaml + labels: + app: guestbook + tier: backend + role: slave +``` + +Le etichette ci permettono di tagliare e tagliare le nostre risorse lungo qualsiasi dimensione specificata da un'etichetta: + +```shell +$ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml +$ kubectl get pods -Lapp -Ltier -Lrole +NAME READY STATUS RESTARTS AGE APP TIER ROLE +guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend +guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend +guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend +guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master +guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave +guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave +my-nginx-divi2 1/1 Running 0 29m nginx +my-nginx-o0ef1 1/1 Running 0 29m nginx +$ kubectl get pods -lapp=guestbook,role=slave +NAME READY STATUS RESTARTS AGE +guestbook-redis-slave-2q2yf 1/1 Running 0 3m +guestbook-redis-slave-qgazl 1/1 Running 0 3m +``` + +## Distribuzioni canarie + +Un altro scenario in cui sono necessarie più etichette è quello di distinguere distribuzioni di diverse versioni o configurazioni dello stesso componente. È prassi comune distribuire un * canarino * di una nuova versione dell'applicazione (specificata tramite il tag immagine nel modello pod) parallelamente alla versione precedente in modo che la nuova versione possa ricevere il traffico di produzione in tempo reale prima di distribuirlo completamente. + +Ad esempio, puoi usare un'etichetta `track` per differenziare le diverse versioni. + +La versione stabile e primaria avrebbe un'etichetta `track` con valore come` stable`: + +```yaml + name: frontend + replicas: 3 + ... + labels: + app: guestbook + tier: frontend + track: stable + ... + image: gb-frontend:v3 +``` + +e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso (ad esempio` canary`), in modo che due gruppi di pod non si sovrappongano: + +```yaml + name: frontend-canary + replicas: 1 + ... + labels: + app: guestbook + tier: frontend + track: canary + ... + image: gb-frontend:v4 +``` + + +Il servizio di frontend coprirebbe entrambe le serie di repliche selezionando il sottoinsieme comune delle loro etichette (ad esempio omettendo l'etichetta `track`), in modo che il traffico venga reindirizzato ad entrambe le applicazioni: + +```yaml + selector: + app: guestbook + tier: frontend +``` + +452/5000 +È possibile modificare il numero di repliche delle versioni stable e canary per determinare il rapporto tra ciascuna versione che riceverà il traffico di produzione live (in questo caso, 3: 1). +Una volta che sei sicuro, puoi aggiornare la traccia stabile alla nuova versione dell'applicazione e rimuovere quella canarino. + +Per un esempio più concreto, controlla il [tutorial di distribuzione di Ghost] (https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary). + +## Updating labels + +A volte i pod esistenti e altre risorse devono essere rinominati prima di creare nuove risorse. Questo può essere fatto con l'etichetta `kubectl`. +Ad esempio, se desideri etichettare tutti i tuoi pod nginx come livello frontend, esegui semplicemente: + +```shell +$ kubectl label pods -l app=nginx tier=fe +pod/my-nginx-2035384211-j5fhi labeled +pod/my-nginx-2035384211-u2c7e labeled +pod/my-nginx-2035384211-u3t6x labeled +``` + +Questo prima filtra tutti i pod con l'etichetta "app = nginx", quindi li etichetta con il "tier = fe". +Per vedere i pod appena etichettati, esegui: + +```shell +$ kubectl get pods -l app=nginx -L tier +NAME READY STATUS RESTARTS AGE TIER +my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe +my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe +my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe +``` + +questo produce tutti i pod "app = nginx", con un'ulteriore colonna di etichette del livello dei pod (specificata con `-L` o` --label-columns`). + +Per ulteriori informazioni, consultare [labels] (/docs/concepts/overview/working-with-objects/labels/) e [kubectl label] (/docs/reference/generated/kubectl/kubectl-commands/ # label). + +## Aggiornare annotazioni + +A volte vorresti allegare annotazioni alle risorse. Le annotazioni sono metadati arbitrari non identificativi per il recupero da parte di client API come strumenti, librerie, ecc. Questo può essere fatto con `kubectl annotate`. Per esempio: + +```shell +$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' +$ kubectl get pods my-nginx-v4-9gw19 -o yaml +apiversion: v1 +kind: pod +metadata: + annotations: + description: my frontend running nginx +... +``` + +Per ulteriori informazioni, consultare il documento [annotazioni] (/docs/concepts/overview/working-with-objects/annotations/) e [kubectl annotate] (/docs/reference/generated/kubectl/kubectl-commands/ # annotate). + +## Ridimensionamento dell'applicazione + +Quando si carica o si riduce la richiesta, è facile ridimensionare con `kubectl`. Ad esempio, per ridurre il numero di repliche nginx da 3 a 1, fare: + +```shell +$ kubectl scale deployment/my-nginx --replicas=1 +deployment.extensions/my-nginx scaled +``` + +Ora hai solo un pod gestito dalla distribuzione + + +```shell +$ kubectl get pods -l app=nginx +NAME READY STATUS RESTARTS AGE +my-nginx-2035384211-j5fhi 1/1 Running 0 30m +``` + +Per fare in modo che il sistema scelga automaticamente il numero di repliche nginx secondo necessità, da 1 a 3, fare: + +```shell +$ kubectl autoscale deployment/my-nginx --min=1 --max=3 +horizontalpodautoscaler.autoscaling/my-nginx autoscaled +``` + +Ora le repliche di nginx verranno ridimensionate automaticamente in base alle esigenze. + +Per maggiori informazioni, vedi [scala kubectl] (/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale] (/docs/reference/generated/kubectl/kubectl-commands/#autoscale) e documento [orizzontale pod autoscaler] (/docs/tasks/run-application/horizontal-pod-autoscale/). + +## Aggiornamenti sul posto delle risorse + +A volte è necessario apportare aggiornamenti stretti e senza interruzioni alle risorse che hai creato. + +### kubectl apply + +Si consiglia di mantenere un set di file di configurazione nel controllo del codice sorgente (vedere [configurazione come codice] (http://martinfowler.com/bliki/InfrastructureAsCode.html)), +in modo che possano essere mantenuti e versionati insieme al codice per le risorse che configurano. +Quindi, puoi usare [`kubectl apply`] (/docs/reference/generated/kubectl/kubectl-commands/#apply) per inviare le modifiche alla configurazione nel cluster. + +Questo comando confronterà la versione della configurazione che stai spingendo con la versione precedente e applicherà le modifiche che hai apportato, senza sovrascrivere le modifiche automatiche alle proprietà che non hai specificato. + +```shell +$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +deployment.apps/my-nginx configured +``` + +Si noti che `kubectl apply` allega un'annotazione alla risorsa per determinare le modifiche alla configurazione dall'invocazione precedente. Quando viene invocato, `kubectl apply` fa una differenza a tre tra la configurazione precedente, l'input fornito e la configurazione corrente della risorsa, al fine di determinare come modificare la risorsa. + +Attualmente, le risorse vengono create senza questa annotazione, quindi la prima chiamata di `kubectl apply` ricadrà su una differenza a due vie tra l'input fornito e la configurazione corrente della risorsa. Durante questa prima chiamata, non è in grado di rilevare l'eliminazione delle proprietà impostate al momento della creazione della risorsa. Per questo motivo, non li rimuoverà. + +Tutte le chiamate successive a `kubectl apply`, e altri comandi che modificano la configurazione, come` kubectl replace` e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a` kubectl apply` per rilevare ed eseguire cancellazioni usando un tre via diff. + +{{< note >}} +To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`. +{{< /note >}} + +### kubectl edit + +In alternativa, puoi anche aggiornare le risorse con `kubectl edit`: + +```shell +$ kubectl edit deployment/my-nginx +``` + +Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la versione aggiornata: + +```shell +$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml +$ vi /tmp/nginx.yaml +# do some edit, and then save the file +$ kubectl apply -f /tmp/nginx.yaml +deployment.apps/my-nginx configured +$ rm /tmp/nginx.yaml +``` + +Questo ti permette di fare più cambiamenti significativi più facilmente. Nota che puoi specificare l'editor con le variabili di ambiente `EDITOR` o` KUBE_EDITOR`. + +Per ulteriori informazioni, consultare il documento [kubectl edit] (/docs/reference/generated/kubectl/kubectl-commands/#edit). + +### kubectl patch + +You can use `kubectl patch` to update API objects in place. This command supports JSON patch, +JSON merge patch, and strategic merge patch. See +[Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/) +and +[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). + + +## Disruptive updates + + +375/5000 +In alcuni casi, potrebbe essere necessario aggiornare i campi di risorse che non possono essere aggiornati una volta inizializzati, oppure si può semplicemente voler fare immediatamente una modifica ricorsiva, come per esempio correggere i pod spezzati creati da una distribuzione. Per cambiare tali campi, usa `replace --force`, che elimina e ricrea la risorsa. In questo caso, puoi semplicemente modificare il tuo file di configurazione originale: + +```shell +$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force +deployment.apps/my-nginx deleted +deployment.apps/my-nginx replaced +``` + +## Aggiornamento dell'applicazione senza un'interruzione del servizio + +A un certo punto, alla fine sarà necessario aggiornare l'applicazione distribuita, in genere specificando una nuova immagine o un tag immagine, come nello scenario di distribuzione canarino precedente. `kubectl` supporta diverse operazioni di aggiornamento, ognuna delle quali è applicabile a diversi scenari. + +Ti guideremo attraverso come creare e aggiornare le applicazioni con le distribuzioni. Se l'applicazione distribuita è gestita dai controller di replica, +dovresti leggere [come usare `kubectl rolling-update`] (/docs/tasks/run-application/rolling-update-replication-controller/). + +Diciamo che stavi usando la versione 1.7.9 di nginx: + +```shell +$ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3 +deployment.apps/my-nginx created +``` + +Per aggiornare alla versione 1.9.1, cambia semplicemente `.spec.template.spec.containers [0] .image` da` nginx: 1.7.9` a `nginx: 1.9.1`, con i comandi kubectl che abbiamo imparato sopra. + +```shell +$ kubectl edit deployment/my-nginx +``` + +Questo è tutto! La distribuzione aggiornerà in modo dichiarativo l'applicazione nginx distribuita progressivamente dietro la scena. Garantisce che solo un certo numero di vecchie repliche potrebbe essere inattivo mentre vengono aggiornate e solo un certo numero di nuove repliche può essere creato sopra il numero desiderato di pod. Per ulteriori informazioni su di esso, visitare [Pagina di distribuzione] (/ docs / concepts / workloads / controller / deployment /). + +{{% /capture %}} + +{{% capture whatsnext %}} + +- [[Scopri come usare `kubectl` per l'introspezione e il debug delle applicazioni.] (/Docs/tasks/debug-application-cluster/debug-application-introspection/) +- [Best practice e suggerimenti sulla configurazione] (/docs/concepts/configuration/overview/) + +{{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md new file mode 100644 index 0000000000..c9c49d5707 --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/networking.md @@ -0,0 +1,292 @@ +--- + +title: Cluster Networking +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +Il networking è una parte centrale di Kubernetes, ma può essere difficile +capire esattamente come dovrebbe funzionare. Ci sono 4 reti distinte +problemi da affrontare: + +1. Comunicazioni container-to-container altamente accoppiate: questo è risolto da +    [pod] (/docs/concepts/workloads/pods/pod/) e comunicazioni `localhost`. +2. Comunicazioni Pod-to-Pod: questo è l'obiettivo principale di questo documento. +3. Comunicazioni Pod-to-Service: questo è coperto da [servizi] (/docs/concepts/services-networking/service/). +4. Comunicazioni da esterno a servizio: questo è coperto da [servizi] (/docs/concepts/services-networking/service/). +{{% /capture %}} + + +{{% capture body %}} + +Kubernetes è tutto basato sulla condivisione di macchine tra le applicazioni. Tipicamente, +la condivisione di macchine richiede che due applicazioni non provino a utilizzare il +stesse porte. È molto difficile coordinare le porte tra più sviluppatori +fare su larga scala ed esporre gli utenti a problemi a livello di cluster al di fuori del loro controllo. + +L'allocazione dinamica delle porte apporta molte complicazioni al sistema: tutte +l'applicazione deve prendere le porte come flag, i server API devono sapere come +inserire numeri di porta dinamici in blocchi di configurazione, i servizi devono sapere +come trovarsi, ecc. Piuttosto che occuparsene, Kubernetes prende un +approccio diverso. + +## Il modello di rete di Kubernetes + +Ogni `Pod` ottiene il proprio indirizzo IP. Ciò significa che non è necessario esplicitamente +crea collegamenti tra `Pod 'e non hai quasi mai bisogno di gestire la mappatura +porte del contenitore per ospitare le porte. Questo crea un pulito, retrocompatibile +modello in cui `Pods` può essere trattato in modo molto simile a VM o host fisici da +prospettive di allocazione delle porte, denominazione, individuazione dei servizi, bilanciamento del carico, +configurazione dell'applicazione e migrazione. + +Kubernetes impone i seguenti requisiti fondamentali su qualsiasi rete +implementazione (salvo eventuali politiche di segmentazione di rete intenzionale): + +   * i pod su un nodo possono comunicare con tutti i pod su tutti i nodi senza NAT +   * agenti su un nodo (ad esempio i daemon di sistema, kubelet) possono comunicare con tutti +     pod su quel nodo + +Nota: per quelle piattaforme che supportano `Pods` in esecuzione nella rete host (ad es. +Linux): + +   * i pod nella rete host di un nodo possono comunicare con tutti i pod su tutti +     nodi senza NAT + +Questo modello non è solo complessivamente meno complesso, ma è principalmente compatibile +con il desiderio di Kubernetes di abilitare il porting a bassa frizione di app da VM +ai contenitori. Se il tuo lavoro è già stato eseguito in una macchina virtuale, la tua macchina virtuale ha avuto un indirizzo IP e potrebbe +parla con altre macchine virtuali nel tuo progetto. Questo è lo stesso modello base. + +Gli indirizzi IP di Kubernetes esistono nello scope `Pod` - contenitori all'interno di un 'Pod` +condividere i loro spazi dei nomi di rete, compreso il loro indirizzo IP. Ciò significa che +i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su` localhost`. Questo +significa anche che i contenitori all'interno di un 'Pod` devono coordinare l'utilizzo della porta, ma questo +non è diverso dai processi in una VM. Questo è chiamato il modello "IP-per-pod". + +Il modo in cui viene implementato è un dettaglio del particolare runtime del contenitore in uso. + +È possibile richiedere le porte sul `Node` stesso che inoltrerà al tuo 'Pod` +(chiamate porte host), ma questa è un'operazione molto di nicchia. Come è quella spedizione +implementato è anche un dettaglio del runtime del contenitore. Il `Pod` stesso è +cieco all'esistenza o alla non esistenza dei porti di accoglienza. + +## Come implementare il modello di rete di Kubernetes + +Ci sono diversi modi in cui questo modello di rete può essere implementato. Questo +il documento non è uno studio esaustivo dei vari metodi, ma si spera che serva +come introduzione a varie tecnologie e serve da punto di partenza. + +Le seguenti opzioni di networking sono ordinate alfabeticamente - l'ordine no +implica uno stato preferenziale. + +### ACI + +[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf). + +### AOS da Apstra + +[AOS] (http://www.apstra.com/products/aos/) è un sistema di rete basato sull'intento che crea e gestisce ambienti di data center complessi da una semplice piattaforma integrata. AOS sfrutta un design distribuito altamente scalabile per eliminare le interruzioni di rete riducendo al minimo i costi. + +Il progetto di riferimento AOS attualmente supporta gli host connessi Layer-3 che eliminano i problemi di commutazione Layer-2 legacy. Questi host Layer-3 possono essere server Linux (Debian, Ubuntu, CentOS) che creano relazioni vicine BGP direttamente con gli switch top of rack (TOR). AOS automatizza le adiacenze di routing e quindi fornisce un controllo a grana fine sulle iniezioni di integrità del percorso (RHI) comuni in una distribuzione di Kubernetes. + +AOS dispone di un ricco set di endpoint REST API che consentono a Kubernetes di modificare rapidamente i criteri di rete in base ai requisiti dell'applicazione. Ulteriori miglioramenti integreranno il modello AOS Graph utilizzato per la progettazione della rete con il provisioning del carico di lavoro, consentendo un sistema di gestione end-to-end per cloud privati ​​e pubblici. + +AOS supporta l'utilizzo di apparecchiature di produttori comuni di produttori quali Cisco, Arista, Dell, Mellanox, HPE e un gran numero di sistemi white-box e sistemi operativi di rete aperti come Microsoft SONiC, Dell OPX e Cumulus Linux. + +I dettagli su come funziona il sistema AOS sono disponibili qui: http://www.apstra.com/products/how-it-works/ + +### Big Cloud Fabric da Big Switch Networks + +[Big Cloud Fabric] (https://www.bigswitch.com/container-network-automation) è un'architettura di rete nativa cloud, progettata per eseguire Kubernetes in ambienti cloud privati ​​/ on-premise. Utilizzando un SDN fisico e virtuale unificato, Big Cloud Fabric affronta problemi intrinseci di rete di container come bilanciamento del carico, visibilità, risoluzione dei problemi, politiche di sicurezza e monitoraggio del traffico container. + +Con l'aiuto dell'architettura multi-tenant del pod virtuale di Big Cloud Fabric, i sistemi di orchestrazione di container come Kubernetes, RedHat OpenShift, Mesosphere DC / OS e Docker Swarm saranno integrati nativamente con i sistemi di orchestrazione VM come VMware, OpenStack e Nutanix. I clienti saranno in grado di interconnettere in modo sicuro qualsiasi numero di questi cluster e abilitare la comunicazione tra i titolari, se necessario. + +BCF è stato riconosciuto da Gartner come un visionario nell'ultimo [Magic Quadrant] (http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). Viene anche fatto riferimento a una delle distribuzioni on-premises BCF Kubernetes (che include Kubernetes, DC / OS e VMware in esecuzione su più DC in diverse regioni geografiche) [https://portworx.com/architects-corner-kubernetes-satya -komala-nio /). +### Cilium + +[Cilium](https://github.com/cilium/cilium) è un software open source per +fornire e proteggere in modo trasparente la connettività di rete tra le applicazioni +contenitori. Cilium è consapevole di L7 / HTTP e può applicare i criteri di rete su L3-L7 +utilizzando un modello di sicurezza basato sull'identità che è disaccoppiato dalla rete +indirizzamento. + +### CNI-Genie from Huawei + +[CNI-Genie] (https://github.com/Huawei-PaaS/CNI-Genie) è un plugin CNI che consente a Kubernetes di [avere simultaneamente accesso a diverse implementazioni] (https://github.com/Huawei-PaaS /CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) del [modello di rete Kubernetes] (https: / /git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime. Ciò include qualsiasi implementazione che funziona come un [plugin CNI] (https://github.com/containernetworking/cni#3rd-party-plugins), come [Flannel] (https://github.com/coreos/flannel# flanella), [Calico] (http://docs.projectcalico.org/), [Romana] (http://romana.io), [Weave-net] (https://www.weave.works/products/ tessere-net /). + +CNI-Genie supporta anche [assegnando più indirizzi IP a un pod] (https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension -cni-genie-multiple-ip-indirizzi-per-pod), ciascuno da un diverso plugin CNI. + +### cni-ipvlan-vpc-k8s +[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contiene un set +di plugin CNI e IPAM per fornire una semplice, host-local, bassa latenza, alta +throughput e stack di rete conforme per Kubernetes in Amazon Virtual +Ambienti Private Cloud (VPC) facendo uso di Amazon Elastic Network +Interfacce (ENI) e associazione degli IP gestiti da AWS in pod usando il kernel di Linux +Driver IPvlan in modalità L2. + +I plugin sono progettati per essere semplici da configurare e distribuire all'interno di +VPC. Kubelets si avvia e quindi autoconfigura e ridimensiona il loro utilizzo IP secondo necessità +senza richiedere le complessità spesso raccomandate della gestione della sovrapposizione +reti, BGP, disabilitazione dei controlli sorgente / destinazione o regolazione del percorso VPC +tabelle per fornire sottoreti per istanza a ciascun host (che è limitato a 50-100 +voci per VPC). In breve, cni-ipvlan-vpc-k8s riduce significativamente il +complessità della rete richiesta per implementare Kubernetes su larga scala all'interno di AWS. + + +### Contiv + + +226/5000 +[Contiv] (https://github.com/contiv/netplugin) fornisce un networking configurabile (nativo l3 usando BGP, overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv] (http://contiv.io) è tutto aperto. + +### Contrail / Tungsten Fabric + +[Contrail] (http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basato su [Tungsten Fabric] (https://tungsten.io), è un virtualizzazione della rete e piattaforma di gestione delle policy realmente aperte e multi-cloud. Contrail e Tungsten Fabric sono integrati con vari sistemi di orchestrazione come Kubernetes, OpenShift, OpenStack e Mesos e forniscono diverse modalità di isolamento per macchine virtuali, contenitori / pod e carichi di lavoro bare metal. + +### DANM + +[DANM] (https://github.com/nokia/danm) è una soluzione di rete per carichi di lavoro di telco in esecuzione in un cluster Kubernetes. È costituito dai seguenti componenti: + + * Un plugin CNI in grado di fornire interfacce IPVLAN con funzionalità avanzate +    * Un modulo IPAM integrato con la capacità di gestire reti L3 multiple, a livello di cluster e discontinue e fornire uno schema di allocazione IP dinamico, statico o nullo su richiesta +    * Metaplugin CNI in grado di collegare più interfacce di rete a un contenitore, tramite il proprio CNI o delegando il lavoro a qualsiasi soluzione CNI come SRI-OV o Flannel in parallelo +    * Un controller Kubernetes in grado di gestire centralmente sia le interfacce VxLAN che VLAN di tutti gli host Kubernetes +    * Un altro controller di Kubernetes che estende il concetto di rilevamento dei servizi basato sui servizi di Kubernetes per funzionare su tutte le interfacce di rete di un pod + +Con questo set di strumenti DANM è in grado di fornire più interfacce di rete separate, la possibilità di utilizzare diversi back-end di rete e funzionalità IPAM avanzate per i pod. +### Flannel + +[Flannel](https://github.com/coreos/flannel#flannel) è un overlay molto semplice +rete che soddisfa i requisiti di Kubernetes. Molti +le persone hanno riportato il successo con Flannel e Kubernetes. + +### Google Compute Engine (GCE) + +Per gli script di configurazione del cluster di Google Compute Engine, [avanzato +routing] (https://cloud.google.com/vpc/docs/routes) è usato per +assegna a ciascuna VM una sottorete (l'impostazione predefinita è `/ 24` - 254 IP). Qualsiasi traffico vincolato per questo +la sottorete verrà instradata direttamente alla VM dal fabric di rete GCE. Questo è dentro +aggiunta all'indirizzo IP "principale" assegnato alla VM, a cui è stato assegnato NAT +accesso a Internet in uscita. Un bridge linux (chiamato `cbr0`) è configurato per esistere +su quella sottorete, e viene passato al flag `--bridge` della finestra mobile. + +Docker è avviato con: + +```shell +DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" +``` + +Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` +flag) in base al `Nodo` .spec.podCIDR`. + +Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere +l'un l'altro e `Nodi` sul ponte` cbr0`. Questi IP sono tutti instradabili +all'interno della rete del progetto GCE. + +GCE non sa nulla di questi IP, quindi non lo farà +loro per il traffico internet in uscita. Per ottenere ciò viene utilizzata una regola iptables +masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` +stesso) traffico che è vincolato per IP al di fuori della rete del progetto GCE +(10.0.0.0/8). + +```shell +iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE +``` + +Infine l'inoltro IP è abilitato nel kernel (quindi il kernel elaborerà +pacchetti per contenitori a ponte): + +```shell +sysctl net.ipv4.ip_forward=1 +``` + +Il risultato di tutto questo è che tutti i `Pods` possono raggiungere l'altro e possono uscire +traffico verso internet. + +### Jaguar + +[Jaguar] (https://gitlab.com/sdnlab/jaguar) è una soluzione open source per la rete di Kubernetes basata su OpenDaylight. Jaguar fornisce una rete overlay utilizzando vxlan e Jaguar. CNIPlugin fornisce un indirizzo IP per pod. + +### Knitter + +363/5000 +[Knitter] (https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. Fornisce la capacità di gestione dei titolari e gestione della rete. Knitter include una serie di soluzioni di rete container NFV end-to-end oltre a più piani di rete, come mantenere l'indirizzo IP per le applicazioni, la migrazione degli indirizzi IP, ecc. + +### Kube-router + +430/5000 +[Kube-router] (https://github.com/cloudnativelabs/kube-router) è una soluzione di rete sviluppata appositamente per Kubernetes che mira a fornire alte prestazioni e semplicità operativa. Kube-router fornisce un proxy di servizio basato su Linux [LVS / IPVS] (http://www.linuxvirtualserver.org/software/ipvs.html), una soluzione di rete pod-to-pod basata sul kernel di inoltro del kernel Linux senza sovrapposizioni, e il sistema di sicurezza della politica di rete basato su iptables / ipset. + +### L2 networks and linux bridging + +Se hai una rete L2 "stupida", come un semplice switch in un "bare metal" +ambiente, dovresti essere in grado di fare qualcosa di simile alla precedente configurazione GCE. +Si noti che queste istruzioni sono state provate solo molto casualmente - a quanto pare +lavoro, ma non è stato testato a fondo. Se usi questa tecnica e +perfezionare il processo, fatecelo sapere. + +Segui la sezione "Con dispositivi Linux Bridge" di [questo molto bello +tutorial] (http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) da +Lars Kellogg-Stedman. + +### Multus (a Multi Network plugin) + +Multus] (https://github.com/Intel-Corp/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi Networking in Kubernetes utilizzando oggetti di rete basati su CRD in Kubernetes. + +Multus supporta tutti i [plug-in di riferimento] (https://github.com/containernetworking/plugins) (ad esempio [Flannel] (https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP] (https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan] (https://github.com/containernetworking/plugins/tree/master/plugins/main / macvlan)) che implementano le specifiche CNI e i plugin di terze parti (ad esempio [Calico] (https://github.com/projectcalico/cni-plugin), [Weave] (https://github.com/weaveworks/weave) ), [Cilium] (https://github.com/cilium/cilium), [Contiv] (https://github.com/contiv/netplugin)). Oltre a ciò, Multus supporta [SRIOV] (https://github.com/hustcat/sriov-cni), [DPDK] (https://github.com/Intel-Corp/sriov-cni), [OVS- DPDK e VPP] (https://github.com/intel/vhost-user-net-plugin) carichi di lavoro in Kubernetes con applicazioni cloud native e basate su NFV in Kubernetes. +### NSX-T + +VMware NSX-T] (https://docs.vmware.com/en/VMware-NSX-T/index.html) è una piattaforma di virtualizzazione e sicurezza della rete. NSX-T può fornire la virtualizzazione di rete per un ambiente multi-cloud e multi-hypervisor ed è focalizzato su architetture applicative emergenti e architetture con endpoint eterogenei e stack tecnologici. Oltre agli hypervisor vSphere, questi ambienti includono altri hypervisor come KVM, container e bare metal. + +[Plug-in contenitore NSX-T (NCP)] (https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) fornisce integrazione tra NSX-T e orchestratori di contenitori come Kubernetes, così come l'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. + +### Nuage Networks VCS (Servizi cloud virtualizzati) + +[Nuage] (http://www.nuagenetworks.net) fornisce una piattaforma Software-Defined Networking (SDN) altamente scalabile basata su policy. Nuage utilizza open source Open vSwitch per il piano dati insieme a un controller SDN ricco di funzionalità basato su standard aperti. + +La piattaforma Nuage utilizza gli overlay per fornire una rete basata su policy senza soluzione di continuità tra i Pod di Kubernetes e gli ambienti non Kubernetes (VM e server bare metal). Il modello di astrazione delle policy di Nuage è stato progettato pensando alle applicazioni e semplifica la dichiarazione di policy a grana fine per le applicazioni. Il motore di analisi in tempo reale della piattaforma consente la visibilità e il monitoraggio della sicurezza per le applicazioni Kubernetes. + +### OpenVSwitch + +[OpenVSwitch] (https://www.openvswitch.org/) è un po 'più maturo ma anche +modo complicato per costruire una rete di sovrapposizione. Questo è approvato da molti dei +"Grandi negozi" per il networking. + +### OVN (Apri rete virtuale) + +OVN è una soluzione di virtualizzazione della rete opensource sviluppata da +Apri la community di vSwitch. Permette di creare switch logici, router logici, +ACL di stato, bilanciamento del carico ecc. per costruire reti virtuali diverse +topologie. Il progetto ha un plugin e una documentazione specifici per Kubernetes +a [ovn-kubernetes] (https://github.com/openvswitch/ovn-kubernetes). + +### Progetto Calico + +[Project Calico] (http://docs.projectcalico.org/) è un provider di rete contenitore open source e motore di criteri di rete. + +Calico offre una soluzione di rete e di rete altamente scalabile per il collegamento di pod Kubernetes basati sugli stessi principi di rete IP di Internet, sia per Linux (open source) che per Windows (proprietario - disponibile da [Tigera] (https: //www.tigera .io / essenziali /)). Calico può essere distribuito senza incapsulamento o sovrapposizioni per fornire reti di data center ad alte prestazioni e su vasta scala. Calico fornisce inoltre una politica di sicurezza di rete basata su intere grane per i pod Kubernetes tramite il firewall distribuito. + +Calico può anche essere eseguito in modalità di applicazione della policy insieme ad altre soluzioni di rete come Flannel, alias [canal] (https://github.com/tigera/canal) o native GCE, AWS o networking Azure. + +### Romana + +[Romana] (http://romana.io) è una soluzione di automazione della sicurezza e della rete open source che consente di distribuire Kubernetes senza una rete di overlay. Romana supporta Kubernetes [Politica di rete] (/ docs / concepts / services-networking / network-policies /) per fornire isolamento tra gli spazi dei nomi di rete. + +### Weave Net di Weaveworks + +[Weave Net] (https://www.weave.works/products/weave-net/) è un +rete resiliente e semplice da usare per Kubernetes e le sue applicazioni in hosting. +Weave Net funziona come un plug-in [CNI] (https://www.weave.works/docs/net/latest/cni-plugin/) +o stand-alone. In entrambe le versioni, non richiede alcuna configurazione o codice aggiuntivo +per eseguire, e in entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per Kubernetes. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro +i piani sono descritti in maggior dettaglio nella [progettazione della rete +documento] (https://git.k8s.io/community/contributors/design-proposals/network/networking.md). + +{{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/proxies.md b/content/it/docs/concepts/cluster-administration/proxies.md new file mode 100644 index 0000000000..5789de393a --- /dev/null +++ b/content/it/docs/concepts/cluster-administration/proxies.md @@ -0,0 +1,68 @@ +--- +title: Proxy in Kubernetes +content_template: templates/concept +weight: 90 +--- + +{{% capture overview %}} +Questa pagina spiega i proxy utilizzati con Kubernetes. + +{{% /capture %}} + +{{% capture body %}} + +## Proxies + +Esistono diversi proxy che puoi incontrare quando usi Kubernetes: + +1. Il [proxy kubectl] (/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api): + +    - Funziona sul desktop di un utente o in un pod +    - proxy da un indirizzo localhost all'apiserver di Kubernetes +    - client per proxy utilizza HTTP +    - proxy per apiserver utilizza HTTPS +    - individua l'apiserver +    - Aggiunge le intestazioni di autenticazione + +1. Il [proxy apiserver] (/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): + +    - è un bastione costruito nell'apiserver +    - collega un utente al di fuori del cluster agli IP del cluster che altrimenti potrebbero non essere raggiungibili +    - funziona nei processi di apiserver +    - client per proxy utilizza HTTPS (o http se apiserver configurato in tal modo) +    - proxy to target può utilizzare HTTP o HTTPS come scelto dal proxy utilizzando le informazioni disponibili +    - può essere utilizzato per raggiungere un nodo, un pod o un servizio +    - esegue il bilanciamento del carico quando viene utilizzato per raggiungere un servizio + +1. Il [kube proxy] (/docs/concepts/services-networking/service/#ips-and-vips): + +    - Funziona su ciascun nodo +    - proxy UDP, TCP e SCTP +    - non capisce l'HTTP +    - fornisce il bilanciamento del carico +    - è appena usato per raggiungere i servizi + +1. Un proxy / bilanciamento del carico di fronte agli apiserver: + +    - esistenza e implementazione variano da cluster a cluster (ad esempio nginx) +    - si trova tra tutti i client e uno o più apiserver +    - funge da bilanciamento del carico se ci sono diversi apiserver. + +1. Cloud Load Balancer su servizi esterni: + +    - sono forniti da alcuni fornitori di servizi cloud (ad es. AWS ELB, Google Cloud Load Balancer) +    - vengono creati automaticamente quando il servizio Kubernetes ha tipo "LoadBalancer" +    - Solitamente supporta solo UDP / TCP +    - Il supporto SCTP dipende dall'implementazione del servizio di bilanciamento del carico del provider cloud +    - l'implementazione varia a seconda del provider cloud. + +Gli utenti di Kubernetes in genere non devono preoccuparsi di nulla di diverso dai primi due tipi. L'amministratore del cluster +in genere assicurerà che questi ultimi tipi siano impostati correttamente. + +## Richiedere reindirizzamenti + +I proxy hanno sostituito le capacità di reindirizzamento. I reindirizzamenti sono stati deprecati. + +{{% /capture %}} + + diff --git a/content/it/docs/concepts/example-concept-template.md b/content/it/docs/concepts/example-concept-template.md new file mode 100644 index 0000000000..27ec896fdc --- /dev/null +++ b/content/it/docs/concepts/example-concept-template.md @@ -0,0 +1,39 @@ +--- +title: Esempio di modello di concetto +content_template: templates/concept +toc_hide: true +--- + +{{% capture overview %}} + +{{< note >}} +Assicurati anche di [creare una voce nel sommario](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) per il tuo nuovo documento. +{{< /note >}} + +Questa pagina spiega ... + +{{% /capture %}} + +{{% capture body %}} + +## Understanding ... + +Kubernetes fornisce ... + + +## Using ... + +Usare + +{{% /capture %}} + +{{% capture whatsnext %}} + +**[Optional Section]** + +* Ulteriori informazioni su [Scrivere un nuovo argomento](/docs/home/contribuisci/scrivi-nuovo-argomento/). +* Vedi [Uso dei modelli di pagina - Modello di concetto](/docs/home/contribuis/page-templates/#concept_template) su come utilizzare questo modello. + +{{% /capture %}} + + diff --git a/content/it/examples/admin/logging/fluentd-sidecar-config.yaml b/content/it/examples/admin/logging/fluentd-sidecar-config.yaml new file mode 100644 index 0000000000..eea1849b03 --- /dev/null +++ b/content/it/examples/admin/logging/fluentd-sidecar-config.yaml @@ -0,0 +1,25 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: fluentd-config +data: + fluentd.conf: | + + type tail + format none + path /var/log/1.log + pos_file /var/log/1.log.pos + tag count.format1 + + + + type tail + format none + path /var/log/2.log + pos_file /var/log/2.log.pos + tag count.format2 + + + + type google_cloud + diff --git a/content/it/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/it/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml new file mode 100644 index 0000000000..b37b616e6f --- /dev/null +++ b/content/it/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-agent + image: k8s.gcr.io/fluentd-gcp:1.30 + env: + - name: FLUENTD_ARGS + value: -c /etc/fluentd-config/fluentd.conf + volumeMounts: + - name: varlog + mountPath: /var/log + - name: config-volume + mountPath: /etc/fluentd-config + volumes: + - name: varlog + emptyDir: {} + - name: config-volume + configMap: + name: fluentd-config diff --git a/content/it/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/it/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml new file mode 100644 index 0000000000..87bd198cfd --- /dev/null +++ b/content/it/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-1 + image: busybox + args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-2 + image: busybox + args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/it/examples/admin/logging/two-files-counter-pod.yaml b/content/it/examples/admin/logging/two-files-counter-pod.yaml new file mode 100644 index 0000000000..6ebeb717a1 --- /dev/null +++ b/content/it/examples/admin/logging/two-files-counter-pod.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/it/examples/application/nginx-app.yaml b/content/it/examples/application/nginx-app.yaml new file mode 100644 index 0000000000..c3f926b74e --- /dev/null +++ b/content/it/examples/application/nginx-app.yaml @@ -0,0 +1,34 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-nginx-svc + labels: + app: nginx +spec: + type: LoadBalancer + ports: + - port: 80 + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/it/examples/debug/counter-pod.yaml b/content/it/examples/debug/counter-pod.yaml new file mode 100644 index 0000000000..f997886386 --- /dev/null +++ b/content/it/examples/debug/counter-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox + args: [/bin/sh, -c, + 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] diff --git a/content/it/includes/federation-deprecation-warning-note.md b/content/it/includes/federation-deprecation-warning-note.md new file mode 100644 index 0000000000..65c54ca01c --- /dev/null +++ b/content/it/includes/federation-deprecation-warning-note.md @@ -0,0 +1,3 @@ +L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` mai raggiunto lo stato GA e non è più in fase di sviluppo attivo. La documentazione è solo per scopi storici. + +Per ulteriori informazioni, consultare la sostituzione prevista, [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).