Heus Habr!
Exness suggestum quadrigis repraesentamus. Antea, collegae nostri, iam scripsit articulum de . Hodie communicare volumus experientiam nostram officia in Kubernetes migrandi.
In primis tibi offerimus aliquos numeros ad melius intelligendum de his quae discutientur;
- Procuratio nostra evolutionis ex 100+ hominibus consistit, inclusis plus quam X diversis iugis cum se contentis QA, DevOpis et Scrum processibus. BIBLIOTHECA Progressu - Python, PHP, C++, Java et Golang.
- Magnitudo temptationis et productionis ambitus circiter 2000 vasorum est. Currunt Rancher v1.6 in virtualizatione sua et sub VMware.
motus
Ut aiunt, nihil perpetuum durat, et Rancherus finem subsidii versionis 1.6 satis diu ante denuntiavit. Etiam plus quam triennio didicimus eam praeparare et problemata quae nascuntur solvenda, sed magis ac saepius in difficultatibus versamur quae numquam corriguntur. Rancher 1.6 etiam rationem ossificatam habet ferendi ius, ubi vel omnia fere vel nihil facere potes.
Etsi virtualisatio proprietaria maiorem potestatem in notitia repono et securitatem praebebat, imposuit operae gratuita quae difficilia erant ad suscipiendum assiduum incrementum societatis, numerus inceptorum et requisitorum pro illis.
Signa Iac sequi voluimus et, si opus est, facultatem cito obtinebimus, in quovis locorum situ ac sine venditore seram, et etiam cito eam relinquere possumus.
tirocinium
Imprimis voluimus in hodiernae technologiae solutionibus niti quae permitterent iunctos cycli evolutionis citius habere et impensas operationales minuere pro mutuo cum suggestu quod potestatem praebet.
Scilicet, primum quod ad mentem nostram venit Kubernetes fuit, sed nos non excitavimus et parum quaesivimus an ius esset optio videre. Nos solutiones apertas tantum aestimavimus et in proelio iniquo Kubernetes sine condicione vicit.
Proxima quaestio est de instrumento eligendo ad ligaturas faciendas. Solutiones populares comparavimus: kops, kubespray, kubeadm.
Ad initium, kubeadm via nimis perplexa nobis visa est, immo ut quaedam inventor "bicycli", et kops flexibilitatem satis non habuit.
et victor erat;
Experiri coepimus cum propria virtualizatione et AWS, recreare conamur aliquid durius simile priori instrumenti ope- ram administrationis, ubi omnes idem "botrus" communicaverunt. Nunc primum botrum habemus de 10 parvis machinis virtualibus, quarum duo in AWS sita sunt. Partes ibi migrare conabantur, omnia videbantur "bona" ββesse, et fabula finiri potuit, sed...
Primum problematum
Ansibile est quod kubespray in structum est, non instrumentum quod te IaC sequi sinit: cum nodis committendis/decommissionibus aliquid constanter erravit et quaedam interventus requirebatur, et cum utens OSes varios, fabulae ratio aliter se gessit. . Cum numerus iunctorum et nodum in botro crevit, incepimus fabularum librum diutius et diutius perficere, et inde testimonium nostrum 3,5 horas, quid de tua? π
Et videtur sicut kubespray justum est Ansible, et prima specie omnia plana sunt, sed;
In initio itineris negotium erat facultates tantum in AWS et in virtualizatione deducendi, sed tunc, ut saepe accidit, requisita mutata sunt.
Sub hac luce patuit vetus exemplar nostrum coniungendi facultates in unam orchestration ratiom non idoneam fuisse - in casu ubi racemi valde remoti sunt et a diversis provisoribus administrantur.
Praeterea plura. Cum omnes iunctiones intra eundem botrum operantur, varia officia cum NodeSelectors perperam inauguratis ad "alienum" exercitum volitare possent et facultates ibi uterentur et, si labes poneretur, assiduae petitiones apparuerunt unum alterumve ministerium non operatum esse, non recte tribuitur factori humano. Alia quaestio sumptus computabat, praesertim problemata in servitiis per nodos distribuendis.
Separata narratio fuit emissionis iurium conductorum: singulae turmae "in capite" botri esse voluit et eam omnino administrare, quae totam ruinam efficere posset, cum iunctae basically ab invicem independentes essent.
Quid faciam?
Attenta supradictorum iunctorum voluntates magis independentes, fecimus conclusionem simplicem: unum manipulum - unum botrum.
Sic secundo nacti sumus;
Tum tertius botrus;
Tunc cogitare coepimus: dicamus anno iunctos nostros plus uno botro habituros? In diversis locis geographicis, exempli gratia, an sub diversis provisoribus? Et aliqui ex eis volent, quod ad tempus botrum aliquod experimentum cito explicari possint.
Plenus Kubernetes veniret! Id multiKubernetes quocunque genere, evenit.
Eodem tempore omnes istas racemos aliquo modo conservare debebimus, ut facile accessum ad eos administrare valeamus, ac novas novasque compositiones veteres sine interventu manuali creare.
Aliquantum temporis ab initio itineris nostri in mundo Kubernetes elapsum est et solutiones praesto denuo examinare decrevimus. Contigit quod iam in foro existit - Rancher 2.2.
In primo stadio investigationis nostrae, Rancher Labs primam emissionem versionis 2 iam fecerat, sed quamvis celerrime erigi posset, vas sine dependentibus externis cum duobus parametris vel cum duobus parametris officialibus utens, rudis videbatur. nobis, et nesciebamus, si huic sententiae inniti possemus utrum enucleetur an cito deseratur. Botrus = clicks paradigma in ipso UI etiam non convenit nobis, et RKE ligari noluimus, cum instrumentum strictius sit usitatum.
Versione Rancher 2.2 iam speciem magis operabilem habuit et, una cum prioribus, fasciculum notarum interesting e cista habuit, ut integratio cum multis provisoribus externis, unum punctum distributionis iurium et imaginum kubeconfig, kubectl deductis. imago cum iuribus tuis in UI, spatiis nominalibus aka inceptis insertis.
Erat etiam communitas circa Rancher 2 formata, et provisor HashiCorp Terraform vocatus creatus est ad eam administrandam, quae nos simul omnia adiuvit.
Quid accidit?
Quam ob rem nos cum uno parvo racemo currente Rancher, omnibus aliis racemis patentibus, ac multis racemis sibi annexis, accessus cuivis tribui potest tam simpliciter ac addito usore ad directorium ldap, cujuscumque rei. ubi sita est et quibus subsidiis provisoris utitur.
Usura gitlab-ci et Terraformi, systema creatum est quod permittit vos creare botrum cuiuslibet configurationis in provisoribus nubis vel infrastructurae nostrae et eas Ranchero coniunge. Haec omnia in stilo IaC fiunt, ubi quilibet botrus per repositorium describitur, et status eius mutatur. Eodem tempore maxime moduli ab exterioribus repositoriis conexi sunt ut omnia quae supersunt variabilia transeant vel tuam consuetudinum figurationem instantiarum describant, quae repetitionem codicis adiuvat reducere recipis.
Utique, iter nostrum longe abest, et adhuc multae operae commodae praecedunt, ut unum punctum laboris cum lignis et metris quarumlibet ligamentorum, reticuli servitii, gitops ad onera gerenda in multiclustro et multo plus. Speramus te experientiam nostram invenire interesting!
Articulum scripsit A. Antipov, A. Ganush, Platform Engineers.
Source: www.habr.com