నా పేరు విక్టర్ యాగోఫరోవ్, మరియు నేను Ops (ఆపరేషన్) టీమ్‌లో టెక్నికల్ డెవలప్‌మెంట్ మేనేజర్‌గా DomClick వద్ద కుబెర్నెట్స్ ప్లాట్‌ఫారమ్‌ను అభివృద్ధి చేస్తున్నాను. నేను మా Dev <-> Ops ప్రాసెస్‌ల నిర్మాణం, రష్యాలోని అతిపెద్ద k8s క్లస్టర్‌లలో ఒకదానిని ఆపరేట్ చేసే ఫీచర్లు, అలాగే మా బృందం వర్తించే DevOps/SRE అభ్యాసాల గురించి మాట్లాడాలనుకుంటున్నాను.
Ops బృందం
ఆప్స్ టీమ్‌లో ప్రస్తుతం 15 మంది ఉన్నారు. వారిలో ముగ్గురు కార్యాలయానికి బాధ్యత వహిస్తారు, ఇద్దరు వేర్వేరు టైమ్ జోన్‌లో పని చేస్తారు మరియు రాత్రితో సహా అందుబాటులో ఉంటారు. అందువల్ల, Ops నుండి ఎవరైనా ఎల్లప్పుడూ మానిటర్ వద్ద ఉంటారు మరియు ఏదైనా సంక్లిష్టత యొక్క సంఘటనకు ప్రతిస్పందించడానికి సిద్ధంగా ఉంటారు. మాకు రాత్రి షిఫ్ట్‌లు లేవు, ఇది మన మనస్తత్వాన్ని సంరక్షిస్తుంది మరియు ప్రతి ఒక్కరికీ తగినంత నిద్ర పొందడానికి మరియు కంప్యూటర్ వద్ద మాత్రమే కాకుండా విశ్రాంతి సమయాన్ని గడపడానికి అవకాశాన్ని ఇస్తుంది.
ప్రతి ఒక్కరికి వేర్వేరు సామర్థ్యాలు ఉన్నాయి: నెట్‌వర్కర్‌లు, DBAలు, ELK స్టాక్ నిపుణులు, కుబెర్నెట్స్ నిర్వాహకులు/డెవలపర్‌లు, పర్యవేక్షణ, వర్చువలైజేషన్, హార్డ్‌వేర్ నిపుణులు మొదలైనవి. ఒక విషయం అందరినీ ఏకం చేస్తుంది - ప్రతి ఒక్కరూ మనలో ఎవరినైనా కొంత వరకు భర్తీ చేయవచ్చు: ఉదాహరణకు, k8s క్లస్టర్‌లో కొత్త నోడ్‌లను పరిచయం చేయండి, PostgreSQLని అప్‌డేట్ చేయండి, CI/CD + Ansible పైప్‌లైన్ రాయండి, పైథాన్/బాష్/గోలో ఏదైనా ఆటోమేట్ చేయండి, హార్డ్‌వేర్‌ని కనెక్ట్ చేయండి డేటా సెంటర్. ఏ ప్రాంతంలోనైనా బలమైన సామర్థ్యాలు మీ కార్యాచరణ దిశను మార్చకుండా మరియు ఇతర ప్రాంతంలో మెరుగుపరచడం ప్రారంభించకుండా మిమ్మల్ని నిరోధించవు. ఉదాహరణకు, నేను PostgreSQL స్పెషలిస్ట్‌గా కంపెనీలో చేరాను, ఇప్పుడు నా ప్రధాన బాధ్యత కుబెర్నెటెస్ క్లస్టర్‌లు. జట్టులో, ఏదైనా ఎత్తు స్వాగతించబడుతుంది మరియు పరపతి భావం చాలా అభివృద్ధి చెందింది.
మార్గం ద్వారా, మేము వేటాడుతున్నాము. అభ్యర్థుల అవసరాలు చాలా ప్రామాణికమైనవి. నాకు వ్యక్తిగతంగా, ఒక వ్యక్తి జట్టుకు సరిపోవడం ముఖ్యం, సంఘర్షణ లేనివాడు, కానీ తన అభిప్రాయాన్ని ఎలా కాపాడుకోవాలో కూడా తెలుసు, అభివృద్ధి చెందాలని కోరుకుంటాడు మరియు కొత్తగా ఏదైనా చేయడానికి భయపడడు, అతని ఆలోచనలను అందిస్తుంది. అలాగే, స్క్రిప్టింగ్ భాషలలో ప్రోగ్రామింగ్ నైపుణ్యాలు, లైనక్స్ మరియు ఇంగ్లీషు బేసిక్స్ పరిజ్ఞానం అవసరం. ఇంగ్లీష్ చాలా అవసరం, తద్వారా ఫకాప్ సంభవించినప్పుడు ఒక వ్యక్తి 10 సెకన్లలో సమస్యకు పరిష్కారాన్ని గూగుల్ చేయవచ్చు మరియు 10 నిమిషాల్లో కాదు. Linux గురించి లోతైన పరిజ్ఞానం ఉన్న నిపుణులను కనుగొనడం ఇప్పుడు చాలా కష్టం: ఇది హాస్యాస్పదంగా ఉంది, కానీ ముగ్గురిలో ఇద్దరు అభ్యర్థులు ప్రశ్నకు సమాధానం ఇవ్వలేరు “లోడ్ సగటు ఏమిటి? ఇది దేనితో తయారు చేయబడింది?", మరియు "C ప్రోగ్రామ్ నుండి కోర్ డంప్‌ను ఎలా సమీకరించాలి" అనే ప్రశ్న సూపర్‌మెన్... లేదా డైనోసార్ల ప్రపంచం నుండి ఏదో ఒకటిగా పరిగణించబడుతుంది. మేము దీనిని సహించవలసి ఉంటుంది, ఎందుకంటే సాధారణంగా వ్యక్తులు ఇతర సామర్థ్యాలను బాగా అభివృద్ధి చేస్తారు, కానీ మేము Linux ను నేర్పుతాము. “ఆధునిక మేఘాల ప్రపంచంలో DevOps ఇంజనీర్ ఇవన్నీ ఎందుకు తెలుసుకోవాలి” అనే ప్రశ్నకు సమాధానం వ్యాసం యొక్క పరిధికి వెలుపల వదిలివేయాలి, కానీ మూడు మాటలలో: ఇవన్నీ అవసరం.
టీమ్ టూల్స్
ఆటోమేషన్‌లో టూల్స్ బృందం ముఖ్యమైన పాత్ర పోషిస్తుంది. డెవలపర్‌ల కోసం అనుకూలమైన గ్రాఫికల్ మరియు CLI సాధనాలను రూపొందించడం వారి ప్రధాన పని. ఉదాహరణకు, మా అంతర్గత డెవలప్‌మెంట్ కాన్ఫర్ మిమ్మల్ని కేవలం కొన్ని మౌస్ క్లిక్‌లతో కుబెర్నెట్స్‌కి యాప్‌ను అక్షరాలా రోల్ అవుట్ చేయడానికి, దాని వనరులు, వాల్ట్ నుండి కీలు మొదలైన వాటిని కాన్ఫిగర్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. గతంలో, జెంకిన్స్ + హెల్మ్ 2 ఉంది, కానీ కాపీ-పేస్ట్‌ను తొలగించడానికి మరియు సాఫ్ట్‌వేర్ జీవితచక్రానికి ఏకరూపతను తీసుకురావడానికి నేను నా స్వంత సాధనాన్ని అభివృద్ధి చేయాల్సి వచ్చింది.
Ops బృందం డెవలపర్‌ల కోసం పైప్‌లైన్‌లను వ్రాయదు, కానీ వారి రచనలో ఏవైనా సమస్యలపై సలహా ఇవ్వగలరు (కొంతమందికి ఇప్పటికీ హెల్మ్ 3 ఉంది).
DevOps
DevOps కొరకు, మేము దీన్ని ఇలా చూస్తాము:
దేవ్ టీమ్‌లు కోడ్‌ను వ్రాస్తాయి, కాన్ఫర్ టు dev -> qa/stage -> prod ద్వారా దాన్ని రోల్ అవుట్ చేస్తాయి. కోడ్ మందగించకుండా మరియు లోపాలను కలిగి ఉండకుండా చూసుకోవాల్సిన బాధ్యత Dev మరియు Ops టీమ్‌లది. పగటిపూట, Ops బృందం నుండి డ్యూటీలో ఉన్న వ్యక్తి ముందుగా తన దరఖాస్తుతో ఒక సంఘటనకు ప్రతిస్పందించాలి మరియు సాయంత్రం మరియు రాత్రి సమయంలో, విధి నిర్వహణలో ఉన్న నిర్వాహకుడు (Ops) డెవలపర్‌కు తెలిస్తే అతనిని నిద్ర లేపాలి. సమస్య మౌలిక సదుపాయాలలో లేదని ఖచ్చితంగా చెప్పవచ్చు. పర్యవేక్షణలో అన్ని కొలమానాలు మరియు హెచ్చరికలు స్వయంచాలకంగా లేదా సెమీ ఆటోమేటిక్‌గా కనిపిస్తాయి.
ఆప్స్ యొక్క బాధ్యత ప్రాంతం అప్లికేషన్ ఉత్పత్తిలోకి వచ్చిన క్షణం నుండి ప్రారంభమవుతుంది, కానీ దేవ్ యొక్క బాధ్యత అక్కడితో ముగియదు - మేము అదే పని చేస్తాము మరియు అదే పడవలో ఉన్నాము.
డెవలపర్‌లు అడ్మిన్ మైక్రోసర్వీస్ (ఉదాహరణకు, గో బ్యాకెండ్ + HTML5) వ్రాయడంలో సహాయం కావాలంటే అడ్మిన్‌లకు సలహా ఇస్తారు మరియు ఏదైనా ఇన్‌ఫ్రాస్ట్రక్చర్ సమస్యలు లేదా k8sకి సంబంధించిన సమస్యలపై డెవలపర్‌లకు అడ్మిన్‌లు సలహా ఇస్తారు.
మార్గం ద్వారా, మాకు ఏకశిలా లేదు, మైక్రోసర్వీసెస్ మాత్రమే. సంఖ్య ద్వారా కొలిస్తే, వారి సంఖ్య ఇప్పటివరకు ఉత్పత్తి k900s క్లస్టర్‌లో 1000 మరియు 8 మధ్య హెచ్చుతగ్గులకు గురవుతుంది విస్తరణలు. పాడ్‌ల సంఖ్య 1700 మరియు 2000 మధ్య హెచ్చుతగ్గులకు లోనవుతుంది. ప్రస్తుతం ఉత్పత్తి క్లస్టర్‌లో దాదాపు 2000 పాడ్‌లు ఉన్నాయి.
మేము అనవసరమైన మైక్రోసర్వీస్‌లను పర్యవేక్షిస్తాము మరియు సెమీ ఆటోమేటిక్‌గా వాటిని కత్తిరించాము కాబట్టి నేను ఖచ్చితమైన సంఖ్యలను ఇవ్వలేను. K8s మాకు అనవసరమైన ఎంటిటీలను ట్రాక్ చేయడంలో సహాయపడుతుంది , ఇది చాలా వనరులు మరియు డబ్బును ఆదా చేస్తుంది.
వనరుల నిర్వహణ
పర్యవేక్షణ
చక్కటి నిర్మాణాత్మక మరియు సమాచార పర్యవేక్షణ పెద్ద క్లస్టర్ యొక్క ఆపరేషన్‌లో మూలస్తంభంగా మారుతుంది. అన్ని పర్యవేక్షణ అవసరాలలో 100% కవర్ చేసే సార్వత్రిక పరిష్కారాన్ని మేము ఇంకా కనుగొనలేదు, కాబట్టి మేము ఈ వాతావరణంలో క్రమానుగతంగా విభిన్న అనుకూల పరిష్కారాలను సృష్టిస్తాము.
- Zabbix. మంచి పాత పర్యవేక్షణ, ఇది ప్రాథమికంగా మౌలిక సదుపాయాల యొక్క మొత్తం స్థితిని ట్రాక్ చేయడానికి ఉద్దేశించబడింది. ప్రాసెసింగ్, మెమరీ, డిస్క్‌లు, నెట్‌వర్క్ మరియు మొదలైన వాటి పరంగా నోడ్ ఎప్పుడు చనిపోతుందో ఇది మాకు తెలియజేస్తుంది. అతీంద్రియమైనది ఏమీ లేదు, కానీ మేము ఏజెంట్ల యొక్క ప్రత్యేక డెమోన్‌సెట్‌ను కూడా కలిగి ఉన్నాము, దీని సహాయంతో, ఉదాహరణకు, మేము క్లస్టర్‌లో DNS స్థితిని పర్యవేక్షిస్తాము: మేము స్టుపిడ్ కోర్డెన్స్ పాడ్‌ల కోసం చూస్తాము, మేము బాహ్య హోస్ట్‌ల లభ్యతను తనిఖీ చేస్తాము. దీనితో ఎందుకు ఇబ్బంది పడుతుందో అనిపిస్తుంది, కానీ పెద్ద మొత్తంలో ట్రాఫిక్‌తో ఈ భాగం తీవ్రమైన వైఫల్యం. ఇప్పటికే నేను , క్లస్టర్‌లో DNS పనితీరుతో నేను ఎలా కష్టపడ్డాను.
- ప్రోమేతియస్ ఆపరేటర్. వివిధ ఎగుమతిదారుల సమితి క్లస్టర్ యొక్క అన్ని భాగాల యొక్క పెద్ద అవలోకనాన్ని అందిస్తుంది. తరువాత, మేము గ్రాఫానాలోని పెద్ద డాష్‌బోర్డ్‌లలో వీటన్నింటిని దృశ్యమానం చేస్తాము మరియు హెచ్చరికల కోసం అలర్ట్‌మేనేజర్‌ని ఉపయోగిస్తాము.
మాకు మరొక ఉపయోగకరమైన సాధనం . ఒక జట్టు మరొక జట్టు ప్రవేశ మార్గాలను అతివ్యాప్తి చేసిన పరిస్థితిని మేము అనేక సార్లు ఎదుర్కొన్న తర్వాత మేము దానిని వ్రాసాము, ఫలితంగా 50x లోపాలు ఏర్పడతాయి. ఇప్పుడు ఉత్పత్తిని అమలు చేయడానికి ముందు, డెవలపర్‌లు ఎవరూ ప్రభావితం చేయబడరని తనిఖీ చేస్తారు మరియు నా బృందానికి ఇది ఇన్‌గ్రెస్‌లతో సమస్యలను ప్రాథమిక నిర్ధారణకు మంచి సాధనం. ఇది మొదట నిర్వాహకుల కోసం వ్రాయబడింది మరియు అది “వికృతంగా” కనిపించడం చాలా హాస్యాస్పదంగా ఉంది, కానీ దేవ్ బృందాలు ఈ సాధనంతో ప్రేమలో పడిన తర్వాత, అది చాలా మారిపోయింది మరియు “అడ్మిన్‌ల కోసం ఒక అడ్మిన్ వెబ్ ఫేస్‌ను రూపొందించాడు. ” త్వరలో మేము ఈ సాధనాన్ని వదిలివేస్తాము మరియు పైప్‌లైన్‌ను రూపొందించడానికి ముందే అటువంటి పరిస్థితులు ధృవీకరించబడతాయి.
క్యూబ్‌లో జట్టు వనరులు
మేము ఉదాహరణలలోకి ప్రవేశించే ముందు, మేము వనరులను ఎలా కేటాయిస్తామో వివరించడం విలువ సూక్ష్మసేవలు.
ఏ బృందాలు మరియు వాటిని ఏ పరిమాణంలో ఉపయోగిస్తారో అర్థం చేసుకోవడానికి వనరులు (ప్రాసెసర్, మెమరీ, స్థానిక SSD), మేము ప్రతి ఆదేశాన్ని దాని స్వంతదానిని కేటాయిస్తాము నేంస్పేస్ "క్యూబ్"లో మరియు ప్రాసెసర్, మెమరీ మరియు డిస్క్ పరంగా దాని గరిష్ట సామర్థ్యాలను పరిమితం చేయండి, గతంలో జట్ల అవసరాలను చర్చించారు. దీని ప్రకారం, ఒక కమాండ్, సాధారణంగా, విస్తరణ కోసం మొత్తం క్లస్టర్‌ను నిరోధించదు, వేలాది కోర్లు మరియు టెరాబైట్‌ల మెమరీని కేటాయిస్తుంది. నేమ్‌స్పేస్‌కు యాక్సెస్ AD ద్వారా మంజూరు చేయబడుతుంది (మేము RBACని ఉపయోగిస్తాము). నేమ్‌స్పేస్‌లు మరియు వాటి పరిమితులు GIT రిపోజిటరీకి పుల్ రిక్వెస్ట్ ద్వారా జోడించబడతాయి, ఆపై అన్నీ ఆటోమేటిక్‌గా యాన్సిబుల్ పైప్‌లైన్ ద్వారా బయటకు వస్తాయి.
బృందానికి వనరులను కేటాయించే ఉదాహరణ:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
అభ్యర్థనలు మరియు పరిమితులు
క్యూబ్డ్" అభ్యర్థన కోసం హామీ ఇవ్వబడిన రిజర్వు వనరుల సంఖ్య పాడ్ (ఒకటి లేదా అంతకంటే ఎక్కువ డాకర్ కంటైనర్లు) క్లస్టర్‌లో. పరిమితి అనేది హామీ లేని గరిష్టం. కొంతమంది బృందం తన అన్ని అప్లికేషన్‌ల కోసం చాలా ఎక్కువ అభ్యర్థనలను ఎలా సెట్ చేసిందో మీరు తరచుగా గ్రాఫ్‌లలో చూడవచ్చు మరియు అప్లికేషన్‌ను “క్యూబ్”కి అమలు చేయడం సాధ్యం కాదు, ఎందుకంటే వారి నేమ్‌స్పేస్‌లోని అన్ని అభ్యర్థనలు ఇప్పటికే “ఖర్చు” చేయబడ్డాయి.
ఈ పరిస్థితి నుండి సరైన మార్గం ఏమిటంటే వాస్తవ వనరుల వినియోగాన్ని పరిశీలించడం మరియు అభ్యర్థించిన మొత్తం (అభ్యర్థన)తో పోల్చడం.
ఎగువన ఉన్న స్క్రీన్‌షాట్‌లలో మీరు "అభ్యర్థించిన" CPUలు థ్రెడ్‌ల వాస్తవ సంఖ్యకు సరిపోలినట్లు చూడవచ్చు మరియు పరిమితులు CPU థ్రెడ్‌ల వాస్తవ సంఖ్యను అధిగమించవచ్చు =)
ఇప్పుడు కొంత నేమ్‌స్పేస్‌ను వివరంగా చూద్దాం (నేను నేమ్‌స్పేస్ క్యూబ్-సిస్టమ్‌ని ఎంచుకున్నాను - “క్యూబ్” యొక్క భాగాల కోసం సిస్టమ్ నేమ్‌స్పేస్) మరియు అభ్యర్థించిన దానికి వాస్తవానికి ఉపయోగించిన ప్రాసెసర్ సమయం మరియు మెమరీ నిష్పత్తిని చూడండి:
వాస్తవానికి ఉపయోగించిన దానికంటే చాలా ఎక్కువ మెమరీ మరియు CPU సిస్టమ్ సేవలకు కేటాయించబడిందని స్పష్టంగా తెలుస్తుంది. కుబే-సిస్టమ్ విషయంలో, ఇది సమర్థించబడుతోంది: nginx ఇన్‌గ్రెస్ కంట్రోలర్ లేదా నోడెలోకాల్డ్‌న్స్ గరిష్టంగా CPUని తాకడం మరియు చాలా RAMని వినియోగించడం జరిగింది, కాబట్టి ఇక్కడ అటువంటి రిజర్వ్ సమర్థించబడుతోంది. అదనంగా, మేము గత 3 గంటలు చార్ట్‌లపై ఆధారపడలేము: ఎక్కువ సమయం పాటు చారిత్రక కొలమానాలను చూడటం మంచిది.
"సిఫార్సుల" వ్యవస్థ అభివృద్ధి చేయబడింది. ఉదాహరణకు, ఇక్కడ మీరు "పరిమితులు" (ఎగువ అనుమతించబడిన బార్) పెంచడం ఉత్తమం అని మీరు చూడవచ్చు, తద్వారా "థ్రోట్లింగ్" జరగదు: వనరు ఇప్పటికే కేటాయించిన సమయ స్లైస్‌లో CPU లేదా మెమరీని ఖర్చు చేసిన క్షణం మరియు అది "ఘనీభవించని" వరకు వేచి ఉంది:
మరియు వారి ఆకలిని అరికట్టాల్సిన పాడ్‌లు ఇక్కడ ఉన్నాయి:
న త్రోట్లింగ్ + వనరుల పర్యవేక్షణ, మీరు ఒకటి కంటే ఎక్కువ కథనాలను వ్రాయవచ్చు, కాబట్టి వ్యాఖ్యలలో ప్రశ్నలు అడగండి. కొన్ని మాటలలో, అటువంటి కొలమానాలను ఆటోమేట్ చేయడం చాలా కష్టమైన పని అని నేను చెప్పగలను మరియు “విండో” ఫంక్షన్‌లు మరియు “CTE” ప్రోమెథియస్ / విక్టోరియామెట్రిక్స్‌తో చాలా సమయం మరియు బ్యాలెన్సింగ్ చర్య అవసరమని నేను చెప్పగలను (ఈ నిబంధనలు దాదాపుగా ఉన్నందున కోట్‌లలో ఉన్నాయి. PromQLలో ఇలాంటివి ఏమీ లేవు మరియు మీరు భయానక ప్రశ్నలను అనేక స్క్రీన్‌ల టెక్స్ట్‌లుగా విభజించి వాటిని ఆప్టిమైజ్ చేయాలి).
ఫలితంగా, డెవలపర్‌లు క్యూబ్‌లో తమ నేమ్‌స్పేస్‌లను పర్యవేక్షించడానికి సాధనాలను కలిగి ఉన్నారు మరియు ఏయే అప్లికేషన్‌లు తమ వనరులను "కట్" చేయవచ్చో మరియు ఏ సర్వర్‌లకు రాత్రంతా మొత్తం CPU ఇవ్వవచ్చో వారు తమ కోసం తాము ఎంచుకోగలుగుతారు.
పద్ధతులు
ఇప్పుడున్న కంపెనీలో ఫ్యాషన్, మేము DevOps- మరియు SRE- అభ్యాసకుడు ఒక కంపెనీకి 1000 మైక్రోసర్వీస్‌లు, 350 మంది డెవలపర్‌లు మరియు మొత్తం మౌలిక సదుపాయాల కోసం 15 మంది నిర్వాహకులు ఉన్నప్పుడు, మీరు “ఫ్యాషన్‌గా” ఉండాలి: ఈ “బాస్‌వర్డ్‌ల” వెనుక ప్రతిదీ మరియు ప్రతి ఒక్కరినీ ఆటోమేట్ చేయాల్సిన అవసరం ఉంది మరియు నిర్వాహకులు అడ్డంకిగా ఉండకూడదు. ప్రక్రియలలో.
Opsగా, మేము సేవా ప్రతిస్పందన రేట్లు మరియు ఎర్రర్‌లకు సంబంధించిన డెవలపర్‌ల కోసం వివిధ కొలమానాలు మరియు డాష్‌బోర్డ్‌లను అందిస్తాము.
మేము అటువంటి పద్ధతులను ఉపయోగిస్తాము: , и వాటిని కలపడం ద్వారా. మేము డ్యాష్‌బోర్డ్‌ల సంఖ్యను కనిష్టీకరించడానికి ప్రయత్నిస్తాము, తద్వారా ఏ సేవ ప్రస్తుతం క్షీణిస్తోంది (ఉదాహరణకు, సెకనుకు ప్రతిస్పందన కోడ్‌లు, ప్రతిస్పందన సమయం 99వ శాతం) మరియు మొదలైనవి. సాధారణ డ్యాష్‌బోర్డ్‌లకు కొన్ని కొత్త కొలమానాలు అవసరమైన వెంటనే, మేము వెంటనే వాటిని గీయండి మరియు జోడిస్తాము.
నేను నెల రోజులుగా గ్రాఫ్‌లు గీయలేదు. ఇది బహుశా మంచి సంకేతం: దీని అర్థం చాలా "కోరికలు" ఇప్పటికే గ్రహించబడ్డాయి. వారంలో నేను కనీసం రోజుకు ఒక్కసారైనా కొత్త గ్రాఫ్ గీస్తాను.
ఫలిత ఫలితం విలువైనది ఎందుకంటే ఇప్పుడు డెవలపర్‌లు చాలా అరుదుగా నిర్వాహకుల వద్దకు "ఒక రకమైన మెట్రిక్‌ని ఎక్కడ చూడాలి" అనే ప్రశ్నలతో వెళతారు.
అమలు సర్వీస్ మెష్ కేవలం మూలలో ఉంది మరియు ప్రతి ఒక్కరికీ జీవితాన్ని మరింత సులభతరం చేస్తుంది, టూల్స్‌లోని సహోద్యోగులు ఇప్పటికే "ఆరోగ్యకరమైన వ్యక్తి యొక్క ఇస్టియో" అనే వియుక్త అమలుకు దగ్గరగా ఉన్నారు: ప్రతి HTTP(లు) అభ్యర్థన యొక్క జీవిత చక్రం పర్యవేక్షణలో కనిపిస్తుంది మరియు ఇది ఇంటర్-సర్వీస్ (మరియు మాత్రమే కాదు) పరస్పర చర్య సమయంలో "ఏ దశలో ప్రతిదీ విరిగింది" అని అర్థం చేసుకోవడం ఎల్లప్పుడూ సాధ్యమవుతుంది. DomClick హబ్ నుండి వార్తలకు సభ్యత్వం పొందండి. =)
కుబెర్నెట్స్ మౌలిక సదుపాయాల మద్దతు
చారిత్రాత్మకంగా, మేము ప్యాచ్డ్ వెర్షన్‌ని ఉపయోగిస్తాము కుబేస్ప్రే - కుబెర్నెట్‌లను అమలు చేయడం, విస్తరించడం మరియు అప్‌డేట్ చేయడంలో ముఖ్యమైన పాత్ర. ఏదో ఒక సమయంలో, నాన్-కుబేడ్మ్ ఇన్‌స్టాలేషన్‌లకు మద్దతు ప్రధాన శాఖ నుండి కత్తిరించబడింది మరియు kubeadmకి మారే ప్రక్రియ ప్రతిపాదించబడలేదు. ఫలితంగా, సౌత్‌బ్రిడ్జ్ కంపెనీ తన సొంత ఫోర్క్‌ను తయారు చేసింది (కుబేడ్మ్ మద్దతుతో మరియు క్లిష్టమైన సమస్యలకు శీఘ్ర పరిష్కారంతో).
అన్ని k8s క్లస్టర్‌లను అప్‌డేట్ చేసే ప్రక్రియ ఇలా కనిపిస్తుంది:
- పడుతుంది కుబేస్ప్రే సౌత్‌బ్రిడ్జ్ నుండి, మా థ్రెడ్, మెర్జిమ్‌తో తనిఖీ చేయండి.
- మేము అప్‌డేట్‌ను విడుదల చేస్తున్నాము ఒత్తిడి- "క్యూబ్".
- మేము ఒక సమయంలో ఒక నోడ్‌ను అప్‌డేట్ చేస్తాము (అన్సిబుల్‌లో ఇది “సీరియల్: 1”) దేవ్- "క్యూబ్".
- మేము అప్‌డేట్ చేస్తాము Prod శనివారం సాయంత్రం ఒక సమయంలో ఒక నోడ్.
భవిష్యత్తులో దీన్ని భర్తీ చేయడానికి ప్రణాళికలు ఉన్నాయి కుబేస్ప్రే వేగవంతమైన దాని కోసం మరియు వెళ్ళండి kubeadm.
మొత్తంగా మనకు మూడు "క్యూబ్స్" ఉన్నాయి: ఒత్తిడి, దేవ్ మరియు ఉత్పత్తి. మేము మరొకదాన్ని ప్రారంభించాలని ప్లాన్ చేస్తున్నాము (వేడి స్టాండ్బై) రెండవ డేటా సెంటర్‌లో ఉత్పత్తి-“క్యూబ్”. ఒత్తిడి и దేవ్ "వర్చువల్ మెషీన్లు" (ఒత్తిడి కోసం oVirt మరియు దేవ్ కోసం VMWare క్లౌడ్)లో నివసిస్తున్నారు. Prod- “క్యూబ్” “బేర్ మెటల్”పై నివసిస్తుంది: ఇవి 32 CPU థ్రెడ్‌లు, 64-128 GB మెమరీ మరియు 300 GB SSD RAID 10తో ఒకే రకమైన నోడ్లు - మొత్తం 50 వాటిలో ఉన్నాయి. మూడు "సన్నని" నోడ్లు "మాస్టర్స్" కు అంకితం చేయబడ్డాయి Prod- “క్యూబా”: 16 GB మెమరీ, 12 CPU థ్రెడ్‌లు.
విక్రయాల కోసం, మేము "బేర్ మెటల్"ని ఉపయోగించడానికి ఇష్టపడతాము మరియు అనవసరమైన పొరలను నివారించండి ఓపెన్స్టాక్: మాకు "ధ్వనించే పొరుగువారు" మరియు CPU అవసరం లేదు సమయం దొంగిలించండి. మరియు అంతర్గత ఓపెన్స్టాక్ విషయంలో పరిపాలన యొక్క సంక్లిష్టత సుమారు రెట్టింపు అవుతుంది.
CI/CD “క్యూబిక్” మరియు ఇతర ఇన్‌ఫ్రాస్ట్రక్చర్ కాంపోనెంట్‌ల కోసం మేము హెల్మ్ 3 అనే ప్రత్యేక GIT సర్వర్‌ని ఉపయోగిస్తాము (ఇది హెల్మ్ 2 నుండి చాలా బాధాకరమైన మార్పు, కానీ మేము ఎంపికలతో చాలా సంతోషంగా ఉన్నాము అణు), జెంకిన్స్, అన్సిబుల్ మరియు డాకర్. మేము ఫీచర్ బ్రాంచ్‌లను ఇష్టపడతాము మరియు ఒక రిపోజిటరీ నుండి విభిన్న వాతావరణాలకు విస్తరించడం.
తీర్మానం
ఇది సాధారణ పరంగా, ఆపరేషన్స్ ఇంజనీర్ దృష్టికోణం నుండి DomClick వద్ద DevOps ప్రక్రియ ఎలా ఉంటుంది. కథనం నేను ఊహించిన దాని కంటే తక్కువ సాంకేతికంగా మారింది: కాబట్టి, హబ్రేలో డొమ్‌క్లిక్ వార్తలను అనుసరించండి: కుబెర్నెటీస్ మరియు మరిన్నింటి గురించి మరిన్ని “హార్డ్‌కోర్” కథనాలు ఉంటాయి.
మూలం: www.habr.com