Ehi Habr!
Rappresentiamo il team della piattaforma Exness. In precedenza, i nostri colleghi hanno già scritto un articolo su . Oggi vogliamo condividere la nostra esperienza di migrazione dei servizi a Kubernetes.
Per cominciare vi proponiamo alcuni numeri per comprendere meglio di cosa si tratterà:
- Il nostro reparto di sviluppo è composto da oltre 100 persone, inclusi più di 10 team diversi con processi QA, DevOps e Scrum autosufficienti. Stack di sviluppo: Python, PHP, C++, Java e Golang.
- La dimensione degli ambienti di test e di produzione è di circa 2000 container ciascuno. Stanno eseguendo Rancher v1.6 sulla propria virtualizzazione e con VMware.
motivazione
Come si suol dire, nulla dura per sempre e Rancher ha annunciato la fine del supporto per la versione 1.6 molto tempo fa. Sì, in più di tre anni abbiamo imparato a prepararlo e a risolvere i problemi che si presentano, ma sempre più spesso ci troviamo di fronte a problemi che non verranno mai risolti. Rancher 1.6 ha anche un sistema fossilizzato per il rilascio dei diritti, dove puoi fare quasi tutto o niente.
Sebbene la virtualizzazione proprietaria fornisse un maggiore controllo sull'archiviazione dei dati e sulla loro sicurezza, imponeva costi operativi difficili da accettare data la costante crescita dell'azienda, il numero di progetti e le relative esigenze.
Volevamo seguire gli standard IaC e, se necessario, ottenere capacità rapidamente, in qualsiasi posizione geografica e senza vincoli del fornitore, ed essere anche in grado di abbandonarla rapidamente.
Primi passi
Innanzitutto volevamo affidarci a tecnologie e soluzioni moderne che consentissero ai team di avere un ciclo di sviluppo più rapido e minimizzassero i costi operativi per l'interazione con la piattaforma che fornisce energia.
Naturalmente la prima cosa che ci è venuta in mente è stata Kubernetes, ma non ci siamo emozionati e abbiamo fatto una piccola ricerca per vedere se fosse la scelta giusta. Abbiamo valutato solo soluzioni open source e, in una battaglia sleale, Kubernetes ha vinto incondizionatamente.
Successivamente è arrivata la questione della scelta di uno strumento per la creazione di cluster. Abbiamo confrontato le soluzioni più popolari: kops, kubespray, kubeadm.
All’inizio kubeadm ci sembrava un percorso troppo complicato, una specie di inventore di “bicicletta”, e kops non aveva abbastanza flessibilità.
E il vincitore è stato:
Abbiamo iniziato a sperimentare con la nostra virtualizzazione e AWS, cercando di ricreare qualcosa di più o meno simile al nostro precedente modello di gestione delle risorse, in cui tutti condividevano lo stesso "cluster". E ora abbiamo il nostro primo cluster di 10 piccole macchine virtuali, un paio delle quali si trovano in AWS. Abbiamo iniziato a provare a migrare le squadre lì, tutto sembrava essere “buono” e la storia poteva essere finita, ma…
Primi problemi
Ansible è ciò su cui è costruito kubespray, non è uno strumento che ti consente di seguire IaC: durante la messa in servizio/dismissione dei nodi, qualcosa andava costantemente storto ed era necessario un qualche tipo di intervento, e quando si utilizzavano sistemi operativi diversi, il playbook si comportava diversamente. . Man mano che il numero di team e nodi nel cluster cresceva, abbiamo iniziato a notare che il completamento del playbook richiedeva sempre più tempo e, di conseguenza, il nostro record era di 3,5 ore, e il tuo? 🙂
E sembra che kubespray sia solo Ansible, e tutto è chiaro a prima vista, ma:
All'inizio del viaggio, il compito era lanciare capacità solo in AWS e nella virtualizzazione, ma poi, come spesso accade, i requisiti sono cambiati.
Alla luce di ciò, è diventato chiaro che il nostro vecchio modello di combinazione delle risorse in un unico sistema di orchestrazione non era adatto nel caso in cui i cluster fossero molto remoti e fossero gestiti da fornitori diversi.
Inoltre. Quando tutti i team lavorano all'interno dello stesso cluster, vari servizi con NodeSelector installati in modo errato potrebbero volare sull'host "estraneo" di un altro team e utilizzare le risorse lì, e se era impostata la contaminazione, c'erano continue richieste che l'uno o l'altro servizio non funzionasse, non distribuito correttamente a causa del fattore umano. Un altro problema era calcolare il costo, soprattutto considerando i problemi nella distribuzione dei servizi tra i nodi.
Una storia a parte è stata l'assegnazione dei diritti ai dipendenti: ogni squadra voleva essere “a capo” del cluster e gestirlo completamente, il che potrebbe causare un collasso completo, poiché le squadre sono sostanzialmente indipendenti l'una dall'altra.
Cosa fare?
Tenendo conto di quanto sopra e del desiderio dei team di essere più indipendenti, siamo giunti ad una conclusione semplice: un team, un cluster.
Quindi ne abbiamo ottenuto un secondo:
E poi il terzo cluster:
Poi abbiamo iniziato a pensare: diciamo che tra un anno i nostri team avranno più di un cluster? In aree geografiche diverse, ad esempio, o sotto il controllo di fornitori diversi? E alcuni di loro vorranno essere in grado di implementare rapidamente un cluster temporaneo per alcuni test.
Arriverebbe Kubernetes completo! Si scopre che questa è una specie di MultiKubernetes.
Allo stesso tempo, dovremo tutti in qualche modo mantenere tutti questi cluster, essere in grado di gestirne facilmente l’accesso, nonché crearne di nuovi e smantellare quelli vecchi senza intervento manuale.
È passato del tempo dall'inizio del nostro viaggio nel mondo di Kubernetes e abbiamo deciso di riesaminare le soluzioni disponibili. Si è scoperto che esiste già sul mercato: Rancher 2.2.
Nella prima fase della nostra ricerca, Rancher Labs aveva già realizzato il primo rilascio della versione 2, ma sebbene potesse essere sollevata molto rapidamente lanciando un contenitore senza dipendenze esterne con un paio di parametri o utilizzando il grafico HELM ufficiale, sembrava rozzo a noi, e non sapevamo se potevamo contare su questa decisione, se sarebbe stata sviluppata o abbandonata rapidamente. Anche il paradigma cluster = clic nell'interfaccia utente stessa non ci andava bene e non volevamo legarci a RKE, poiché è uno strumento piuttosto mirato.
La versione Rancher 2.2 aveva già un aspetto più funzionale e, insieme alle precedenti, aveva una serie di caratteristiche interessanti pronte all'uso, come l'integrazione con molti provider esterni, un unico punto di distribuzione dei diritti e dei file kubeconfig, il lancio di un kubectl immagine con i tuoi diritti nell'interfaccia utente, spazi dei nomi nidificati, ovvero progetti.
C'era anche una comunità già formata attorno a Rancher 2 e per gestirla è stato creato un provider chiamato HashiCorp Terraform, che ci ha aiutato a mettere insieme il tutto.
Quello che è successo
Di conseguenza, ci siamo ritrovati con un piccolo cluster che esegue Rancher, accessibile a tutti gli altri cluster, così come a molti cluster ad esso collegati, l'accesso a ognuno dei quali può essere concesso semplicemente come aggiungendo un utente alla directory ldap, indipendentemente da dove si trova e quali risorse del provider utilizza.
Utilizzando gitlab-ci e Terraform, è stato creato un sistema che consente di creare un cluster di qualsiasi configurazione nei provider cloud o nella nostra infrastruttura e collegarli a Rancher. Tutto questo viene fatto in stile IaC, dove ogni cluster è descritto da un repository e il suo stato è dotato di versione. Allo stesso tempo, la maggior parte dei moduli sono collegati da repository esterni in modo che tutto ciò che resta da fare sia passare variabili o descrivere la configurazione personalizzata per le istanze, il che aiuta a ridurre la percentuale di ripetizione del codice.
Naturalmente, il nostro viaggio è lungi dall'essere finito e ci sono ancora molti compiti interessanti da fare, come un unico punto di lavoro con log e metriche di eventuali cluster, mesh di servizi, gitops per la gestione dei carichi in un multicluster e molto altro. Ci auguriamo che troverai la nostra esperienza interessante!
L'articolo è stato scritto da A. Antipov, A. Ganush, Platform Engineers.
Fonte: habr.com