Questa pagina spiega perché e come gestire più cluster di Kubernetes utilizzando
federazione.
{{% /capture %}}
{{% capture body %}}
## Perché la federation
La federation facilita la gestione di più cluster. Lo fa fornendo 2
principali elementi costitutivi:
* Sincronizzare le risorse tra i cluster: la Federazione offre la possibilità di conservare
risorse in più cluster sincronizzati. Ad esempio, è possibile garantire che la stessa distribuzione esista in più cluster.
* Rilevamento cross cluster: Federation offre la possibilità di configurare automaticamente server DNS e load balancer con i backend di tutti i cluster. Ad esempio, è possibile garantire che un record VIP o DNS globale possa essere utilizzato per accedere ai backend da più cluster.
Alcuni altri casi d'uso abilitati dalla federazione sono:
* Alta disponibilità: distribuendo il carico tra i cluster e la configurazione automatica del DNS
server e bilanciamento del carico, la federazione riduce al minimo l'impatto del cluster
fallimento.
* Evitare il lock-in del provider: semplificando la migrazione delle applicazioni
cluster, la federazione impedisce il lock-in del provider di cluster.
La federazione non è utile se non si hanno più cluster. Alcuni dei motivi
perché potresti volere che più cluster siano:
* Bassa latenza: la presenza di cluster in più regioni riduce al minimo la latenza servendo
utenti dal cluster che è più vicino a loro.
* Isolamento dei guasti: potrebbe essere meglio avere più cluster piccoli
di un singolo cluster di grandi dimensioni per l'isolamento dei guasti (ad esempio: multiplo
cluster in diverse zone di disponibilità di un provider cloud).
* Scalabilità: esistono limiti di scalabilità per un singolo cluster di kubernetes (questo
non dovrebbe essere il caso per la maggior parte degli utenti. Per ulteriori dettagli:
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
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
