Salve, nomen meum Dmitry Krasnov. Plus quam quinque annos in Kubernetes ligaturas administravi et architecturae microserviae multiplices aedificavi. Ineunte hoc anno ministerium ad uvas Kubernetes in Containerum fundandas curavimus. Hac occasione accepta, dicam tibi quid sit Kubernetes et quam integratio venditoris a fonte aperto differat.
In primis, quid? . Haec est ratio disponendi continentia in multitudine exercituum. Obiter a Graeco interpretatur gubernator seu gubernator. Principio a Google evoluta et postea donata ut technicae contributionis ad Fundationem Computing Native Cloud, ordo internationalis non-prodest, qui tincidunt principes mundi colligit, finis usorum et provisorum technologiae continens.
Curo numerus continentia
Nunc quaenam ista sint vasa. Haec est applicatio cum totius ambitus eius - maxime bibliothecarum ex quibus ratio dependet. Haec omnia in archivis fasciculata sunt, et in forma imaginis exhibita quae ratio operandi, probata et magis, potest currere. Sed quaestio est - in vasis administrandis magnum numerum exercituum difficillimum est. Quam ob rem Kubernetes creatus est.
Continens imaginem repraesentat applicationem plus clientelas eius. Applicatio, clientelas, et ratio imaginis OS in diversis partibus imaginis sita est, ut aiunt, stratis. Stratis pro diversis vasis reddi potest. For example, all applications in the Decuria turpis accumsan dolor ut tortor. Cum vasis currit, non opus est multa exemplaria unius basi iacuit super exercitum condere. Hoc permittit ut imaginem repono et partus optimize.
Cum applicatione a vase currere volumus, stratae necessariae inter se superimponuntur et ratio fasciculi operies formatur. Superposita tabula tabularia ponitur, quae cum sistit continens tollitur. Hoc efficit ut, cum currit, applicatio semper eundem ambitum habeat, quod mutari non potest. Hoc praestat reproducibilitatem ambitus in diversis OSes hospes. Sive Decuria sive Centos est, idem semper ambitus erit. Praeterea receptaculum ab hospite machinationibus in Linux nucleum constructum separatum est. Applicationes in vase non vident files, processus exercitus et continentia vicina. Haec solitudo applicationum ab exercitu OS additam securitatem praebet.
Multa instrumenta praesto sunt ad continentiam in hospicio regendi. Earum maxime popularis est Docker. Permittit tibi plenam vitae cyclum vasorum praebere. Sed in una tantum operatur exercitum. Si vascula per multiplices catervas regere debes, Docker vitam gehennam pro mechanicis facere potest. Quam ob rem Kubernetes creatus est.
Postulatio Kubernetes hoc praecise tribuit facultatem regendi coetus continentium in multiplicibus exercitibus tamquam aliqua quadam entitate simplici. Ratio popularis occasionem praebet DevOps vel Development Operationibus aedificandi, in quibus Kubernetes processus ipsius DevOps currere solebat.
Figure 1. Schematica repraesentatio quomodo Kubernetes operatur
Plena automation
Devops plerumque est automatio processus evolutionis. Dure loquendo, tincidunt scribe codicem, qui ad repositorium uploaded est. Inde statim in hunc codicem colligi potest cum omnibus bibliothecis, probatis et "volutis" ad gradum proximum - Staging, deinde statim ad productionem.
Una cum Kubernetes, DevOps permittit te hunc processum automate ut cum nulla fere participatione fiat ab ipsis tincidunt. Ob hoc, aedificatio signanter velocius est, cum in computatro suo hoc facere non debet - simpliciter particulam codicis scribit, repositorium impellit codicem, post quod pipelineum emittitur, qui processus includere potest. edificandi, probandi, evolvite. Et hoc fit cum omni perpetratione, ideo probatio fit continue.
Simul, utens continente, certo scito totam huius programmatis ambitum in productione omnino solvendam esse in forma qua probatum est. Hoc est, nullae difficultates erunt sicut "aliae versiones in probatione, aliae in productione, sed cum eas instituimus, omnia ceciderunt." Et quoniam hodie inclinatio ad architecturam microservicam habemus, cum pro uno ingenti applicatione centum parvae sunt, ut manualiter eas administraret, ingens baculus operariorum requiretur. Quam ob rem Kubernetes utimur.
Pros, pros, pros
Si de commoda Kubernetarum in suggestu loquimur, tunc magnas utilitates habet ex parte architecturae microserviae administrandi.
- Multas replicas administrandi. Maxima res est per multiplices exercitus continentia continentia. Potius multiplicem applicationem in vasis ut unum ens replicetur. Propter hoc, fabrum de singulis vasis solliciti non sunt. Si unus e vasis inruerit, Kubernetes hoc videbunt et iterum sileo.
- Botri ornatum. Kubernetes etiam botrum retis sic dictam cum spatio electronico suo habet. Propter hoc unumquemque vasculum suam habet orationem. Subpod intellegitur minimum unitas structuralis botri in quo vasa directe emittuntur. Praeterea Kubernetes habet functionem quae libratorem et servitii Inventionem coniungit. Hoc tibi permittit ut manual IP administratione electronica carere ac Kubernetes hoc munus delegare permittat. Valetudo latae compescit et quaestiones adiuvabit deprehendere et negotiatio redirecta ad siliquas operandas.
- Configurationis administratio. Cum frequentes applicationes administrandi, difficile fit applicationem configurationis administrare. Ad hoc, Kubernetes peculiares habet facultates ConfigMap. Permittunt te figurationes in centro condere et eas siliquis applicationibus currentibus exponere. Haec mechanismus permittit nos praestare constantiam configurationis in replicationibus applicationis saltem decem vel centum.
- Volumen Pertinax. Vasa intrinsece immutabilia sunt et, cum continens interclusum est, omnia notitia tabellae systematis scripta destruentur. Sed quaedam applicationes reponunt notitias directe in disco. Ad hanc problema solvendam, Kubernetes habet functionem functionis in disco repositorii - Volumes persistentes. Haec mechanismus externa ad notitias repositionis utitur ac pervicax repositionis, clausulae vel fasciculi in vasa transferre potest. Haec solutio permittit ut separatim ab operariis notitias congreges, quae eos salvat, si iidem operarii dissolvunt.
- Load Balancer. Etsi in Kubernetes res abstractas administrare sicut instruere, StatefulSet, etc., ultimo vasis currunt in machinis virtualibus regularibus vel servientibus ferrariis. Integer non est et nulla tempor incidunt. Kubernetes hoc videbunt et commercium internum ad alias replicas redigunt. Sed quid agat negotiatio quae extrinsecus venit? Si negotium simpliciter directum uni ex operariis, si ingruat, servitus unavailable fiet. Ad hanc solvendam quaestionem, Kubernetes operas habet sicut Balancer Lond. Eaedem ordinantur ut nubes externam libratorem pro omnibus operariis in botro automatice configuret. Librarius externus hic negotiationem externam ad operarios et monitores status sui dirigit. Si unus vel plures opifices facti sunt unavailable, negotiatio ad alios dirigitur. Hoc tibi permittit ut Kubernetes utendo operas aptissimas creas.
Kubernetes optime operatur cum architecturae microserviae currit. Fieri potest ut systema in architectura classica efficiatur, sed frustra est. Si applicatio non potest currere ad multiplices replicationes, quid interest in Kubernetibus an non?
Apertum fontem Kubernetes
Fons apertus Kubernetes res magna est: illud constitui et operatur. Potes eam destruere in servientibus tuis ferramentis, in tua infrastructura, magistros et operarios institue in quibus omnes applicationes persequentur. Maxime, omnis libero id. Sed nuances sunt.
- Prima postulatio cognitionis et experientiae administratorum et fabrum, qui haec omnia explicant et confirmant. Cum client plenam libertatem actionis in botro accipit, reus est ipsius botri faciendi. Et omnia hic frangere perfacile est.
- Secundum est defectus integrationum. Si Kubernetes sine populari virtualizationis suggestu curris, omnia beneficia programmatis non habebis. Ut per assidua volumina et onera librariorum officia.
Figure 2. k8s architectura
Kubernetes a venditore
Integratio cum provisore nubilo duas optiones praebet:
- Uno modo, homo simpliciter preme in globulum creandi globulum et botrum iam figuratum et ad usum paratum.
- Secundo, ipse venditor botrum instituit et cum nube erigit integrationem.
Quomodo hic fit. Ingeniarius qui botrum incipit designat quot opifices indigeat et quibus parametris (exempli gratia 5 operarii, singuli cum 10 CPUs, 16 GB ipsius RAM et dic 100 GB orbis). Post quem accedit ad botrum formatum. In hoc casu, operarii in quo onus immittitur, omnino ad clientem transferuntur, sed totum planum administratio sub officio venditoris manet (si servitium praestatur secundum exemplar muneris administrati).
Sed haec ratio sua vitia habet. Ob hoc quod administratio plane manet apud venditorem, venditor non dat plenam accessum clienti, et hoc minuit flexibilitatem in operando cum Kubernetes. Aliquando accidit ut cliens aliquas functiones specificas Kubernetes addere velit, exempli gratia, authenticas per LDAP, sed procuratio plani configurationis hoc non permittit.
Figure 3. Exemplum Kubernetes botri e nube provisoris
Quid eligere: apertum fontem vel venditorem
So, Estne Kubernetes fons apertus vel venditor specificus? Si apertum fontem Kubernetes accipiamus, usor id agit quod cum eo vult. Sed magna copia te in pede sagittis. Difficilius est apud venditorem, quia omnia excogitantur et figurantur pro societate. Maximum incommodum apertum fontis Kubernetes est postulatio specialium. Cum optio venditoris, societas capitis huius liberatur, sed decernere debebit an emptores suos vel venditores solvant.
Bene, pros sunt manifesta, cons nota sunt. Unum constat: Kubernetes multum difficultates solvit per administrationem multorum continentiae automando. Et quae quis eligat, fons pateret vel venditor - quisque suum consilium facit.
Articulus paratus est a Dmitry Krasnov, architectus principali Containerum servitii provisoris #CloudMTS
Source: www.habr.com