Pod, node o clúster: què redirigeix realment un sidecar VPN

Un sidecar VPN dins d'un Pod de Kubernetes sembla una VPN a nivell d'amfitrió amb millors maneres, i la semblança s'acaba a la frontera de l'espai de noms. Els contenidors d'un Pod comparteixen l'espai de noms de xarxa, incloent-hi l'espai d'adreces i ports, així que un sidecar que instal·la rutes i política canvia de debò on van els paquets de l'aplicació. No canvia res per als altres Pods del node, i no toca la pila pròpia del node tret que el configuris per fer-ho. Encertar aquesta frontera decideix tant què pots desplegar com què has de provar. Les seccions següents ho segueixen des de l'espai de noms cap enfora.

Espai de noms compartit, conseqüències compartides

Dos contenidors d'un Pod parlen per loopback i veuen les mateixes interfícies, i per això el patró de sidecar funciona: l'aplicació no necessita saber que existeix un túnel, perquè la ruta que resol es va instal·lar a l'espai de noms que utilitza. La mateixa propietat fa que els errors del sidecar siguin errors de l'aplicació. Una ruta que captura massa, o un canvi de DNS que apunta a un resolutor dins del túnel, s'aplica immediatament a cada procés d'aquell Pod. En un espai de noms compartit no hi ha encaminament per contenidor, així que un sidecar no es pot limitar a un procés.

Aquest és el mecanisme que cal tenir present durant la revisió: el radi d'impacte és el Pod, no el node ni el clúster.

Fins on no arriba el sidecar

Els altres Pods conserven els seus espais de noms i el seu encaminament, així que una càrrega de treball que necessita la mateixa sortida necessita el mateix sidecar o, en lloc d'això, un disseny a nivell de node. El trànsit del node també queda fora de l'espai de noms del Pod, i els Pods amb xarxa d'amfitrió s'exclouen deliberadament d'aquest aïllament del tot. Si executes el sidecar amb xarxa d'amfitrió per arribar a alguna cosa còmoda, has ampliat l'abast d'un Pod a tot el node i ho hauries de dir en veu alta.

El trànsit dels serveis del clúster és l'altra sorpresa habitual. Una ruta per defecte àmplia dins del Pod pot capturar peticions destinades al servidor d'API o a un servei ClusterIP, que després fallen de maneres que semblen un túnel trencat.

Pla de rutes: rangs de Pod, servei, node i VPN

Anota els quatre rangs i comprova'ls per detectar solapaments abans de desplegar res: CIDR de Pod, CIDR de servei, adreces de node i destinacions darrere de la VPN. El solapament entre els rangs privats de la VPN i l'espai propi del clúster no és estrany, i una ruta per defecte és la solució equivocada. El pla de rutes pertany al mateix repositori que el manifest, perquè el proper clúster pot atorgar rangs de Pod i de servei completament diferents.

El DNS forma part del pla i no és una preocupació a part. Un sidecar que reescriu la configuració del resolutor pot trencar el descobriment de serveis dins del clúster mentre fa que les cerques externes funcionin perfectament.

L'arrencada i la fallada són estats explícits

Un procés de sidecar en marxa no és una política de sortida. Decideix quin trànsit pot fluir abans que el túnel estigui a punt i què passa si mor després, i després implementa aquesta decisió: una sonda que condicioni el contenidor de l'aplicació, una política de xarxa que denegui per defecte, o totes dues. Sense cap de les dues, l'aplicació arrenca, resol i envia trànsit pel camí normal del node mentre el túnel encara s'està connectant.

Aquest buit és breu en un clúster sa i permanent en un de trencat, i és exactament la propietat que prefereix un atacant o una fuita de dades accidental.

Combina l'ordenació amb una prova de fallada. Mata el sidecar i confirma que l'aplicació perd la sortida prevista en lloc de retrocedir en silenci.

Capacitats, polítiques i proves des del contenidor de l'aplicació

Concedir les capacitats necessàries per crear interfícies i alterar rutes és una decisió de privilegis, i un privilegi adequat per a un Pod aïllat no ho és automàticament a la pila del node. Fes servir els mecanismes de política de xarxa i de seguretat que admet el clúster, i no assumeixis que tota implementació de CNI o de política tracta una interfície VPN de la mateixa manera; les diferències apareixen justament en els casos de fallada que t'importen.

Prova des del contenidor real de l'aplicació, amb peticions noves a una destinació privada, un servei del clúster i internet públic. Una prova des del sidecar demostra que el túnel funciona, no que l'aplicació arribi al que necessita.

Documenta les suposicions de xarxa del clúster al costat de la configuració de la VPN. Moure la càrrega de treball a un altre clúster és llavors un exercici de comprovar el pla de rutes i no un canvi d'imatge que deixa de funcionar en silenci.