Estas pluraj manieroj agordi datumstokadon por aplikaĵoj kurantaj sur Kubernetes-areto. Kelkaj el ili jam estas malmodernaj, aliaj aperis sufiĉe lastatempe. En ĉi tiu artikolo, ni rigardos la koncepton de tri ebloj por konekti stokadsistemojn, inkluzive de la plej lastatempa - konekti per la Uja Stoka Interfaco.
Metodo 1: Specifu PV en la pod manifesto
Tipa manifesto priskribanta balgon en Kubernetes-areto:
La partoj de la manifesto kiuj priskribas kiu volumeno estas ligita kaj kie estas elstarigitaj en koloro.
sekcio volumeMontoj indiku la muntajn punktojn (mountPath) - en kiu dosierujo ene de la ujo la konstanta volumeno estos muntita, same kiel la nomo de la volumeno.
sekcio x listigas ĉiujn volumojn kiuj estas uzataj en la pod. Indiku la nomon de ĉiu volumo, same kiel la tipon (en nia kazo: awsElasticBlockStore) kaj konektajn parametrojn. Kiuj parametroj estas listigitaj en la manifesto dependas de la volumtipo.
La sama volumeno povas esti muntita samtempe en multoblaj podujoj. Tiel, malsamaj aplikaĵprocezoj povas aliri la samajn datumojn.
Ĉi tiu konektometodo estis inventita komence, kiam Kubernetes estis ĵus en sia infanaĝo, kaj hodiaŭ la metodo estas malmoderna.
Estas pluraj problemoj dum ĝi uzas:
- ĉiuj volumoj devas esti kreitaj permane; Kubernetes ne povas krei ion ajn por ni;
- alirparametroj por ĉiu volumo estas unikaj, kaj ili devas esti specifitaj en la manifestoj de ĉiuj balgoj kiuj uzas la volumon;
- por ŝanĝi la stokadsistemon (ekzemple, moviĝi de AWS al Google Cloud), vi devas ŝanĝi la agordojn kaj tipon de muntitaj volumoj en ĉiuj manifestoj.
Ĉio ĉi estas tre maloportuna, do fakte ĉi tiu metodo estas uzata por konekti nur iujn specialajn tipojn de volumoj: configMap, sekreta, emptyDir, hostPath:
-
configMap kaj sekreto estas servaj volumoj, kiuj permesas vin krei volumon kun dosieroj de Kubernetes-manifestoj en la ujo.
-
emptyDir estas provizora volumo, kreita nur por la vivdaŭro de la pod. Konvena uzi por testi aŭ stoki provizorajn datumojn. Kiam pod estas forigita, la volumo emptyDir ankaŭ estas forigita kaj ĉiuj datumoj estas perditaj.
-
hostPath - permesas vin munti ajnan dosierujon sur la loka disko de la servilo sur kiu la aplikaĵo funkcias ene de la ujo kun la aplikaĵo, inkluzive de /etc/kubernetes. Ĉi tio estas nesekura funkcio, do sekurecaj politikoj kutime malpermesas la uzon de ĉi tiu tipo. Alie, la aplikaĵo de atakanto povos munti la dosierujon de HTC Kubernetes ene de sia ujo kaj ŝteli ĉiujn grapolajn atestilojn. Tipe, hostPath-volumoj nur rajtas esti uzataj de sistemaj aplikaĵoj, kiuj funkcias en la kube-sistema nomspaco.
estas donitaj en la dokumentado.
Metodo 2. Konekto al SC/PVC/PV-fajroj
Alternativa konekta metodo estas la koncepto de Stokado klaso, PersistentVolumeClaim, PersistentVolume.
Stoka klaso stokas konektajn parametrojn al la datumstokada sistemo.
PersistentVolumeClaim priskribas la postulojn por tio, kion la aplikaĵo bezonas.
Persistenta Volumo stokas alirparametrojn kaj voluman statuson.
La esenco de la ideo: en la pod manifesto ili indikas volumon de tipo PersistentVolumeClaim kaj indikas la nomon de ĉi tiu ento en la parametro claimName.
La PersistentVolumeClaim manifesto priskribas la postulojn por la volumo de datumoj kiujn la aplikaĵo postulas. Inkluzive de:
- grandeco de disko;
- alirmetodo: ReadWriteOnce aŭ ReadWriteMany;
- ligo al Stokado klaso - en kiu datumstokado sistemo ni volas krei la volumon.
La Stoka klasmanifesto stokas la tipon kaj parametrojn de la konekto al la stokadsistemo. La kubeto bezonas ilin por munti la volumon sur sia nodo.
PersistentVolume-manifestoj indikas la Stokadoklason kaj alirparametrojn por specifa volumeno (volumenidentigilo, vojo, ktp.).
Kreante PVC, Kubernetes rigardas kian grandecon kaj kian Stokan klason necesas, kaj elektas senpagan PersistentVolume.
Se tiaj PV-oj ne haveblas, Kubernetes povas lanĉi specialan programon - Provizanto (ĝia nomo estas indikita en la Stokado-klaso). Ĉi tiu programo konektas al la stokada sistemo, kreas volumon de la bezonata grandeco, ricevas identigilon kaj kreas PersistentVolume manifeston en la Kubernetes-grupo, kiu estas asociita kun la PersistentVolumeClaim.
Ĉiu ĉi tiu amaso da abstraktaĵoj permesas forigi informojn pri kiu konserva sistemo kun kiu la aplikaĵo laboras de la aplikaĵa manifestnivelo ĝis la administra nivelo.
Ĉiuj parametroj por konektiĝi al la datuma stokado-sistemo situas en la Stokado-klaso, pri kiu respondecas administrantoj de cluster. Ĉio, kion vi devas fari, kiam vi translokiĝas de AWS al Google Cloud, estas ŝanĝi la nomon de la Stokado-klaso al PVC en la aplikaĵaj manifestoj. Persista Volumo por datumstokado estos kreita en la areto aŭtomate per la programo Provisioner.
Способ 3. Container Storage Interface
Ĉiu kodo, kiu interagas kun diversaj stokadsistemoj, estas parto de la Kubernetes-kerno. La liberigo de eraroj aŭ nova funkcio estas ligita al novaj eldonoj; la kodo devas esti ŝanĝita por ĉiuj subtenataj versioj de Kubernetes. Ĉio ĉi estas malfacile konservi kaj aldoni novajn funkciojn.
Por solvi la problemon, programistoj de Cloud Foundry, Kubernetes, Mesos kaj Docker kreis la Container Storage Interface (CSI) - simplan unuigitan interfacon, kiu priskribas la interagadon de la kontenera mastruma sistemo kaj speciala ŝoforo (CSI Driver) kiu funkcias kun specifa. stokado sistemo. Ĉiu kodo por interagado kun stokadsistemoj estis movita de la Kubernetes-kerno al aparta sistemo.
.
Tipe, CSI Driver konsistas el du komponentoj: Noda Kromaĵo kaj Controller kromaĵo.
Node Plugin funkcias sur ĉiu nodo kaj respondecas pri muntado de volumoj kaj farado de operacioj sur ili. La aldonaĵo Controller interagas kun la stokadsistemo: kreas aŭ forigas volumojn, asignas alirrajtojn, ktp.
Nuntempe, la malnovaj ŝoforoj restas en la Kubernetes-kerno, sed oni ne plu rekomendas uzi ilin kaj oni konsilas al ĉiuj instali la CSI-ŝoforon specife por la sistemo kun kiu ili funkcios.
La novigo eble timigos tiujn, kiuj jam kutimas agordi datumstokadon per la Stokado klaso, sed fakte nenio terura okazis. Por programistoj, nenio vere ŝanĝiĝas - ili funkciis nur kun la nomo Stokado klaso, kaj daŭre faros tion. Por administrantoj, la instalo de helm-diagramo estis aldonita kaj la strukturo de la agordoj ŝanĝiĝis. Se antaŭe la agordoj estis enigitaj rekte en la Stokado-klason, nun ili unue devas esti agorditaj en la stirila letero, kaj poste en la Stokado-klaso. Se vi rigardas ĝin, nenio malbona okazis.
Ni prenu ekzemplon por rigardi la avantaĝojn, kiujn vi povas akiri ŝanĝante al konekto de Ceph-stokaj sistemoj per la CSI-ŝoforo.
Kiam vi laboras kun Ceph, la kromaĵo CSI provizas pli da ebloj por labori kun stokadsistemoj ol enkonstruitaj ŝoforoj.
- Dinamika kreado de disko. Tipe RBD-diskoj estas uzitaj nur en RWO-reĝimo, sed CSI por Ceph permesas al ili esti uzitaj en RWX-reĝimo. Pluraj balgoj sur malsamaj nodoj povas munti la saman RDB-diskon sur siaj nodoj kaj labori kun ili paralele. Por esti justa, ne ĉio estas tiel hela - ĉi tiu disko povas esti konektita nur kiel bloka aparato, kio signifas, ke vi devos adapti la aplikaĵon por labori kun ĝi en multobla alira reĝimo.
- Kreante momentfotojn. En Kubernetes-grupo, vi povas krei manifeston kun la postulo krei momentfoton. La CSI-kromaĵo vidos ĝin kaj prenos momentfoton de la disko. Surbaze de ĝi, vi povas fari aŭ sekurkopion aŭ kopion de PersistentVolume.
- Pliigante diskograndecon pri stokado kaj PersistentVolume en Kubernetes-areto.
- Kvotoj. La CephFS-ŝoforoj enkonstruitaj en Kubernetes ne subtenas kvotojn, sed freŝaj CSI-kromaĵoj kun la plej nova Ceph Nautilus povas ebligi kvotojn sur CephFS-diskoj.
- Metriko. La CSI-kromaĵo povas provizi Prometheus per diversaj mezuroj pri kiuj volumoj estas konektitaj, kiaj komunikadoj okazas, ktp.
- Topologio konscia. Permesas al vi specifi en manifestoj kiel la areto estas geografie distribuita, kaj eviti konekti stoksistemon situantan en Amsterdamo al podoj kurantaj en Londono.
Kiel konekti Ceph al Kubernetes-areo per CSI, vidu . Vi ankaŭ povas aboni , kiu lanĉos la 15-an de oktobro.
Aŭtoro de la artikolo: Sergey Bondarev, praktikanta arkitekto ĉe Southbridge, Certified Kubernetes Administrator, unu el la programistoj de kubespray.
Немного Post Scriptum не рекламы для, а пользы ради…
PS Sergey Bondarev gvidas du intensajn kursojn: ĝisdatigita 28-30 septembro kaj progresinta 14–16 oktobro.
fonto: www.habr.com