Adunay daghang mga paagi aron ma-configure ang pagtipig sa datos alang sa mga aplikasyon nga nagdagan sa usa ka cluster sa Kubernetes. Ang uban kanila karaan na, ang uban nagpakita nga bag-o lang. Niini nga artikulo, atong tan-awon ang konsepto sa tulo ka mga kapilian alang sa pagkonektar sa mga sistema sa pagtipig, lakip ang pinakabag-o nga usa - pagkonektar pinaagi sa Container Storage Interface.
Pamaagi 1: Ipiho ang PV sa pod manifest
Usa ka tipikal nga manifest nga naghulagway sa usa ka pod sa usa ka Kubernetes cluster:
Ang mga bahin sa manifest nga naghulagway kung unsang volume ang konektado ug diin gipasiugda ang kolor.
seksyon volumeMounts ipahibalo ang mga punto sa pag-mount (mountPath) - diin ang direktoryo sa sulod sa sulud i-mount ang permanente nga volume, ingon man ang ngalan sa volume.
seksyon x naglista sa tanang volume nga gigamit sa pod. Ipiho ang ngalan sa matag volume, ingon man ang tipo (sa among kaso: awsElasticBlockStore) ug mga parameter sa koneksyon. Unsa nga mga parameter ang gilista sa manifest nagdepende sa tipo sa volume.
Ang parehas nga gidaghanon mahimong i-mount dungan sa daghang mga sudlanan nga pod. Niining paagiha, ang lainlaing mga proseso sa aplikasyon maka-access sa parehas nga datos.
Kini nga pamaagi sa koneksyon naimbento sa sinugdanan, sa dihang ang Kubernetes bag-o pa lang, ug karon ang pamaagi wala na sa panahon.
Adunay daghang mga problema sa paggamit niini:
- ang tanan nga mga volume kinahanglan himuon nga mano-mano; ang mga Kubernetes dili makahimo og bisan unsa alang kanamo;
- Ang mga parameter sa pag-access alang sa matag volume talagsaon, ug kini kinahanglan nga itakda sa mga pagpakita sa tanan nga mga pod nga naggamit sa volume;
- aron mabag-o ang sistema sa pagtipig (pananglitan, pagbalhin gikan sa AWS hangtod sa Google Cloud), kinahanglan nimo nga usbon ang mga setting ug tipo sa gi-mount nga mga volume sa tanan nga mga pagpakita.
Kining tanan dili kombenyente, mao nga sa pagkatinuod kini nga pamaagi gigamit sa pagkonektar lamang sa pipila ka mga espesyal nga matang sa mga volume: configMap, sekreto, emptyDir, hostPath:
-
Ang configMap ug sekreto mao ang mga volume sa serbisyo nga nagtugot kanimo sa paghimo og volume nga adunay mga file gikan sa Kubernetes nga gipakita sa sudlanan.
-
Ang emptyDir usa ka temporaryo nga volume, nga gihimo lamang alang sa tibuok kinabuhi sa pod. Sayon gamiton alang sa pagsulay o pagtipig sa temporaryo nga datos. Kung matangtang ang usa ka pod, ang volume nga emptyDir matangtang usab ug mawala ang tanan nga datos.
-
hostPath - nagtugot kanimo sa pag-mount sa bisan unsang direktoryo sa lokal nga disk sa server diin ang aplikasyon nagdagan sa sulod sa sudlanan nga adunay aplikasyon, lakip ang /etc/kubernetes. Kini usa ka dili luwas nga bahin, busa ang mga palisiya sa seguridad kasagarang nagdili sa paggamit sa mga volume sa kini nga klase. Kung dili, ang aplikasyon sa usa ka tig-atake makahimo sa pag-mount sa direktoryo sa HTC Kubernetes sa sulod sa sulud niini ug kawaton ang tanan nga mga sertipiko sa cluster. Kasagaran, ang mga volume sa hostPath gitugotan ra nga magamit sa mga aplikasyon sa sistema nga nagdagan sa namespace sa kube-system.
gihatag sa dokumentasyon.
Pamaagi 2. Koneksyon sa SC/PVC/PV hearths
Usa ka alternatibo nga paagi sa koneksyon mao ang konsepto sa klase sa Pagtipig, PersistentVolumeClaim, PersistentVolume.
Klase sa pagtipig nagtipig sa mga parameter sa koneksyon sa sistema sa pagtipig sa datos.
PersistentVolumeClaim naghulagway sa mga kinahanglanon alang sa gikinahanglan sa aplikasyon.
PersistentVolume nagtipig sa mga parameter sa pag-access ug kahimtang sa volume.
Ang esensya sa ideya: sa pod nga gipakita gipakita nila ang usa ka gidaghanon sa tipo nga PersistentVolumeClaim ug gipakita ang ngalan niini nga entidad sa parameter nga claimName.
Ang PersistentVolumeClaim manifest naghulagway sa mga kinahanglanon alang sa gidaghanon sa datos nga gikinahanglan sa aplikasyon. Lakip ang:
- gidak-on sa disk;
- paagi sa pag-access: ReadWriteOnce o ReadWriteMany;
- link sa klase sa Pagtipig - diin ang sistema sa pagtipig sa datos gusto namon nga himuon ang gidaghanon.
Gitipigan sa klase sa Pagtipig ang klase ug mga parameter sa koneksyon sa sistema sa pagtipig. Ang cubelet nagkinahanglan kanila sa pag-mount sa volume sa iyang node.
Gipakita sa PersistentVolume ang klase sa Pagtipig ug mga parameter sa pag-access alang sa usa ka piho nga volume (volume ID, agianan, ug uban pa).
Sa paghimo ug PVC, gitan-aw sa Kubernetes kung unsa ang gidak-on sa gidaghanon ug unsa nga klase sa Pagtipig ang gikinahanglan, ug nagpili usa ka libre nga PersistentVolume.
Kung ang ingon nga mga PV wala magamit, ang Kubernetes mahimong maglunsad og usa ka espesyal nga programa - Provisioner (ang ngalan niini gipakita sa klase sa Pagtipig). Kini nga programa nagkonektar sa sistema sa pagtipig, nagmugna sa usa ka gidaghanon sa gikinahanglan nga gidak-on, nakadawat sa usa ka identifier ug nagmugna sa usa ka PersistentVolume nga manifest sa Kubernetes cluster, nga gilambigit sa PersistentVolumeClaim.
Ang tanan nga kini nga hugpong sa mga abstraction nagtugot kanimo sa pagtangtang sa kasayuran bahin sa kung unsang sistema sa pagtipig ang gigamit sa aplikasyon gikan sa lebel sa pagpakita sa aplikasyon hangtod sa lebel sa administrasyon.
Ang tanan nga mga parameter alang sa pagkonektar sa sistema sa pagtipig sa datos nahimutang sa klase sa Pagtipig, diin ang mga tagdumala sa cluster ang responsable. Ang kinahanglan nimong buhaton kung mobalhin gikan sa AWS hangtod sa Google Cloud mao ang pagbag-o sa ngalan sa klase sa Pagtipig sa PVC sa mga pagpakita sa aplikasyon. Ang Persistance Volume para sa pagtipig sa datos himoon sa cluster nga awtomatiko gamit ang Provisioner program.
Pamaagi 3. Container Storage Interface
Ang tanan nga code nga nakig-uban sa lain-laing mga sistema sa pagtipig kay bahin sa Kubernetes core. Ang pagpagawas sa mga pag-ayo sa bug o bag-ong pagpaandar nahigot sa mga bag-ong pagpagawas; ang code kinahanglang usbon para sa tanang gisuportahan nga bersyon sa Kubernetes. Tanan kini lisud nga mapadayon ug makadugang bag-ong pagpaandar.
Aron masulbad ang problema, ang mga developers gikan sa Cloud Foundry, Kubernetes, Mesos ug Docker naghimo sa Container Storage Interface (CSI) - usa ka yano nga hiniusa nga interface nga naghulagway sa interaksyon sa container management system ug usa ka espesyal nga drayber (CSI Driver) nga nagtrabaho sa usa ka piho sistema sa pagtipig. Ang tanan nga code alang sa interaksyon sa mga sistema sa pagtipig gibalhin gikan sa kinauyokan sa Kubernetes ngadto sa usa ka bulag nga sistema.
.
Kasagaran, ang CSI Driver naglangkob sa duha ka sangkap: Node Plugin ug Controller plugin.
Ang Node Plugin nagdagan sa matag node ug responsable sa pagpataas sa mga volume ug paghimo sa mga operasyon niini. Ang Controller nga plugin nakig-uban sa sistema sa pagtipig: nagmugna o nagtangtang sa mga volume, naghatag mga katungod sa pag-access, ug uban pa.
Sa pagkakaron, ang daan nga mga drayber nagpabilin sa Kubernetes kernel, apan wala na sila girekomenda nga gamiton ug ang tanan gitambagan nga i-install ang CSI Driver ilabi na alang sa sistema diin sila magtrabaho.
Ang kabag-ohan mahimong makahadlok sa mga naanad na sa pag-set up sa pagtipig sa datos pinaagi sa klase sa Pagtipig, apan sa tinuud walaβy makalilisang nga nahitabo. Alang sa mga programmer, wala'y kausaban - nagtrabaho lamang sila sa ngalan nga klase sa Pagtipig, ug magpadayon sa pagbuhat niini. Alang sa mga tigdumala, ang pag-instalar sa helm chart gidugang ug ang istruktura sa mga setting nausab. Kung kaniadto ang mga setting gisulod direkta sa klase sa Pagtipig, karon kinahanglan una nga ibutang kini sa tsart sa timon, ug dayon sa klase sa Pagtipig. Kung imong tan-awon, walaβy daotan nga nahitabo.
Atong kuhaon ang usa ka pananglitan aron tan-awon ang mga benepisyo nga imong makuha pinaagi sa pagbalhin sa pagkonekta sa mga sistema sa pagtipig sa Ceph gamit ang drayber sa CSI.
Kung nagtrabaho kauban ang Ceph, ang CSI plugin naghatag daghang mga kapilian alang sa pagtrabaho sa mga sistema sa pagtipig kaysa sa mga built-in nga drayber.
- Pagmugna sa dinamikong disk. Kasagaran ang mga RBD disk gigamit lamang sa RWO mode, apan ang CSI para sa Ceph nagtugot niini nga gamiton sa RWX mode. Daghang mga pod sa lain-laing mga node ang maka-mount sa parehas nga RDB disk sa ilang mga node ug magtrabaho uban kanila nga managsama. Aron mahimong patas, dili tanan hayag kaayo - kini nga disk mahimo ra nga konektado ingon usa ka block device, nga nagpasabut nga kinahanglan nimo nga ipahiangay ang aplikasyon aron magamit kini sa daghang mode sa pag-access.
- Paghimo og mga snapshot. Sa usa ka Kubernetes cluster, makahimo ka og manifest nga adunay kinahanglanon nga maghimo og snapshot. Ang CSI plugin makakita niini ug mokuha og snapshot gikan sa disk. Pinasukad niini, mahimo ka maghimo usa ka backup o kopya sa PersistentVolume.
- Pagdugang sa gidak-on sa disk sa pagtipig ug PersistentVolume sa Kubernetes cluster.
- Mga quota. Ang mga drayber sa CephFS nga gitukod sa Kubernetes wala mosuporta sa mga quota, apan ang mga presko nga CSI plugins nga adunay pinakabag-o nga Ceph Nautilus makahimo sa mga quota sa mga partisyon sa CephFS.
- Mga sukatan. Ang CSI plugin makahatag sa Prometheus sa lain-laing mga metrics mahitungod sa kung unsang mga volume ang konektado, unsa nga mga komunikasyon ang nahitabo, ug uban pa.
- Nahibal-an ang topology. Nagtugot kanimo sa pagpiho sa mga pagpakita kung giunsa ang cluster giapod-apod sa heyograpiya, ug likayan ang pagkonektar sa usa ka sistema sa pagtipig nga nahimutang sa Amsterdam sa mga pod nga nagdagan sa London.
Giunsa pagkonektar ang Ceph sa usa ka kumpol sa Kubernetes pinaagi sa CSI, tan-awa . Mahimo ka usab nga mag-subscribe sa , nga ilusad sa Oktubre 15th.
Awtor sa artikulo: Sergey Bondarev, nagpraktis nga arkitekto sa Southbridge, Certified Kubernetes Administrator, usa sa mga nag-develop sa kubespray.
Usa ka gamay nga Post Scriptum dili alang sa advertising, apan alang sa kaayohan ...
Si PS Sergey Bondarev nanguna sa duha ka intensive nga kurso: updated Septiyembre 28-30 ug abante Oktubre 14β16.
Source: www.habr.com