لنډمهاله حجمونه د ذخیره کولو ظرفیت تعقیب سره: EmptyDir په سټرایډونو کې

لنډمهاله حجمونه د ذخیره کولو ظرفیت تعقیب سره: EmptyDir په سټرایډونو کې

ځینې ​​​​اپلیکیشنونه د ډیټا ذخیره کولو ته هم اړتیا لري ، مګر دوی د دې حقیقت سره خورا آرام دي چې ډیټا به د بیا پیل کولو وروسته خوندي نشي.

د مثال په توګه، د کیشینګ خدمتونه د RAM لخوا محدود دي، مګر کولی شي هغه ډاټا هم حرکت وکړي چې په ندرت سره د ذخیره کولو لپاره کارول کیږي چې د RAM په پرتله ورو وي، په ټولیز فعالیت لږ اغیز لري. نور غوښتنلیکونه باید خبر وي چې ممکن په فایلونو کې د لوستلو یو څه ان پټ وي، لکه ترتیبات یا پټ کیلي.

Kubernetes لا دمخه ډیری ډولونه لري لنډمهاله حجمونه، مګر د دوی فعالیت په هغه څه پورې محدود دی چې په K8s کې پلي کیږي.

وختي د CSI حجم Kubernetes ته اجازه ورکړل شوې چې د CSI چلوونکو سره وغځول شي ترڅو د لږ وزن محلي حجمونو لپاره مالتړ چمتو کړي. په دې توګه د کارولو امکان لري خپلمنځي جوړښتونه: ترتیبات، رازونه، د پیژندنې ډاټا، متغیرات، او داسې نور. د CSI ډرایورونه باید د دې Kubernetes خصوصیت مالتړ لپاره تعدیل شي، ځکه چې داسې انګیرل کیږي چې منظم معیاري چلونکي به کار ونکړي - مګر داسې انګیرل کیږي چې دا ډول حجمونه د پوډ لپاره غوره شوي هر نوډ کې کارول کیدی شي.

دا ممکن د حجمونو لپاره ستونزه وي چې د پام وړ کوربه سرچینې مصرفوي یا د ذخیره کولو لپاره چې یوازې په ځینو میزبانونو کې شتون لري. له همدې امله Kubernetes 1.19 د الفا ازموینې حجم دوه نوي ځانګړتیاوې معرفي کوي چې په تصور کې د EmptyDir حجمونو سره ورته دي:

  • د عمومي هدف لنډمهاله حجم؛

  • د CSI ذخیره کولو ظرفیت تعقیب.

د نوې تګلارې ګټې:

  • ذخیره کولی شي ځایی وي یا د شبکې له لارې وصل شي؛

  • حجمونه کولی شي مشخص اندازه ولري چې د غوښتنلیک لخوا نشي تیریدلی؛

  • د هر CSI ډرایور سره کار کوي چې د دوامداره حجمونو چمتو کولو ملاتړ کوي او (د ظرفیت تعقیب ملاتړ کولو لپاره) زنګ پلي کوي GetCapacity;

  • حجم ممکن د چلوونکي او ترتیباتو پورې اړه ولري ځینې لومړني معلومات ولري؛

  • ټول معیاري عملیات د حجم سره (د سنیپ شاټ رامینځته کول ، د اندازې بدلول او داسې نور) ملاتړ کیږي؛

  • حجمونه د هر غوښتنلیک کنټرولر سره کارول کیدی شي چې ماډل یا حجم مشخصات مني؛

  • د Kubernetes مهالویش کونکی پخپله مناسب نوډونه غوره کوي، نو نور اړتیا نشته چې د مهالویش توسیع تنظیم او تنظیم کړئ یا د ویب هکونو ترمیم کړئ.

د غوښتنلیک اختیارونه

له همدې امله، د عمومي هدف لنډمهاله حجمونه د لاندې کارولو قضیو لپاره مناسب دي:

دوامداره حافظه د memcached لپاره د RAM لپاره د بدیل په توګه

د memcached وروستي خپرونه اضافه ملاتړ د دوامداره حافظې کارول (Intel Optane، او نور، نږدې ژباړن) د منظم رام پرځای. کله چې د اپلیکیشن کنټرولر له لارې memcached ځای په ځای کول ، تاسو کولی شئ د عمومي هدف لنډیز حجم وکاروئ ترڅو غوښتنه وکړئ چې د ورکړل شوي اندازې حجم د PMEM څخه د CSI ډرایور په کارولو سره تخصیص شي ، د مثال په توګه PMEM-CSI.

LVM ځایی ذخیره د کاري ځای په توګه

هغه غوښتنلیکونه چې د ډیټا سره کار کوي چې د RAM څخه لوی وي ممکن د اندازې یا فعالیت میټریکونو سره محلي ذخیره کولو ته اړتیا ولري چې د Kubernetes څخه د EmptyDir منظم حجم نشي چمتو کولی. د مثال په توګه، دا د دې هدف لپاره لیکل شوی و TopoLVM.

د معلوماتو حجمونو لپاره یوازې لوستلو لاسرسی

د حجم تخصیص کولی شي د بشپړ حجم رامینځته کولو پایله ولري کله چې:

دا حجمونه یوازې د لوستلو حالت کې نصب کیدی شي.

دا څنګه کار کوي؟

عمومي هدف لنډمهاله حجمونه

د عمومي هدف لنډمهاله حجمونو کلیدي ځانګړتیا د نوي حجم سرچینه ده، EphemeralVolumeSource، د حجم غوښتنې رامینځته کولو لپاره ټولې ساحې لري (په تاریخي ډول د دوامداره حجم غوښتنې په نوم یادیږي ، PVC). نوی کنټرولر داخل شو kube-controller-manager پوډونو ته ګوري چې دا ډول حجم سرچینه رامینځته کوي ، او بیا د دې پوډونو لپاره PVC رامینځته کوي. د CSI ډرایور لپاره، دا غوښتنه د نورو په څیر ښکاري، نو دلته کوم ځانګړي ملاتړ ته اړتیا نشته.

تر هغه چې دا ډول PVC شتون ولري، دوی په حجم کې د نورو غوښتنو په څیر کارول کیدی شي. په ځانګړې توګه، دوی د معلوماتو سرچینې په توګه راجع کیدی شي کله چې د حجم کاپي کول یا د حجم څخه سنیپ شاټ رامینځته کول. د PVC څیز هم د حجم اوسنی حالت لري.

په اتوماتيک ډول جوړ شوي PVCs نومونه مخکې تعریف شوي دي: دا د پوډ نوم او د حجم نوم ترکیب دی، د هایفین لخوا جلا شوی. مخکې ټاکل شوي نومونه د PVC سره اړیکه اسانه کوي ځکه چې تاسو اړتیا نلرئ د هغې په لټه کې شئ که تاسو د پوډ نوم او حجم نوم پیژنئ. نیمګړتیا دا ده چې نوم ممکن دمخه په کارولو کې وي ، کوم چې د کوبرنیټس لخوا کشف شوی او په پایله کې پوډ د پیل کولو څخه بند شوی دی.

د دې لپاره چې ډاډ ترلاسه شي چې حجم د پوډ سره حذف شوی ، کنټرولر د مالک لاندې حجم ته غوښتنه کوي. کله چې پوډ حذف شي، د معیاري کثافاتو راټولولو میکانیزم کار کوي، کوم چې غوښتنه او حجم دواړه حذفوي.

غوښتنې د ذخیره کولو ټولګي د نورمال میکانیزم له لارې د ذخیره چلونکي لخوا سره سمون لري. که څه هم ټولګي د فوري او ناوخته پابندۍ سره (aka WaitForFirstConsumer) ملاتړ کیږي، د لنډمهاله حجمونو لپاره دا د کارولو لپاره معنی لري WaitForFirstConsumer، بیا مهالویش کوونکی کولی شي د نوډ غوره کولو په وخت کې د نوډ کارول او د ذخیره کولو شتون دواړه په پام کې ونیسي. یو نوی خصوصیت دلته څرګندیږي.

د ذخیره کولو ظرفیت تعقیب

په عموم ډول مهالویش کونکی پدې نه پوهیږي چې چیرې د CSI ډرایور به حجم رامینځته کړي. د مهالویش کونکي لپاره هیڅ لاره هم شتون نلري چې د دې معلوماتو غوښتنه کولو لپاره مستقیم له ډرایور سره اړیکه ونیسي. له همدې امله، مهالویش کوونکی تر هغه وخته پورې ټولپوښتنه کوي تر څو چې یو داسې ونه موندل شي چې په کومو حجمونو ته لاسرسی پیدا کیدی شي (ناوخته پابند) یا د ځای انتخاب په بشپړه توګه ډرایور ته پریږدي (سمدستي پابند).

نوی API CSIStorageCapacity، کوم چې په الفا مرحله کې دی ، اړین معلومات په etcd کې زیرمه کولو ته اجازه ورکوي ترڅو دا مهالویش کونکي ته شتون ولري. د عمومي هدف لنډمهاله حجمونو لپاره د ملاتړ برخلاف ، کله چې تاسو ډرایور ځای په ځای کړئ ، تاسو باید د ذخیره کولو ظرفیت تعقیب فعال کړئ: external-provisioner باید د ډرایور څخه ترلاسه شوي ظرفیت معلومات په نورمال ډول خپاره کړي GetCapacity.

که مهالویش کونکی اړتیا ولري د پوډ لپاره یو نوډ غوره کړي چې د غیر محدود حجم سره وي چې ناوخته پابندۍ کاروي ، او ډرایور د بیرغ په ترتیب کولو سره د ځای په ځای کولو پرمهال دا خصوصیت فعال کړی. CSIDriver.storageCapacity، بیا نوډونه چې د ذخیره کولو کافي ظرفیت نلري په اوتومات ډول له مینځه وړل کیږي. دا دواړه د عمومي هدف لنډمهاله او دوامداره حجمونو لپاره کار کوي ، مګر د CSI لنډمهاله حجمونو لپاره نه ځکه چې د دوی پیرامیټرې د کوبرنیټس لخوا نشي لوستل کیدی.

د معمول په څیر، سمدلاسه تړل شوي حجمونه مخکې له دې چې پوډونه مهالویش شي رامینځته کیږي، او د دوی ځای پرځای کول د ذخیره ډرایور لخوا غوره کیږي، نو کله چې تنظیم کول external-provisioner د ډیفالټ په واسطه، د سمدستي پابندۍ سره د ذخیره کولو ټولګي پریښودل شوي، ځکه چې دا ډاټا به په هیڅ صورت کې نه کارول کیږي.

څرنګه چې د کبرنیټس مهالویش کونکی مجبور دی چې د احتمالي تاریخ څخه تیر شوي معلوماتو سره کار وکړي ، هیڅ تضمین شتون نلري چې ظرفیت به په هر حالت کې شتون ولري کله چې حجم رامینځته کیږي ، مګر دا چانس چې دا به د بیا تکرار پرته رامینځته شي بیا هم ډیر شوي.

NB تاسو کولی شئ نور تفصيلي معلومات ترلاسه کړئ، په بیله بیا په خوندي توګه "د پیشوګانو په موقف کې تمرین وکړئ"، او د بشپړ نه پوهیدو وړ وضعیت په صورت کې، په جدي کورسونو کې د وړ تخنیکي مالتړ مرستې ترلاسه کړئ - د کوبرنیټس بیس به د سپتمبر په 28-30 کې ترسره شي، او د نورو پرمختللو متخصصینو لپاره Kubernetes Mega د اکتوبر 14-16

امنیت

CSISstorageCapacity

د CSIStorageCapacity توکي په نوم ځایونو کې اوسیږي؛ کله چې هر CSI ډرایور په خپل نوم ځای کې راوباسي، نو سپارښتنه کیږي چې په هغه ځای کې د CSIStorageCapacity لپاره د RBAC حقونه محدود کړي، ځکه چې دا څرګنده ده چې ډاټا له کوم ځای څخه راځي. Kubernetes په هرصورت د دې لپاره نه ګوري، او معمولا ډرایورونه په ورته نوم ځای کې ایښودل کیږي، نو بالاخره له ډرایورانو څخه تمه کیږي چې کار وکړي او غلط معلومات خپاره نه کړي (او دا هغه ځای دی چې زما کارت ناکام شو، نږدې ژباړن د ږیرې ټوکې پر بنسټ)

عمومي هدف لنډمهاله حجمونه

که چیرې کاروونکي د پوډ رامینځته کولو حق ولري (مستقیم یا غیر مستقیم) ، دوی به وکولی شي د عمومي هدف لنډیز حجمونه رامینځته کړي حتی که دوی په حجم کې د غوښتنې رامینځته کولو حق نلري. دا ځکه چې د RBAC اجازې چیکونه په کنټرولر کې پلي کیږي چې PVC رامینځته کوي ، نه کارونکي ته. دا د اضافه کولو اصلي بدلون دی ستاسو حساب ته, مخکې له دې چې دا فیچر په کلسترونو کې فعال کړئ چیرې چې بې باوره کاروونکي باید د حجمونو جوړولو حق ونه لري.

بېلګه:

جلا څانګه PMEM-CSI د الفا مرحله کې د ټولو ځانګړتیاو سره د QEMU مجازی ماشینونو دننه د Kubernetes 1.19 کلستر چلولو لپاره ټول اړین بدلونونه لري. د موټر چلوونکي کوډ نه دی بدل شوی، یوازې ځای پرځای کول بدل شوي.

په یو مناسب ماشین کې (لینکس، یو عادي کاروونکي کولی شي کار واخلي ډاکر، وګوره دلته توضیحات) دا کمانډونه به کلستر راوړي او د PMEM-CSI ډرایور به نصب کړي:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh

وروسته له دې چې هرڅه کار کوي، محصول به د کارولو لپاره لارښوونې ولري:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in.  Alternatively, use kubectl directly with the
following env variable:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

د CSISstorageCapacity توکي د دې لپاره ندي چې د انسانانو لخوا لوستل شي، نو ځینې پروسس کولو ته اړتیا ده. د ګولنګ ټیمپلیټ فلټرونه به د ذخیره کولو ټولګي وښیې، دا مثال به نوم، ټوپولوژي او ظرفیت وښيي:

$ kubectl get 
        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}' 
        csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

یو واحد شی لاندې مواد لري:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Name:         csisc-sqdnt
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  storage.k8s.io/v1alpha1
Capacity:     30716Mi
Kind:         CSIStorageCapacity
Metadata:
  Creation Timestamp:  2020-08-11T15:41:03Z
  Generate Name:       csisc-
  Managed Fields:
    ...
  Owner References:
    API Version:     apps/v1
    Controller:      true
    Kind:            StatefulSet
    Name:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Resource Version:  2994
  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Storage Class Name:           pmem-csi-sc-late-binding
Events:                       <none>

راځئ هڅه وکړو چې د یو واحد عمومي هدف لنډیز حجم سره د ډیمو غوښتنلیک رامینځته کړئ. د فایل منځپانګې pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: intel/pmem-csi-driver-test:v0.7.14
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 4Gi
          storageClassName: pmem-csi-sc-late-binding

د جوړولو وروسته، لکه څنګه چې په پورته لارښوونو کې ښودل شوي، موږ اوس یو اضافي پوډ او PVC لرو:

$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

د PVC مالک - لاندې:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
  creationTimestamp: "2020-08-11T15:44:57Z"
  finalizers:
  - kubernetes.io/pvc-protection
  managedFields:
    ...
  name: my-csi-app-inline-volume-my-csi-volume
  namespace: default
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Pod
    name: my-csi-app-inline-volume
    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...

په تمه تازه شوي معلومات لپاره pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

که بل غوښتنلیک له 26620Mi څخه ډیر ته اړتیا ولري ، مهالویش به په پام کې ونه نیسي pmem-csi-pmem-govm-worker1 په هر حال.

څه راتلونکو؟

دواړه ځانګړتیاوې لاهم د پراختیا په حال کې دي. د الفا ازموینې په جریان کې ډیری غوښتنلیکونه پرانستل شوي. د پرمختګ وړاندیز لینکونه هغه کار مستند کوي چې د بیټا مرحلې ته د تللو لپاره باید ترسره شي، او همدارنګه کوم بدیلونه دمخه په پام کې نیول شوي او رد شوي دي:

سرچینه: www.habr.com

Add a comment