Improved markdown for Italian translation (#13785)
This commit is contained in:
Roy Lenferink
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
5a7d1f6c39
commit
cf86480431
@@ -19,7 +19,6 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
|
|||||||
|
|
||||||
## Networking and Network Policy
|
## Networking and Network Policy
|
||||||
|
|
||||||
|
|
||||||
* [ACI](https://www.github.com/noironetworks/aci-containers) fornisce funzionalità integrate di networking e sicurezza di rete con Cisco ACI.
|
* [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.
|
* [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.
|
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete.
|
||||||
|
|||||||
@@ -11,10 +11,11 @@ fornitore di servizi cloud.
|
|||||||
|
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
|
|
||||||
### kubeadm
|
### kubeadm
|
||||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) è un'opzione popolare per la creazione di cluster di kuberneti.
|
[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
|
kubeadm ha opzioni di configurazione per specificare le informazioni di configurazione per i provider cloud. Ad esempio
|
||||||
il provider cloud in-tree può essere configurato utilizzando kubeadm come mostrato di seguito:
|
un tipico il provider cloud in-tree può essere configurato utilizzando kubeadm come mostrato di seguito:
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: kubeadm.k8s.io/v1beta1
|
apiVersion: kubeadm.k8s.io/v1beta1
|
||||||
@@ -45,18 +46,18 @@ controllerManager:
|
|||||||
mountPath: "/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
|
I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
|
||||||
per [kube-apiserver] (/docs/admin/kube-apiserver/), [kube-controller-manager] (/docs/admin/kube-controller-manager/) e il
|
comando per [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
|
||||||
[Kubelet] (/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider è documentato di seguito.
|
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.
|
Per tutti i fornitori di servizi cloud esterni, seguire le istruzioni sui singoli repository.
|
||||||
|
|
||||||
## AWS
|
## AWS
|
||||||
Questa sezione descrive tutte le possibili configurazioni che possono
|
Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato durante l'esecuzione di
|
||||||
essere utilizzato durante l'esecuzione di Kubernetes su Amazon Web Services.
|
Kubernetes su Amazon Web Services.
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
|
||||||
Il provider cloud AWS utilizza il nome DNS privato dell'istanza AWS come nome dell'oggetto Nodo Kubernetes.
|
Il provider cloud AWS utilizza il nome DNS privato dell'istanza AWS come nome dell'oggetto Nodo Kubernetes.
|
||||||
|
|
||||||
### Load Balancers
|
### Load Balancers
|
||||||
@@ -106,38 +107,36 @@ Le informazioni per le annotazioni per AWS sono tratte dai commenti su [aws.go]
|
|||||||
## Azure
|
## Azure
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
Il provider cloud di Azure utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
|
||||||
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.
|
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
|
||||||
Si noti che il nome del nodo Kubernetes deve corrispondere al nome VM di Azure.
|
corrispondere al nome VM di Azure.
|
||||||
|
|
||||||
## CloudStack
|
## CloudStack
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
Il provider cloud CloudStack utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
|
||||||
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.
|
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
|
||||||
Si noti che il nome del nodo Kubernetes deve corrispondere al nome VM di CloudStack.
|
corrispondere al nome VM di CloudStack.
|
||||||
|
|
||||||
## GCE
|
## GCE
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
|
||||||
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.
|
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il primo segmento del nome del nodo
|
||||||
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`) .
|
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
|
## OpenStack
|
||||||
Questa sezione descrive tutte le possibili configurazioni che possono
|
Questa sezione descrive tutte le possibili configurazioni che possono
|
||||||
essere utilizzato quando si utilizza OpenStack con Kubernetes.
|
essere utilizzato quando si utilizza OpenStack con Kubernetes.
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
|
||||||
Il provider cloud OpenStack utilizza il nome dell'istanza (come determinato dai metadati OpenStack) come nome dell'oggetto Nodo Kubernetes.
|
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.
|
Si noti che il nome dell'istanza deve essere un nome nodo Kubernetes valido affinché kubelet registri correttamente il suo oggetto Node.
|
||||||
|
|
||||||
### Services
|
### Services
|
||||||
|
Il provider cloud OpenStack implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da la nuvola
|
||||||
Il provider cloud OpenStack
|
sottostante, ove disponibile:
|
||||||
implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da
|
|
||||||
la nuvola sottostante, ove disponibile:
|
|
||||||
|
|
||||||
| Servizio | Versioni API | Richiesto |
|
| Servizio | Versioni API | Richiesto |
|
||||||
| -------------------------- | ---------------- | ----- ----- |
|
| -------------------------- | ---------------- | ----- ----- |
|
||||||
@@ -253,7 +252,8 @@ file:
|
|||||||
L'impostazione predefinita è `false`. Quando è specificato `true` quindi` monitor-delay`,
|
L'impostazione predefinita è `false`. Quando è specificato `true` quindi` monitor-delay`,
|
||||||
`monitor-timeout`, e` monitor-max-retries` deve essere impostato.
|
`monitor-timeout`, e` monitor-max-retries` deve essere impostato.
|
||||||
* `monitor-delay` (Opzionale): il tempo tra l'invio delle sonde a
|
* `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"
|
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
|
* `monitor-timeout` (Opzionale): tempo massimo di attesa per un monitor
|
||||||
per una risposta ping prima che scada. Il valore deve essere inferiore al ritardo
|
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"
|
valore. Assicurati di specificare un'unità di tempo valida. Le unità di tempo valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h"
|
||||||
@@ -346,42 +346,54 @@ File `cloud.conf`:
|
|||||||
## OVirt
|
## OVirt
|
||||||
|
|
||||||
### Node Name
|
### 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 `<vm> <guest_info> <fqdn> ... </fqdn> </guest_info> </vm>`)
|
||||||
|
|
||||||
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 `<vm> <guest_info> <fqdn> ... </fqdn> </guest_info> </vm>`)
|
|
||||||
## Photon
|
## Photon
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
Il provider cloud Photon utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
|
||||||
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.
|
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
|
||||||
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).
|
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
|
## VSphere
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
Il provider cloud VSphere utilizza il nome host rilevato del nodo (come determinato dal kubelet) come nome dell'oggetto
|
||||||
Il provider cloud VSphere utilizza il nome host rilevato del nodo (come determinato dal kubelet) come nome dell'oggetto Nodo Kubernetes.
|
Nodo Kubernetes.
|
||||||
|
|
||||||
Il parametro `--hostname-override` viene ignorato dal fornitore di cloud VSphere.
|
Il parametro `--hostname-override` viene ignorato dal fornitore di cloud VSphere.
|
||||||
|
|
||||||
## IBM Cloud Kubernetes Service
|
## IBM Cloud Kubernetes Service
|
||||||
|
|
||||||
### Compute nodes
|
### 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).
|
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.
|
Il nome dell'oggetto Nodo Kubernetes è l'indirizzo IP privato dell'istanza del nodo di lavoro IBM Cloud Kubernetes Service.
|
||||||
|
|
||||||
### Networking
|
### 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).
|
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).
|
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
|
### 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).
|
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
|
## Baidu Cloud Container Engine
|
||||||
|
|
||||||
### Node Name
|
### Node Name
|
||||||
|
Il provider di cloud Baidu utilizza l'indirizzo IP privato del nodo (come determinato dal kubelet o sovrascritto
|
||||||
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.
|
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
|
||||||
Si noti che il nome del nodo Kubernetes deve corrispondere all'IP privato VM di Baidu.
|
corrispondere all'IP privato VM di Baidu.
|
||||||
|
|||||||
@@ -12,7 +12,8 @@ Presuppone una certa dimestichezza con i core Kubernetes [concetti] (/docs/conce
|
|||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
## Planning a cluster
|
## 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*.
|
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:
|
Prima di scegliere una guida, ecco alcune considerazioni:
|
||||||
|
|
||||||
|
|||||||
@@ -7,19 +7,20 @@ weight: 100
|
|||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
Le metriche del controller controller forniscono informazioni importanti sulle prestazioni e la salute di
|
Le metriche del controller controller forniscono informazioni importanti sulle prestazioni e la salute di
|
||||||
il responsabile del controller.
|
il responsabile del controller.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
|
|
||||||
## Cosa sono le metriche del controller
|
## Cosa sono le metriche del controller
|
||||||
|
|
||||||
Le metriche del controller forniscono informazioni importanti sulle prestazioni del controller.
|
Le metriche del controller forniscono informazioni importanti sulle prestazioni del controller. Queste metriche
|
||||||
Queste metriche includono le comuni metriche di runtime del linguaggio Go, come il conteggio go_routine e le metriche specifiche del controller come
|
includono le comuni metriche di runtime del linguaggio Go, come il conteggio go_routine e le metriche specifiche del
|
||||||
latenze delle richieste etcd o latenze API Cloudprovider (AWS, GCE, OpenStack) che possono essere utilizzate
|
controller come latenze delle richieste etcd o latenze API Cloudprovider (AWS, GCE, OpenStack) che possono essere
|
||||||
per valutare la salute di un cluster.
|
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.
|
A partire da Kubernetes 1.7, le metriche dettagliate di Cloudprovider sono disponibili per le operazioni di archiviazione
|
||||||
Queste metriche possono essere utilizzate per monitorare lo stato delle operazioni di volume persistenti.
|
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:
|
Ad esempio, per GCE queste metriche sono chiamate:
|
||||||
|
|
||||||
@@ -32,7 +33,6 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
|||||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
## Configurazione
|
## Configurazione
|
||||||
|
|
||||||
In un cluster, le metriche di controller-manager sono disponibili da `http://localhost:10252/metrics`
|
In un cluster, le metriche di controller-manager sono disponibili da `http://localhost:10252/metrics`
|
||||||
@@ -44,4 +44,3 @@ In un ambiente di produzione è possibile configurare prometheus o altri strumen
|
|||||||
per raccogliere periodicamente queste metriche e renderle disponibili in una sorta di database di serie temporali.
|
per raccogliere periodicamente queste metriche e renderle disponibili in una sorta di database di serie temporali.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|||||||
@@ -172,8 +172,7 @@ cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni] (/docs/s
|
|||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
* Ulteriori informazioni sulla [Federazione
|
* Ulteriori informazioni sulla [Federazione proposta](https://github.com/kubernetes/community/blob/{{<param "githubbranch">}}/contributors/design-proposal/multicluster/federation.md).
|
||||||
proposta] (https://github.com/kubernetes/community/blob/{{<param "githubbranch">}}/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 [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 [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 [Kubecon2017 aggiornamento Europa sulla federazione](https://www.youtube.com/watch?v=kwOvOLnFYck)
|
||||||
@@ -181,6 +180,3 @@ cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni] (/docs/s
|
|||||||
* Vedi questo [Kubecon2018 Europe Federation-v2 presentazione prototipo](https://youtu.be/q27rbaX5Jis?t=7m20s)
|
* 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)
|
* Vedi questo [Federation-v2 Userguide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md)
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -6,10 +6,12 @@ weight: 70
|
|||||||
---
|
---
|
||||||
|
|
||||||
{{% capture overview %}}
|
{{% 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.
|
||||||
|
|
||||||
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.
|
||||||
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 %}}
|
||||||
|
|
||||||
|
|
||||||
@@ -32,10 +34,19 @@ soglia è stata soddisfatta.
|
|||||||
|
|
||||||
## Container Collection
|
## 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 politica per i contenitori di garbage collection considera tre variabili definite dall'utente. `MinAge` è l'età minima
|
||||||
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.
|
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".
|
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.
|
I contenitori che non sono gestiti da Kubelet non sono soggetti alla garbage collection del contenitore.
|
||||||
|
|
||||||
@@ -61,8 +72,7 @@ I contenitori possono potenzialmente essere raccolti prima che la loro utilità
|
|||||||
può contenere log e altri dati che possono essere utili per la risoluzione dei problemi. Un valore sufficientemente grande per
|
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
|
`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
|
mantenuto per contenitore previsto. Un valore più grande per "massimo-dead-containers" è anche raccomandato per a
|
||||||
motivo simile.
|
motivo simile. Vedi [questo problema](https://github.com/kubernetes/kubernetes/issues/13287) per maggiori dettagli.
|
||||||
Vedi [questo problema] (https://github.com/kubernetes/kubernetes/issues/13287) per maggiori dettagli.
|
|
||||||
|
|
||||||
|
|
||||||
## Deprecation
|
## Deprecation
|
||||||
|
|||||||
@@ -6,7 +6,10 @@ weight: 40
|
|||||||
|
|
||||||
{{% capture overview %}}
|
{{% 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/).
|
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 %}}
|
||||||
|
|
||||||
@@ -136,7 +139,8 @@ Se sei interessato a saperne di più su `kubectl`, vai avanti e leggi [Panoramic
|
|||||||
|
|
||||||
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.
|
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/ {{<param"). githubbranch ">}} / guestbook /), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette:
|
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/{{< param "githubbranch" >}}/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette:
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
labels:
|
labels:
|
||||||
app: guestbook
|
app: guestbook
|
||||||
@@ -183,7 +187,10 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
|||||||
|
|
||||||
## Distribuzioni canarie
|
## 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.
|
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.
|
Ad esempio, puoi usare un'etichetta `track` per differenziare le diverse versioni.
|
||||||
|
|
||||||
@@ -201,7 +208,8 @@ La versione stabile e primaria avrebbe un'etichetta `track` con valore come` sta
|
|||||||
image: gb-frontend:v3
|
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:
|
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
|
```yaml
|
||||||
name: frontend-canary
|
name: frontend-canary
|
||||||
@@ -215,8 +223,9 @@ e quindi puoi creare una nuova versione del frontend del guestbook che porta l'e
|
|||||||
image: gb-frontend:v4
|
image: gb-frontend:v4
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Il servizio di frontend coprirebbe entrambe le serie di repliche selezionando il sottoinsieme comune delle loro
|
||||||
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:
|
etichette (ad esempio omettendo l'etichetta `track`), in modo che il traffico venga reindirizzato ad entrambe le
|
||||||
|
applicazioni:
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
selector:
|
selector:
|
||||||
@@ -225,15 +234,17 @@ Il servizio di frontend coprirebbe entrambe le serie di repliche selezionando il
|
|||||||
```
|
```
|
||||||
|
|
||||||
452/5000
|
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).
|
È possibile modificare il numero di repliche delle versioni stable e canary per determinare il rapporto tra ciascuna
|
||||||
Una volta che sei sicuro, puoi aggiornare la traccia stabile alla nuova versione dell'applicazione e rimuovere quella canarino.
|
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).
|
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
|
## 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`.
|
A volte i pod esistenti e altre risorse devono essere rinominati prima di creare nuove risorse. Questo può essere fatto
|
||||||
Ad esempio, se desideri etichettare tutti i tuoi pod nginx come livello frontend, esegui semplicemente:
|
con l'etichetta `kubectl`. Ad esempio, se desideri etichettare tutti i tuoi pod nginx come livello frontend, esegui
|
||||||
|
semplicemente:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl label pods -l app=nginx tier=fe
|
$ kubectl label pods -l app=nginx tier=fe
|
||||||
@@ -242,8 +253,8 @@ pod/my-nginx-2035384211-u2c7e labeled
|
|||||||
pod/my-nginx-2035384211-u3t6x 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".
|
Questo prima filtra tutti i pod con l'etichetta "app = nginx", quindi li etichetta con il "tier = fe". Per vedere i pod
|
||||||
Per vedere i pod appena etichettati, esegui:
|
appena etichettati, esegui:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl get pods -l app=nginx -L tier
|
$ kubectl get pods -l app=nginx -L tier
|
||||||
@@ -253,13 +264,17 @@ my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe
|
|||||||
my-nginx-2035384211-u3t6x 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`).
|
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).
|
Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e
|
||||||
|
[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
|
||||||
|
|
||||||
## Aggiornare annotazioni
|
## 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:
|
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
|
```shell
|
||||||
$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
||||||
@@ -272,11 +287,13 @@ metadata:
|
|||||||
...
|
...
|
||||||
```
|
```
|
||||||
|
|
||||||
Per ulteriori informazioni, consultare il documento [annotazioni] (/docs/concepts/overview/working-with-objects/annotations/) e [kubectl annotate] (/docs/reference/generated/kubectl/kubectl-commands/ # annotate).
|
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
|
## 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:
|
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
|
```shell
|
||||||
$ kubectl scale deployment/my-nginx --replicas=1
|
$ kubectl scale deployment/my-nginx --replicas=1
|
||||||
@@ -285,7 +302,6 @@ deployment.extensions/my-nginx scaled
|
|||||||
|
|
||||||
Ora hai solo un pod gestito dalla distribuzione
|
Ora hai solo un pod gestito dalla distribuzione
|
||||||
|
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl get pods -l app=nginx
|
$ kubectl get pods -l app=nginx
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
@@ -301,7 +317,9 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled
|
|||||||
|
|
||||||
Ora le repliche di nginx verranno ridimensionate automaticamente in base alle esigenze.
|
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/).
|
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
|
## Aggiornamenti sul posto delle risorse
|
||||||
|
|
||||||
@@ -309,22 +327,33 @@ A volte è necessario apportare aggiornamenti stretti e senza interruzioni alle
|
|||||||
|
|
||||||
### kubectl apply
|
### 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)),
|
Si consiglia di mantenere un set di file di configurazione nel controllo del codice sorgente (vedere
|
||||||
in modo che possano essere mantenuti e versionati insieme al codice per le risorse che configurano.
|
[configurazione come codice](http://martinfowler.com/bliki/InfrastructureAsCode.html)), in modo che possano essere
|
||||||
Quindi, puoi usare [`kubectl apply`] (/docs/reference/generated/kubectl/kubectl-commands/#apply) per inviare le modifiche alla configurazione nel cluster.
|
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.
|
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
|
```shell
|
||||||
$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||||
deployment.apps/my-nginx configured
|
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.
|
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à.
|
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.
|
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 >}}
|
{{< note >}}
|
||||||
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
||||||
@@ -338,7 +367,8 @@ In alternativa, puoi anche aggiornare le risorse con `kubectl edit`:
|
|||||||
$ kubectl edit deployment/my-nginx
|
$ 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:
|
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
|
||||||
|
versione aggiornata:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
|
$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
|
||||||
@@ -349,7 +379,8 @@ deployment.apps/my-nginx configured
|
|||||||
$ rm /tmp/nginx.yaml
|
$ 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`.
|
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).
|
Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit).
|
||||||
|
|
||||||
@@ -364,9 +395,11 @@ and
|
|||||||
|
|
||||||
## Disruptive updates
|
## Disruptive updates
|
||||||
|
|
||||||
|
|
||||||
375/5000
|
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:
|
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
|
```shell
|
||||||
$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
||||||
@@ -376,10 +409,13 @@ deployment.apps/my-nginx replaced
|
|||||||
|
|
||||||
## Aggiornamento dell'applicazione senza un'interruzione del servizio
|
## 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.
|
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,
|
Ti guideremo attraverso come creare e aggiornare le applicazioni con le distribuzioni. Se l'applicazione distribuita è
|
||||||
dovresti leggere [come usare `kubectl rolling-update`] (/docs/tasks/run-application/rolling-update-replication-controller/).
|
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:
|
Diciamo che stavi usando la versione 1.7.9 di nginx:
|
||||||
|
|
||||||
@@ -388,13 +424,17 @@ $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
|
|||||||
deployment.apps/my-nginx created
|
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.
|
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
|
```shell
|
||||||
$ kubectl edit deployment/my-nginx
|
$ 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 /).
|
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 %}}
|
||||||
|
|
||||||
|
|||||||
@@ -1,14 +1,12 @@
|
|||||||
---
|
---
|
||||||
|
|
||||||
title: Cluster Networking
|
title: Cluster Networking
|
||||||
content_template: templates/concept
|
content_template: templates/concept
|
||||||
weight: 50
|
weight: 50
|
||||||
---
|
---
|
||||||
|
|
||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
Il networking è una parte centrale di Kubernetes, ma può essere difficile
|
Il networking è una parte centrale di Kubernetes, ma può essere difficile capire esattamente come dovrebbe funzionare.
|
||||||
capire esattamente come dovrebbe funzionare. Ci sono 4 reti distinte
|
Ci sono 4 reti distinte problemi da affrontare:
|
||||||
problemi da affrontare:
|
|
||||||
|
|
||||||
1. Comunicazioni container-to-container altamente accoppiate: questo è risolto da
|
1. Comunicazioni container-to-container altamente accoppiate: questo è risolto da
|
||||||
[pod](/docs/concepts/workloads/pods/pod/) e comunicazioni `localhost`.
|
[pod](/docs/concepts/workloads/pods/pod/) e comunicazioni `localhost`.
|
||||||
@@ -73,26 +71,36 @@ cieco all'esistenza o alla non esistenza dei porti di accoglienza.
|
|||||||
|
|
||||||
## Come implementare il modello di rete di Kubernetes
|
## Come implementare il modello di rete di Kubernetes
|
||||||
|
|
||||||
Ci sono diversi modi in cui questo modello di rete può essere implementato. Questo
|
Ci sono diversi modi in cui questo modello di rete può essere implementato. Questo il documento non è uno studio
|
||||||
il documento non è uno studio esaustivo dei vari metodi, ma si spera che serva
|
esaustivo dei vari metodi, ma si spera che serva come introduzione a varie tecnologie e serve da punto di partenza.
|
||||||
come introduzione a varie tecnologie e serve da punto di partenza.
|
|
||||||
|
|
||||||
Le seguenti opzioni di networking sono ordinate alfabeticamente - l'ordine no
|
Le seguenti opzioni di networking sono ordinate alfabeticamente - l'ordine no implica uno stato preferenziale.
|
||||||
implica uno stato preferenziale.
|
|
||||||
|
|
||||||
### ACI
|
### 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).
|
[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 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.
|
[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.
|
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 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.
|
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/
|
I dettagli su come funziona il sistema AOS sono disponibili qui: http://www.apstra.com/products/how-it-works/
|
||||||
|
|
||||||
@@ -113,7 +121,12 @@ indirizzamento.
|
|||||||
|
|
||||||
### CNI-Genie from Huawei
|
### 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](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-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.
|
||||||
|
|
||||||
@@ -138,11 +151,16 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all
|
|||||||
|
|
||||||
|
|
||||||
226/5000
|
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.
|
[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 / 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.
|
[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
|
||||||
|
|
||||||
@@ -155,20 +173,19 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all
|
|||||||
* 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
|
* 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.
|
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
|
||||||
|
|
||||||
[Flannel](https://github.com/coreos/flannel#flannel) è un overlay molto semplice
|
[Flannel](https://github.com/coreos/flannel#flannel) è un overlay molto semplice rete che soddisfa i requisiti di
|
||||||
rete che soddisfa i requisiti di Kubernetes. Molti
|
Kubernetes. Molti le persone hanno riportato il successo con Flannel e Kubernetes.
|
||||||
le persone hanno riportato il successo con Flannel e Kubernetes.
|
|
||||||
|
|
||||||
### Google Compute Engine (GCE)
|
### Google Compute Engine (GCE)
|
||||||
|
|
||||||
Per gli script di configurazione del cluster di Google Compute Engine, [avanzato
|
Per gli script di configurazione del cluster di Google Compute Engine,
|
||||||
routing] (https://cloud.google.com/vpc/docs/routes) è usato per
|
[avanzato routing](https://cloud.google.com/vpc/docs/routes) è usato per assegna a ciascuna VM una sottorete
|
||||||
assegna a ciascuna VM una sottorete (l'impostazione predefinita è `/ 24` - 254 IP). Qualsiasi traffico vincolato per questo
|
(l'impostazione predefinita è `/ 24` - 254 IP). Qualsiasi traffico vincolato per questo la sottorete verrà instradata
|
||||||
la sottorete verrà instradata direttamente alla VM dal fabric di rete GCE. Questo è dentro
|
direttamente alla VM dal fabric di rete GCE. Questo è dentro aggiunta all'indirizzo IP "principale" assegnato alla VM,
|
||||||
aggiunta all'indirizzo IP "principale" assegnato alla VM, a cui è stato assegnato NAT
|
a cui è stato assegnato NAT accesso a Internet in uscita. Un bridge linux (chiamato `cbr0`) è configurato per esistere
|
||||||
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.
|
su quella sottorete, e viene passato al flag `--bridge` della finestra mobile.
|
||||||
|
|
||||||
Docker è avviato con:
|
Docker è avviato con:
|
||||||
@@ -177,18 +194,14 @@ Docker è avviato con:
|
|||||||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||||
```
|
```
|
||||||
|
|
||||||
Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet`
|
Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al `Nodo` .spec.podCIDR`.
|
||||||
flag) in base al `Nodo` .spec.podCIDR`.
|
|
||||||
|
|
||||||
Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere
|
Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere l'un l'altro e `Nodi` sul
|
||||||
l'un l'altro e `Nodi` sul ponte` cbr0`. Questi IP sono tutti instradabili
|
ponte` cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
|
||||||
all'interno della rete del progetto GCE.
|
|
||||||
|
|
||||||
GCE non sa nulla di questi IP, quindi non lo farà
|
GCE non sa nulla di questi IP, quindi non lo farà loro per il traffico internet in uscita. Per ottenere ciò viene
|
||||||
loro per il traffico internet in uscita. Per ottenere ciò viene utilizzata una regola iptables
|
utilizzata una regola iptables masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` stesso)
|
||||||
masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node`
|
traffico che è vincolato per IP al di fuori della rete del progetto GCE (10.0.0.0/8).
|
||||||
stesso) traffico che è vincolato per IP al di fuori della rete del progetto GCE
|
|
||||||
(10.0.0.0/8).
|
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
|
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
|
||||||
@@ -206,17 +219,26 @@ traffico verso internet.
|
|||||||
|
|
||||||
### Jaguar
|
### 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.
|
[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
|
### Knitter
|
||||||
|
|
||||||
363/5000
|
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.
|
[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
|
### Kube-router
|
||||||
|
|
||||||
430/5000
|
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.
|
[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
|
### L2 networks and linux bridging
|
||||||
|
|
||||||
@@ -232,20 +254,42 @@ Lars Kellogg-Stedman.
|
|||||||
|
|
||||||
### Multus (a Multi Network plugin)
|
### 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](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.
|
||||||
|
|
||||||
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
|
### 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.
|
[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.
|
[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 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.
|
[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.
|
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
|
||||||
|
|
||||||
@@ -263,30 +307,37 @@ a [ovn-kubernetes] (https://github.com/openvswitch/ovn-kubernetes).
|
|||||||
|
|
||||||
### Progetto Calico
|
### Progetto Calico
|
||||||
|
|
||||||
[Project Calico] (http://docs.projectcalico.org/) è un provider di rete contenitore open source e motore di criteri di rete.
|
[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 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.
|
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
|
||||||
|
|
||||||
[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.
|
[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 di Weaveworks
|
||||||
|
|
||||||
[Weave Net] (https://www.weave.works/products/weave-net/) è un
|
[Weave Net](https://www.weave.works/products/weave-net/) è un rete resiliente e semplice da usare per Kubernetes e le
|
||||||
rete resiliente e semplice da usare per Kubernetes e le sue applicazioni in hosting.
|
sue applicazioni in hosting. Weave Net funziona come un plug-in [CNI](https://www.weave.works/docs/net/latest/cni-plugin/)
|
||||||
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
|
||||||
o stand-alone. In entrambe le versioni, non richiede alcuna configurazione o codice aggiuntivo
|
entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per Kubernetes.
|
||||||
per eseguire, e in entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per Kubernetes.
|
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
||||||
Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro
|
Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro i piani sono descritti in maggior
|
||||||
i piani sono descritti in maggior dettaglio nella [progettazione della rete
|
dettaglio nella [progettazione della rete documento](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||||
documento] (https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|||||||
@@ -1,3 +1,5 @@
|
|||||||
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.
|
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).
|
Per ulteriori informazioni, consultare la sostituzione prevista,
|
||||||
|
[Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).
|
||||||
|
|||||||
Reference in New Issue
Block a user