హెల్మ్ సెక్యూరిటీ

Kubernetes కోసం అత్యంత ప్రజాదరణ పొందిన ప్యాకేజీ మేనేజర్ గురించిన కథనం యొక్క సారాంశం ఎమోజిని ఉపయోగించి చిత్రీకరించబడుతుంది:

• పెట్టె హెల్మ్ (ఇది తాజా ఎమోజి విడుదలకు దగ్గరగా ఉన్న విషయం);
• లాక్ - భద్రత;
• చిన్న మనిషి సమస్యకు పరిష్కారం.

నిజానికి, ప్రతిదీ కొంచెం క్లిష్టంగా ఉంటుంది మరియు కథ గురించి సాంకేతిక వివరాలతో నిండి ఉంటుంది హెల్మ్‌ను ఎలా సురక్షితంగా చేయాలి.

• క్లుప్తంగా హెల్మ్ అంటే ఏమిటో మీకు తెలియకపోయినా లేదా మరచిపోయినా. ఇది ఏ సమస్యలను పరిష్కరిస్తుంది మరియు పర్యావరణ వ్యవస్థలో ఎక్కడ ఉంది.
• హెల్మ్ నిర్మాణాన్ని చూద్దాం. భాగం యొక్క నిర్మాణాన్ని అర్థం చేసుకోకుండా భద్రత మరియు సాధనం లేదా పరిష్కారాన్ని మరింత సురక్షితమైనదిగా చేయడం గురించి ఎటువంటి సంభాషణ పూర్తి కాదు.
• హెల్మ్ భాగాల గురించి చర్చిద్దాం.
• అత్యంత మండుతున్న ప్రశ్న భవిష్యత్తు - హెల్మ్ 3 యొక్క కొత్త వెర్షన్. 

ఈ కథనంలోని ప్రతిదీ హెల్మ్ 2కి వర్తిస్తుంది. ఈ సంస్కరణ ప్రస్తుతం ఉత్పత్తిలో ఉంది మరియు మీరు ప్రస్తుతం ఉపయోగిస్తున్నది చాలా మటుకు, మరియు ఇది భద్రతా ప్రమాదాలను కలిగి ఉన్న సంస్కరణ.

స్పీకర్ గురించి: అలెగ్జాండర్ ఖయోరోవ్ (allexx) 10 సంవత్సరాలుగా అభివృద్ధి చెందుతోంది, కంటెంట్‌ని మెరుగుపరచడంలో సహాయపడుతుంది మాస్కో పైథాన్ కాన్ఫ్++ మరియు కమిటీలో చేరారు హెల్మ్ సమ్మిట్. ఇప్పుడు అతను డెవలప్‌మెంట్ లీడ్‌గా చైన్‌స్టాక్‌లో పని చేస్తున్నాడు - ఇది డెవలప్‌మెంట్ మేనేజర్ మరియు తుది విడుదలలను అందించే బాధ్యత కలిగిన వ్యక్తి మధ్య హైబ్రిడ్. అంటే, ఇది యుద్ధభూమిలో ఉంది, ఇక్కడ ఉత్పత్తిని సృష్టించడం నుండి దాని ఆపరేషన్ వరకు ప్రతిదీ జరుగుతుంది.

చైన్‌స్టాక్ అనేది ఒక చిన్న, చురుగ్గా అభివృద్ధి చెందుతున్న స్టార్టప్, దీని లక్ష్యం క్లయింట్‌లు ఆపరేటింగ్ వికేంద్రీకృత అప్లికేషన్‌ల యొక్క మౌలిక సదుపాయాలు మరియు సంక్లిష్టతలను మరచిపోయేలా చేయడం; అభివృద్ధి బృందం సింగపూర్‌లో ఉంది. క్రిప్టోకరెన్సీని విక్రయించమని లేదా కొనుగోలు చేయమని చైన్‌స్టాక్‌ని అడగవద్దు, కానీ ఎంటర్‌ప్రైజ్ బ్లాక్‌చెయిన్ ఫ్రేమ్‌వర్క్‌ల గురించి మాట్లాడమని ఆఫర్ చేయండి మరియు వారు మీకు సంతోషంగా సమాధానం ఇస్తారు.

హెల్మ్

ఇది Kubernetes కోసం ప్యాకేజీ (చార్ట్) మేనేజర్. Kubernetes క్లస్టర్‌కి అప్లికేషన్‌లను తీసుకురావడానికి అత్యంత స్పష్టమైన మరియు సార్వత్రిక మార్గం.

మేము మీ స్వంత YAML మానిఫెస్ట్‌లను సృష్టించడం మరియు చిన్న యుటిలిటీలను వ్రాయడం కంటే మరింత నిర్మాణాత్మక మరియు పారిశ్రామిక విధానం గురించి మాట్లాడుతున్నాము.

హెల్మ్ ప్రస్తుతం అందుబాటులో ఉన్న మరియు జనాదరణ పొందిన అత్యుత్తమమైనది.

హెల్మ్ ఎందుకు? ప్రధానంగా దీనికి CNCF మద్దతు ఉంది. క్లౌడ్ నేటివ్ అనేది ఒక పెద్ద సంస్థ మరియు ఇది కుబెర్నెటెస్, etcd, Fluentd మరియు ఇతర ప్రాజెక్ట్‌లకు మాతృ సంస్థ.

మరో ముఖ్యమైన విషయం ఏమిటంటే, హెల్మ్ చాలా ప్రజాదరణ పొందిన ప్రాజెక్ట్. జనవరి 2019లో హెల్మ్‌ని ఎలా సురక్షితంగా ఉంచాలనే దాని గురించి నేను మాట్లాడటం ప్రారంభించినప్పుడు, ప్రాజెక్ట్‌కి GitHubలో వెయ్యి నక్షత్రాలు ఉన్నాయి. మే నాటికి వారిలో 12 వేల మంది ఉన్నారు.

చాలా మంది వ్యక్తులు హెల్మ్‌పై ఆసక్తి కలిగి ఉన్నారు, కాబట్టి మీరు దీన్ని ఇంకా ఉపయోగించకపోయినా, దాని భద్రత గురించి తెలుసుకోవడం ద్వారా మీరు ప్రయోజనం పొందుతారు. భద్రత ముఖ్యం.

కోర్ హెల్మ్ టీమ్‌కు మైక్రోసాఫ్ట్ అజూర్ మద్దతు ఇస్తుంది మరియు అనేక ఇతర వాటిలా కాకుండా ఇది చాలా స్థిరమైన ప్రాజెక్ట్. జూలై మధ్యలో హెల్మ్ 3 ఆల్ఫా 2 విడుదల ప్రాజెక్ట్‌లో చాలా మంది వ్యక్తులు పనిచేస్తున్నారని సూచిస్తుంది మరియు హెల్మ్‌ను అభివృద్ధి చేయడానికి మరియు మెరుగుపరచడానికి వారికి కోరిక మరియు శక్తి ఉంది.

హెల్మ్ కుబెర్నెట్స్‌లో అప్లికేషన్ మేనేజ్‌మెంట్ యొక్క అనేక మూల సమస్యలను పరిష్కరిస్తుంది.

• అప్లికేషన్ ప్యాకేజింగ్. WordPressలో "హలో, వరల్డ్" వంటి అప్లికేషన్ కూడా ఇప్పటికే అనేక సేవలను కలిగి ఉంది మరియు మీరు వాటిని కలిసి ప్యాకేజీ చేయాలనుకుంటున్నారు.
• ఈ అప్లికేషన్‌ల నిర్వహణతో వచ్చే సంక్లిష్టతను నిర్వహించడం.
• అప్లికేషన్‌ను ఇన్‌స్టాల్ చేసిన తర్వాత లేదా అమలు చేసిన తర్వాత ముగియని జీవిత చక్రం. ఇది జీవించడం కొనసాగుతుంది, ఇది నవీకరించబడాలి మరియు హెల్మ్ దీనికి సహాయం చేస్తుంది మరియు దీని కోసం సరైన చర్యలు మరియు విధానాలను తీసుకురావడానికి ప్రయత్నిస్తుంది.

బ్యాగింగ్ ఇది స్పష్టమైన మార్గంలో నిర్వహించబడుతుంది: Linux, Windows లేదా MacOS కోసం సాధారణ ప్యాకేజీ మేనేజర్ యొక్క పనికి అనుగుణంగా పూర్తి మెటాడేటా ఉంది. అంటే, రిపోజిటరీ, వివిధ ప్యాకేజీలపై ఆధారపడటం, అప్లికేషన్‌ల కోసం మెటా సమాచారం, సెట్టింగ్‌లు, కాన్ఫిగరేషన్ ఫీచర్‌లు, ఇన్ఫర్మేషన్ ఇండెక్సింగ్ మొదలైనవి. హెల్మ్ మీరు అప్లికేషన్‌ల కోసం వీటన్నింటిని పొందేందుకు మరియు ఉపయోగించడానికి అనుమతిస్తుంది.

సంక్లిష్టత నిర్వహణ. మీరు ఒకే రకమైన అనేక అప్లికేషన్‌లను కలిగి ఉంటే, అప్పుడు పారామిటరైజేషన్ అవసరం. టెంప్లేట్‌లు దీని నుండి వచ్చాయి, కానీ టెంప్లేట్‌లను సృష్టించే మీ స్వంత మార్గంతో ముందుకు రాకుండా ఉండేందుకు, మీరు హెల్మ్ అందించే వాటిని ఉపయోగించవచ్చు.

అప్లికేషన్ లైఫ్‌సైకిల్ మేనేజ్‌మెంట్ - నా అభిప్రాయం ప్రకారం, ఇది చాలా ఆసక్తికరమైన మరియు పరిష్కరించని ప్రశ్న. ఇందువల్లనే నేను మళ్లీ ఆ రోజు హెల్మ్‌కి వచ్చాను. మేము అప్లికేషన్ లైఫ్‌సైకిల్‌పై నిఘా ఉంచాలి మరియు మా CI/CD మరియు అప్లికేషన్ సైకిల్‌లను ఈ ఉదాహరణకి తరలించాలనుకుంటున్నాము.

హెల్మ్ మిమ్మల్ని అనుమతిస్తుంది:

• విస్తరణలను నిర్వహించండి, కాన్ఫిగరేషన్ మరియు పునర్విమర్శ భావనను పరిచయం చేస్తుంది;
• విజయవంతంగా రోల్‌బ్యాక్ నిర్వహించండి;
• వివిధ సంఘటనల కోసం హుక్స్ ఉపయోగించండి;
• అదనపు అప్లికేషన్ తనిఖీలను జోడించండి మరియు వాటి ఫలితాలకు ప్రతిస్పందించండి.

అదనంగా హెల్మ్‌లో "బ్యాటరీలు" ఉన్నాయి - మీ జీవితాన్ని సులభతరం చేసే ప్లగిన్‌ల రూపంలో చేర్చగలిగే భారీ సంఖ్యలో రుచికరమైన విషయాలు. ప్లగిన్లు స్వతంత్రంగా వ్రాయబడతాయి, అవి చాలా ఒంటరిగా ఉంటాయి మరియు శ్రావ్యమైన నిర్మాణం అవసరం లేదు. మీరు ఏదైనా అమలు చేయాలనుకుంటే, దాన్ని ప్లగ్‌ఇన్‌గా చేయమని నేను సిఫార్సు చేస్తున్నాను, ఆపై దానిని అప్‌స్ట్రీమ్‌లో చేర్చవచ్చు.

హెల్మ్ మూడు ప్రధాన భావనలపై ఆధారపడి ఉంటుంది:

• చార్ట్ రెపో — మీ మానిఫెస్ట్ కోసం సాధ్యమయ్యే పారామీటర్ల వివరణ మరియు శ్రేణి. 
• config -అంటే, వర్తించే విలువలు (టెక్స్ట్, సంఖ్యా విలువలు మొదలైనవి).
• విడుదల రెండు ఎగువ భాగాలను సేకరిస్తుంది మరియు అవి కలిసి విడుదలగా మారుతాయి. విడుదలలను సంస్కరణ చేయవచ్చు, తద్వారా వ్యవస్థీకృత జీవిత చక్రాన్ని సాధించవచ్చు: ఇన్‌స్టాలేషన్ సమయంలో చిన్నది మరియు అప్‌గ్రేడ్, డౌన్‌గ్రేడ్ లేదా రోల్‌బ్యాక్ సమయంలో పెద్దది.

హెల్మ్ ఆర్కిటెక్చర్

రేఖాచిత్రం హెల్మ్ యొక్క ఉన్నత-స్థాయి నిర్మాణాన్ని సంభావితంగా వర్ణిస్తుంది.

హెల్మ్ అనేది కుబెర్నెట్స్‌కి సంబంధించిన విషయం అని నేను మీకు గుర్తు చేస్తాను. అందువల్ల, కుబెర్నెట్స్ క్లస్టర్ (దీర్ఘచతురస్రం) లేకుండా మనం చేయలేము. kube-apiserver భాగం మాస్టర్‌పై ఉంటుంది. హెల్మ్ లేకుండా మనకు Kubeconfig ఉంది. హెల్మ్ ఒక చిన్న బైనరీని తీసుకువస్తుంది, మీరు దానిని పిలవగలిగితే, హెల్మ్ CLI యుటిలిటీ, ఇది కంప్యూటర్, ల్యాప్‌టాప్, మెయిన్‌ఫ్రేమ్‌లో ఇన్‌స్టాల్ చేయబడింది - ఏదైనా.

అయితే ఇది చాలదు. హెల్మ్‌లో టిల్లర్ అనే సర్వర్ భాగం ఉంది. ఇది క్లస్టర్‌లోని హెల్మ్ యొక్క ఆసక్తులను సూచిస్తుంది; ఇది కుబెర్నెట్స్ క్లస్టర్‌లోని ఇతర అప్లికేషన్‌ల మాదిరిగానే ఉంటుంది.

చార్ట్ రెపో యొక్క తదుపరి భాగం చార్ట్‌లతో కూడిన రిపోజిటరీ. అధికారిక రిపోజిటరీ ఉంది మరియు కంపెనీ లేదా ప్రాజెక్ట్ యొక్క ప్రైవేట్ రిపోజిటరీ ఉండవచ్చు.

పరస్పర

మేము హెల్మ్‌ని ఉపయోగించి అప్లికేషన్‌ను ఇన్‌స్టాల్ చేయాలనుకున్నప్పుడు ఆర్కిటెక్చర్ భాగాలు ఎలా ఇంటరాక్ట్ అవుతాయో చూద్దాం.

• మేము మాట్లాడుతున్నాము Helm install, రిపోజిటరీని యాక్సెస్ చేయండి (చార్ట్ రెపో) మరియు హెల్మ్ చార్ట్ పొందండి.

• హెల్మ్ యుటిలిటీ (హెల్మ్ CLI) ఏ క్లస్టర్‌ను సంప్రదించాలో గుర్తించడానికి Kubeconfigతో పరస్పర చర్య చేస్తుంది. 
• ఈ సమాచారాన్ని స్వీకరించిన తరువాత, యుటిలిటీ మా క్లస్టర్‌లో ఉన్న టిల్లర్‌ను అప్లికేషన్‌గా సూచిస్తుంది. 
• టిల్లర్ Kubernetes లో చర్యలు నిర్వహించడానికి Kube-apiserver కాల్, కొన్ని వస్తువులు (సేవలు, పాడ్లు, ప్రతిరూపాలు, రహస్యాలు, మొదలైనవి).

తర్వాత, మొత్తం హెల్మ్ ఆర్కిటెక్చర్‌ను బహిర్గతం చేయగల దాడి వెక్టర్‌ను చూడటానికి మేము రేఖాచిత్రాన్ని క్లిష్టతరం చేస్తాము. ఆపై మేము ఆమెను రక్షించడానికి ప్రయత్నిస్తాము.

దాడి వెక్టర్

మొదటి సంభావ్య బలహీన పాయింట్ విశేష API-యూజర్. పథకంలో భాగంగా, ఇది హెల్మ్ CLIకి అడ్మిన్ యాక్సెస్‌ని పొందిన హ్యాకర్.

ప్రత్యేకించబడని API వినియోగదారు సమీపంలో ఎక్కడైనా ఉంటే కూడా ప్రమాదాన్ని కలిగిస్తుంది. అటువంటి వినియోగదారు వేరే సందర్భాన్ని కలిగి ఉంటారు, ఉదాహరణకు, అతను Kubeconfig సెట్టింగ్‌లలో ఒక క్లస్టర్ నేమ్‌స్పేస్‌లో స్థిరపరచబడవచ్చు.

అత్యంత ఆసక్తికరమైన దాడి వెక్టర్ అనేది టిల్లర్‌కు సమీపంలో ఉన్న క్లస్టర్‌లో ఉండే ప్రక్రియ కావచ్చు మరియు దానిని యాక్సెస్ చేయవచ్చు. ఇది క్లస్టర్ యొక్క నెట్‌వర్క్ వాతావరణాన్ని చూసే వెబ్ సర్వర్ లేదా మైక్రోసర్వీస్ కావచ్చు.

అన్యదేశ, కానీ పెరుగుతున్న జనాదరణ పొందిన దాడి వేరియంట్‌లో చార్ట్ రెపో ఉంటుంది. నిష్కపటమైన రచయిత సృష్టించిన చార్ట్ అసురక్షిత వనరులను కలిగి ఉండవచ్చు మరియు మీరు దానిని విశ్వాసంతో పూర్తి చేస్తారు. లేదా మీరు అధికారిక రిపోజిటరీ నుండి డౌన్‌లోడ్ చేసే చార్ట్‌ను భర్తీ చేయవచ్చు మరియు ఉదాహరణకు, పాలసీల రూపంలో వనరును సృష్టించి, దాని యాక్సెస్‌ను పెంచవచ్చు.

ఈ నాలుగు వైపుల నుండి దాడులను నిరోధించడానికి ప్రయత్నిద్దాం మరియు హెల్మ్ ఆర్కిటెక్చర్‌లో ఎక్కడ సమస్యలు ఉన్నాయి మరియు ఎక్కడ ఏవీ లేకపోవచ్చు.

రేఖాచిత్రాన్ని విస్తరింపజేద్దాం, మరిన్ని ఎలిమెంట్లను జోడించండి, కానీ అన్ని ప్రాథమిక భాగాలను ఉంచండి.

హెల్మ్ CLI చార్ట్ రెపోతో కమ్యూనికేట్ చేస్తుంది, Kubeconfigతో పరస్పర చర్య చేస్తుంది మరియు పని క్లస్టర్‌కి Tiller కాంపోనెంట్‌కు బదిలీ చేయబడుతుంది.

టిల్లర్ రెండు వస్తువుల ద్వారా సూచించబడుతుంది:

• Tiller-deploy svc, ఇది ఒక నిర్దిష్ట సేవను బహిర్గతం చేస్తుంది;
• టిల్లర్-డిప్లాయ్ పాడ్ (రేఖాచిత్రంలో ఒక ప్రతిరూపంలో ఒకే కాపీలో), దానిపై మొత్తం లోడ్ నడుస్తుంది, ఇది క్లస్టర్‌ను యాక్సెస్ చేస్తుంది.

పరస్పర చర్య కోసం వివిధ ప్రోటోకాల్‌లు మరియు స్కీమ్‌లు ఉపయోగించబడతాయి. భద్రతా దృక్కోణం నుండి, మేము అత్యంత ఆసక్తి కలిగి ఉన్నాము:

• హెల్మ్ CLI చార్ట్ రెపోను యాక్సెస్ చేసే విధానం: ఏ ప్రోటోకాల్, అక్కడ ప్రామాణీకరణ ఉంది మరియు దానితో ఏమి చేయవచ్చు.
• హెల్మ్ CLI, kubectlని ఉపయోగించి, టిల్లర్‌తో కమ్యూనికేట్ చేసే ప్రోటోకాల్. ఇది క్లస్టర్ లోపల ఇన్‌స్టాల్ చేయబడిన RPC సర్వర్.
• క్లస్టర్‌లో నివసించే మరియు కుబే-అపిసర్వర్‌తో పరస్పర చర్య చేసే మైక్రోసర్వీస్‌లకు టిల్లర్ స్వయంగా అందుబాటులో ఉంటుంది.

ఈ రంగాలన్నింటినీ ఒక క్రమంలో చర్చిద్దాం.

RBAC

RBAC ప్రారంభించబడితే తప్ప, హెల్మ్ లేదా క్లస్టర్‌లోని ఏదైనా ఇతర సేవ కోసం ఏదైనా భద్రత గురించి మాట్లాడటంలో అర్థం లేదు.

ఇది తాజా సిఫార్సు కాదని తెలుస్తోంది, కానీ చాలా మంది ఇప్పటికీ ఉత్పత్తిలో కూడా RBACని ప్రారంభించలేదని నేను ఖచ్చితంగా అనుకుంటున్నాను, ఎందుకంటే ఇది చాలా రచ్చ మరియు చాలా విషయాలు కాన్ఫిగర్ చేయబడాలి. అయినప్పటికీ, దీన్ని చేయమని నేను మిమ్మల్ని ప్రోత్సహిస్తున్నాను.

https://rbac.dev/ — RBAC కోసం వెబ్‌సైట్ న్యాయవాది. ఇది RBACని సెటప్ చేయడంలో మీకు సహాయపడే భారీ మొత్తంలో ఆసక్తికరమైన మెటీరియల్‌లను కలిగి ఉంది, ఇది ఎందుకు మంచిదో మరియు ఉత్పత్తిలో దానితో ప్రాథమికంగా ఎలా జీవించాలో చూపుతుంది.

నేను టిల్లర్ మరియు RBAC ఎలా పని చేస్తాయో వివరించడానికి ప్రయత్నిస్తాను. టిల్లర్ ఒక నిర్దిష్ట సేవా ఖాతా కింద క్లస్టర్ లోపల పని చేస్తుంది. సాధారణంగా, RBAC కాన్ఫిగర్ చేయకపోతే, ఇది సూపర్యూజర్ అవుతుంది. ప్రాథమిక కాన్ఫిగరేషన్‌లో, టిల్లర్ అడ్మిన్‌గా ఉంటారు. అందుకే టిల్లర్ మీ క్లస్టర్‌కి ఒక SSH సొరంగం అని తరచుగా చెబుతారు. నిజానికి, ఇది నిజం, కాబట్టి మీరు ఎగువ రేఖాచిత్రంలో డిఫాల్ట్ సేవా ఖాతాకు బదులుగా ప్రత్యేక అంకితమైన సేవా ఖాతాను ఉపయోగించవచ్చు.

మీరు హెల్మ్‌ని ప్రారంభించి, సర్వర్‌లో మొదటిసారి ఇన్‌స్టాల్ చేసినప్పుడు, మీరు ఉపయోగించి సేవా ఖాతాను సెట్ చేయవచ్చు --service-account. ఇది కనీస అవసరమైన హక్కులతో వినియోగదారుని ఉపయోగించడానికి మిమ్మల్ని అనుమతిస్తుంది. నిజమే, మీరు అలాంటి “హారము” సృష్టించాలి: పాత్ర మరియు పాత్ర బైండింగ్.

దురదృష్టవశాత్తూ, హెల్మ్ మీ కోసం దీన్ని చేయదు. హెల్మ్‌లో ఉత్తీర్ణత సాధించడానికి మీరు లేదా మీ కుబెర్నెటెస్ క్లస్టర్ అడ్మినిస్ట్రేటర్ సర్వీస్-ఖాతా కోసం ముందుగా రోల్స్ మరియు రోల్‌బైండింగ్‌ల సెట్‌ను సిద్ధం చేయాలి.

ప్రశ్న తలెత్తుతుంది - రోల్ మరియు క్లస్టర్ రోల్ మధ్య తేడా ఏమిటి? తేడా ఏమిటంటే, ClusterRole అన్ని నేమ్‌స్పేస్‌ల కోసం పని చేస్తుంది, సాధారణ పాత్రలు మరియు రోల్‌బైండింగ్‌ల వలె కాకుండా, ఇది ప్రత్యేకమైన నేమ్‌స్పేస్ కోసం మాత్రమే పని చేస్తుంది. మీరు మొత్తం క్లస్టర్ మరియు అన్ని నేమ్‌స్పేస్‌ల కోసం విధానాలను కాన్ఫిగర్ చేయవచ్చు లేదా ఒక్కొక్క నేమ్‌స్పేస్ కోసం వ్యక్తిగతీకరించవచ్చు.

RBAC మరొక పెద్ద సమస్యను పరిష్కరిస్తుంది అని చెప్పడం విలువ. హెల్మ్, దురదృష్టవశాత్తూ, మల్టీటెనన్సీ కాదు (మల్టీటెనెన్స్‌కి మద్దతు ఇవ్వదు) అని చాలా మంది ఫిర్యాదు చేస్తున్నారు. అనేక బృందాలు క్లస్టర్‌ని వినియోగించి, హెల్మ్‌ని ఉపయోగిస్తుంటే, ఈ క్లస్టర్‌లో పాలసీలను సెటప్ చేయడం మరియు వారి యాక్సెస్‌ని పరిమితం చేయడం ప్రాథమికంగా అసాధ్యం, ఎందుకంటే హెల్మ్ నడుస్తున్న నిర్దిష్ట సేవా ఖాతా ఉంది మరియు దాని కింద నుండి క్లస్టర్‌లోని అన్ని వనరులను సృష్టిస్తుంది. , ఇది కొన్నిసార్లు చాలా అసౌకర్యంగా ఉంటుంది. ఇది నిజం - బైనరీ ఫైల్ వలె, ప్రక్రియ వలె, హెల్మ్ టిల్లర్‌కు మల్టీటెనెన్స్ అనే భావన లేదు.

అయినప్పటికీ, క్లస్టర్‌లో టిల్లర్‌ను అనేకసార్లు అమలు చేయడానికి మిమ్మల్ని అనుమతించే గొప్ప మార్గం ఉంది. దీనితో ఎటువంటి సమస్య లేదు, ప్రతి నేమ్‌స్పేస్‌లో టిల్లర్‌ను ప్రారంభించవచ్చు. అందువలన, మీరు RBAC, Kubeconfig ను సందర్భోచితంగా ఉపయోగించవచ్చు మరియు ప్రత్యేక హెల్మ్‌కి ప్రాప్యతను పరిమితం చేయవచ్చు.

ఇది ఇలా ఉంటుంది.

ఉదాహరణకు, విభిన్న బృందాలకు (రెండు నేమ్‌స్పేస్‌లు) సందర్భంతో కూడిన రెండు Kubeconfigలు ఉన్నాయి: అభివృద్ధి బృందం మరియు నిర్వాహక క్లస్టర్ కోసం X బృందం. అడ్మిన్ క్లస్టర్ దాని స్వంత విస్తృత టిల్లర్‌ను కలిగి ఉంది, ఇది కుబే-సిస్టమ్ నేమ్‌స్పేస్‌లో ఉంది, తదనుగుణంగా అధునాతన సేవా-ఖాతా. మరియు డెవలప్‌మెంట్ టీమ్‌కు ప్రత్యేక నేమ్‌స్పేస్, వారు తమ సేవలను ప్రత్యేక నేమ్‌స్పేస్‌కు అమలు చేయగలుగుతారు.

ఇది పని చేయదగిన విధానం, టిల్లర్ శక్తి ఆకలితో లేదు, ఇది మీ బడ్జెట్‌ను బాగా ప్రభావితం చేస్తుంది. ఇది త్వరిత పరిష్కారాలలో ఒకటి.

టిల్లర్‌ని విడిగా కాన్ఫిగర్ చేయడానికి సంకోచించకండి మరియు బృందం కోసం, నిర్దిష్ట డెవలపర్ కోసం లేదా పర్యావరణం కోసం సందర్భంతో Kubeconfigని అందించండి: Dev, Staging, Production (అంతా ఒకే క్లస్టర్‌లో ఉంటుందనేది సందేహాస్పదంగా ఉంది, అయితే ఇది చేయవచ్చు).

మా కథనాన్ని కొనసాగిస్తూ, RBAC నుండి మారండి మరియు ConfigMaps గురించి మాట్లాడుకుందాం.

ConfigMaps

హెల్మ్ దాని డేటా స్టోర్‌గా కాన్ఫిగ్‌మ్యాప్‌లను ఉపయోగిస్తుంది. మేము ఆర్కిటెక్చర్ గురించి మాట్లాడినప్పుడు, విడుదలలు, కాన్ఫిగరేషన్‌లు, రోల్‌బ్యాక్‌లు మొదలైన వాటి గురించి సమాచారాన్ని నిల్వ చేసే డేటాబేస్ ఎక్కడా లేదు. దీని కోసం కాన్ఫిగ్‌మ్యాప్స్ ఉపయోగించబడుతుంది.

కాన్ఫిగ్‌మ్యాప్స్‌తో ప్రధాన సమస్య తెలుసు - అవి సూత్రప్రాయంగా సురక్షితం కాదు; సున్నితమైన డేటాను నిల్వ చేయడం అసాధ్యం. మేము సేవకు మించి వెళ్లకూడని ప్రతిదాని గురించి మాట్లాడుతున్నాము, ఉదాహరణకు, పాస్వర్డ్లు. ప్రస్తుతం హెల్మ్‌కు అత్యంత స్థానిక మార్గం కాన్ఫిగ్‌మ్యాప్‌లను ఉపయోగించడం నుండి రహస్యాలకు మారడం.

ఇది చాలా సరళంగా జరుగుతుంది. టిల్లర్ సెట్టింగ్‌ను భర్తీ చేసి, నిల్వ రహస్యాలుగా ఉంటుందని పేర్కొనండి. అప్పుడు ప్రతి విస్తరణకు మీరు ConfigMapని అందుకుంటారు, కానీ ఒక రహస్యం.

రహస్యాలు ఒక విచిత్రమైన భావన మరియు చాలా సురక్షితం కాదని మీరు వాదించవచ్చు. అయితే, కుబెర్నెట్స్ డెవలపర్లు స్వయంగా దీన్ని చేస్తున్నారని అర్థం చేసుకోవడం విలువ. వెర్షన్ 1.10 నుండి ప్రారంభమవుతుంది, అనగా. చాలా కాలంగా, రహస్యాలను నిల్వ చేయడానికి సరైన నిల్వను కనెక్ట్ చేయడం కనీసం పబ్లిక్ క్లౌడ్‌లలో అయినా సాధ్యమైంది. సీక్రెట్స్, వ్యక్తిగత పాడ్‌లు లేదా ఇతర ఎంటిటీలకు యాక్సెస్‌ను మెరుగ్గా పంపిణీ చేసే మార్గాలపై బృందం ఇప్పుడు పని చేస్తోంది.

స్టోరేజ్ హెల్మ్‌ను రహస్యాలకు బదిలీ చేయడం ఉత్తమం మరియు అవి కేంద్రంగా భద్రపరచబడతాయి.

అయితే అది అలాగే ఉంటుంది డేటా నిల్వ పరిమితి 1 MB. ఇక్కడ హెల్మ్ కాన్ఫిగ్‌మ్యాప్స్ కోసం పంపిణీ చేయబడిన నిల్వగా etcdని ఉపయోగిస్తుంది. మరియు అక్కడ వారు ఇది ప్రతిరూపణకు తగిన డేటా భాగం అని భావించారు. రెడ్డిట్‌లో దీని గురించి ఆసక్తికరమైన చర్చ ఉంది, వారాంతంలో ఈ ఫన్నీ రీడ్‌ని కనుగొనమని లేదా ఎక్స్‌ట్రాక్ట్ చదవమని నేను సిఫార్సు చేస్తున్నాను ఇక్కడ.

చార్ట్ రెపోలు

చార్ట్‌లు సామాజికంగా అత్యంత హాని కలిగించేవి మరియు ముఖ్యంగా మీరు స్టాక్ సొల్యూషన్‌ని ఉపయోగిస్తే, "మ్యాన్ ఇన్ ది మిడిల్"కి మూలంగా మారవచ్చు. అన్నింటిలో మొదటిది, మేము HTTP ద్వారా బహిర్గతమయ్యే రిపోజిటరీల గురించి మాట్లాడుతున్నాము.

మీరు ఖచ్చితంగా HTTPS ద్వారా హెల్మ్ రెపోను బహిర్గతం చేయాలి - ఇది ఉత్తమ ఎంపిక మరియు చవకైనది.

దయచేసి గమనించండి చార్ట్ సంతకం మెకానిజం. సాంకేతికత నరకం వలె సులభం. పబ్లిక్ మరియు ప్రైవేట్ కీలతో కూడిన సాధారణ PGP మెషీన్ అయిన GitHubలో మీరు ఉపయోగించేది ఇదే. సెటప్ చేయండి మరియు అవసరమైన కీలను కలిగి ఉండటం మరియు ప్రతిదానిపై సంతకం చేయడం, ఇది నిజంగా మీ చార్ట్ అని నిర్ధారించుకోండి.

అదనంగా, హెల్మ్ క్లయింట్ TLSకి మద్దతు ఇస్తుంది (సర్వర్ వైపు HTTP అర్థంలో కాదు, కానీ పరస్పర TLS). మీరు కమ్యూనికేట్ చేయడానికి సర్వర్ మరియు క్లయింట్ కీలను ఉపయోగించవచ్చు. నిజాయితీగా ఉండటానికి, నేను పరస్పర సర్టిఫికేట్లను ఇష్టపడనందున నేను అలాంటి యంత్రాంగాన్ని ఉపయోగించను. ప్రాథమికంగా, చార్ట్ మ్యూజియం - హెల్మ్ 2 కోసం హెల్మ్ రెపోను సెటప్ చేయడానికి ప్రధాన సాధనం - ప్రాథమిక ప్రమాణీకరణకు కూడా మద్దతు ఇస్తుంది. ఇది మరింత సౌకర్యవంతంగా మరియు నిశ్శబ్దంగా ఉంటే మీరు ప్రాథమిక ప్రమాణీకరణను ఉపయోగించవచ్చు.

ఒక ప్లగ్ఇన్ కూడా ఉంది helm-gcs, ఇది Google క్లౌడ్ స్టోరేజ్‌లో చార్ట్ రెపోలను హోస్ట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, గొప్పగా పనిచేస్తుంది మరియు చాలా సురక్షితం, ఎందుకంటే వివరించిన అన్ని యంత్రాంగాలు రీసైకిల్ చేయబడతాయి.

మీరు HTTPS లేదా TLSని ప్రారంభించినట్లయితే, mTLSని ఉపయోగిస్తే మరియు ప్రమాదాలను మరింత తగ్గించడానికి ప్రాథమిక ప్రమాణీకరణను ప్రారంభించినట్లయితే, మీరు హెల్మ్ CLI మరియు చార్ట్ రెపోతో సురక్షితమైన కమ్యూనికేషన్ ఛానెల్‌ని పొందుతారు.

gRPC API

తదుపరి దశ చాలా ముఖ్యమైనది - క్లస్టర్‌లో ఉన్న టిల్లర్‌ను భద్రపరచడం మరియు ఒక వైపు సర్వర్, మరోవైపు, ఇది ఇతర భాగాలను యాక్సెస్ చేస్తుంది మరియు ఎవరైనా ఉన్నట్లు నటించడానికి ప్రయత్నిస్తుంది.

నేను ఇప్పటికే చెప్పినట్లుగా, టిల్లర్ అనేది gRPCని బహిర్గతం చేసే సేవ, హెల్మ్ క్లయింట్ gRPC ద్వారా దానికి వస్తుంది. డిఫాల్ట్‌గా, TLS నిలిపివేయబడింది. ఇది ఎందుకు జరిగింది అనేది చర్చనీయాంశమైన ప్రశ్న, ప్రారంభంలో సెటప్‌ను సరళీకృతం చేయాలని నాకు అనిపిస్తోంది.

ఉత్పత్తి మరియు స్టేజింగ్ కోసం, gRPCలో TLSని ప్రారంభించాలని నేను సిఫార్సు చేస్తున్నాను.

నా అభిప్రాయం ప్రకారం, చార్ట్‌ల కోసం mTLS వలె కాకుండా, ఇది ఇక్కడ సముచితమైనది మరియు చాలా సరళంగా చేయబడుతుంది - PQI ఇన్‌ఫ్రాస్ట్రక్చర్‌ను రూపొందించండి, సర్టిఫికేట్‌ను సృష్టించండి, టిల్లర్‌ను ప్రారంభించండి, ప్రారంభ సమయంలో సర్టిఫికేట్‌ను బదిలీ చేయండి. దీని తర్వాత, మీరు రూపొందించిన సర్టిఫికేట్ మరియు ప్రైవేట్ కీని ప్రదర్శించడం ద్వారా అన్ని హెల్మ్ ఆదేశాలను అమలు చేయవచ్చు.

ఈ విధంగా మీరు క్లస్టర్ వెలుపల నుండి టిల్లర్‌కు వచ్చే అన్ని అభ్యర్థనల నుండి మిమ్మల్ని మీరు రక్షించుకుంటారు.

కాబట్టి, మేము Tillerకి కనెక్షన్ ఛానెల్‌ని భద్రపరిచాము, మేము ఇప్పటికే RBAC గురించి చర్చించాము మరియు కుబెర్నెట్స్ apiserver యొక్క హక్కులను సర్దుబాటు చేసాము, దానితో సంభాషించగల డొమైన్‌ను తగ్గించాము.

రక్షిత హెల్మ్

చివరి రేఖాచిత్రాన్ని చూద్దాం. ఇది అదే బాణాలతో అదే నిర్మాణం.

అన్ని కనెక్షన్లు ఇప్పుడు సురక్షితంగా ఆకుపచ్చ రంగులో డ్రా చేయబడతాయి:

• చార్ట్ రెపో కోసం మేము TLS లేదా mTLS మరియు ప్రాథమిక ప్రమాణీకరణను ఉపయోగిస్తాము;
• టిల్లర్ కోసం mTLS, మరియు ఇది TLSతో gRPC సేవగా బహిర్గతం చేయబడింది, మేము ప్రమాణపత్రాలను ఉపయోగిస్తాము;
• క్లస్టర్ రోల్ మరియు రోల్‌బైండింగ్‌తో ప్రత్యేక సేవా ఖాతాను ఉపయోగిస్తుంది. 

మేము క్లస్టర్‌ను గణనీయంగా భద్రపరిచాము, కానీ ఎవరో తెలివైనవారు ఇలా అన్నారు:

"ఒకే ఖచ్చితంగా సురక్షితమైన పరిష్కారం మాత్రమే ఉంటుంది - స్విచ్ ఆఫ్ కంప్యూటర్, ఇది కాంక్రీట్ పెట్టెలో ఉంది మరియు సైనికులచే రక్షించబడుతుంది."

డేటాను మార్చడానికి మరియు కొత్త దాడి వెక్టర్‌లను కనుగొనడానికి వివిధ మార్గాలు ఉన్నాయి. అయితే, ఈ సిఫార్సులు భద్రత కోసం ప్రాథమిక పరిశ్రమ ప్రమాణాన్ని సాధిస్తాయని నేను విశ్వసిస్తున్నాను.

బోనస్

ఈ భాగం నేరుగా భద్రతకు సంబంధించినది కాదు, కానీ ఉపయోగకరంగా ఉంటుంది. కొంతమందికి తెలిసిన కొన్ని ఆసక్తికరమైన విషయాలను నేను మీకు చూపిస్తాను. ఉదాహరణకు, చార్ట్‌ల కోసం ఎలా శోధించాలి - అధికారిక మరియు అనధికారిక.

రిపోజిటరీలో github.com/helm/charts ఇప్పుడు దాదాపు 300 చార్ట్‌లు మరియు రెండు స్ట్రీమ్‌లు ఉన్నాయి: స్థిరమైన మరియు ఇంక్యుబేటర్. ఇంక్యుబేటర్ నుండి స్టేబుల్‌కి చేరుకోవడం ఎంత కష్టమో, స్టేబుల్ నుండి బయటికి వెళ్లడం ఎంత సులభమో సహకరించే ఎవరికైనా బాగా తెలుసు. అయినప్పటికీ, ప్రోమేతియస్ కోసం చార్ట్‌ల కోసం శోధించడానికి ఇది ఉత్తమమైన సాధనం కాదు మరియు మీకు నచ్చిన వాటి కోసం, ఒక సాధారణ కారణం కోసం - ఇది మీరు ప్యాకేజీల కోసం సౌకర్యవంతంగా శోధించగల పోర్టల్ కాదు.

కానీ ఒక సేవ ఉంది hub.helm.sh, ఇది చార్ట్‌లను కనుగొనడం చాలా సౌకర్యవంతంగా ఉంటుంది. మరీ ముఖ్యంగా, ఇంకా చాలా బాహ్య రిపోజిటరీలు మరియు దాదాపు 800 రక్షలు అందుబాటులో ఉన్నాయి. అదనంగా, కొన్ని కారణాల వల్ల మీరు మీ చార్ట్‌లను స్థిరంగా పంపకూడదనుకుంటే మీరు మీ రిపోజిటరీని కనెక్ట్ చేయవచ్చు.

hub.helm.shని ప్రయత్నించండి మరియు దానిని కలిసి అభివృద్ధి చేద్దాం. ఈ సేవ హెల్మ్ ప్రాజెక్ట్ కింద ఉంది మరియు మీరు ఫ్రంట్-ఎండ్ డెవలపర్ అయితే మరియు రూపాన్ని మెరుగుపరచాలనుకుంటే మీరు దాని UIకి కూడా సహకరించవచ్చు.

నేను మీ దృష్టిని కూడా ఆకర్షించాలనుకుంటున్నాను సర్వీస్ బ్రోకర్ API ఇంటిగ్రేషన్ తెరవండి. ఇది గజిబిజిగా మరియు అస్పష్టంగా అనిపిస్తుంది, కానీ ఇది ప్రతి ఒక్కరూ ఎదుర్కొనే సమస్యలను పరిష్కరిస్తుంది. ఒక సాధారణ ఉదాహరణతో వివరిస్తాను.

కుబెర్నెటెస్ క్లస్టర్ ఉంది, దీనిలో మేము క్లాసిక్ అప్లికేషన్‌ను అమలు చేయాలనుకుంటున్నాము - WordPress. సాధారణంగా, పూర్తి కార్యాచరణ కోసం డేటాబేస్ అవసరం. అనేక విభిన్న పరిష్కారాలు ఉన్నాయి, ఉదాహరణకు, మీరు మీ స్వంత స్టేట్‌ఫుల్ సేవను ప్రారంభించవచ్చు. ఇది చాలా సౌకర్యవంతంగా లేదు, కానీ చాలా మంది దీన్ని చేస్తారు.

చైన్‌స్టాక్‌లో ఉన్న మనలాగే ఇతరులు తమ సర్వర్‌ల కోసం MySQL లేదా PostgreSQL వంటి మేనేజ్డ్ డేటాబేస్‌లను ఉపయోగిస్తున్నారు. అందుకే మన డేటాబేస్‌లు ఎక్కడో క్లౌడ్‌లో ఉంటాయి.

కానీ ఒక సమస్య తలెత్తుతుంది: మేము మా సేవను డేటాబేస్తో కనెక్ట్ చేయాలి, డేటాబేస్ రుచిని సృష్టించాలి, ఆధారాలను బదిలీ చేయాలి మరియు దానిని ఎలాగైనా నిర్వహించాలి. ఇదంతా సాధారణంగా సిస్టమ్ అడ్మినిస్ట్రేటర్ లేదా డెవలపర్ ద్వారా మాన్యువల్‌గా చేయబడుతుంది. మరియు కొన్ని అప్లికేషన్లు ఉన్నప్పుడు సమస్య లేదు. వాటిలో చాలా ఉన్నప్పుడు, మీరు కలపాలి. అటువంటి హార్వెస్టర్ ఉంది - ఇది సర్వీస్ బ్రోకర్. పబ్లిక్ క్లౌడ్ క్లస్టర్ కోసం ప్రత్యేక ప్లగ్‌ఇన్‌ని ఉపయోగించడానికి మరియు API లాగా బ్రోకర్ ద్వారా ప్రొవైడర్ నుండి వనరులను ఆర్డర్ చేయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. దీన్ని చేయడానికి, మీరు స్థానిక Kubernetes సాధనాలను ఉపయోగించవచ్చు.

ఇది చాలా సులభం. మీరు ప్రశ్నించవచ్చు, ఉదాహరణకు, బేస్ టైర్‌తో అజూర్‌లో నిర్వహించబడిన MySQL (దీనిని కాన్ఫిగర్ చేయవచ్చు). Azure APIని ఉపయోగించి, డేటాబేస్ సృష్టించబడుతుంది మరియు ఉపయోగం కోసం సిద్ధం చేయబడుతుంది. మీరు దీనితో జోక్యం చేసుకోవలసిన అవసరం లేదు, దీనికి ప్లగ్ఇన్ బాధ్యత వహిస్తుంది. ఉదాహరణకు, OSBA (అజూర్ ప్లగ్ఇన్) సేవకు ఆధారాలను తిరిగి ఇస్తుంది మరియు దానిని హెల్మ్‌కు పంపుతుంది. మీరు క్లౌడ్ MySQLతో WordPressని ఉపయోగించగలరు, నిర్వహించబడే డేటాబేస్‌లతో వ్యవహరించలేరు మరియు లోపల స్టేట్‌ఫుల్ సేవల గురించి చింతించకండి.

హెల్మ్ జిగురుగా పనిచేస్తుందని మేము చెప్పగలం, ఇది ఒక వైపు, సేవలను అమలు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు మరోవైపు, క్లౌడ్ ప్రొవైడర్ల వనరులను వినియోగిస్తుంది.

మీరు మీ స్వంత ప్లగ్‌ఇన్‌ని వ్రాయవచ్చు మరియు ఈ మొత్తం కథనాన్ని ఆవరణలో ఉపయోగించవచ్చు. అప్పుడు మీరు కార్పొరేట్ క్లౌడ్ ప్రొవైడర్ కోసం మీ స్వంత ప్లగ్ఇన్‌ను కలిగి ఉంటారు. ఈ విధానాన్ని ప్రయత్నించమని నేను సిఫార్సు చేస్తున్నాను, ప్రత్యేకించి మీరు పెద్ద స్థాయిని కలిగి ఉంటే మరియు ఫీచర్ కోసం దేవ్, స్టేజింగ్ లేదా మొత్తం మౌలిక సదుపాయాలను త్వరగా అమలు చేయాలనుకుంటే. ఇది మీ కార్యకలాపాలు లేదా DevOps కోసం జీవితాన్ని సులభతరం చేస్తుంది.

నేను ఇప్పటికే పేర్కొన్న మరొక అన్వేషణ helm-gcs ప్లగిన్, ఇది హెల్మ్ చార్ట్‌లను నిల్వ చేయడానికి Google-బకెట్‌లను (వస్తువు నిల్వ) ఉపయోగించడానికి మిమ్మల్ని అనుమతిస్తుంది.

దీన్ని ఉపయోగించడం ప్రారంభించడానికి మీకు నాలుగు ఆదేశాలు మాత్రమే అవసరం:

1. ప్లగిన్‌ను ఇన్‌స్టాల్ చేయండి;
2. దానిని ప్రారంభించు;
3. gcp లో ఉన్న బకెట్‌కు మార్గాన్ని సెట్ చేయండి;
4. ప్రామాణిక పద్ధతిలో చార్ట్‌లను ప్రచురించండి.

అందం ఏమిటంటే ప్రామాణీకరణ కోసం స్థానిక gcp పద్ధతి ఉపయోగించబడుతుంది. మీరు సేవా ఖాతా, డెవలపర్ ఖాతాను, మీకు కావలసినది ఉపయోగించవచ్చు. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది మరియు ఆపరేట్ చేయడానికి ఏమీ ఖర్చు చేయదు. మీరు, నాలాగే, ఆప్స్‌లెస్ ఫిలాసఫీని ప్రోత్సహిస్తే, ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, ముఖ్యంగా చిన్న జట్లకు.

ప్రత్యామ్నాయాలు

హెల్మ్ మాత్రమే సేవా నిర్వహణ పరిష్కారం కాదు. దాని గురించి చాలా ప్రశ్నలు ఉన్నాయి, అందుకే మూడవ వెర్షన్ చాలా త్వరగా కనిపించింది. వాస్తవానికి ప్రత్యామ్నాయాలు ఉన్నాయి.

ఇవి ప్రత్యేకమైన పరిష్కారాలు కావచ్చు, ఉదాహరణకు, Ksonnet లేదా Metaparticle. నేను మాట్లాడిన అదే ప్రయోజనాల కోసం మీరు మీ క్లాసిక్ ఇన్‌ఫ్రాస్ట్రక్చర్ మేనేజ్‌మెంట్ టూల్స్ (Ansible, Terraform, Chef, మొదలైనవి) ఉపయోగించవచ్చు.

చివరకు ఒక పరిష్కారం ఉంది ఆపరేటర్ ఫ్రేమ్‌వర్క్, దీని ప్రజాదరణ పెరుగుతోంది.

ఆపరేటర్ ఫ్రేమ్‌వర్క్ అనేది పరిగణించవలసిన అగ్ర హెల్మ్ ప్రత్యామ్నాయం.

ఇది CNCF మరియు కుబెర్నెటెస్‌లకు మరింత స్థానికంగా ఉంటుంది, కానీ ప్రవేశానికి అడ్డంకి చాలా ఎక్కువ, మీరు మరింత ప్రోగ్రామ్ చేయాలి మరియు మానిఫెస్ట్‌లను తక్కువగా వివరించాలి.

డ్రాఫ్ట్, స్కాఫోల్డ్ వంటి వివిధ యాడ్ఆన్‌లు ఉన్నాయి. అవి జీవితాన్ని చాలా సులభతరం చేస్తాయి, ఉదాహరణకు, డెవలపర్‌ల కోసం పరీక్షా వాతావరణాన్ని అమలు చేయడానికి హెల్మ్‌ని పంపడం మరియు ప్రారంభించడం వంటి చక్రాన్ని అవి సులభతరం చేస్తాయి. నేను వారిని సాధికారత అని పిలుస్తాను.

ప్రతిదీ ఎక్కడ ఉందో విజువల్ చార్ట్ ఇక్కడ ఉంది.

x-యాక్సిస్‌లో ఏమి జరుగుతుందో దానిపై మీ వ్యక్తిగత నియంత్రణ స్థాయి, y-అక్షంలో కుబెర్నెటీస్ యొక్క స్థానికత స్థాయి. హెల్మ్ వెర్షన్ 2 మధ్యలో ఎక్కడో వస్తుంది. వెర్షన్ 3లో, పెద్దగా కాదు, నియంత్రణ మరియు స్థానికత స్థాయి రెండూ మెరుగుపరచబడ్డాయి. Ksonnet స్థాయిలో పరిష్కారాలు ఇప్పటికీ హెల్మ్ 2 కంటే తక్కువ స్థాయిలో ఉన్నాయి. అయితే, ఈ ప్రపంచంలో ఇంకా ఏమి ఉందో తెలుసుకోవడానికి వాటిని చూడటం విలువైనదే. అయితే, మీ కాన్ఫిగరేషన్ మేనేజర్ మీ నియంత్రణలో ఉంటారు, కానీ ఇది ఖచ్చితంగా కుబెర్నెట్స్‌కి చెందినది కాదు.

ఆపరేటర్ ఫ్రేమ్‌వర్క్ పూర్తిగా కుబెర్నెటెస్‌కు చెందినది మరియు దీన్ని మరింత సొగసైన మరియు నిశితంగా నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది (కానీ ప్రవేశ స్థాయి గురించి గుర్తుంచుకోండి). బదులుగా, హెల్మ్‌ని ఉపయోగించి భారీ సంఖ్యలో అప్లికేషన్‌లను ప్యాకేజింగ్ చేయడానికి మాస్ హార్వెస్టర్ కాకుండా, ప్రత్యేకమైన అప్లికేషన్ మరియు దాని నిర్వహణను రూపొందించడానికి ఇది అనుకూలంగా ఉంటుంది.

ఎక్స్‌టెండర్‌లు నియంత్రణను కొద్దిగా మెరుగుపరుస్తాయి, వర్క్‌ఫ్లోను పూర్తి చేస్తాయి లేదా CI/CD పైప్‌లైన్‌లపై మూలలను కత్తిరించాయి.

హెల్మ్ యొక్క భవిష్యత్తు

శుభవార్త ఏమిటంటే, హెల్మ్ 3 వస్తోంది. హెల్మ్ 3.0.0-ఆల్ఫా.2 ఆల్ఫా వెర్షన్ ఇప్పటికే విడుదల చేయబడింది, మీరు దీన్ని ప్రయత్నించవచ్చు. ఇది చాలా స్థిరంగా ఉంది, కానీ కార్యాచరణ ఇప్పటికీ పరిమితం చేయబడింది.

మీకు హెల్మ్ 3 ఎందుకు అవసరం? అన్నింటిలో మొదటిది, ఇది ఒక కథ టిల్లర్ అదృశ్యం, ఒక భాగం వలె. ఇది, మీరు ఇప్పటికే అర్థం చేసుకున్నట్లుగా, భారీ ముందడుగు, ఎందుకంటే వాస్తుశిల్పం యొక్క భద్రత యొక్క కోణం నుండి, ప్రతిదీ సరళీకృతం చేయబడింది.

హెల్మ్ 2 సృష్టించబడినప్పుడు, ఇది కుబెర్నెటెస్ 1.8 లేదా అంతకు ముందు కాలంలో, చాలా భావనలు అపరిపక్వంగా ఉన్నాయి. ఉదాహరణకు, CRD భావన ఇప్పుడు చురుకుగా అమలు చేయబడుతోంది మరియు హెల్మ్ చేస్తుంది CRD ఉపయోగించండినిర్మాణాలను నిల్వ చేయడానికి. క్లయింట్‌ను మాత్రమే ఉపయోగించడం సాధ్యమవుతుంది మరియు సర్వర్ భాగాన్ని నిర్వహించదు. దీని ప్రకారం, నిర్మాణాలు మరియు వనరులతో పని చేయడానికి స్థానిక కుబెర్నెట్స్ ఆదేశాలను ఉపయోగించండి. ఇది ఒక పెద్ద ముందడుగు.

కనిపిస్తుంది స్థానిక OCI రిపోజిటరీలకు మద్దతు (ఓపెన్ కంటైనర్ ఇనిషియేటివ్). ఇది భారీ చొరవ, మరియు హెల్మ్ దాని చార్ట్‌లను పోస్ట్ చేయడానికి ప్రధానంగా ఆసక్తిని కలిగి ఉంది. ఉదాహరణకు, డాకర్ హబ్ అనేక OCI ప్రమాణాలకు మద్దతు ఇస్తుంది. నేను ఊహించడం లేదు, కానీ బహుశా క్లాసిక్ డాకర్ రిపోజిటరీ ప్రొవైడర్లు మీ హెల్మ్ చార్ట్‌లను హోస్ట్ చేసే అవకాశాన్ని మీకు అందించడం ప్రారంభిస్తారు.

నాకు వివాదాస్పద కథ లువా మద్దతు, స్క్రిప్ట్‌లను వ్రాయడానికి టెంప్లేటింగ్ ఇంజిన్‌గా. నేను లువాకి పెద్ద అభిమానిని కాదు, కానీ ఇది పూర్తిగా ఐచ్ఛిక లక్షణం. నేను దీన్ని 3 సార్లు తనిఖీ చేసాను - Luaని ఉపయోగించాల్సిన అవసరం లేదు. అందువల్ల, లువాను ఉపయోగించాలనుకునే వారు, గో ఇష్టపడే వారు మా భారీ క్యాంపులో చేరండి మరియు దీని కోసం go-tmplని ఉపయోగించండి.

చివరగా, నేను ఖచ్చితంగా తప్పిపోయాను స్కీమా ఆవిర్భావం మరియు డేటా రకం ధ్రువీకరణ. Int లేదా స్ట్రింగ్‌తో ఎక్కువ సమస్యలు ఉండవు, డబుల్ కోట్‌లలో సున్నాని చుట్టాల్సిన అవసరం లేదు. విలువల కోసం దీన్ని స్పష్టంగా వివరించడానికి మిమ్మల్ని అనుమతించే JSONS స్కీమా కనిపిస్తుంది.

భారీగా పునర్నిర్మించబడుతుంది ఈవెంట్-ఆధారిత మోడల్. ఇది ఇప్పటికే సంభావితంగా వివరించబడింది. హెల్మ్ 3 బ్రాంచ్‌ని చూడండి మరియు ఎన్ని ఈవెంట్‌లు మరియు హుక్స్ మరియు ఇతర విషయాలు జోడించబడ్డాయో మీరు చూస్తారు, ఇది చాలా సులభతరం చేస్తుంది మరియు మరోవైపు, వాటికి విస్తరణ ప్రక్రియలు మరియు ప్రతిచర్యలపై నియంత్రణను జోడిస్తుంది.

హెల్మ్ 3 సరళమైనది, సురక్షితమైనది మరియు మరింత ఆహ్లాదకరంగా ఉంటుంది, మేము హెల్మ్ 2ని ఇష్టపడనందున కాదు, కానీ కుబెర్నెటెస్ మరింత అభివృద్ధి చెందుతున్నందున. దీని ప్రకారం, హెల్మ్ కుబెర్నెట్స్ యొక్క అభివృద్ధిని ఉపయోగించుకోవచ్చు మరియు దానిపై కుబెర్నెట్స్ కోసం అద్భుతమైన నిర్వాహకులను సృష్టించవచ్చు.

మరో శుభవార్త ఏమిటంటే DevOpsConf అలెగ్జాండర్ ఖయోరోవ్ మీకు చెప్తాడు, కంటైనర్లు సురక్షితంగా ఉండవచ్చా? అభివృద్ధి, పరీక్ష మరియు ఆపరేషన్ ప్రక్రియల ఏకీకరణపై సమావేశం మాస్కోలో నిర్వహించబడుతుందని మీకు గుర్తు చేద్దాం సెప్టెంబర్ 30 మరియు అక్టోబర్ 1. మీరు ఇప్పటికీ ఆగస్టు 20 వరకు దీన్ని చేయవచ్చు నివేదన అందజేయు మరియు పరిష్కారంతో మీ అనుభవం గురించి మాకు చెప్పండి అనేక వాటిలో ఒకటి DevOps విధానం యొక్క పనులు.

కాన్ఫరెన్స్ చెక్‌పోస్టులు మరియు వార్తలను అనుసరించండి మెయిలింగ్ జాబితా и టెలిగ్రామ్ ఛానల్.

మూలం: www.habr.com