भण्डारण क्षमता ट्र्याकिङको साथ अल्पकालीन भोल्युमहरू: स्टेरोइडहरूमा EmptyDir

केहि अनुप्रयोगहरूले पनि डाटा भण्डारण गर्न आवश्यक छ, तर तिनीहरू तथ्यसँग एकदम सहज छन् कि पुन: सुरु पछि डाटा बचत हुनेछैन।

उदाहरणका लागि, क्यासिङ सेवाहरू RAM द्वारा सीमित छन्, तर यसले समग्र कार्यसम्पादनमा थोरै प्रभाव पारेर RAM भन्दा ढिलो भएको भण्डारणमा दुर्लभ रूपमा प्रयोग हुने डाटा सार्न सक्छ। अन्य अनुप्रयोगहरूलाई सचेत हुन आवश्यक छ कि फाइलहरूमा केही पढ्ने-मात्र इनपुट हुन सक्छ, जस्तै सेटिङहरू वा गोप्य कुञ्जीहरू।

Kubernetes पहिले नै धेरै प्रकारहरू छन् क्षणिक मात्रा, तर तिनीहरूको कार्यक्षमता K8s मा लागू गरिएको कुरामा सीमित छ।

क्षणिक CSI भोल्युमहरू Kubernetes लाई CSI ड्राइभरहरूसँग विस्तार गर्न अनुमति दिईयो हल्का स्थानीय भोल्युमहरूको लागि समर्थन प्रदान गर्न। यसरी प्रयोग गर्न सम्भव छ मनमानी संरचनाहरू: सेटिङहरू, गोप्यहरू, पहिचान डाटा, चर, र यति। CSI ड्राइभरहरू यो Kubernetes सुविधालाई समर्थन गर्न परिमार्जन गर्नुपर्छ, किनकि यो मानिन्छ कि नियमित मानकीकृत ड्राइभरहरूले काम गर्दैनन् - तर यो मानिन्छ कि त्यस्ता भोल्युमहरू पोडको लागि चयन गरिएको कुनै पनि नोडमा प्रयोग गर्न सकिन्छ।

यो भोल्युमहरूको लागि समस्या हुन सक्छ जसले महत्त्वपूर्ण होस्ट स्रोतहरू खपत गर्दछ वा भण्डारणको लागि जुन केही होस्टहरूमा मात्र उपलब्ध छ। यसैले Kubernetes 1.19 ले दुई नयाँ अल्फा परीक्षण भोल्युम सुविधाहरू प्रस्तुत गर्दछ जुन अवधारणात्मक रूपमा EmptyDir भोल्युमहरूसँग मिल्दोजुल्दो छ:

• सामान्य उद्देश्य अल्पकालिक मात्रा;

• CSI भण्डारण क्षमता ट्र्याकिङ।

नयाँ दृष्टिकोणका फाइदाहरू:

• भण्डारण स्थानीय वा नेटवर्क मार्फत जडान हुन सक्छ;

• भोल्युमहरूमा निर्दिष्ट आकार हुन सक्छ जुन अनुप्रयोगले पार गर्न सक्दैन;

• कुनै पनि CSI ड्राइभरहरूसँग काम गर्दछ जसले निरन्तर भोल्युमहरूको प्रावधानलाई समर्थन गर्दछ र (क्षमता ट्र्याकिङलाई समर्थन गर्न) कल कार्यान्वयन गर्दछ। GetCapacity;

• भोल्युमहरूमा ड्राइभर र सेटिङहरूको आधारमा केही प्रारम्भिक डाटा हुन सक्छ;

• भोल्युमका साथ सबै मानक अपरेशनहरू (स्न्यापसट सिर्जना गर्ने, रिसाइज गर्ने, आदि) समर्थित छन्;

• भोल्युमहरू कुनै पनि अनुप्रयोग नियन्त्रकसँग प्रयोग गर्न सकिन्छ जसले मोड्युल वा भोल्युम विशिष्टता स्वीकार गर्दछ;

• Kubernetes अनुसूचक आफैले उपयुक्त नोडहरू चयन गर्दछ, त्यसैले अब अनुसूचक विस्तारहरू प्रावधान र कन्फिगर गर्न वा वेबहुकहरू परिमार्जन गर्न आवश्यक छैन।

अनुप्रयोग विकल्पहरू

तसर्थ, सामान्य उद्देश्य अल्पकालिक भोल्युमहरू निम्न प्रयोग केसहरूको लागि उपयुक्त छन्:

memcached को लागि RAM को प्रतिस्थापनको रूपमा स्थायी मेमोरी

Memcached को नवीनतम रिलीज समर्थन थपियो लगातार मेमोरी प्रयोग गर्दै (Intel Optane, आदि, लगभग। अनुवादक) नियमित RAM को सट्टा। एप्लिकेसन कन्ट्रोलर मार्फत मेमक्याच डिप्लोइ गर्दा, तपाईंले CSI ड्राइभर प्रयोग गरेर PMEM बाट दिइएको साइजको भोल्युम आवंटित गर्न अनुरोध गर्न सामान्य उद्देश्यका क्षणिक भोल्युमहरू प्रयोग गर्न सक्नुहुन्छ, उदाहरणका लागि। PMEM-CSI.

LVM स्थानीय भण्डारण कार्यस्थानको रूपमा

RAM भन्दा ठुलो डाटासँग काम गर्ने अनुप्रयोगहरूलाई आकार वा कार्यसम्पादन मेट्रिक्सको साथ स्थानीय भण्डारण चाहिन्छ जुन Kubernetes बाट नियमित EmptyDir भोल्युमहरू प्रदान गर्न सक्दैन। उदाहरणका लागि, यो उद्देश्यका लागि लेखिएको थियो TopoLVM.

डेटा भोल्युमहरूको लागि मात्र पढ्ने पहुँच

भोल्युमको आवंटनले पूर्ण भोल्युम सिर्जना गर्न सक्छ जब:

• पुनर्स्थापना भोल्युम स्न्यापसट;

• सिर्जना भोल्युम प्रतिलिपिहरू;

• काम गर्नुहोस् डाटा प्लेसहोल्डरहरू.

यी भोल्युमहरू पढ्ने मात्र मोडमा माउन्ट गर्न सकिन्छ।

यो कसरी काम गर्छ

सामान्य उद्देश्य अल्पकालिक भोल्युमहरू

सामान्य उद्देश्य अल्पकालिक भोल्युमहरूको मुख्य विशेषता नयाँ भोल्युम स्रोत हो, EphemeralVolumeSource, भोल्युम अनुरोध सिर्जना गर्नका लागि सबै क्षेत्रहरू समावेश गर्दै (ऐतिहासिक रूपमा निरन्तर भोल्युम अनुरोध, PVC भनिन्छ)। नयाँ नियन्त्रक मा kube-controller-manager यस्तो भोल्युम स्रोत सिर्जना गर्ने पोडहरू हेर्छ, र त्यसपछि ती पोडहरूको लागि PVC सिर्जना गर्दछ। CSI ड्राइभरको लागि, यो अनुरोध अरूहरू जस्तै देखिन्छ, त्यसैले यहाँ कुनै विशेष समर्थन आवश्यक पर्दैन।

जबसम्म यस्ता PVC हरू अवस्थित छन्, तिनीहरू भोल्युममा अन्य अनुरोधहरू जस्तै प्रयोग गर्न सकिन्छ। विशेष गरी, भोल्युम प्रतिलिपि गर्दा वा भोल्युमबाट स्न्यापसट सिर्जना गर्दा तिनीहरू डेटा स्रोतको रूपमा सन्दर्भ गर्न सकिन्छ। PVC वस्तुले भोल्युमको हालको अवस्था पनि समावेश गर्दछ।

स्वचालित रूपमा सिर्जना गरिएका PVC हरूका नामहरू पूर्वनिर्धारित छन्: तिनीहरू पोड नाम र भोल्युम नामको संयोजन हुन्, हाइफनद्वारा अलग गरिएको। पूर्वनिर्धारित नामहरूले PVC सँग अन्तर्क्रिया गर्न सजिलो बनाउँदछ किनभने यदि तपाईंलाई पोड नाम र भोल्युम नाम थाहा छ भने तपाईंले यसलाई खोज्नु पर्दैन। नकारात्मक पक्ष यो हो कि नाम पहिले नै प्रयोगमा हुन सक्छ, जुन Kubernetes द्वारा पत्ता लगाइएको छ र फलस्वरूप पोड सुरु हुनबाट रोकिएको छ।

भोल्युम पोडसँगै मेटाइएको छ भनी सुनिश्चित गर्न, नियन्त्रकले मालिक अन्तर्गत भोल्युमलाई अनुरोध गर्दछ। जब पोड मेटाइन्छ, मानक फोहोर संकलन संयन्त्रले काम गर्दछ, जसले अनुरोध र भोल्युम दुवै मेटाउँछ।

अनुरोधहरू भण्डारण कक्षाको सामान्य संयन्त्र मार्फत भण्डारण ड्राइभरद्वारा मेल खान्छ। यद्यपि तत्काल र ढिलो बन्धनका साथ कक्षाहरू (उर्फ WaitForFirstConsumer) समर्थित छन्, अल्पकालिक भोल्युमहरूको लागि यो प्रयोग गर्न अर्थ बनाउँछ WaitForFirstConsumer, त्यसपछि अनुसूचकले नोड चयन गर्दा नोड प्रयोग र भण्डारण उपलब्धता दुवैलाई विचार गर्न सक्छ। एउटा नयाँ सुविधा यहाँ देखिन्छ।

भण्डारण क्षमता ट्र्याकिङ

सामान्यतया अनुसूचकलाई CSI ड्राइभरले भोल्युम सिर्जना गर्ने ठाउँको कुनै ज्ञान हुँदैन। यो जानकारी अनुरोध गर्नको लागि ड्राइभरलाई सीधै सम्पर्क गर्ने समय तालिकाको लागि कुनै तरिका पनि छैन। त्यसकारण, अनुसूचकले भोल्युमहरू पहुँच गर्न सकिने (ढिलो बाइन्डिङ) वा स्थानको छनोट पूर्ण रूपमा ड्राइभरमा छोडेसम्म नोडहरू पोल गर्छ (तत्काल बाध्यकारी)।

नयाँ एपीआई CSIStorageCapacity, जुन अल्फा चरणमा छ, आवश्यक डाटा etcd मा भण्डारण गर्न अनुमति दिन्छ ताकि यो अनुसूचकमा उपलब्ध छ। सामान्य उद्देश्य अल्पकालिक भोल्युमहरूको लागि समर्थनको विपरीत, जब तपाइँ ड्राइभर तैनात गर्नुहुन्छ, तपाइँले भण्डारण क्षमता ट्र्याकिङ सक्षम गर्नुपर्छ: external-provisioner सामान्य मार्फत चालकबाट प्राप्त क्षमता जानकारी प्रकाशित गर्नुपर्छ GetCapacity.

यदि अनुसूचकले ढिलो बाइन्डिङ प्रयोग गर्ने अनबाउन्ड भोल्युमको साथ पोडको लागि नोड चयन गर्न आवश्यक छ भने, र ड्राइभरले झण्डा सेट गरेर डिप्लोयमेन्टको समयमा यो सुविधा सक्षम गरेको छ। CSIDriver.storageCapacity, त्यसपछि पर्याप्त भण्डारण क्षमता नभएका नोडहरू स्वतः खारेज हुनेछन्। यसले सामान्य उद्देश्यका क्षणिक र निरन्तर भोल्युमहरू दुवैका लागि काम गर्छ, तर CSI अल्पकालिक भोल्युमहरूको लागि होइन किनभने तिनीहरूका प्यारामिटरहरू Kubernetes द्वारा पढ्न सकिँदैन।

सामान्य रूपमा, पोडहरू निर्धारित हुनु अघि तुरुन्तै लिङ्क गरिएको भोल्युमहरू सिर्जना गरिन्छ, र तिनीहरूको स्थान भण्डारण ड्राइभरद्वारा छनोट गरिन्छ, त्यसैले कन्फिगर गर्दा external-provisioner पूर्वनिर्धारित रूपमा, तत्काल बाइन्डिङका साथ भण्डारण कक्षाहरू छोडिएका छन्, किनकि यो डेटा जसरी पनि प्रयोग गरिने छैन।

kubernetes अनुसूचकलाई सम्भावित रूपमा पुरानो जानकारीको साथ काम गर्न बाध्य पारिएको हुनाले, भोल्युम सिर्जना गर्दा प्रत्येक अवस्थामा क्षमता उपलब्ध हुनेछ भन्ने कुनै ग्यारेन्टी छैन, तर पुन: प्रयास नगरी सिर्जना हुने सम्भावनाहरू अझै बढेका छन्।

एनबी तपाईं थप विस्तृत जानकारी प्राप्त गर्न सक्नुहुन्छ, साथै सुरक्षित रूपमा "बिरालाहरूको स्ट्यान्डमा अभ्यास गर्नुहोस्", र पूर्ण रूपमा बुझ्न नसकिने स्थितिमा, गहन पाठ्यक्रमहरूमा योग्य प्राविधिक समर्थन सहायता प्राप्त गर्नुहोस् - Kubernetes आधार सेप्टेम्बर 28-30 मा आयोजित हुनेछ, र थप उन्नत विशेषज्ञहरूको लागि Kubernetes मेगा अक्टोबर 14-16।

सुरक्षा

CSISstorage क्षमता

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 वस्तुहरू मानिसले पढ्नको लागि होइन, त्यसैले केही प्रशोधन आवश्यक छ। 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 कुनै पनि अवस्थामा।

के अर्को छ?

दुबै सुविधाहरू अझै विकासमा छन्। अल्फा परीक्षणको क्रममा धेरै अनुप्रयोगहरू खोलिएका थिए। सुधार प्रस्ताव लिङ्कले बिटा चरणमा सार्नको लागि गर्नु पर्ने काम, साथै कुन विकल्पहरू पहिले नै विचार गरी अस्वीकृत भइसकेका छन् भनेर दस्तावेज गर्दछ:

• KEP-1698: जेनेरिक एफेमरल इनलाइन भोल्युमहरू

• KEP-1472: भण्डारण क्षमता ट्र्याकिङ

स्रोत: www.habr.com