కొన్ని అప్లికేషన్‌లు కూడా డేటాను నిల్వ చేయవలసి ఉంటుంది, అయితే పునఃప్రారంభించిన తర్వాత డేటా సేవ్ చేయబడదు అనే వాస్తవంతో అవి చాలా సౌకర్యవంతంగా ఉంటాయి.
ఉదాహరణకు, కాషింగ్ సేవలు RAM ద్వారా పరిమితం చేయబడ్డాయి, అయితే RAM కంటే నెమ్మదిగా ఉండే నిల్వకు అరుదుగా ఉపయోగించే డేటాను కూడా తరలించవచ్చు, మొత్తం పనితీరుపై తక్కువ ప్రభావం ఉంటుంది. ఫైల్‌లలో సెట్టింగ్‌లు లేదా రహస్య కీలు వంటి కొన్ని రీడ్-ఓన్లీ ఇన్‌పుట్ ఉండవచ్చని ఇతర అప్లికేషన్‌లు తెలుసుకోవాలి.
Kubernetes ఇప్పటికే అనేక రకాలు ఉన్నాయి , కానీ వాటి కార్యాచరణ K8sలో అమలు చేయబడిన వాటికి పరిమితం చేయబడింది.
అశాశ్వతమైన తేలికైన స్థానిక వాల్యూమ్‌లకు మద్దతును అందించడానికి కుబెర్నెట్‌లను CSI డ్రైవర్‌లతో విస్తరించడానికి అనుమతించింది. ఈ విధంగా ఉపయోగించడం సాధ్యమవుతుంది : సెట్టింగ్‌లు, రహస్యాలు, గుర్తింపు డేటా, వేరియబుల్స్ మొదలైనవి. CSI డ్రైవర్లు తప్పనిసరిగా ఈ కుబెర్నెటీస్ లక్షణానికి మద్దతు ఇవ్వడానికి సవరించబడాలి, ఎందుకంటే సాధారణ ప్రామాణిక డ్రైవర్లు పని చేయవని భావించబడుతుంది - అయితే పాడ్ కోసం ఎంచుకున్న ఏ నోడ్‌లోనైనా ఇటువంటి వాల్యూమ్‌లను ఉపయోగించవచ్చని భావించబడుతుంది.
ఇది ముఖ్యమైన హోస్ట్ వనరులను వినియోగించే వాల్యూమ్‌లకు లేదా కొన్ని హోస్ట్‌లలో మాత్రమే అందుబాటులో ఉండే నిల్వకు సమస్య కావచ్చు. అందుకే Kubernetes 1.19 రెండు కొత్త ఆల్ఫా టెస్టింగ్ వాల్యూమ్ ఫీచర్‌లను పరిచయం చేసింది, ఇవి సంభావితంగా EmptyDir వాల్యూమ్‌లను పోలి ఉంటాయి:
-
సాధారణ ప్రయోజన అశాశ్వత వాల్యూమ్‌లు;
-
CSI నిల్వ సామర్థ్యం ట్రాకింగ్.
కొత్త విధానం యొక్క ప్రయోజనాలు:
-
నిల్వ స్థానికంగా ఉండవచ్చు లేదా నెట్‌వర్క్ ద్వారా కనెక్ట్ చేయబడవచ్చు;
-
వాల్యూమ్‌లు నిర్దిష్ట పరిమాణాన్ని కలిగి ఉండవచ్చు, అది అప్లికేషన్ ద్వారా మించకూడదు;
-
నిరంతర వాల్యూమ్‌లను అందించడానికి మరియు (సామర్థ్యం ట్రాకింగ్‌కు మద్దతు ఇవ్వడానికి) కాల్‌ను అమలు చేయడానికి మద్దతు ఇచ్చే ఏదైనా CSI డ్రైవర్‌లతో పని చేస్తుంది
GetCapacity; -
వాల్యూమ్‌లు డ్రైవర్ మరియు సెట్టింగ్‌లను బట్టి కొంత ప్రారంభ డేటాను కలిగి ఉండవచ్చు;
-
వాల్యూమ్‌తో అన్ని ప్రామాణిక కార్యకలాపాలు (స్నాప్‌షాట్‌ను సృష్టించడం, పునఃపరిమాణం చేయడం మొదలైనవి) మద్దతునిస్తాయి;
-
మాడ్యూల్ లేదా వాల్యూమ్ స్పెసిఫికేషన్‌ను ఆమోదించే ఏదైనా అప్లికేషన్ కంట్రోలర్‌తో వాల్యూమ్‌లను ఉపయోగించవచ్చు;
-
Kubernetes షెడ్యూలర్ దాని స్వంతంగా తగిన నోడ్‌లను ఎంచుకుంటుంది, కాబట్టి ఇకపై షెడ్యూలర్ పొడిగింపులను అందించడం మరియు కాన్ఫిగర్ చేయడం లేదా వెబ్‌హుక్‌లను సవరించడం అవసరం లేదు.
అప్లికేషన్ ఎంపికలు
అందువల్ల, సాధారణ ప్రయోజన అశాశ్వత వాల్యూమ్‌లు క్రింది వినియోగ సందర్భాలలో అనుకూలంగా ఉంటాయి:
మెమ్‌క్యాచ్డ్ కోసం RAMకి బదులుగా పెర్సిస్టెంట్ మెమరీ
memcached యొక్క తాజా విడుదలలు నిరంతర మెమరీని ఉపయోగించడం (ఇంటెల్ ఆప్టేన్, మొదలైనవి, సుమారు అనువాదకుడు) సాధారణ RAMకి బదులుగా. అప్లికేషన్ కంట్రోలర్ ద్వారా మెమ్‌క్యాచ్‌ని అమలు చేస్తున్నప్పుడు, మీరు CSI డ్రైవర్‌ని ఉపయోగించి PMEM నుండి ఇచ్చిన పరిమాణం యొక్క వాల్యూమ్‌ను కేటాయించమని అభ్యర్థించడానికి సాధారణ ప్రయోజన ఎఫెమెరల్ వాల్యూమ్‌లను ఉపయోగించవచ్చు, ఉదాహరణకు .
వర్క్‌స్పేస్‌గా LVM స్థానిక నిల్వ
RAM కంటే పెద్ద డేటాతో పని చేసే అప్లికేషన్‌లకు, Kubernetes నుండి సాధారణ EmptyDir వాల్యూమ్‌లు అందించలేని పరిమాణం లేదా పనితీరు కొలమానాలతో స్థానిక నిల్వ అవసరం కావచ్చు. ఉదాహరణకు, ఈ ప్రయోజనం కోసం ఇది వ్రాయబడింది .
డేటా వాల్యూమ్‌ల కోసం చదవడానికి మాత్రమే యాక్సెస్
వాల్యూమ్ యొక్క కేటాయింపు పూర్తి వాల్యూమ్‌ను సృష్టించడానికి దారితీస్తుంది:
-
పునరుద్ధరణ ;
-
సృష్టి ;
-
ది .
ఈ వాల్యూమ్‌లను రీడ్-ఓన్లీ మోడ్‌లో మౌంట్ చేయవచ్చు.
ఎలా పని చేస్తుంది
జనరల్ పర్పస్ ఎఫెమెరల్ వాల్యూమ్‌లు
సాధారణ ప్రయోజన అశాశ్వత వాల్యూమ్‌ల యొక్క ముఖ్య లక్షణం కొత్త వాల్యూమ్ మూలం, EphemeralVolumeSource, వాల్యూమ్ అభ్యర్థనను సృష్టించడానికి అన్ని ఫీల్డ్‌లను కలిగి ఉంటుంది (చారిత్రాత్మకంగా నిరంతర వాల్యూమ్ అభ్యర్థన, PVC అని పిలుస్తారు). కొత్త కంట్రోలర్ kube-controller-manager అటువంటి వాల్యూమ్ మూలాన్ని సృష్టించే పాడ్‌లను చూస్తుంది, ఆపై ఆ పాడ్‌ల కోసం PVCని సృష్టిస్తుంది. CSI డ్రైవర్ కోసం, ఈ అభ్యర్థన ఇతరుల మాదిరిగానే కనిపిస్తుంది, కాబట్టి ఇక్కడ ప్రత్యేక మద్దతు అవసరం లేదు.
అటువంటి PVCలు ఉన్నంత వరకు, వాల్యూమ్‌లోని ఏవైనా ఇతర అభ్యర్థనల వలె వాటిని ఉపయోగించవచ్చు. ప్రత్యేకించి, వాల్యూమ్‌ను కాపీ చేసేటప్పుడు లేదా వాల్యూమ్ నుండి స్నాప్‌షాట్‌ను రూపొందించేటప్పుడు వాటిని డేటా సోర్స్‌గా సూచించవచ్చు. PVC ఆబ్జెక్ట్ వాల్యూమ్ యొక్క ప్రస్తుత స్థితిని కూడా కలిగి ఉంటుంది.
స్వయంచాలకంగా సృష్టించబడిన PVCల పేర్లు ముందే నిర్వచించబడ్డాయి: అవి పాడ్ పేరు మరియు వాల్యూమ్ పేరు కలయిక, హైఫన్‌తో వేరు చేయబడతాయి. ముందుగా నిర్వచించిన పేర్లు PVCతో ఇంటరాక్ట్ అవ్వడాన్ని సులభతరం చేస్తాయి ఎందుకంటే మీకు పాడ్ పేరు మరియు వాల్యూమ్ పేరు తెలిస్తే మీరు దాని కోసం వెతకాల్సిన అవసరం లేదు. ప్రతికూలత ఏమిటంటే, పేరు ఇప్పటికే వాడుకలో ఉండవచ్చు, ఇది Kubernetes ద్వారా కనుగొనబడింది మరియు ఫలితంగా పాడ్ ప్రారంభించకుండా నిరోధించబడింది.
పాడ్‌తో పాటు వాల్యూమ్ తొలగించబడిందని నిర్ధారించుకోవడానికి, కంట్రోలర్ యజమాని కింద ఉన్న వాల్యూమ్‌కు అభ్యర్థన చేస్తుంది. పాడ్ తొలగించబడినప్పుడు, ప్రామాణిక చెత్త సేకరణ విధానం పని చేస్తుంది, ఇది అభ్యర్థన మరియు వాల్యూమ్ రెండింటినీ తొలగిస్తుంది.
స్టోరేజ్ క్లాస్ యొక్క సాధారణ మెకానిజం ద్వారా స్టోరేజ్ డ్రైవర్ ద్వారా అభ్యర్థనలు సరిపోలాయి. తక్షణ మరియు ఆలస్యంగా బైండింగ్‌తో తరగతులు ఉన్నప్పటికీ (అకా WaitForFirstConsumer) మద్దతిస్తుంది, అశాశ్వత వాల్యూమ్‌ల కోసం ఉపయోగించడం అర్ధమే WaitForFirstConsumer, అప్పుడు షెడ్యూలర్ నోడ్‌ను ఎంచుకున్నప్పుడు నోడ్ వినియోగం మరియు నిల్వ లభ్యత రెండింటినీ పరిగణించవచ్చు. ఇక్కడ ఒక కొత్త ఫీచర్ కనిపిస్తుంది.
స్టోరేజ్ కెపాసిటీ ట్రాకింగ్
సాధారణంగా CSI డ్రైవర్ వాల్యూమ్‌ను ఎక్కడ సృష్టిస్తుందో షెడ్యూలర్‌కు తెలియదు. ఈ సమాచారాన్ని అభ్యర్థించడానికి షెడ్యూలర్ నేరుగా డ్రైవర్‌ను సంప్రదించడానికి కూడా మార్గం లేదు. అందువల్ల, షెడ్యూలర్ పోల్స్ నోడ్‌లు ఏ వాల్యూమ్‌లను యాక్సెస్ చేయవచ్చో (లేట్ బైండింగ్) కనుగొనే వరకు లేదా లొకేషన్ ఎంపికను పూర్తిగా డ్రైవర్‌కు వదిలివేస్తుంది (తక్షణ బైండింగ్).
కొత్త CSIStorageCapacity, ఇది ఆల్ఫా దశలో ఉంది, అవసరమైన డేటాను etcdలో నిల్వ చేయడానికి అనుమతిస్తుంది, తద్వారా అది షెడ్యూలర్‌కు అందుబాటులో ఉంటుంది. సాధారణ ప్రయోజన అశాశ్వత వాల్యూమ్‌లకు మద్దతు కాకుండా, మీరు డ్రైవర్‌ను అమలు చేసినప్పుడు, మీరు తప్పనిసరిగా నిల్వ సామర్థ్యం ట్రాకింగ్‌ను ప్రారంభించాలి: external-provisioner డ్రైవర్ నుండి పొందిన సామర్థ్య సమాచారాన్ని సాధారణ ద్వారా ప్రచురించాలి GetCapacity.
షెడ్యూలర్ లేట్ బైండింగ్‌ని ఉపయోగించే అన్‌బౌండ్ వాల్యూమ్‌తో పాడ్ కోసం నోడ్‌ను ఎంచుకోవాల్సి వస్తే మరియు డ్రైవర్ ఫ్లాగ్‌ని సెట్ చేయడం ద్వారా డిప్లాయ్‌మెంట్ సమయంలో ఈ ఫీచర్‌ను ఎనేబుల్ చేస్తే CSIDriver.storageCapacity, అప్పుడు తగినంత నిల్వ సామర్థ్యం లేని నోడ్‌లు స్వయంచాలకంగా విస్మరించబడతాయి. ఇది సాధారణ ప్రయోజన అశాశ్వత మరియు నిరంతర వాల్యూమ్‌ల కోసం పనిచేస్తుంది, కానీ CSI అశాశ్వత వాల్యూమ్‌ల కోసం కాదు ఎందుకంటే వాటి పారామితులను కుబెర్నెట్స్ చదవలేరు.
ఎప్పటిలాగే, పాడ్‌లను షెడ్యూల్ చేయడానికి ముందు వెంటనే లింక్ చేయబడిన వాల్యూమ్‌లు సృష్టించబడతాయి మరియు వాటి ప్లేస్‌మెంట్ నిల్వ డ్రైవర్ ద్వారా ఎంపిక చేయబడుతుంది, కాబట్టి కాన్ఫిగర్ చేస్తున్నప్పుడు external-provisioner డిఫాల్ట్‌గా, తక్షణ బైండింగ్‌తో కూడిన నిల్వ తరగతులు దాటవేయబడతాయి, ఎందుకంటే ఈ డేటా ఏమైనప్పటికీ ఉపయోగించబడదు.
కుబెర్నెటెస్ షెడ్యూలర్ కాలం చెల్లిన సమాచారంతో పని చేయవలసి వస్తుంది కాబట్టి, వాల్యూమ్ సృష్టించబడినప్పుడు ప్రతి సందర్భంలోనూ కెపాసిటీ అందుబాటులో ఉంటుందని గ్యారెంటీ లేదు, అయితే మళ్లీ ప్రయత్నించకుండానే అది సృష్టించబడే అవకాశాలు పెరుగుతాయి.
NB మీరు మరింత వివరణాత్మక సమాచారాన్ని పొందవచ్చు, అలాగే సురక్షితంగా “పిల్లుల స్టాండ్‌పై ప్రాక్టీస్” చేయవచ్చు మరియు పూర్తిగా అపారమయిన పరిస్థితిలో, ఇంటెన్సివ్ కోర్సులలో అర్హత కలిగిన సాంకేతిక మద్దతు సహాయాన్ని పొందవచ్చు - సెప్టెంబర్ 28-30 తేదీలలో మరియు మరింత అధునాతన నిపుణుల కోసం నిర్వహించబడుతుంది అక్టోబర్ 14–16.
భద్రత
CSISస్టోరేజ్ కెపాసిటీ
CSIStorageCapacity ఆబ్జెక్ట్‌లు నేమ్‌స్పేస్‌లలో ఉంటాయి; ప్రతి CSI డ్రైవర్‌ను దాని స్వంత నేమ్‌స్పేస్‌లో రోల్ అవుట్ చేస్తున్నప్పుడు, డేటా ఎక్కడ నుండి వస్తుందో స్పష్టంగా ఉన్నందున ఆ స్థలంలో CSIStorageCapacityకి RBAC హక్కులను పరిమితం చేయాలని సిఫార్సు చేయబడింది. Kubernetes ఏమైనప్పటికీ దీని కోసం తనిఖీ చేయదు మరియు సాధారణంగా డ్రైవర్లు ఒకే నేమ్‌స్పేస్‌లో ఉంచబడతారు, కాబట్టి చివరికి డ్రైవర్లు పని చేస్తారని మరియు తప్పు డేటాను ప్రచురించకూడదని భావిస్తున్నారు (మరియు ఇక్కడే నా కార్డ్ విఫలమైంది, సుమారు గడ్డం గల జోక్ ఆధారంగా అనువాదకుడు)
జనరల్ పర్పస్ ఎఫెమెరల్ వాల్యూమ్‌లు
వినియోగదారులు పాడ్‌ను (ప్రత్యక్షంగా లేదా పరోక్షంగా) సృష్టించే హక్కులు కలిగి ఉంటే, వారు వాల్యూమ్‌పై అభ్యర్థనను సృష్టించే హక్కులు లేకపోయినా సాధారణ ప్రయోజన అశాశ్వత వాల్యూమ్‌లను కూడా సృష్టించగలరు. ఎందుకంటే RBAC అనుమతి తనిఖీలు వినియోగదారుకు కాకుండా PVCని సృష్టించే కంట్రోలర్‌కు వర్తింపజేయబడతాయి. జోడించాల్సిన ప్రధాన మార్పు ఇది , అవిశ్వసనీయ వినియోగదారులు వాల్యూమ్‌లను సృష్టించడానికి హక్కులు కలిగి ఉండని క్లస్టర్‌లలో ఈ లక్షణాన్ని ప్రారంభించే ముందు.
ఉదాహరణకు
వేరు PMEM-CSI ఆల్ఫా దశలో ఉన్న అన్ని లక్షణాలతో QEMU వర్చువల్ మిషన్‌ల లోపల కుబెర్నెటెస్ 1.19 క్లస్టర్‌ను అమలు చేయడానికి అవసరమైన అన్ని మార్పులను కలిగి ఉంది. డ్రైవర్ కోడ్ మారలేదు, విస్తరణ మాత్రమే మార్చబడింది.
తగిన మెషీన్‌లో (Linux, ఒక సాధారణ వినియోగదారు ఉపయోగించవచ్చు , చూడండి వివరాలు) ఈ ఆదేశాలు క్లస్టర్‌ను తెస్తాయి మరియు 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 -
CSIStorageCapacity వస్తువులు మానవులు చదవడానికి ఉద్దేశించినవి కావు, కాబట్టి కొంత ప్రాసెసింగ్ అవసరం. గోలాంగ్ టెంప్లేట్ ఫిల్టర్‌లు నిల్వ తరగతులను చూపుతాయి, ఈ ఉదాహరణ పేరు, టోపోలాజీ మరియు సామర్థ్యాన్ని చూపుతుంది:
$ 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