Pam mae kubectl yn gweithio dros y VPN ond mae AKS yn stopio graddio

Rydych yn ychwanegu cyfeiriad cyhoeddus VPN y swyddfa at restr caniatáu gweinydd API AKS, ac mae kubectl yn gweithio. Wythnos yn ddiweddarach mae graddio node pool yn methu, ni all swydd CI gyrraedd y clwstwr, ac mae'r porth yn dangos gwall nad yw'n sôn dim am ystodau IP. Ni newidiodd neb y rhestr ganiatáu. Mae'r rheolaeth a alluogwyd gennych yn hidlydd IP cyhoeddus o flaen y gweinydd API, ac nid yw'n gwybod pwy sy'n galw, dim ond o ba gyfeiriad y daeth yr alwad. Mae'r VPN yn un cyfeiriad ymhlith sawl un y mae ar y clwstwr eu hangen, ac anaml yw'r un sy'n torri gyntaf.

Mae'r rhestr ganiatáu yn cyfateb i gyfeiriad, nid i berson

--api-server-authorized-ip-ranges mae'n cymryd blociau CIDR, nid defnyddwyr na grwpiau. Pan fydd cais datblygwr yn gadael y gweinydd VPN am Azure, y cyfeiriad ffynhonnell yn y gweinydd API yw allbwn cyhoeddus y gweinydd VPN. Felly mae pawb ar y VPN hwnnw'n rhannu un cofnod, ac mae unrhyw un y tu allan i'r VPN yn cael ei wrthod cyn i ddilysiad ddigwydd hyd yn oed.

Mae hynny hefyd yn golygu bod y cofnod yn derbyn mwy o bobl nag y bwriadwch. Mae contractwr â mynediad VPN, gliniadur personol ar yr un consentrator, a chyfrif wedi'i gyfaddawdu i gyd yn dod o'r un cyfeiriad. Nid yw awdurdodiad y clwstwr wedi newid, felly rheolaeth mynediad yn seiliedig ar rolau sy'n penderfynu o hyd beth y caiff y galwr ei wneud, ond nid rheolaeth hunaniaeth yw'r rhestr ganiatáu ac na ddylid byth ei disgrifio felly.

Y peth sy'n torri gyntaf fel arfer nid kubectl yw

Mae'r rhestr ganiatáu yn berthnasol i benbwynt cyhoeddus y gweinydd API, felly mae unrhyw beth y tu allan i'ch cyfeiriadau rhestredig yn stopio gweithio ar unwaith. Y dioddefwyr amlwg yw'r ail swyddfa heb lwybr VPN, rhedwr CI mewn piblinell a gynhelir, a gliniadur a anghofiodd gysylltu. Mae'r rhain yn hawdd eu hadnabod oherwydd bod rhywun yn aros.

Yr achos llai amlwg yw awtomeiddio a yrrir gan Azure neu eich offer eich hun. Mae rhai gweithrediadau a gychwynnir gan y platfform yn cyrraedd y gweinydd API o gyfeiriadau nad ydynt yn eich VPN, a phan fydd un ohonynt yn dechrau methu yn syth ar ôl tynhau'r rhestr, yr amseriad yw'r cliw. Peidiwch â chymryd bod y rhestr yn gyflawn oherwydd bod mynediad rhyngweithiol yn gweithio; gwiriwch beth mae'r nodwedd yn ei olygu ar gyfer eich rhanbarth a'ch tanysgrifiadau cyn dod i'r casgliad bod y clwstwr wedi torri.

Mae llofnod y methiant yn helpu. Os nad yw'r cais byth yn cyrraedd dilysiad, yr hidlydd yw'r achos. Os yw'n dilysu ac yna'n cael gwall caniatâd, mae'r hidlydd wedi gwneud ei waith a'r broblem yw rheolaeth mynediad yn seiliedig ar rolau, nad yw'r rhestr ganiatáu byth yn ei chyffwrdd.

Adeiladwch y rhestr gyfan mewn un gorchymyn

Mae'r paramedr diweddaru'n disodli'r rhestr gyfan yn lle ychwanegu cofnod, felly mae gorchymyn sy'n cario cyfeiriad y VPN yn unig yn gollwng yn dawel bopeth arall a oedd yno. Darllenwch y gwerth presennol yn gyntaf, cadwch ef, ac anfonwch yr undeb:

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

Defnyddiwch IP cyhoeddus neilltuedig ar gyfer y gweinydd VPN cyn dibynnu ar hyn. Mae cyfeiriad deinamig yn newid wrth ailgysylltu, ac mae pob newid yn cloi'r tîm allan o'r clwstwr yn dawel nes bod rhywun yn diweddaru'r rhestr o rwydwaith sy'n dal i fod yn caniatáu. Os oes gennych ddau bwynt allbwn VPN ar gyfer disodli, rhowch y ddau ar y rhestr, oherwydd nid oes gan yr hidlydd unrhyw syniad o lwybr a ffefrir.

Trefnwch y newid fel bod y cynnig cyntaf a ganiateir hefyd yn brawf. Cyhoeddwch y rhestr newydd, cymhwyswch hi, a chysylltwch o'r VPN ar unwaith; mae gwneud hynny yn y drefn arall yn gadael ffenestr lle na all neb gyrraedd y gweinydd API i drwsio gwall teipio mewn bloc CIDR.

Yr hyn na orchuddiodd y rhestr ganiatáu erioed

Nid yw'n gwneud y gweinydd API yn breifat. Mae clwstwr preifat yn defnyddio penbwynt preifat a DNS preifat, ac nid y rhestr ystodau awdurdodedig yw'r rheolaeth sy'n ei disodli. Nid yw chwaith yn newid yr hyn y caiff galwr a dderbyniwyd ei wneud, felly mae kubeconfig gweinyddol sydd wedi gollwng yn dal i weithio o unrhyw gyfeiriad a ganiateir. Triniwch y cyfrinair fel ffin diogelwch a'r rhestr fel cyfleustra rhwydwaith.

Nid oes ganddo unrhyw beth i'w wneud â llwythi gwaith. Mae Pods a Services yn parhau i redeg gyda'r rhestr yn weithredol, ac mae cyrraedd cymhwysiad dros y VPN yn broblem ar wahân: mae Service sydd â IP clwstwr yn unig yn dal i fod angen balansydd llwyth mewnol, ingress neu port-forward cyn y gall gliniadur ei agor. Mae cymysgu'r ddau ddyluniad yn cynhyrchu tocyn newid sy'n honni cyfyngu ar ddatblygwyr ac mewn gwirionedd yn cyfyngu ar ddim o'r cymhwysiadau.

Gwiriwch o'r ddwy ochr, yna rhedwch un gweithrediad go iawn

Profwch gyda chleient newydd ar y VPN a chleient y tu allan iddo. Dylai'r cynnig o'r tu allan gael ei wrthod yn y gweinydd API, nid wrth ddatrys enwau; os nad yw'r enw'n datrys, rydych yn profi DNS ac nid ydych wedi dysgu dim am yr hidlydd. Yna rhedwch weithrediad nad yw'n alwad kubectl ryngweithiol, fel graddio node pool neu wiriant uwchraddio, a chadarnhewch ei fod yn cwblhau yn lle tybio y bydd.

Cadwch werth y rhestr flaenorol wedi'i gofnodi wrth ymyl y newid, ac ail-ddarllenwch y gwerth effeithiol ar ôl y diweddariad yn lle ymddiried yn y gorchymyn a deipiwyd. Mae dogfennaeth AKS ar ystodau IP awdurdodedig yn rhestru'r paramedrau a gynhelir a'r gofynion platfform sy'n perthyn i'r un rhestr, sef y rhan y mae'r rhan fwyaf o ddisgrifiadau tocynnau yn ei hepgor.