वर्कर मशीनों का एक समूह, जिन्हें नोड्स भी कहा जाता है, जो कंटेनरीकृत एप्लिकेशन्स चलाते हैं। हर क्लस्टर में कम से कम एक वर्कर नोड होता है।
aka:
tags:
- fundamental
- operation
---
वर्कर मशीनों का एक समूह, जिन्हें {{<glossary_tooltiptext="नोड्स"term_id="node">}} भी कहा जाता है,
जो कंटेनरीकृत एप्लिकेशन्स चलाते हैं। हर क्लस्टर में कम से कम एक वर्कर नोड होता है।
<!--more-->
वर्कर मशीन {{<glossary_tooltiptext="पॉड्स"term_id="pod">}} को होस्ट करते है जो कि एप्लिकेशन वर्कलोड के घटक हैं।
{{<glossary_tooltiptext="कंट्रोल प्लेन"term_id="control-plane">}} क्लस्टर में वर्कर नोड्स और पॉड्स का प्रबंधन करता है। एक प्रोडक्शन वातावरण में, कंट्रोल प्लेन आमतौर पर
कई कंप्यूटरों पर चलता है और एक क्लस्टर आमतौर पर कई नोड्स चलाता है, जो बिना किसी विफलता के और उच्च उपलब्धता प्रदान करता है।
Questa pagina spiega perché e come gestire più cluster di Kubernetes utilizzando
federazione.
<!-- body -->
## Perché la federation
La federation facilita la gestione di più cluster. Lo fa fornendo 2
principali elementi costitutivi:
* Sincronizzare le risorse tra i cluster: la Federazione offre la possibilità di conservare
risorse in più cluster sincronizzati. Ad esempio, è possibile garantire che la stessa distribuzione esista in più cluster.
* Rilevamento cross cluster: Federation offre la possibilità di configurare automaticamente server DNS e load balancer con i backend di tutti i cluster. Ad esempio, è possibile garantire che un record VIP o DNS globale possa essere utilizzato per accedere ai backend da più cluster.
Alcuni altri casi d'uso abilitati dalla federazione sono:
* Alta disponibilità: distribuendo il carico tra i cluster e la configurazione automatica del DNS
server e bilanciamento del carico, la federazione riduce al minimo l'impatto del cluster
fallimento.
* Evitare il lock-in del provider: semplificando la migrazione delle applicazioni
cluster, la federazione impedisce il lock-in del provider di cluster.
La federazione non è utile se non si hanno più cluster. Alcuni dei motivi
perché potresti volere che più cluster siano:
* Bassa latenza: la presenza di cluster in più regioni riduce al minimo la latenza servendo
utenti dal cluster che è più vicino a loro.
* Isolamento dei guasti: potrebbe essere meglio avere più cluster piccoli
di un singolo cluster di grandi dimensioni per l'isolamento dei guasti (ad esempio: multiplo
cluster in diverse zone di disponibilità di un provider cloud).
* Scalabilità: esistono limiti di scalabilità per un singolo cluster di kubernetes (questo
non dovrebbe essere il caso per la maggior parte degli utenti. Per ulteriori dettagli:
[Scaling di Kubernetes e obiettivi di rendimento](https://git.k8s.io/community/sig-scalability/goals.md)).
* [Hybrid cloud](#hybrid-cloud-capabilities): è possibile avere più cluster su diversi provider cloud o
data center locali.
### Caveats
ci sono un sacco di casi d'uso interessanti per la federazione, ci sono anche
alcuni avvertimenti:
* Maggiore larghezza di banda e costo della rete: l'aereo di controllo della federazione controlla tutto
cluster per garantire che lo stato attuale sia come previsto. Questo può portare a
costo di rete significativo se i cluster sono in esecuzione in diverse regioni in
un provider cloud o su diversi provider cloud.
* Ridotto isolamento del cluster incrociato: un errore sul piano di controllo oils può
impatto su tutti i cluster. Questo è mitigato mantenendo la logica in federazione
piano di controllo al minimo. In gran parte delega al piano di controllo in
cluster di kubernetes ogni volta che può. Anche la progettazione e l'implementazione sbagliano
dal lato della sicurezza ed evitare l'interruzione del multi-cluster.
* Maturità: il progetto di federazione è relativamente nuovo e non è molto maturo.
Non tutte le risorse sono disponibili e molte sono ancora alfa. [Problema
problemi noti con il sistema che il team è impegnato a risolvere.
### Hybrid cloud capabilities
le federation di Kubernetes Clusters possono includere cluster in esecuzione
diversi fornitori di servizi cloud (ad esempio Google Cloud, AWS) e locali
(ad esempio su OpenStack). [Kubefed](https://kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/) è il metodo consigliato per la distribuzione di cluster federati.
Successivamente, le [risorse API](#api-risorse) possono estendersi su diversi cluster
e fornitori di cloud.
## Setting up federation
Per poter federare più cluster, è necessario prima impostare una federazione
piano di controllo.
Seguire la [guida di installazione](/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per configurare il
piano di controllo della federazione.
## API resources
Una volta impostato il piano di controllo, è possibile iniziare a creare l'API di federazione
risorse.
Le seguenti guide illustrano alcune delle risorse in dettaglio:
Suggeriamo che tutte le VM in un cluster Kubernetes debbano essere nella stessa zona di disponibilità, perché:
- Rispetto ad un singolo cluster globale di Kubernetes, ci sono meno punti singoli di errore.
- confrontato con un cluster che copre le zone di disponibilità, è più facile ragionare sulle proprietà di disponibilità di a
cluster a zona singola.
- quando gli sviluppatori di Kubernetes stanno progettando il sistema (ad esempio facendo ipotesi su latenza, larghezza di banda o
errori correlati) si presuppone che tutte le macchine si trovino in un unico data center o comunque strettamente connesse.
Si consiglia di eseguire meno cluster con più VM per zona di disponibilità; ma è possibile eseguire più cluster per zone di disponibilità.
I motivi per preferire un minor numero di cluster per zona di disponibilità sono:
- Miglioramento del confezionamento dei contenitori in alcuni casi con più nodi in un cluster (minore frammentazione delle risorse).
- riduzione delle spese generali operative (sebbene il vantaggio sia diminuito man mano che gli strumenti operativi e i processi maturano).
- costi ridotti per i costi fissi delle risorse per gruppo, ad es. VM di apiserver (ma piccole in percentuale
del costo complessivo del cluster per cluster di dimensioni medio-grandi).
I motivi per avere più cluster includono:
- rigide politiche di sicurezza che richiedono l'isolamento di una classe di lavoro da un'altra (ma, vedi Partizionare Cluster
sotto).
- testare i cluster su nuove versioni di Kubernetes o su altri software cluster.
## Selezione del numero corretto di cluster
La selezione del numero di cluster di Kubernetes può essere una scelta relativamente statica, rivisitata solo occasionalmente.
Al contrario, il numero di nodi in un cluster e il numero di pod in un servizio possono variare di frequente in base a
carico e crescita.
Per scegliere il numero di cluster, in primo luogo, decidere in quali regioni è necessario avere una latenza adeguata per tutti gli utenti finali, per i servizi che verranno eseguiti
su Kubernetes (se si utilizza una rete di distribuzione di contenuti, i requisiti di latenza per i contenuti ospitati da CDN non sono necessari
essere considerato). Questioni legali potrebbero influenzare anche questo. Ad esempio, un'azienda con una base clienti globale potrebbe decidere di avere cluster nelle regioni USA, UE, AP e SA.
Chiama il numero di regioni in "R".
In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stesso tempo, pur essendo disponibili. Chiamata
il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta.
Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora
avete bisogno almeno dei grossi `R` o `U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)`
(`U + 1` in ciascuna delle regioni `R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora
potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8
cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni](/docs/setup/cluster-large/) per maggiori informazioni.
## {{% heading "whatsnext" %}}
* Ulteriori informazioni sulla [Federazione 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 [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8)
* Vedi questo [Kubecon2017 aggiornamento Europa sulla federazione](https://www.youtube.com/watch?v=kwOvOLnFYck)
* Vedi questo [Kubecon2018 aggiornamento Europa su sig-multicluster](https://www.youtube.com/watch?v=vGZo5DaThQU)
* Vedi questo [Kubecon2018 Europe Federation-v2 presentazione prototipo](https://youtu.be/q27rbaX5Jis?t=7m20s)
* Vedi questo [Federation-v2 Userguide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md)
other=" Die Dokumentation wird nicht mehr aktiv gepflegt. Die aktuell angezeigte Version ist eine statische Momentaufnahme. Aktuelle Dokumentation finden Sie unter "
Drew Hagen
GitHub