Kubernetes အစုအဝေးတွင် ဒေတာသိမ်းဆည်းခြင်း။

Kubernetes အစုအဝေးတွင် လုပ်ဆောင်နေသော အပလီကေးရှင်းများအတွက် ဒေတာသိုလှောင်မှုကို စီစဉ်သတ်မှတ်ရန် နည်းလမ်းများစွာ ရှိပါသည်။ တချို့က ခေတ်နောက်ကျနေပြီ၊ တချို့က မကြာသေးဘူး။ ဤဆောင်းပါးတွင်၊ နောက်ဆုံးတစ်ခု - Container Storage Interface မှတစ်ဆင့် ချိတ်ဆက်ခြင်းအပါအဝင် သိုလှောင်မှုစနစ်များကို ချိတ်ဆက်ခြင်းအတွက် ရွေးချယ်စရာသုံးခု၏ သဘောတရားကို ဤဆောင်းပါးတွင် ကြည့်ရှုပါမည်။

နည်းလမ်း 1- pod manifest တွင် PV ကို သတ်မှတ်ပါ။

Kubernetes အစုအဝေးတွင် pod တစ်ခုကို ဖော်ပြသည့် ပုံမှန် manifest တစ်ခု-

မည်သည့်အသံအတိုးအကျယ်ကို ချိတ်ဆက်ထားပြီး မည်သည့်နေရာတွင် အရောင်ဖြင့် မီးမောင်းထိုးထားသည်ကို ဖော်ပြသည့် မန်နီးဖက်စ်၏ အစိတ်အပိုင်းများ။

အပိုင်း volumemounts mount အမှတ်များ (mountPath) ကိုညွှန်ပြပါ - ကွန်တိန်နာအတွင်းအမြဲတမ်းအသံအတိုးအကျယ်ကိုတပ်ဆင်မည့်လမ်းညွှန်အပြင် volume ၏အမည်။

အပိုင်း x pod တွင်အသုံးပြုသော volumes အားလုံးကိုစာရင်းပြုစုသည်။ အသံအတိုးအကျယ်တစ်ခုစီ၏အမည်၊ အမျိုးအစား (ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ awsElasticBlockStore) နှင့် ချိတ်ဆက်မှုဘောင်များကို သတ်မှတ်ပါ။ မန်နီးဖက်စ်တွင် ဖော်ပြထားသော မည်သည့် ကန့်သတ်ချက်များသည် အသံအတိုးအကျယ် အမျိုးအစားပေါ်တွင် မူတည်သည်။

တူညီသောအသံအတိုးအကျယ်ကို pod container အများအပြားတွင် တပြိုင်နက်တည်း တပ်ဆင်နိုင်သည်။ ဤနည်းအားဖြင့် မတူညီသော အပလီကေးရှင်းလုပ်ငန်းစဉ်များသည် တူညီသောဒေတာကို ရယူနိုင်သည်။

Kubernetes သည် နို့စို့အရွယ်တွင်ရှိစဉ်ကတည်းက ဤချိတ်ဆက်မှုနည်းလမ်းကို စတင်တီထွင်ခဲ့ပြီး ယနေ့ခေတ်တွင် နည်းလမ်းသည် ခေတ်နောက်ကျနေပြီဖြစ်သည်။

၎င်းကိုအသုံးပြုရာတွင် ပြဿနာများစွာရှိသည်။

1. အတွဲအားလုံးကို ကိုယ်တိုင်ဖန်တီးရမည်ဖြစ်ပြီး Kubernetes သည် ကျွန်ုပ်တို့အတွက် မည်သည့်အရာကိုမျှ ဖန်တီးမပေးနိုင်ပါ။
2. Volume တစ်ခုစီအတွက် access parameters များသည် ထူးခြားပြီး volume ကိုအသုံးပြုသည့် pods အားလုံး၏ manifests များတွင် ၎င်းတို့ကို သတ်မှတ်ပေးရပါမည်။
3. သိုလှောင်မှုစနစ်အား ပြောင်းလဲရန် (ဥပမာ၊ AWS မှ Google Cloud သို့ ရွှေ့ရန်)၊ မန်နီးဖက်စ်များအားလုံးတွင် ဆက်တင်များနှင့် တပ်ဆင်ထားသည့် volumes အမျိုးအစားကို ပြောင်းလဲရန် လိုအပ်သည်။

ဤအရာအားလုံးသည် အလွန်အဆင်မပြေသောကြောင့် လက်တွေ့တွင် ဤနည်းလမ်းသည် အချို့သော အထူး volumes အမျိုးအစားများကိုသာ ချိတ်ဆက်ရန် အသုံးပြုသည်- configMap၊ secret, emptyDir, hostPath:

• configMap နှင့် လျှို့ဝှက်ချက်တို့သည် ကွန်တိန်နာအတွင်းရှိ Kubernetes မှ ဖိုင်များနှင့်အတူ volume တစ်ခုကို ဖန်တီးနိုင်စေမည့် ဝန်ဆောင်မှုပမာဏများဖြစ်သည်။

• emptyDir သည် pod ၏တစ်သက်တာအတွက်သာဖန်တီးထားသောယာယီအသံအတိုးအကျယ်ဖြစ်သည်။ ယာယီဒေတာကို စမ်းသပ်ရန် သို့မဟုတ် သိမ်းဆည်းရန်အတွက် အသုံးပြုရန် အဆင်ပြေသည်။ ပေါ့ဒ်တစ်ခုကို ဖျက်လိုက်သောအခါ၊ ဗလာဒိုင်ယာ အသံအတိုးအကျယ်ကိုလည်း ဖျက်လိုက်ပြီး ဒေတာအားလုံး ဆုံးရှုံးသွားပါသည်။

• hostPath - သင့်အား /etc/kubernetes အပါအဝင် အပလီကေးရှင်းဖြင့် ကွန်တိန်နာအတွင်း အလုပ်လုပ်နေသည့် ဆာဗာ၏ ဒေသန္တရဒစ်တွင် မည်သည့်လမ်းညွှန်ကိုမဆို တပ်ဆင်ခွင့်ပြုသည်။ ၎င်းသည် အန္တရာယ်ကင်းသည့် အင်္ဂါရပ်ဖြစ်သောကြောင့် လုံခြုံရေးမူဝါဒများသည် ပုံမှန်အားဖြင့် ဤအမျိုးအစား၏ volumes ကိုအသုံးပြုခြင်းကို တားမြစ်ထားသည်။ မဟုတ်ပါက၊ တိုက်ခိုက်သူ၏အပလီကေးရှင်းသည် ၎င်း၏ကွန်တိန်နာအတွင်း HTC Kubernetes လမ်းညွှန်ကို တပ်ဆင်နိုင်ပြီး အစုလိုက်လက်မှတ်များအားလုံးကို ခိုးယူနိုင်မည်ဖြစ်သည်။ ပုံမှန်အားဖြင့်၊ hostPath volumes များကို kube-system namespace တွင်လည်ပတ်သည့်စနစ်အပလီကေးရှင်းများမှသာအသုံးပြုရန်ခွင့်ပြုထားသည်။

Kubernetes သည် သေတ္တာအပြင်ဘက်တွင် အလုပ်လုပ်သော သိုလှောင်မှုစနစ်များ စာရွက်စာတမ်းများတွင်ပေးထားသည်။

နည်းလမ်း 2. SC/PVC/PV မီးဖိုများနှင့် ချိတ်ဆက်မှု

အခြားချိတ်ဆက်မှုနည်းလမ်းမှာ Storage အတန်းအစား၊ PersistentVolumeClaim၊ PersistentVolume ၏ သဘောတရားဖြစ်သည်။

သိုလှောင်မှုအတန်း ဒေတာသိုလှောင်မှုစနစ်တွင် ချိတ်ဆက်မှုဘောင်များကို သိမ်းဆည်းပါ။

PersistentVolumeClaim လျှောက်လွှာတွင် လိုအပ်သည်များ အတွက် လိုအပ်ချက်များကို ဖော်ပြသည်။
PersistentVolume ဝင်ရောက်ခွင့် ကန့်သတ်ချက်များနှင့် အသံအတိုးအကျယ် အခြေအနေတို့ကို သိမ်းဆည်းထားသည်။

အိုင်ဒီယာ၏ အနှစ်သာရ- pod manifest တွင် PersistentVolumeClaim အမျိုးအစား၏ ပမာဏကို ညွှန်ပြပြီး တောင်းဆိုမှုအမည် ကန့်သတ်ချက်ရှိ ဤအဖွဲ့အစည်း၏ အမည်ကို ညွှန်ပြပါသည်။

PersistentVolumeClaim မန်နီးဖက်စ်သည် အပလီကေးရှင်းလိုအပ်သည့် ဒေတာပမာဏအတွက် လိုအပ်ချက်များကို ဖော်ပြသည်။ အပါအဝင်-

• disk အရွယ်အစား;
• အသုံးပြုခွင့်နည်းလမ်း- ReadWriteOnce သို့မဟုတ် ReadWriteMany;
• သိုလှောင်မှု အတန်းသို့ လင့်ခ် - ဒေတာ သိမ်းဆည်းမှု စနစ်တွင် ကျွန်ုပ်တို့ ဖန်တီးလိုသော အသံအတိုးအကျယ်။

သိုလှောင်ခန်း မန်နီးဖက်စ်သည် သိုလှောင်မှုစနစ်သို့ ချိတ်ဆက်မှု၏ အမျိုးအစားနှင့် ကန့်သတ်ချက်များကို သိမ်းဆည်းထားသည်။ cubelet သည် ၎င်း၏ node တွင် volume ကိုတပ်ဆင်ရန် ၎င်းတို့ကို လိုအပ်သည်။

PersistentVolume manifests များသည် သိုလှောင်မှု အတန်းအစား နှင့် တိကျသော volume (volume ID, path, etc.) အတွက် အသုံးပြုခွင့် ဘောင်များကို ညွှန်ပြပါသည်။

PVC ကိုဖန်တီးသောအခါတွင် Kubernetes သည် မည်သည့်အရွယ်အစားပမာဏနှင့် Storage အတန်းလိုအပ်သည်ကို ကြည့်ရှုပြီး အခမဲ့ PersistentVolume ကို ရွေးချယ်သည်။

ထိုသို့သော PV များကိုမရရှိနိုင်ပါက Kubernetes သည် အထူးပရိုဂရမ်တစ်ခု - Provisioner (၎င်း၏အမည်ကို Storage အတန်းတွင်ဖော်ပြထားသည်)။ ဤပရိုဂရမ်သည် သိုလှောင်မှုစနစ်သို့ ချိတ်ဆက်ပြီး၊ လိုအပ်သည့် အရွယ်အစား၏ ပမာဏကို ဖန်တီးပေးကာ၊ အထောက်အထားတစ်ခု လက်ခံရရှိကာ PersistentVolumeClaim နှင့် ဆက်စပ်နေသည့် Kubernetes အစုအဝေးတွင် PersistentVolume မန်နီးဖက်စ်ကို ဖန်တီးပေးပါသည်။

ဤ abstractions အစုံလိုက်အားလုံးသည် အပလီကေးရှင်းမှ အက်ပ်လီကေးရှင်းဖော်ပြသည့်အဆင့်မှ စီမံခန့်ခွဲရေးအဆင့်အထိ မည်သည့်သိုလှောင်မှုစနစ်အကြောင်း အချက်အလက်များကို ဖယ်ရှားနိုင်စေမည်ဖြစ်သည်။

ဒေတာသိမ်းဆည်းမှုစနစ်သို့ ချိတ်ဆက်ခြင်းအတွက် ကန့်သတ်ဘောင်များအားလုံးသည် အစုအဝေးစီမံခန့်ခွဲသူများတွင် တာဝန်ရှိသည့် သိုလှောင်မှုအတန်းတွင် တည်ရှိပါသည်။ AWS မှ Google Cloud သို့ပြောင်းသောအခါ သင်လုပ်ဆောင်ရမည့်အရာမှာ အပလီကေးရှင်းဖော်ပြချက်တွင် Storage အတန်း၏အမည်ကို PVC သို့ပြောင်းရန်ဖြစ်သည်။ Provisioner ပရိုဂရမ်ကို အသုံးပြု၍ ဒေတာသိမ်းဆည်းမှုအတွက် ဆက်တိုက်ပမာဏကို အစုအဝေးတွင် အလိုအလျောက် ဖန်တီးပေးမည်ဖြစ်သည်။

နည်းလမ်း 3- ကွန်တိန်နာ သိုလှောင်မှု အင်တာဖေ့စ်

အမျိုးမျိုးသော သိုလှောင်မှုစနစ်များနှင့် အပြန်အလှန်တုံ့ပြန်သည့် ကုဒ်အားလုံးသည် Kubernetes core ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ ချွတ်ယွင်းချက်ပြင်ဆင်မှုများ သို့မဟုတ် လုပ်ဆောင်နိုင်စွမ်းအသစ်များ ထုတ်ဝေမှုသည် အသစ်ထွက်ရှိမှုများနှင့် ဆက်စပ်နေသည်; Kubernetes ၏ ပံ့ပိုးထားသောဗားရှင်းအားလုံးအတွက် ကုဒ်ကို ပြောင်းလဲရပါမည်။ ဤအရာအားလုံးကို ထိန်းသိမ်းရန်နှင့် လုပ်ဆောင်ချက်အသစ်များကို ထည့်သွင်းရန် ခက်ခဲသည်။

ပြဿနာကိုဖြေရှင်းရန်အတွက် Cloud Foundry၊ Kubernetes၊ Mesos နှင့် Docker မှ developer များသည် Container Storage Interface (CSI) - ကွန်တိန်နာစီမံခန့်ခွဲမှုစနစ်၏ အပြန်အလှန်အကျိုးသက်ရောက်မှုကိုဖော်ပြသည့် ရိုးရှင်းသောပေါင်းစပ်အင်တာဖေ့စ်ကို ဖန်တီးပြီး တိကျသောအထူးဒရိုင်ဘာ (CSI Driver) ကို ဖန်တီးခဲ့သည်။ သိုလှောင်မှုစနစ်။ သိုလှောင်မှုစနစ်များနှင့် အပြန်အလှန်တုံ့ပြန်မှုအတွက် ကုဒ်အားလုံးကို Kubernetes core မှ သီးခြားစနစ်သို့ ရွှေ့ထားသည်။

Container Storage Interface Documentation.

ပုံမှန်အားဖြင့်၊ CSI Driver တွင် Node Plugin နှင့် Controller plugin တွင် အစိတ်အပိုင်းနှစ်ခု ပါဝင်သည်။

Node Plugin သည် node တစ်ခုစီတွင် အလုပ်လုပ်ပြီး Volume များကို တပ်ဆင်ရန်နှင့် ၎င်းတို့အပေါ် လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ရန် တာဝန်ရှိသည်။ Controller ပလပ်အင်သည် သိုလှောင်မှုစနစ်နှင့် အပြန်အလှန်အကျိုးသက်ရောက်သည်- volumes များကို ဖန်တီးခြင်း သို့မဟုတ် ဖျက်ခြင်း၊ ဝင်ရောက်ခွင့်များကို သတ်မှတ်ပေးခြင်း စသည်ဖြင့်။

လက်ရှိတွင်၊ ယာဉ်မောင်းဟောင်းများသည် Kubernetes kernel တွင်ရှိနေသော်လည်း ၎င်းတို့ကိုအသုံးပြုရန် အကြံပြုထားခြင်းမရှိတော့ဘဲ ၎င်းတို့လုပ်ဆောင်မည့်စနစ်အတွက် CSI Driver ကို လူတိုင်းထည့်သွင်းရန် အကြံပြုထားသည်။

ဆန်းသစ်တီထွင်မှုသည် Storage အတန်းမှတစ်ဆင့် ဒေတာသိုလှောင်မှုကို စတင်လုပ်ဆောင်လေ့ရှိသော သူများကို ခြောက်လှန့်စေသော်လည်း အမှန်တကယ်မှာ ကြောက်စရာကောင်းသည့်အရာတစ်ခုမျှ ဖြစ်မလာပါ။ ပရိုဂရမ်မာများအတွက်၊ မည်သည့်အရာမှ အမှန်တကယ် ပြောင်းလဲခြင်းမရှိပါ - ၎င်းတို့သည် Storage class အမည်ဖြင့်သာ လုပ်ဆောင်ခဲ့ပြီး ဆက်လက်လုပ်ဆောင်သွားမည်ဖြစ်သည်။ စီမံခန့်ခွဲသူများအတွက်၊ ဦးခေါင်းဇယားတပ်ဆင်မှုကို ထည့်သွင်းပြီး ဆက်တင်များ၏ဖွဲ့စည်းပုံမှာ ပြောင်းလဲသွားပါသည်။ ယခင်က ဆက်တင်များကို Storage အတန်းထဲသို့ တိုက်ရိုက်ထည့်သွင်းခဲ့ပါက၊ ယခု ၎င်းတို့ကို ဦးထုပ်တန်းဇယားတွင် ဦးစွာသတ်မှတ်ထားပြီး၊ ထို့နောက် Storage အတန်းတွင် ထည့်သွင်းရပါမည်။ ကြည့်လိုက်ရင် ဘာမှ မကောင်းပါဘူး။

CSI ဒရိုက်ဘာကို အသုံးပြု၍ Ceph သိုလှောင်မှုစနစ်များကို ချိတ်ဆက်ခြင်းဖြင့် သင်ရနိုင်သော အကျိုးကျေးဇူးများကို ကြည့်ရှုရန် ဥပမာတစ်ခုကို ကြည့်ကြပါစို့။

Ceph နှင့်အလုပ်လုပ်သောအခါ၊ CSI plugin သည် built-in drivers များထက်သိုလှောင်မှုစနစ်များနှင့်အလုပ်လုပ်ရန်ရွေးချယ်စရာများကိုပေးသည်။

1. Dynamic disk ဖန်တီးမှု။ ပုံမှန်အားဖြင့် RBD ဒစ်များကို RWO မုဒ်တွင်သာ အသုံးပြုသော်လည်း CSI အတွက် Ceph သည် ၎င်းတို့အား RWX မုဒ်တွင် အသုံးပြုရန် ခွင့်ပြုထားသည်။ မတူညီသော node များရှိ pods အများအပြားသည် တူညီသော RDB disk ကို ၎င်းတို့၏ node များတွင် တပ်ဆင်နိုင်ပြီး ၎င်းတို့နှင့် အပြိုင်အလုပ်လုပ်နိုင်သည်။ တရားမျှတစေရန်၊ အရာအားလုံးသည် ဤမျှတောက်ပသည်မဟုတ်ပါ - ဤဒစ်ခ်ကို ပိတ်ဆို့ကိရိယာတစ်ခုအဖြစ်သာ ချိတ်ဆက်နိုင်သည်၊ ဆိုလိုသည်မှာ သင်သည် အက်ပ်လီကေးရှင်းကို အများအပြားဝင်ရောက်ခွင့်မုဒ်တွင် တွဲဖက်လုပ်ဆောင်ရမည်ဖြစ်ပါသည်။
2. လျှပ်တစ်ပြက်ရိုက်ချက်များ ဖန်တီးခြင်း။ Kubernetes အစုအဝေးတွင်၊ လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုဖန်တီးရန် လိုအပ်ချက်နှင့်အတူ မန်နီးဖက်စ်တစ်ခုကို သင်ဖန်တီးနိုင်သည်။ CSI ပလပ်အင်သည် ၎င်းကိုမြင်ရပြီး ဒစ်ခ်မှ လျှပ်တစ်ပြက်ရိုက်ယူမည်ဖြစ်သည်။ ၎င်းကို အခြေခံ၍ သင်သည် အရန်ကူးခြင်း သို့မဟုတ် PersistentVolume ၏ မိတ္တူတစ်ခု ပြုလုပ်နိုင်သည်။
3. ဒစ်ခ်အရွယ်အစားကို တိုးမြှင့်ခြင်း။ သိုလှောင်မှုနှင့် Kubernetes အစုအဝေးရှိ PersistentVolume ပေါ်တွင်။
4. ခွဲတမ်းများ။ Kubernetes တွင်တည်ဆောက်ထားသော CephFS drivers များသည် quotas ကိုမပံ့ပိုးပါ၊ သို့သော်နောက်ဆုံးပေါ် Ceph Nautilus ပါသော CSI ပလပ်အင်အသစ်များသည် CephFS partitions များတွင် quotas ကိုဖွင့်နိုင်သည်။
5. မက်ထရစ်များ။ CSI ပလပ်အင်သည် Prometheus သည် မည်သည့် volumes များ ချိတ်ဆက်နေသည်၊ မည်သို့သော ဆက်သွယ်မှုများ ဖြစ်ပွားနေသည် စသဖြင့် အမျိုးမျိုးသော မက်ထရစ်များကို ပေးစွမ်းနိုင်ပါသည်။
6. Topology သတိထားပါ။ အစုအဝေးကို ပထဝီဝင်အနေအထားအရ ဖြန့်ဝေပုံကို ဖော်ပြချက်တွင် သင့်အား သတ်မှတ်ခွင့်ပြုပြီး အမ်စတာဒမ်တွင်ရှိသော သိုလှောင်မှုစနစ်အား လန်ဒန်တွင် လုပ်ဆောင်နေသော pods များနှင့် ချိတ်ဆက်ခြင်းမှ ရှောင်ကြဉ်ပါ။

CSI မှတဆင့် Ceph ကို Kubernetes အစုအဝေးသို့ မည်သို့ချိတ်ဆက်ရမည်ကို ကြည့်ပါ။ Slurm ညနေပိုင်းကျောင်းဟောပြောပွဲ၏လက်တွေ့အပိုင်းတွင်. စာရင်းသွင်းလို့လည်းရပါတယ်။ Ceph ဗီဒီယိုသင်တန်းအောက်တိုဘာလ 15 ရက်နေ့တွင် စတင်ရောင်းချမည်ဖြစ်သည်။

ဆောင်းပါးရေးသားသူ- Sergey Bondarev၊ Southbridge တွင် ဗိသုကာပညာရှင်၊ Kubernetes စီမံခန့်ခွဲသူ၊ kubespray တီထွင်သူ တစ်ဦးဖြစ်သည်။

အနည်းငယ်သော Post Scriptum သည် ကြော်ငြာရန်အတွက်မဟုတ်သော်လည်း အကျိုးအတွက်...

PS Sergey Bondarev သည် အထူးကြပ်မတ်သင်တန်းနှစ်ခုကို ဦးဆောင်သည်- မွမ်းမံထားသည်။ Kubernetes အခြေစိုက်စခန်း စက်တင်ဘာ ၂၈-၃၀ နှင့် အဆင့်မြင့် Kubernetes Mega အောက်တိုဘာ ၁၄-၁၆။

source: www.habr.com