🥇 سٹوریج کی صلاحیت سے باخبر رہنے کے ساتھ مختصر حجم: سٹیرائڈز پر EmptyDir

کچھ ایپلی کیشنز کو ڈیٹا اسٹور کرنے کی بھی ضرورت ہوتی ہے، لیکن وہ اس حقیقت سے کافی آرام دہ ہیں کہ دوبارہ شروع ہونے کے بعد ڈیٹا محفوظ نہیں ہوگا۔

مثال کے طور پر، کیشنگ سروسز RAM کے ذریعے محدود ہیں، لیکن وہ ڈیٹا کو بھی منتقل کر سکتی ہیں جو شاذ و نادر ہی اسٹوریج کے لیے استعمال ہوتا ہے جو کہ RAM سے سست ہے، جس کا مجموعی کارکردگی پر بہت کم اثر پڑتا ہے۔ دیگر ایپلیکیشنز کو اس بات سے آگاہ کرنے کی ضرورت ہے کہ فائلوں میں کچھ صرف پڑھنے کے لیے ان پٹ ہو سکتے ہیں، جیسے کہ سیٹنگز یا خفیہ کلید۔

Kubernetes پہلے سے ہی کئی اقسام ہیں عارضی حجم، لیکن ان کی فعالیت صرف اس تک محدود ہے جو K8s میں نافذ ہے۔

عارضی CSI والیوم ہلکے وزن کے مقامی حجم کے لیے سپورٹ فراہم کرنے کے لیے Kubernetes کو CSI ڈرائیوروں کے ساتھ بڑھانے کی اجازت دی گئی۔ اس طرح استعمال کرنا ممکن ہے۔ صوابدیدی ڈھانچے: ترتیبات، راز، شناختی ڈیٹا، متغیرات، وغیرہ۔ اس Kubernetes فیچر کو سپورٹ کرنے کے لیے CSI ڈرائیورز میں ترمیم کی جانی چاہیے، کیونکہ باقاعدہ معیاری ڈرائیوروں سے کام کرنے کی توقع نہیں کی جاتی ہے - لیکن اس طرح کی جلدیں پوڈ کے لیے منتخب کیے گئے کسی بھی نوڈ پر قابل استعمال ہونے کی توقع کی جاتی ہے۔

یہ ان حجموں کے لیے ایک مسئلہ ہو سکتا ہے جو اہم میزبان وسائل استعمال کرتے ہیں یا اسٹوریج کے لیے جو صرف کچھ میزبانوں پر دستیاب ہے۔ اسی لیے Kubernetes 1.19 نے الفا ٹیسٹنگ والیوم کی دو نئی خصوصیات متعارف کرائی ہیں جو تصوراتی طور پر EmptyDir والیوم سے ملتی جلتی ہیں:

عام مقصد کے عارضی حجم؛
CSI اسٹوریج کی صلاحیت سے باخبر رہنا۔

نئے طریقہ کار کے فوائد:

اسٹوریج مقامی یا نیٹ ورک کے ذریعے منسلک ہو سکتا ہے؛
جلدوں کا ایک مخصوص سائز ہو سکتا ہے جسے ایپلیکیشن سے زیادہ نہیں کیا جا سکتا۔
کسی بھی CSI ڈرائیور کے ساتھ کام کرتا ہے جو مستقل والیوم کی فراہمی کی حمایت کرتا ہے اور (کیپیسٹی ٹریکنگ کو سپورٹ کرنے کے لیے) کال کو لاگو کرتا ہے۔ GetCapacity;
حجم میں ڈرائیور اور سیٹنگز کے لحاظ سے کچھ ابتدائی ڈیٹا ہو سکتا ہے۔
حجم کے ساتھ تمام معیاری آپریشنز (اسنیپ شاٹ بنانا، سائز تبدیل کرنا وغیرہ) تعاون یافتہ ہیں۔
حجم کو کسی بھی ایپلیکیشن کنٹرولر کے ساتھ استعمال کیا جا سکتا ہے جو ماڈیول یا حجم کی تفصیلات کو قبول کرتا ہو۔
Kubernetes شیڈیولر اپنے طور پر مناسب نوڈس کا انتخاب کرتا ہے، لہذا آپ کو شیڈولر ایکسٹینشن کی فراہمی اور ترتیب دینے اور ویب ہکس کو تبدیل کرنے کی ضرورت نہیں ہے۔

درخواست کے اختیارات

لہٰذا، عام مقصد کے عارضی حجم درج ذیل استعمال کے معاملات کے لیے موزوں ہیں:

میم کیچڈ کے لیے RAM کے متبادل کے طور پر مستقل میموری

memcached کی تازہ ترین ریلیز شامل کی حمایت مستقل میموری کا استعمال کرتے ہوئے (انٹیل آپٹین، وغیرہ، تقریبا. مترجم) باقاعدہ RAM کے بجائے۔ ایپلیکیشن کنٹرولر کے ذریعے میمکیچڈ کو تعینات کرتے وقت، آپ عام مقصد کے عارضی حجم کا استعمال کرتے ہوئے درخواست کر سکتے ہیں کہ سی ایس آئی ڈرائیور کا استعمال کرتے ہوئے PMEM سے کسی مخصوص سائز کا حجم مختص کیا جائے، مثال کے طور پر PMEM-CSI.

LVM لوکل اسٹوریج بطور ورک اسپیس

RAM سے بڑے ڈیٹا کے ساتھ کام کرنے والی ایپلیکیشنز کو سائز یا کارکردگی کے میٹرکس کے ساتھ مقامی اسٹوریج کی ضرورت ہو سکتی ہے جو Kubernetes سے EmptyDir والیوم فراہم نہیں کر سکتی۔ مثلاً اس مقصد کے لیے لکھا گیا۔ TopoLVM.

ڈیٹا والیوم کے لیے صرف پڑھنے کی رسائی

حجم کی تقسیم کے نتیجے میں مکمل حجم کی تخلیق ہو سکتی ہے جب:

ان جلدوں کو صرف پڑھنے کے موڈ میں نصب کیا جا سکتا ہے۔

یہ کیسے کام کرتا ہے

عام مقصد کے مختصر حجم

عام مقصد کے عارضی جلدوں کی ایک اہم خصوصیت نئے حجم کا ذریعہ ہے، EphemeralVolumeSource, حجم کی درخواست بنانے کے لیے تمام فیلڈز پر مشتمل ہے (تاریخی طور پر ایک مستقل والیوم کی درخواست، PVC کہا جاتا ہے)۔ میں نیا کنٹرولر kube-controller-manager ان پوڈز کو دیکھتا ہے جو اس طرح کے حجم کا ذریعہ بناتے ہیں، اور پھر ان پوڈز کے لیے پیویسی بناتا ہے۔ CSI ڈرائیور کے لیے، یہ درخواست دوسروں کی طرح ہی نظر آتی ہے، اس لیے یہاں کسی خاص تعاون کی ضرورت نہیں ہے۔

جب تک اس طرح کے PVC موجود ہیں، وہ حجم پر کسی بھی دوسری درخواست کی طرح استعمال کیے جا سکتے ہیں۔ خاص طور پر، کسی والیوم کو کاپی کرتے وقت یا والیوم سے سنیپ شاٹ بناتے وقت انہیں ڈیٹا سورس کے طور پر حوالہ دیا جا سکتا ہے۔ پیویسی آبجیکٹ میں حجم کی موجودہ حالت بھی ہوتی ہے۔

خود بخود تخلیق شدہ PVCs کے نام پہلے سے طے شدہ ہیں: وہ پوڈ کے نام اور حجم کے نام کا مجموعہ ہیں، جو ایک ہائفن سے الگ ہوتے ہیں۔ پہلے سے طے شدہ نام PVC کے ساتھ بات چیت کرنا آسان بناتے ہیں کیونکہ اگر آپ پوڈ کا نام اور حجم کا نام جانتے ہیں تو آپ کو اسے تلاش کرنے کی ضرورت نہیں ہے۔ منفی پہلو یہ ہے کہ یہ نام پہلے سے استعمال میں ہو سکتا ہے، جس کا پتہ کبرنیٹس نے لگایا ہے اور اس کے نتیجے میں پوڈ کو شروع ہونے سے روک دیا گیا ہے۔

اس بات کو یقینی بنانے کے لیے کہ والیوم کو پوڈ کے ساتھ حذف کر دیا گیا ہے، کنٹرولر مالک کے نیچے والیوم سے درخواست کرتا ہے۔ جب پوڈ کو حذف کر دیا جاتا ہے، تو معیاری کوڑا اٹھانے کا طریقہ کار کام کرتا ہے، جو درخواست اور حجم دونوں کو حذف کر دیتا ہے۔

سٹوریج ڈرائیور کے ذریعہ سٹوریج کلاس کے نارمل طریقہ کار کے ذریعے درخواستوں کو ملایا جاتا ہے۔ اگرچہ فوری اور دیر سے بائنڈنگ والی کلاسز (عرف WaitForFirstConsumer) تعاون یافتہ ہیں، عارضی جلدوں کے لیے اس کا استعمال کرنا سمجھ میں آتا ہے۔ WaitForFirstConsumer، پھر شیڈیولر نوڈ کا انتخاب کرتے وقت نوڈ کے استعمال اور اسٹوریج کی دستیابی دونوں پر غور کر سکتا ہے۔ ایک نئی خصوصیت یہاں ظاہر ہوتی ہے۔

اسٹوریج کی صلاحیت سے باخبر رہنا

عام طور پر شیڈیولر کو اس بات کا کوئی علم نہیں ہوتا ہے کہ CSI ڈرائیور والیوم کہاں بنائے گا۔ شیڈولر کے لیے اس معلومات کی درخواست کرنے کے لیے ڈرائیور سے براہ راست رابطہ کرنے کا بھی کوئی طریقہ نہیں ہے۔ لہذا، شیڈیولر اس وقت تک نوڈز کو پول کرتا ہے جب تک کہ اسے کوئی ایسی والیوم نہ مل جائے جس تک رسائی حاصل کی جاسکتی ہے (دیر سے بائنڈنگ) یا مقام کا انتخاب مکمل طور پر ڈرائیور (فوری بائنڈنگ) پر چھوڑ دیتا ہے۔

نئی API CSIStorageCapacityجو کہ الفا مرحلے میں ہے، ضروری ڈیٹا کو etcd میں ذخیرہ کرنے کی اجازت دیتا ہے تاکہ یہ شیڈولر کے لیے دستیاب ہو۔ عام مقصد کے عارضی حجم کے لیے سپورٹ کے برعکس، جب آپ ڈرائیور کو تعینات کرتے ہیں، تو آپ کو سٹوریج کی گنجائش سے باخبر رہنے کو فعال کرنا چاہیے: external-provisioner ڈرائیور سے موصول ہونے والی صلاحیت کی معلومات کو نارمل کے ذریعے شائع کرنا چاہیے۔ GetCapacity.

اگر شیڈیولر کو ایک پوڈ کے لیے ایک نوڈ منتخب کرنے کی ضرورت ہے جس میں ان باؤنڈ والیوم ہے جو لیٹ بائنڈنگ کا استعمال کرتا ہے، اور ڈرائیور نے فلیگ سیٹ کرکے تعیناتی کے دوران اس فیچر کو فعال کیا ہے۔ CSIDriver.storageCapacity، پھر نوڈس جن میں کافی ذخیرہ کرنے کی گنجائش نہیں ہے وہ خود بخود ضائع ہو جائیں گے۔ یہ عام مقصد کے عارضی اور مستقل حجم دونوں کے لیے کام کرتا ہے، لیکن CSI فیمرل جلدوں کے لیے نہیں کیونکہ ان کے پیرامیٹرز کوبرنیٹس پڑھ نہیں سکتے۔

ہمیشہ کی طرح، پوڈز کے شیڈول ہونے سے پہلے فوری طور پر منسلک جلدیں بنائی جاتی ہیں، اور ان کی جگہ کا انتخاب سٹوریج ڈرائیور کرتا ہے، اس لیے ترتیب دیتے وقت external-provisioner بطور ڈیفالٹ، فوری بائنڈنگ والی سٹوریج کلاسز کو چھوڑ دیا جاتا ہے، کیونکہ یہ ڈیٹا بہرحال استعمال نہیں کیا جائے گا۔

چونکہ kubernetes شیڈیولر کو ممکنہ طور پر پرانی معلومات کے ساتھ کام کرنے پر مجبور کیا جاتا ہے، اس لیے اس بات کی کوئی گارنٹی نہیں ہے کہ حجم تخلیق ہونے پر ہر صورت میں صلاحیت دستیاب ہوگی، لیکن اس کے باوجود دوبارہ کوششوں کے بنائے جانے کے امکانات بڑھ گئے ہیں۔

این بی آپ مزید تفصیلی معلومات حاصل کر سکتے ہیں، ساتھ ہی محفوظ طریقے سے "کیٹس اسٹینڈ پر مشق" کر سکتے ہیں، اور مکمل طور پر ناقابل فہم صورتحال کی صورت میں، انتہائی کورسز میں قابل تکنیکی مدد حاصل کر سکتے ہیں۔ کبرنیٹس بیس 28-30 ستمبر کو منعقد کیا جائے گا، اور مزید جدید ماہرین کے لیے کبرنیٹس میگا اکتوبر 14-16۔

سیکورٹی

CSISstorageCapacity

CSIStorageCapacity آبجیکٹ نام کی جگہوں میں رہتے ہیں؛ جب ہر CSI ڈرائیور کو اس کے اپنے نام کی جگہ میں رول آؤٹ کرتے ہیں، تو اس جگہ میں RBAC کے حقوق کو CSIStorageCapacity تک محدود کرنے کی سفارش کی جاتی ہے کیونکہ یہ واضح ہے کہ ڈیٹا کہاں سے آرہا ہے۔ کوبرنیٹس بہرحال اس کی جانچ نہیں کرتا ہے، اور عام طور پر ڈرائیوروں کو اسی نام کی جگہ پر رکھا جاتا ہے، لہذا بالآخر ڈرائیوروں سے توقع کی جاتی ہے کہ وہ کام کریں اور غلط ڈیٹا شائع نہ کریں (اور یہیں سے میرا کارڈ ناکام ہو گیا، تقریبا. داڑھی والے لطیفے پر مبنی مترجم)

عام مقصد کے مختصر حجم

اگر صارفین کے پاس پوڈ بنانے کے حقوق ہیں (براہ راست یا بالواسطہ)، تو وہ عام مقصد کی عارضی جلدیں بھی تخلیق کر سکیں گے چاہے ان کے پاس والیوم پر درخواست بنانے کے حقوق نہ ہوں۔ اس کی وجہ یہ ہے کہ RBAC اجازت کے چیک اس کنٹرولر پر لاگو ہوتے ہیں جو PVC بناتا ہے، صارف پر نہیں۔ یہ شامل کرنے کی اہم تبدیلی ہے۔ آپ کے اکاؤنٹ میں، اس خصوصیت کو کلسٹرز پر فعال کرنے سے پہلے جہاں ناقابل اعتماد صارفین کے پاس حجم بنانے کے حقوق نہیں ہونے چاہئیں۔

مثال کے طور پر

الگ شاخ PMEM-CSI میں الفا مرحلے میں تمام خصوصیات کے ساتھ QEMU ورچوئل مشینوں کے اندر Kubernetes 1.19 کلسٹر چلانے کے لیے تمام ضروری تبدیلیاں شامل ہیں۔ ڈرائیور کا کوڈ تبدیل نہیں ہوا ہے، صرف تعیناتی تبدیل ہوئی ہے۔

مناسب مشین پر (لینکس، ایک عام صارف استعمال کر سکتا ہے۔ میں Dockerدیکھو یہاں تفصیلات) یہ کمانڈز کلسٹر کو سامنے لائیں گے اور 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 &amp;&amp; echo &amp;&amp; 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

بنانے کے بعد، جیسا کہ اوپر دی گئی ہدایات میں دکھایا گیا ہے، اب ہمارے پاس ایک اضافی پوڈ اور پی وی سی ہے:

$ 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

پی وی سی مالک - کے تحت:

$ 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

سٹوریج کی صلاحیت سے باخبر رہنے کے ساتھ عارضی حجم: سٹیرائڈز پر EmptyDir

درخواست کے اختیارات

میم کیچڈ کے لیے RAM کے متبادل کے طور پر مستقل میموری

LVM لوکل اسٹوریج بطور ورک اسپیس

ڈیٹا والیوم کے لیے صرف پڑھنے کی رسائی

یہ کیسے کام کرتا ہے

عام مقصد کے مختصر حجم

اسٹوریج کی صلاحیت سے باخبر رہنا

سیکورٹی

CSISstorageCapacity

عام مقصد کے مختصر حجم

مثال کے طور پر

اس کے بعد کیا ہے؟

نیا تبصرہ شامل کریں جواب منسوخ کریں