Pod IP, ClusterIP aŭ interna ŝarĝbalancilo por VPN-uzantoj

Kun la VPC CNI, Pod povas teni adreson el la VPC, kaj VPN-uzanto kun la ĝusta vojo povas atingi ĝin rekte. Tio igas rektan aliron al la Pod aspekti kiel la plej simpla opcio, kaj ĝi estas, ĝis la Pod estas anstataŭigita. La adreso, kiun uzanto memoras, devus aparteni al la aplikaĵo, ne al kopio. Kompari la tri enirojn reduktiĝas al tio, kiu objekto posedas la adreson kaj kio devas daŭre funkcii, kiam la laborŝarĝo translokiĝas.

Elektu unue laŭ vivociklo, poste laŭ tio, kion la reto devas fari por igi la eniron atingebla.

Tri eniroj, tri vivocikloj

Pod IP apartenas al Pod: ĝi estas atribuita kun ĝi kaj liberigita, kiam ĝi finiĝas. ClusterIP apartenas al Service kaj estas virtuala, ĝi havas sencon nur tie, kie ekzistas la serva enkursigado de la klastro. Internan ŝarĝbalancilon posedas nuba rimedo, kiun la regilo de la klastro programadas per backend-oj. Tiuj posedmodeloj antaŭdiras la fiaskon, kiun vi ricevos: malaktuala adreso, neatingebla nomo aŭ malaktuala aro da backend-oj.

Skribu la komparon antaŭ ol elekti. Kiam la posedanto kaj la fiasko estas nomitaj, la elekto kutime faras sin mem.

Rekta aliro al la Pod: utila, provizora

Rekta aliro estas vere utila por kontrolita testado: unu administranto, unu mallonga sesio, unu specifa pordo. Sed ĝi estas malbona kontrakto por uzantoj, ĉar la adreso estas efektiviga detalo, kiu ŝanĝiĝas ĉe ĉiu deplojo. Kaj noti unu en vikio estas la maniero, kiel funkcianta servo fariĝas onidiro.

Ĝi ankaŭ invitas larĝajn regulojn. Permeso por unu administranto atingi unu Pod ne estas permeso por ĉiu adreso en la subreto de la nodo, kaj kutime la dua estas skribata.

ClusterIP: limigita al la klastro laŭ dizajno

ClusterIP funkcias ĉar la datumplano de la klastro programadas enkursigadon por ĝi ene de la klastro. De tekkomputilo en la VPN la adreso signifas nenion, krom se io intence elmetas ĝin. Nomo finiĝanta per svc.cluster.local apartenas al la DNS de la klastro, do kopii ĝin al kliento kun alia solvilo produktas nomon, kiu ne ekzistas, anstataŭ enkursigadan eraron.

ClusterIP restas la ĝusta eniro por alvokantoj ene de la klastro, inkluzive de aliaj laborŝarĝoj. Ĝi simple ne estas publikiga mekanismo por uzantoj ekster la enkursigada domajno de la klastro.

Interna ŝarĝbalancilo: la publikigita vojo

Interna ŝarĝbalancilo donas al vi stabilan privatan adreson kaj nomon, al kiu via propra zono povas montri, dum la regilo tenas la aron da backend-oj aktuala, kiel priskribas la gvidilo de EKS pri ŝarĝbalancado. Tiu estas la eniro, kiu postvivas ordinaran anstataŭigon de Pod sen ke iu redaktu dokumenton. Ĝi kostas nuban rimedon, agordon de regilo kaj vojon el la VPN, kaj ĝuste tiujn partojn homoj subtaksas.

Uzu la regilan modelon, kiun la klastro efektive funkciigas. Adnotaĵoj skribitaj por unu integriĝo ne validas por alia.

Kiu estas la fonta adreso

Sekurecaj grupoj vidas la fonton, kiu alvenas al ilia limo, kaj tio povas esti la konektita kliento aŭ tradukita adreso depende de la VPN kaj de la ŝarĝbalanca vojo. Sur nodoj bazitaj sur EC2, ordinaraj Pod-oj de VPC CNI heredas defaŭlte la grupojn de la ENI de la nodo, dum subtenataj agordoj povas alkroĉi grupojn specifajn al Pod. Skribu regulojn por la dokumentita vojo anstataŭ por supozita tekkomputila adreso.

Tenu la propran aŭskultilon kaj aŭtentikigon de la aplikaĵo kiel apartajn kontrolojn. Reta regulo, kiu permesas la fluon, ne estas rajtiga decido kaj ne devus esti traktata kiel tia.

Kion doni al uzantoj

Donu al uzantoj servan nomon, ne adreson. Publikigu la nomon en la privata zono, montru ĝin al la interna eniro, kaj poste testu anstataŭigante backend-Pod dum kliento tenas la saman nomon malfermita. Tiu ekzerco testas la econ, kiu gravas: atingi la saman aplikaĵon post rutina deplojo.

Tenu rektan aliron al la Pod kiel dokumentitan operacian escepton kun propra amplekso, malproksime de la instrukcioj por uzantoj.