అప్లికేషన్‌ను కుబెర్నెట్స్‌కి తరలించడం సరిపోతుందని చాలా మంది నమ్ముతారు (హెల్మ్‌ని ఉపయోగించడం లేదా మాన్యువల్‌గా) మరియు వారు సంతోషంగా ఉంటారు. కానీ అది అంత సులభం కాదు.
జట్టు DevOps ఇంజనీర్ జూలియన్ గిండి ద్వారా ఒక కథనాన్ని అనువదించారు. మైగ్రేషన్ ప్రక్రియలో తన కంపెనీకి ఎదురైన ఆపదలను అతను పంచుకుంటాడు, తద్వారా మీరు అదే రేక్‌పై అడుగు పెట్టరు.
మొదటి దశ: పాడ్ అభ్యర్థనలు మరియు పరిమితులను ఏర్పాటు చేయడం
మన పాడ్‌లు పనిచేసే స్వచ్ఛమైన వాతావరణాన్ని ఏర్పాటు చేయడం ద్వారా ప్రారంభిద్దాం. కుబెర్నెటెస్ పాడ్‌లను షెడ్యూల్ చేయడం మరియు వైఫల్య పరిస్థితులను నిర్వహించడంలో గొప్ప పని చేస్తుంది. కానీ అది విజయవంతంగా పని చేయడానికి ఎన్ని వనరులు అవసరమో అంచనా వేయడం కష్టంగా ఉంటే, షెడ్యూలర్ కొన్నిసార్లు పాడ్‌ను ఉంచలేరని తేలింది. ఇక్కడే వనరులు మరియు పరిమితుల కోసం అభ్యర్థనలు వస్తాయి. అభ్యర్థనలు మరియు పరిమితులను సెట్ చేయడానికి ఉత్తమమైన విధానం గురించి చాలా చర్చలు జరుగుతున్నాయి. కొన్నిసార్లు ఇది సైన్స్ కంటే ఎక్కువ కళలా అనిపిస్తుంది. ఇదిగో మా విధానం.
పాడ్ అభ్యర్థనలు - పాడ్‌ను ఉత్తమంగా ఉంచడానికి షెడ్యూలర్ ఉపయోగించే ప్రధాన విలువ ఇది.
నుండి : వడపోత దశ పాడ్ షెడ్యూల్ చేయగలిగే నోడ్‌ల సెట్‌ను నిర్ణయిస్తుంది. ఉదాహరణకు, PodFitsResources ఫిల్టర్ పాడ్ యొక్క నిర్దిష్ట వనరుల అభ్యర్థనలను సంతృప్తి పరచడానికి నోడ్‌లో తగినంత వనరులు ఉన్నాయో లేదో తనిఖీ చేస్తుంది.
మేము అప్లికేషన్ అభ్యర్థనలను ఉపయోగిస్తాము, తద్వారా అవి ఎన్ని వనరులను అంచనా వేయడానికి ఉపయోగించబడతాయి నిజానికి అప్లికేషన్ సరిగ్గా పని చేయడానికి ఇది అవసరం. ఈ విధంగా షెడ్యూలర్ నోడ్‌లను వాస్తవికంగా ఉంచవచ్చు. మేము మొదట్లో ప్రతి పాడ్‌కు తగినంత పెద్ద సంఖ్యలో వనరులు ఉండేలా మార్జిన్‌తో రిక్వెస్ట్‌లను సెట్ చేయాలనుకున్నాము, కానీ షెడ్యూలింగ్ సమయాలు గణనీయంగా పెరిగాయని మరియు కొన్ని పాడ్‌లకు రిసోర్స్ రిక్వెస్ట్‌లు అందనట్లుగా పూర్తిగా షెడ్యూల్ చేయలేదని మేము గమనించాము.
ఈ సందర్భంలో, షెడ్యూలర్ తరచుగా పాడ్‌లను బయటకు నెట్టివేస్తారు మరియు వాటిని రీషెడ్యూల్ చేయడం సాధ్యం కాదు ఎందుకంటే అప్లికేషన్‌కు ఎన్ని వనరులు అవసరమో నియంత్రణ ప్లేన్‌కు తెలియదు, ఇది షెడ్యూలింగ్ అల్గారిథమ్‌లో కీలకమైన అంశం.
పాడ్ పరిమితులు - ఇది పాడ్ కోసం స్పష్టమైన పరిమితి. ఇది క్లస్టర్ కంటైనర్‌కు కేటాయించే గరిష్ట వనరులను సూచిస్తుంది.
మళ్ళీ, నుండి : ఒక కంటైనర్ 4 GiB మెమరీ పరిమితిని కలిగి ఉంటే, అప్పుడు kubelet (మరియు కంటైనర్ రన్‌టైమ్) దానిని అమలు చేస్తుంది. రన్‌టైమ్ కంటైనర్‌ను పేర్కొన్న వనరుల పరిమితి కంటే ఎక్కువ ఉపయోగించడానికి అనుమతించదు. ఉదాహరణకు, కంటైనర్‌లోని ప్రక్రియ అనుమతించబడిన మెమరీ కంటే ఎక్కువ ఉపయోగించేందుకు ప్రయత్నించినప్పుడు, సిస్టమ్ కెర్నల్ "మెమొరీ ముగిసింది" (OOM) లోపంతో ప్రక్రియను ముగించింది.
కంటైనర్ ఎల్లప్పుడూ వనరుల అభ్యర్థనలో పేర్కొన్న దానికంటే ఎక్కువ వనరులను ఉపయోగించవచ్చు, కానీ పరిమితిలో పేర్కొన్న దానికంటే ఎక్కువ ఉపయోగించదు. ఈ విలువను సరిగ్గా సెట్ చేయడం కష్టం, కానీ ఇది చాలా ముఖ్యం.
ఆదర్శవంతంగా, సిస్టమ్‌లోని ఇతర ప్రక్రియలతో జోక్యం చేసుకోకుండా ఒక ప్రక్రియ యొక్క జీవిత చక్రంలో పాడ్ యొక్క వనరుల అవసరాలు మారాలని మేము కోరుకుంటున్నాము-అది పరిమితులను సెట్ చేయడం యొక్క లక్ష్యం.
దురదృష్టవశాత్తూ, ఏ విలువలను సెట్ చేయాలనే దానిపై నేను నిర్దిష్ట సూచనలను ఇవ్వలేను, కానీ మనం ఈ క్రింది నియమాలకు కట్టుబడి ఉంటాము:
- లోడ్ టెస్టింగ్ సాధనాన్ని ఉపయోగించి, మేము ట్రాఫిక్ యొక్క ప్రాథమిక స్థాయిని అనుకరిస్తాము మరియు పాడ్ వనరుల (మెమరీ మరియు ప్రాసెసర్) వినియోగాన్ని పర్యవేక్షిస్తాము.
- మేము పాడ్ అభ్యర్థనలను ఏకపక్షంగా తక్కువ విలువకు సెట్ చేసాము (అభ్యర్థనల విలువ కంటే దాదాపు 5 రెట్లు రిసోర్స్ పరిమితితో) మరియు గమనించండి. అభ్యర్థనలు చాలా తక్కువగా ఉన్నప్పుడు, ప్రక్రియ ప్రారంభించబడదు, తరచుగా గో రన్‌టైమ్ ఎర్రర్‌లకు కారణమవుతుంది.
పాడ్‌కు తగినన్ని వనరులు అందుబాటులో ఉన్న టార్గెట్ నోడ్ అవసరం కాబట్టి అధిక వనరుల పరిమితులు షెడ్యూలింగ్‌ను మరింత కష్టతరం చేస్తాయని గమనించండి.
మీరు చాలా ఎక్కువ వనరుల పరిమితితో తేలికపాటి వెబ్ సర్వర్‌ని కలిగి ఉన్న పరిస్థితిని ఊహించండి, 4 GB మెమరీని చెప్పండి. ఈ ప్రక్రియ క్షితిజ సమాంతరంగా స్కేల్ చేయవలసి ఉంటుంది మరియు ప్రతి కొత్త మాడ్యూల్ కనీసం 4 GB అందుబాటులో ఉన్న మెమరీతో నోడ్‌లో షెడ్యూల్ చేయబడాలి. అటువంటి నోడ్ ఉనికిలో లేనట్లయితే, ఆ పాడ్‌ను ప్రాసెస్ చేయడానికి క్లస్టర్ తప్పనిసరిగా కొత్త నోడ్‌ను పరిచయం చేయాలి, దీనికి కొంత సమయం పట్టవచ్చు. వేగవంతమైన మరియు మృదువైన స్కేలింగ్‌ని నిర్ధారించడానికి వనరుల అభ్యర్థనలు మరియు పరిమితుల మధ్య వ్యత్యాసాన్ని కనిష్టంగా ఉంచడం చాలా ముఖ్యం.
దశ రెండు: లైవ్‌నెస్ మరియు రెడీనెస్ పరీక్షలను సెటప్ చేయడం
ఇది కుబెర్నెట్స్ కమ్యూనిటీలో తరచుగా చర్చించబడే మరొక సూక్ష్మ అంశం. లైవ్‌నెస్ మరియు సంసిద్ధత పరీక్షలపై మంచి అవగాహన కలిగి ఉండటం ముఖ్యం, ఎందుకంటే అవి సాఫ్ట్‌వేర్ సజావుగా అమలు చేయడానికి మరియు పనికిరాని సమయాన్ని తగ్గించడానికి ఒక యంత్రాంగాన్ని అందిస్తాయి. అయినప్పటికీ, అవి సరిగ్గా కాన్ఫిగర్ చేయకపోతే మీ అప్లికేషన్‌కు తీవ్రమైన పనితీరు దెబ్బతినవచ్చు. రెండు నమూనాలు ఎలా ఉన్నాయో క్రింద సారాంశం ఉంది.
జీవనం కంటైనర్ నడుస్తుందో లేదో చూపిస్తుంది. అది విఫలమైతే, kubelet కంటైనర్‌ను చంపుతుంది మరియు దాని కోసం పునఃప్రారంభ విధానం ప్రారంభించబడుతుంది. కంటైనర్‌లో లైవ్‌నెస్ ప్రోబ్ అమర్చబడకపోతే, డిఫాల్ట్ స్థితి విజయవంతమవుతుంది - ఇది ఇలా చెబుతుంది .
లైవ్‌నెస్ ప్రోబ్‌లు చౌకగా ఉండాలి, అంటే అవి చాలా వనరులను వినియోగించకూడదు, ఎందుకంటే అవి తరచుగా నడుస్తాయి మరియు అప్లికేషన్ రన్ అవుతుందని కుబెర్నెట్‌లకు తెలియజేయాలి.
మీరు ప్రతి సెకనును అమలు చేయడానికి ఎంపికను సెట్ చేస్తే, ఇది సెకనుకు 1 అభ్యర్థనను జోడిస్తుంది, కాబట్టి ఈ ట్రాఫిక్‌ను నిర్వహించడానికి అదనపు వనరులు అవసరమవుతాయని గుర్తుంచుకోండి.
మా కంపెనీలో, డేటా (ఉదాహరణకు, రిమోట్ డేటాబేస్ లేదా కాష్ నుండి) పూర్తిగా యాక్సెస్ చేయబడనప్పటికీ, లైవ్‌నెస్ పరీక్షలు అప్లికేషన్ యొక్క ప్రధాన భాగాలను తనిఖీ చేస్తాయి.
మేము కేవలం 200 ప్రతిస్పందన కోడ్‌ని అందించే "ఆరోగ్యం" ముగింపు పాయింట్‌తో యాప్‌లను కాన్ఫిగర్ చేసాము. ఇది ప్రాసెస్ రన్ అవుతుందని మరియు అభ్యర్థనలను ప్రాసెస్ చేయగలదని సూచిస్తోంది (కానీ ఇంకా ట్రాఫిక్ లేదు).
పరీక్ష సంసిద్ధతను అభ్యర్థనలను అందించడానికి కంటైనర్ సిద్ధంగా ఉందో లేదో సూచిస్తుంది. సంసిద్ధత ప్రోబ్ విఫలమైతే, ఎండ్‌పాయింట్ కంట్రోలర్ పాడ్‌కు సంబంధించిన అన్ని సేవల ముగింపు పాయింట్‌ల నుండి పాడ్ యొక్క IP చిరునామాను తొలగిస్తుంది. ఇది కుబెర్నెట్స్ డాక్యుమెంటేషన్‌లో కూడా పేర్కొనబడింది.
అభ్యర్థనలను ఆమోదించడానికి అప్లికేషన్ సిద్ధంగా ఉందని సూచించే విధంగా వాటిని బ్యాకెండ్‌కు పంపాలి కాబట్టి సంసిద్ధత ప్రోబ్‌లు మరిన్ని వనరులను వినియోగిస్తాయి.
డేటాబేస్ను నేరుగా యాక్సెస్ చేయాలా వద్దా అనే దానిపై సమాజంలో చాలా చర్చలు జరుగుతున్నాయి. ఓవర్‌హెడ్ (తనిఖీలు తరచుగా నిర్వహించబడతాయి, కానీ సర్దుబాటు చేయబడతాయి) కారణంగా, డేటాబేస్ నుండి రికార్డ్‌లు తిరిగి వచ్చాయో లేదో ధృవీకరించిన తర్వాత మాత్రమే ట్రాఫిక్‌ను అందించడానికి సంసిద్ధతను లెక్కించాలని మేము నిర్ణయించుకున్నాము. చక్కగా రూపొందించబడిన సంసిద్ధత ట్రయల్స్ అధిక స్థాయి లభ్యతను నిర్ధారించాయి మరియు విస్తరణ సమయంలో పనికిరాని సమయాన్ని తొలగించాయి.
మీరు మీ అప్లికేషన్ యొక్క సంసిద్ధతను పరీక్షించడానికి డేటాబేస్ను ప్రశ్నించాలని నిర్ణయించుకుంటే, అది సాధ్యమైనంత తక్కువ ధరలో ఉందని నిర్ధారించుకోండి. ఈ అభ్యర్థనను తీసుకుందాం:
SELECT small_item FROM table LIMIT 1మేము ఈ రెండు విలువలను కుబెర్నెట్స్‌లో ఎలా కాన్ఫిగర్ చేస్తాము అనేదానికి ఇక్కడ ఒక ఉదాహరణ ఉంది:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
మీరు కొన్ని అదనపు కాన్ఫిగరేషన్ ఎంపికలను జోడించవచ్చు:
initialDelaySeconds- కంటైనర్ లాంచ్ మరియు నమూనాల ప్రారంభం మధ్య ఎన్ని సెకన్లు గడిచిపోతాయి.periodSeconds- నమూనా పరుగుల మధ్య నిరీక్షణ విరామం.timeoutSeconds- యూనిట్ అత్యవసరంగా పరిగణించబడే సెకన్ల సంఖ్య. రెగ్యులర్ సమయం ముగిసింది.failureThreshold- రీస్టార్ట్ సిగ్నల్ పాడ్‌కు పంపబడటానికి ముందు పరీక్ష వైఫల్యాల సంఖ్య.successThreshold- పాడ్ సిద్ధంగా ఉన్న స్థితికి వెళ్లే ముందు విజయవంతమైన ప్రోబ్‌ల సంఖ్య (ఒక వైఫల్యం తర్వాత, పాడ్ ప్రారంభమైనప్పుడు లేదా కోలుకున్నప్పుడు).
దశ మూడు: పాడ్ కోసం డిఫాల్ట్ నెట్‌వర్క్ విధానాలను సెటప్ చేయండి
కుబెర్నెటెస్ "ఫ్లాట్" నెట్‌వర్క్ టోపోగ్రఫీని కలిగి ఉంది; డిఫాల్ట్‌గా, అన్ని పాడ్‌లు ఒకదానితో ఒకటి నేరుగా కమ్యూనికేట్ చేస్తాయి. కొన్ని సందర్భాల్లో ఇది వాంఛనీయం కాదు.
ఒక సంభావ్య భద్రతా సమస్య ఏమిటంటే, దాడి చేసే వ్యక్తి నెట్‌వర్క్‌లోని అన్ని పాడ్‌లకు ట్రాఫిక్‌ను పంపడానికి ఒకే హాని కలిగించే అప్లికేషన్‌ను ఉపయోగించవచ్చు. భద్రతకు సంబంధించిన అనేక రంగాల మాదిరిగానే, ఇక్కడ కూడా కనీస హక్కు సూత్రం వర్తిస్తుంది. ఆదర్శవంతంగా, నెట్‌వర్క్ విధానాలు పాడ్‌ల మధ్య ఏ కనెక్షన్‌లు అనుమతించబడతాయో మరియు ఏది కాదో స్పష్టంగా పేర్కొనాలి.
ఉదాహరణకు, నిర్దిష్ట నేమ్‌స్పేస్ కోసం ఇన్‌కమింగ్ ట్రాఫిక్ మొత్తాన్ని తిరస్కరించే సాధారణ విధానం క్రింద ఉంది:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
ఈ కాన్ఫిగరేషన్ యొక్క విజువలైజేషన్:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
వివరములతో .
దశ నాలుగు: హుక్స్ మరియు init కంటైనర్‌లను ఉపయోగించి అనుకూల ప్రవర్తన
డెవలపర్‌ల కోసం పనికిరాని సమయం లేకుండా కుబెర్నెట్‌లకు విస్తరణలను అందించడం మా ప్రధాన లక్ష్యాలలో ఒకటి. అప్లికేషన్‌లను మూసివేయడానికి మరియు వారు ఉపయోగించిన వనరులను ఖాళీ చేయడానికి అనేక ఎంపికలు ఉన్నందున ఇది కష్టం.
ప్రత్యేక ఇబ్బందులు తలెత్తాయి . ఈ పాడ్‌లు వరుసగా అమర్చబడినప్పుడు, విజయవంతంగా పూర్తి కావడానికి ముందు క్రియాశీల కనెక్షన్‌లు తొలగించబడిందని మేము గమనించాము.
ఆన్‌లైన్‌లో విస్తృతమైన పరిశోధన తర్వాత, పాడ్‌ను ముగించే ముందు Nginx కనెక్షన్‌లు అయిపోయే వరకు Kubernetes వేచి ఉండదని తేలింది. ప్రీ-స్టాప్ హుక్‌ని ఉపయోగించి, మేము ఈ క్రింది కార్యాచరణను అమలు చేసాము మరియు పనికిరాని సమయాన్ని పూర్తిగా వదిలించుకున్నాము:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
మరియు ఇక్కడ nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
మరొక అత్యంత ఉపయోగకరమైన ఉదాహరణ, నిర్దిష్ట అప్లికేషన్‌ల ప్రారంభాన్ని నిర్వహించడానికి init కంటైనర్‌లను ఉపయోగించడం. మీరు అప్లికేషన్ ప్రారంభమయ్యే ముందు అమలు చేయాల్సిన రిసోర్స్-ఇంటెన్సివ్ డేటాబేస్ మైగ్రేషన్ ప్రాసెస్‌ని కలిగి ఉంటే ఇది చాలా ఉపయోగకరంగా ఉంటుంది. మీరు ప్రధాన అప్లికేషన్ కోసం అటువంటి పరిమితిని సెట్ చేయకుండా ఈ ప్రక్రియ కోసం అధిక వనరుల పరిమితిని కూడా పేర్కొనవచ్చు.
ప్రధాన మాడ్యూల్‌కు ఆ ఆధారాలను అందించే init కంటైనర్‌లోని రహస్యాలను యాక్సెస్ చేయడం మరొక సాధారణ పథకం, ఇది ప్రధాన అప్లికేషన్ మాడ్యూల్ నుండి రహస్యాలకు అనధికార ప్రాప్యతను నిరోధిస్తుంది.
ఎప్పటిలాగే, డాక్యుమెంటేషన్ నుండి కోట్ చేయండి: Init కంటైనర్లు కస్టమ్ కోడ్ లేదా యుటిలిటీలను సురక్షితంగా అమలు చేస్తాయి, లేకపోతే అప్లికేషన్ కంటైనర్ ఇమేజ్ భద్రతను తగ్గిస్తుంది. అనవసరమైన సాధనాలను వేరుగా ఉంచడం ద్వారా, మీరు అప్లికేషన్ కంటైనర్ చిత్రం యొక్క దాడి ఉపరితలాన్ని పరిమితం చేస్తారు.
దశ ఐదు: కెర్నల్‌ను కాన్ఫిగర్ చేస్తోంది
చివరగా, మరింత అధునాతన సాంకేతికత గురించి మాట్లాడుదాం.
కుబెర్నెటెస్ అనేది చాలా సౌకర్యవంతమైన ప్లాట్‌ఫారమ్, ఇది మీకు సరిపోయే విధంగా పనిభారాన్ని అమలు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. మా వద్ద చాలా అధిక-పనితీరు గల అప్లికేషన్‌లు ఉన్నాయి, అవి చాలా వనరులతో కూడుకున్నవి. విస్తృతమైన లోడ్ పరీక్షను నిర్వహించిన తర్వాత, Kubernetes డిఫాల్ట్ సెట్టింగ్‌లు అమలులో ఉన్నప్పుడు ఊహించిన ట్రాఫిక్ లోడ్‌ని నిర్వహించడానికి ఒక అప్లికేషన్ కష్టపడుతుందని మేము కనుగొన్నాము.
అయినప్పటికీ, నిర్దిష్ట పాడ్ కోసం మాత్రమే కెర్నల్ పారామితులను మార్చే విశేషమైన కంటైనర్‌ను అమలు చేయడానికి Kubernetes మిమ్మల్ని అనుమతిస్తుంది. గరిష్ట సంఖ్యలో ఓపెన్ కనెక్షన్‌లను మార్చడానికి మేము ఉపయోగించినవి ఇక్కడ ఉన్నాయి:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
ఇది మరింత అధునాతన సాంకేతికత, ఇది తరచుగా అవసరం లేదు. కానీ మీ అప్లికేషన్ భారీ లోడ్‌ను ఎదుర్కోవడంలో ఇబ్బంది పడుతుంటే, మీరు ఈ సెట్టింగ్‌లలో కొన్నింటిని ట్వీక్ చేయడానికి ప్రయత్నించవచ్చు. ఈ ప్రక్రియపై మరిన్ని వివరాలు మరియు విభిన్న విలువలను సెట్ చేయడం - ఎప్పటిలాగే .
ముగింపులో
కుబెర్నెట్స్ ఒక రెడీమేడ్ సొల్యూషన్‌గా కనిపించినప్పటికీ, మీ అప్లికేషన్‌లను సజావుగా అమలు చేయడానికి మీరు తీసుకోవలసిన కొన్ని కీలక దశలు ఉన్నాయి.
మీ కుబెర్నెట్స్ మైగ్రేషన్ అంతటా, "లోడ్ టెస్టింగ్ సైకిల్"ని అనుసరించడం చాలా ముఖ్యం: అప్లికేషన్‌ను ప్రారంభించండి, లోడ్ టెస్ట్ చేయండి, కొలమానాలు మరియు స్కేలింగ్ ప్రవర్తనను గమనించండి, ఆ డేటా ఆధారంగా కాన్ఫిగరేషన్‌ను సర్దుబాటు చేయండి, ఆపై మళ్లీ సైకిల్‌ను పునరావృతం చేయండి.
మీరు ఊహించిన ట్రాఫిక్ గురించి వాస్తవికంగా ఉండండి మరియు ముందుగా ఏ భాగాలు విరిగిపోతాయో చూడటానికి దాన్ని దాటి ముందుకు వెళ్లడానికి ప్రయత్నించండి. ఈ పునరావృత విధానంతో, విజయం సాధించడానికి జాబితా చేయబడిన కొన్ని సిఫార్సులు మాత్రమే సరిపోతాయి. లేదా దీనికి లోతైన అనుకూలీకరణ అవసరం కావచ్చు.
ఎల్లప్పుడూ ఈ ప్రశ్నలను మీరే ప్రశ్నించుకోండి:
- అప్లికేషన్‌లు ఎన్ని వనరులను వినియోగిస్తాయి మరియు ఈ వాల్యూమ్ ఎలా మారుతుంది?
- నిజమైన స్కేలింగ్ అవసరాలు ఏమిటి? యాప్ సగటున ఎంత ట్రాఫిక్‌ను నిర్వహిస్తుంది? పీక్ ట్రాఫిక్ గురించి ఏమిటి?
- సేవను క్షితిజ సమాంతరంగా స్కేల్ చేయడానికి ఎంత తరచుగా అవసరం? ట్రాఫిక్‌ని స్వీకరించడానికి ఎంత త్వరగా కొత్త పాడ్‌లను ఆన్‌లైన్‌లోకి తీసుకురావాలి?
- పాడ్‌లు ఎంత సరిగ్గా మూసివేయబడతాయి? ఇది అస్సలు అవసరమా? డౌన్‌టైమ్ లేకుండా విస్తరణను సాధించడం సాధ్యమేనా?
- మీరు భద్రతా ప్రమాదాలను ఎలా తగ్గించవచ్చు మరియు ఏదైనా రాజీపడే పాడ్‌ల నుండి నష్టాన్ని ఎలా పరిమితం చేయవచ్చు? ఏవైనా సేవలకు వాటికి అవసరం లేని అనుమతులు లేదా యాక్సెస్ ఉందా?
కుబెర్నెటెస్ అద్భుతమైన ప్లాట్‌ఫారమ్‌ను అందిస్తుంది, ఇది క్లస్టర్‌లో వేలకొద్దీ సేవలను అమలు చేయడానికి ఉత్తమ పద్ధతులను ఉపయోగించుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. అయితే, ప్రతి అప్లికేషన్ భిన్నంగా ఉంటుంది. కొన్నిసార్లు అమలుకు కొంచెం ఎక్కువ పని అవసరం.
అదృష్టవశాత్తూ, Kubernetes అన్ని సాంకేతిక లక్ష్యాలను సాధించడానికి అవసరమైన కాన్ఫిగరేషన్‌ను అందిస్తుంది. వనరుల అభ్యర్థనలు మరియు పరిమితులు, లైవ్‌నెస్ మరియు రెడీనెస్ ప్రోబ్స్, init కంటైనర్లు, నెట్‌వర్క్ విధానాలు మరియు కస్టమ్ కెర్నల్ ట్యూనింగ్ కలయికను ఉపయోగించి, మీరు ఫాల్ట్ టాలరెన్స్ మరియు వేగవంతమైన స్కేలబిలిటీతో పాటు అధిక పనితీరును సాధించవచ్చు.
ఇంకా ఏమి చదవాలి:
- .
- .
- .
మూలం: www.habr.com