పావెల్ సెలివనోవ్, సౌత్‌బ్రిడ్జ్ సొల్యూషన్స్ ఆర్కిటెక్ట్ మరియు స్లర్మ్ టీచర్, DevOpsConf 2019లో ప్రెజెంటేషన్ ఇచ్చారు. ఈ చర్చ కుబెర్నెటెస్ “స్లర్మ్ మెగా”పై లోతైన కోర్సులోని ఒక అంశంలో భాగం.
నవంబర్ 18-20 తేదీలలో మాస్కోలో జరుగుతుంది.
- మాస్కో, నవంబర్ 22-24.
ఎల్లప్పుడూ అందుబాటులో ఉంటుంది.
కట్ క్రింద నివేదిక యొక్క ట్రాన్స్క్రిప్ట్ ఉంది.
శుభ మధ్యాహ్నం, సహచరులు మరియు వారితో సానుభూతి చూపే వారు. ఈ రోజు నేను భద్రత గురించి మాట్లాడతాను.
ఈరోజు హాలులో చాలా మంది సెక్యూరిటీ గార్డులు ఉండడం చూశాను. నేను మీకు ఆచారంగా కాకుండా భద్రతా ప్రపంచంలోని నిబంధనలను ఉపయోగిస్తుంటే ముందుగానే మీకు క్షమాపణలు కోరుతున్నాను.
ఆరు నెలల క్రితం నేను ఒక పబ్లిక్ కుబెర్నెటెస్ క్లస్టర్‌ని చూశాను. పబ్లిక్ అంటే నేమ్‌స్పేస్‌లలో nవ సంఖ్య ఉంది; ఈ నేమ్‌స్పేస్‌లలో వారి నేమ్‌స్పేస్‌లో ఐసోలేట్ చేయబడిన వినియోగదారులు ఉన్నారు. ఈ వినియోగదారులందరూ వేర్వేరు కంపెనీలకు చెందినవారు. సరే, ఈ క్లస్టర్‌ని CDNగా ఉపయోగించాలని భావించారు. అంటే, వారు మీకు క్లస్టర్‌ను ఇస్తారు, వారు మీకు అక్కడ ఒక వినియోగదారుని ఇస్తారు, మీరు మీ నేమ్‌స్పేస్‌కి వెళ్లండి, మీ ఫ్రంట్‌లను అమలు చేయండి.
నా మునుపటి కంపెనీ అటువంటి సేవను విక్రయించడానికి ప్రయత్నించింది. మరియు ఈ పరిష్కారం సరిపోతుందా లేదా అని చూడడానికి క్లస్టర్‌ను దూర్ చేయమని నన్ను అడిగారు.
నేను ఈ క్లస్టర్‌కి వచ్చాను. నాకు పరిమిత హక్కులు, పరిమిత నేమ్‌స్పేస్ ఇచ్చారు. భద్రత అంటే ఏమిటో అక్కడి కుర్రాళ్లకు అర్థమైంది. వారు కుబెర్నెటెస్‌లో రోల్-బేస్డ్ యాక్సెస్ కంట్రోల్ (RBAC) గురించి చదివారు - మరియు నేను డిప్లాయ్‌మెంట్‌ల నుండి విడిగా పాడ్‌లను లాంచ్ చేయలేని విధంగా వారు దానిని వక్రీకరించారు. విస్తరణ లేకుండా పాడ్‌ని ప్రారంభించడం ద్వారా నేను పరిష్కరించడానికి ప్రయత్నిస్తున్న సమస్య నాకు గుర్తులేదు, కానీ నేను నిజంగా పాడ్‌ను ప్రారంభించాలనుకుంటున్నాను. అదృష్టం కోసం, క్లస్టర్‌లో నాకు ఎలాంటి హక్కులు ఉన్నాయి, నేను ఏమి చేయగలను, నేను ఏమి చేయలేను మరియు అక్కడ వారు ఏమి చిత్తు చేసారో చూడాలని నిర్ణయించుకున్నాను. అదే సమయంలో, వారు RBACలో తప్పుగా కాన్ఫిగర్ చేసిన వాటిని నేను మీకు చెప్తాను.
రెండు నిమిషాల్లో నేను వారి క్లస్టర్‌కి అడ్మిన్‌ని అందుకున్నాను, పొరుగున ఉన్న అన్ని నేమ్‌స్పేస్‌లను చూశాను, అక్కడ ఇప్పటికే సేవను కొనుగోలు చేసి మోహరించిన కంపెనీల నడుస్తున్న ప్రొడక్షన్ ఫ్రంట్‌లను చూశాను. ఒకరి ముందుకి వెళ్లి మెయిన్ పేజీలో కొన్ని తిట్లు వేయకుండా నేను ఆపుకోలేకపోయాను.
నేను దీన్ని ఎలా చేసాను మరియు దీని నుండి మిమ్మల్ని మీరు ఎలా రక్షించుకోవాలో ఉదాహరణలతో మీకు చెప్తాను.
అయితే ముందుగా నన్ను నేను పరిచయం చేసుకుంటాను. నా పేరు పావెల్ సెలివనోవ్. నేను సౌత్‌బ్రిడ్జ్‌లో ఆర్కిటెక్ట్‌ని. నేను Kubernetes, DevOps మరియు అన్ని రకాల ఫ్యాన్సీ విషయాలను అర్థం చేసుకున్నాను. సౌత్‌బ్రిడ్జ్ ఇంజనీర్లు మరియు నేను ఇవన్నీ నిర్మిస్తున్నాము మరియు నేను సలహా ఇస్తున్నాను.
మా ప్రధాన కార్యకలాపాలతో పాటు, మేము ఇటీవల స్లర్మ్స్ అనే ప్రాజెక్ట్‌లను ప్రారంభించాము. మేము కుబెర్నెట్స్‌తో కలిసి పని చేసే మా సామర్థ్యాన్ని కొంచెం జనాల్లోకి తీసుకురావడానికి ప్రయత్నిస్తున్నాము, ఇతర వ్యక్తులకు కూడా K8లతో పని చేయడం నేర్పించాము.
ఈ రోజు నేను ఏమి మాట్లాడతాను? నివేదిక యొక్క అంశం స్పష్టంగా ఉంది - కుబెర్నెట్స్ క్లస్టర్ యొక్క భద్రత గురించి. కానీ ఈ అంశం చాలా పెద్దదని నేను వెంటనే చెప్పాలనుకుంటున్నాను - అందువల్ల నేను ఖచ్చితంగా ఏమి మాట్లాడను అని వెంటనే స్పష్టం చేయాలనుకుంటున్నాను. ఇంటర్నెట్‌లో ఇప్పటికే వందసార్లు ఉపయోగించిన హ్యాక్‌నీడ్ పదాల గురించి నేను మాట్లాడను. అన్ని రకాల RBAC మరియు సర్టిఫికెట్లు.
కుబెర్నెట్స్ క్లస్టర్‌లో భద్రత గురించి నాకు మరియు నా సహోద్యోగులకు బాధ కలిగించే దాని గురించి నేను మాట్లాడతాను. మేము Kubernetes క్లస్టర్‌లను అందించే ప్రొవైడర్‌లలో మరియు మా వద్దకు వచ్చే క్లయింట్‌లలో ఈ సమస్యలను చూస్తున్నాము. మరియు ఇతర కన్సల్టింగ్ అడ్మిన్ కంపెనీల నుండి మా వద్దకు వచ్చే క్లయింట్ల నుండి కూడా. అంటే, విషాదం యొక్క స్థాయి నిజానికి చాలా పెద్దది.
ఈ రోజు నేను మాట్లాడే మూడు పాయింట్లు ఉన్నాయి:
- వినియోగదారు హక్కులు vs పాడ్ హక్కులు. వినియోగదారు హక్కులు మరియు పాడ్ హక్కులు ఒకే విషయం కాదు.
- క్లస్టర్ గురించి సమాచారాన్ని సేకరిస్తోంది. ఈ క్లస్టర్‌లో ప్రత్యేక హక్కులు లేకుండానే క్లస్టర్ నుండి మీకు అవసరమైన మొత్తం సమాచారాన్ని మీరు సేకరించవచ్చని నేను చూపిస్తాను.
- క్లస్టర్‌పై DoS దాడి. మేము సమాచారాన్ని సేకరించలేకపోతే, మేము ఏ సందర్భంలోనైనా క్లస్టర్‌ను ఉంచగలుగుతాము. నేను క్లస్టర్ కంట్రోల్ ఎలిమెంట్స్‌పై DoS దాడుల గురించి మాట్లాడతాను.
నేను ప్రస్తావించే మరో సాధారణ విషయం ఏమిటంటే, నేను వీటన్నింటిని పరీక్షించాను, ఇది ఖచ్చితంగా పనిచేస్తుందని నేను ఖచ్చితంగా చెప్పగలను.
మేము Kubespray ఉపయోగించి Kubernetes క్లస్టర్ యొక్క సంస్థాపనను ప్రాతిపదికగా తీసుకుంటాము. ఎవరికైనా తెలియకపోతే, ఇది నిజానికి అన్సిబుల్ పాత్రల సమితి. మేము మా పనిలో నిరంతరం ఉపయోగిస్తాము. మంచి విషయం ఏమిటంటే, మీరు దానిని ఎక్కడైనా చుట్టవచ్చు - మీరు దానిని ఇనుప ముక్కలపైకి లేదా ఎక్కడో ఒక మేఘంలోకి చుట్టవచ్చు. ప్రతిదానికీ ఒక ఇన్‌స్టాలేషన్ పద్ధతి సూత్రప్రాయంగా పనిచేస్తుంది.
ఈ క్లస్టర్‌లో నేను కుబెర్నెట్స్ v1.14.5ని కలిగి ఉంటాను. మేము పరిగణించే మొత్తం క్యూబ్ క్లస్టర్, నేమ్‌స్పేస్‌లుగా విభజించబడింది, ప్రతి నేమ్‌స్పేస్ ప్రత్యేక బృందానికి చెందినది మరియు ఈ బృందంలోని సభ్యులు ప్రతి నేమ్‌స్పేస్‌కు యాక్సెస్ కలిగి ఉంటారు. వారు వేర్వేరు నేమ్‌స్పేస్‌లకు వెళ్లలేరు, వారి స్వంత వాటికి మాత్రమే. కానీ మొత్తం క్లస్టర్‌పై హక్కులను కలిగి ఉన్న నిర్దిష్ట నిర్వాహక ఖాతా ఉంది.
క్లస్టర్‌కి అడ్మిన్ హక్కులను పొందడం మేము చేసే మొదటి పని అని నేను వాగ్దానం చేసాను. కుబెర్నెటెస్ క్లస్టర్‌ను విచ్ఛిన్నం చేసే ప్రత్యేకంగా తయారు చేసిన పాడ్ మాకు అవసరం. మనం చేయాల్సిందల్లా దానిని కుబెర్నెట్స్ క్లస్టర్‌కు వర్తింపజేయడం.
kubectl apply -f pod.yamlఈ పాడ్ కుబెర్నెటెస్ క్లస్టర్ యొక్క మాస్టర్స్‌లో ఒకరికి చేరుకుంటుంది. మరియు దీని తర్వాత క్లస్టర్ మాకు admin.conf అనే ఫైల్‌ను సంతోషంగా తిరిగి ఇస్తుంది. క్యూబ్‌లో, ఈ ఫైల్ అన్ని అడ్మినిస్ట్రేటర్ సర్టిఫికేట్‌లను నిల్వ చేస్తుంది మరియు అదే సమయంలో క్లస్టర్ APIని కాన్ఫిగర్ చేస్తుంది. 98% కుబెర్నెటెస్ క్లస్టర్‌లకు అడ్మిన్ యాక్సెస్ పొందడం ఎంత సులభం అని నేను అనుకుంటున్నాను.
నేను పునరావృతం చేస్తున్నాను, ఈ పాడ్‌ను మీ క్లస్టర్‌లోని ఒక డెవలపర్ తయారు చేసాడు, అతను తన ప్రతిపాదనలను ఒక చిన్న నేమ్‌స్పేస్‌లో అమర్చడానికి యాక్సెస్ కలిగి ఉన్నాడు, ఇదంతా RBAC ద్వారా బిగించబడింది. అతనికి హక్కులు లేవు. అయితే, సర్టిఫికేట్ తిరిగి వచ్చింది.
మరియు ఇప్పుడు ప్రత్యేకంగా తయారుచేసిన పాడ్ గురించి. మేము దానిని ఏదైనా చిత్రంపై అమలు చేస్తాము. డెబియన్:జెస్సీని ఉదాహరణగా తీసుకుందాం.
మాకు ఈ విషయం ఉంది:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" సహనం అంటే ఏమిటి? కుబెర్నెటీస్ క్లస్టర్‌లోని మాస్టర్‌లు సాధారణంగా టెన్ట్ అని పిలవబడే వాటితో గుర్తించబడతాయి. మరియు ఈ "ఇన్ఫెక్షన్" యొక్క సారాంశం ఏమిటంటే, పాడ్‌లను మాస్టర్ నోడ్‌లకు కేటాయించలేమని చెప్పింది. కానీ "ఇన్ఫెక్షన్"ని తట్టుకోగలదని ఏ పాడ్‌లోనైనా సూచించడానికి ఎవరూ బాధపడరు. కొన్ని నోడ్‌లకు NoSchedule ఉంటే, మన నోడ్ అటువంటి ఇన్‌ఫెక్షన్‌ను తట్టుకుంటుంది - మరియు ఎటువంటి సమస్యలు ఉండవని టోలరేషన్ విభాగం చెబుతోంది.
ఇంకా, మా అండర్ సహనం మాత్రమే కాదు, మాస్టర్‌ను ప్రత్యేకంగా లక్ష్యంగా చేసుకోవాలనుకుంటున్నాము. అన్ని సర్టిఫికేట్లు - మాస్టర్స్ మేము అవసరం అత్యంత రుచికరమైన విషయం కలిగి ఎందుకంటే. అందువల్ల, మేము nodeSelector అని అంటాము - మరియు మేము మాస్టర్స్‌పై ప్రామాణిక లేబుల్‌ని కలిగి ఉన్నాము, ఇది క్లస్టర్‌లోని అన్ని నోడ్‌ల నుండి ఖచ్చితంగా మాస్టర్స్ అయిన నోడ్‌లను ఎంచుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది.
ఈ రెండు విభాగాలతో అతను ఖచ్చితంగా మాస్టర్ వద్దకు వస్తాడు. మరియు అతను అక్కడ నివసించడానికి అనుమతించబడతాడు.
కానీ మాస్టారు వద్దకు రావడం మాత్రమే మనకు సరిపోదు. ఇది మాకు ఏమీ ఇవ్వదు. కాబట్టి తరువాత మనకు ఈ రెండు విషయాలు ఉన్నాయి:
hostNetwork: true
hostPID: true మేము ప్రారంభించే మా పాడ్, కెర్నల్ నేమ్‌స్పేస్‌లో, నెట్‌వర్క్ నేమ్‌స్పేస్‌లో మరియు PID నేమ్‌స్పేస్‌లో నివసిస్తుందని మేము పేర్కొంటాము. పాడ్‌ని మాస్టర్‌లో ప్రారంభించిన తర్వాత, అది ఈ నోడ్ యొక్క అన్ని నిజమైన, ప్రత్యక్ష ఇంటర్‌ఫేస్‌లను చూడగలదు, అన్ని ట్రాఫిక్‌లను వినగలదు మరియు అన్ని ప్రక్రియల PIDని చూడగలదు.
అప్పుడు అది చిన్న విషయాల విషయం. etcd తీసుకొని మీకు కావలసినది చదవండి.
అత్యంత ఆసక్తికరమైన విషయం ఏమిటంటే, డిఫాల్ట్‌గా ఉన్న ఈ కుబెర్నెట్స్ ఫీచర్.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host మరియు దాని సారాంశం ఏమిటంటే, ఈ క్లస్టర్‌కు హక్కులు లేకపోయినా, మేము హోస్ట్‌పాత్ టైప్ యొక్క వాల్యూమ్‌ను సృష్టించాలనుకుంటున్నాము అని మేము ప్రారంభించే పాడ్‌లో చెప్పగలము. దీని అర్థం మనం ప్రారంభించబోయే హోస్ట్ నుండి పాత్‌ను తీసుకోవడం - మరియు దానిని వాల్యూమ్‌గా తీసుకోవడం. ఆపై మేము దానిని పేరు: హోస్ట్ అని పిలుస్తాము. మేము ఈ మొత్తం హోస్ట్‌పాత్‌ను పాడ్ లోపల మౌంట్ చేస్తాము. ఈ ఉదాహరణలో, /హోస్ట్ డైరెక్టరీకి.
నేను మళ్ళీ పునరావృతం చేస్తాను. మేము పాడ్‌ని మాస్టర్ వద్దకు రమ్మని చెప్పాము, అక్కడ హోస్ట్‌నెట్‌వర్క్ మరియు హోస్ట్‌పిఐడిని పొందండి - మరియు ఈ పాడ్ లోపల మాస్టర్ యొక్క మొత్తం రూట్‌ను మౌంట్ చేయండి.
డెబియన్‌లో మనకు బాష్ రన్నింగ్ ఉందని మరియు ఈ బాష్ రూట్ కింద నడుస్తుందని మీరు అర్థం చేసుకున్నారు. అంటే, మేము కుబెర్నెటెస్ క్లస్టర్‌లో ఎలాంటి హక్కులు లేకుండానే మాస్టర్‌పై రూట్‌ని పొందాము.
అప్పుడు మొత్తం పని సబ్ డైరెక్టరీ / హోస్ట్ / etc / kubernetes / pkiకి వెళ్లడం, నేను తప్పుగా భావించకపోతే, క్లస్టర్ యొక్క అన్ని మాస్టర్ సర్టిఫికేట్‌లను తీయండి మరియు తదనుగుణంగా క్లస్టర్ అడ్మినిస్ట్రేటర్ అవ్వండి.
మీరు ఈ విధంగా చూస్తే, ఇవి పాడ్‌లలో అత్యంత ప్రమాదకరమైన కొన్ని హక్కులు - వినియోగదారుకు ఎలాంటి హక్కులు ఉన్నాయో దానితో సంబంధం లేకుండా:
క్లస్టర్‌లోని కొంత నేమ్‌స్పేస్‌లో పాడ్‌ను అమలు చేయడానికి నాకు హక్కులు ఉంటే, ఈ పాడ్‌కి డిఫాల్ట్‌గా ఈ హక్కులు ఉంటాయి. నేను ప్రివిలేజ్డ్ పాడ్‌లను అమలు చేయగలను మరియు ఇవి సాధారణంగా అన్ని హక్కులు, ఆచరణాత్మకంగా నోడ్‌లో రూట్ చేయబడతాయి.
నాకు ఇష్టమైనది రూట్ యూజర్. మరియు Kubernetes ఈ రన్ నాన్-రూట్ ఎంపికను కలిగి ఉంది. ఇది హ్యాకర్ నుండి ఒక రకమైన రక్షణ. "మోల్దవియన్ వైరస్" అంటే ఏమిటో తెలుసా? మీరు అకస్మాత్తుగా హ్యాకర్ అయి, నా కుబెర్నెటెస్ క్లస్టర్‌కి వచ్చినట్లయితే, మేము, పేద నిర్వాహకులు ఇలా అడుగుతాము: “దయచేసి మీరు నా క్లస్టర్‌ని హ్యాక్ చేసే మీ పాడ్‌లలో సూచించండి, నాన్-రూట్‌గా అమలు చేయండి. లేకపోతే, మీరు మీ పాడ్‌లో ప్రాసెస్‌ను రూట్ కింద అమలు చేయడం జరుగుతుంది మరియు మీరు నన్ను హ్యాక్ చేయడం చాలా సులభం అవుతుంది. దయచేసి మీ నుండి మిమ్మల్ని మీరు రక్షించుకోండి."
హోస్ట్ పాత్ వాల్యూమ్, నా అభిప్రాయం ప్రకారం, కుబెర్నెట్స్ క్లస్టర్ నుండి ఆశించిన ఫలితాన్ని పొందడానికి వేగవంతమైన మార్గం.
అయితే వీటన్నింటితో ఏమి చేయాలి?
కుబెర్నెటీస్‌ని ఎదుర్కొన్న ఏ సాధారణ నిర్వాహకునికైనా వచ్చే ఆలోచన ఏమిటంటే: “అవును, నేను మీకు చెప్పాను, కుబెర్నెటీస్ పని చేయదు. అందులో రంధ్రాలు ఉన్నాయి. మరియు మొత్తం క్యూబ్ బుల్‌షిట్." వాస్తవానికి, డాక్యుమెంటేషన్ వంటి విషయం ఉంది మరియు మీరు అక్కడ చూస్తే, ఒక విభాగం ఉంది .
ఇది యామల్ వస్తువు - మేము దీనిని కుబెర్నెటెస్ క్లస్టర్‌లో సృష్టించవచ్చు - ఇది పాడ్‌ల వివరణలో ప్రత్యేకంగా భద్రతా అంశాలను నియంత్రిస్తుంది. అంటే, వాస్తవానికి, స్టార్టప్‌లో పాడ్‌లలో ఉండే ఏదైనా హోస్ట్‌నెట్‌వర్క్, హోస్ట్‌పిఐడి, నిర్దిష్ట వాల్యూమ్ రకాలను ఉపయోగించే హక్కులను ఇది నియంత్రిస్తుంది. పాడ్ సెక్యూరిటీ పాలసీ సహాయంతో, ఇవన్నీ వివరించవచ్చు.
పాడ్ సెక్యూరిటీ పాలసీ గురించి అత్యంత ఆసక్తికరమైన విషయం ఏమిటంటే, కుబెర్నెట్స్ క్లస్టర్‌లో, అన్ని PSP ఇన్‌స్టాలర్‌లు ఏ విధంగానూ వివరించబడలేదు, అవి డిఫాల్ట్‌గా నిలిపివేయబడతాయి. అడ్మిషన్ ప్లగ్ఇన్ ఉపయోగించి పాడ్ సెక్యూరిటీ పాలసీ ప్రారంభించబడింది.
సరే, పాడ్ సెక్యూరిటీ పాలసీని క్లస్టర్‌లో అమలు చేద్దాం, నేమ్‌స్పేస్‌లో మనకు కొన్ని సర్వీస్ పాడ్‌లు ఉన్నాయని చెప్పండి, వాటికి అడ్మిన్‌లకు మాత్రమే యాక్సెస్ ఉంటుంది. అన్ని ఇతర సందర్భాల్లో, పాడ్‌లకు పరిమిత హక్కులు ఉన్నాయని చెప్పండి. ఎందుకంటే డెవలపర్‌లు మీ క్లస్టర్‌లో ప్రివిలేజ్డ్ పాడ్‌లను రన్ చేయాల్సిన అవసరం లేదు.
మరియు ప్రతిదీ మాతో బాగానే ఉన్నట్లు అనిపిస్తుంది. మరియు మా కుబెర్నెట్స్ క్లస్టర్‌ని రెండు నిమిషాల్లో హ్యాక్ చేయడం సాధ్యం కాదు.
అక్కడ సమస్య ఉంది. చాలా మటుకు, మీకు కుబెర్నెట్స్ క్లస్టర్ ఉంటే, మీ క్లస్టర్‌లో పర్యవేక్షణ ఇన్‌స్టాల్ చేయబడుతుంది. మీ క్లస్టర్‌కు మానిటరింగ్ ఉంటే, దానిని ప్రోమేథియస్ అని పిలుస్తారని అంచనా వేయడానికి కూడా నేను ముందుకు వెళ్తాను.
నేను మీకు చెప్పబోయేది ప్రోమేతియస్ ఆపరేటర్ మరియు ప్రోమేతియస్ రెండింటికీ దాని స్వచ్ఛమైన రూపంలో అందించబడుతుంది. ప్రశ్న ఏమిటంటే, నేను ఇంత త్వరగా క్లస్టర్‌లోకి అడ్మిన్‌ని పొందలేకపోతే, నేను మరింత చూడాలని దీని అర్థం. మరియు నేను మీ పర్యవేక్షణ సహాయంతో శోధించగలను.
బహుశా అందరూ హబ్రేలో ఒకే కథనాలను చదువుతారు మరియు పర్యవేక్షణ పర్యవేక్షణ నేమ్‌స్పేస్‌లో ఉంది. హెల్మ్ చార్ట్ అందరికీ దాదాపు ఒకే విధంగా ఉంటుంది. మీరు స్టేబుల్/ప్రోమేథియస్‌ని హెల్మ్ ఇన్‌స్టాల్ చేస్తే, మీరు దాదాపు అదే పేర్లతో ముగుస్తుందని నేను ఊహిస్తున్నాను. మరియు చాలా మటుకు నేను మీ క్లస్టర్‌లో DNS పేరును ఊహించనవసరం లేదు. ఎందుకంటే అది ప్రామాణికం.
తర్వాత మేము ఒక నిర్దిష్ట dev nsని కలిగి ఉన్నాము, దీనిలో మీరు నిర్దిష్ట పాడ్‌ని అమలు చేయవచ్చు. ఆపై ఈ పాడ్ నుండి ఇలాంటివి చేయడం చాలా సులభం:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics అనేది కుబెర్నెటెస్ API నుండే కొలమానాలను సేకరించే ప్రోమేతియస్ ఎగుమతిదారులలో ఒకటి. అక్కడ చాలా డేటా ఉంది, మీ క్లస్టర్‌లో ఏమి నడుస్తోంది, అది ఏమిటి, దానితో మీకు ఎలాంటి సమస్యలు ఉన్నాయి.
ఒక సాధారణ ఉదాహరణగా:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
అప్రివిలేజ్డ్ పాడ్ నుండి సాధారణ కర్ల్ అభ్యర్థన చేయడం ద్వారా, మీరు క్రింది సమాచారాన్ని పొందవచ్చు. మీరు అమలు చేస్తున్న Kubernetes యొక్క ఏ వెర్షన్ మీకు తెలియకపోతే, అది మీకు సులభంగా తెలియజేస్తుంది.
మరియు అత్యంత ఆసక్తికరమైన విషయం ఏమిటంటే, క్యూబ్-స్టేట్-మెట్రిక్‌లను యాక్సెస్ చేయడంతో పాటు, మీరు నేరుగా ప్రోమేతియస్‌ను కూడా సులభంగా యాక్సెస్ చేయవచ్చు. మీరు అక్కడ నుండి కొలమానాలను సేకరించవచ్చు. మీరు అక్కడ నుండి కొలమానాలను కూడా నిర్మించవచ్చు. సిద్ధాంతపరంగా కూడా, మీరు ప్రోమేతియస్‌లోని క్లస్టర్ నుండి అటువంటి ప్రశ్నను రూపొందించవచ్చు, అది కేవలం దాన్ని ఆపివేస్తుంది. మరియు మీ పర్యవేక్షణ క్లస్టర్ నుండి పని చేయడం పూర్తిగా ఆగిపోతుంది.
మరియు ఇక్కడ ఏదైనా బాహ్య పర్యవేక్షణ మీ పర్యవేక్షణను పర్యవేక్షిస్తుందా అనే ప్రశ్న తలెత్తుతుంది. నాకు ఎలాంటి పరిణామాలు లేకుండా కుబెర్నెట్స్ క్లస్టర్‌లో పనిచేసే అవకాశం నాకు ఇప్పుడే వచ్చింది. ఇకపై పర్యవేక్షణ లేనందున నేను అక్కడ పనిచేస్తున్నానని కూడా మీకు తెలియదు.
PSP మాదిరిగానే, సమస్య ఏమిటంటే, ఈ ఫాన్సీ టెక్నాలజీలన్నీ - కుబెర్నెట్స్, ప్రోమేథియస్ - అవి పని చేయవు మరియు రంధ్రాలతో నిండి ఉన్నాయి. నిజంగా కాదు.
అలాంటిది ఉంది - .
మీరు సాధారణ అడ్మిన్ అయితే, నెట్‌వర్క్ పాలసీ గురించి మీకు తెలిసి ఉండవచ్చు, ఇది మరొక యామల్ మాత్రమే, క్లస్టర్‌లో ఇప్పటికే చాలా ఉన్నాయి. మరియు కొన్ని నెట్‌వర్క్ విధానాలు ఖచ్చితంగా అవసరం లేదు. మరియు మీరు నెట్‌వర్క్ పాలసీ అంటే ఏమిటో చదివినా, అది కుబెర్నెట్స్ యొక్క యమ్ల్ ఫైర్‌వాల్, ఇది నేమ్‌స్పేస్‌ల మధ్య, పాడ్‌ల మధ్య యాక్సెస్ హక్కులను పరిమితం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, అప్పుడు మీరు ఖచ్చితంగా కుబెర్నెట్స్‌లోని యమ్ల్ ఫార్మాట్‌లోని ఫైర్‌వాల్ తదుపరి సారాంశాలపై ఆధారపడి ఉంటుందని నిర్ణయించుకున్నారు. ... కాదు కాదు . ఇది ఖచ్చితంగా అవసరం లేదు.
మీ కుబెర్నెట్‌లను ఉపయోగించి మీరు చాలా సులభమైన మరియు సరళమైన ఫైర్‌వాల్‌ని మరియు చాలా గ్రాన్యులర్‌గా నిర్మించవచ్చని మీరు మీ భద్రతా నిపుణులకు చెప్పనప్పటికీ. వారికి ఇది ఇంకా తెలియకపోతే మరియు మిమ్మల్ని ఇబ్బంది పెట్టకుంటే: “సరే, నాకు ఇవ్వండి, నాకు ఇవ్వండి...” ఏదైనా సందర్భంలో, మీ క్లస్టర్ నుండి లాగబడే కొన్ని సేవా స్థలాలకు యాక్సెస్‌ను బ్లాక్ చేయడానికి మీకు నెట్‌వర్క్ పాలసీ అవసరం. ఎలాంటి అనుమతి లేకుండా.
నేను ఇచ్చిన ఉదాహరణలో వలె, మీరు కుబెర్నెటెస్ క్లస్టర్‌లోని ఏదైనా నేమ్‌స్పేస్ నుండి క్యూబ్ స్టేట్ మెట్రిక్‌లను ఎలాంటి హక్కులు లేకుండా తీయవచ్చు. నెట్‌వర్క్ విధానాలు అన్ని ఇతర నేమ్‌స్పేస్‌ల నుండి మానిటరింగ్ నేమ్‌స్పేస్‌కి క్లోజ్డ్ యాక్సెస్‌ను కలిగి ఉన్నాయి మరియు అంతే: యాక్సెస్ లేదు, సమస్యలు లేవు. ఉన్న అన్ని చార్ట్‌లలో, ప్రామాణిక ప్రోమేతియస్ మరియు ఆపరేటర్‌లో ఉన్న ప్రోమేతియస్ రెండింటిలోనూ, వాటి కోసం నెట్‌వర్క్ విధానాలను ప్రారంభించడానికి హెల్మ్ విలువలలో ఒక ఎంపిక ఉంది. మీరు దీన్ని ఆన్ చేయాలి మరియు అవి పని చేస్తాయి.
ఇక్కడ నిజంగా ఒక సమస్య ఉంది. సాధారణ గడ్డం ఉన్న అడ్మిన్ అయినందున, మీరు నెట్‌వర్క్ విధానాలు అవసరం లేదని ఎక్కువగా నిర్ణయించుకున్నారు. మరియు హబ్ర్ వంటి వనరులపై అన్ని రకాల కథనాలను చదివిన తర్వాత, ఫ్లాన్నెల్, ముఖ్యంగా హోస్ట్-గేట్‌వే మోడ్‌తో మీరు ఎంచుకోగల ఉత్తమమైన విషయం అని మీరు నిర్ణయించుకున్నారు.
నేను ఏమి చేయాలి?
మీరు మీ కుబెర్నెటెస్ క్లస్టర్‌లో ఉన్న నెట్‌వర్క్ సొల్యూషన్‌ను మళ్లీ అమర్చడానికి ప్రయత్నించవచ్చు, దాన్ని మరింత ఫంక్షనల్‌తో భర్తీ చేయడానికి ప్రయత్నించండి. అదే కాలికో కోసం, ఉదాహరణకు. కానీ కుబెర్నెట్స్ వర్కింగ్ క్లస్టర్‌లో నెట్‌వర్క్ సొల్యూషన్‌ను మార్చడం చాలా చిన్నవిషయం కాదని నేను వెంటనే చెప్పాలనుకుంటున్నాను. నేను దానిని రెండుసార్లు పరిష్కరించాను (రెండు సార్లు, అయితే, సిద్ధాంతపరంగా), కానీ మేము స్లర్మ్స్‌లో దీన్ని ఎలా చేయాలో కూడా చూపించాము. మా విద్యార్థుల కోసం, మేము Kubernetes క్లస్టర్‌లో నెట్‌వర్క్ సొల్యూషన్‌ను ఎలా మార్చాలో చూపించాము. సూత్రప్రాయంగా, మీరు ఉత్పత్తి క్లస్టర్‌లో పనికిరాని సమయం లేదని నిర్ధారించుకోవడానికి ప్రయత్నించవచ్చు. కానీ మీరు బహుశా విజయం సాధించలేరు.
మరియు సమస్య నిజానికి చాలా సరళంగా పరిష్కరించబడుతుంది. క్లస్టర్‌లో సర్టిఫికెట్లు ఉన్నాయి మరియు మీ సర్టిఫికెట్‌ల గడువు ఒక సంవత్సరంలో ముగుస్తుందని మీకు తెలుసు. సరే, సాధారణంగా క్లస్టర్‌లో సర్టిఫికేట్‌లతో కూడిన సాధారణ పరిష్కారం - మనం ఎందుకు చింతిస్తున్నాము, మేము సమీపంలో కొత్త క్లస్టర్‌ను పెంచుతాము, పాతది కుళ్ళిపోనివ్వండి మరియు ప్రతిదీ మళ్లీ అమర్చండి. నిజమే, అది కుళ్ళిపోయినప్పుడు, మేము ఒక రోజు కూర్చోవలసి ఉంటుంది, కానీ ఇక్కడ కొత్త క్లస్టర్ ఉంది.
మీరు కొత్త క్లస్టర్‌ను పెంచినప్పుడు, అదే సమయంలో ఫ్లాన్నెల్‌కు బదులుగా కాలికోను చొప్పించండి.
మీ సర్టిఫికేట్లు వంద సంవత్సరాలు జారీ చేయబడితే మరియు మీరు క్లస్టర్‌ను మళ్లీ అమలు చేయకపోతే ఏమి చేయాలి? Kube-RBAC-Proxy వంటిది ఉంది. ఇది చాలా కూల్ డెవలప్‌మెంట్, ఇది కుబెర్నెట్స్ క్లస్టర్‌లోని ఏదైనా పాడ్‌కి సైడ్‌కార్ కంటైనర్‌గా పొందుపరచడానికి మిమ్మల్ని అనుమతిస్తుంది. మరియు ఇది వాస్తవానికి కుబెర్నెటెస్ యొక్క RBAC ద్వారా ఈ పాడ్‌కు అధికారాన్ని జోడిస్తుంది.
ఒక సమస్య ఉంది. మునుపు, ఈ Kube-RBAC-ప్రాక్సీ సొల్యూషన్ ఆపరేటర్ ప్రోమేథియస్‌లో నిర్మించబడింది. కానీ అప్పుడు అతను వెళ్లిపోయాడు. ఇప్పుడు ఆధునిక సంస్కరణలు మీరు నెట్‌వర్క్ విధానాన్ని కలిగి ఉన్నారనే వాస్తవంపై ఆధారపడతాయి మరియు వాటిని ఉపయోగించి దాన్ని మూసివేయండి. అందువల్ల మేము చార్ట్‌ను కొద్దిగా తిరిగి వ్రాయవలసి ఉంటుంది. నిజానికి, మీరు వెళ్తే , దీన్ని సైడ్‌కార్‌లుగా ఎలా ఉపయోగించాలో ఉదాహరణలు ఉన్నాయి మరియు చార్ట్‌లను కనిష్టంగా తిరిగి వ్రాయవలసి ఉంటుంది.
ఇంకో చిన్న సమస్య ఉంది. ప్రోమేతియస్ మాత్రమే దాని కొలమానాలను ఎవరికైనా అందజేసేవాడు కాదు. మా కుబెర్నెటీస్ క్లస్టర్ కాంపోనెంట్‌లన్నీ కూడా వాటి స్వంత కొలమానాలను తిరిగి ఇవ్వగలవు.
కానీ నేను ఇప్పటికే చెప్పినట్లుగా, మీరు క్లస్టర్‌ను యాక్సెస్ చేయలేకపోతే మరియు సమాచారాన్ని సేకరించలేకపోతే, మీరు కనీసం కొంత హాని చేయవచ్చు.
కాబట్టి కుబెర్నెటీస్ క్లస్టర్‌ను ఎలా నాశనం చేయవచ్చో నేను త్వరగా రెండు మార్గాలను చూపుతాను.
నేను ఈ విషయం చెబితే మీరు నవ్వుతారు, ఇవి రెండు రియల్ లైఫ్ కేసులు.
విధానం ఒకటి. వనరుల క్షీణత.
ఇంకో స్పెషల్ పాడ్ లాంచ్ చేద్దాం. ఇందులో ఇలాంటి సెక్షన్ ఉంటుంది.
resources:
requests:
cpu: 4
memory: 4Gi మీకు తెలిసినట్లుగా, అభ్యర్థనలు అనేది అభ్యర్థనలతో కూడిన నిర్దిష్ట పాడ్‌ల కోసం హోస్ట్‌లో రిజర్వు చేయబడిన CPU మరియు మెమరీ మొత్తం. మేము Kubernetes క్లస్టర్‌లో నాలుగు-కోర్ హోస్ట్‌ను కలిగి ఉంటే మరియు నాలుగు CPU పాడ్‌లు అభ్యర్థనలతో అక్కడికి చేరుకుంటే, ఈ హోస్ట్‌కి అభ్యర్థనలతో కూడిన పాడ్‌లు ఏవీ రాలేవని అర్థం.
నేను అటువంటి పాడ్‌ను అమలు చేస్తే, నేను ఆదేశాన్ని అమలు చేస్తాను:
$ kubectl scale special-pod --replicas=...అప్పుడు కుబెర్నెటెస్ క్లస్టర్‌కు మరెవరూ అమర్చలేరు. ఎందుకంటే అన్ని నోడ్‌ల అభ్యర్థనలు అయిపోతాయి. అందువలన నేను మీ కుబెర్నెట్స్ క్లస్టర్‌ను ఆపివేస్తాను. నేను సాయంత్రం ఇలా చేస్తే, నేను చాలా కాలం పాటు విస్తరణలను ఆపగలను.
మనం కుబెర్నెట్స్ డాక్యుమెంటేషన్‌ని మళ్లీ చూస్తే, పరిమితి పరిధి అని పిలువబడే ఈ విషయం మనకు కనిపిస్తుంది. ఇది క్లస్టర్ వస్తువుల కోసం వనరులను సెట్ చేస్తుంది. మీరు లిమిట్ రేంజ్ ఆబ్జెక్ట్‌ను yamlలో వ్రాయవచ్చు, దానిని నిర్దిష్ట నేమ్‌స్పేస్‌లకు వర్తింపజేయవచ్చు - ఆపై ఈ నేమ్‌స్పేస్‌లో మీరు పాడ్‌ల కోసం డిఫాల్ట్, గరిష్ట మరియు కనిష్ట వనరులను కలిగి ఉన్నారని చెప్పవచ్చు.
అటువంటి వాటి సహాయంతో, మేము జట్ల నిర్దిష్ట ఉత్పత్తి నేమ్‌స్పేస్‌లలోని వినియోగదారులను వారి పాడ్‌లపై అన్ని రకాల అసహ్యకరమైన విషయాలను సూచించే సామర్థ్యాన్ని పరిమితం చేయవచ్చు. కానీ దురదృష్టవశాత్తూ, ఒకటి కంటే ఎక్కువ CPUల కోసం అభ్యర్థనలతో పాడ్‌లను ప్రారంభించలేమని మీరు వినియోగదారుకు చెప్పినప్పటికీ, అటువంటి అద్భుతమైన స్కేల్ కమాండ్ ఉంది లేదా వారు డాష్‌బోర్డ్ ద్వారా స్కేల్ చేయవచ్చు.
మరియు ఇక్కడ పద్ధతి సంఖ్య రెండు నుండి వచ్చింది. మేము 11 పాడ్‌లను ప్రారంభించాము. అంటే పదకొండు బిలియన్లు. ఇది నేను అలాంటి నంబర్‌తో వచ్చినందున కాదు, నేనే దానిని చూసినందున.
అసలు కథ. సాయంత్రం ఆలస్యంగా నేను ఆఫీసు నుండి బయలుదేరబోతున్నాను. డెవలపర్‌ల గుంపు మూలన కూర్చొని, తమ ల్యాప్‌టాప్‌లతో ఆవేశంగా ఏదో చేయడం నేను చూస్తున్నాను. నేను అబ్బాయిల వద్దకు వెళ్లి అడిగాను: "మీకు ఏమి జరిగింది?"
కొంచెం ముందుగా, సాయంత్రం తొమ్మిది గంటల ప్రాంతంలో, డెవలపర్‌లలో ఒకరు ఇంటికి వెళ్లడానికి సిద్ధంగా ఉన్నారు. మరియు నేను నిర్ణయించుకున్నాను: "నేను ఇప్పుడు నా దరఖాస్తును ఒకదానికి తగ్గించుకుంటాను." నేను ఒకటి నొక్కాను, కానీ ఇంటర్నెట్ కొద్దిగా నెమ్మదించింది. అతను దానిని మళ్ళీ నొక్కి, అతను దానిని నొక్కి, మరియు ఎంటర్ క్లిక్ చేసాడు. నేను చేయగలిగినదంతా పోక్ చేసాను. అప్పుడు ఇంటర్నెట్ ప్రాణం పోసుకుంది - మరియు ప్రతిదీ ఈ సంఖ్యకు తగ్గించడం ప్రారంభించింది.
నిజమే, ఈ కథ కుబెర్నెట్స్‌లో జరగలేదు; ఆ సమయంలో అది నోమాడ్. నోమాడ్‌ను స్కేల్ చేయడానికి నిరంతర ప్రయత్నాల నుండి ఆపడానికి మేము చేసిన ఒక గంట తర్వాత, నోమాడ్ తాను స్కేలింగ్‌ను ఆపలేనని మరియు ఇంకేమీ చేయనని సమాధానమిచ్చాడు. "నేను అలసిపోయాను, నేను బయలుదేరుతున్నాను." మరియు అతను ముడుచుకున్నాడు.
సహజంగానే, నేను కుబెర్నెట్స్‌లో కూడా అదే చేయడానికి ప్రయత్నించాను. కుబెర్నెటెస్ పదకొండు బిలియన్ పాడ్‌లతో సంతోషంగా లేడు, అతను ఇలా అన్నాడు: “నేను చేయలేను. అంతర్గత మౌత్ గార్డ్‌లను మించిపోయింది." కానీ 1 పాడ్‌లు చేయగలవు.
ఒక బిలియన్‌కి ప్రతిస్పందనగా, క్యూబ్ దానిలోకి ఉపసంహరించుకోలేదు. అతను నిజంగా స్కేలింగ్ ప్రారంభించాడు. ప్రక్రియ మరింత ముందుకు సాగింది, కొత్త పాడ్‌లను రూపొందించడానికి అతనికి ఎక్కువ సమయం పట్టింది. కానీ ఇప్పటికీ ప్రక్రియ కొనసాగింది. ఒకే సమస్య ఏమిటంటే, నేను నా నేమ్‌స్పేస్‌లో అపరిమితంగా పాడ్‌లను ప్రారంభించగలిగితే, అభ్యర్థనలు మరియు పరిమితులు లేకుండా కూడా నేను కొన్ని టాస్క్‌లతో చాలా పాడ్‌లను ప్రారంభించగలను, ఈ టాస్క్‌ల సహాయంతో నోడ్‌లు CPUలో మెమరీలో జోడించడం ప్రారంభిస్తాయి. నేను చాలా పాడ్‌లను లాంచ్ చేసినప్పుడు, వాటి నుండి సమాచారం నిల్వలోకి వెళ్లాలి, అంటే, మొదలైనవి. మరియు చాలా సమాచారం అక్కడకు వచ్చినప్పుడు, నిల్వ చాలా నెమ్మదిగా తిరిగి రావడం ప్రారంభమవుతుంది - మరియు కుబెర్నెటెస్ నిస్తేజంగా మారడం ప్రారంభమవుతుంది.
మరియు మరొక సమస్య... మీకు తెలిసినట్లుగా, కుబెర్నెట్స్ నియంత్రణ అంశాలు ఒక ప్రధాన విషయం కాదు, అనేక భాగాలు. ప్రత్యేకించి, కంట్రోలర్ మేనేజర్, షెడ్యూలర్ మరియు మొదలైనవి ఉన్నాయి. ఈ కుర్రాళ్లందరూ ఒకే సమయంలో అనవసరమైన, తెలివితక్కువ పనిని చేయడం ప్రారంభిస్తారు, ఇది కాలక్రమేణా ఎక్కువ సమయం తీసుకోవడం ప్రారంభమవుతుంది. కంట్రోలర్ మేనేజర్ కొత్త పాడ్‌లను సృష్టిస్తారు. షెడ్యూలర్ వారి కోసం కొత్త నోడ్‌ను కనుగొనడానికి ప్రయత్నిస్తాడు. మీ క్లస్టర్‌లో త్వరలో కొత్త నోడ్‌లు అయిపోయే అవకాశం ఉంది. కుబెర్నెటెస్ క్లస్టర్ నెమ్మదిగా మరియు నెమ్మదిగా పని చేయడం ప్రారంభిస్తుంది.
కానీ నేను మరింత ముందుకు వెళ్లాలని నిర్ణయించుకున్నాను. మీకు తెలిసినట్లుగా, కుబెర్నెట్స్‌లో సేవ అని పిలువబడే ఒక విషయం ఉంది. బాగా, మీ క్లస్టర్‌లలో డిఫాల్ట్‌గా, చాలా మటుకు, సేవ IP పట్టికలను ఉపయోగించి పని చేస్తుంది.
మీరు ఒక బిలియన్ పాడ్‌లను అమలు చేస్తే, ఉదాహరణకు, కొత్త సేవలను సృష్టించమని కుబెర్నెటిస్‌ను బలవంతం చేయడానికి స్క్రిప్ట్‌ని ఉపయోగించండి:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done క్లస్టర్ యొక్క అన్ని నోడ్‌లలో, మరింత ఎక్కువ కొత్త iptables నియమాలు సుమారుగా ఏకకాలంలో రూపొందించబడతాయి. అంతేకాకుండా, ప్రతి సేవ కోసం ఒక బిలియన్ iptables నియమాలు రూపొందించబడతాయి.
నేను ఈ మొత్తం విషయాన్ని అనేక వేల, పది వరకు తనిఖీ చేసాను. మరియు సమస్య ఏమిటంటే, ఇప్పటికే ఈ థ్రెషోల్డ్ వద్ద నోడ్‌కు ssh చేయడం చాలా సమస్యాత్మకం. ఎందుకంటే ప్యాకెట్లు, చాలా గొలుసుల గుండా వెళుతున్నాయి, చాలా మంచివి కావు.
మరియు ఇది కూడా కుబెర్నెట్స్ సహాయంతో పరిష్కరించబడుతుంది. అటువంటి రిసోర్స్ కోటా ఆబ్జెక్ట్ ఉంది. క్లస్టర్‌లో నేమ్‌స్పేస్ కోసం అందుబాటులో ఉన్న వనరులు మరియు ఆబ్జెక్ట్‌ల సంఖ్యను సెట్ చేస్తుంది. మేము కుబెర్నెటెస్ క్లస్టర్‌లోని ప్రతి నేమ్‌స్పేస్‌లో యామల్ వస్తువును సృష్టించవచ్చు. ఈ ఆబ్జెక్ట్‌ని ఉపయోగించి, ఈ నేమ్‌స్పేస్ కోసం నిర్దిష్ట సంఖ్యలో అభ్యర్థనలు మరియు పరిమితులు కేటాయించబడ్డాయని మనం చెప్పగలం, ఆపై ఈ నేమ్‌స్పేస్‌లో 10 సేవలు మరియు 10 పాడ్‌లను సృష్టించడం సాధ్యమవుతుందని చెప్పగలం. మరియు ఒకే డెవలపర్ కనీసం సాయంత్రాలలో తనను తాను ఉక్కిరిబిక్కిరి చేయవచ్చు. కుబెర్నెటెస్ అతనితో ఇలా చెబుతాడు: "మీరు మీ పాడ్‌లను ఆ మొత్తానికి స్కేల్ చేయలేరు, ఎందుకంటే వనరు కోటాను మించిపోయింది." అంతే, సమస్య పరిష్కరించబడింది. .
ఈ విషయంలో ఒక సమస్యాత్మక అంశం తలెత్తుతుంది. కుబెర్నెటెస్‌లో నేమ్‌స్పేస్‌ని సృష్టించడం ఎంత కష్టంగా మారుతుందో మీకు అనిపిస్తుంది. దీన్ని సృష్టించడానికి, మనం చాలా విషయాలను పరిగణనలోకి తీసుకోవాలి.
వనరుల కోటా + పరిమితి పరిధి + RBAC
• నేమ్‌స్పేస్‌ని సృష్టించండి
• లోపల పరిమితిని సృష్టించండి
• వనరుల కోటా లోపల సృష్టించండి
• CI కోసం సేవా ఖాతాను సృష్టించండి
• CI మరియు వినియోగదారుల కోసం రోల్‌బైండింగ్‌ని సృష్టించండి
• ఐచ్ఛికంగా అవసరమైన సర్వీస్ పాడ్‌లను ప్రారంభించండి
అందువల్ల, నా పరిణామాలను పంచుకోవడానికి నేను ఈ అవకాశాన్ని ఉపయోగించాలనుకుంటున్నాను. SDK ఆపరేటర్ అని పిలువబడే ఒక విషయం ఉంది. ఇది Kubernetes క్లస్టర్ కోసం ఆపరేటర్‌లను వ్రాయడానికి ఒక మార్గం. మీరు Ansible ఉపయోగించి స్టేట్‌మెంట్‌లను వ్రాయవచ్చు.
మొదట ఇది Ansible లో వ్రాయబడింది, ఆపై SDK ఆపరేటర్ ఉన్నట్లు నేను చూసాను మరియు Ansible పాత్రను ఆపరేటర్‌గా తిరిగి వ్రాసాను. ఈ ప్రకటన మిమ్మల్ని కుబెర్నెట్స్ క్లస్టర్‌లో కమాండ్ అని పిలిచే ఒక వస్తువును సృష్టించడానికి అనుమతిస్తుంది. కమాండ్ లోపల, ఈ కమాండ్ కోసం పర్యావరణాన్ని yamlలో వివరించడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. మరియు జట్టు వాతావరణంలో, మేము చాలా వనరులను కేటాయిస్తున్నామని వివరించడానికి ఇది అనుమతిస్తుంది.
సూక్ష్మశరీరం .
మరియు ముగింపులో. వీటన్నింటితో ఏమి చేయాలి?
ప్రధమ. పాడ్ సెక్యూరిటీ పాలసీ బాగుంది. మరియు ఈ రోజు వరకు కుబెర్నెట్స్ ఇన్‌స్టాలర్‌లు ఎవరూ వాటిని ఉపయోగించనప్పటికీ, మీరు వాటిని మీ క్లస్టర్‌లలో ఉపయోగించాల్సి ఉంటుంది.
నెట్‌వర్క్ పాలసీ అనేది మరొక అనవసరమైన ఫీచర్ మాత్రమే కాదు. క్లస్టర్‌లో ఇది నిజంగా అవసరం.
LimitRange/ResourceQuota - ఇది ఉపయోగించడానికి సమయం. మేము దీన్ని చాలా కాలం క్రితం ఉపయోగించడం ప్రారంభించాము మరియు చాలా కాలంగా అందరూ దీన్ని ఉపయోగిస్తున్నారని నేను ఖచ్చితంగా అనుకుంటున్నాను. ఇది చాలా అరుదు అని తేలింది.
నివేదిక సమయంలో నేను పేర్కొన్న దానితో పాటు, క్లస్టర్‌పై దాడి చేయడానికి మిమ్మల్ని అనుమతించే డాక్యుమెంట్ లేని ఫీచర్‌లు కూడా ఉన్నాయి. ఇటీవలే విడుదలైంది .
కొన్ని విషయాలు చాలా బాధాకరమైనవి మరియు బాధాకరమైనవి. ఉదాహరణకు, కొన్ని షరతులలో, Kubernetes క్లస్టర్‌లోని క్యూబ్లెట్‌లు అనధికార వినియోగదారుకు వార్‌లాక్స్ డైరెక్టరీలోని కంటెంట్‌లను అందించగలవు.
నేను మీకు చెప్పిన ప్రతిదాన్ని ఎలా పునరుత్పత్తి చేయాలో సూచనలు ఉన్నాయి. ResourceQuota మరియు Pod సెక్యూరిటీ పాలసీ ఎలా ఉంటుందో దాని ఉత్పత్తి ఉదాహరణలతో ఫైల్‌లు ఉన్నాయి. మరియు మీరు ఇవన్నీ తాకవచ్చు.
అందరికి ధన్యవాదాలు.
మూలం: www.habr.com