Pod IP, ClusterIP o panloob na load balancer para sa mga user ng VPN
Ang Pod IP ay maruruta sa VPN hanggang mapalitan ang Pod. Paghambingin ang direktang access sa Pod, ClusterIP at isang panloob na balancer, at ang gastos ng bawat isa sa iyo.
Sa VPC CNI, ang isang Pod ay maaaring may address mula sa VPC, at ang user ng VPN na may tamang ruta ay maaaring maabot ito nang direkta. Kaya’t ang direktang access sa Pod ay mukhang pinakasimpleng opsyon, at ito nga, hanggang mapalitan ang Pod. Ang address na natatandaan ng user ay dapat pag-aari ng aplikasyon, hindi ng isang replika. Ang paghahambing ng tatlong pasukan ay bumababa sa kung aling object ang nagmamay-ari ng address at ano ang dapat patuloy na gumana kapag lumipat ang workload.
Pumili muna ayon sa lifecycle, pagkatapos ay ayon sa dapat gawin ng network upang maging maabot ang pasukan.
Tatlong pasukan, tatlong lifecycle
Ang Pod IP ay pag-aari ng isang Pod: inilalaan kasama nito at pinakawalan kapag natapos ito. Ang ClusterIP ay pag-aari ng isang Service at ito ay virtual, may kahulugan lamang kung saan naroon ang routing ng mga serbisyo ng cluster. Ang panloob na load balancer ay pag-aari ng isang cloud resource na ipinoprograma ng controller ng cluster sa mga backend. Ang mga modelong ito ng pagmamay-ari ay hinuhulaan ang kabiguan na makukuha mo: isang lumang address, isang hindi maabot na pangalan, o isang lumang set ng backend.
Isulat ang paghahambing bago pumili. Kapag napangalanan na ang may-ari at ang kabiguan, kadalasang nagagawa na mismo ang pagpili.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Direktang access sa Pod: kapaki-pakinabang, pansamantala
Ang direktang access ay tunay na kapaki-pakinabang para sa isang kontroladong pagsusuri: isang administrador, isang maikling sesyon, isang tiyak na port. Ngunit ito ay masamang kontrata para sa mga user, dahil ang address ay isang detalye ng implementasyon na nagbabago sa bawat deployment. At ang itala ito sa isang wiki ay ang paraan kung paano nagiging tsismis ang isang gumaganang serbisyo.
Inaanyayahan din nito ang malalawak na patakaran. Ang pahintulot para sa isang administrador na maabot ang isang Pod ay hindi pahintulot para sa bawat address sa subnet ng node, at ang pangalawa ang kadalasang isinusulat.
ClusterIP: limitado sa cluster ayon sa disenyo
Gumagana ang ClusterIP dahil ipinoprograma ng dataplane ng cluster ang routing para dito sa loob ng cluster. Mula sa laptop sa VPN, walang kahulugan ang address maliban kung sadyang ilantad ito ng isang bagay. Ang pangalang nagtatapos sa svc.cluster.local ay pag-aari ng DNS ng cluster, kaya’t ang pagkopya nito sa isang client na may ibang resolver ay nagbubunga ng pangalang hindi umiiral sa halip na error sa routing.
Ang ClusterIP ay nananatiling tamang pasukan para sa mga tumatawag sa loob ng cluster, kasama ang iba pang workload. Hindi lamang ito isang mekanismo ng paglalathala para sa mga user sa labas ng domain ng routing ng cluster.
Panloob na load balancer: ang nailathalang landas
Ang panloob na load balancer ay nagbibigay sa iyo ng matatag na pribadong address at pangalan na maaaring ituro ng sarili mong zone, habang pinapanatili ng controller na bago ang set ng backend, gaya ng inilalarawan ng gabay ng EKS sa load balancing. Ito ang pasukang nakakaligtas sa ordinaryong pagpapalit ng Pod nang walang nag-e-edit ng dokumento. Ang gastos nito ay isang cloud resource, isang configuration ng controller at isang ruta mula sa VPN, at iyon ang mga bahaging minamaliit ng mga tao.
Gamitin ang modelong controller na aktwal na pinapatakbo ng cluster. Ang mga annotation na isinulat para sa isang integrasyon ay hindi nalalapat sa iba.
Sino ang source address
Nakikita ng mga security group ang source na dumarating sa kanilang hangganan, at ito ay maaaring ang konektadong client o isang isinaling address depende sa landas ng VPN at load balancing. Sa mga node na nakabase sa EC2, ang mga ordinaryong Pod ng VPC CNI ay nagmamana ng mga grupo ng ENI ng node bilang default, habang ang mga sinusuportahang configuration ay maaaring maglakip ng mga grupong partikular sa Pod. Sumulat ng mga patakaran para sa dokumentadong landas sa halip na sa hinulaang address ng laptop.
Panatilihin ang sariling listener at authentication ng aplikasyon bilang magkahiwalay na kontrol. Ang isang patakaran ng network na nagpapahintulot sa daloy ay hindi desisyon sa awtorisasyon at hindi dapat ituring na ganoon.
Ano ang ibibigay sa mga user
Bigyan ang mga user ng pangalan ng serbisyo, hindi address. Ilathala ang pangalan sa pribadong zone, ituro ito sa panloob na pasukan, pagkatapos ay subukan sa pamamagitan ng pagpapalit ng backend na Pod habang bukas pa rin ng client ang parehong pangalan. Sinusubok ng pagsasanay na iyon ang katangiang mahalaga: maabot ang parehong aplikasyon pagkatapos ng rutinang deployment.
Panatilihin ang direktang access sa Pod bilang dokumentadong pagbubukod sa operasyon na may sariling saklaw, malayo sa mga tagubilin para sa mga user.