23 settembre 20.00 MSK Sergej Bondarev terrà un webinar gratuito "`, in cui spiegherà come si prepara kubespray per renderlo veloce, efficiente e resistente ai guasti.
Sergej Bondarev illustrerà le differenze tra la versione originale e il nostro fork:
La differenza tra la versione originale e il nostro fork.
Coloro che hanno già avuto esperienza con kubespray potrebbero ora chiedersi perché io opponga kubeadm a kubespray, dato che kubespray viene utilizzato per creare un cluster e in effetti chiama kubeadm, e a prima vista sembra un semplice script per l'installazione di pacchetti e l'avvio automatizzato.
Ma non è sempre stato così; in origine, kubespray installava tutti i componenti autonomamente:
- assemblava il cluster etcd;
- installava i kubelet, generava certificati, configurazioni e token di accesso per i pod statici del control plane e altri componenti di servizio;
- creava account di servizio per i nodi di lavoro e li collegava al cluster.
Ma l'anno scorso hanno rimosso questa funzionalità, lasciando solo kubeadm, che all'epoca non era molto performante. Mi sono sentito deluso e ho creato il mio fork, nel quale ho mantenuto la modalità classica di installazione, e ora supporto attivamente questo fork, cherry-pickando i commit dal kubespray originale. Nel frattempo, aggiorno la modalità classica con le nuove modifiche.
Pertanto, la differenza tra i cluster creati dal mio fork e quello originale è kube-proxy e i tempi di validità dei certificati.
Nel mio fork tutto è rimasto come prima: kube-proxy viene eseguito come static pod e i certificati vengono emessi per 100 anni.
In Kubeadm, kube-proxy viene eseguito come daemonset e i certificati vengono emessi per 1 anno, e devono essere rinnovati periodicamente. kubeadm ha finalmente imparato a fare questo con un solo comando.
La differenza è piccola, e al momento utilizziamo entrambi i varianti.
Caratteristiche (svantaggi) nell'uso industriale:
Lo scenario è universale, quindi non è molto veloce. La propria versione può essere notevolmente accelerata, eliminando i controlli e avviandosi da un'immagine preconfigurata.
Lo scenario è complesso, ci sono parti illogiche e un pesante retaggio legacy. L'installazione di controller e software aggiuntivi tramite kubespray è utile per l'apprendimento e i test. Nella produzione, dipendere da kubespray non è una grande idea; inoltre, l'aggiornamento del software avviene con il metodo "ho distrutto - fatto nuovo", il che significa interruzioni nel servizio.
È possibile aggiungere solo nodi di lavoro; ci sono alcune complessità con i master riguardo ai certificati e lo scenario non gestisce tutti i possibili problemi che potrebbero sorgere.
Ad esempio, ho avuto un problema con kubeadm quando è fallito durante l'aggiunta del secondo e terzo master, e dopo questo kubespray eseguiva kubeadm reset sul nodo, provando ad aggiungere di nuovo il master.
Il problema era che al momento del guasto il secondo istanza di etcd si era già registrata, e poiché veniva anch'essa eliminata dopo il reset, ci ritrovavamo in una situazione difficile: un cluster etcd con due nodi, uno dei quali era stato rimosso e l'altro non accettava più clienti. Alla fine, il cluster è morto prima ancora di nascere.
Opensource com'è.
Tutto questo e molto altro in un webinar gratuito "" il 23 settembre alle 20:00 MSK.
Unisciti a noi!
Fonte: habr.com
