వేదిక సృష్టిని క్రమబద్ధీకరించడానికి మిమ్మల్ని అనుమతిస్తుంది , క్లౌడ్ సర్వీస్ ప్రొవైడర్‌ల ఇన్‌ఫ్రాస్ట్రక్చర్‌తో సహా, వర్చువలైజేషన్ ప్లాట్‌ఫారమ్‌లలో లేదా బేర్-మెటల్ సిస్టమ్‌లలో. నిజంగా క్లౌడ్-ఆధారిత ప్లాట్‌ఫారమ్‌ను రూపొందించడానికి, మేము ఉపయోగించిన అన్ని మూలకాలపై కఠినమైన నియంత్రణను తీసుకోవాలి మరియు తద్వారా సంక్లిష్టమైన ఆటోమేషన్ ప్రక్రియ యొక్క విశ్వసనీయతను పెంచాలి.
స్పష్టమైన పరిష్కారం Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux యొక్క వేరియంట్) మరియు CRI-Oని ప్రమాణంగా ఉపయోగించడం, మరియు ఇక్కడ ఎందుకు...
కుబెర్నెట్స్ మరియు కంటైనర్ల పనిని వివరించేటప్పుడు సారూప్యతలను కనుగొనడానికి సెయిలింగ్ అంశం చాలా మంచిది కాబట్టి, ఒక ఉదాహరణను ఉపయోగించి CoreOS మరియు CRI-O పరిష్కరించే వ్యాపార సమస్యల గురించి మాట్లాడటానికి ప్రయత్నిద్దాం. . 1803లో, పెరుగుతున్న బ్రిటీష్ నౌకాదళ అవసరాల కోసం 100 రిగ్గింగ్ బ్లాక్‌లను ఉత్పత్తి చేసే బాధ్యత మార్క్ బ్రూనెల్‌కు ఉంది. రిగ్గింగ్ బ్లాక్ అనేది తెరచాపలకు తాడులను అటాచ్ చేయడానికి ఉపయోగించే ఒక రకమైన రిగ్గింగ్. 19వ శతాబ్దం ప్రారంభం వరకు, ఈ బ్లాక్‌లు చేతితో తయారు చేయబడ్డాయి, అయితే బ్రూనెల్ ఉత్పత్తిని ఆటోమేట్ చేయగలిగాడు మరియు యంత్ర పరికరాలను ఉపయోగించి ప్రామాణిక బ్లాక్‌లను ఉత్పత్తి చేయడం ప్రారంభించాడు. ఈ ప్రక్రియ యొక్క ఆటోమేషన్ అంటే ఫలితంగా వచ్చే బ్లాక్‌లు తప్పనిసరిగా ఒకేలా ఉంటాయి, విచ్ఛిన్నమైతే సులభంగా భర్తీ చేయబడతాయి మరియు పెద్ద పరిమాణంలో ఉత్పత్తి చేయబడతాయి.
బ్రూనెల్ ఈ పనిని 20 వేర్వేరు ఓడ నమూనాలు (కుబెర్నెటెస్ వెర్షన్లు) మరియు పూర్తిగా భిన్నమైన సముద్ర ప్రవాహాలు మరియు గాలులు (క్లౌడ్ ప్రొవైడర్లు) కలిగిన ఐదు వేర్వేరు గ్రహాల కోసం చేయవలసి వచ్చిందేమో ఇప్పుడు ఊహించండి. అదనంగా, నావిగేషన్ నిర్వహించబడే గ్రహాలతో సంబంధం లేకుండా అన్ని నౌకలు (ఓపెన్‌షిఫ్ట్ క్లస్టర్‌లు), కెప్టెన్ల (క్లస్టర్‌ల ఆపరేషన్‌ను నిర్వహించే ఆపరేటర్లు) దృక్కోణం నుండి ఒకే విధంగా ప్రవర్తించడం అవసరం. సముద్ర సారూప్యతను కొనసాగించడానికి, ఓడ కెప్టెన్లు తమ ఓడలలో ఎలాంటి రిగ్గింగ్ బ్లాక్‌లను (CRI-O) ఉపయోగిస్తున్నారనే విషయాన్ని అస్సలు పట్టించుకోరు - వారికి ప్రధాన విషయం ఏమిటంటే ఈ బ్లాక్‌లు బలంగా మరియు నమ్మదగినవి.
OpenShift 4, క్లౌడ్ ప్లాట్‌ఫారమ్‌గా, చాలా సారూప్య వ్యాపార సవాలును ఎదుర్కొంటుంది. క్లస్టర్ సృష్టి సమయంలో, నోడ్‌లలో ఒకదానిలో వైఫల్యం సంభవించినప్పుడు లేదా క్లస్టర్‌ను స్కేలింగ్ చేసేటప్పుడు కొత్త నోడ్‌లు తప్పనిసరిగా సృష్టించబడాలి. కొత్త నోడ్ సృష్టించబడినప్పుడు మరియు ప్రారంభించబడినప్పుడు, CRI-Oతో సహా క్లిష్టమైన హోస్ట్ భాగాలు తదనుగుణంగా కాన్ఫిగర్ చేయబడాలి. ఏదైనా ఇతర ఉత్పత్తిలో వలె, "ముడి పదార్థాలు" ప్రారంభంలో తప్పనిసరిగా సరఫరా చేయబడాలి. ఓడల విషయంలో, ముడి పదార్థాలు లోహం మరియు కలప. అయితే, OpenShift 4 క్లస్టర్‌లో కంటైనర్‌లను అమర్చడం కోసం హోస్ట్‌ను సృష్టించే సందర్భంలో, మీరు ఇన్‌పుట్‌గా కాన్ఫిగరేషన్ ఫైల్‌లు మరియు API అందించిన సర్వర్‌లను కలిగి ఉండాలి. OpenShift మొత్తం జీవిత చక్రంలో అవసరమైన స్థాయి ఆటోమేషన్‌ను అందిస్తుంది, తుది వినియోగదారులకు అవసరమైన ఉత్పత్తి మద్దతును అందిస్తుంది మరియు తద్వారా ప్లాట్‌ఫారమ్‌లో పెట్టుబడిని తిరిగి పొందుతుంది.
ఓపెన్‌షిఫ్ట్ 4 అన్ని ప్రధాన క్లౌడ్ కంప్యూటింగ్ ప్రొవైడర్లు, వర్చువలైజేషన్ ప్లాట్‌ఫారమ్‌లు మరియు బేర్ మెటల్ సిస్టమ్‌ల కోసం ప్లాట్‌ఫారమ్ యొక్క మొత్తం జీవిత చక్రంలో (4.X వెర్షన్‌ల కోసం) సౌకర్యవంతంగా సిస్టమ్‌ను నవీకరించే సామర్థ్యాన్ని అందించే విధంగా సృష్టించబడింది. దీన్ని చేయడానికి, మార్చుకోగలిగిన మూలకాల ఆధారంగా నోడ్లను సృష్టించాలి. క్లస్టర్‌కి కుబెర్నెట్స్ యొక్క కొత్త వెర్షన్ అవసరమైనప్పుడు, అది CoreOSలో CRI-O యొక్క సంబంధిత వెర్షన్‌ను కూడా అందుకుంటుంది. CRI-O వెర్షన్ నేరుగా కుబెర్నెట్స్‌తో ముడిపడి ఉన్నందున, ఇది టెస్టింగ్, ట్రబుల్షూటింగ్ లేదా సపోర్ట్ ప్రయోజనాల కోసం ఏదైనా ప్రస్తారణలను చాలా సులభతరం చేస్తుంది. అదనంగా, ఈ విధానం తుది వినియోగదారులు మరియు Red Hat కోసం ఖర్చులను తగ్గిస్తుంది.
ఇది కుబెర్నెటెస్ క్లస్టర్‌ల గురించి ఆలోచించే ప్రాథమికంగా కొత్త మార్గం మరియు కొన్ని చాలా ఉపయోగకరమైన మరియు ఆకట్టుకునే కొత్త ఫీచర్‌లను ప్లాన్ చేయడానికి పునాది వేస్తుంది. CRI-O (కంటైనర్ రన్‌టైమ్ ఇంటర్‌ఫేస్ - ఓపెన్ కంటైనర్ ఇనిషియేటివ్, సంక్షిప్త CRI-OCI) ఓపెన్‌షిఫ్ట్‌తో పని చేయడానికి అవసరమైన నోడ్‌ల భారీ సృష్టికి అత్యంత విజయవంతమైన ఎంపికగా మారింది. CRI-O మునుపు ఉపయోగించిన డాకర్ ఇంజిన్‌ను భర్తీ చేస్తుంది, ఓపెన్‌షిఫ్ట్ వినియోగదారులను అందిస్తుంది – అవును, మీరు విన్నది నిజమే – కుబెర్నెటెస్‌తో పని చేయడానికి ప్రత్యేకంగా రూపొందించబడిన బోరింగ్ కంటైనర్ ఇంజిన్.
ఓపెన్ కంటైనర్ల ప్రపంచం
ప్రపంచం చాలా కాలంగా ఓపెన్ కంటైనర్ల వైపు కదులుతోంది. కుబెర్నెట్స్‌లో ఉన్నా, లేదా తక్కువ స్థాయిలో ఉన్నా, ప్రతి స్థాయిలో ఆవిష్కరణల పర్యావరణ వ్యవస్థలో ఫలితాలు.
ఇది అన్ని ఓపెన్ కంటైనర్లు ఇనిషియేటివ్ యొక్క సృష్టితో ప్రారంభమైంది . పని యొక్క ఈ ప్రారంభ దశలో, కంటైనర్ లక్షణాలు ఏర్పడ్డాయి и . సాధనాలు ఒకే ప్రమాణాన్ని ఉపయోగించగలవని ఇది నిర్ధారిస్తుంది మరియు వారితో పని చేయడానికి ఏకీకృత ఆకృతి. స్పెసిఫికేషన్లు తర్వాత జోడించబడ్డాయి , వినియోగదారులు సులభంగా భాగస్వామ్యం చేయడానికి అనుమతిస్తుంది .
కుబెర్నెటెస్ కమ్యూనిటీ అప్పుడు ప్లగ్ చేయదగిన ఇంటర్‌ఫేస్ కోసం ఒకే ప్రమాణాన్ని అభివృద్ధి చేసింది . దీనికి ధన్యవాదాలు, Kubernetes వినియోగదారులు డాకర్‌తో పాటు కంటైనర్‌లతో పనిచేయడానికి వివిధ ఇంజిన్‌లను కనెక్ట్ చేయగలిగారు.
Red Hat మరియు Googleలోని ఇంజనీర్లు CRI ప్రోటోకాల్‌పై Kubelet అభ్యర్థనలను ఆమోదించగల కంటైనర్ ఇంజిన్ కోసం మార్కెట్ అవసరాన్ని చూసారు మరియు పైన పేర్కొన్న OCI స్పెసిఫికేషన్‌లకు అనుకూలంగా ఉండే కంటైనర్‌లను ప్రవేశపెట్టారు. కాబట్టి . అయితే నన్ను క్షమించండి, ఈ మెటీరియల్ CRI-Oకి అంకితం చేయబడుతుందని మేము చెప్పలేదా? వాస్తవానికి ఇది విడుదలతో మాత్రమే ప్రాజెక్ట్ CRI-O గా పేరు మార్చబడింది.
అంజీర్. 1.
CRI-O మరియు CoreOSతో ఆవిష్కరణ
ఓపెన్‌షిఫ్ట్ 4 ప్లాట్‌ఫారమ్ ప్రారంభించడంతో, అది మార్చబడింది , ప్లాట్‌ఫారమ్‌లో డిఫాల్ట్‌గా ఉపయోగించబడుతుంది మరియు డాకర్ CRI-O ద్వారా భర్తీ చేయబడింది, ఇది కుబెర్నెటెస్‌తో సమాంతరంగా అభివృద్ధి చెందుతున్న కంటైనర్‌ను అమలు చేయడానికి ఖర్చుతో కూడుకున్న, స్థిరమైన, సరళమైన మరియు బోరింగ్ వాతావరణాన్ని అందిస్తుంది. ఇది క్లస్టర్ మద్దతు మరియు కాన్ఫిగరేషన్‌ను చాలా సులభతరం చేస్తుంది. కంటైనర్ ఇంజిన్ మరియు హోస్ట్ యొక్క కాన్ఫిగరేషన్, అలాగే వాటి నిర్వహణ, OpenShift 4లో స్వయంచాలకంగా మారుతుంది.
వేచి ఉండండి, ఇది ఎలా ఉంది?
సరిగ్గా, OpenShift 4 రావడంతో, ఇకపై వ్యక్తిగత హోస్ట్‌లకు కనెక్ట్ చేసి కంటైనర్ ఇంజిన్‌ను ఇన్‌స్టాల్ చేయడం, నిల్వను కాన్ఫిగర్ చేయడం, శోధన సర్వర్‌లను కాన్ఫిగర్ చేయడం లేదా నెట్‌వర్క్‌ను కాన్ఫిగర్ చేయడం అవసరం లేదు. OpenShift 4 ప్లాట్‌ఫారమ్‌ను ఉపయోగించడానికి పూర్తిగా పునఃరూపకల్పన చేయబడింది తుది వినియోగదారు అప్లికేషన్‌ల పరంగా మాత్రమే కాకుండా, ఇమేజ్‌లను అమర్చడం, సిస్టమ్‌ను కాన్ఫిగర్ చేయడం లేదా అప్‌డేట్‌లను ఇన్‌స్టాల్ చేయడం వంటి ప్రాథమిక ప్లాట్‌ఫారమ్-స్థాయి కార్యకలాపాల పరంగా కూడా.
కోరుకున్న స్థితిని నిర్వచించడం ద్వారా మరియు ఉపయోగించడం ద్వారా అప్లికేషన్‌లను నిర్వహించడానికి Kubernetes ఎల్లప్పుడూ వినియోగదారులను అనుమతించింది , వాస్తవ స్థితి లక్ష్య స్థితికి వీలైనంత దగ్గరగా సరిపోలుతుందని నిర్ధారించడానికి. ఈ అభివృద్ధి మరియు కార్యకలాపాల దృక్కోణం నుండి గొప్ప అవకాశాలను తెరుస్తుంది. డెవలపర్లు అవసరమైన స్థితిని దీని ద్వారా నిర్వచించగలరు YAML లేదా JSON ఫైల్ రూపంలో ఆపరేటర్‌కు, ఆపై ఆపరేటర్ ఉత్పత్తి వాతావరణంలో అవసరమైన అప్లికేషన్ ఉదాహరణను సృష్టించవచ్చు మరియు ఈ ఉదాహరణ యొక్క ఆపరేటింగ్ స్థితి పూర్తిగా పేర్కొన్న దానికి అనుగుణంగా ఉంటుంది.
ప్లాట్‌ఫారమ్‌లో ఆపరేటర్‌లను ఉపయోగించడం ద్వారా, ఓపెన్‌షిఫ్ట్ 4 ఈ కొత్త నమూనాను (సెట్ మరియు వాస్తవ స్థితి భావనను ఉపయోగించి) RHEL CoreOS మరియు CRI-O నిర్వహణకు తీసుకువస్తుంది. ఆపరేటింగ్ సిస్టమ్ మరియు కంటైనర్ ఇంజిన్ యొక్క సంస్కరణలను కాన్ఫిగర్ చేయడం మరియు నిర్వహించడం యొక్క పనులు అని పిలవబడే వాటిని ఉపయోగించి స్వయంచాలకంగా ఉంటాయి. . MCO క్లస్టర్ అడ్మినిస్ట్రేటర్ యొక్క పనిని చాలా సులభతరం చేస్తుంది, ముఖ్యంగా ఇన్‌స్టాలేషన్ చివరి దశలను ఆటోమేట్ చేస్తుంది, అలాగే తదుపరి ఇన్‌స్టాలేషన్ ఆపరేషన్లు (రోజు రెండు కార్యకలాపాలు). ఇవన్నీ OpenShift 4ని నిజమైన క్లౌడ్ ప్లాట్‌ఫారమ్‌గా చేస్తాయి. మేము కొంచెం తరువాత దీనిలోకి ప్రవేశిస్తాము.
నడుస్తున్న కంటైనర్లు
వినియోగదారులు టెక్ ప్రివ్యూ స్టేటస్‌లో వెర్షన్ 3.7 నుండి ఓపెన్‌షిఫ్ట్ ప్లాట్‌ఫారమ్‌లో CRI-O ఇంజిన్‌ను ఉపయోగించుకునే అవకాశాన్ని కలిగి ఉన్నారు మరియు సాధారణంగా అందుబాటులో ఉన్న స్థితిలో (ప్రస్తుతం మద్దతు ఉంది) వెర్షన్ 3.9 నుండి. అదనంగా, Red Hat భారీగా ఉపయోగిస్తుంది వెర్షన్ 3.10 నుండి OpenShift ఆన్‌లైన్‌లో. ఇవన్నీ CRI-Oలో పని చేస్తున్న బృందాన్ని పెద్ద కుబెర్నెట్స్ క్లస్టర్‌లపై మాస్ లాంచ్ కంటైనర్‌లలో విస్తృతమైన అనుభవాన్ని పొందేందుకు అనుమతించాయి. కుబెర్నెటెస్ CRI-Oని ఎలా ఉపయోగిస్తుందనే దాని గురించి ప్రాథమిక అవగాహన పొందడానికి, ఆర్కిటెక్చర్ ఎలా పనిచేస్తుందో చూపే క్రింది దృష్టాంతాన్ని చూద్దాం.
అన్నం. 2. కుబెర్నెట్స్ క్లస్టర్‌లో కంటైనర్లు ఎలా పని చేస్తాయి
CRI-O కొత్త నోడ్లను ప్రారంభించేటప్పుడు మరియు ఓపెన్‌షిఫ్ట్ ప్లాట్‌ఫారమ్ యొక్క కొత్త వెర్షన్‌లను విడుదల చేసేటప్పుడు పూర్తి స్థాయిని సమకాలీకరించడం ద్వారా కొత్త కంటైనర్ హోస్ట్‌ల సృష్టిని సులభతరం చేస్తుంది. మొత్తం ప్లాట్‌ఫారమ్ యొక్క పునర్విమర్శ లావాదేవీల అప్‌డేట్‌లు/రోల్‌బ్యాక్‌లను అనుమతిస్తుంది మరియు కంటైనర్ టెయిల్ కోర్, కంటైనర్ ఇంజిన్, నోడ్స్ (కుబెలెట్స్) మరియు కుబెర్నెట్స్ మాస్టర్ నోడ్ మధ్య డిపెండెన్సీలలో డెడ్‌లాక్‌లను నిరోధిస్తుంది. నియంత్రణ మరియు సంస్కరణతో అన్ని ప్లాట్‌ఫారమ్ భాగాలను కేంద్రీయంగా నిర్వహించడం ద్వారా, రాష్ట్రం A నుండి స్థితి Bకి ఎల్లప్పుడూ స్పష్టమైన మార్గం ఉంటుంది. ఇది నవీకరణ ప్రక్రియను సులభతరం చేస్తుంది, భద్రతను మెరుగుపరుస్తుంది, పనితీరు రిపోర్టింగ్‌ను మెరుగుపరుస్తుంది మరియు కొత్త సంస్కరణల నవీకరణలు మరియు ఇన్‌స్టాలేషన్‌ల ధరను తగ్గించడంలో సహాయపడుతుంది. .
భర్తీ మూలకాల యొక్క శక్తిని ప్రదర్శిస్తుంది
ముందే చెప్పినట్లుగా, OpenShift 4లో కంటైనర్ హోస్ట్ మరియు కంటైనర్ ఇంజిన్‌ను నిర్వహించడానికి మెషిన్ కాన్ఫిగ్ ఆపరేటర్‌ని ఉపయోగించడం ద్వారా కుబెర్నెటెస్ ప్లాట్‌ఫారమ్‌లో గతంలో సాధ్యం కాని కొత్త స్థాయి ఆటోమేషన్‌ను అందిస్తుంది. కొత్త ఫీచర్‌లను ప్రదర్శించడానికి, మీరు crio.conf ఫైల్‌కి ఎలా మార్పులు చేయవచ్చో మేము చూపుతాము. పదజాలంతో గందరగోళం చెందకుండా ఉండటానికి, ఫలితాలపై దృష్టి పెట్టడానికి ప్రయత్నించండి.
ముందుగా, కంటైనర్ రన్‌టైమ్ కాన్ఫిగరేషన్ అని పిలవబడే దాన్ని క్రియేట్ చేద్దాం - కంటైనర్ రన్‌టైమ్ కాన్ఫిగరేషన్. CRI-O కోసం కాన్ఫిగరేషన్‌ను సూచించే కుబెర్నెట్స్ వనరుగా భావించండి. వాస్తవానికి, ఇది MachineConfig అని పిలువబడే దాని యొక్క ప్రత్యేక సంస్కరణ, ఇది OpenShift క్లస్టర్‌లో భాగంగా RHEL CoreOS మెషీన్‌కు అమలు చేయబడిన ఏదైనా కాన్ఫిగరేషన్.
CRI-Oని కాన్ఫిగర్ చేయడానికి క్లస్టర్ నిర్వాహకులకు సులభతరం చేయడానికి ContainerRuntimeConfig అని పిలువబడే ఈ అనుకూల వనరు సృష్టించబడింది. ఈ సాధనం తగినంత శక్తివంతమైనది, ఇది MachineConfigPool సెట్టింగ్‌లపై ఆధారపడి నిర్దిష్ట నోడ్‌లకు మాత్రమే వర్తించబడుతుంది. అదే ప్రయోజనాన్ని అందించే యంత్రాల సమూహంగా భావించండి.
/etc/crio/crio.conf ఫైల్‌లో మనం మార్చబోతున్న చివరి రెండు పంక్తులను గమనించండి. ఈ రెండు పంక్తులు crio.conf ఫైల్‌లోని పంక్తులకు చాలా పోలి ఉంటాయి, అవి:
vi ContainerRuntimeConfig.yaml
తీర్మానం:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
ఇప్పుడు ఈ ఫైల్‌ని కుబెర్నెట్స్ క్లస్టర్‌కి పుష్ చేద్దాం మరియు ఇది నిజంగా సృష్టించబడిందో లేదో తనిఖీ చేద్దాం. ఏదైనా ఇతర కుబెర్నెట్స్ వనరుతో ఆపరేషన్ సరిగ్గా అదే విధంగా ఉంటుందని దయచేసి గమనించండి:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
తీర్మానం:
NAME AGE
set-log-and-pid 22h
మేము ContainerRuntimeConfigని సృష్టించిన తర్వాత, మేము ఈ కాన్ఫిగరేషన్‌ను క్లస్టర్‌లోని నిర్దిష్ట సమూహ మెషీన్‌లకు వర్తింపజేయాలనుకుంటున్నామని కుబెర్నెట్‌లకు సూచించడానికి MachineConfigPoolsలో ఒకదానిని సవరించాలి. ఈ సందర్భంలో మేము మాస్టర్ నోడ్‌ల కోసం MachineConfigPoolని మారుస్తాము:
oc edit MachineConfigPool/master
ముగింపు (స్పష్టత కోసం, ప్రధాన సారాంశం మిగిలి ఉంది):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
ఈ సమయంలో, MCO క్లస్టర్ కోసం కొత్త crio.conf ఫైల్‌ను సృష్టించడం ప్రారంభిస్తుంది. ఈ సందర్భంలో, పూర్తిగా పూర్తయిన కాన్ఫిగరేషన్ ఫైల్‌ను Kubernetes API ఉపయోగించి వీక్షించవచ్చు. గుర్తుంచుకోండి, ContainerRuntimeConfig అనేది MachineConfig యొక్క ప్రత్యేక సంస్కరణ మాత్రమే, కాబట్టి మేము MachineConfigsలోని సంబంధిత లైన్‌లను చూడటం ద్వారా ఫలితాన్ని చూడవచ్చు:
oc get MachineConfigs | grep rendered
తీర్మానం:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
మాస్టర్ నోడ్‌ల కోసం ఫలిత కాన్ఫిగరేషన్ ఫైల్ అసలు కాన్ఫిగరేషన్‌ల కంటే కొత్త వెర్షన్ అని దయచేసి గమనించండి. దీన్ని వీక్షించడానికి, కింది ఆదేశాన్ని అమలు చేయండి. పాసింగ్‌లో, ఇది బహుశా కుబెర్నెటీస్ చరిత్రలో అత్యుత్తమ వన్-లైనర్‌లలో ఒకటి అని మేము గమనించాము:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
తీర్మానం:
pids_limit = 2048
ఇప్పుడు కాన్ఫిగరేషన్ అన్ని మాస్టర్ నోడ్‌లకు వర్తింపజేయబడిందని నిర్ధారించుకోండి. మొదట మేము క్లస్టర్‌లోని నోడ్‌ల జాబితాను పొందుతాము:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ఇప్పుడు ఇన్‌స్టాల్ చేసిన ఫైల్‌ని చూద్దాం. ContainerRuntimeConfig రిసోర్స్‌లో మేము పేర్కొన్న పిడ్ మరియు డీబగ్ డైరెక్టివ్‌ల కోసం ఫైల్ కొత్త విలువలతో నవీకరించబడిందని మీరు చూస్తారు. చక్కదనం స్వయంగా:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
తీర్మానం:
...
pids_limit = 2048
...
log_level = "debug"
...
క్లస్టర్‌కి ఈ మార్పులన్నీ SSHని కూడా అమలు చేయకుండానే చేయబడ్డాయి. కుబెరెంటెస్ మాస్టర్ నోడ్‌ని యాక్సెస్ చేయడం ద్వారా అన్ని పనులు జరిగాయి. అంటే, ఈ కొత్త పారామితులు మాస్టర్ నోడ్‌లలో మాత్రమే కాన్ఫిగర్ చేయబడ్డాయి. వర్కర్ నోడ్‌లు మారలేదు, ఇది కంటైనర్ హోస్ట్‌లు మరియు మార్చుకోగలిగిన మూలకాలతో కంటైనర్ ఇంజిన్‌లకు సంబంధించి పేర్కొన్న మరియు వాస్తవ స్థితులను ఉపయోగించే కుబెర్నెట్స్ పద్దతి యొక్క ప్రయోజనాలను ప్రదర్శిస్తుంది.
ఎగువ ఉదాహరణ మూడు ఉత్పత్తి నోడ్‌లతో కూడిన చిన్న OpenShift కంటైనర్ ప్లాట్‌ఫారమ్ 4 క్లస్టర్‌కు లేదా 3000 నోడ్‌లతో కూడిన భారీ ఉత్పత్తి క్లస్టర్‌కు మార్పులు చేయగల సామర్థ్యాన్ని చూపుతుంది. ఏదైనా సందర్భంలో, పని మొత్తం ఒకే విధంగా ఉంటుంది - మరియు చాలా చిన్నది - కేవలం ContainerRuntimeConfig ఫైల్‌ను కాన్ఫిగర్ చేసి, MachineConfigPoolలో ఒక లేబుల్‌ని మార్చండి. మరియు మీరు దీన్ని OpenShift కంటైనర్ ప్లాట్‌ఫారమ్ 4.X యొక్క ఏదైనా వెర్షన్‌తో దాని జీవితచక్రం అంతటా నడుస్తున్న Kubernetesతో చేయవచ్చు.
తరచుగా సాంకేతిక సంస్థలు చాలా త్వరగా అభివృద్ధి చెందుతాయి, మేము అంతర్లీన భాగాల కోసం నిర్దిష్ట సాంకేతికతలను ఎందుకు ఎంచుకుంటామో వివరించలేము. కంటైనర్ ఇంజిన్‌లు చారిత్రాత్మకంగా వినియోగదారులు నేరుగా సంభాషించే భాగం. కంటైనర్ల యొక్క ప్రజాదరణ సహజంగా కంటైనర్ ఇంజిన్ల ఆగమనంతో ప్రారంభమైంది కాబట్టి, వినియోగదారులు తరచుగా వాటిపై ఆసక్తి చూపుతారు. Red Hat CRI-Oని ఎంచుకోవడానికి ఇది మరొక కారణం. ఇప్పుడు ఆర్కెస్ట్రేషన్‌పై దృష్టి సారించి కంటైనర్లు అభివృద్ధి చెందుతున్నాయి మరియు OpenShift 4తో పనిచేసేటప్పుడు CRI-O అత్యుత్తమ అనుభవాన్ని అందిస్తుందని మేము కనుగొన్నాము.
మూలం: www.habr.com