Jarri EKS API VPN baten atzean: eragiketen ordena
Gaitu endpoint pribatua, frogatu kubectl hara iritsi dela eta gero itxi publikoa. Runbook etapakakoa, komandoekin eta urrats bakoitzaren arteko egiaztapenekin.
Aldaketa honen bertsio arriskutsua endpoint-a aldatzen duen eta administratzaile guztiak aldi berean kanpoan uzten dituen komando bakarra da. Bertsio seguruak bi bideak irekita mantentzen ditu, pribatuak VPN-tik funtzionatzen duela frogatzen du, eta soilik orduan erretiratzen du endpoint publikoa. Suposatu existitzen den kluster bat, haren VPC-ra onartutako tunel bat eta jada funtzionatzen duen kubeconfig bat; zeregina Kubernetes API-rako sarbide pribatua da, ez nodo pribatuak eta ez baimen-eredu berria. Beheko urrats bakoitzak modu seguruan huts egin dezakezun egiaztapen bat du.
1. Inbentariatu endpoint-a eta gorde itzultzeko bidea
Erregistratu uneko egoera aldatu aurretik, CIDR baimenduen zerrenda publikoa eta klusterraren segurtasun-taldea barne. Bi horiek izango dira konparatuko dituzunak zerbait funtzionatzeari uzten dionean, eta baimenduen zerrenda ere zure atzeranzko bidea da bide pribatua okerra dela erakusten bada.
aws eks describe-cluster --region REGION --name CLUSTER \
--query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'
REGION eta CLUSTER leku-markak dira hemen. Ohartu zer irakurtzen duen bandera pribatuak orain, pribatua jada gaituta duen kluster batek lehen urrats desberdina behar baitu inoiz izan ez duenak baino. Mantendu gutxienez administrazio-bide onartu bat irekita trantsizioan zehar; kluster bera eskuragarri egotearen mende dagoen VPN bat ez da berreskuratze-bide bat.
2. Gaitu sarbide pribatua sare-bidea prest dagoenean
Bandera piztea erdia erraza da. Tunelek endpoint-aren helbide pribatuetarako bide bat behar du, eta klusterraren segurtasun-taldeak VPN-ak benetan aurkezten duen iturritik TCP 443 behar du. Client VPN elkarte batek, site-to-site ate-bide batek eta peeratutako VPC batek iturburu-helbide desberdinak aurkez ditzakete, beraz, erabili inplementatu duzun eredua, barruti pribatu orokor baten ordez.
aws eks update-cluster-config --region REGION --name CLUSTER \
--resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true
aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID
Eguneratzea asinkronoa da. Galdetu eguneratze-id-a arrakasta adierazi arte, segundo kopuru finko bat itxaron eta suposatu beharrean. Utzi nodoen eta kontrol-planoaren trafikoa bakean hori egiten duzun bitartean: klusterraren segurtasun-talde osoa zure ordenagailu eramangarrirako arau batekin ordezkatzea da datu-plano funtzionatzen duena bigarren gertakari bihurtzeko modua.
EKS endpoint-en dokumentazioa behin oso-osorik irakurtzea merezi du, pribatuko sarbidea soilik VPC-tik edo konektatutako sare batetik etor daitekeela dioelako. Esaldi hori da migrazio hau posible izateko arrazoi osoa, eta hori da hurrengo urratsa existitzeko arrazoia ere.
3. Frogatu lan-estazioak bide pribatua erabili duela
Bi endpoint-ak gaituta, kubectl get ns arrakastatsu batek ez du ezer frogatzen zeinek erantzun zuen. Ebatzi endpoint-aren ostalari-izena eta egiaztatu lortu duzun helbidea barruti pribatukoa edo publikoa den. Zure konektatutako sareak ez badu ikuspegi pribatua DNS bidez jasotzen, komandoak arrakasta izango du endpoint publikoaren bidez eta bide publikoa froga faltsuetan oinarrituta erretiratuko duzu. Hau da migrazio hau gaizki ateratzeko modurik ohikoena, eta arrakastaren itxura zehatza du.
nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s
Mantendu ostalari-izena eta ziurtagiriaren balidazioa dauden bezala. kubeconfig-en IP pribatu bat jartzea eta TLS egiaztapena saltatzea ez da aldaketa-erregistroan deskribatu duzun migrazioa, eta berriro huts egingo du endpoint-a biratzen den unean.
4. Erretiratu sarbide publikoa nahita
Bide pribatua frogatu eta berreskuratze-fluxua onartu ondoren, itxi endpoint publikoa. Hau benetako aldaketa da, ez aurrebista, beraz exekutatu benetan pentsatzen duzun kontuaren eta ezarpenen aurka.
aws eks update-cluster-config --region REGION --name CLUSTER \
--resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true
Soilik pribatua den moduan, DNS izen publikoak endpoint-aren helbide pribatuetara ebazten du VPC-ren barrutik, beraz ebazpena eta irisgarritasuna ez dira gauza bera izateari uzten diote. Helbide publikoan oinarritzen zen guztiak, CI exekutzaileak edo beste sare bateko ordenagailu eramangarri bat barne, orain bere sarrera-bidea behar du.
5. Mantendu sare-politika eta identitate-politika bereizita
Sarbide publikoko CIDR zerrendak endpoint publikoa soilik gobernatzen du. Ez du endpoint pribatua mugatzen; hura klusterraren segurtasun-taldeak eta konektatutako sarearen politikak mugatzen dute. Endpoint publikoa mantentzen baduzu, haren baimenduen zerrendak zure API bezeroek eta nodeek benetan erabiltzen duten irteera publikoarekin bat etorri behar du; VPN pool-eko helbidea gutxitan da iturri hori.
Horietako ezerk ez du IAM edo Kubernetes RBAC aldatzen. Endpoint-ezarpenak administrazio-ekintza dira, eta erabiltzaile arruntek ez lukete muga biguntzeko baimenik jaso behar API-ra iristeko soilik. Idatzi azken egoera, data eta berreskuratze-bidea runbookean, eta gero probatu berreskuratze-bidea behin, oraindik erraza den bitartean.