🥇 حجم های زودگذر با ردیابی ظرفیت ذخیره سازی: EmptyDir در استروئیدها

برخی از برنامه ها نیز نیاز به ذخیره داده دارند، اما با این واقعیت که داده ها پس از راه اندازی مجدد ذخیره نمی شوند، کاملا راحت هستند.

برای مثال، سرویس‌های کش توسط RAM محدود می‌شوند، اما همچنین می‌توانند داده‌هایی را که به ندرت استفاده می‌شوند به ذخیره‌سازی کندتر از RAM منتقل کنند و تأثیر کمی بر عملکرد کلی داشته باشند. سایر برنامه‌ها باید بدانند که ممکن است مقداری ورودی فقط خواندنی در فایل‌ها وجود داشته باشد، مانند تنظیمات یا کلیدهای مخفی.

Kubernetes قبلاً چندین نوع دارد حجم های زودگذر، اما عملکرد آنها محدود به آنچه در K8s پیاده سازی شده است.

زودگذر مجلدات CSI به Kubernetes اجازه داد تا با درایورهای CSI توسعه یابد تا از حجم های محلی سبک پشتیبانی کند. به این ترتیب امکان استفاده وجود دارد ساختارهای دلخواه: تنظیمات، اسرار، داده های شناسایی، متغیرها و غیره. درایورهای CSI باید برای پشتیبانی از این ویژگی Kubernetes اصلاح شوند، زیرا فرض بر این است که درایورهای استاندارد معمولی کار نمی کنند - اما فرض بر این است که چنین حجم هایی را می توان در هر گره انتخاب شده برای pod استفاده کرد.

این ممکن است برای حجم هایی که منابع میزبان قابل توجهی را مصرف می کنند یا برای ذخیره سازی که فقط در برخی از هاست ها در دسترس است مشکل باشد. به همین دلیل است که Kubernetes 1.19 دو ویژگی جدید حجم تست آلفا را معرفی می کند که از نظر مفهومی شبیه به حجم های EmptyDir هستند:

حجم های زودگذر با هدف عمومی;
ردیابی ظرفیت ذخیره سازی CSI

مزایای رویکرد جدید:

ذخیره سازی می تواند محلی باشد یا از طریق شبکه متصل شود.
حجم ها می توانند اندازه مشخصی داشته باشند که برنامه نمی تواند از آن بیشتر شود.
با هر درایور CSI کار می کند که از ارائه حجم های پایدار پشتیبانی می کند و (برای پشتیبانی از ردیابی ظرفیت) تماس را اجرا می کند GetCapacity;
بسته به درایور و تنظیمات، حجم ممکن است دارای برخی از داده های اولیه باشد.
تمام عملیات استاندارد با حجم (ایجاد یک عکس فوری، تغییر اندازه و غیره) پشتیبانی می شود.
ولوم ها را می توان با هر برنامه کاربردی کنترل کننده ای که یک ماژول یا مشخصات حجم را می پذیرد استفاده کرد.
زمان‌بند Kubernetes گره‌های مناسب را به تنهایی انتخاب می‌کند، بنابراین دیگر نیازی به تهیه و پیکربندی پسوندهای زمان‌بندی یا اصلاح وبکهک‌ها نیست.

گزینه های برنامه

بنابراین، حجم های زودگذر با هدف عمومی برای موارد استفاده زیر مناسب هستند:

حافظه پایدار به عنوان جایگزینی برای RAM برای memcached

آخرین نسخه های memcached پشتیبانی اضافه شد با استفاده از حافظه پایدار (Intel Optane و غیره، تقریبا مترجم) به جای رم معمولی. هنگام استقرار memcached از طریق یک کنترل‌کننده برنامه، می‌توانید از حجم‌های زودگذر عمومی برای درخواست تخصیص حجمی با اندازه معین از PMEM با استفاده از درایور CSI استفاده کنید. PMEM-CSI.

ذخیره سازی محلی LVM به عنوان یک فضای کاری

برنامه‌هایی که با داده‌های بزرگ‌تر از RAM کار می‌کنند ممکن است به ذخیره‌سازی محلی با اندازه یا معیارهای عملکردی نیاز داشته باشند که حجم‌های معمولی EmptyDir از Kubernetes نمی‌توانند ارائه کنند. مثلا برای این منظور نوشته شد TopoLVM.

دسترسی فقط خواندنی برای حجم داده ها

تخصیص یک جلد می تواند منجر به ایجاد یک جلد کامل شود زمانی که:

این حجم ها را می توان در حالت فقط خواندنی نصب کرد.

چطور کار می کند؟

حجم های زودگذر با هدف عمومی

یکی از ویژگی های کلیدی حجم های زودگذر عمومی، منبع حجم جدید است، EphemeralVolumeSource، شامل تمام فیلدها برای ایجاد یک درخواست حجم (که از لحاظ تاریخی درخواست حجم مداوم، PVC نامیده می شود). کنترلر جدید در kube-controller-manager به غلاف هایی که چنین منبع حجمی را ایجاد می کنند نگاه می کند و سپس یک PVC برای آن غلاف ها ایجاد می کند. برای درایور CSI، این درخواست مانند سایر درخواست ها به نظر می رسد، بنابراین در اینجا به پشتیبانی خاصی نیاز نیست.

تا زمانی که چنین PVC وجود دارد، می توان از آنها مانند هر درخواست دیگری در حجم استفاده کرد. به طور خاص، هنگام کپی کردن یک جلد یا ایجاد یک عکس فوری از یک جلد، می توان به آنها به عنوان منبع داده اشاره کرد. شی PVC همچنین شامل وضعیت فعلی حجم است.

نام PVC های ایجاد شده به طور خودکار از پیش تعریف شده است: آنها ترکیبی از نام غلاف و نام حجم هستند که با خط فاصله از هم جدا شده اند. نام‌های از پیش تعریف‌شده تعامل با PVC را آسان‌تر می‌کنند، زیرا اگر نام غلاف و نام حجم را می‌دانید، نیازی به جستجوی آن ندارید. نکته منفی این است که ممکن است نام قبلاً در حال استفاده باشد، که توسط Kubernetes شناسایی می شود و در نتیجه پاد از شروع مسدود می شود.

برای اطمینان از حذف ولوم به همراه پاد، کنترلر از ولوم تحت مالک درخواست می کند. هنگامی که غلاف حذف می شود، مکانیسم استاندارد جمع آوری زباله کار می کند، که هم درخواست و هم حجم را حذف می کند.

درخواست‌ها توسط درایور ذخیره‌سازی از طریق مکانیسم عادی کلاس ذخیره‌سازی مطابقت داده می‌شوند. اگرچه کلاس هایی با صحافی فوری و دیررس (معروف به WaitForFirstConsumer) پشتیبانی می شوند، برای حجم های زودگذر استفاده از آن منطقی است WaitForFirstConsumer، سپس زمانبندی می تواند هنگام انتخاب یک گره، استفاده از گره و در دسترس بودن ذخیره سازی را در نظر بگیرد. یک ویژگی جدید در اینجا ظاهر می شود.

ردیابی ظرفیت ذخیره سازی

معمولاً زمان‌بند اطلاعی از محل ایجاد حجم توسط درایور CSI ندارد. همچنین هیچ راهی برای زمانبندی وجود ندارد که مستقیماً با راننده تماس بگیرد تا این اطلاعات را درخواست کند. بنابراین، زمان‌بندی گره‌ها را تا زمانی که گره‌هایی را پیدا کند که می‌توان به حجم‌ها دسترسی پیدا کرد (صحافی دیرهنگام) یا انتخاب مکان را به طور کامل به راننده واگذار می‌کند (صحافی فوری).

جدید API CSIStorageCapacity، که در مرحله آلفا است، اجازه می دهد تا داده های لازم در etcd ذخیره شود تا در دسترس زمانبند باشد. بر خلاف پشتیبانی از حجم‌های زودگذر عمومی، وقتی درایور را نصب می‌کنید، باید ردیابی ظرفیت ذخیره‌سازی را فعال کنید: external-provisioner باید اطلاعات ظرفیت دریافتی از راننده را از طریق عادی منتشر کند GetCapacity.

اگر زمان‌بند نیاز به انتخاب گره‌ای برای یک پاد با حجم غیر محدود دارد که از اتصال دیرهنگام استفاده می‌کند، و درایور این ویژگی را در حین استقرار با تنظیم پرچم فعال کرده است. CSIDriver.storageCapacity، سپس گره هایی که ظرفیت ذخیره سازی کافی ندارند به طور خودکار دور ریخته می شوند. این هم برای حجم‌های زودگذر و هم برای حجم‌های دائمی با هدف عمومی کار می‌کند، اما برای حجم‌های زودگذر CSI نه، زیرا پارامترهای آن‌ها توسط Kubernetes قابل خواندن نیستند.

طبق معمول، حجم‌های مرتبط بلافاصله قبل از برنامه‌ریزی پادها ایجاد می‌شوند و محل قرارگیری آنها توسط درایور ذخیره‌سازی انتخاب می‌شود، بنابراین هنگام پیکربندی external-provisioner به‌طور پیش‌فرض، کلاس‌های ذخیره‌سازی با اتصال فوری حذف می‌شوند، زیرا به هر حال از این داده‌ها استفاده نمی‌شود.

از آنجایی که زمان‌بندی kubernetes مجبور است با اطلاعات بالقوه قدیمی کار کند، هیچ تضمینی وجود ندارد که در هر موردی که حجم ایجاد می‌شود، ظرفیت در دسترس باشد، اما شانس ایجاد آن بدون تلاش مجدد افزایش می‌یابد.

NB شما می توانید اطلاعات دقیق تر و همچنین با خیال راحت "تمرین روی پایه گربه ها" دریافت کنید و در صورت وضعیت کاملاً غیرقابل درک ، در دوره های فشرده از پشتیبانی فنی واجد شرایط دریافت کنید - پایگاه کوبرنتیس در تاریخ 28-30 سپتامبر و برای متخصصان پیشرفته تر برگزار می شود Kubernetes Mega 14 تا 16 اکتبر.

امنیت

ظرفیت CSIStorage

اشیاء CSIStorageCapacity در فضاهای نام قرار دارند؛ زمانی که هر درایور CSI را در فضای نام خود منتشر می‌کنید، توصیه می‌شود حقوق RBAC را به CSIStorageCapacity در آن فضا محدود کنید، زیرا مشخص است که داده‌ها از کجا می‌آیند. Kubernetes به هر حال این مورد را بررسی نمی‌کند، و معمولا درایورها در فضای نام یکسانی قرار می‌گیرند، بنابراین در نهایت انتظار می‌رود درایورها کار کنند و داده‌های نادرست را منتشر نکنند (و این جایی است که کارت من خراب شد، تقریبا مترجم بر اساس یک شوخی ریش دار)

حجم های زودگذر با هدف عمومی

اگر کاربران حق ایجاد یک پاد (مستقیم یا غیرمستقیم) را داشته باشند، حتی اگر حق ایجاد درخواست روی حجم را نداشته باشند، می‌توانند حجم‌های زودگذر با هدف عمومی ایجاد کنند. این به این دلیل است که بررسی های مجوز RBAC به کنترل کننده ای که PVC را ایجاد می کند اعمال می شود، نه برای کاربر. این تغییر اصلی برای اضافه کردن است به حساب شما، قبل از فعال کردن این ویژگی در خوشه هایی که کاربران غیرقابل اعتماد نباید حق ایجاد حجم را داشته باشند.

مثال

جداگانه، مجزا شاخه PMEM-CSI شامل تمام تغییرات لازم برای اجرای یک خوشه Kubernetes 1.19 در داخل ماشین های مجازی QEMU با تمام ویژگی ها در مرحله آلفا است. کد راننده تغییر نکرده است، فقط استقرار تغییر کرده است.

در یک ماشین مناسب (لینوکس، یک کاربر عادی می تواند استفاده کند کارگر بارانداز، نگاه کن اینجا جزئیات) این دستورات خوشه را نمایش می دهند و درایور 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 -

اشیاء CSIStorageCapacity قرار نیست توسط انسان خوانده شوند، بنابراین مقداری پردازش مورد نیاز است. فیلترهای قالب Golang کلاس های ذخیره سازی را نشان می دهد، این مثال نام، توپولوژی و ظرفیت را نشان می دهد:

$ 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

حجم های زودگذر با ردیابی ظرفیت ذخیره سازی: EmptyDir در استروئیدها

گزینه های برنامه

حافظه پایدار به عنوان جایگزینی برای RAM برای memcached

ذخیره سازی محلی LVM به عنوان یک فضای کاری

دسترسی فقط خواندنی برای حجم داده ها

چطور کار می کند؟

حجم های زودگذر با هدف عمومی

ردیابی ظرفیت ذخیره سازی

امنیت

ظرفیت CSIStorage

حجم های زودگذر با هدف عمومی

مثال

گام بعدی چیست؟

اضافه کردن نظر انصراف از پاسخ