kubectl VPN ద్వారా పని చేస్తుంది కానీ AKS స్కేలింగ్ ఆగిపోతుంది ఎందుకు

మీరు కార్యాలయ VPN యొక్క పబ్లిక్ చిరునామాను AKS API సర్వర్ అనుమతి జాబితాలో జోడిస్తారు, kubectl పని చేస్తుంది. ఒక వారం తర్వాత node pool స్కేల్-అప్ విఫలమవుతుంది, CI పని క్లస్టర్ను చేరుకోలేదు, పోర్టల్ IP శ్రేణుల గురించి ఏమీ చెప్పని లోపాన్ని చూపిస్తుంది. అనుమతి జాబితాను ఎవరూ మార్చలేదు. మీరు ప్రారంభించిన నియంత్రణ API సర్వర్ ముందున్న పబ్లిక్ IP ఫిల్టర్, ఎవరు కాల్ చేస్తున్నారో దానికి తెలియదు, కాల్ ఏ చిరునామా నుండి వచ్చిందో మాత్రమే తెలుసు. VPN క్లస్టర్కు అవసరమైన అనేక చిరునామాలలో ఒకటి, మొదట విరిగేది అదే కావడం అరుదు.

అనుమతి జాబితా చిరునామాతో సరిపోతుంది, వ్యక్తితో కాదు

--api-server-authorized-ip-ranges ఇది CIDR బ్లాక్లను తీసుకుంటుంది, వినియోగదారులు లేదా సమూహాలను కాదు. డెవలపర్ అభ్యర్థన VPN సర్వర్ను విడిచి Azure వైపు వెళ్ళినప్పుడు, API సర్వర్ వద్ద మూల చిరునామా VPN సర్వర్ యొక్క పబ్లిక్ ఎగ్రెస్. అందువల్ల ఆ VPNలో ప్రతి ఒక్కరూ ఒకే నమోదును పంచుకుంటారు, VPN వెలుపల ఉన్న ఎవరైనా ప్రామాణీకరణ జరగక ముందే తిరస్కరించబడతారు.

దీని అర్థం ఈ నమోదు మీరు భావించినదానికంటే ఎక్కువ మందిని అనుమతిస్తుంది. VPN ప్రాప్యత ఉన్న కాంట్రాక్టర్, అదే కన్సంట్రేటర్పై ఉన్న వ్యక్తిగత ల్యాప్టాప్, మరియు హ్యాక్ చేయబడిన ఖాతా అందరూ ఒకే చిరునామా నుండి వస్తారు. క్లస్టర్ అధికారం మారలేదు, కాబట్టి పాత్ర-ఆధారిత ప్రాప్యత నియంత్రణ ఇప్పటికీ కాల్ చేసేవాడు ఏమి చేయగలడో నిర్ణయిస్తుంది, కానీ అనుమతి జాబితా గుర్తింపు నియంత్రణ కాదు మరియు అలా ఎప్పుడూ వర్ణించకూడదు.

మొదట విరిగేది సాధారణంగా kubectl కాదు

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

తక్కువ స్పష్టమైన సందర్భం Azure లేదా మీ స్వంత సాధనాలు నడిపే ఆటోమేషన్. ప్లాట్ఫారమ్ ప్రారంభించిన కొన్ని కార్యకలాపాలు మీ VPN కాని చిరునామాల నుండి API సర్వర్ను చేరుకుంటాయి, జాబితా కఠినం చేసిన వెంటనే వాటిలో ఒకటి విఫలమవడం ప్రారంభిస్తే, సమయమే సూచన. ఇంటరాక్టివ్ ప్రాప్యత పని చేస్తుందని జాబితా పూర్తయిందని భావించవద్దు; క్లస్టర్ పాడైందని నిర్ణయించే ముందు మీ ప్రాంతం మరియు సబ్స్క్రిప్షన్లకు ఈ ఫీచర్ ఏమి అవసరమో తనిఖీ చేయండి.

విఫలత యొక్క సంతకం సహాయపడుతుంది. అభ్యర్థన ఎప్పుడూ ప్రామాణీకరణను చేరుకోకపోతే, అది ఫిల్టర్. అది ప్రామాణీకరించబడి తర్వాత అనుమతి లోపం వస్తే, ఫిల్టర్ తన పని చేసింది మరియు సమస్య పాత్ర-ఆధారిత ప్రాప్యత నియంత్రణలో ఉంది, దానిని అనుమతి జాబితా ఎప్పుడూ తాకదు.

మొత్తం జాబితాను ఒకే ఆదేశంలో నిర్మించండి

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

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

దీనిపై ఆధారపడే ముందు VPN సర్వర్ కోసం రిజర్వ్ చేసిన పబ్లిక్ IPని ఉపయోగించండి. డైనమిక్ చిరునామా తిరిగి కనెక్ట్ అయ్యేటప్పుడు మారుతుంది, మరియు ప్రతి మార్పు ఇంకా అనుమతించబడిన నెట్వర్క్ నుండి ఎవరైనా జాబితాను నవీకరించే వరకు జట్టును క్లస్టర్ నుండి నిశ్శబ్దంగా లాక్ చేస్తుంది. రిడండెన్సీ కోసం రెండు VPN ఎగ్రెస్ పాయింట్లు ఉంటే రెండింటినీ జాబితా చేయండి, ఎందుకంటే ఫిల్టర్కు ఇష్టపడే మార్గం అనే భావన లేదు.

మొదటి అనుమతించబడిన ప్రయత్నమే పరీక్షగా ఉండేలా మార్పును క్రమబద్ధీకరించండి. కొత్త జాబితాను ప్రకటించండి, వర్తించండి, మరియు వెంటనే VPN నుండి కనెక్ట్ అవ్వండి; వ్యతిరేక క్రమంలో చేస్తే CIDR బ్లాక్లోని టైపోను సరిచేయడానికి ఎవరూ API సర్వర్ను చేరుకోలేని విండో మిగిలిపోతుంది.

అనుమతి జాబితా ఎప్పుడూ కవర్ చేయనిది

ఇది API సర్వర్ను ప్రైవేట్గా చేయదు. ప్రైవేట్ క్లస్టర్ ప్రైవేట్ ఎండ్పాయింట్ మరియు ప్రైవేట్ DNSని ఉపయోగిస్తుంది, మరియు అధికృత-శ్రేణి జాబితా దానిని భర్తీ చేసే నియంత్రణ కాదు. లోపలికి తీసుకున్న కాల్ చేసేవాడు ఏమి చేయగలడో కూడా ఇది మార్చదు, కాబట్టి లీక్ అయిన అడ్మిన్ kubeconfig ఏదైనా అనుమతించబడిన చిరునామా నుండి ఇప్పటికీ పని చేస్తుంది. ఆధారాలను భద్రతా హద్దుగా, జాబితాను నెట్వర్క్ సౌలభ్యంగా పరిగణించండి.

దీనికి వర్క్లోడ్లతో ఎటువంటి సంబంధం లేదు. జాబితా ప్రారంభించి ఉన్నప్పుడు కూడా Pods మరియు Services నడుస్తూనే ఉంటాయి, మరియు VPN ద్వారా అప్లికేషన్ను చేరుకోవడం వేరే సమస్య: కేవలం క్లస్టర్ IP ఉన్న Serviceకు ల్యాప్టాప్ తెరవగలిగే ముందు ఇంకా అంతర్గత లోడ్ బ్యాలెన్సర్, ingress లేదా port-forward అవసరం. ఈ రెండు డిజైన్లను కలపడం డెవలపర్లను పరిమితం చేస్తున్నట్టు చెప్పుకుని వాస్తవంగా అప్లికేషన్ల గురించి ఏమీ పరిమితం చేయని మార్పు టికెట్ను సృష్టిస్తుంది.

రెండు వైపులా ధృవీకరించండి, తర్వాత ఒక నిజమైన కార్యకలాపాన్ని అమలు చేయండి

VPNలో కొత్త క్లయింట్ మరియు దాని వెలుపల ఉన్న క్లయింట్తో పరీక్షించండి. బయటి ప్రయత్నం పేరు పరిష్కారం వద్ద కాదు, API సర్వర్ వద్ద తిరస్కరించబడాలి; పేరు పరిష్కారం కాకపోతే, మీరు DNSను పరీక్షిస్తున్నారు మరియు ఫిల్టర్ గురించి ఏమీ నేర్చుకోలేదు. తర్వాత ఇంటరాక్టివ్ kubectl కాల్ కాని కార్యకలాపాన్ని అమలు చేయండి, ఉదాహరణకు node pool స్కేల్ లేదా అప్గ్రేడ్ తనిఖీ, మరియు జరుగుతుందని ఊహించడం బదులు పూర్తయిందని నిర్ధారించండి.

మార్పు పక్కన మునుపటి జాబితా విలువను నమోదు చేయండి, మరియు టైప్ చేసిన ఆదేశాన్ని నమ్మడం బదులు అప్డేట్ తర్వాత ప్రభావవంతమైన విలువను మళ్లీ చదవండి. AKS అధికృత IP శ్రేణుల పత్రం మద్దతు ఉన్న పరామితులను మరియు అదే జాబితాలో ఉండాల్సిన ప్లాట్ఫారమ్ అవసరాలను జాబితా చేస్తుంది, చాలా టికెట్ వివరణలు వదిలేసే భాగం ఇదే.