Un sidecar de VPN necessita una regla d'inici i una regla de fallada

Un pod inicia el contenidor del túnel abans de l'aplicació i les primeres peticions tenen èxit, que és exactament el cas que amaga el problema. L'ordenació resol una cursa i no diu res sobre el trànsit que l'aplicació comença quatre hores més tard, després que el túnel hagi fallat. Són dues decisions separades. Normalment només se'n dissenya una.

L'ordenació només controla la primera petició

Kubernetes admet un cicle de vida de sidecar construït amb contenidors init reiniciables. Dins d'aquest model, una sonda d'inici pot aturar el següent pas d'inicialització fins que el túnel informi que està a punt. És una millora genuïna i val la pena fer-la servir deliberadament en lloc d'afegir un sleep a un script d'entrada. La porta només és tan bona com la condició que comprova.

Fora d'aquest model, la semàntica de l'ordenació pertany al runtime o sistema de dependències que feu servir, i no cal que coincideixin. Un desplegament copiat d'una altra plataforma pot semblar que espera el túnel perquè l'aplicació comença lentament per casualitat. No és la mateixa garantia i falla sota càrrega.

Digueu què observa la porta: hi ha un procés, hi ha una interfície, una handshake s'ha completat. Cadascuna d'aquestes afirmacions és més feble que «el camí de dades fins a les destinacions que necessita aquest pod funciona».

Forceu el camí de dades en lloc de suposar-lo

Una sonda és una comprovació en un moment i un tallafoc és una propietat que val entre moments. Si el requisit és que el trànsit de l'aplicació no surti mai fora del túnel, s'ha d'expressar a l'espai de noms de xarxa compartit com una regla d'acceptar o descartar. L'ordre d'inici dels contenidors no pot portar aquest requisit. Només una regla pot.

Els contenidors d'un mateix pod comparteixen aquest espai de noms, així que el punt d'aplicació és l'espai de noms mateix. Tot el que escriviu ha de deixar disponible la connexió exterior del túnel, perquè bloquejar-la per protegir l'aplicació talla el camí que l'aplicació necessita.

Decidiu la política de fallada explícitament: ha de parar del tot el trànsit de l'aplicació quan el túnel no està sa, o ha de continuar i quedar marcat com a no protegit? Totes dues són defensables, i cap de les dues no és el que obteniu iniciant contenidors en un ordre determinat.

Proveu el trànsit que no heu esmentat

Feu una petició nova durant una fallada controlada del túnel i mireu si surt. Després repetiu la comprovació per als camins que una prova d'adreça de sortida no toca mai: resolució de DNS dins del clúster, destinacions IPv6 i serveis abastats per adreces internes del clúster en lloc d'internet públic. Aquests són els camins que continuen funcionant en silenci després que el túnel mori.

Una pàgina d'adreça de sortida demostra que una petició va anar on esperàveu en aquell moment. No pot inventariar els altres camins, i la diferència entre el que heu provat i el que el pod pot abastar és on viuen les fallades interessants.

Repetiu la prova després d'un reinici del sidecar, no només després d'un inici net. Un contenidor de túnel reiniciat pot deixar l'espai de noms amb rutes i política en un estat intermedi.

Escriviu el registre de desplegament

Tres fets pertanyen a les notes de desplegament: la prova de disponibilitat i què observa, l'acció de recuperació quan aquesta prova falla i la regla d'aplicació que governa la sortida. La documentació dels contenidors sidecar cobreix la mecànica del cicle de vida i us deixa aquesta decisió de política. Aquesta divisió és correcta, i és també per això que la política sol faltar.

Una comprovació d'estat confosa amb una protecció és el tipus més car d'indicador verd, perquè fa que la gent deixi de fer preguntes. Anomenar-la amb precisió a la documentació costa una frase i ho evita.

Finalment, proveu el camí de recuperació una vegada amb l'aplicació en marxa. Un disseny que exigeix recrear el pod per restaurar la sortida és una decisió, i hauria de ser una que hàgiu pres, no una que hàgiu descobert.