Mwanzoni mwa mwezi huu, Mei 3, toleo kubwa la "mfumo wa usimamizi wa uhifadhi wa data uliosambazwa huko Kubernetes" ulitangazwa - Rook 1.0.0. Zaidi ya mwaka mmoja uliopita sisi tayari iliyochapishwa Muhtasari wa jumla wa Rook. Kisha tuliulizwa kuzungumza juu ya uzoefu wake kutumia katika mazoezi - na sasa, kwa wakati unaofaa kwa hatua muhimu kama hii katika historia ya mradi, tunafurahi kushiriki hisia zetu zilizokusanywa.
Kwa kifupi, Rook ni seti waendeshaji kwa Kubernetes, ambayo inachukua udhibiti kamili wa uwekaji, usimamizi, uokoaji kiotomatiki wa suluhisho za kuhifadhi data kama vile Ceph, EdgeFS, Minio, Cassandra, CockroachDB.
Kumbuka: Miongoni mwa mabadiliko makubwa katika toleo la Rook 1.0.0 linalohusiana na Ceph, tunaweza kutambua msaada kwa Ceph Nautilus na uwezo wa kutumia NFS kwa CephFS au ndoo za RGW. Kinachojitokeza kati ya zingine ni kukomaa kwa usaidizi wa EdgeFS hadi kiwango cha beta.
Kwa hiyo, katika makala hii sisi:
Hebu tujibu swali kuhusu faida gani tunaona katika kutumia Rook kupeleka Ceph katika kundi la Kubernetes;
Tutashiriki uzoefu wetu na maonyesho ya kutumia Rook katika uzalishaji;
Hebu tuambie kwa nini tunasema βNdiyo!β kwa Rook, na kuhusu mipango yetu kwa ajili yake.
Wacha tuanze na dhana na nadharia ya jumla.
"Nina faida ya Rook mmoja!" (mchezaji chess asiyejulikana)
Moja ya faida kuu za Rook ni kwamba mwingiliano na duka za data hufanywa kupitia mifumo ya Kubernetes. Hii inamaanisha kuwa hauitaji tena kunakili amri ili kusanidi Ceph kutoka kwa laha hadi koni.
Je! unataka kupeleka CephFS kwenye nguzo? Andika tu faili ya YAML!
- Nini? Je! unataka pia kupeleka duka la kitu na S3 API? Andika tu faili ya pili ya YAML!
Rook imeundwa kulingana na sheria zote za operator wa kawaida. Kuingiliana naye hutokea kwa kutumia CRD (Ufafanuzi wa Rasilimali Maalum), ambamo tunaelezea sifa za vyombo vya Ceph tunavyohitaji (kwa kuwa huu ndio utekelezaji pekee thabiti, kwa chaguo-msingi kifungu hiki kitazungumza juu ya Ceph, isipokuwa imeelezwa waziwazi). Kwa mujibu wa vigezo maalum, operator atafanya moja kwa moja amri zinazohitajika kwa usanidi.
Wacha tuangalie maalum kwa kutumia mfano wa kuunda Duka la Kitu, au tuseme - CephObjectStoreUser.
Vigezo vilivyoonyeshwa kwenye uorodheshaji ni vya kawaida kabisa na havihitaji maoni, lakini inafaa kulipa kipaumbele maalum kwa zile zilizotengwa kwa anuwai za templeti.
Mpango wa jumla wa kazi unatokana na ukweli kwamba "tunaagiza" rasilimali kupitia faili ya YAML, ambayo opereta hutekeleza amri zinazohitajika na huturudishia siri "isiyo ya kweli" ambayo tunaweza kufanya kazi nayo zaidi. (tazama hapa chini). Na kutoka kwa vigezo vilivyoorodheshwa hapo juu, amri na jina la siri litaundwa.
Hii ni timu ya aina gani? Wakati wa kuunda mtumiaji kwa uhifadhi wa kitu, opereta wa Rook ndani ya ganda atafanya yafuatayo:
radosgw-admin user create --uid="rook-user" --display-name="{{ .Values.s3.username }}"
Matokeo ya kutekeleza amri hii itakuwa muundo wa JSON:
Keys - ni programu gani za siku zijazo zitahitaji kufikia hifadhi ya kitu kupitia API ya S3. Opereta wa Rook huwachagua kwa fadhili na kuziweka katika nafasi ya jina lake kwa njia ya siri iliyo na jina rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.
Ili kutumia data kutoka kwa siri hii, ongeza tu kwenye kontena kama anuwai za mazingira. Kama mfano, nitatoa kiolezo cha Ayubu, ambacho tunatengeneza ndoo kiotomatiki kwa kila mazingira ya mtumiaji:
Vitendo vyote vilivyoorodheshwa katika Ayubu hii vilifanywa ndani ya mfumo wa Kubernetes. Miundo iliyofafanuliwa katika faili za YAML huhifadhiwa kwenye hazina ya Git na kutumika tena mara nyingi. Tunaona hii kama faida kubwa kwa wahandisi wa DevOps na mchakato wa CI/CD kwa ujumla.
Furahia na Rook na Rados
Kutumia mchanganyiko wa Ceph + RBD huweka vizuizi fulani juu ya uwekaji wa ujazo kwenye maganda.
Hasa, nafasi ya majina lazima iwe na siri ya kufikia Ceph ili programu za hali ya juu zifanye kazi. Ni sawa ikiwa una mazingira 2-3 katika nafasi zao za majina: unaweza kwenda na kunakili siri wewe mwenyewe. Lakini vipi ikiwa kwa kila kipengele mazingira tofauti na nafasi yake ya majina yameundwa kwa watengenezaji?
Tulitatua shida hii wenyewe kwa kutumia shell-operator, ambayo ilinakili siri kiotomatiki kwa nafasi mpya za majina (mfano wa ndoano kama hiyo imeelezewa ndani Makala hii).
Walakini, wakati wa kutumia Rook shida hii haipo. Mchakato wa kuweka hutokea kwa kutumia madereva yake kulingana na Sauti ya Flex au CSI (bado katika hatua ya beta) na kwa hivyo hauhitaji siri.
Rook hutatua matatizo mengi kiatomati, ambayo hutuhimiza kuitumia katika miradi mipya.
Kuzingirwa kwa Rook
Wacha tukamilishe sehemu ya vitendo kwa kupeleka Rook na Ceph ili tuweze kufanya majaribio yetu wenyewe. Ili kurahisisha kuvamia mnara huu usioweza kuingizwa, watengenezaji wameandaa kifurushi cha Helm. Hebu tuipakue:
Katika faili rook-ceph/values.yaml unaweza kupata mipangilio mingi tofauti. Jambo muhimu zaidi ni kutaja uvumilivu kwa mawakala na utafutaji. Tulielezea kwa undani ni nini utaratibu wa kuchafua/kuvumilia unaweza kutumika Makala hii.
Kwa kifupi, hatutaki ganda la programu ya mteja liwe kwenye nodi sawa na diski za kuhifadhi data. Sababu ni rahisi: kwa njia hii kazi ya mawakala wa Rook haitaathiri programu yenyewe.
Kwa hiyo, fungua faili rook-ceph/values.yaml na mhariri wako unaopenda na ongeza kizuizi kifuatacho mwishoni:
$ kubectl -n ${ROOK_NAMESPACE} exec $(kubectl -n ${ROOK_NAMESPACE} get pod -l app=rook-ceph-operator -o name -o jsonpath='{.items[0].metadata.name}') -- ceph -s
Wakati huo huo, wacha tuangalie ikiwa maganda yaliyo na programu ya mteja hayaishii kwenye nodi zilizohifadhiwa kwa Ceph:
$ kubectl -n ${APPLICATION_NAMESPACE} get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName
Zaidi ya hayo, vipengele vya ziada vinaweza kusanidiwa kama unavyotaka. Maelezo zaidi juu yao yameonyeshwa katika nyaraka. Kwa utawala, tunapendekeza sana kusakinisha dashibodi na kisanduku cha zana.
Rook na ndoano: Je, Rook inatosha kwa kila kitu?
Kama unaweza kuona, maendeleo ya Rook yanaendelea kikamilifu. Lakini bado kuna shida ambazo hazituruhusu kuachana kabisa na usanidi wa mwongozo wa Ceph:
Hakuna Dereva wa Rook haiwezi metrics ya kuuza nje juu ya matumizi ya vitalu vyema, ambayo inatunyima ufuatiliaji.
Flexvolume na CSI sijui jinsi gani badilisha saizi ya juzuu (kinyume na RBD sawa), kwa hivyo Rook ananyimwa zana muhimu (na wakati mwingine inahitajika sana!).
Rook bado hawezi kunyumbulika kama Ceph wa kawaida. Ikiwa tunataka kusanidi bwawa la metadata ya CephFS kuhifadhiwa kwenye SSD, na data yenyewe kuhifadhiwa kwenye HDD, tutahitaji kusajili vikundi tofauti vya vifaa katika ramani za CRUSH wenyewe.
Licha ya ukweli kwamba rook-ceph-operator inachukuliwa kuwa thabiti, kwa sasa kuna shida kadhaa wakati wa kusasisha Ceph kutoka toleo la 13 hadi 14.
Matokeo
"Kwa sasa Rook amefungiwa kutoka kwa ulimwengu wa nje na pawns, lakini tunaamini kwamba siku moja atachukua jukumu muhimu katika mchezo huo!" (nukuu iliyoundwa mahsusi kwa nakala hii)
Mradi wa Rook bila shaka umeshinda mioyo yetu - tunaamini kwamba [pamoja na faida na hasara zake zote] bila shaka unastahili kuzingatiwa.
Mipango yetu ya siku za usoni inakaribia kutengeneza rook-ceph kuwa moduli ya kiendeshaji cha kuongeza, ambayo itafanya matumizi yake katika vikundi vyetu vingi vya Kubernetes kuwa rahisi na rahisi zaidi.