Pod, nodo aŭ klastero: kion VPN-flanka ujo efektive rerutas

VPN-flanka ujo en Kubernetes Pod aspektas kiel VPN ĉe gastiga nivelo kun pli bonaj manieroj, kaj la simileco finiĝas ĉe la limo de la nomspaco. Ujoj en unu Pod kunhavas la retan nomspacon, inkluzive de la adresa kaj porda spaco, do flanka ujo, kiu instalas itinerojn kaj politikon, vere ŝanĝas kien iras la pakaĵoj de la aplikaĵo. Ĝi ŝanĝas nenion por la aliaj Podoj sur la nodo, kaj ĝi ne tuŝas la propran stakon de la nodo, krom se vi agordas ĝin tiel. Ĝuste regi tiun limon decidas kaj kion vi povas surlokigi kaj kion vi devas testi. La sekvaj sekcioj sekvas ĝin de la nomspaco eksteren.

Komuna nomspaco, komunaj sekvoj

Du ujoj en Pod interparolas tra loopback kaj vidas la samajn interfacojn, kaj tial la ŝablono de flanka ujo entute funkcias: la aplikaĵo ne bezonas scii, ke tunelo ekzistas, ĉar la itinero, kiun ĝi solvas, estis instalita en la nomspaco, kiun ĝi uzas. La sama eco signifas, ke la eraroj de la flanka ujo estas eraroj de la aplikaĵo. Itinero, kiu kaptas tro multe, aŭ DNS-ŝanĝo, kiu montras al solvilo ene de la tunelo, validas tuj por ĉiu procezo en tiu Pod. En komuna nomspaco ne ekzistas enkursigo po ujo, do flanka ujo ne povas esti limigita al unu procezo.

Tio estas la mekanismo memorenda dum revizio: la efika radiuso estas la Pod, ne la nodo kaj ne la klastero.

Kien la flanka ujo ne atingas

Aliaj Podoj tenas siajn proprajn nomspacojn kaj sian propran enkursigon, do laborŝarĝo, kiu bezonas la saman eliron, bezonas la saman flankan ujon aŭ anstataŭe dizajnon ĉe noda nivelo. Ankaŭ la trafiko de la nodo estas ekster la nomspaco de la Pod, kaj Podoj kun gastiga reto konscie tute retiriĝas de ĉi tiu izolado. Se vi rulas la flankan ujon kun gastiga reto por atingi ion oportunan, vi vastigis la amplekson de unu Pod al la tuta nodo kaj devus diri tion laŭte.

Trafiko al klasteraj servoj estas la alia ordinara surprizo. Larĝa implicita itinero ene de la Pod povas kapti petojn destinitajn al la API-servilo aŭ al ClusterIP-servo, kaj ili poste malsukcesas tiel, ke ŝajnas, ke la tunelo estas rompita.

Itinera plano: Podaj, servaj, nodaj kaj VPN-aj kampoj

Skribu la kvar kampojn kaj kontrolu ilin por interkovro antaŭ ol surlokigi ion ajn: Pod-CIDR, serva CIDR, nodaj adresoj kaj la celoj malantaŭ la VPN. Interkovro inter la privataj kampoj de la VPN kaj la propra spaco de la klastero ne estas malofta, kaj implicita itinero estas la malĝusta solvo por ĝi. La itinera plano apartenas al la sama deponejo kiel la manifesto, ĉar la sekva klastero povas doni tute aliajn Podajn kaj servajn kampojn.

DNS estas parto de la plano, ne aparta zorgo. Flanka ujo, kiu reskribas la agordon de la solvilo, povas rompi servan malkovron ene de la klastero dum eksteraj serĉoj funkcias perfekte.

Starto kaj paneo estas eksplicitaj statoj

Rulanta flanka procezo ne estas elira politiko. Decidu, kiu trafiko rajtas flui antaŭ ol la tunelo pretas kaj kio okazas, se ĝi mortas poste, poste efektivigu tiun decidon: sondilo, kiu baras la ujon de la aplikaĵo, reta politiko, kiu implicite rifuzas, aŭ ambaŭ. Sen unu el ili la aplikaĵo startas, solvas kaj sendas trafikon ekster la normalan vojon de la nodo dum la tunelo ankoraŭ konektiĝas.

Tiu breĉo estas mallonga en sana klastero kaj daŭra en rompita, kaj ĝuste tiun econ preferas atakanto aŭ hazarda datumliko.

Parigu la ordigon kun pana testo. Mortigu la flankan ujon kaj konfirmu, ke la aplikaĵo perdas sian celitan eliron anstataŭ silente retrofali.

Kapabloj, politikoj kaj testado el la aplikaĵa ujo

Doni la kapablojn necesajn por krei interfacojn kaj ŝanĝi itinerojn estas decido pri privilegioj, kaj privilegio taŭga por izolita Pod ne aŭtomate taŭgas sur la noda stako. Uzu la retajn kaj sekurecajn politikajn mekanismojn subtenatajn de la klastero, kaj ne supozu, ke ĉiu CNI- aŭ politika efektivigo traktas VPN-interfacon idente; la diferencoj montriĝas ĝuste en la paneaj kazoj, kiuj gravas al vi.

Testu el la reala aplikaĵa ujo, per novaj petoj al privata celo, klastera servo kaj la publika interreto. Testo el la flanka ujo pruvas, ke la tunelo funkcias, ne ke la aplikaĵo atingas tion, kion ĝi bezonas.

Dokumentu la retajn supozojn de la klastero apud la VPN-agordo. Movi la laborŝarĝon al alia klastero tiam estas ekzerco pri kontrolado de la itinera plano anstataŭ bilda ŝanĝo, kiu silente ĉesas funkcii.