23 settembre 20.00 MSK Sergei Bondarev terrà un webinar gratuito «», dove spiegherà come si prepara kubespray per essere veloce, efficace e resiliente.
Sergei Bondarev parlerà delle differenze tra la versione originale e il nostro fork:
Differenze tra la versione originale e il nostro fork.
Coloro che hanno già avuto a che fare con kubespray si staranno probabilmente chiedendo perché io contrapponga kubeadm a kubespray, visto che kubespray per creare un cluster chiama proprio kubeadm e, a prima vista, sembra un semplice script per l'installazione dei pacchetti e l'avvio automatizzato.
Ma non è stato sempre così; inizialmente, kubespray installava tutti i componenti autonomamente:
- costruiva un 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 due anni fa hanno rimosso questa funzionalità, lasciando solo kubeadm, che all'epoca non era molto buono. Mi sono sentito frustrato e ho creato il mio fork, nel quale ho mantenuto la modalità di installazione classica e ora tengo aggiornato questo fork, cherry-pickando i commit dall'originale kubespray. Nel frattempo, ho aggiornato la modalità classica per adattarla ai nuovi cambiamenti.
Di conseguenza, la differenza tra i cluster creati dal mio fork e quello originale è kube-proxy e la durata dei certificati.
Nel mio fork, tutto è rimasto com'era prima: kube-proxy viene eseguito come pod statico, 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 finalmente ha imparato a farlo con un solo comando.
La differenza è piccola e al momento utilizziamo entrambe le varianti.
Caratteristiche (svantaggi) nell'uso industriale:
Lo scenario è universale, quindi non è molto veloce. La versione proprietaria può essere notevolmente accelerata, eliminando i controlli, avviandosi da un'immagine pronta.
La sceneggiatura è complessa, ci sono punti illogici, eredità pesante legacy. L'installazione di controllori e software aggiuntivi tramite Kubespray è utile per formazione e test. In produzione, dipendere da Kubespray non è un'idea molto saggia, inoltre l'aggiornamento del software è realizzato con il metodo "ho distrutto-fatto nuovo" — il che significa interruzione del servizio.
È possibile aggiungere solo nodi di lavoro, con i master ci sono alcune questioni relative ai certificati, e lo scenario non affronta tutti i possibili problemi che potrebbero sorgere.
Ad esempio, ho avuto un problema con kubeadm, quando falliva nel momento in cui aggiungevo il secondo e il terzo master, e dopo di che Kubespray eseguiva kubeadm reset sul nodo, e provava ad aggiungere il master di nuovo.
Solo che il problema era che al momento del crash il secondo istanza etcd era già riuscito a registrarsi, e poiché veniva anche rimosso dopo il reset, si otteneva un incubo — un cluster etcd di due nodi, uno dei quali era stato rimosso, mentre l'altro non accettava più i client. Alla fine, il cluster è morto prima ancora di nascere.
Opensource così com'è.
Tutto ciò e molto altro in un webinar gratuito "" il 23 settembre alle 20.00 MSK.
Unisciti a noi!
Fonte: habr.com
