કન્વેયરથી કન્વેયર: CRI-O હવે OpenShift કન્ટેનર પ્લેટફોર્મ 4 માં ડિફોલ્ટ છે

પ્લેટફોર્મ રેડ હેટ ઓપનશીફ્ટ કન્ટેનર પ્લેટફોર્મ 4 તમને રચનાને સુવ્યવસ્થિત કરવાની મંજૂરી આપે છે કન્ટેનર જમાવવા માટે યજમાનો, ક્લાઉડ સેવા પ્રદાતાઓના ઈન્ફ્રાસ્ટ્રક્ચરમાં, વર્ચ્યુઅલાઈઝેશન પ્લેટફોર્મ્સ પર અથવા બેર-મેટલ સિસ્ટમ્સમાં. સાચા અર્થમાં ક્લાઉડ-આધારિત પ્લેટફોર્મ બનાવવા માટે, અમારે ઉપયોગમાં લેવાતા તમામ ઘટકો પર કડક નિયંત્રણ રાખવું પડ્યું અને આ રીતે જટિલ ઓટોમેશન પ્રક્રિયાની વિશ્વસનીયતા વધારવી પડી.

સ્પષ્ટ ઉકેલ એ Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux નું એક પ્રકાર) અને CRI-O ને પ્રમાણભૂત તરીકે વાપરવાનું હતું, અને અહીં શા માટે...

કુબરનેટ્સ અને કન્ટેનરના કામને સમજાવતી વખતે સઢવાળો વિષય સામ્યતા શોધવા માટે ખૂબ જ સારો હોવાથી, ચાલો ઉદાહરણનો ઉપયોગ કરીને CoreOS અને CRI-O દ્વારા ઉકેલાતી વ્યવસાયિક સમસ્યાઓ વિશે વાત કરવાનો પ્રયાસ કરીએ. રિગિંગ બ્લોક્સના ઉત્પાદન માટે બ્રુનેલની શોધ. 1803 માં, માર્ક બ્રુનેલને વધતી જતી બ્રિટિશ નૌકાદળની જરૂરિયાતો માટે 100 રિગિંગ બ્લોક્સ બનાવવાનું કામ સોંપવામાં આવ્યું હતું. રિગિંગ બ્લોક એ એક પ્રકારનું રિગિંગ છે જેનો ઉપયોગ સેઇલ સાથે દોરડાને જોડવા માટે થાય છે. 19મી સદીની શરૂઆત સુધી, આ બ્લોક્સ હાથથી બનાવવામાં આવતા હતા, પરંતુ બ્રુનેલે ઉત્પાદનને સ્વચાલિત કરવામાં વ્યવસ્થાપિત કરી અને મશીન ટૂલ્સનો ઉપયોગ કરીને પ્રમાણિત બ્લોક્સ બનાવવાનું શરૂ કર્યું. આ પ્રક્રિયાના ઓટોમેશનનો અર્થ એ થયો કે પરિણામી બ્લોક્સ આવશ્યકપણે સમાન હતા, જો તૂટી જાય તો તેને સરળતાથી બદલી શકાય છે અને મોટા જથ્થામાં ઉત્પાદન કરી શકાય છે.

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

OpenShift 4, ક્લાઉડ પ્લેટફોર્મ તરીકે, ખૂબ જ સમાન બિઝનેસ પડકારનો સામનો કરે છે. નવા નોડ્સ ક્લસ્ટર બનાવતી વખતે, એક નોડ્સમાં નિષ્ફળતાના કિસ્સામાં અથવા ક્લસ્ટરને સ્કેલ કરતી વખતે બનાવવી આવશ્યક છે. જ્યારે નવો નોડ બનાવવામાં આવે છે અને પ્રારંભ કરવામાં આવે છે, ત્યારે CRI-O સહિત નિર્ણાયક હોસ્ટ ઘટકો, તે મુજબ ગોઠવેલા હોવા જોઈએ. અન્ય કોઈપણ ઉત્પાદનની જેમ, "કાચો માલ" શરૂઆતમાં પૂરો પાડવો આવશ્યક છે. જહાજોના કિસ્સામાં, કાચો માલ મેટલ અને લાકડું છે. જો કે, OpenShift 4 ક્લસ્ટરમાં કન્ટેનર જમાવવા માટે હોસ્ટ બનાવવાના કિસ્સામાં, તમારી પાસે ઇનપુટ તરીકે રૂપરેખાંકન ફાઇલો અને API- પ્રદાન કરેલ સર્વર્સ હોવા જરૂરી છે. OpenShift પછી સમગ્ર જીવન ચક્ર દરમ્યાન જરૂરી સ્તરનું ઓટોમેશન પૂરું પાડશે, જે અંતિમ વપરાશકર્તાઓને જરૂરી ઉત્પાદન સપોર્ટ ઓફર કરશે અને આમ પ્લેટફોર્મમાં રોકાણની પુનઃપ્રાપ્તિ કરશે.

OpenShift 4 એવી રીતે બનાવવામાં આવ્યું હતું કે તમામ મુખ્ય ક્લાઉડ કમ્પ્યુટિંગ પ્રદાતાઓ, વર્ચ્યુઅલાઈઝેશન પ્લેટફોર્મ્સ અને એકદમ મેટલ સિસ્ટમ્સ માટે પ્લેટફોર્મના સમગ્ર જીવન ચક્ર દરમિયાન (સંસ્કરણ 4.X માટે) સિસ્ટમને અનુકૂળ રીતે અપડેટ કરવાની ક્ષમતા પ્રદાન કરવા માટે. આ કરવા માટે, વિનિમયક્ષમ તત્વોના આધારે ગાંઠો બનાવવી આવશ્યક છે. જ્યારે ક્લસ્ટરને કુબરનેટ્સના નવા સંસ્કરણની જરૂર હોય, ત્યારે તે CoreOS પર CRI-O નું અનુરૂપ સંસ્કરણ પણ મેળવે છે. CRI-O સંસ્કરણ સીધા કુબરનેટ્સ સાથે જોડાયેલું હોવાથી, આ પરીક્ષણ, મુશ્કેલીનિવારણ અથવા સમર્થન હેતુઓ માટે કોઈપણ ક્રમચયોને મોટા પ્રમાણમાં સરળ બનાવે છે. વધુમાં, આ અભિગમ અંતિમ વપરાશકર્તાઓ અને Red Hat માટે ખર્ચ ઘટાડે છે.

કુબરનેટ્સ ક્લસ્ટરો વિશે વિચારવાની આ મૂળભૂત રીતે નવી રીત છે અને કેટલીક ખૂબ જ ઉપયોગી અને આકર્ષક નવી સુવિધાઓના આયોજન માટે પાયો નાખે છે. CRI-O (કન્ટેનર રનટાઇમ ઇન્ટરફેસ - ઓપન કન્ટેનર ઇનિશિયેટિવ, સંક્ષિપ્તમાં CRI-OCI) નોડ્સના સામૂહિક નિર્માણ માટે સૌથી સફળ પસંદગી હોવાનું બહાર આવ્યું છે જે ઓપનશિફ્ટ સાથે કામ કરવા માટે જરૂરી છે. CRI-O અગાઉ ઉપયોગમાં લેવાતા ડોકર એન્જિનને બદલશે, ઓપનશિફ્ટ વપરાશકર્તાઓને ઓફર કરશે આર્થિક, સ્થિર, સરળ અને કંટાળાજનક – હા, તમે સાચું સાંભળ્યું – કંટાળાજનક કન્ટેનર એન્જિન ખાસ કરીને કુબરનેટ્સ સાથે કામ કરવા માટે બનાવવામાં આવ્યું છે.

ખુલ્લા કન્ટેનરની દુનિયા

વિશ્વ લાંબા સમયથી ખુલ્લા કન્ટેનર તરફ આગળ વધી રહ્યું છે. ભલે કુબરનેટ્સમાં હોય, અથવા નીચલા સ્તરે, કન્ટેનર ધોરણોનો વિકાસ દરેક સ્તરે નવીનતાની ઇકોસિસ્ટમમાં પરિણમે છે.

તે બધું ઓપન કન્ટેનર ઇનિશિયેટિવની રચના સાથે શરૂ થયું જૂન 2015 માં. કામના આ પ્રારંભિક તબક્કે, કન્ટેનર વિશિષ્ટતાઓ બનાવવામાં આવી હતી છબી и રનટાઇમ પર્યાવરણ. આ સુનિશ્ચિત કરે છે કે સાધનો એક જ ધોરણનો ઉપયોગ કરી શકે છે કન્ટેનર છબીઓ અને તેમની સાથે કામ કરવા માટે એકીકૃત ફોર્મેટ. સ્પષ્ટીકરણો પાછળથી ઉમેરવામાં આવ્યા હતા વિતરણ, વપરાશકર્તાઓ સરળતાથી શેર કરવા માટે પરવાનગી આપે છે કન્ટેનર છબીઓ.

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

Red Hat અને Googleના એન્જિનિયરોએ બજારને કન્ટેનર એન્જિનની જરૂરિયાત જોઈ કે જે CRI પ્રોટોકોલ પર કુબેલેટની વિનંતીઓ સ્વીકારી શકે અને ઉપર જણાવેલ OCI સ્પષ્ટીકરણો સાથે સુસંગત હોય તેવા કન્ટેનર રજૂ કર્યા. તેથી OCID દેખાયો. પણ માફ કરશો, શું અમે એવું નથી કહ્યું કે આ સામગ્રી CRI-O ને સમર્પિત કરવામાં આવશે? વાસ્તવમાં તે માત્ર પ્રકાશન સાથે છે સંસ્કરણ 1.0 પ્રોજેક્ટનું નામ બદલીને CRI-O રાખવામાં આવ્યું.

ફિગ. 1.

CRI-O અને CoreOS સાથે નવીનતા

OpenShift 4 પ્લેટફોર્મની શરૂઆત સાથે, તે બદલાઈ ગયું હતું કન્ટેનર એન્જિન, પ્લેટફોર્મમાં ડિફૉલ્ટ રૂપે ઉપયોગમાં લેવાય છે, અને ડોકરને CRI-O દ્વારા બદલવામાં આવ્યું હતું, જે કુબરનેટ્સ સાથે સમાંતર રીતે વિકસિત કન્ટેનર ચલાવવા માટે ખર્ચ-અસરકારક, સ્થિર, સરળ અને કંટાળાજનક વાતાવરણ પ્રદાન કરે છે. આ ક્લસ્ટર સપોર્ટ અને રૂપરેખાંકનને મોટા પ્રમાણમાં સરળ બનાવે છે. કન્ટેનર એન્જિન અને હોસ્ટનું રૂપરેખાંકન, તેમજ તેમનું સંચાલન, OpenShift 4 ની અંદર સ્વયંસંચાલિત બને છે.

રાહ જુઓ, આ કેવી રીતે છે?

તે સાચું છે, OpenShift 4 ના આગમન સાથે, હવે વ્યક્તિગત યજમાનો સાથે કનેક્ટ કરવાની અને કન્ટેનર એન્જિન ઇન્સ્ટોલ કરવાની, સ્ટોરેજ ગોઠવવાની, શોધ સર્વર્સને ગોઠવવાની અથવા નેટવર્કને ગોઠવવાની જરૂર નથી. OpenShift 4 પ્લેટફોર્મનો ઉપયોગ કરવા માટે સંપૂર્ણપણે ફરીથી ડિઝાઇન કરવામાં આવ્યું છે ઓપરેટર ફ્રેમવર્ક માત્ર અંતિમ-વપરાશકર્તા એપ્લિકેશનોના સંદર્ભમાં જ નહીં, પણ મૂળભૂત પ્લેટફોર્મ-સ્તરની કામગીરી જેમ કે છબીઓ જમાવવી, સિસ્ટમને ગોઠવવી અથવા અપડેટ્સ ઇન્સ્ટોલ કરવી.

Kubernetes હંમેશા વપરાશકર્તાઓને ઇચ્છિત સ્થિતિ વ્યાખ્યાયિત કરીને અને ઉપયોગ કરીને એપ્લિકેશનને સંચાલિત કરવાની મંજૂરી આપે છે નિયંત્રકો, ખાતરી કરવા માટે કે વાસ્તવિક સ્થિતિ લક્ષ્ય રાજ્ય સાથે શક્ય તેટલી નજીકથી મેળ ખાય છે. આ લક્ષ્ય રાજ્ય અને વાસ્તવિક રાજ્ય અભિગમ વિકાસ અને કામગીરી બંને દ્રષ્ટિકોણથી મહાન તકો ખોલે છે. વિકાસકર્તાઓ દ્વારા આવશ્યક સ્થિતિને વ્યાખ્યાયિત કરી શકે છે તેને પસાર કરો YAML અથવા JSON ફાઇલના રૂપમાં ઑપરેટરને મોકલો, અને પછી ઑપરેટર પ્રોડક્શન એન્વાયર્નમેન્ટમાં જરૂરી ઍપ્લિકેશન ઇન્સ્ટન્સ બનાવી શકે છે, અને આ ઇન્સ્ટન્સની ઑપરેટિંગ સ્થિતિ સંપૂર્ણપણે ઉલ્લેખિત એકને અનુરૂપ હશે.

પ્લેટફોર્મમાં ઓપરેટર્સનો ઉપયોગ કરીને, OpenShift 4 RHEL CoreOS અને CRI-O ના સંચાલન માટે આ નવો દાખલો (સેટ અને વાસ્તવિક સ્થિતિનો ઉપયોગ કરીને) લાવે છે. ઓપરેટિંગ સિસ્ટમ અને કન્ટેનર એન્જિનના વર્ઝનને ગોઠવવા અને મેનેજ કરવાના કાર્યો કહેવાતા ઉપયોગ કરીને સ્વચાલિત છે મશીન રૂપરેખા ઓપરેટર (MCO). MCO ક્લસ્ટર એડમિનિસ્ટ્રેટરના કાર્યને મોટા પ્રમાણમાં સરળ બનાવે છે, અનિવાર્યપણે ઇન્સ્ટોલેશનના છેલ્લા તબક્કાઓ, તેમજ અનુગામી પોસ્ટ-ઇન્સ્ટોલેશન કામગીરી (દિવસ બે કામગીરી) ને સ્વચાલિત કરે છે. આ બધું OpenShift 4 ને સાચું ક્લાઉડ પ્લેટફોર્મ બનાવે છે. અમે થોડી વાર પછી આમાં પ્રવેશ કરીશું.

કન્ટેનર ચાલી રહ્યું છે

વપરાશકર્તાઓને ટેક પ્રીવ્યુ સ્ટેટસમાં વર્ઝન 3.7 થી અને સામાન્ય રીતે ઉપલબ્ધ સ્ટેટસમાં (હાલમાં સપોર્ટેડ) વર્ઝન 3.9 થી OpenShift પ્લેટફોર્મમાં CRI-O એન્જિનનો ઉપયોગ કરવાની તક મળી છે. વધુમાં, Red Hat મોટા પાયે ઉપયોગ કરે છે ઉત્પાદન વર્કલોડ ચલાવવા માટે CRI-O આવૃત્તિ 3.10 થી OpenShift Online માં. આ બધાએ CRI-O પર કામ કરતી ટીમને મોટા કુબરનેટ્સ ક્લસ્ટરો પર સામૂહિક લોંચિંગ કન્ટેનરમાં વ્યાપક અનુભવ મેળવવાની મંજૂરી આપી. કુબરનેટ્સ CRI-O નો ઉપયોગ કેવી રીતે કરે છે તેની મૂળભૂત સમજ મેળવવા માટે, ચાલો નીચેના ચિત્રને જોઈએ, જે દર્શાવે છે કે આર્કિટેક્ચર કેવી રીતે કાર્ય કરે છે.

ચોખા. 2. કુબરનેટ્સ ક્લસ્ટરમાં કન્ટેનર કેવી રીતે કાર્ય કરે છે

CRI-O નવા નોડ્સની શરૂઆત કરતી વખતે અને OpenShift પ્લેટફોર્મના નવા સંસ્કરણો બહાર પાડતી વખતે સમગ્ર ટોચના સ્તરને સિંક્રનાઇઝ કરીને નવા કન્ટેનર હોસ્ટની રચનાને સરળ બનાવે છે. સમગ્ર પ્લેટફોર્મનું પુનરાવર્તન ટ્રાન્ઝેક્શનલ અપડેટ્સ/રોલબેક માટે પરવાનગી આપે છે, અને કન્ટેનર ટેલ કોર, કન્ટેનર એન્જિન, નોડ્સ (કુબેલેટ્સ) અને કુબરનેટ્સ માસ્ટર નોડ વચ્ચેની અવલંબનમાં અવરોધોને પણ અટકાવે છે. કંટ્રોલ અને વર્ઝનિંગ સાથે તમામ પ્લેટફોર્મ ઘટકોને કેન્દ્રિય રીતે મેનેજ કરીને, રાજ્ય A થી રાજ્ય B સુધીનો હંમેશા સ્પષ્ટ રસ્તો હોય છે. આ અપડેટ પ્રક્રિયાને સરળ બનાવે છે, સુરક્ષામાં સુધારો કરે છે, પર્ફોર્મન્સ રિપોર્ટિંગમાં સુધારો કરે છે અને નવા સંસ્કરણોના અપડેટ્સ અને ઇન્સ્ટોલેશનની કિંમત ઘટાડવામાં મદદ કરે છે. .

રિપ્લેસમેન્ટ તત્વોની શક્તિનું પ્રદર્શન

અગાઉ ઉલ્લેખ કર્યો છે તેમ, OpenShift 4 માં કન્ટેનર હોસ્ટ અને કન્ટેનર એન્જિનને મેનેજ કરવા માટે મશીન કન્ફિગ ઓપરેટરનો ઉપયોગ કરીને ઓટોમેશનનું નવું સ્તર પૂરું પાડે છે જે અગાઉ Kubernetes પ્લેટફોર્મ પર શક્ય ન હતું. નવી સુવિધાઓ દર્શાવવા માટે, અમે બતાવીશું કે તમે કેવી રીતે crio.conf ફાઇલમાં ફેરફારો કરી શકો છો. પરિભાષા દ્વારા મૂંઝવણમાં ન આવવા માટે, પરિણામો પર ધ્યાન કેન્દ્રિત કરવાનો પ્રયાસ કરો.

પ્રથમ, ચાલો બનાવીએ જેને કન્ટેનર રનટાઇમ રૂપરેખાંકન કહેવાય છે - કન્ટેનર રનટાઇમ રૂપરેખા. CRI-O માટે રૂપરેખાંકનનું પ્રતિનિધિત્વ કરતા કુબરનેટીસ સંસાધન તરીકે તેને વિચારો. વાસ્તવમાં, તે MachineConfig નામની કોઈ વસ્તુનું વિશિષ્ટ સંસ્કરણ છે, જે કોઈપણ રૂપરેખાંકન છે જે ઓપનશિફ્ટ ક્લસ્ટરના ભાગ રૂપે RHEL CoreOS મશીનમાં જમાવવામાં આવે છે.

આ વૈવિધ્યપૂર્ણ સંસાધન, જેને ContainerRuntimeConfig કહેવાય છે, તે ક્લસ્ટર સંચાલકો માટે CRI-O ને ગોઠવવાનું સરળ બનાવવા માટે બનાવવામાં આવ્યું હતું. આ સાધન એટલું શક્તિશાળી છે કે તે માત્ર 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 ફાઇલ બનાવવાનું શરૂ કરે છે. આ કિસ્સામાં, કુબરનેટ્સ 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 ચલાવ્યા વિના પણ કરવામાં આવ્યા હતા. કુબેરેન્ટેસ માસ્ટર નોડને ઍક્સેસ કરીને તમામ કાર્ય કરવામાં આવ્યું હતું. એટલે કે, આ નવા પરિમાણો માત્ર માસ્ટર નોડ્સ પર ગોઠવવામાં આવ્યા હતા. વર્કર નોડ્સ બદલાયા નથી, જે કન્ટેનર યજમાનો અને કન્ટેનર એન્જીનને બદલી શકાય તેવા તત્વો સાથેના સંબંધમાં ઉલ્લેખિત અને વાસ્તવિક સ્થિતિઓનો ઉપયોગ કરવાની કુબરનેટીસ પદ્ધતિના ફાયદા દર્શાવે છે.

ઉપરનું ઉદાહરણ ત્રણ પ્રોડક્શન નોડ્સવાળા નાના ઓપનશિફ્ટ કન્ટેનર પ્લેટફોર્મ 4 ક્લસ્ટરમાં અથવા 3000 નોડ્સવાળા વિશાળ પ્રોડક્શન ક્લસ્ટરમાં ફેરફાર કરવાની ક્ષમતા દર્શાવે છે. કોઈ પણ સંજોગોમાં, કામની માત્રા સમાન હશે - અને ખૂબ જ ઓછી - ફક્ત ContainerRuntimeConfig ફાઇલને ગોઠવો, અને MachineConfigPool માં એક લેબલ બદલો. અને તમે ઓપનશિફ્ટ કન્ટેનર પ્લેટફોર્મ 4.X ના કોઈપણ વર્ઝન સાથે આ કરી શકો છો જે કુબરનેટ્સને તેના સમગ્ર જીવનકાળ દરમિયાન ચલાવે છે.

ઘણીવાર ટેક્નોલોજી કંપનીઓ એટલી ઝડપથી વિકસિત થાય છે કે શા માટે અમે અંતર્ગત ઘટકો માટે અમુક તકનીકો પસંદ કરીએ છીએ તે અમે સમજાવી શકતા નથી. કન્ટેનર એન્જિન ઐતિહાસિક રીતે એવા ઘટક રહ્યા છે કે જેની સાથે વપરાશકર્તાઓ સીધી રીતે સંપર્ક કરે છે. કન્ટેનરની લોકપ્રિયતા કુદરતી રીતે કન્ટેનર એન્જિનના આગમન સાથે શરૂ થઈ હોવાથી, વપરાશકર્તાઓ ઘણીવાર તેમાં રસ દર્શાવે છે. આ બીજું કારણ છે કે શા માટે Red Hat CRI-O પસંદ કરે છે. હવે ઓર્કેસ્ટ્રેશન પર ધ્યાન કેન્દ્રિત કરીને કન્ટેનર વિકસિત થઈ રહ્યા છે, અને અમને જાણવા મળ્યું છે કે OpenShift 4 સાથે કામ કરતી વખતે CRI-O શ્રેષ્ઠ અનુભવ પ્રદાન કરે છે.

સોર્સ: www.habr.com