Topologie & dépendances
Voir tous les tagsLa carte des services devient le point d'entrée de l'application : sélectionnez un service, gardez la carte sous les yeux, et passez à ses appelants, ses dépendances, ses traces et ses journaux depuis un seul inspecteur.
Une ligne d'espace de noms qui affiche STRICT rapporte une affirmation. Une
politique stricte appliquée et une qui ne l'est pas — une charge jamais
inscrite, un sélecteur qui ne correspond à rien, une règle qui désactive TLS
en dessous — sont identiques vues de la configuration comme des traces. Seul le
proxy qui a terminé la connexion le sait, et jusqu'ici personne ne le lui
demandait.
La v0.15.0 met sur une même ligne ce que la configuration de votre maillage dit d'une charge de travail et ce que son proxy a réellement fait — et donne une ligne à chaque charge que le cluster exécute, qu'elle ait ou non jamais émis un span.
La v0.16.0 fait de la page d'une charge de travail, sur l'écran du maillage, la fiche que le cluster en tient lui-même — et y met ses journaux : ses propres lignes, et celles que le proxy de nœud et son waypoint ont écrites à son sujet, reliées par le hub qui connaît ses pods.
L'écran Maillage savait dire si vos proxys allaient bien et si votre plan de contrôle poussait encore la configuration. Sur un cluster où le maillage fonctionne sans sidecars, cela fait deux lignes et quatre chiffres. Il se lit désormais comme une console dédiée au tissu réseau.
La v0.14.0 comble les écarts entre ce que la v0.12 promettait à un agent et ce qu'un opérateur obtenait réellement — et fait de l'écran Maillage une console pour la trame qui court sous vos services.
La page d'un service savait nommer ce qui l'appelle et ce qu'il appelle. Elle ne savait pas en montrer la forme. Désormais, elle la dessine.
La v0.13.0 dessine les connexions que la page d'un service savait seulement énumérer — et achève le travail consistant à rendre propre à la source chaque image tirée par une installation, plutôt que de la faire excuser par un registre.
v0.10.0 répond à une question qui vient de l'extérieur de l'équipe plateforme : combien coûte ce cluster, et quelle part de cette dépense n'achète rien ? Un cluster Kubernetes est dimensionné par ce que ses charges de travail réservent, pas par ce qu'elles consomment — et jusqu'ici avuru obs ne connaissait que la seconde moitié de la phrase.
v0.9.0 s'adresse aux clusters où le réseau n'est pas une ligne droite. Un maillage de services intercepte chaque appel : un graphe de dépendances y dessine donc soit des sauts qui n'en sont pas, soit plus rien du tout — et le noyau, en dessous, observait des défauts que personne ne lui demandait.