ఈ రోజు నేను అప్లికేషన్‌లను ఎలా వ్రాయాలి మరియు కుబెర్నెట్స్‌లో మీ అప్లికేషన్ బాగా పని చేయడానికి అవసరాలు ఏమిటి అనే దాని గురించి మాట్లాడాలనుకుంటున్నాను. అప్లికేషన్‌తో ఎటువంటి తలనొప్పులు ఉండవు, తద్వారా మీరు దాని చుట్టూ ఎటువంటి “క్రాచ్‌లను” కనిపెట్టాల్సిన అవసరం లేదు - మరియు ప్రతిదీ కుబెర్నెటెస్ ఉద్దేశించిన విధంగానే పని చేస్తుంది.
ఈ ఉపన్యాసం "" మీరు సాయంత్రం పాఠశాల యొక్క బహిరంగ సైద్ధాంతిక ఉపన్యాసాలను చూడవచ్చు . వీడియో కంటే వచనాన్ని ఇష్టపడే వారి కోసం, మేము ఈ కథనాన్ని సిద్ధం చేసాము.
నా పేరు పావెల్ సెలివనోవ్, ప్రస్తుతం నేను Mail.ru క్లౌడ్ సొల్యూషన్స్‌లో ప్రముఖ DevOps ఇంజనీర్‌ని, మేము క్లౌడ్‌లను తయారు చేస్తాము, మేము మేనేజ్‌మెంట్ కుబెర్నెట్‌లను తయారు చేస్తాము మరియు మొదలైనవి. నా టాస్క్‌లలో ఇప్పుడు డెవలప్‌మెంట్‌లో సహాయం, ఈ క్లౌడ్‌లను రోల్ అవుట్ చేయడం, మేము వ్రాసే అప్లికేషన్‌లను రోల్ అవుట్ చేయడం మరియు మా వినియోగదారుల కోసం మేము అందించే సాధనాలను నేరుగా అభివృద్ధి చేయడం వంటివి ఉన్నాయి.
నేను DevOps చేస్తున్నాను, నేను గత, బహుశా, మూడు సంవత్సరాలుగా అనుకుంటున్నాను. కానీ, సూత్రప్రాయంగా, నేను దాదాపు ఐదు సంవత్సరాలుగా DevOps చేసే పనిని చేస్తున్నాను. అంతకు ముందు, నేను ఎక్కువగా అడ్మిన్ విషయాల్లో పాల్గొన్నాను. నేను చాలా కాలం క్రితం కుబెర్నెట్స్‌తో కలిసి పనిచేయడం ప్రారంభించాను - నేను దానితో పనిచేయడం ప్రారంభించి దాదాపు నాలుగు సంవత్సరాలు గడిచి ఉండవచ్చు.
సాధారణంగా, నేను కుబెర్నెటీస్ వెర్షన్ 1.3 అయినప్పుడు ప్రారంభించాను, బహుశా, మరియు బహుశా 1.2 - ఇది ఇంకా ప్రారంభ దశలో ఉన్నప్పుడు. ఇప్పుడు అది శైశవదశలో లేదు - మరియు కుబెర్నెట్స్ చేయాలనుకుంటున్న ఇంజనీర్లకు మార్కెట్లో విపరీతమైన డిమాండ్ ఉందని స్పష్టంగా తెలుస్తుంది. మరియు కంపెనీలకు అలాంటి వారికి చాలా ఎక్కువ డిమాండ్ ఉంది. అందువలన, నిజానికి, ఈ ఉపన్యాసం కనిపించింది.
నేను ఏమి మాట్లాడతాను అనే ప్రణాళిక గురించి మనం మాట్లాడినట్లయితే, ఇది ఇలా కనిపిస్తుంది, బ్రాకెట్లలో ఇది వ్రాయబడింది (TL;DR) - “చాలా పొడవుగా ఉంది; చదవవద్దు". ఈ రోజు నా ప్రదర్శన అంతులేని జాబితాలను కలిగి ఉంటుంది.
వాస్తవానికి, అలాంటి ప్రెజెంటేషన్‌లను రూపొందించినప్పుడు నేను ఇష్టపడను, కానీ ఇది అలాంటి అంశం, నేను ఈ ప్రెజెంటేషన్‌ను సిద్ధం చేస్తున్నప్పుడు, ఈ సమాచారాన్ని భిన్నంగా ఎలా నిర్వహించాలో నేను నిజంగా గుర్తించలేదు.
ఎందుకంటే, మొత్తంగా, ఈ సమాచారం “ctrl+c, ctrl+v”, ఇతర విషయాలతోపాటు, DevOps విభాగంలోని మా వికీ, ఇక్కడ డెవలపర్‌ల కోసం మేము వ్రాతపూర్వక అవసరాలను కలిగి ఉన్నాము: “అబ్బాయిలు, మేము మీ అప్లికేషన్‌ను దీనిలో ప్రారంభించాము కుబెర్నెట్స్, ఇది ఇలా ఉండాలి."
అందుకే ప్రెజెంటేషన్ పెద్ద జాబితాగా మారింది. క్షమించండి. వీలైతే బోర్ కొట్టకుండా వీలైనంత వరకు చెప్పే ప్రయత్నం చేస్తాను.
మనం ఇప్పుడు ఏమి చూడబోతున్నాం:
- ఇవి మొదటగా, లాగ్‌లు (అప్లికేషన్ లాగ్‌లు?), కుబెర్నెట్స్‌లో వాటితో ఏమి చేయాలి, వాటితో ఏమి చేయాలి, అవి ఎలా ఉండాలి;
- కుబెర్నెట్స్‌లోని కాన్ఫిగరేషన్‌లతో ఏమి చేయాలి, కుబెర్నెట్స్ కోసం అప్లికేషన్‌ను కాన్ఫిగర్ చేయడానికి ఉత్తమమైన మరియు చెత్త మార్గాలు ఏమిటి;
- యాక్సెసిబిలిటీ చెక్‌లు సాధారణంగా ఏవి, అవి ఎలా ఉండాలి అనే దాని గురించి మాట్లాడుదాం;
- మనోహరమైన షట్‌డౌన్ అంటే ఏమిటో మాట్లాడుకుందాం;
- వనరుల గురించి మళ్ళీ మాట్లాడుకుందాం;
- డేటా స్టోరేజ్ అంశాన్ని మరోసారి టచ్ చేద్దాం;
- మరియు ముగింపులో ఈ రహస్యమైన క్లౌడ్-నేటివ్ అప్లికేషన్ అనే పదం ఏమిటో నేను మీకు చెప్తాను. క్లౌడ్నేటివ్నెస్, ఈ పదానికి విశేషణంగా.
లాగ్‌లు
లాగ్‌లతో ప్రారంభించాలని నేను సూచిస్తున్నాను - ఈ లాగ్‌లను కుబెర్నెట్స్‌లో ఎక్కడికి తరలించాలి. ఇప్పుడు మీరు కుబెర్నెట్స్‌లో అప్లికేషన్‌ను ప్రారంభించారు. క్లాసిక్‌ల ప్రకారం, మునుపటి అప్లికేషన్‌లు ఎల్లప్పుడూ ఫైల్‌లో ఎక్కడో లాగ్‌లను వ్రాస్తాయి. అప్లికేషన్‌ను ప్రారంభించిన డెవలపర్ హోమ్ డైరెక్టరీలోని ఫైల్‌కు తప్పు అప్లికేషన్‌లు లాగ్‌లను వ్రాసాయి. మంచి అప్లికేషన్‌లు ఎక్కడో ఉన్న ఫైల్‌కి లాగ్‌లను వ్రాసాయి /var/log.
తదనుగుణంగా, ఇంకా, మంచి అడ్మినిస్ట్రేటర్‌లు తమ ఇన్‌ఫ్రాస్ట్రక్చర్‌లలో ఈ లాగ్‌లను తిప్పగలిగేలా కాన్ఫిగర్ చేసారు - అదే rsyslog, ఈ లాగ్‌లను చూస్తుంది మరియు వాటికి ఏదైనా జరిగినప్పుడు, వాటిలో చాలా ఉన్నాయి, ఇది బ్యాకప్ కాపీలను సృష్టిస్తుంది , లాగ్‌లను అక్కడ ఉంచుతుంది. , పాత ఫైల్‌లను తొలగిస్తుంది, ఒక వారం, ఆరు నెలలు మరియు మరికొన్ని. సిద్ధాంతంలో, అప్లికేషన్ లాగ్‌లను వ్రాసినందున, ఉత్పత్తి సర్వర్‌లలోని ఖాళీ (పోరాట సర్వర్లు?) అయిపోకుండా ఉండేలా మేము నిబంధనలను కలిగి ఉండాలి. మరియు, తదనుగుణంగా, లాగ్ల కారణంగా మొత్తం ఉత్పత్తి ఆగిపోలేదు.
మేము కుబెర్నెటెస్ ప్రపంచానికి వెళ్లి, అక్కడ అదే పనిని అమలు చేసినప్పుడు, మీరు దృష్టి పెట్టవలసిన మొదటి విషయం ఏమిటంటే, వ్యక్తులు ఫైల్‌లో లాగ్‌లను వ్రాసినట్లుగా, వాటిని వ్రాయడం కొనసాగిస్తారు.
మేము Kubernetes గురించి మాట్లాడినట్లయితే, డాకర్ కంటైనర్ నుండి ఎక్కడో లాగ్‌లను వ్రాయడానికి సరైన స్థలం వాటిని అప్లికేషన్ నుండి Stdout/Stderr అని పిలవబడే వాటికి వ్రాయడం, అంటే ఆపరేటింగ్ సిస్టమ్ యొక్క ప్రామాణిక అవుట్‌పుట్ స్ట్రీమ్‌లు, ప్రామాణిక లోపం అవుట్‌పుట్. డాకర్‌లో మరియు ప్రత్యేకంగా కుబెర్నెటిస్‌లో సూత్రప్రాయంగా లాగ్‌లను ఉంచడానికి ఇది చాలా సరైన, సరళమైన మరియు అత్యంత తార్కిక మార్గం. ఎందుకంటే మీ అప్లికేషన్ Stdout/Stderrకి లాగ్‌లను వ్రాస్తే, ఈ లాగ్‌లను ఏమి చేయాలో నిర్ణయించుకోవాల్సిన బాధ్యత డాకర్ మరియు కుబెర్నెట్స్ యాడ్-ఆన్‌లదే. డాకర్ డిఫాల్ట్‌గా తన ప్రత్యేక ఫైల్‌లను JSON ఫార్మాట్‌లో నిర్మిస్తుంది.
ఇక్కడ ప్రశ్న తలెత్తుతుంది, ఈ లాగ్‌లతో మీరు తర్వాత ఏమి చేస్తారు? సులభమయిన మార్గం స్పష్టంగా ఉంది, మనకు చేయగల సామర్థ్యం ఉంది kubectl logs మరియు ఈ "పాడ్స్" యొక్క ఈ లాగ్‌లను చూడండి. కానీ, బహుశా, ఇది చాలా మంచి ఎంపిక కాదు - లాగ్‌లతో వేరే ఏదైనా చేయవలసి ఉంటుంది.
ప్రస్తుతానికి, మేము లాగ్ల అంశంపై తాకినందున, లాగ్‌లు ఎలా ఉండాలో అదే సమయంలో మాట్లాడుదాం. అంటే, ఇది నేరుగా కుబెర్నెటీస్‌కు వర్తించదు, కానీ మనం లాగ్‌లను ఏమి చేయాలో ఆలోచించడం ప్రారంభించినప్పుడు, దీని గురించి కూడా ఆలోచించడం మంచిది.
మన డాకర్ తన ఫైల్‌లలో ఉంచే ఈ లాగ్‌లను తీసుకుని, వాటిని ఎక్కడికైనా పంపే ఒక రకమైన సాధనం మాకు అవసరం. పెద్దగా, మేము సాధారణంగా Kubernetes లోపల ఒక రకమైన ఏజెంట్‌ను డెమోన్‌సెట్ రూపంలో ప్రారంభిస్తాము - లాగ్ కలెక్టర్, ఇది డాకర్ సేకరించే లాగ్‌లు ఎక్కడ ఉన్నాయో చెప్పబడుతుంది. మరియు ఈ కలెక్టింగ్ ఏజెంట్ వాటిని తీసుకెళ్తాడు, బహుశా వాటిని ఏదో ఒకవిధంగా అన్వయించవచ్చు, బహుశా కొన్ని అదనపు మెటా-సమాచారంతో వాటిని మెరుగుపరుస్తుంది మరియు చివరికి, వాటిని ఎక్కడికో నిల్వ కోసం పంపుతుంది. అక్కడ వైవిధ్యాలు ఇప్పటికే సాధ్యమే. అత్యంత సాధారణమైనది బహుశా సాగే శోధన, ఇక్కడ మీరు లాగ్‌లను నిల్వ చేయవచ్చు మరియు మీరు వాటిని అక్కడ నుండి సౌకర్యవంతంగా తిరిగి పొందవచ్చు. అప్పుడు, అభ్యర్థనను ఉపయోగించి, కిబానాను ఉపయోగించి, ఉదాహరణకు, వాటి ఆధారంగా గ్రాఫ్‌లను రూపొందించండి, వాటి ఆధారంగా హెచ్చరికలను రూపొందించండి మరియు మొదలైనవి.
చాలా ముఖ్యమైన ఆలోచన, నేను దీన్ని మళ్లీ పునరావృతం చేయాలనుకుంటున్నాను, డాకర్ లోపల, ప్రత్యేకించి కుబెర్నెట్స్ లోపల, మీ లాగ్‌లను ఫైల్‌లో నిల్వ చేయడం చాలా చెడ్డ ఆలోచన.
ఎందుకంటే ముందుగా, కంటైనర్‌లోని లాగ్‌లను ఫైల్‌లో పొందడం కష్టం. మీరు మొదట కంటైనర్‌లోకి వెళ్లి, అక్కడ ఎగ్జిక్యూట్ చేసి, ఆపై లాగ్‌లను చూడాలి. తదుపరి విషయం ఏమిటంటే, మీరు ఫైల్‌లో లాగ్‌లను కలిగి ఉంటే, అప్పుడు కంటైనర్‌లు సాధారణంగా కొద్దిపాటి వాతావరణాన్ని కలిగి ఉంటాయి మరియు లాగ్‌లతో సాధారణ పని కోసం సాధారణంగా అవసరమైన యుటిలిటీలు లేవు. వాటిని పాతిపెట్టండి, వాటిని చూడండి, వాటిని టెక్స్ట్ ఎడిటర్‌లో తెరవండి. మరుసటి క్షణం, మనకు కంటైనర్ లోపల ఫైల్‌లో లాగ్‌లు ఉన్నప్పుడు, ఈ కంటైనర్ తొలగించబడితే, దానితో పాటు లాగ్‌లు చనిపోతాయని మీకు అర్థమైంది. దీని ప్రకారం, కంటైనర్ యొక్క ఏదైనా పునఃప్రారంభం అంటే ఎక్కువ లాగ్‌లు లేవు. మళ్ళీ, చెడు ఎంపిక.
మరియు చివరి విషయం ఏమిటంటే, కంటైనర్ల లోపల మీరు సాధారణంగా మీ అప్లికేషన్‌ను కలిగి ఉంటారు మరియు అంతే - ఇది సాధారణంగా నడుస్తున్న ఏకైక ప్రక్రియ. మీ లాగ్‌లతో ఫైల్‌లను రొటేట్ చేసే ఏ ప్రక్రియ గురించి మాట్లాడటం లేదు. లాగ్‌లు ఫైల్‌కి వ్రాయడం ప్రారంభించిన వెంటనే, నన్ను క్షమించండి, మేము ప్రొడక్షన్ సర్వర్‌ను కోల్పోవడం ప్రారంభిస్తాము. ఎందుకంటే, మొదట, వాటిని కనుగొనడం కష్టం, ఎవరూ వాటిని ట్రాక్ చేయరు, అలాగే ఎవరూ వాటిని నియంత్రించరు - తదనుగుణంగా, సర్వర్‌లోని ఖాళీ ఖాళీ అయ్యే వరకు ఫైల్ అనంతంగా పెరుగుతుంది. అందువల్ల, డాకర్‌లో, ముఖ్యంగా కుబెర్నెట్స్‌లో, ఫైల్‌కి లాగిన్ చేయడం చెడ్డ ఆలోచన అని నేను మళ్ళీ చెప్తున్నాను.
తదుపరి అంశం, ఇక్కడ నేను దీని గురించి మళ్లీ మాట్లాడాలనుకుంటున్నాను - మేము లాగ్ల అంశంపై తాకడం వలన, లాగ్‌లు వాటితో పని చేయడం సౌకర్యవంతంగా ఉండటానికి ఎలా కనిపించాలి అనే దాని గురించి మాట్లాడటం మంచిది. నేను చెప్పినట్లుగా, అంశం నేరుగా కుబెర్నెట్‌లకు సంబంధించినది కాదు, కానీ ఇది DevOps అంశానికి చాలా బాగా సంబంధించినది. డెవలప్‌మెంట్ కల్చర్ మరియు ఈ రెండు విభిన్న విభాగాల మధ్య స్నేహం అనే అంశంపై - Dev మరియు Ops, అందరూ సౌకర్యవంతంగా ఉంటారు.
దీనర్థం ఆదర్శవంతంగా, నేడు, లాగ్‌లు JSON ఆకృతిలో వ్రాయబడాలి. మీరు మీ స్వంత అపారమయిన అప్లికేషన్‌ను కలిగి ఉంటే, మీరు ఒక రకమైన ప్రింట్ లేదా అలాంటిదేని చొప్పించినందున అపారమయిన ఫార్మాట్‌లలో లాగ్‌లను వ్రాస్తారు, అప్పుడు సాధారణ లాగింగ్‌ను అమలు చేయడానికి మిమ్మల్ని అనుమతించే ఒక రకమైన ఫ్రేమ్‌వర్క్, ఒక రకమైన రేపర్‌ను గూగుల్ చేయడానికి ఇది సమయం; JSONలో లాగింగ్ పారామితులను అక్కడ ప్రారంభించండి, ఎందుకంటే JSON ఒక సాధారణ ఆకృతి, దానిని అన్వయించడం సులభం.
మీ JSON కొన్ని ప్రమాణాల ప్రకారం పని చేయకపోతే, ఎవరికీ ఏమి తెలియదు, కనీసం పార్స్ చేయగల ఫార్మాట్‌లో లాగ్‌లను వ్రాయండి. ఇక్కడ, బదులుగా, మీరు చాలా కంటైనర్‌లను నడుపుతున్నట్లయితే లేదా nginxతో ప్రాసెస్ చేస్తుంటే మరియు ప్రతి దాని స్వంత లాగింగ్ సెట్టింగ్‌లను కలిగి ఉంటే, అది మీకు చాలా అసౌకర్యంగా ఉంటుంది అనే వాస్తవం గురించి ఆలోచించడం విలువైనదే. వాటిని అన్వయించండి. ఎందుకంటే ప్రతి కొత్త nginx ఉదాహరణకి మీరు మీ స్వంత పార్సర్‌ని వ్రాయవలసి ఉంటుంది, ఎందుకంటే అవి లాగ్‌లను విభిన్నంగా వ్రాస్తాయి. మళ్ళీ, ఈ nginx ఉదంతాలు ఒకే లాగింగ్ కాన్ఫిగరేషన్‌ను కలిగి ఉన్నాయని మరియు వాటి లాగ్‌లన్నింటినీ పూర్తిగా ఏకరీతిగా వ్రాసినట్లు నిర్ధారించుకోవడం గురించి ఆలోచించడం విలువైనదే. ఇది ఖచ్చితంగా అన్ని అప్లికేషన్‌లకు వర్తిస్తుంది.
చివరికి, నేను అగ్నికి ఇంధనాన్ని జోడించాలనుకుంటున్నాను, ఆదర్శంగా, బహుళ-లైన్ ఫార్మాట్ లాగ్‌లను నివారించాలి. ఇక్కడ విషయం ఏమిటంటే, మీరు ఎప్పుడైనా లాగ్ కలెక్టర్‌లతో పని చేసి ఉంటే, వారు మీకు ఏమి వాగ్దానం చేస్తారో మీరు చూసారు, వారు బహుళ-లైన్ లాగ్‌లతో పని చేయగలరు, వాటిని ఎలా సేకరించాలో తెలుసుకోవడం మరియు మొదలైనవి. నిజానికి, నా అభిప్రాయం ప్రకారం, ఈ రోజు ఒక్క కలెక్టర్ కూడా బహుళ-లైన్ లాగ్‌లను సాధారణంగా, పూర్తిగా మరియు లోపాలు లేకుండా సేకరించలేరు. మానవ మార్గంలో, ఇది సౌకర్యవంతంగా మరియు దోష రహితంగా ఉంటుంది.
కానీ స్టాక్ ట్రేస్ ఎల్లప్పుడూ బహుళ-లైన్ లాగ్‌లు మరియు వాటిని ఎలా నివారించాలి. ఇక్కడ ప్రశ్న ఏమిటంటే, లాగ్ అనేది ఈవెంట్ యొక్క రికార్డ్, మరియు స్టాక్ట్రేస్ వాస్తవానికి లాగ్ కాదు. మేము లాగ్‌లను సేకరించి, వాటిని ఎలాస్టిక్‌సెర్చ్‌లో ఎక్కడైనా ఉంచి, ఆపై వాటి నుండి గ్రాఫ్‌లను గీస్తే, మీ సైట్‌లో యూజర్ యాక్టివిటీకి సంబంధించిన కొన్ని రిపోర్ట్‌లను రూపొందించినట్లయితే, మీరు స్టాక్ ట్రేస్‌ను పొందినప్పుడు, మీ అప్లికేషన్‌లో ఏదో ఊహించని పరిస్థితి ఏర్పడిందని అర్థం. మరియు వాటిని ట్రాక్ చేయగల సిస్టమ్‌లోకి ఎక్కడో స్టాక్ ట్రేస్‌ను స్వయంచాలకంగా అప్‌లోడ్ చేయడం అర్ధమే.
ఇది స్టాక్ ట్రేస్‌తో పని చేయడానికి ప్రత్యేకంగా రూపొందించబడిన సాఫ్ట్‌వేర్ (అదే సెంట్రీ). ఇది వెంటనే ఆటోమేటెడ్ టాస్క్‌లను సృష్టించగలదు, వాటిని ఎవరికైనా కేటాయించవచ్చు, స్టాక్ట్‌ట్రేస్‌లు సంభవించినప్పుడు అప్రమత్తం చేయవచ్చు, ఈ స్టాక్ట్‌ట్రేస్‌లను ఒక రకం ద్వారా సమూహపరచవచ్చు మరియు మొదలైనవి. సూత్రప్రాయంగా, మేము లాగ్ల గురించి మాట్లాడేటప్పుడు స్టాక్ట్రేసెస్ గురించి మాట్లాడటం చాలా అర్ధవంతం కాదు, ఎందుకంటే ఇవి అన్ని తరువాత, విభిన్న ప్రయోజనాలతో విభిన్న విషయాలు.
ఆకృతీకరణ
మేము Kubernetes లో కాన్ఫిగరేషన్ గురించి మాట్లాడతాము: దానితో ఏమి చేయాలి మరియు Kubernetes లోపల అప్లికేషన్‌లను ఎలా కాన్ఫిగర్ చేయాలి. సాధారణంగా, డాకర్ అనేది కంటైనర్ల గురించి కాదని నేను సాధారణంగా చెబుతాను. డాకర్ అనేది కంటైనర్ల గురించి అందరికీ తెలుసు, డాకర్‌తో పెద్దగా పని చేయని వారికి కూడా. నేను పునరావృతం చేస్తున్నాను, డాకర్ అనేది కంటైనర్ల గురించి కాదు.
డాకర్, నా అభిప్రాయం ప్రకారం, ప్రమాణాల గురించి. మరియు ఆచరణాత్మకంగా ప్రతిదానికీ ప్రమాణాలు ఉన్నాయి: మీ అప్లికేషన్‌ను రూపొందించడానికి ప్రమాణాలు, మీ అప్లికేషన్‌ను ఇన్‌స్టాల్ చేయడానికి ప్రమాణాలు.
మరియు ఈ విషయం - మేము దీన్ని ఇంతకు ముందు ఉపయోగించాము, ఇది కంటైనర్ల ఆగమనంతో బాగా ప్రాచుర్యం పొందింది - ఈ విషయాన్ని ENV (పర్యావరణ) వేరియబుల్స్ అని పిలుస్తారు, అంటే మీ ఆపరేటింగ్ సిస్టమ్‌లోని ఎన్విరాన్మెంట్ వేరియబుల్స్. ఇది సాధారణంగా మీ అప్లికేషన్‌ను కాన్ఫిగర్ చేయడానికి అనువైన మార్గం, ఎందుకంటే మీకు JAVA, Python, Go, Perl, God forbidలో అప్లికేషన్‌లు ఉంటే మరియు అవన్నీ డేటాబేస్ హోస్ట్, డేటాబేస్ యూజర్, డేటాబేస్ పాస్‌వర్డ్ వేరియబుల్స్‌ను చదవగలవు, అప్పుడు ఇది అనువైనది. మీరు అదే విధంగా డేటాబేస్ ప్లాన్‌లో కాన్ఫిగర్ చేయబడిన నాలుగు వేర్వేరు భాషలలో అప్లికేషన్‌లను కలిగి ఉన్నారు. విభిన్న కాన్ఫిగరేషన్‌లు ఏవీ లేవు.
ENV వేరియబుల్స్ ఉపయోగించి ప్రతిదీ కాన్ఫిగర్ చేయవచ్చు. మేము Kubernetes గురించి మాట్లాడేటప్పుడు, ENV వేరియబుల్‌లను డిప్లాయ్‌మెంట్‌లోనే డిక్లేర్ చేయడానికి ఒక గొప్ప మార్గం ఉంది. దీని ప్రకారం, మేము రహస్య డేటా గురించి మాట్లాడుతున్నట్లయితే, మేము వెంటనే ENV వేరియబుల్స్ (డేటాబేస్‌లకు పాస్‌వర్డ్‌లు మొదలైనవి) నుండి రహస్య డేటాను రహస్యంగా నెట్టవచ్చు, రహస్య క్లస్టర్‌ను సృష్టించి, మేము నేరుగా ప్రకటించడం లేదని డిప్లాయ్‌మెంట్‌లోని ENV వివరణలో సూచించవచ్చు. ఈ వేరియబుల్ విలువ మరియు ఈ డేటాబేస్ పాస్‌వర్డ్ వేరియబుల్ విలువ రహస్యం నుండి చదవబడుతుంది. ఇది ప్రామాణిక కుబెర్నెట్స్ ప్రవర్తన. మరియు మీ అప్లికేషన్‌లను కాన్ఫిగర్ చేయడానికి ఇది అత్యంత ఆదర్శవంతమైన ఎంపిక. కోడ్ స్థాయిలో, మళ్లీ ఇది డెవలపర్‌లకు వర్తిస్తుంది. మీరు DevOps అయితే, మీరు ఇలా అడగవచ్చు: “గైస్, దయచేసి ఎన్విరాన్మెంట్ వేరియబుల్స్‌ని చదవడానికి మీ అప్లికేషన్‌కు నేర్పండి. మరియు మనమందరం సంతోషంగా ఉంటాము. ”
కంపెనీలోని ప్రతి ఒక్కరూ అదే పేరున్న ఎన్విరాన్మెంట్ వేరియబుల్స్ చదివితే, అది చాలా బాగుంది. కొంతమంది పోస్ట్‌గ్రెస్ డేటాబేస్ కోసం ఎదురు చూస్తున్నారు, మరికొందరు డేటాబేస్ పేరు కోసం ఎదురు చూస్తున్నారు, మరికొందరు వేరే వాటి కోసం ఎదురు చూస్తున్నారు, మరికొందరు ఏదో ఒక రకమైన dbn కోసం ఎదురు చూస్తున్నారు, తద్వారా, తదనుగుణంగా, ఏకరూపత ఉంది.
మీకు చాలా ఎన్విరాన్మెంట్ వేరియబుల్స్ ఉన్నప్పుడు సమస్య వస్తుంది, మీరు డిప్లాయ్‌మెంట్‌ని తెరిచారు - మరియు ఎన్విరాన్మెంట్ వేరియబుల్స్‌లో ఐదు వందల లైన్లు ఉన్నాయి. ఈ సందర్భంలో, మీరు కేవలం పెరిగిన పర్యావరణ వేరియబుల్‌లను కలిగి ఉన్నారు - మరియు మీరు ఇకపై మిమ్మల్ని మీరు హింసించాల్సిన అవసరం లేదు. ఈ సందర్భంలో, కాన్ఫిగర్‌లను ఉపయోగించడం ప్రారంభించడం అర్ధమే. అంటే, కాన్ఫిగరేషన్‌లను ఉపయోగించడానికి మీ అప్లికేషన్‌కు శిక్షణ ఇవ్వండి.
ఒకే ప్రశ్న ఏమిటంటే, కాన్ఫిగరేషన్‌లు మీరు అనుకున్నవి కావు. Config.pi అనేది ఉపయోగించడానికి అనుకూలమైన కాన్ఫిగర్ కాదు. లేదా మీ స్వంత ఫార్మాట్‌లో కొన్ని కాన్ఫిగర్‌లు, ప్రత్యామ్నాయంగా బహుమతిగా ఇవ్వబడ్డాయి - ఇది కూడా నా ఉద్దేశ్యం కాదు.
నేను మాట్లాడుతున్నది ఆమోదయోగ్యమైన ఫార్మాట్‌లలోని కాన్ఫిగరేషన్ గురించి, అంటే ఇప్పటివరకు అత్యంత ప్రజాదరణ పొందిన ప్రమాణం .yaml ప్రమాణం. దీన్ని ఎలా చదవాలో స్పష్టంగా ఉంది, ఇది మానవులకు చదవదగినది, అప్లికేషన్ నుండి ఎలా చదవాలో స్పష్టంగా ఉంది.
తదనుగుణంగా, YAMLతో పాటు, మీరు కూడా, ఉదాహరణకు, JSONని కూడా ఉపయోగించవచ్చు, అక్కడ నుండి అప్లికేషన్ కాన్ఫిగరేషన్‌ను చదవడానికి పార్సింగ్ YAML వలె సౌకర్యవంతంగా ఉంటుంది. ఇది చదవడానికి ప్రజలకు మరింత అసౌకర్యంగా ఉంది. మీరు ఫార్మాట్‌ని ప్రయత్నించవచ్చు, లా ఇనీ. ఇది మానవ దృక్కోణం నుండి చదవడానికి చాలా సౌకర్యవంతంగా ఉంటుంది, కానీ మీరు ఎప్పుడైనా మీ స్వంత కాన్ఫిగరేషన్‌లను రూపొందించాలనుకుంటే, ini ఫార్మాట్ ఇప్పటికే రూపొందించడానికి అసౌకర్యంగా ఉండవచ్చు అనే కోణంలో దీన్ని స్వయంచాలకంగా ప్రాసెస్ చేయడం అసౌకర్యంగా ఉండవచ్చు.
ఏ సందర్భంలోనైనా, మీరు ఎంచుకున్న ఫార్మాట్ ఏమైనప్పటికీ, కుబెర్నెట్స్ కోణం నుండి ఇది చాలా సౌకర్యవంతంగా ఉంటుంది. మీరు మీ మొత్తం కాన్ఫిగరేషన్‌ను కుబెర్నెట్స్ లోపల, కాన్ఫిగ్ మ్యాప్‌లో ఉంచవచ్చు. ఆపై ఈ కాన్ఫిగ్‌మ్యాప్‌ని తీసుకుని, దానిని మీ పాడ్‌లో కొన్ని నిర్దిష్ట డైరెక్టరీలో మౌంట్ చేయమని అడగండి, ఇక్కడ మీ అప్లికేషన్ ఈ కాన్ఫిగరేషన్ నుండి కాన్ఫిగరేషన్‌ను కేవలం ఫైల్ లాగా చదువుతుంది. వాస్తవానికి, మీ అప్లికేషన్‌లో మీకు చాలా కాన్ఫిగరేషన్ ఎంపికలు ఉన్నప్పుడు చేయడం మంచిది. లేదా ఇది కేవలం ఒక రకమైన సంక్లిష్ట నిర్మాణం, గూడు ఉంది.
మీకు కాన్ఫిగ్‌మ్యాప్ ఉంటే, మీరు మీ అప్లికేషన్‌ను బాగా బోధించవచ్చు, ఉదాహరణకు, కాన్ఫిగ్‌మ్యాప్ మౌంట్ చేయబడిన ఫైల్‌లో మార్పులను స్వయంచాలకంగా ట్రాక్ చేయడం మరియు కాన్ఫిగర్‌లు మారినప్పుడు మీ అప్లికేషన్‌ను స్వయంచాలకంగా రీలోడ్ చేయడం. ఇది సాధారణంగా ఆదర్శవంతమైన ఎంపికగా ఉంటుంది.
మళ్ళీ, నేను ఇప్పటికే దీని గురించి మాట్లాడాను - రహస్య సమాచారం కాన్ఫిగమ్‌లో లేదు, రహస్య సమాచారం వేరియబుల్స్‌లో లేదు, రహస్య సమాచారం రహస్యాలలో లేదు. అక్కడ నుండి, ఈ రహస్య సమాచారాన్ని దౌత్యానికి కనెక్ట్ చేయండి. సాధారణంగా మేము Kubernetes వస్తువులు, విస్తరణలు, కాన్ఫిగమ్‌లు, సేవల యొక్క అన్ని వివరణలను gitలో నిల్వ చేస్తాము. దీని ప్రకారం, మీరు కంపెనీలో అంతర్గతంగా కలిగి ఉన్న మీ git అయినప్పటికీ, డేటాబేస్‌కు పాస్‌వర్డ్‌ను git లో ఉంచడం చెడ్డ ఆలోచన. ఎందుకంటే, కనీసం, git ప్రతిదీ గుర్తుంచుకుంటుంది మరియు అక్కడ నుండి పాస్‌వర్డ్‌లను తీసివేయడం అంత సులభం కాదు.
ఆరోగ్య పరీక్ష
తదుపరి అంశం ఆరోగ్య తనిఖీ అనే విషయం. సాధారణంగా, ఆరోగ్య తనిఖీ అనేది మీ అప్లికేషన్ పని చేస్తుందో లేదో తనిఖీ చేస్తుంది. అదే సమయంలో, మేము చాలా తరచుగా కొన్ని వెబ్ అప్లికేషన్ల గురించి మాట్లాడుతున్నాము, దీని కోసం, ఆరోగ్య తనిఖీ కోణం నుండి (ఇక్కడ మరియు మరింతగా అనువదించకపోవడమే మంచిది) ఇది కొన్ని ప్రత్యేక URL అవుతుంది, వీటిని వారు ప్రాసెస్ చేస్తారు ఒక ప్రమాణం, వారు సాధారణంగా చేస్తారు /health.
ఈ URLని యాక్సెస్ చేస్తున్నప్పుడు, తదనుగుణంగా, మా అప్లికేషన్ “అవును, సరే, నాతో అంతా బాగానే ఉంది, 200” లేదా “లేదు, నాకు అంతా బాగాలేదు, దాదాపు 500” అని చెబుతుంది. దీని ప్రకారం, మా అప్లికేషన్ http కానట్లయితే, వెబ్ అప్లికేషన్ కాదు, మేము ఇప్పుడు ఒక రకమైన డెమోన్ గురించి మాట్లాడుతున్నాము, ఆరోగ్య తనిఖీలు ఎలా చేయాలో మనం గుర్తించవచ్చు. అంటే, ఇది అవసరం లేదు, అప్లికేషన్ http కాకపోతే, ఆరోగ్య తనిఖీ లేకుండా ప్రతిదీ పని చేస్తుంది మరియు ఇది ఏ విధంగానూ చేయలేము. మీరు ఫైల్‌లోని కొంత సమాచారాన్ని కాలానుగుణంగా అప్‌డేట్ చేయవచ్చు, మీరు మీ డెమోన్ కోసం కొన్ని ప్రత్యేక కమాండ్‌తో రావచ్చు, daemon status, ఇది "అవును, అంతా బాగానే ఉంది, డెమోన్ పని చేస్తోంది, అది సజీవంగా ఉంది" అని చెబుతుంది.
అది దేనికోసం? మొదటి మరియు అత్యంత స్పష్టమైన విషయం ఏమిటంటే, ఆరోగ్య తనిఖీ ఎందుకు అవసరమో - అప్లికేషన్ పని చేస్తుందని అర్థం చేసుకోవడానికి. నా ఉద్దేశ్యం, ఇది కేవలం తెలివితక్కువదని, ఇప్పుడు పైకి వచ్చినప్పుడు, ఇది పని చేస్తున్నట్లుగా కనిపిస్తుంది, కాబట్టి ఇది పని చేస్తుందని మీరు ఖచ్చితంగా అనుకోవచ్చు. మరియు అప్లికేషన్ రన్ అవుతోంది, కంటైనర్ రన్ అవుతోంది, ఉదాహరణ పనిచేస్తోంది, ప్రతిదీ బాగానే ఉంది - ఆపై వినియోగదారులు ఇప్పటికే సాంకేతిక మద్దతు నుండి అన్ని ఫోన్ నంబర్‌లను కత్తిరించారు మరియు “మీరు ఏమిటి..., మీరు నిద్రపోయింది, ఏమీ పని చేయడం లేదు.
ఆరోగ్య తనిఖీ అనేది వినియోగదారు దృక్కోణం నుండి అది పని చేస్తుందని చూడటానికి ఒక మార్గం. పద్ధతుల్లో ఒకటి. దానిని ఇలా వుంచుకుందాం. కుబెర్నెటెస్ దృక్కోణం నుండి, అప్లికేషన్ ఎప్పుడు ప్రారంభమవుతుందో అర్థం చేసుకోవడానికి ఇది ఒక మార్గం, ఎందుకంటే కంటైనర్ ఎప్పుడు ప్రారంభించబడింది, సృష్టించబడింది మరియు ప్రారంభించబడింది మరియు అప్లికేషన్ నేరుగా ఈ కంటైనర్‌లో ప్రారంభించబడినప్పుడు మధ్య వ్యత్యాసం ఉందని మేము అర్థం చేసుకున్నాము. ఎందుకంటే మనం కొంత సగటు జావా అప్లికేషన్‌ని తీసుకొని దానిని డాక్‌లో లాంచ్ చేయడానికి ప్రయత్నిస్తే, నలభై సెకన్లు, లేదా ఒక నిమిషం లేదా పది వరకు, అది బాగానే ప్రారంభమవుతుంది. ఈ సందర్భంలో, మీరు కనీసం దాని పోర్ట్‌లపై తట్టవచ్చు, అది అక్కడ సమాధానం ఇవ్వదు, అంటే, ఇది ట్రాఫిక్‌ను స్వీకరించడానికి ఇంకా సిద్ధంగా లేదు.
మళ్ళీ, ఆరోగ్య తనిఖీ సహాయంతో మరియు మేము ఇక్కడ తిరుగుతున్నాము అనే వాస్తవం సహాయంతో, అప్లికేషన్‌లో కంటైనర్ మాత్రమే పెరగలేదని, కానీ అప్లికేషన్ కూడా ప్రారంభించబడిందని, ఇది ఇప్పటికే ప్రతిస్పందిస్తుందని కుబెర్నెట్స్‌లో అర్థం చేసుకోవచ్చు. ఆరోగ్య తనిఖీ, అంటే మేము అక్కడికి ట్రాఫిక్‌ని పంపగలము.
నేను ఇప్పుడు మాట్లాడుతున్న దాని గురించి కుబెర్నెట్స్‌లోని సంసిద్ధత/జీవన పరీక్షలు అంటారు; తదనుగుణంగా, బ్యాలెన్సింగ్‌లో అప్లికేషన్ యొక్క లభ్యతకు మా సంసిద్ధత పరీక్షలు బాధ్యత వహిస్తాయి. అంటే, అప్లికేషన్‌లో సంసిద్ధత పరీక్షలు నిర్వహించబడితే, అప్పుడు ప్రతిదీ సరే, క్లయింట్ ట్రాఫిక్ అప్లికేషన్‌కు వెళుతుంది. సంసిద్ధత పరీక్షలు నిర్వహించబడకపోతే, అప్లికేషన్ కేవలం పాల్గొనదు, ఈ ప్రత్యేక సందర్భం బ్యాలెన్సింగ్‌లో పాల్గొనదు, ఇది బ్యాలెన్సింగ్ నుండి తీసివేయబడుతుంది, క్లయింట్ ట్రాఫిక్ ప్రవహించదు. తదనుగుణంగా, కుబెర్నెటీస్‌లో లైవ్‌నెస్ పరీక్షలు అవసరం, తద్వారా అప్లికేషన్ చిక్కుకుపోయినట్లయితే, దాన్ని పునఃప్రారంభించవచ్చు. కుబెర్నెట్స్‌లో డిక్లేర్ చేయబడిన అప్లికేషన్ కోసం లైవ్‌నెస్ టెస్ట్ పని చేయకపోతే, అప్లికేషన్ బ్యాలెన్సింగ్ నుండి తీసివేయబడదు, అది మళ్లీ ప్రారంభించబడుతుంది.
మరియు ఇక్కడ నేను ప్రస్తావించదలిచిన ఒక ముఖ్యమైన విషయం ఉంది: ఆచరణాత్మక దృక్కోణం నుండి, సంసిద్ధత పరీక్ష సాధారణంగా తరచుగా ఉపయోగించబడుతుంది మరియు సజీవ పరీక్ష కంటే చాలా తరచుగా అవసరం. అంటే, కేవలం ఆలోచన లేకుండా సంసిద్ధత మరియు సజీవత పరీక్షలు రెండింటినీ ప్రకటించడం, ఎందుకంటే కుబెర్నెట్స్ అలా చేయగలడు మరియు అది చేయగలిగినదంతా ఉపయోగించుకుందాం, ఇది చాలా మంచి ఆలోచన కాదు. ఎందుకో వివరిస్తాను. ఎందుకంటే పరీక్షలో పాయింట్ నంబర్ టూ మీ ఆరోగ్య తనిఖీలలో అంతర్లీన సేవను తనిఖీ చేయడం మంచిది. దీనర్థం మీరు కొంత సమాచారాన్ని అందించే వెబ్ అప్లికేషన్‌ను కలిగి ఉంటే, అది సహజంగా ఎక్కడి నుండైనా తీసుకోవాలి. డేటాబేస్లో, ఉదాహరణకు. సరే, ఇది ఈ REST APIలోకి వచ్చే సమాచారాన్ని అదే డేటాబేస్లో సేవ్ చేస్తుంది. తదనుగుణంగా, మీ హెల్త్‌చెక్ సంప్రదించిన స్లాష్‌హెల్త్ లాగా స్పందిస్తే, అప్లికేషన్ “200, సరే, అంతా బాగానే ఉంది” అని చెబుతుంది మరియు అదే సమయంలో మీ అప్లికేషన్ డేటాబేస్ యాక్సెస్ చేయబడదు మరియు హెల్త్‌చెక్ అప్లికేషన్ “200, సరే, అంతా బాగానే ఉంది ” - ఇది చెడ్డ ఆరోగ్య తనిఖీ. ఇది ఎలా పని చేయకూడదు.
అంటే, మీ అప్లికేషన్, దానికి అభ్యర్థన వచ్చినప్పుడు /health, ఇది కేవలం ప్రతిస్పందించదు, “200, సరే”, ఇది మొదట డేటాబేస్‌కు వెళుతుంది, ఉదాహరణకు, దానికి కనెక్ట్ చేయడానికి ప్రయత్నిస్తుంది, అక్కడ చాలా ప్రాథమికంగా ఏదైనా చేస్తుంది, ఒకదాన్ని ఎంచుకోవడం వంటిది, అందులో కనెక్షన్ ఉందో లేదో తనిఖీ చేస్తుంది. డేటాబేస్ మరియు మీరు డేటాబేస్ను ప్రశ్నించవచ్చు. ఇవన్నీ విజయవంతమైతే, “200, సరే” అని సమాధానం వస్తుంది. ఇది విజయవంతం కాకపోతే, లోపం ఉందని, డేటాబేస్ అందుబాటులో లేదని చెప్పింది.
అందువల్ల, ఈ విషయంలో, నేను మళ్లీ సంసిద్ధత/జీవన పరీక్షలకు తిరిగి వస్తాను - మీకు సంసిద్ధత పరీక్ష ఎందుకు అవసరమవుతుంది, అయితే లైవ్‌నెస్ పరీక్ష ప్రశ్నార్థకంగా ఉంది. ఎందుకంటే మీరు ఆరోగ్య తనిఖీలను నేను చెప్పినట్లు సరిగ్గా వివరిస్తే, అది ఉదాహరణ భాగంలో అందుబాటులో లేదని తేలింది.в или со всех instanceడేటాబేస్లో, ఉదాహరణకు. మీరు సంసిద్ధత పరీక్షను ప్రకటించినప్పుడు, మా ఆరోగ్య తనిఖీలు విఫలమయ్యాయి మరియు తదనుగుణంగా డేటాబేస్ అందుబాటులో లేని అన్ని అప్లికేషన్‌లు బ్యాలెన్సింగ్ నుండి ఆపివేయబడతాయి మరియు వాస్తవానికి నిర్లక్ష్యం చేయబడిన స్థితిలో “హాంగ్” చేయబడతాయి మరియు వాటి డేటాబేస్ కోసం వేచి ఉండండి. పని.
మేము లైవ్‌నెస్ పరీక్షను ప్రకటించినట్లయితే, మా డేటాబేస్ విచ్ఛిన్నమైందని ఊహించుకోండి మరియు మీ కుబెర్నెట్స్‌లో సగానికి సంబంధించిన పరీక్ష విఫలమైనందున ప్రతిదీ పునఃప్రారంభించబడుతుంది. దీని అర్థం మీరు పునఃప్రారంభించవలసి ఉంటుంది. ఇది మీకు కావలసినది కాదు, ఆచరణలో నాకు వ్యక్తిగత అనుభవం కూడా ఉంది. మేము JSలో వ్రాసిన మరియు మొంగో డేటాబేస్లో ఫీడ్ చేయబడిన చాట్ అప్లికేషన్‌ని కలిగి ఉన్నాము. మరియు సమస్య ఏమిటంటే, ఇది కుబెర్నెటెస్‌తో నా పని ప్రారంభంలో ఉంది, కుబెర్నెట్స్ దీన్ని చేయగలదనే సూత్రంపై పరీక్షల సంసిద్ధత, సజీవతను మేము వివరించాము, కాబట్టి మేము దానిని ఉపయోగిస్తాము. దీని ప్రకారం, ఏదో ఒక సమయంలో మొంగో కొద్దిగా "నిస్తేజంగా" మారింది మరియు నమూనా విఫలం కావడం ప్రారంభించింది. దీని ప్రకారం, వర్షపు పరీక్ష ప్రకారం, పాడ్లు "చంపడం" ప్రారంభించాయి.
మీరు అర్థం చేసుకున్నట్లుగా, వారు "చంపబడినప్పుడు", ఇది చాట్, అంటే, క్లయింట్ల నుండి చాలా కనెక్షన్లు దానిపై వేలాడుతున్నాయి. వారు కూడా “చంపబడ్డారు” - కాదు, క్లయింట్లు కాదు, కనెక్షన్లు మాత్రమే - అన్నీ ఒకే సమయంలో కాదు, మరియు వారు ఒకే సమయంలో చంపబడకపోవడం వల్ల, కొంత ముందు, కొన్ని తరువాత, అవి ఒకే సమయంలో ప్రారంభించబడవు. సమయం. ప్లస్ స్టాండర్డ్ యాదృచ్ఛికంగా, మేము ప్రతిసారీ అప్లికేషన్ యొక్క ప్రారంభ సమయాన్ని మిల్లీసెకండ్ ఖచ్చితత్వంతో అంచనా వేయలేము, కాబట్టి వారు ఒక్కోసారి దీన్ని చేస్తారు. ఒక ఇన్ఫోస్పాట్ పెరుగుతుంది, బ్యాలెన్సింగ్‌కు జోడించబడింది, క్లయింట్లందరూ అక్కడికి వస్తారు, ఇది అలాంటి భారాన్ని తట్టుకోదు, ఎందుకంటే అది ఒంటరిగా ఉంది మరియు సుమారుగా చెప్పాలంటే, అక్కడ డజను మంది పని చేస్తున్నారు మరియు అది పడిపోతుంది. తదుపరిది పెరుగుతుంది, మొత్తం లోడ్ అతనిపై ఉంది, అతను కూడా పడిపోతాడు. బాగా, ఈ జలపాతాలు కేవలం క్యాస్కేడ్‌ను కొనసాగిస్తాయి. చివరికి, ఇది ఎలా పరిష్కరించబడింది - మేము ఈ అనువర్తనానికి వినియోగదారు ట్రాఫిక్‌ను ఖచ్చితంగా ఆపివేయాలి, అన్ని సందర్భాలు పెరగనివ్వండి మరియు ఆపై మొత్తం వినియోగదారుల ట్రాఫిక్‌ను ఒకేసారి ప్రారంభించండి, తద్వారా ఇది ఇప్పటికే మొత్తం పది సందర్భాలలో పంపిణీ చేయబడింది.
ఈ లైవ్‌నెస్ టెస్ట్ ప్రకటించబడకపోతే, ఇది అన్నింటినీ రీస్టార్ట్ చేయమని బలవంతం చేస్తుంది, అప్లికేషన్ దీన్ని చక్కగా నిర్వహించేది. కానీ బ్యాలెన్సింగ్ నుండి ప్రతిదీ మాకు నిలిపివేయబడింది, ఎందుకంటే డేటాబేస్‌లు ప్రాప్యత చేయలేవు మరియు వినియోగదారులందరూ "పడిపోయారు". అప్పుడు, ఈ డేటాబేస్ అందుబాటులోకి వచ్చినప్పుడు, ప్రతిదీ బ్యాలెన్సింగ్‌లో చేర్చబడుతుంది, అయితే అప్లికేషన్‌లు మళ్లీ ప్రారంభించాల్సిన అవసరం లేదు మరియు దీనిపై సమయం మరియు వనరులను వృథా చేయవలసిన అవసరం లేదు. వారందరూ ఇప్పటికే ఇక్కడ ఉన్నారు, వారు ట్రాఫిక్ కోసం సిద్ధంగా ఉన్నారు, కాబట్టి ట్రాఫిక్ ఇప్పుడే తెరుచుకుంటుంది, ప్రతిదీ బాగానే ఉంది - అప్లికేషన్ స్థానంలో ఉంది, ప్రతిదీ పని చేస్తూనే ఉంది.
అందువల్ల, సంసిద్ధత మరియు జీవక్రియ పరీక్షలు భిన్నంగా ఉంటాయి, అంతేకాకుండా, మీరు సిద్ధాంతపరంగా వివిధ ఆరోగ్య తనిఖీలు, ఒక రకమైన రేడియే, ఒక రకం లైవ్, ఉదాహరణకు, మరియు వివిధ విషయాలను తనిఖీ చేయవచ్చు. సంసిద్ధత పరీక్షల సమయంలో, మీ బ్యాకెండ్‌లను తనిఖీ చేయండి. మరియు లైవ్‌నెస్ టెస్ట్‌లో, ఉదాహరణకు, లైవ్‌నెస్ టెస్ట్ అనేది సాధారణంగా ప్రతిస్పందించే అప్లికేషన్ మాత్రమే అని మీరు తనిఖీ చేయరు, అది ప్రతిస్పందించగలిగితే.
ఎందుకంటే లైవ్‌నెస్ టెస్ట్, పెద్దగా, మనం “ఇరుక్కుపోయి” ఉన్నప్పుడు. అంతులేని లూప్ ప్రారంభమైంది లేదా మరేదైనా ఉంది - మరియు ఇకపై అభ్యర్థనలు ఏవీ ప్రాసెస్ చేయబడవు. అందువల్ల, వాటిని వేరు చేయడం కూడా అర్ధమే - మరియు వాటిలో విభిన్న తర్కాన్ని అమలు చేయడం.
మీకు పరీక్ష ఉన్నప్పుడు, మీరు ఆరోగ్య తనిఖీలు చేసినప్పుడు మీరు ఏమి సమాధానం చెప్పాలి. ఇది నిజంగా నొప్పి మాత్రమే. దీని గురించి తెలిసిన వారు బహుశా నవ్వుతారు - కానీ తీవ్రంగా, 200% కేసులలో “XNUMX” అని సమాధానమిచ్చే సేవలను నేను నా జీవితంలో చూశాను. అంటే, ఎవరు విజయం సాధించారు. కానీ అదే సమయంలో ప్రతిస్పందన శరీరంలో వారు "అటువంటి లోపం" అని వ్రాస్తారు.
అంటే, ప్రతిస్పందన స్థితి మీకు వస్తుంది - ప్రతిదీ విజయవంతమైంది. కానీ అదే సమయంలో, మీరు తప్పనిసరిగా శరీరాన్ని అన్వయించాలి, ఎందుకంటే శరీరం "క్షమించండి, అభ్యర్థన లోపంతో ముగిసింది" అని చెబుతుంది మరియు ఇది కేవలం వాస్తవం. ఇది నిజ జీవితంలో చూశాను.
మరియు కొంతమందికి ఇది ఫన్నీగా అనిపించదు, మరికొందరు చాలా బాధాకరమైనదిగా భావిస్తారు, ఇది ఇప్పటికీ సాధారణ నియమానికి కట్టుబడి ఉండటం విలువైనదే. ఆరోగ్య తనిఖీలలో మరియు వెబ్ అప్లికేషన్‌లతో పనిచేసేటప్పుడు సూత్రప్రాయంగా.
ప్రతిదీ సరిగ్గా జరిగితే, రెండు వందల సమాధానంతో ప్రతిస్పందించండి. సూత్రప్రాయంగా, ఏదైనా రెండు వందల సమాధానం మీకు సరిపోతుంది. మీరు రాగ్సీని బాగా చదివి, కొన్ని ప్రతిస్పందన స్థితిగతులు ఇతరులకు భిన్నంగా ఉన్నాయని తెలిస్తే, తగిన వాటితో సమాధానం ఇవ్వండి: 204, 5, 10, 15, ఏమైనా. ఇది బాగా లేకుంటే, కేవలం "రెండు సున్నా సున్నా." అంతా చెడిపోయి, హెల్త్ చెక్ రెస్పాండ్ కాకపోతే, ఏదైనా అయిదు వందలతో సమాధానం చెప్పండి. మళ్ళీ, మీరు ఎలా ప్రతిస్పందించాలో అర్థం చేసుకుంటే, విభిన్న ప్రతిస్పందన స్థితిగతులు ఒకదానికొకటి ఎలా భిన్నంగా ఉంటాయి. మీకు అర్థం కాకపోతే, ఏదైనా తప్పు జరిగితే ఆరోగ్య తనిఖీలకు ప్రతిస్పందించడానికి 502 మీ ఎంపిక.
ఇది మరొక అంశం, నేను అంతర్లీన సేవలను తనిఖీ చేయడం గురించి కొంచెం తిరిగి ఇవ్వాలనుకుంటున్నాను. మీరు ప్రారంభిస్తే, ఉదాహరణకు, మీ అప్లికేషన్ వెనుక ఉన్న అన్ని అంతర్లీన సేవలను తనిఖీ చేయడం - సాధారణంగా ప్రతిదీ. మైక్రోసర్వీస్ ఆర్కిటెక్చర్ దృక్కోణం నుండి మేము ఏమి పొందుతాము, మేము "తక్కువ కలపడం" వంటి భావనను కలిగి ఉన్నాము - అంటే, మీ సేవలు ఒకదానికొకటి తక్కువగా ఆధారపడి ఉన్నప్పుడు. వాటిలో ఒకటి విఫలమైతే, ఈ ఫంక్షనాలిటీ లేకుండా మిగతావన్నీ పని చేస్తూనే ఉంటాయి. కొన్ని ఫంక్షనాలిటీలు పని చేయవు. దీని ప్రకారం, మీరు అన్ని ఆరోగ్య తనిఖీలను ఒకదానితో ఒకటి ముడిపెట్టినట్లయితే, మీరు మౌలిక సదుపాయాలలో ఒక విషయం పడిపోతారు, మరియు అది పడిపోయినందున, అన్ని సేవల యొక్క అన్ని ఆరోగ్య తనిఖీలు కూడా విఫలమవుతాయి - మరియు సాధారణంగా మరిన్ని మౌలిక సదుపాయాలు ఉన్నాయి. మొత్తం మైక్రోసర్వీస్ ఆర్కిటెక్చర్ నం. అక్కడ అంతా చీకటి పడింది.
అందువల్ల, మీరు అంతర్లీన సేవలను తనిఖీ చేయాల్సిన అవసరం ఉందని నేను దీన్ని మళ్లీ పునరావృతం చేయాలనుకుంటున్నాను, వంద శాతం కేసులలో మీ అప్లికేషన్ దాని పనిని చేయలేనివి. అంటే, మీరు REST APIని కలిగి ఉంటే, దాని ద్వారా వినియోగదారు డేటాబేస్లో సేవ్ చేస్తే లేదా డేటాబేస్ నుండి తిరిగి పొందితే, డేటాబేస్ లేనప్పుడు, మీరు మీ వినియోగదారులతో పనికి హామీ ఇవ్వలేరు.
అయితే మీ వినియోగదారులు, మీరు వారిని డేటాబేస్ నుండి తీసివేసినప్పుడు, ఫ్రంటెండ్‌కు ప్రతిస్పందనను పంపే ముందు మీరు నమోదు చేసే మరొక బ్యాకెండ్ నుండి కొన్ని ఇతర మెటాడేటాతో అదనంగా సమృద్ధిగా ఉంటే - మరియు ఈ బ్యాకెండ్ అందుబాటులో లేదు, అంటే మీరు మీ మెటాడేటాలో ఏ భాగం లేకుండా సమాధానం ఇవ్వండి.
తరువాత, అప్లికేషన్‌లను ప్రారంభించేటప్పుడు మాకు బాధాకరమైన సమస్యలు కూడా ఉన్నాయి.
వాస్తవానికి, ఇది కుబెర్నెటీస్‌కు మాత్రమే వర్తించదు; ఒకరకమైన మాస్ డెవలప్‌మెంట్ మరియు ముఖ్యంగా DevOps సంస్కృతి కుబెర్నెట్స్ మాదిరిగానే వ్యాప్తి చెందడం ప్రారంభించింది. అందువల్ల, పెద్దగా, మీరు కుబెర్నెట్స్ లేకుండా మీ అప్లికేషన్‌ను సరసముగా మూసివేయవలసి ఉంటుంది. కుబెర్నెటెస్ కంటే ముందు కూడా, ప్రజలు దీన్ని చేసారు, కానీ కుబెర్నెట్స్ రాకతో, మేము దాని గురించి సామూహికంగా మాట్లాడటం ప్రారంభించాము.
అందమైన షట్‌డౌన్
సాధారణంగా, గ్రేస్‌ఫుల్ షట్‌డౌన్ అంటే ఏమిటి మరియు అది ఎందుకు అవసరం? ఇది మీ అప్లికేషన్ కొన్ని కారణాల వలన క్రాష్ అయినప్పుడు, మీరు చేయాల్సి ఉంటుంది app stop - లేదా మీరు ఉదాహరణకు, ఆపరేటింగ్ సిస్టమ్ నుండి సిగ్నల్‌ను స్వీకరిస్తారు, మీ అప్లికేషన్ దానిని అర్థం చేసుకోవాలి మరియు దాని గురించి ఏదైనా చేయాలి. మీ అప్లికేషన్ SIGTERMని స్వీకరించినప్పుడు మరియు "SIGTERM, లెట్స్ హ్యాంగ్ ఆన్ చేద్దాం, పని చేయండి, ఏమీ చేయవద్దు" లాగా ఉన్నప్పుడు చెత్త దృష్టాంతంలో ఉంటుంది. ఇది పూర్తిగా చెడ్డ ఎంపిక.
మీ అప్లికేషన్ ఒక SIGTERMని స్వీకరించినప్పుడు మరియు "వారు సెగ్‌టెర్మ్‌గా చెప్పారు, అంటే మనం ముగిస్తున్నాము, నేను చూడలేదు, వినియోగదారు అభ్యర్థనలు ఏవీ నాకు తెలియవు, ఏ రకమైనవి నాకు తెలియదు నేను ప్రస్తుతం పని చేస్తున్న అభ్యర్థనలు, వారు SIGTERM అన్నారు, అంటే మేము ముగిస్తున్నాము " ఇది కూడా చెడ్డ ఎంపిక.
ఏ ఎంపిక మంచిది? మొదటి విషయం ఏమిటంటే కార్యకలాపాల పూర్తిని పరిగణనలోకి తీసుకోవడం. మీ సర్వర్ ఒక SIGTERMని స్వీకరిస్తే అది ఏమి చేస్తుందో ఇప్పటికీ పరిగణనలోకి తీసుకోవడం మంచి ఎంపిక.
SIGTERM అనేది సాఫ్ట్ షట్‌డౌన్, ఇది ప్రత్యేకంగా రూపొందించబడింది, ఇది కోడ్ స్థాయిలో అంతరాయం కలిగించవచ్చు, దీన్ని ప్రాసెస్ చేయవచ్చు, ఇప్పుడు చెప్పండి, వేచి ఉండండి, మొదట మన వద్ద ఉన్న పనిని పూర్తి చేస్తాము, ఆపై మేము నిష్క్రమిస్తాము.
కుబెర్నెట్స్ దృక్కోణం నుండి, ఇది ఇలా కనిపిస్తుంది. మేము Kubernetes క్లస్టర్‌లో నడుస్తున్న పాడ్‌కి, “దయచేసి ఆపివేయండి, దూరంగా వెళ్లండి” అని చెప్పినప్పుడు లేదా మేము పునఃప్రారంభించబడ్డాము లేదా Kubernetes పాడ్‌లను పునఃసృష్టించినప్పుడు ఒక నవీకరణ సంభవించినప్పుడు, Kubernetes పాడ్‌కి అదే SIGTERM సందేశాన్ని పంపుతుంది, వేచి ఉంది కొంత సమయం, మరియు , ఇది అతను వేచి ఉండే సమయం, ఇది కూడా కాన్ఫిగర్ చేయబడింది, డిప్లొమాలలో అటువంటి ప్రత్యేక పరామితి ఉంది మరియు దానిని గ్రేస్‌ఫుల్ షట్‌డౌన్ టైమ్‌అవుట్ అంటారు. మీరు అర్థం చేసుకున్నట్లుగా, ఇది ఏమీ కోసం పిలవబడదు మరియు మేము ఇప్పుడు దాని గురించి మాట్లాడటం ఏమీ కోసం కాదు.
మేము అప్లికేషన్‌కు SIGTERMని పంపే సమయానికి మధ్య ఎంతసేపు వేచి ఉండాలో అక్కడ ప్రత్యేకంగా చెప్పగలం మరియు అప్లికేషన్ ఏదో వెర్రివాడిగా ఉన్నట్లు లేదా "ఇరుక్కుపోయిందని" మరియు అది ముగియబోతోందని మేము అర్థం చేసుకున్నప్పుడు - మరియు మనం ఇలా చేయాలి దానికి SIGKILLని పంపండి, అంటే కష్టపడి దాని పనిని పూర్తి చేయండి. అంటే, తదనుగుణంగా, మనకు ఒక రకమైన డెమోన్ రన్నింగ్ ఉంది, ఇది కార్యకలాపాలను ప్రాసెస్ చేస్తుంది. డెమోన్ పనిచేసే మా కార్యకలాపాలు సగటున 30 సెకన్ల కంటే ఎక్కువ ఉండవని మేము అర్థం చేసుకున్నాము. దీని ప్రకారం, SIGTERM వచ్చినప్పుడు, మా డెమోన్ SIGTERM తర్వాత గరిష్టంగా 30 సెకన్లు పూర్తి చేయగలదని మేము అర్థం చేసుకున్నాము. మేము దానిని వ్రాస్తాము, ఉదాహరణకు, కేవలం 45 సెకన్లు మరియు SIGTERM అని చెప్పండి. ఆ తర్వాత మేము 45 సెకన్లు వేచి ఉంటాము. సిద్ధాంతంలో, ఈ సమయంలో దెయ్యం తన పనిని పూర్తి చేసి, స్వయంగా ముగించాలి. కానీ అకస్మాత్తుగా అది కుదరకపోతే, అది చాలావరకు చిక్కుకుపోయిందని అర్థం-ఇది ఇకపై మా అభ్యర్థనలను సాధారణంగా ప్రాసెస్ చేయడం లేదు. మరియు 45 సెకన్లలో మీరు సురక్షితంగా, నిజానికి, అతనిని వ్రేలాడదీయవచ్చు.
మరియు ఇక్కడ, వాస్తవానికి, 2 అంశాలను కూడా పరిగణనలోకి తీసుకోవచ్చు. ముందుగా, మీరు అభ్యర్థనను స్వీకరించినట్లయితే, మీరు దానితో ఎలాగైనా పని చేయడం ప్రారంభించారని మరియు వినియోగదారుకు ప్రతిస్పందన ఇవ్వలేదని అర్థం చేసుకోండి, కానీ మీరు SIGTERMని స్వీకరించారు, ఉదాహరణకు. దాన్ని శుద్ధి చేసి, వినియోగదారుకు సమాధానం ఇవ్వడం సమంజసం. ఈ విషయంలో ఇదే పాయింట్ నంబర్ వన్. ఇక్కడ పాయింట్ నంబర్ టూ ఏమిటంటే, మీరు మీ స్వంత అప్లికేషన్‌ను వ్రాస్తే, సాధారణంగా మీరు మీ అప్లికేషన్ కోసం అభ్యర్థనను స్వీకరించే విధంగా ఆర్కిటెక్చర్‌ను రూపొందించండి, ఆపై మీరు కొంత పనిని ప్రారంభించండి, ఎక్కడి నుండైనా ఫైల్‌లను డౌన్‌లోడ్ చేయడం ప్రారంభించండి, డేటాబేస్ డౌన్‌లోడ్ చేయడం మరియు ఏది కాదు. - ఆ. సాధారణంగా, మీ వినియోగదారు, మీ అభ్యర్థన అరగంట పాటు వేలాడదీయబడుతుంది మరియు మీరు అతనికి సమాధానం ఇవ్వడానికి వేచి ఉంటారు - అప్పుడు, చాలా మటుకు, మీరు ఆర్కిటెక్చర్‌పై పని చేయాలి. అంటే, మీ కార్యకలాపాలు చిన్నవిగా ఉంటే, SIGTERMని విస్మరించి, దానిని సవరించడం సమంజసమే అనే ఇంగితజ్ఞానాన్ని కూడా పరిగణనలోకి తీసుకోండి. మీ కార్యకలాపాలు చాలా పొడవుగా ఉంటే, ఈ సందర్భంలో SIGTERMని విస్మరించడంలో అర్ధమే లేదు. అటువంటి సుదీర్ఘ కార్యకలాపాలను నివారించడానికి నిర్మాణాన్ని పునఃరూపకల్పన చేయడం అర్ధమే. తద్వారా వినియోగదారులు చుట్టూ తిరుగుతూ వేచి ఉండరు. నాకు తెలియదు, అక్కడ ఒక రకమైన వెబ్‌సాకెట్‌ను తయారు చేయండి, మీ సర్వర్ ఇప్పటికే క్లయింట్‌కి పంపే రివర్స్ హుక్స్‌లను తయారు చేయండి, మరేదైనా, కానీ వినియోగదారుని అరగంట పాటు హ్యాంగ్ చేయమని బలవంతం చేయవద్దు మరియు మీరు వచ్చే వరకు సెషన్ కోసం వేచి ఉండండి అతనికి సమాధానం చెప్పు. ఎందుకంటే అది ఎక్కడ విరిగిపోతుందో ఊహించలేము.
మీ అప్లికేషన్ ముగిసినప్పుడు, మీరు తగిన నిష్క్రమణ కోడ్‌ను అందించాలి. అంటే, మీ అప్లికేషన్‌ను మూసివేయమని, ఆపివేయమని అడిగితే మరియు అది సాధారణంగా ఆపివేయగలిగితే, మీరు నిష్క్రమణ కోడ్ 1,5,255 మొదలైనవాటిని తిరిగి ఇవ్వాల్సిన అవసరం లేదు. కనీసం Linux సిస్టమ్స్‌లో జీరో కోడ్ లేని ఏదైనా, ఇది విజయవంతం కాదని నేను ఖచ్చితంగా అనుకుంటున్నాను. అంటే, ఈ సందర్భంలో మీ దరఖాస్తు లోపంతో ముగిసినట్లు పరిగణించబడుతుంది. తదనుగుణంగా, స్నేహపూర్వక మార్గంలో, మీ అప్లికేషన్ లోపం లేకుండా పూర్తి చేసినట్లయితే, మీరు అవుట్‌పుట్‌పై 0 అని చెప్పండి. మీ అప్లికేషన్ కొన్ని కారణాల వల్ల విఫలమైతే, మీరు అవుట్‌పుట్‌లో నాన్-0 అని చెబుతారు. మరియు మీరు ఈ సమాచారంతో పని చేయవచ్చు.
మరియు చివరి ఎంపిక. మీ వినియోగదారు ఒక అభ్యర్థనను పంపినప్పుడు మరియు మీరు దానిని ప్రాసెస్ చేస్తున్నప్పుడు అరగంట పాటు ఆగిపోయినప్పుడు ఇది చెడ్డది. కానీ సాధారణంగా, క్లయింట్ వైపు నుండి సాధారణంగా విలువైన దాని గురించి కూడా నేను చెప్పాలనుకుంటున్నాను. మీకు మొబైల్ అప్లికేషన్, ఫ్రంట్ ఎండ్ మొదలైనవి ఉన్నా పర్వాలేదు. సాధారణంగా వినియోగదారు సెషన్‌ను ముగించవచ్చు, ఏదైనా జరగవచ్చు అని పరిగణనలోకి తీసుకోవడం అవసరం. ఒక అభ్యర్థన పంపబడవచ్చు, ఉదాహరణకు, అండర్ ప్రాసెస్ చేయబడింది మరియు ఎటువంటి ప్రతిస్పందన తిరిగి ఇవ్వబడలేదు. మీ ఫ్రంటెండ్ లేదా మీ మొబైల్ అప్లికేషన్ - సాధారణంగా ఏదైనా ఫ్రంటెండ్, దానిని అలా వుంచుకుందాం - దీన్ని పరిగణనలోకి తీసుకోవాలి. మీరు వెబ్‌సాకెట్‌లతో పని చేస్తుంటే, ఇది సాధారణంగా నేను ఎదుర్కొన్న అత్యంత దారుణమైన నొప్పి.
కొన్ని సాధారణ చాట్‌ల డెవలపర్‌లకు తెలియనప్పుడు, వెబ్‌సాకెట్ విరిగిపోతుందని తేలింది. వారి కోసం, ప్రాక్సీ వద్ద ఏదైనా జరిగినప్పుడు, మేము కేవలం కాన్ఫిగరేషన్‌ను మారుస్తాము మరియు అది రీలోడ్ చేస్తుంది. సహజంగానే, అన్ని దీర్ఘకాల సెషన్లు ఈ సందర్భంలో నలిగిపోతాయి. డెవలపర్‌లు మా వద్దకు పరుగెత్తుకుంటూ వచ్చి ఇలా అంటారు: “అబ్బాయిలు, మీరు ఏమి చేస్తున్నారు, మా ఖాతాదారులందరికీ చాట్ విచ్ఛిన్నమైంది!” మేము వారితో ఇలా అంటాము: “మీరు ఏమి చేస్తున్నారు? మీ క్లయింట్లు మళ్లీ కనెక్ట్ కాలేకపోతున్నారా? వారు ఇలా అంటారు: "లేదు, మాకు సెషన్లు చిరిగిపోకూడదు." సంక్షిప్తంగా, ఇది నిజానికి అర్ధంలేనిది. క్లయింట్ వైపు పరిగణనలోకి తీసుకోవడం అవసరం. ముఖ్యంగా, నేను చెప్పినట్లు, వెబ్‌సాకెట్‌ల వంటి దీర్ఘకాల సెషన్‌లతో, అది విచ్ఛిన్నమవుతుంది మరియు వినియోగదారు గుర్తించకుండా, మీరు అలాంటి సెషన్‌లను మళ్లీ ఇన్‌స్టాల్ చేయగలగాలి. ఆపై ప్రతిదీ ఖచ్చితంగా ఉంది.
వనరులు
నిజానికి, ఇక్కడ నేను మీకు ఒక సరళమైన కథ చెబుతాను. మళ్ళీ నిజ జీవితం నుండి. వనరుల గురించి నేను ఎప్పుడూ వినని అనారోగ్యకరమైన విషయం.
ఈ సందర్భంలో వనరులు, నా ఉద్దేశ్యం, కొన్ని రకాల అభ్యర్థనలు, మీరు మీ కుబెర్నెట్స్ క్లస్టర్‌లలో పాడ్‌లపై ఉంచగల పరిమితులు. డెవలపర్ నుండి నేను విన్న అత్యంత హాస్యాస్పదమైన విషయం... మునుపటి పని ప్రదేశంలో ఉన్న నా తోటి డెవలపర్‌లలో ఒకరు ఒకసారి ఇలా అన్నారు: "నా అప్లికేషన్ క్లస్టర్‌లో ప్రారంభం కాదు." ఇది ప్రారంభం కాలేదని నేను చూశాను, కానీ అది వనరులకు సరిపోలేదు, లేదా వారు చాలా చిన్న పరిమితులను సెట్ చేసారు. సంక్షిప్తంగా, వనరుల కారణంగా అప్లికేషన్ ప్రారంభించబడదు. నేను చెప్తున్నాను: "ఇది వనరుల కారణంగా ప్రారంభం కాదు, మీకు ఎంత అవసరమో మీరే నిర్ణయించుకోండి మరియు తగిన విలువను సెట్ చేయండి." అతను ఇలా అంటాడు: "ఏ రకమైన వనరులు?" కుబెర్నెట్స్, అభ్యర్థనలపై పరిమితులు మరియు బ్లా, బ్లా, బ్లా సెట్ చేయాల్సిన అవసరం ఉందని నేను అతనికి వివరించడం ప్రారంభించాను. ఆ వ్యక్తి ఐదు నిమిషాలు విన్నాడు, నవ్వాడు మరియు ఇలా అన్నాడు: “నేను డెవలపర్‌గా పని చేయడానికి ఇక్కడకు వచ్చాను, నాకు వనరుల గురించి ఏమీ తెలుసుకోవాలనుకోవడం లేదు. నేను కోడ్ రాయడానికి ఇక్కడకు వచ్చాను మరియు అంతే. ఇది విచారకరం. డెవలపర్ దృక్కోణం నుండి ఇది చాలా విచారకరమైన భావన. ముఖ్యంగా ఆధునిక ప్రపంచంలో, ప్రోగ్రెసివ్ డెవొప్స్ గురించి చెప్పాలంటే.
అసలు వనరులు ఎందుకు అవసరం? కుబెర్నెట్స్‌లో 2 రకాల వనరులు ఉన్నాయి. కొన్నింటిని అభ్యర్థనలు అంటారు, మరికొన్ని పరిమితులు అంటారు. వనరుల ద్వారా మేము ప్రాథమికంగా ఎల్లప్పుడూ రెండు ప్రాథమిక పరిమితులు మాత్రమే ఉన్నాయని అర్థం చేసుకుంటాము. అంటే, కుబెర్నెట్స్‌లో నడుస్తున్న కంటైనర్ కోసం CPU సమయ పరిమితులు మరియు RAM పరిమితులు.
మీ అప్లికేషన్‌లో వనరును ఎలా ఉపయోగించవచ్చనే దానిపై పరిమితి గరిష్ట పరిమితిని ఉంచుతుంది. అంటే, దాని ప్రకారం, మీరు పరిమితుల్లో 1GB RAM అని చెబితే, మీ అప్లికేషన్ 1GB RAM కంటే ఎక్కువ ఉపయోగించలేరు. మరియు అతను అకస్మాత్తుగా దీన్ని కోరుకుంటే మరియు దీన్ని చేయడానికి ప్రయత్నిస్తే, ఓమ్ కిల్లర్ అనే ప్రక్రియ, మెమరీలో లేదు, అంటే, వచ్చి మీ అప్లికేషన్‌ను చంపుతుంది - అంటే, అది కేవలం రీస్టార్ట్ అవుతుంది. CPU ఆధారంగా అప్లికేషన్‌లు పునఃప్రారంభించబడవు. CPU పరంగా, ఒక అప్లికేషన్ పరిమితుల్లో పేర్కొన్న దానికంటే ఎక్కువగా ఉపయోగించడానికి ప్రయత్నిస్తే, CPU ఖచ్చితంగా ఎంపిక చేయబడుతుంది. ఇది పునఃప్రారంభానికి దారితీయదు. ఇది పరిమితి - ఇది ఎగువ పరిమితి.
మరియు ఒక అభ్యర్థన ఉంది. మీ కుబెర్నెట్స్ క్లస్టర్‌లోని నోడ్‌లు అప్లికేషన్‌లతో ఎలా నిండిపోయాయో కుబెర్నెట్స్ ఎలా అర్థం చేసుకుంటారనేది అభ్యర్థన. అంటే, అభ్యర్థన అనేది మీ దరఖాస్తు యొక్క ఒక రకమైన నిబద్ధత. నేను ఏమి ఉపయోగించాలనుకుంటున్నానో అది చెబుతుంది: "మీరు నా కోసం ఇంత CPU మరియు ఇంత మెమరీని రిజర్వ్ చేయాలని నేను కోరుకుంటున్నాను." అటువంటి సాధారణ సారూప్యత. మనకు మొత్తం 8 CPUలు ఉన్న నోడ్ ఉంటే, నాకు తెలియదు. మరియు ఒక పాడ్ అక్కడికి వస్తుంది, దీని అభ్యర్థనలు 1 CPU అని చెబుతాయి, అంటే నోడ్‌లో 7 CPUలు మిగిలి ఉన్నాయి. అంటే, తదనుగుణంగా, ఈ నోడ్‌కి 8 పాడ్లు వచ్చిన వెంటనే, వాటిలో ప్రతి దాని అభ్యర్థనలలో 1 CPU ఉంటుంది, నోడ్, కుబెర్నెటీస్ కోణం నుండి, CPU అయిపోయినట్లుగా మరియు అభ్యర్థనలతో మరిన్ని పాడ్లు ఉండకూడదు. ఈ నోడ్‌లో ప్రారంభించబడింది. అన్ని నోడ్‌లు CPU అయిపోతే, CPU అయిపోయినందున మీ పాడ్‌లను అమలు చేయడానికి క్లస్టర్‌లో తగిన నోడ్‌లు లేవని Kubernetes చెప్పడం ప్రారంభిస్తారు.
అభ్యర్థనలు ఎందుకు అవసరం మరియు అభ్యర్థనలు లేకుండా ఎందుకు, కుబెర్నెట్స్‌లో ఏదైనా ప్రారంభించాల్సిన అవసరం లేదని నేను భావిస్తున్నాను? ఒక ఊహాజనిత పరిస్థితిని ఊహించుకుందాం. మీరు అభ్యర్థనలు లేకుండా మీ అప్లికేషన్‌ను ప్రారంభించండి, కుబెర్నెటెస్‌కు మీ వద్ద ఎంత ఉంది, మీరు ఏ నోడ్‌లకు దాన్ని నెట్టగలరో తెలియదు. బాగా, అతను నోడ్స్‌పైకి నెట్టివేస్తాడు, నెట్టివేస్తాడు. ఏదో ఒక సమయంలో, మీరు మీ అప్లికేషన్‌కి ట్రాఫిక్‌ని పొందడం ప్రారంభిస్తారు. మరియు అనువర్తనాల్లో ఒకటి అకస్మాత్తుగా పరిమితులకు అనుగుణంగా ఉన్న పరిమితుల వరకు వనరులను ఉపయోగించడం ప్రారంభిస్తుంది. సమీపంలో మరొక అప్లికేషన్ ఉందని మరియు దీనికి వనరులు కూడా అవసరమని తేలింది. నోడ్ వాస్తవానికి భౌతికంగా వనరుల నుండి బయటపడటం ప్రారంభమవుతుంది, ఉదాహరణకు, OP. నోడ్ వాస్తవానికి భౌతికంగా వనరులు అయిపోవడం ప్రారంభమవుతుంది, ఉదాహరణకు, రాండమ్ యాక్సెస్ మెమరీ (RAM). నోడ్ పవర్ అయిపోతే, ముందుగా డాకర్ ప్రతిస్పందించడం ఆపివేస్తుంది, తర్వాత క్యూబ్‌లెట్, తర్వాత OS. వారు కేవలం అపస్మారక స్థితికి వెళ్లిపోతారు మరియు ప్రతిదీ ఖచ్చితంగా మీ కోసం పనిచేయడం మానేస్తుంది. అంటే, ఇది మీ నోడ్ చిక్కుకుపోవడానికి దారి తీస్తుంది మరియు మీరు దాన్ని పునఃప్రారంభించవలసి ఉంటుంది. సంక్షిప్తంగా, పరిస్థితి చాలా బాగా లేదు.
మరియు మీకు అభ్యర్థనలు ఉన్నప్పుడు, పరిమితులు చాలా భిన్నంగా ఉండవు, పరిమితులు లేదా అభ్యర్థనల కంటే కనీసం అనేక రెట్లు ఎక్కువ కావు, అప్పుడు మీరు కుబెర్నెటెస్ క్లస్టర్‌ల నోడ్‌ల అంతటా అటువంటి సాధారణ, హేతుబద్ధమైన అప్లికేషన్‌లను నింపవచ్చు. అదే సమయంలో, కుబెర్నెటెస్‌కు అది ఎక్కడ ఉంచుతుంది, ఏది ఎక్కడ ఎంత ఉపయోగించబడుతుందో సుమారుగా తెలుసు. అంటే, ఇది అలాంటి క్షణం మాత్రమే. దానిని అర్థం చేసుకోవడం ముఖ్యం. మరియు ఇది సూచించబడిందని నియంత్రించడం ముఖ్యం.
డేటా నిల్వ
మా తదుపరి పాయింట్ డేటా నిల్వ గురించి. వారితో ఏమి చేయాలి మరియు సాధారణంగా, కుబెర్నెట్స్‌లో పట్టుదలతో ఏమి చేయాలి?
నేను మళ్ళీ, మా లోపల అనుకుంటున్నాను , Kubernetes లో డేటాబేస్ గురించి ఒక అంశం ఉంది. "కుబెర్నెట్స్‌లో డేటాబేస్ను అమలు చేయడం సాధ్యమేనా?" అని అడిగినప్పుడు మీ సహోద్యోగులు మీకు ఏమి చెప్పారో కూడా నాకు దాదాపుగా తెలుసునని నాకు అనిపిస్తోంది. కొన్ని కారణాల వల్ల, కుబెర్నెట్స్‌లో డేటాబేస్ను అమలు చేయడం సాధ్యమేనా అని మీరు ప్రశ్న అడుగుతుంటే, అది అసాధ్యం అని మీ సహోద్యోగులు మీకు చెప్పినట్లు నాకు అనిపిస్తోంది.
ఇక్కడ లాజిక్ చాలా సులభం. ఒకవేళ, మీరు పంపిణీ చేయబడిన నెట్‌వర్క్ నిల్వ యొక్క తప్పులను తట్టుకునే వ్యవస్థను రూపొందించగల మంచి వ్యక్తి అయితే, ఈ సందర్భంలో డేటాబేస్ను ఎలా అమర్చాలో అర్థం చేసుకోండి, కంటైనర్‌లలో క్లౌడ్ స్థానికంగా ఎలా పని చేయాలో నేను మరోసారి వివరిస్తాను. సాధారణంగా డేటాబేస్లో. చాలా మటుకు, దీన్ని ఎలా అమలు చేయాలనే దాని గురించి మీకు ఎటువంటి సందేహం లేదు. మీకు అలాంటి ప్రశ్న ఉంటే, మరియు ఉత్పత్తిలో అదంతా విప్పి, మరణానికి సరైనదని మరియు ఎప్పటికీ పడిపోదని మీరు నిర్ధారించుకోవాలనుకుంటే, ఇది జరగదు. ఈ విధానంతో మిమ్మల్ని మీరు పాదంలో కాల్చుకోవడం గ్యారెంటీ. కాబట్టి చేయకపోవడమే మంచిది.
ఉదాహరణకు, మా అప్లికేషన్ స్టోర్ చేయదలిచిన డేటా, వినియోగదారులు అప్‌లోడ్ చేసే కొన్ని చిత్రాలు, మా అప్లికేషన్ దాని ఆపరేషన్ సమయంలో ఉత్పత్తి చేసే కొన్ని విషయాలు, ఉదాహరణకు, ప్రారంభంలో మనం ఏమి చేయాలి? కుబెర్నెట్స్‌లో వారితో ఏమి చేయాలి?
సాధారణంగా, ఆదర్శవంతంగా, అవును, వాస్తవానికి, కుబెర్నెటెస్ చాలా బాగా రూపొందించబడింది మరియు సాధారణంగా ప్రారంభంలో స్థితిలేని అనువర్తనాల కోసం రూపొందించబడింది. అంటే, సమాచారాన్ని నిల్వ చేయని అప్లికేషన్ల కోసం. ఇది ఆదర్శవంతమైనది.
కానీ, వాస్తవానికి, ఆదర్శ ఎంపిక ఎల్లప్పుడూ ఉండదు. అయితే ఏంటి? మొదటి మరియు సరళమైన విషయం ఏమిటంటే, ఒక రకమైన S3ని తీసుకోవడం, కేవలం ఇంట్లో తయారు చేసినది కాదు, ఇది ఎలా పని చేస్తుందో కూడా అస్పష్టంగా ఉంది, కానీ కొంతమంది ప్రొవైడర్ నుండి. మంచి, సాధారణ ప్రొవైడర్ - మరియు S3ని ఉపయోగించడానికి మీ అప్లికేషన్‌ను బోధించండి. అంటే, మీ వినియోగదారు ఫైల్‌ను అప్‌లోడ్ చేయాలనుకున్నప్పుడు, “ఇక్కడ, దయచేసి దాన్ని S3కి అప్‌లోడ్ చేయండి” అని చెప్పండి. అతను దానిని స్వీకరించాలనుకున్నప్పుడు, "ఇదిగో S3 బ్యాక్‌కి లింక్ ఉంది మరియు దానిని ఇక్కడ నుండి తీసుకోండి" అని చెప్పండి. ఇది ఆదర్శవంతమైనది.
అకస్మాత్తుగా కొన్ని కారణాల వల్ల ఈ ఆదర్శ ఎంపిక సరిపోకపోతే, మీరు వ్రాయని, మీరు అభివృద్ధి చేయని అప్లికేషన్ లేదా ఇది ఒక రకమైన భయంకరమైన వారసత్వం అయితే, ఇది S3 ప్రోటోకాల్‌ను ఉపయోగించదు, కానీ స్థానిక డైరెక్టరీలతో పని చేయాలి స్థానిక ఫోల్డర్లు. ఎక్కువ లేదా తక్కువ సరళమైనదాన్ని తీసుకోండి, కుబెర్నెట్‌లను అమలు చేయండి. అంటే, వెంటనే కొన్ని కనీస పనుల కోసం Ceph ఫెన్సింగ్, ఇది ఒక చెడ్డ ఆలోచన అని నాకు అనిపిస్తోంది. ఎందుకంటే Ceph, కోర్సు యొక్క, మంచి మరియు ఫ్యాషన్. కానీ మీరు ఏమి చేస్తున్నారో మీకు నిజంగా అర్థం కాకపోతే, మీరు సెఫ్‌లో ఏదైనా ఉంచిన తర్వాత, మీరు చాలా సులభంగా మరియు మళ్లీ దాన్ని ఎప్పటికీ పొందలేరు. ఎందుకంటే, మీకు తెలిసినట్లుగా, Ceph దాని క్లస్టర్‌లో బైనరీ రూపంలో డేటాను నిల్వ చేస్తుంది మరియు సాధారణ ఫైల్‌ల రూపంలో కాదు. అందువల్ల, అకస్మాత్తుగా Ceph క్లస్టర్ విచ్ఛిన్నమైతే, మీరు అక్కడ నుండి మీ డేటాను ఎప్పటికీ పొందలేరు అనే పూర్తి మరియు అధిక సంభావ్యత ఉంది.
మేము Ceph పై ఒక కోర్సును కలిగి ఉంటాము, మీరు చేయగలరు .
కాబట్టి, NFS సర్వర్ వంటి సాధారణమైనదాన్ని చేయడం మంచిది. Kubernetes వారితో పని చేయవచ్చు, మీరు NFS సర్వర్ క్రింద డైరెక్టరీని మౌంట్ చేయవచ్చు - మీ అప్లికేషన్ కేవలం స్థానిక డైరెక్టరీ వలె ఉంటుంది. అదే సమయంలో, సహజంగానే, మీరు మళ్ళీ, మీ NFSతో ఏదైనా చేయవలసి ఉందని మీరు అర్థం చేసుకోవాలి, కొన్నిసార్లు ఇది అసాధ్యమని మీరు అర్థం చేసుకోవాలి మరియు ఈ సందర్భంలో మీరు ఏమి చేస్తారనే ప్రశ్నను పరిగణించండి. బహుశా అది వేరే మెషీన్‌లో ఎక్కడో బ్యాకప్ చేయబడి ఉండవచ్చు.
నేను మాట్లాడిన తదుపరి అంశం ఏమిటంటే, మీ అప్లికేషన్ ఆపరేషన్ సమయంలో కొన్ని ఫైల్‌లను రూపొందిస్తే ఏమి చేయాలి. ఉదాహరణకు, ఇది ప్రారంభమైనప్పుడు, ఇది కొన్ని స్టాటిక్ ఫైల్‌ను ఉత్పత్తి చేస్తుంది, ఇది లాంచ్ సమయంలో మాత్రమే అప్లికేషన్ స్వీకరించే కొంత సమాచారం ఆధారంగా ఉంటుంది. ఏ క్షణం. అటువంటి డేటా ఎక్కువగా లేకపోతే, మీరు అస్సలు బాధపడాల్సిన అవసరం లేదు, మీ కోసం ఈ అప్లికేషన్‌ను ఇన్‌స్టాల్ చేసి పని చేయండి. ఇక్కడ ఒక్కటే ప్రశ్న ఏమిటి, చూడండి. చాలా తరచుగా, WordPress వంటి అన్ని రకాల లెగసీ సిస్టమ్‌లు, ప్రత్యేకించి కొన్ని రకాల మోసపూరిత ప్లగిన్‌లు, మోసపూరిత PHP డెవలపర్‌లను సవరించడంతో, వారు తమ కోసం ఒక రకమైన ఫైల్‌ను రూపొందించుకునేలా దీన్ని ఎలా తయారు చేయాలో తరచుగా తెలుసు. దీని ప్రకారం, ఒకటి ఒక ఫైల్‌ను ఉత్పత్తి చేస్తుంది, రెండవది రెండవ ఫైల్‌ను ఉత్పత్తి చేస్తుంది. అవి భిన్నమైనవి. ఖాతాదారుల కుబెర్నెట్స్ క్లస్టర్‌లో బ్యాలెన్సింగ్ యాదృచ్ఛికంగా జరుగుతుంది. తదనుగుణంగా, ఉదాహరణకు, కలిసి ఎలా పని చేయాలో వారికి తెలియదని తేలింది. ఒకటి ఒక సమాచారాన్ని ఇస్తుంది, మరొకటి వినియోగదారుకు మరొక సమాచారాన్ని ఇస్తుంది. ఇది మీరు నివారించవలసిన విషయం. అంటే, కుబెర్నెటీస్‌లో, మీరు ప్రారంభించిన ప్రతి ఒక్కటి బహుళ సందర్భాలలో పని చేయగలదని హామీ ఇవ్వబడుతుంది. ఎందుకంటే కుబెర్నెటీస్ కదిలే విషయం. దీని ప్రకారం, అతను ఎవరినీ అడగకుండానే, అతను కోరుకున్నప్పుడు ఏదైనా తరలించగలడు. అందువల్ల, మీరు దీన్ని లెక్కించాలి. ఒక సందర్భంలో ప్రారంభించిన ప్రతిదీ త్వరగా లేదా తరువాత విఫలమవుతుంది. మీకు ఎంత ఎక్కువ రిజర్వేషన్లు ఉంటే అంత మంచిది. కానీ మళ్ళీ, నేను చెప్తున్నాను, మీకు అలాంటి కొన్ని ఫైల్స్ ఉంటే, మీరు వాటిని మీ క్రింద ఉంచవచ్చు, అవి చిన్న మొత్తంలో ఉంటాయి. వాటిలో కొంచెం ఎక్కువ ఉంటే, మీరు వాటిని కంటైనర్‌లోకి నెట్టకూడదు.
కుబెర్నెట్స్‌లో అలాంటి అద్భుతమైన విషయం ఉందని నేను సలహా ఇస్తాను, మీరు వాల్యూమ్‌ను ఉపయోగించవచ్చు. ముఖ్యంగా, టైప్ ఖాళీ డిర్ వాల్యూమ్ ఉంది. అంటే, మీరు ప్రారంభించిన సర్వర్‌లోని దాని సేవా డైరెక్టరీలలో కుబెర్నెట్స్ స్వయంచాలకంగా డైరెక్టరీని సృష్టిస్తుంది. మరియు అతను దానిని మీకు ఇస్తాడు, తద్వారా మీరు దానిని ఉపయోగించుకోవచ్చు. ఒకే ఒక ముఖ్యమైన అంశం ఉంది. అంటే, మీ డేటా కంటైనర్‌లో నిల్వ చేయబడదు, కానీ మీరు నడుస్తున్న హోస్ట్‌లో నిల్వ చేయబడదు. అంతేకాకుండా, కుబెర్నెట్స్ సాధారణ కాన్ఫిగరేషన్‌లో అటువంటి ఖాళీ డిర్‌లను నియంత్రించవచ్చు మరియు వాటి గరిష్ట పరిమాణాన్ని నియంత్రించగలుగుతుంది మరియు దానిని అధిగమించడానికి అనుమతించదు. పాడ్ రీస్టార్ట్ సమయంలో మీరు ఖాళీగా ఉన్న డిర్‌లో వ్రాసినది కోల్పోలేదు. అంటే, మీ పాడ్ పొరపాటున పడిపోయి, మళ్లీ పైకి లేస్తే, ఖాళీగా ఉన్న డిర్‌లోని సమాచారం ఎక్కడికీ వెళ్లదు. అతను దీన్ని మళ్లీ కొత్త ప్రారంభంలో ఉపయోగించవచ్చు - మరియు అది మంచిది. మీ పాడ్ ఎక్కడో వెళ్లిపోతే, సహజంగానే అతను డేటా లేకుండా వెళ్లిపోతాడు. అంటే, ఖాళీ డిర్‌తో ప్రారంభించబడిన నోడ్ నుండి పాడ్ అదృశ్యమైన వెంటనే, ఖాళీ డిర్ తొలగించబడుతుంది.
ఖాళీ దిర్ గురించి ఇంకా ఏది మంచిది? ఉదాహరణకు, దీనిని కాష్‌గా ఉపయోగించవచ్చు. మా అప్లికేషన్ ఫ్లైలో ఏదైనా ఉత్పత్తి చేస్తుందని, దానిని వినియోగదారులకు అందజేస్తుందని మరియు చాలా కాలం పాటు చేస్తుందని ఊహించుకుందాం. అందువల్ల, అప్లికేషన్, ఉదాహరణకు, ఉత్పత్తి చేస్తుంది మరియు వినియోగదారులకు ఇస్తుంది, అదే సమయంలో దానిని ఎక్కడో నిల్వ చేస్తుంది, తద్వారా వినియోగదారు తదుపరిసారి అదే పని కోసం వచ్చినప్పుడు, దాన్ని వెంటనే రూపొందించడం వేగవంతం అవుతుంది. మెమరీలో క్రియేట్ చేయమని కుబెర్నెట్స్‌ని ఖాళీ డిర్‌ని అడగవచ్చు. అందువలన, మీ కాష్‌లు సాధారణంగా మెరుపు వేగంతో పని చేయగలవు - డిస్క్ యాక్సెస్ వేగం పరంగా. అంటే, మీరు మెమరీలో ఖాళీగా ఉన్న dirని కలిగి ఉన్నారు, OSలో అది మెమరీలో నిల్వ చేయబడుతుంది, కానీ మీ కోసం, పాడ్ లోపల ఉన్న వినియోగదారు కోసం, ఇది కేవలం స్థానిక డైరెక్టరీ వలె కనిపిస్తుంది. ప్రత్యేకంగా ఏదైనా మ్యాజిక్ నేర్పడానికి మీకు యాప్ అవసరం లేదు. మీరు నేరుగా మీ ఫైల్‌ను తీసుకొని డైరెక్టరీలో ఉంచండి, కానీ, వాస్తవానికి, OSలో మెమరీలో. ఇది కుబెర్నెట్స్ పరంగా కూడా చాలా అనుకూలమైన లక్షణం.
మినియోకి ఎలాంటి సమస్యలు ఉన్నాయి? మినియోతో ఉన్న ప్రధాన సమస్య ఏమిటంటే, ఈ విషయం పని చేయడానికి, ఇది ఎక్కడో అమలు చేయబడాలి మరియు ఒక రకమైన ఫైల్ సిస్టమ్ ఉండాలి, అంటే నిల్వ. మరియు ఇక్కడ మేము Ceph కలిగి ఉన్న అదే సమస్యలను ఎదుర్కొంటాము. అంటే, మినియో తన ఫైల్‌లను ఎక్కడో భద్రపరచాలి. ఇది మీ ఫైల్‌లకు కేవలం HTTP ఇంటర్‌ఫేస్. అంతేకాకుండా, అమెజాన్ యొక్క S3 కంటే ఫంక్షనాలిటీ స్పష్టంగా పేలవంగా ఉంది. మునుపు, ఇది వినియోగదారుని సరిగ్గా ప్రామాణీకరించలేకపోయింది. ఇప్పుడు, నాకు తెలిసినంతవరకు, ఇది ఇప్పటికే వేర్వేరు అధికారాలతో బకెట్లను సృష్టించగలదు, కానీ మళ్ళీ, ప్రధాన సమస్య ఏమిటంటే, కనీసం అంతర్లీన నిల్వ వ్యవస్థ అని నాకు అనిపిస్తోంది.
మెమరీలో ఖాళీ డైర్ పరిమితులను ఎలా ప్రభావితం చేస్తుంది? పరిమితులను ఏ విధంగానూ ప్రభావితం చేయదు. ఇది హోస్ట్ యొక్క మెమరీలో ఉంటుంది మరియు మీ కంటైనర్ మెమరీలో కాదు. అంటే, మీ కంటైనర్ మెమరీలో ఖాళీగా ఉన్న డిర్‌ని దాని ఆక్రమిత మెమరీలో భాగంగా చూడదు. హోస్ట్ దీన్ని చూస్తుంది. దీని ప్రకారం, అవును, kubernetes దృష్టికోణంలో, మీరు దీన్ని ఉపయోగించడం ప్రారంభించినప్పుడు, మీరు మీ మెమరీలో కొంత భాగాన్ని ఖాళీ డిర్‌కు వెచ్చిస్తున్నారని అర్థం చేసుకోవడం మంచిది. మరియు తదనుగుణంగా, అప్లికేషన్ల వల్ల మాత్రమే మెమరీ అయిపోతుందని అర్థం చేసుకోండి, కానీ ఎవరైనా ఈ ఖాళీ డిర్లకు వ్రాస్తారు.
క్లౌడ్నేటివ్నెస్
మరియు చివరి ఉపశీర్షిక Cloudnative అంటే ఏమిటి. అది ఎందుకు అవసరం? క్లౌడ్నేటివ్నెస్ మరియు మొదలైనవి.
అంటే, ఆధునిక క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో పని చేయడానికి సామర్థ్యం మరియు వ్రాయబడిన అప్లికేషన్‌లు. కానీ, వాస్తవానికి, క్లౌడ్‌నేటివ్‌కు అలాంటి మరొక అంశం ఉంది. ఇది ఆధునిక క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్ యొక్క అన్ని అవసరాలను పరిగణనలోకి తీసుకునే అప్లికేషన్ మాత్రమే కాదు, ఈ ఆధునిక క్లౌడ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌తో ఎలా పని చేయాలో కూడా తెలుసు, ఈ క్లౌడ్‌లలో ఇది పని చేయడం వల్ల కలిగే ప్రయోజనాలు మరియు అప్రయోజనాలను సద్వినియోగం చేసుకోండి. ఓవర్‌బోర్డ్‌కు వెళ్లి మేఘాలలో పని చేయవద్దు, కానీ క్లౌడ్‌లో పని చేయడం వల్ల కలిగే ప్రయోజనాలను సద్వినియోగం చేసుకోండి.
కుబెర్నెట్స్‌ని ఉదాహరణగా తీసుకుందాం. మీ అప్లికేషన్ Kubernetesలో అమలవుతోంది. మీ అప్లికేషన్ ఎల్లప్పుడూ లేదా మీ అప్లికేషన్ కోసం నిర్వాహకులు ఎల్లప్పుడూ సేవా ఖాతాను సృష్టించవచ్చు. అంటే, దాని సర్వర్‌లో కుబెర్నెట్స్‌లోనే అధికారం కోసం ఒక ఖాతా. అక్కడ మనకు అవసరమైన కొన్ని హక్కులను జోడించండి. మరియు మీరు మీ అప్లికేషన్ నుండి కుబెర్నెట్‌లను యాక్సెస్ చేయవచ్చు. మీరు ఈ విధంగా ఏమి చేయవచ్చు? ఉదాహరణకు, అప్లికేషన్ నుండి, మీ ఇతర అప్లికేషన్‌లు, ఇతర సారూప్య సందర్భాలు ఎక్కడ ఉన్నాయి అనే దాని గురించి డేటాను స్వీకరించండి మరియు అలాంటి అవసరం ఉంటే కుబెర్నెటెస్ పైన క్లస్టర్ చేయండి.
మళ్ళీ, మాకు అక్షరాలా ఇటీవల ఒక కేసు ఉంది. క్యూను పర్యవేక్షించే ఒక కంట్రోలర్ మాకు ఉంది. మరియు ఈ క్యూలో కొన్ని కొత్త టాస్క్‌లు కనిపించినప్పుడు, అది కుబెర్నెట్స్‌కి వెళుతుంది - మరియు కుబెర్నెట్స్ లోపల అది కొత్త పాడ్‌ను సృష్టిస్తుంది. ఈ పాడ్‌కి కొంత కొత్త పనిని ఇస్తుంది మరియు ఈ పాడ్ ఫ్రేమ్‌వర్క్‌లో, పాడ్ టాస్క్‌ను నిర్వహిస్తుంది, కంట్రోలర్‌కు ప్రతిస్పందనను పంపుతుంది మరియు కంట్రోలర్ ఈ సమాచారంతో ఏదైనా చేస్తుంది. ఉదాహరణకు, ఇది డేటాబేస్ను జోడిస్తుంది. అంటే, మళ్ళీ, ఇది మా అప్లికేషన్ కుబెర్నెట్స్‌లో నడుస్తుంది అనే వాస్తవం యొక్క ప్లస్. మా అప్లికేషన్ యొక్క కార్యాచరణను ఎలాగైనా విస్తరించడానికి మరియు మరింత సౌకర్యవంతంగా చేయడానికి మేము అంతర్నిర్మిత కుబెర్నెట్స్ ఫంక్షనాలిటీని ఉపయోగించవచ్చు. అంటే, ఒక అప్లికేషన్‌ను ఎలా లాంచ్ చేయాలి, వర్కర్‌ను ఎలా లాంచ్ చేయాలి అనే విషయాల గురించి కొన్ని రకాల మాయాజాలాన్ని దాచవద్దు. కుబెర్నెట్స్‌లో, అప్లికేషన్ పైథాన్‌లో వ్రాయబడి ఉంటే మీరు యాప్‌లో అభ్యర్థనను పంపండి.
మేము కుబెర్నెట్స్ దాటి వెళితే అదే వర్తిస్తుంది. మా కుబెర్నెట్‌లు ఎక్కడో నడుస్తున్నాయి - అది ఒక రకమైన క్లౌడ్‌లో ఉంటే మంచిది. మళ్ళీ, మనం రన్ అవుతున్న క్లౌడ్ యొక్క సామర్థ్యాలను మనం ఉపయోగించుకోవచ్చు మరియు ఉపయోగించాలి అని నేను నమ్ముతున్నాను. మేఘం మనకు అందించే ప్రాథమిక విషయాల నుండి. బ్యాలెన్సింగ్ అంటే క్లౌడ్ బ్యాలెన్సర్‌లను క్రియేట్ చేసి వాడుకోవచ్చు. ఇది మనం ఉపయోగించగల దాని యొక్క ప్రత్యక్ష ప్రయోజనం. ఎందుకంటే క్లౌడ్ బ్యాలెన్సింగ్, మొదటగా, అది ఎలా పని చేస్తుందో, ఎలా కాన్ఫిగర్ చేయబడిందో మన నుండి మూర్ఖంగా బాధ్యతను తొలగిస్తుంది. ప్లస్ ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, ఎందుకంటే సాధారణ కుబెర్నెట్‌లు మేఘాలతో కలిసిపోతాయి.
స్కేలింగ్ కోసం కూడా అదే జరుగుతుంది. రెగ్యులర్ కుబెర్నెట్‌లు క్లౌడ్ ప్రొవైడర్‌లతో కలిసిపోవచ్చు. క్లస్టర్ నోడ్‌లు అయిపోతే, అంటే నోడ్ ఖాళీ అయిపోయినట్లయితే, మీరు జోడించాల్సిన అవసరం ఉందని అర్థం చేసుకోవడం ఎలాగో తెలుసు - కుబెర్నెట్స్ స్వయంగా మీ క్లస్టర్‌కి కొత్త నోడ్‌లను జోడిస్తుంది మరియు వాటిపై పాడ్‌లను ప్రారంభించడం ప్రారంభిస్తుంది. అంటే, మీ లోడ్ వచ్చినప్పుడు, పొయ్యిల సంఖ్య పెరగడం ప్రారంభమవుతుంది. ఈ పాడ్‌ల కోసం క్లస్టర్‌లోని నోడ్‌లు అయిపోయినప్పుడు, కుబెర్నెటెస్ కొత్త నోడ్‌లను లాంచ్ చేస్తుంది మరియు తదనుగుణంగా, పాడ్‌ల సంఖ్య ఇంకా పెరుగుతుంది. మరియు ఇది చాలా సౌకర్యవంతంగా ఉంటుంది. ఫ్లైలో క్లస్టర్‌ను స్కేల్ చేయడానికి ఇది ప్రత్యక్ష అవకాశం. చాలా వేగంగా కాదు, ఇది సెకను కాదు అనే అర్థంలో, కొత్త నోడ్‌లను జోడించడానికి ఇది ఒక నిమిషం లాంటిది.
కానీ నా అనుభవం నుండి, మళ్ళీ, ఇది నేను చూసిన చక్కని విషయం. రోజు సమయం ఆధారంగా క్లౌడ్‌నేటివ్ క్లస్టర్ స్కేల్ చేసినప్పుడు. ఇది బ్యాక్ ఆఫీస్‌లోని వ్యక్తులు ఉపయోగించే బ్యాకెండ్ సేవ. అంటే, వారు ఉదయం 9 గంటలకు పనికి వస్తారు, సిస్టమ్‌లోకి లాగిన్ అవ్వడం ప్రారంభిస్తారు మరియు తదనుగుణంగా, అన్నీ నడుస్తున్న క్లౌడ్‌నేటివ్ క్లస్టర్ ఉబ్బడం ప్రారంభమవుతుంది, కొత్త పాడ్‌లను లాంచ్ చేస్తుంది, తద్వారా పనికి వచ్చే ప్రతి ఒక్కరూ అప్లికేషన్‌తో పని చేయవచ్చు. వారు రాత్రి 8 గంటలకు లేదా సాయంత్రం 6 గంటలకు పనిని విడిచిపెట్టినప్పుడు, ఇకపై ఎవరూ అప్లికేషన్‌ను ఉపయోగించడం లేదని కుబెర్నెట్స్ క్లస్టర్‌లు గమనించి, కుదించడం ప్రారంభిస్తారు. 30 శాతం వరకు పొదుపు హామీ ఇవ్వబడుతుంది. ఇది ఆ సమయంలో అమెజాన్‌లో పనిచేసింది; ఆ సమయంలో రష్యాలో ఇంత బాగా చేయగలిగిన వారు ఎవరూ లేరు.
నేను మీకు సూటిగా చెబుతాను, మేము కుబెర్నెట్‌లను ఉపయోగిస్తాము మరియు క్లౌడ్ సామర్థ్యాలను సద్వినియోగం చేసుకుంటాము కాబట్టి పొదుపులు 30 శాతం. ఇప్పుడు ఇది రష్యాలో చేయవచ్చు. నేను ఎవరికీ ప్రచారం చేయను, అయితే దీన్ని చేయగల ప్రొవైడర్లు ఉన్నారని చెప్పండి, దాన్ని బటన్‌తో బాక్స్ వెలుపల అందించండి.
నేను మీ దృష్టిని ఆకర్షించాలనుకుంటున్న చివరి పాయింట్ ఒకటి ఉంది. మీ అప్లికేషన్, మీ ఇన్‌ఫ్రాస్ట్రక్చర్ క్లౌడ్‌నేటివ్‌గా ఉండాలంటే, ఇన్‌ఫ్రాస్ట్రక్చర్ అనే విధానాన్ని కోడ్‌గా స్వీకరించడం ప్రారంభించడం అర్థవంతంగా ఉంటుంది. అంటే, మీ అప్లికేషన్ లేదా మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌కు మీ వర్ణించండి అనే కోడ్ అవసరం అని అర్థం. అప్లికేషన్, కోడ్ రూపంలో మీ వ్యాపార తర్కం. మరియు దానితో కోడ్‌గా పని చేయండి, అంటే, దాన్ని పరీక్షించండి, రోల్ అవుట్ చేయండి, gitలో నిల్వ చేయండి, దానికి CICDని వర్తింపజేయండి.
మరియు ఇది ఖచ్చితంగా మీ అవస్థాపనపై ఎల్లప్పుడూ నియంత్రణను కలిగి ఉండటానికి, ఇది ఏ స్థితిలో ఉందో ఎల్లప్పుడూ అర్థం చేసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. రెండవది, లోపాలను కలిగించే మాన్యువల్ ఆపరేషన్లను నివారించండి. మూడవది, మీరు నిరంతరం అదే మాన్యువల్ పనులను చేయవలసి వచ్చినప్పుడు టర్నోవర్ అని పిలవబడే వాటిని నివారించండి. నాల్గవది, వైఫల్యం సంభవించినప్పుడు చాలా వేగంగా కోలుకోవడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. రష్యాలో, నేను దీని గురించి మాట్లాడిన ప్రతిసారీ, "అవును, ఇది స్పష్టంగా ఉంది, కానీ మీకు విధానాలు ఉన్నాయి, సంక్షిప్తంగా, ఏదైనా పరిష్కరించాల్సిన అవసరం లేదు" అని చెప్పే పెద్ద సంఖ్యలో వ్యక్తులు ఎల్లప్పుడూ ఉంటారు. కానీ ఇది నిజం. మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ఏదైనా విచ్ఛిన్నమైతే, క్లౌడ్‌నేటివ్ విధానం మరియు ఇన్‌ఫ్రాస్ట్రక్చర్‌ని కోడ్‌గా పరిగణించడం ద్వారా, దాన్ని పరిష్కరించడం కంటే, సర్వర్‌కి వెళ్లి, విరిగిపోయిన వాటిని గుర్తించడం మరియు దాన్ని పరిష్కరించడం సులభం. సర్వర్‌ని తొలగించి, దాన్ని మళ్లీ సృష్టించడానికి. మరియు నేను ఇవన్నీ పునరుద్ధరించబడతాను.
ఈ సమస్యలన్నీ మరింత వివరంగా చర్చించబడ్డాయి . లింక్‌ని అనుసరించడం ద్వారా మీరు ప్రోగ్రామ్ మరియు షరతులతో మిమ్మల్ని పరిచయం చేసుకోవచ్చు. అనుకూలమైన విషయం ఏమిటంటే, మీరు ఇంటి నుండి లేదా రోజుకు 1-2 గంటలు పని చేయడం ద్వారా కుబెర్నెట్స్‌లో నైపుణ్యం సాధించవచ్చు.
మూలం: www.habr.com