Remove trailing spaces from it documents (#16790)
This commit is contained in:
Yushiro FURUKAWA
GitHub
parent
669bf498a9
commit
aec8c4bcf5
|
|
@ -8,16 +8,16 @@ css: /css/community.css
|
|||
<div class="community_main">
|
||||
<h1>Codice di condotta della comunità di Kubernetes</h1>
|
||||
|
||||
Kubernetes segue il
|
||||
Kubernetes segue il
|
||||
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">codice di condotta CNCF</a>.
|
||||
Il testo del CNC CoC è replicato di seguito a partire dal
|
||||
Il testo del CNC CoC è replicato di seguito a partire dal
|
||||
<a href="https://github.com/cncf/foundation/blob/0ce4694e5103c0c24ca90c189da81e5408a46632/code-of-conduct.md">commit 0ce4694</a>.
|
||||
Se noti che questo non è aggiornato, ti preghiamo di far presente questo problema.
|
||||
<a href="https://github.com/kubernetes/website/issues/new">file an issue</a>.
|
||||
|
||||
Se noti una violazione del Codice di condotta in occasione di un evento o una riunione, in Slack o in un altro meccanismo di comunicazione,
|
||||
contatta il Comitato per
|
||||
<a href="https://git.k8s.io/community/committee-code-of-conduct">il codice di condotta di Kubernetes/a>.
|
||||
Se noti una violazione del Codice di condotta in occasione di un evento o una riunione, in Slack o in un altro meccanismo di comunicazione,
|
||||
contatta il Comitato per
|
||||
<a href="https://git.k8s.io/community/committee-code-of-conduct">il codice di condotta di Kubernetes/a>.
|
||||
Potete raggiungerci via email all'indirizzo <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
|
||||
Il tuo anonimato sarà protetto.
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ numero di pod che possono essere programmati sul nodo.
|
|||
|
||||
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.
|
||||
Le informazioni sono raccolte da Kubelet dal nodo.
|
||||
|
||||
## Management
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ NodeController è responsabile per l'aggiunta di taints corrispondenti ai proble
|
|||
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.
|
||||
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
|
||||
|
|
@ -229,7 +229,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
|
|||
- `--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
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ fornitore di servizi cloud.
|
|||
|
||||
### 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
|
||||
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
|
||||
|
|
@ -46,15 +46,15 @@ controllerManager:
|
|||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
```
|
||||
|
||||
I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
|
||||
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
|
||||
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
|
||||
Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato durante l'esecuzione di
|
||||
Kubernetes su Amazon Web Services.
|
||||
|
||||
### Node Name
|
||||
|
|
@ -107,23 +107,23 @@ Le informazioni per le annotazioni per AWS sono tratte dai commenti su [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
|
||||
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
|
||||
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
|
||||
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`
|
||||
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
|
||||
|
|
@ -135,7 +135,7 @@ Il provider cloud OpenStack utilizza il nome dell'istanza (come determinato dai
|
|||
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
|
||||
Il provider cloud OpenStack implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da la nuvola
|
||||
sottostante, ove disponibile:
|
||||
|
||||
| Servizio | Versioni API | Richiesto |
|
||||
|
|
@ -252,7 +252,7 @@ file:
|
|||
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
|
||||
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
|
||||
|
|
@ -346,22 +346,22 @@ File `cloud.conf`:
|
|||
## 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
|
||||
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
|
||||
|
||||
### 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
|
||||
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
|
||||
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.
|
||||
|
|
@ -369,31 +369,31 @@ 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,
|
||||
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
|
||||
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 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
|
||||
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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -20,9 +20,9 @@ Prima di scegliere una guida, ecco alcune considerazioni:
|
|||
- **Se si sta progettando per l'alta disponibilità**, impara 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 stai configurando Kubernetes on-premises**, considera quale [modello di rete](/docs/concepts/cluster-administration/networking/) si adatti meglio.
|
||||
- **Se stai configurando Kubernetes on-premises**, considera quale [modello di rete](/docs/concepts/cluster-administration/networking/) si adatti meglio.
|
||||
- Eseguirai 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**?
|
||||
- Vuoi **solo eseguire un cluster**, oppure ti aspetti di fare **lo sviluppo attivo del codice del progetto di Kubernetes**?
|
||||
In quest'ultimo caso, scegli una distribuzione sviluppata attivamente. Alcune distribuzioni utilizzano solo versioni binarie, ma offrono una maggiore varietà di scelte
|
||||
- Familiarizzare con i [componenti](/docs/admin/cluster-components/) necessari per eseguire un cluster.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,13 +13,13 @@ il responsabile del controller.
|
|||
|
||||
## 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
|
||||
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
|
||||
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:
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@ 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
|
||||
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
|
||||
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 %}}
|
||||
|
||||
|
|
@ -34,18 +34,18 @@ 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`
|
||||
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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ 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/)
|
||||
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 %}}
|
||||
|
|
@ -187,9 +187,9 @@ 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
|
||||
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.
|
||||
|
|
@ -208,7 +208,7 @@ La versione stabile e primaria avrebbe un'etichetta `track` con valore come` sta
|
|||
image: gb-frontend:v3
|
||||
```
|
||||
|
||||
e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso
|
||||
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
|
||||
|
|
@ -223,8 +223,8 @@ e quindi puoi creare una nuova versione del frontend del guestbook che porta l'e
|
|||
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
|
||||
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
|
||||
|
|
@ -234,16 +234,16 @@ applicazioni:
|
|||
```
|
||||
|
||||
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
|
||||
È 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
|
||||
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
|
||||
|
|
@ -253,7 +253,7 @@ 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
|
||||
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
|
||||
|
|
@ -267,13 +267,13 @@ 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
|
||||
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
|
||||
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
|
||||
|
|
@ -287,12 +287,12 @@ metadata:
|
|||
...
|
||||
```
|
||||
|
||||
Per ulteriori informazioni, consultare il documento [annotazioni](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
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
|
||||
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
|
||||
|
|
@ -318,7 +318,7 @@ 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
|
||||
[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
|
||||
|
|
@ -327,13 +327,13 @@ A volte è necessario apportare aggiornamenti stretti e senza interruzioni alle
|
|||
|
||||
### 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
|
||||
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à
|
||||
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
|
||||
|
|
@ -341,18 +341,18 @@ $ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.ya
|
|||
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
|
||||
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
|
||||
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
|
||||
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 >}}
|
||||
|
|
@ -367,7 +367,7 @@ In alternativa, puoi anche aggiornare le risorse con `kubectl edit`:
|
|||
$ kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
|
||||
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
|
||||
versione aggiornata:
|
||||
|
||||
```shell
|
||||
|
|
@ -379,7 +379,7 @@ 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
|
||||
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).
|
||||
|
|
@ -396,9 +396,9 @@ and
|
|||
## 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
|
||||
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
|
||||
|
|
@ -409,12 +409,12 @@ 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
|
||||
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
|
||||
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:
|
||||
|
|
@ -424,16 +424,16 @@ $ 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`
|
||||
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
|
||||
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 %}}
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ weight: 50
|
|||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Il networking è una parte centrale di Kubernetes, ma può essere difficile capire esattamente come dovrebbe funzionare.
|
||||
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
|
||||
|
|
@ -71,35 +71,35 @@ 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
|
||||
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)
|
||||
[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.
|
||||
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
|
||||
[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
|
||||
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
|
||||
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
|
||||
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/
|
||||
|
|
@ -121,11 +121,11 @@ 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/),
|
||||
[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.
|
||||
|
|
@ -151,15 +151,15 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all
|
|||
|
||||
|
||||
226/5000
|
||||
[Contiv](https://github.com/contiv/netplugin) fornisce un networking configurabile (nativo l3 usando BGP,
|
||||
[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
|
||||
[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
|
||||
|
|
@ -176,14 +176,14 @@ Con questo set di strumenti DANM è in grado di fornire più interfacce di rete
|
|||
|
||||
### Flannel
|
||||
|
||||
[Flannel](https://github.com/coreos/flannel#flannel) è un overlay molto semplice rete che soddisfa i requisiti di
|
||||
[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
|
||||
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.
|
||||
|
|
@ -196,11 +196,11 @@ 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
|
||||
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)
|
||||
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
|
||||
|
|
@ -219,25 +219,25 @@ 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
|
||||
[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,
|
||||
[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
|
||||
[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
|
||||
|
|
@ -254,41 +254,41 @@ 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
|
||||
[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
|
||||
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
|
||||
[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
|
||||
[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
|
||||
[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
|
||||
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
|
||||
|
|
@ -307,37 +307,37 @@ 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
|
||||
[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
|
||||
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
|
||||
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
|
||||
[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
|
||||
[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
|
||||
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
|
||||
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 %}}
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` ha ormai raggiunto lo stato GA e non è più in
|
||||
L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` ha ormai raggiunto lo stato GA e non è più in
|
||||
fase di sviluppo attivo. La documentazione è solo per scopi storici.
|
||||
|
||||
Per ulteriori informazioni, il seguente link
|
||||
Per ulteriori informazioni, il seguente link
|
||||
[Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).
|
||||
|
|
|
|||
Loading…
Reference in New Issue