સ્ટોરેજ કેપેસિટી ટ્રેકિંગ સાથે ક્ષણિક વોલ્યુમ્સ: સ્ટેરોઇડ્સ પર EmptyDir

કેટલીક એપ્લિકેશનોને ડેટા સ્ટોર કરવાની પણ જરૂર હોય છે, પરંતુ તેઓ એ હકીકતથી તદ્દન આરામદાયક છે કે પુનઃપ્રારંભ કર્યા પછી ડેટા સાચવવામાં આવશે નહીં.

ઉદાહરણ તરીકે, કેશીંગ સેવાઓ RAM દ્વારા મર્યાદિત છે, પરંતુ તે ડેટાને પણ ખસેડી શકે છે જેનો ઉપયોગ ભાગ્યે જ સ્ટોરેજ માટે થાય છે જે RAM કરતાં ધીમી હોય છે, એકંદર કામગીરી પર થોડી અસર થાય છે. અન્ય એપ્લીકેશનોએ એ વાતનું ધ્યાન રાખવું જરૂરી છે કે ફાઈલોમાં કેટલાક ફક્ત વાંચવા માટેના ઇનપુટ હોઈ શકે છે, જેમ કે સેટિંગ્સ અથવા ગુપ્ત કી.

કુબરનેટ્સ પાસે પહેલાથી જ ઘણા પ્રકારો છે ક્ષણિક વોલ્યુમો, પરંતુ તેમની કાર્યક્ષમતા K8s માં લાગુ કરવામાં આવે છે તેના સુધી મર્યાદિત છે.

ક્ષણિક CSI વોલ્યુમો હળવા વજનના સ્થાનિક વોલ્યુમો માટે આધાર પૂરો પાડવા માટે કુબરનેટ્સને CSI ડ્રાઇવરો સાથે વિસ્તૃત કરવાની મંજૂરી આપી હતી. આ રીતે તેનો ઉપયોગ શક્ય છે મનસ્વી રચનાઓ: સેટિંગ્સ, રહસ્યો, ઓળખ ડેટા, ચલો, અને તેથી વધુ. CSI ડ્રાઇવરોને આ કુબરનેટ્સ સુવિધાને સમર્થન આપવા માટે સંશોધિત કરવું આવશ્યક છે, કારણ કે એવું માનવામાં આવે છે કે નિયમિત પ્રમાણિત ડ્રાઇવરો કામ કરશે નહીં - પરંતુ એવું માનવામાં આવે છે કે પોડ માટે પસંદ કરેલ કોઈપણ નોડ પર આવા વોલ્યુમોનો ઉપયોગ કરી શકાય છે.

આ વોલ્યુમો માટે સમસ્યા હોઈ શકે છે જે નોંધપાત્ર હોસ્ટ સંસાધનોનો ઉપયોગ કરે છે અથવા સ્ટોરેજ માટે કે જે ફક્ત કેટલાક યજમાનો પર ઉપલબ્ધ છે. તેથી જ કુબરનેટ્સ 1.19 બે નવા આલ્ફા પરીક્ષણ વોલ્યુમ લક્ષણો રજૂ કરે છે જે કલ્પનાત્મક રીતે EmptyDir વોલ્યુમ્સ સમાન છે:

• સામાન્ય હેતુ ક્ષણિક વોલ્યુમો;

• CSI સંગ્રહ ક્ષમતા ટ્રેકિંગ.

નવા અભિગમના ફાયદા:

• સ્ટોરેજ સ્થાનિક અથવા નેટવર્ક દ્વારા કનેક્ટેડ હોઈ શકે છે;

• વોલ્યુમમાં ચોક્કસ કદ હોઈ શકે છે જે એપ્લિકેશન દ્વારા ઓળંગી શકાતું નથી;

• કોઈપણ CSI ડ્રાઇવરો સાથે કામ કરે છે જે સતત વોલ્યુમની જોગવાઈને સમર્થન આપે છે અને (ક્ષમતા ટ્રેકિંગને સમર્થન આપવા માટે) કૉલને અમલમાં મૂકે છે GetCapacity;

• ડ્રાઇવર અને સેટિંગ્સના આધારે વોલ્યુમમાં થોડો પ્રારંભિક ડેટા હોઈ શકે છે;

• વોલ્યુમ સાથેની તમામ પ્રમાણભૂત કામગીરી (સ્નેપશોટ બનાવવી, માપ બદલવી વગેરે) સપોર્ટેડ છે;

• વોલ્યુમનો ઉપયોગ કોઈપણ એપ્લિકેશન નિયંત્રક સાથે કરી શકાય છે જે મોડ્યુલ અથવા વોલ્યુમ સ્પષ્ટીકરણ સ્વીકારે છે;

• કુબરનેટ્સ શેડ્યૂલર તેની પોતાની રીતે યોગ્ય નોડ્સ પસંદ કરે છે, તેથી શેડ્યૂલર એક્સ્ટેંશનને જોગવાઈ અને ગોઠવવાની અથવા વેબહુક્સને સંશોધિત કરવાની હવે કોઈ જરૂર નથી.

એપ્લિકેશન વિકલ્પો

તેથી, સામાન્ય હેતુના ક્ષણિક વોલ્યુમો નીચેના ઉપયોગના કિસ્સાઓ માટે યોગ્ય છે:

મેમકેશ્ડ માટે RAM ના રિપ્લેસમેન્ટ તરીકે સતત મેમરી

memcached ના નવીનતમ પ્રકાશનો ઉમેરાયેલ આધાર સતત મેમરીનો ઉપયોગ કરીને (Intel Optane, વગેરે, આશરે અનુવાદક) નિયમિત RAM ને બદલે. એપ્લીકેશન કંટ્રોલર દ્વારા મેમકેશ્ડ જમાવતી વખતે, તમે CSI ડ્રાઇવરનો ઉપયોગ કરીને PMEM માંથી આપેલ કદના વોલ્યુમની ફાળવણી કરવા વિનંતી કરવા માટે સામાન્ય હેતુના ક્ષણિક વોલ્યુમોનો ઉપયોગ કરી શકો છો, ઉદાહરણ તરીકે PMEM-CSI.

વર્કસ્પેસ તરીકે LVM સ્થાનિક સંગ્રહ

એપ્લિકેશન કે જે RAM કરતા મોટા ડેટા સાથે કામ કરે છે તેને કદ અથવા પ્રદર્શન મેટ્રિક્સ સાથે સ્થાનિક સ્ટોરેજની જરૂર પડી શકે છે જે Kubernetes ના નિયમિત EmptyDir વોલ્યુમ પ્રદાન કરી શકતા નથી. ઉદાહરણ તરીકે, આ હેતુ માટે તે લખવામાં આવ્યું હતું ટોપોએલવીએમ.

ડેટા વોલ્યુમ્સ માટે ફક્ત વાંચવા માટેની ઍક્સેસ

વોલ્યુમની ફાળવણી સંપૂર્ણ વોલ્યુમની રચનામાં પરિણમી શકે છે જ્યારે:

• પુનઃસંગ્રહ વોલ્યુમ સ્નેપશોટ;

• બનાવટ વોલ્યુમ નકલો;

• કામ ડેટા પ્લેસહોલ્ડર્સ.

આ વોલ્યુમો ફક્ત વાંચવા માટેના મોડમાં માઉન્ટ કરી શકાય છે.

આ કેવી રીતે કામ કરે છે

સામાન્ય હેતુ ક્ષણિક વોલ્યુમો

સામાન્ય હેતુના ક્ષણિક વોલ્યુમોની મુખ્ય વિશેષતા એ નવો વોલ્યુમ સ્ત્રોત છે, EphemeralVolumeSource, વોલ્યુમ વિનંતિ બનાવવા માટે તમામ ક્ષેત્રો ધરાવે છે (ઐતિહાસિક રીતે સતત વોલ્યુમ વિનંતી, PVC કહેવાય છે). માં નવા નિયંત્રક kube-controller-manager પોડ્સને જુએ છે જે આવા વોલ્યુમ સ્ત્રોત બનાવે છે, અને પછી તે પોડ્સ માટે પીવીસી બનાવે છે. CSI ડ્રાઇવર માટે, આ વિનંતિ અન્ય જેવી જ લાગે છે, તેથી અહીં કોઈ વિશેષ સમર્થનની જરૂર નથી.

જ્યાં સુધી આવા PVC અસ્તિત્વમાં છે, ત્યાં સુધી તેનો ઉપયોગ વોલ્યુમ પરની અન્ય વિનંતીઓની જેમ થઈ શકે છે. ખાસ કરીને, વોલ્યુમની નકલ કરતી વખતે અથવા વોલ્યુમમાંથી સ્નેપશોટ બનાવતી વખતે તેમને ડેટા સ્ત્રોત તરીકે સંદર્ભિત કરી શકાય છે. પીવીસી ઑબ્જેક્ટમાં વોલ્યુમની વર્તમાન સ્થિતિ પણ શામેલ છે.

આપમેળે બનાવેલ PVC ના નામ પૂર્વવ્યાખ્યાયિત છે: તે પોડ નામ અને વોલ્યુમ નામનું સંયોજન છે, જે હાઇફન દ્વારા અલગ પડે છે. પૂર્વવ્યાખ્યાયિત નામો PVC સાથે ક્રિયાપ્રતિક્રિયા કરવાનું સરળ બનાવે છે કારણ કે જો તમને પોડ નામ અને વોલ્યુમ નામ ખબર હોય તો તમારે તેને શોધવાની જરૂર નથી. નુકસાન એ છે કે નામ પહેલેથી ઉપયોગમાં હોઈ શકે છે, જે કુબરનેટ્સ દ્વારા શોધાયેલ છે અને પરિણામે પોડ શરૂ થવાથી અવરોધિત છે.

પોડ સાથે વોલ્યુમ કાઢી નાખવામાં આવે તેની ખાતરી કરવા માટે, નિયંત્રક માલિક હેઠળના વોલ્યુમને વિનંતી કરે છે. જ્યારે પોડ કાઢી નાખવામાં આવે છે, ત્યારે પ્રમાણભૂત કચરો એકત્ર કરવાની પદ્ધતિ કામ કરે છે, જે વિનંતી અને વોલ્યુમ બંનેને કાઢી નાખે છે.

સ્ટોરેજ ક્લાસની સામાન્ય મિકેનિઝમ દ્વારા સ્ટોરેજ ડ્રાઇવર દ્વારા વિનંતીઓ મેળ ખાય છે. જો કે તાત્કાલિક અને મોડું બંધનકર્તા વર્ગો (ઉર્ફ WaitForFirstConsumer) સમર્થિત છે, ક્ષણિક વોલ્યુમો માટે તેનો ઉપયોગ કરવો અર્થપૂર્ણ છે WaitForFirstConsumer, પછી શેડ્યૂલર નોડ પસંદ કરતી વખતે નોડનો ઉપયોગ અને સ્ટોરેજ ઉપલબ્ધતા બંનેને ધ્યાનમાં લઈ શકે છે. એક નવી સુવિધા અહીં દેખાય છે.

સંગ્રહ ક્ષમતા ટ્રેકિંગ

સામાન્ય રીતે શેડ્યૂલરને CSI ડ્રાઇવર ક્યાં વોલ્યુમ બનાવશે તેની કોઈ જાણકારી હોતી નથી. આ માહિતીની વિનંતી કરવા માટે શેડ્યૂલર માટે ડ્રાઇવરનો સીધો સંપર્ક કરવાનો પણ કોઈ રસ્તો નથી. તેથી, શેડ્યૂલર મતદાન નોડ્સ કરે છે જ્યાં સુધી તે એક એવું શોધી ન લે કે જેના પર વોલ્યુમ્સ એક્સેસ કરી શકાય (લેટ બાઈન્ડિંગ) અથવા સ્થાનની પસંદગી સંપૂર્ણપણે ડ્રાઈવર (તાત્કાલિક બંધનકર્તા) પર છોડી દે.

નવી API CSIStorageCapacity, જે આલ્ફા સ્ટેજમાં છે, જરૂરી ડેટાને etcd માં સંગ્રહિત કરવાની પરવાનગી આપે છે જેથી કરીને તે શેડ્યૂલર માટે ઉપલબ્ધ હોય. સામાન્ય હેતુના ક્ષણિક વોલ્યુમો માટેના સમર્થનથી વિપરીત, જ્યારે તમે ડ્રાઇવરને જમાવશો, ત્યારે તમારે સંગ્રહ ક્ષમતા ટ્રેકિંગને સક્ષમ કરવું આવશ્યક છે: external-provisioner સામાન્ય મારફતે ડ્રાઈવર પાસેથી પ્રાપ્ત ક્ષમતા માહિતી પ્રકાશિત કરવી જોઈએ GetCapacity.

જો શેડ્યૂલરને અનબાઉન્ડ વોલ્યુમ સાથે પોડ માટે નોડ પસંદ કરવાની જરૂર હોય જે લેટ બાઈન્ડિંગનો ઉપયોગ કરે છે, અને ડ્રાઇવરે ધ્વજ સેટ કરીને જમાવટ દરમિયાન આ સુવિધાને સક્ષમ કરી છે. CSIDriver.storageCapacity, પછી નોડ્સ કે જેની પાસે પૂરતી સંગ્રહ ક્ષમતા નથી તે આપમેળે કાઢી નાખવામાં આવશે. આ સામાન્ય હેતુ ક્ષણિક અને સતત વોલ્યુમ બંને માટે કામ કરે છે, પરંતુ CSI ક્ષણિક વોલ્યુમો માટે નહીં કારણ કે તેમના પરિમાણો કુબરનેટ્સ દ્વારા વાંચી શકાતા નથી.

હંમેશની જેમ, પોડ્સ શેડ્યૂલ થાય તે પહેલાં તરત જ લિંક કરેલા વોલ્યુમો બનાવવામાં આવે છે, અને તેમની પ્લેસમેન્ટ સ્ટોરેજ ડ્રાઇવર દ્વારા પસંદ કરવામાં આવે છે, તેથી જ્યારે ગોઠવણી કરવામાં આવે ત્યારે external-provisioner ડિફૉલ્ટ રૂપે, તાત્કાલિક બંધનકર્તા સાથેના સંગ્રહ વર્ગો છોડવામાં આવે છે, કારણ કે આ ડેટા કોઈપણ રીતે ઉપયોગમાં લેવાશે નહીં.

kubernetes શેડ્યૂલરને સંભવિત રૂપે જૂની માહિતી સાથે કામ કરવાની ફરજ પાડવામાં આવતી હોવાથી, જ્યારે વોલ્યુમ બનાવવામાં આવે ત્યારે દરેક કિસ્સામાં ક્ષમતા ઉપલબ્ધ રહેશે તેની કોઈ ગેરેંટી નથી, પરંતુ તેમ છતાં તે પુનઃપ્રયાસ કર્યા વિના બનાવવામાં આવશે તેવી શક્યતાઓ વધી છે.

નો તમે વધુ વિગતવાર માહિતી મેળવી શકો છો, તેમજ સુરક્ષિત રીતે "બિલાડીઓના સ્ટેન્ડ પર પ્રેક્ટિસ" કરી શકો છો, અને સંપૂર્ણપણે અગમ્ય પરિસ્થિતિના કિસ્સામાં, સઘન અભ્યાસક્રમોમાં લાયક તકનીકી સહાયતા પ્રાપ્ત કરી શકો છો - કુબરનેટ્સ બેઝ સપ્ટેમ્બર 28-30 ના રોજ યોજાશે, અને વધુ અદ્યતન નિષ્ણાતો માટે કુબરનેટ્સ મેગા ઓક્ટોબર 14-16.

સુરક્ષા

CSISstorageક્ષમતા

CSISstorageCapacity ઑબ્જેક્ટ્સ નેમસ્પેસમાં રહે છે; જ્યારે દરેક CSI ડ્રાઇવરને તેની પોતાની નેમસ્પેસમાં રોલઆઉટ કરવામાં આવે છે, ત્યારે તે જગ્યામાં CSIStorageCapacity માટે RBAC અધિકારોને પ્રતિબંધિત કરવાની ભલામણ કરવામાં આવે છે કારણ કે તે સ્પષ્ટ છે કે ડેટા ક્યાંથી આવી રહ્યો છે. કુબરનેટ્સ કોઈપણ રીતે આ માટે તપાસ કરતું નથી, અને સામાન્ય રીતે ડ્રાઇવરોને સમાન નેમસ્પેસમાં મૂકવામાં આવે છે, તેથી આખરે ડ્રાઇવરો પાસે કામ કરવાની અને ખોટો ડેટા પ્રકાશિત ન કરવાની અપેક્ષા રાખવામાં આવે છે (અને આ તે છે જ્યાં મારું કાર્ડ નિષ્ફળ થયું, આશરે દાઢીવાળા જોક પર આધારિત અનુવાદક)

સામાન્ય હેતુ ક્ષણિક વોલ્યુમો

જો વપરાશકર્તાઓ પાસે પોડ (પ્રત્યક્ષ અથવા પરોક્ષ રીતે) બનાવવાના અધિકારો હોય, તો તેઓ વોલ્યુમ પર વિનંતી બનાવવાના અધિકારો ધરાવતા ન હોય તો પણ તેઓ સામાન્ય હેતુના ક્ષણિક વોલ્યુમો પણ બનાવી શકશે. આ એટલા માટે છે કારણ કે RBAC પરવાનગી તપાસો તે નિયંત્રક પર લાગુ થાય છે જે પીવીસી બનાવે છે, વપરાશકર્તાને નહીં. ઉમેરવા માટે આ મુખ્ય ફેરફાર છે તમારા ખાતામાં, ક્લસ્ટરો પર આ સુવિધાને સક્ષમ કરતા પહેલા જ્યાં અવિશ્વસનીય વપરાશકર્તાઓ પાસે વોલ્યુમ બનાવવાના અધિકારો ન હોવા જોઈએ.

ઉદાહરણ:

અલગ શાખા PMEM-CSI એ QEMU વર્ચ્યુઅલ મશીનોની અંદર આલ્ફા સ્ટેજની તમામ સુવિધાઓ સાથે કુબરનેટ્સ 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 && 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

બનાવ્યા પછી, ઉપરની સૂચનાઓમાં બતાવ્યા પ્રમાણે, અમારી પાસે હવે વધારાના પોડ અને પીવીસી છે:

$ 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 કોઈપણ કિસ્સામાં.

શું આગામી છે?

બંને સુવિધાઓ હજી વિકાસમાં છે. આલ્ફા પરીક્ષણ દરમિયાન કેટલીક એપ્લિકેશનો ખોલવામાં આવી હતી. સુધારણા દરખાસ્ત લિંક્સ એ કાર્યને દસ્તાવેજ કરે છે જે બીટા તબક્કામાં જવા માટે કરવાની જરૂર છે, તેમજ કયા વિકલ્પો પહેલાથી જ ધ્યાનમાં લેવામાં આવ્યા છે અને નકારવામાં આવ્યા છે:

• KEP-1698: સામાન્ય ક્ષણિક ઇનલાઇન વોલ્યુમો

• KEP-1472: સ્ટોરેજ કેપેસિટી ટ્રેકિંગ

સોર્સ: www.habr.com