Comment installer et utiliser Linkerd avec Kubernetes

L’auteur a choisi le Tech Education Fund pour recevoir un don dans le cadre du programme Write for DOnations.

Introduction

Un maillage de services est une couche d’infrastructure dédiée qui aide les administrateurs à gérer la communication de service à service. Offrant de nombreux outils puissants, ces mailles de service peuvent rendre votre système plus sûr, plus fiable et également plus visible.

Un maillage de services comme Linkerd, par exemple, peut automatiquement chiffrer les connexions, gérer les retours et les délais de demande, fournir des informations télémétriques comme les taux de réussite et les temps de latence, etc.

Dans ce tutoriel, vous allez installer le maillage de services Linkerd dans votre cluster Kubernetes, déployer une application d’exemple, puis explorer le tableau de bord de Linkerd. Après vous être familiarisé avec certaines des informations de ce tableau de bord, vous configurerez Linkerd pour faire respecter le délai d'attente et réessayer des politiques pour un module particulier de Kubernetes.

Sinon, envisagez d’explorer l’option d’installation de Linkerd/Kubernetes en un clic de DigitalOcean.

Conditions préalables

• Un cluster Kubernetes 1.12+. Dans ce tutoriel, la configuration utilisera un cluster Kubernetes de DigitalOcean en trois nœuds, mais vous êtes libre de créer un cluster en utilisant une autre méthode.

• L’outil de ligne de commande kubectl installé sur un serveur de développement et configuré pour se connecter à votre cluster. Vous pouvez en savoir plus sur l’installation de kubectl dans sa documentation officielle.

Étape 1 — Déploiement de l’application

Pour voir Linkerd en action, vous devez avoir une application en cours d’exécution dans votre cluster. Au cours de cette étape, vous déploierez une application appelée emojivoto que l’équipe de Linkerd a créée à cet effet.

Dans ce référentiel, vous pouvez voir le code des quatre services qui composent l’application, ainsi que le fichier manifest que vous utiliserez pour déployer ces services dans votre cluster Kubernetes.

Tout d’abord, enregistrez ce fichier manifest en local :

curl https://run.linkerd.io/emojivoto.yml --output manifest.yaml

Vous utilisez curl pour récupérer le fichier, puis vous passez l’option --output pour lui dire où vous voulez que le fichier soit enregistré. Dans ce cas, vous créez un fichier appelé manifest.yaml.

Pour mieux comprendre les objectifs de ce dossier, consultez son contenu avec catou ouvrez-le avec votre éditeur préféré :

cat manifest.yaml | less

Appuyez sur ESPACE pour parcourir les directives. Vous verrez que manifest.yaml est en train de créer un espace de noms Kubernetes appelé emojivoto où tout ce qui est lié à cette application sera exécuté, et quelques déploiements et services Kubernetes.

Ensuite, appliquez ce fichier manifest dans votre cluster Kubernetes :

kubectl apply -f manifest.yaml

Encore une fois, vous utilisez kubectl apply avec l’indicateur -f pour attribuer un fichier que vous voulez appliquer.

Cette commande produira une liste de toutes les ressources qui ont été créées :

Output
namespace/emojivoto created
serviceaccount/emoji created
serviceaccount/voting created
serviceaccount/web created
service/emoji-svc created
service/voting-svc created
service/web-svc created
deployment.apps/emoji created
deployment.apps/vote-bot created
deployment.apps/voting created
deployment.apps/web created

Vérifiez maintenant que les services fonctionnent :

kubectl -n emojivoto get pods

Vous utilisez kubectl pour répertorier tous les modules que vous avez dans votre cluster, puis en passant le drapeau -n pour indiquer les espaces de noms que vous voulez utiliser. Vous passez l’espace de noms emojivoto parce que c’est là que vous gérez tous ces services.

Quand vous voyez ous les modules en état de marche, vous êtes prêt à partir :

Output
NAME                        READY   STATUS    RESTARTS   AGE
emoji-566954596f-cw75b      1/1     Running   0          24s
vote-bot-85c5f5699f-7dw5c   1/1     Running   0          24s
voting-756995b6fc-czf8z     1/1     Running   0          24s
web-7f7b69d467-2546n        1/1     Running   0          23s

Enfin, pour voir l’application s’exécuter dans votre navigateur, vous utiliserez la fonction intégrée de transfert des requêtes locales de kubectl vers votre cluster distant :

kubectl -n emojivoto port-forward svc/web-svc 8080:80

Vous voici de nouveau en train d’utiliser kubectl dans l’espace de noms emojivoto, mais en appelant maintenant la sous-commande du transfert de port et en lui donnant pour instruction de transmettre toutes les requêtes locales concernant le port 8080 au service Kubernetes web-svc, sur le port 80. Il s’agit simplement d’un moyen pratique pour vous d’accéder à votre application sans avoir besoin de mettre en place un équilibreur de charge adéquat.

Visitez maintenant le site http://localhost:8080 et vous verrez l’application emojivoto.

Appuyez sur CTRL + C dans votre terminal. Avec une application en cours d’exécution dans votre cluster, vous êtes maintenant prêt à installer Linkerd et à voir comment il fonctionne.

Étape 2 — Installer Linkerd

Maintenant que vous avez une application en cours d’exécution, installons Linkerd. Pour l’installer dans votre cluster Kubernetes, vous avez d’abord besoin du CLI Linkerd. Vous utiliserez cette interface en ligne de commande pour interagir avec Linkerd depuis votre machine locale. Ensuite, vous pouvez installer Linkerd dans votre cluster.

Tout d’abord, installons le CLI avec le script fourni par l’équipe de Linkerd :

curl https://run.linkerd.io/install | sh

Ici, vous utilisez le curl pour télécharger le script d’installation, puis vous transmettez la sortie à shqui exécute automatiquement le script. Vous pouvez également télécharger le CLI directement à partir de la page de publication de Linkerd

Si vous utilisez le script, il installera Linkerd à ~/.linkerd2/bin. Confirmez maintenant que le CLI fonctionne correctement :

~/.linkerd2/bin/linkerd version

La commande produira quelque chose comme ceci :

Output
Client version: stable-2.7.1
Server version: unavailable

Ensuite, pour faciliter le fonctionnement de la CLI, ajoutez ce répertoire à votre $PATH:

export PATH=$PATH:$HOME/.linkerd2/bin

Vous pouvez maintenant exécuter plus directement les commandes, comme la précédente :

linkerd version

Enfin, nous allons installer Linkerd dans votre cluster Kubernetes. La commande linkerd install est utilisée pour générer tous les manifestes yaml nécessaires à l’exécution de Linkerd, mais elle n’appliquera pas ces manifestes à votre cluster. Exécutez cette commande pour inspecter sa sortie :

linkerd install

Vous verrez une longue sortie, énumérant tous les manifestes de yaml pour les ressources que Linkerd doit exécuter. Pour appliquer ces manifestes à votre cluster, exécutez :

linkerd install | kubectl apply -f -

L’exécution de l'installation de Linkerd produira tous les manifestes que vous avez vus précédemment. | puis transmet cette sortie directement à kubectl apply, qui les appliquera.

Après avoir exécuté cette commande, kubectl apply produira une liste de toutes les ressources qui ont été créées.

Pour confirmer que tout fonctionne dans votre cluster, lancez la vérification de Linkerd :

linkerd check

Plusieurs contrôles seront alors effectués sur votre cluster pour confirmer que tous les composants nécessaires fonctionnent :

Output
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

[...]

control-plane-version
---------------------
√ control plane is up-to-date
√ control plane and cli versions match

Status check results are √

Enfin, exécutez cette commande pour ouvrir le tableau de bord intégré de Linkerd dans votre navigateur (n’oubliez pas que vous devrez fournir le drapeau--address 0.0.0.0 si vous ne l’exécutez pas depuis votre machine locale) :

linkerd dashboard

La plupart des informations que vous voyez dans le tableau de bord peuvent être obtenues en utilisant le CLI de Linkerd. Par exemple, lancez cette commande pour voir les déploiements de statistiques de haut niveau :

linkerd stat deployments -n linkerd

Ici, vous dites que vous voulez que les statistiques des déploiements se déroulent dans l’espace de noms linkerd. Ce sont des composants propres à Linkerd, et, fait intéressant, vous pouvez utiliser Linkerd lui-même pour les surveiller. Vous pouvez voir des statistiques comme les demandes par seconde (RPS), le taux de réussite, la latence, et plus encore. Vous pouvez également voir une colonne Meshed, qui indique combien de modules Linkerd a injecté :

Output
NAME                     MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
linkerd-controller          1/1   100.00%   0.4rps           1ms          87ms          98ms          5
linkerd-destination         1/1   100.00%   0.3rps           1ms           2ms           2ms         13
linkerd-grafana             1/1   100.00%   0.3rps           2ms           3ms           3ms          2
linkerd-identity            1/1   100.00%   0.3rps           1ms           2ms           2ms         10
linkerd-prometheus          1/1   100.00%   0.7rps          35ms         155ms         191ms          9
linkerd-proxy-injector      1/1   100.00%   0.3rps           2ms           3ms           3ms          2
linkerd-sp-validator        1/1   100.00%   0.3rps           1ms           5ms           5ms          2
linkerd-tap                 1/1   100.00%   0.3rps           1ms           4ms           4ms          6
linkerd-web                 1/1   100.00%   0.3rps           1ms           2ms           2ms          2

Maintenant, essayez cette commande dans votre espace de noms emojivoto :

linkerd stat deployments -n emojivoto

Même si vous pouvez voir vos quatre services, aucune des statistiques que vous avez vues auparavant n’est disponible pour ces déploiements, et dans la colonne « Meshed », vous pouvez voir qu’il est écrit 0/1:

Output
NAME       MESHED   SUCCESS   RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         0/1         -     -             -             -             -          -
vote-bot      0/1         -     -             -             -             -          -
voting        0/1         -     -             -             -             -          -
web           0/1         -     -             -             -             -          -

Le résultat ici signifie que vous n’avez pas encore injecté Linkerd dans l’application. Ce sera votre prochaine étape.

Étape 3 — Injecter Linkerd dans votre application

Maintenant que Linkerd fonctionne dans votre cluster, vous êtes prêt à l’injecter dans votre application emojivoto.

Linkerd travaille en faisant fonctionner un conteneur sidecar dans vos modules Kubernetes. C’est-à-dire que vous allez injecter un conteneur proxy Linkerd dans chaque module que vous avez en cours d’exécution. Chaque demande que vos modules enverront ou recevront passera par ce proxy très léger qui peut recueillir des mesures (comme le taux de réussite, les demandes par seconde et la latence) et appliquer des politiques (comme les délais d’attente et les nouveaux essais).

Vous pouvez injecter manuellement le proxy de Linkerd avec cette commande :

kubectl get deployments -n emojivoto -o yaml | linkerd inject - | kubectl apply -f -

Dans cette commande, vous utilisez d’abord kubectl get pour obtenir tout le déploiement de Kubernetes que vous avez en cours d’exécution dans l’espace de noms emojivoto puis en spécifiant que vous souhaitez que le résultat soit au format yaml. Ensuite, vous envoyez ce résultat à la commande linkerd inject. Cette commande permet de lire le fichier yaml avec les manifestes en cours d’exécution et de le modifier pour inclure le proxy linkerd à côté de chaque déploiement.

Enfin, vous recevez ce manifeste modifié et l’appliquez à votre cluster avec kubectl apply.

Après avoir exécuté cette commande, vous verrez un message disant que les quatre services emojivoto (emoji, vote-bot, voting et web) ont été injectés avec succès.

Si vous récupérez maintenant les statistiques pour emojivotovous verrez que tous vos déploiements sont maintenant maillés, et après quelques secondes, vous commencerez à voir les mêmes statistiques que celles que vous avez vues pour l’espace de noms Linkerd :

linkerd stat deployments -n emojivoto

Vous pouvez voir ici les statistiques des quatre services qui composent l’application emojivoto avec leur taux de réussite respectif, les demandes par seconde et la latence, sans avoir à écrire ou à modifier un code d’application.

Output
NAME       MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         1/1   100.00%   1.9rps           1ms           2ms           2ms          2
vote-bot      1/1         -        -             -             -             -          -
voting        1/1    85.96%   0.9rps           1ms           1ms           1ms          2
web           1/1    93.04%   1.9rps           8ms          27ms          29ms          2

Le service vote-bot n’affiche aucune statistique, car il s’agit simplement d’un robot qui envoie des demandes à d’autres services et ne reçoit donc aucun trafic, ce qui constitue en soi une information précieuse.

Voyons maintenant comment vous pouvez fournir à Linkerd des informations supplémentaires sur vos services afin de personnaliser leur comportement.

Étape 4 — Définir un profil de service

Maintenant que vous avez injecté Linkerd dans votre application, vous pouvez commencer à récupérer des informations précieuses sur le comportement de chacun de vos services. De plus, vous avez accompli cela sans avoir besoin d’écrire des configurations personnalisées ou de modifier le code de votre application. Toutefois, si vous fournissez à Linkerd des informations supplémentaires, il peut alors appliquer de nombreuses politiques, comme les délais d’attente et les nouvelles tentatives. Il peut également fournir des mesures par itinéraire.

Ces informations sont fournies par le biais d’un profil de service, qui est une ressource Linkerd personnalisée où vous pouvez décrire les parcours dans vos demandes et comment chacun se comportera.

Voici un exemple de ce à quoi ressemble un fichier manifest de profil de service :

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.my-namespace.svc.cluster.local
spec:
  routes:
  - name: My Route Name
    isRetryable: true # Define it's safe to retry this route
    timeout: 100ms # Define a timeout for this route
    condition:
      method: GET
      pathRegex: /my/route/path

Le profil de service décrit une liste d’itinéraires, puis définit le comportement des requêtes qui correspondent à la condition spécifiée. Dans cet exemple, vous dites que chaque demande GET envoyée à /my/route/path s’arrêtera après 100 ms et, en cas d’échec, elle pourra être réessayée.

Nous allons maintenant créer un profil de service pour l’un de vos services. En prenant voting-svc comme exemple, utilisez d’abord le CLI de Linkerd pour vérifier les itinéraires que vous avez définis pour ce service :

linkerd routes svc/voting-svc -n emojivoto

Ici, vous utilisez les itinéraires linkerd pour lister tous les itinéraires du service voting-svc, dans l’espace de noms emojiovoto :

Output
ROUTE          SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
[DEFAULT]   voting-svc    83.05%   1.0rps           1ms           1ms           2ms

Vous ne trouverez qu’un seul itinéraire, [DEFAULT] C’est là que toutes les requêtes sont regroupées jusqu’à ce que vous définissiez votre profil de service.

Ouvrez maintenant nano ou votre éditeur préféré pour créer un fichier service-profil.yaml :

nano service-profile.yaml

Ajoutez la définition de profil de service suivante dans ce fichier :

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: voting-svc.emojivoto.svc.cluster.local
  namespace: emojivoto
spec:
  routes:
  - name: VoteDoughnut
    isRetryable: true
    timeout: 100ms
    condition:
      method: POST
      pathRegex: /emojivoto.v1.VotingService/VoteDoughnut

Maintenant, enregistrez le fichier et fermez votre éditeur.

Ici vous déclarez un profil de service pour le service voting-svc, dans l’espace de noms emojivoto. Vous avez défini un itinéraire appelé VoteDoughnut qui correspondra à toute demande POST vers /emojivoto.v1. Chemin VotingService/VoteDoughnut. Si une requête correspondant à ces critères prend plus de 100 ms, Linkerd l’annulera et le client recevra une réponse 504 en retour. Vous dites également à Linkerd que si cette demande échoue, elle peut être réessayée.

Appliquez maintenant ce fichier à votre cluster :

kubectl apply -f service-profile.yaml

Après quelques secondes, revérifiez les itinéraires de ce service :

linkerd routes svc/voting-svc -n emojivoto

Vous allez maintenant voir votre nouvel itinéraire VoteDoughnut :

Output
ROUTE             SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
VoteDoughnut   voting-svc     0.00%   0.2rps           1ms           1ms           1ms
[DEFAULT]      voting-svc   100.00%   0.8rps           1ms           4ms           4ms

Vous pouvez voir plusieurs mesures personnalisées, comme le taux de réussite, les demandes par seconde et la latence pour cet itinéraire spécifique. Notez que l’objectif de VoteDoughnut est configuré intentionnellement pour toujours renvoyer une erreur, et qu’il produit un taux de réussite de 0%, alors que la route [DEFAULT] produit 100%.

Maintenant, après avoir donné à Linkerd un peu d’informations sur votre service, vous disposez de mesures personnalisées par itinéraire, ainsi que de deux politiques appliquées : les temps d’attente et les retours.

Conclusion

Dans cet article, vous avez installé Linkerd dans votre cluster Kubernetes et l’avez utilisé pour surveiller un exemple d’application. Vous avez extrait des informations télémétriques utiles comme le taux de réussite, le débit et la latence. Vous avez également configuré un profil de service Linkerd pour collecter des mesures par itinéraire et appliquer deux politiques dans l’application emojivoto.

Si vous souhaitez en savoir plus sur Linkerd, vous pouvez parcourir leur excellente page de documentation, où ils montrent comment sécuriser vos services, configurer le traçage distribué, automatiser les versions canaries et bien plus encore.

A partir de là, vous pourriez également envisager de consulter Istio, qui est un autre Service Mesh avec un ensemble différent de caractéristiques et de compromis.