Pod, nyje apo klaster: çfarë ridrejton vërtet një sidecar VPN

Një sidecar VPN brenda një Pod Kubernetes duket si një VPN në nivel hosti me sjellje më të mirë, dhe ngjashmëria mbaron në kufirin e hapësirës së emrave. Kontejnerët në një Pod ndajnë hapësirën e emrave të rrjetit, përfshirë hapësirën e adresave dhe porteve, kështu që një sidecar që instalon rrugë dhe politikë ndryshon vërtet se ku shkojnë paketat e aplikacionit. Për Pod të tjera në nyje nuk ndryshon asgjë, dhe nuk prek stakun e vetë nyjes nëse nuk e konfiguroni ashtu. Kuptimi i saktë i këtij kufiri përcakton si atë që mund të vendosni, ashtu edhe atë që duhet të testoni. Seksionet më poshtë e ndjekin këtë nga hapësira e emrave drejt jashtë.

Hapësirë emrash e ndarë, pasoja të ndara

Dy kontejnerë në një Pod komunikojnë përmes loopback dhe shohin të njëjtat ndërfaqe, dhe kjo është arsyeja pse modeli i sidecar funksionon fare: aplikacioni nuk ka nevojë të dijë se ekziston një tunel, sepse rruga që zgjidh është instaluar në hapësirën e emrave që përdor. E njëjta veti do të thotë që gabimet e sidecar janë gabimet e aplikacionit. Një rrugë që kap shumë, ose një ndryshim DNS që tregon drejt një zgjidhësi brenda tunelit, zbatohet menjëherë për çdo proces në atë Pod. Në një hapësirë emrash të ndarë nuk ka rrugëzim sipas kontejnerit, kështu që një sidecar nuk mund të kufizohet në një proces.

Ky është mekanizmi që duhet mbajtur parasysh gjatë rishikimit: rrezja e ndikimit është Pod, jo nyja dhe jo klasteri.

Ku sidecar nuk arrin

Pod të tjera mbajnë hapësirat e tyre të emrave dhe rrugëzimin e tyre, kështu që një ngarkesë pune që ka nevojë për të njëjtën dalje ka nevojë për të njëjtin sidecar ose, në vend të kësaj, për një dizajn në nivel nyje. Edhe trafiku i nyjes është jashtë hapësirës së emrave të Pod, dhe Pod me rrjet hosti heqin dorë qëllimisht plotësisht nga ky izolim. Nëse e ekzekutoni sidecar me rrjet hosti për të arritur diçka të përshtatshme, e keni zgjeruar shtrirjen nga një Pod në të gjithë nyjen dhe duhet ta thoni me zë të lartë.

Trafiku drejt shërbimeve të klasterit është surpriza tjetër e zakonshme. Një rrugë e gjerë e parazgjedhur brenda Pod mund të kapë kërkesa të destinuara për serverin API ose një shërbim ClusterIP, të cilat më pas dështojnë në mënyra që duken si tunel i thyer.

Plani i rrugëve: intervalet Pod, shërbim, nyje dhe VPN

Shkruani katër intervalet dhe kontrolloni mbivendosjen përpara se të vendosni çdo gjë: CIDR e Pod, CIDR e shërbimit, adresat e nyjes dhe destinacionet prapa VPN. Mbivendosja midis intervaleve private të VPN dhe hapësirës së vetë klasterit nuk është e rrallë, dhe rruga e parazgjedhur është zgjidhja e gabuar për të. Plani i rrugëve i përket të njëjtit depo si manifesti, sepse klasteri i ardhshëm mund të japë intervale Pod dhe shërbimi krejt të ndryshme.

DNS është pjesë e planit dhe jo shqetësim i veçantë. Një sidecar që rishkruan konfigurimin e zgjidhësit mund të thyejë zbulimin e shërbimeve brenda klasterit ndërsa kërkimet e jashtme funksionojnë përsosurisht.

Nisja dhe dështimi janë gjendje të qarta

Një proces sidecar në punë nuk është politikë daljeje. Vendosni çfarë trafiku mund të rrjedhë përpara se tuneli të jetë gati dhe çfarë ndodh nëse vdes më pas, pastaj zbatojeni atë vendim: një sondë që kontrollon kontejnerin e aplikacionit, një politikë rrjeti që refuzon si parazgjedhje, ose të dyja. Pa njërën prej tyre aplikacioni niset, zgjidh dhe dërgon trafik jashtë rrugës normale të nyjes ndërsa tuneli ende po lidhet.

Ai boshllëk është i shkurtër në një klaster të shëndoshë dhe i përhershëm në një të prishur, dhe pikërisht kjo veti është ajo që preferon një sulmues ose një rrjedhje aksidentale e të dhënave.

Lidhni rendin me një test dështimi. Vritni sidecar dhe konfirmoni se aplikacioni humbet daljen e synuar në vend që të tërhiqet në heshtje.

Aftësitë, politikat dhe testimi nga kontejneri i aplikacionit

Dhënia e aftësive të nevojshme për të krijuar ndërfaqe dhe për të ndryshuar rrugët është një vendim privilegjesh, dhe një privilegj i përshtatshëm për një Pod të izoluar nuk është automatikisht i përshtatshëm në stakun e nyjes. Përdorni mekanizmat e politikës së rrjetit dhe të sigurisë që klasteri mbështet, dhe mos supozoni se çdo implementim CNI ose politike e trajton një ndërfaqe VPN në të njëjtën mënyrë; dallimet shfaqen pikërisht në rastet e dështimit që ju interesojnë.

Testoni nga kontejneri i vërtetë i aplikacionit, me kërkesa të reja drejt një destinacioni privat, një shërbimi të klasterit dhe internetit publik. Një test nga sidecar provon se tuneli funksionon, jo se aplikacioni arrin atë që i nevojitet.

Dokumentoni supozimet e rrjetit të klasterit pranë konfigurimit të VPN. Zhvendosja e ngarkesës së punës në një klaster tjetër është atëherë një ushtrim në kontrollimin e planit të rrugëve dhe jo një ndryshim imazhi që ndalon në heshtje së funksionuari.