Pod, nodo ou clúster: que redirixe realmente un sidecar VPN

Un sidecar VPN dentro dun Pod de Kubernetes parece unha VPN a nivel de host con mellores modais, e o parecido remata na fronteira do espazo de nomes. Os contedores dun Pod comparten o espazo de nomes de rede, incluído o espazo de enderezos e portos, así que un sidecar que instala rutas e políticas cambia de verdade a onde van os paquetes da aplicación. Non cambia nada para os demais Pods do nodo, e non toca a pila propia do nodo salvo que o configures para iso. Acertar con esa fronteira decide tanto o que podes despregar como o que debes probar. As seccións seguintes ségueno desde o espazo de nomes cara a fóra.

Espazo de nomes compartido, consecuencias compartidas

Dous contedores dun Pod falan por loopback e ven as mesmas interfaces, e por iso o patrón de sidecar funciona: a aplicación non necesita saber que existe un túnel, porque a ruta que resolve instalouse no espazo de nomes que usa. A mesma propiedade fai que os erros do sidecar sexan erros da aplicación. Unha ruta que captura demasiado, ou un cambio de DNS que apunta a un resolutor dentro do túnel, aplícase de inmediato a cada proceso dese Pod. Nun espazo de nomes compartido non hai encamiñamento por contedor, así que un sidecar non se pode limitar a un proceso.

Este é o mecanismo que cómpre ter presente durante a revisión: o radio de impacto é o Pod, non o nodo e non o clúster.

Ata onde non chega o sidecar

Os demais Pods conservan os seus espazos de nomes e o seu propio encamiñamento, así que unha carga de traballo que necesita a mesma saída necesita o mesmo sidecar ou, no seu lugar, un deseño a nivel de nodo. O tráfico do nodo tamén queda fóra do espazo de nomes do Pod, e os Pods con rede de host exclúense deliberadamente deste illamento por completo. Se executas o sidecar con rede de host para chegar a algo cómodo, ampliaches o alcance dun Pod a todo o nodo e deberías dicilo en voz alta.

O tráfico cara aos servizos do clúster é a outra sorpresa habitual. Unha ruta predeterminada ampla dentro do Pod pode capturar peticións destinadas ao servidor de API ou a un servizo ClusterIP, que despois fallan de formas que parecen un túnel roto.

Plan de rutas: rangos de Pod, servizo, nodo e VPN

Anota os catro rangos e compróbaos en busca de solapamento antes de despregar nada: CIDR do Pod, CIDR do servizo, enderezos do nodo e destinos detrás da VPN. O solapamento entre os rangos privados da VPN e o espazo propio do clúster non é raro, e unha ruta predeterminada é a solución equivocada. O plan de rutas pertence ao mesmo repositorio que o manifesto, porque o seguinte clúster pode repartir rangos de Pod e de servizo completamente distintos.

O DNS é parte do plan e non unha preocupación á parte. Un sidecar que reescribe a configuración do resolutor pode romper o descubrimento de servizos dentro do clúster mentres fai que as consultas externas funcionen á perfección.

O arranque e o fallo son estados explícitos

Un proceso de sidecar en marcha non é unha política de saída. Decide que tráfico pode fluír antes de que o túnel estea listo e que pasa se morre despois, e despois implementa esa decisión: unha sonda que condicione o contedor da aplicación, unha política de rede que denegue por defecto, ou ambas. Sen ningunha das dúas, a aplicación arranca, resolve e envía tráfico pola ruta normal do nodo mentres o túnel aínda se está conectando.

Ese oco é breve nun clúster san e permanente nun roto, e é exactamente a propiedade que prefire un atacante ou unha fuga de datos accidental.

Combina a orde cunha proba de fallo. Mata o sidecar e confirma que a aplicación perde a súa saída prevista en lugar de retroceder en silencio.

Capacidades, políticas e probas desde o contedor da aplicación

Conceder as capacidades necesarias para crear interfaces e alterar rutas é unha decisión de privilexios, e un privilexio axeitado para un Pod illado non o é automaticamente na pila do nodo. Usa os mecanismos de política de rede e seguridade que admite o clúster, e non deas por feito que toda implementación de CNI ou de políticas trata unha interface VPN igual; as diferenzas aparecen xusto nos casos de fallo que che importan.

Proba desde o contedor real da aplicación, con peticións novas a un destino privado, un servizo do clúster e internet público. Unha proba desde o sidecar demostra que o túnel funciona, non que a aplicación chegue ao que necesita.

Documenta os supostos de rede do clúster xunto á configuración da VPN. Mover a carga de traballo a outro clúster é entón un exercicio de comprobar o plan de rutas e non un cambio de imaxe que deixa de funcionar en silencio.