From 041030f32a0cc40fa5de16e1e7057a3f2b9d908f Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 12 Aug 2024 01:35:42 +0100 Subject: [PATCH] Drop legacy federation page Dropping this localized page allows us to stop defining some of the shortcodes it relies upon. --- .../cluster-administration/federation.md | 184 ------------------ 1 file changed, 184 deletions(-) delete mode 100644 content/it/docs/concepts/cluster-administration/federation.md diff --git a/content/it/docs/concepts/cluster-administration/federation.md b/content/it/docs/concepts/cluster-administration/federation.md deleted file mode 100644 index 48816b40f9..0000000000 --- a/content/it/docs/concepts/cluster-administration/federation.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -draft: True -title: Federation -content_type: concept -weight: 80 ---- - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -Questa pagina spiega perché e come gestire più cluster di Kubernetes utilizzando -federazione. - - - -## Perché la federation - -La federation facilita la gestione di più cluster. Lo fa fornendo 2 -principali elementi costitutivi: - -  * Sincronizzare le risorse tra i cluster: la Federazione offre la possibilità di conservare -    risorse in più cluster sincronizzati. Ad esempio, è possibile garantire che la stessa distribuzione esista in più cluster. -  * Rilevamento cross cluster: Federation offre la possibilità di configurare automaticamente server DNS e load balancer con i backend di tutti i cluster. Ad esempio, è possibile garantire che un record VIP o DNS globale possa essere utilizzato per accedere ai backend da più cluster. - -Alcuni altri casi d'uso abilitati dalla federazione sono: - -* Alta disponibilità: distribuendo il carico tra i cluster e la configurazione automatica del DNS -  server e bilanciamento del carico, la federazione riduce al minimo l'impatto del cluster -  fallimento. -* Evitare il lock-in del provider: semplificando la migrazione delle applicazioni -  cluster, la federazione impedisce il lock-in del provider di cluster. - -La federazione non è utile se non si hanno più cluster. Alcuni dei motivi -perché potresti volere che più cluster siano: - -* Bassa latenza: la presenza di cluster in più regioni riduce al minimo la latenza servendo -  utenti dal cluster che è più vicino a loro. -* Isolamento dei guasti: potrebbe essere meglio avere più cluster piccoli -  di un singolo cluster di grandi dimensioni per l'isolamento dei guasti (ad esempio: multiplo -  cluster in diverse zone di disponibilità di un provider cloud). -* Scalabilità: esistono limiti di scalabilità per un singolo cluster di kubernetes (questo -  non dovrebbe essere il caso per la maggior parte degli utenti. Per ulteriori dettagli: -  [Scaling di Kubernetes e obiettivi di rendimento](https://git.k8s.io/community/sig-scalability/goals.md)). -* [Hybrid cloud](#hybrid-cloud-capabilities): è possibile avere più cluster su diversi provider cloud o -  data center locali. - -### Caveats - -ci sono un sacco di casi d'uso interessanti per la federazione, ci sono anche -alcuni avvertimenti: - -* Maggiore larghezza di banda e costo della rete: l'aereo di controllo della federazione controlla tutto -  cluster per garantire che lo stato attuale sia come previsto. Questo può portare a -  costo di rete significativo se i cluster sono in esecuzione in diverse regioni in -  un provider cloud o su diversi provider cloud. -* Ridotto isolamento del cluster incrociato: un errore sul piano di controllo oils può -  impatto su tutti i cluster. Questo è mitigato mantenendo la logica in federazione -  piano di controllo al minimo. In gran parte delega al piano di controllo in -  cluster di kubernetes ogni volta che può. Anche la progettazione e l'implementazione sbagliano -  dal lato della sicurezza ed evitare l'interruzione del multi-cluster. -* Maturità: il progetto di federazione è relativamente nuovo e non è molto maturo. -  Non tutte le risorse sono disponibili e molte sono ancora alfa. [Problema -  88](https://github.com/kubernetes/federation/issues/88) enumera -  problemi noti con il sistema che il team è impegnato a risolvere. - -### Hybrid cloud capabilities - -le federation di Kubernetes Clusters possono includere cluster in esecuzione -diversi fornitori di servizi cloud (ad esempio Google Cloud, AWS) e locali -(ad esempio su OpenStack). [Kubefed](https://kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/) è il metodo consigliato per la distribuzione di cluster federati. - -Successivamente, le [risorse API](#api-risorse) possono estendersi su diversi cluster -e fornitori di cloud. - -## Setting up federation - -Per poter federare più cluster, è necessario prima impostare una federazione -piano di controllo. -Seguire la [guida di installazione](/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per configurare il -piano di controllo della federazione. - -## API resources - -Una volta impostato il piano di controllo, è possibile iniziare a creare l'API di federazione -risorse. -Le seguenti guide illustrano alcune delle risorse in dettaglio: - -* [Cluster](/docs/tasks/administer-federation/cluster/) -* [ConfigMap](/docs/tasks/administer-federation/configmap/) -* [DaemonSets](/docs/tasks/administer-federation/daemonset/) -* [Deployment](/docs/tasks/administer-federation/deployment/) -* [Events](/docs/tasks/administer-federation/events/) -* [Hpa](/docs/tasks/administer-federation/hpa/) -* [Ingress](/docs/tasks/administer-federation/ingress/) -* [Jobs](/docs/tasks/administer-federation/job/) -* [Namespaces](/docs/tasks/administer-federation/namespaces/) -* [ReplicaSets](/docs/tasks/administer-federation/replicaset/) -* [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) - -I [documenti di riferimento API](/docs/reference/federation/) elencano tutti i -risorse supportate da apiserver della federazione. -## Cascading deletion - -Kubernetes versione 1.6 include il supporto per l'eliminazione a cascata di federati -risorse. Con la cancellazione a cascata, quando si elimina una risorsa dal -piano di controllo della federazione, si eliminano anche le risorse corrispondenti in tutti i cluster sottostanti. - -L'eliminazione a cascata non è abilitata per impostazione predefinita quando si utilizza l'API REST. Abilitare -it, imposta l'opzione `DeleteOptions.orphanDependents = false` quando elimini a -risorsa dal piano di controllo della federazione utilizzando l'API REST. Usando `kubectl -delete` -abilita la cancellazione a cascata per impostazione predefinita. Puoi disabilitarlo eseguendo `kubectl -cancella --cascade = false` - -Nota: la versione 1.5 di Kubernetes includeva il supporto per l'eliminazione a cascata di un sottoinsieme di -risorse federative. - -## Ambito di un singolo cluster - -Sui provider IaaS come Google Compute Engine o Amazon Web Services, esiste una VM in a -[zona](https://cloud.google.com/compute/docs/zones) o [disponibilità -zona](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). -Suggeriamo che tutte le VM in un cluster Kubernetes debbano essere nella stessa zona di disponibilità, perché: - -  - Rispetto ad un singolo cluster globale di Kubernetes, ci sono meno punti singoli di errore. -  - confrontato con un cluster che copre le zone di disponibilità, è più facile ragionare sulle proprietà di disponibilità di a -    cluster a zona singola. -  - quando gli sviluppatori di Kubernetes stanno progettando il sistema (ad esempio facendo ipotesi su latenza, larghezza di banda o -    errori correlati) si presuppone che tutte le macchine si trovino in un unico data center o comunque strettamente connesse. - -Si consiglia di eseguire meno cluster con più VM per zona di disponibilità; ma è possibile eseguire più cluster per zone di disponibilità. - -I motivi per preferire un minor numero di cluster per zona di disponibilità sono: - -  - Miglioramento del confezionamento dei contenitori in alcuni casi con più nodi in un cluster (minore frammentazione delle risorse). -  - riduzione delle spese generali operative (sebbene il vantaggio sia diminuito man mano che gli strumenti operativi e i processi maturano). -  - costi ridotti per i costi fissi delle risorse per gruppo, ad es. VM di apiserver (ma piccole in percentuale -    del costo complessivo del cluster per cluster di dimensioni medio-grandi). - -I motivi per avere più cluster includono: - -  - rigide politiche di sicurezza che richiedono l'isolamento di una classe di lavoro da un'altra (ma, vedi Partizionare Cluster -    sotto). -  - testare i cluster su nuove versioni di Kubernetes o su altri software cluster. - -## Selezione del numero corretto di cluster - -La selezione del numero di cluster di Kubernetes può essere una scelta relativamente statica, rivisitata solo occasionalmente. -Al contrario, il numero di nodi in un cluster e il numero di pod in un servizio possono variare di frequente in base a -carico e crescita. - -Per scegliere il numero di cluster, in primo luogo, decidere in quali regioni è necessario avere una latenza adeguata per tutti gli utenti finali, per i servizi che verranno eseguiti -su Kubernetes (se si utilizza una rete di distribuzione di contenuti, i requisiti di latenza per i contenuti ospitati da CDN non sono necessari -essere considerato). Questioni legali potrebbero influenzare anche questo. Ad esempio, un'azienda con una base clienti globale potrebbe decidere di avere cluster nelle regioni USA, UE, AP e SA. -Chiama il numero di regioni in "R". - -In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stesso tempo, pur essendo disponibili. Chiamata -il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta. - -Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora -avete bisogno almeno dei grossi `R` o `U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti -utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)` -(`U + 1` in ciascuna delle regioni `R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa. - -Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora -potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8 -cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni](/docs/setup/cluster-large/) per maggiori informazioni. - - - -## {{% heading "whatsnext" %}} - -* Ulteriori informazioni sulla [Federazione proposta](https://github.com/kubernetes/community/blob/{{}}/contributors/design-proposal/multicluster/federation.md). -* Vedi questo [guida alla configurazione](/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per la federazione dei cluster. -* Vedi questo [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8) -* Vedi questo [Kubecon2017 aggiornamento Europa sulla federazione](https://www.youtube.com/watch?v=kwOvOLnFYck) -* Vedi questo [Kubecon2018 aggiornamento Europa su sig-multicluster](https://www.youtube.com/watch?v=vGZo5DaThQU) -* Vedi questo [Kubecon2018 Europe Federation-v2 presentazione prototipo](https://youtu.be/q27rbaX5Jis?t=7m20s) -* Vedi questo [Federation-v2 Userguide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) -