https://medium.com/@christianbellet/kubeshark-pour-surveiller-son-trafic-dans-k8s-a3cc7d6bcf96
Kubeshark est un outil opensource de surveillance du trafic au sein de votre cluster Kubernetes. Que vous ayez déployé des microservices pour exposer une API ou bien différents microservices qui communiquent entre eux pour faire fonctionner une application visible depuis internet, il est très utile de pouvoir comprendre et diagnostiquer des problèmes qui peuvent survenir entre vos services.
Combien de fois ai-je des erreurs 500, quels sont les urls appelées, mon application est-elle stable ? Kubeshark surveille en temps réel votre traffic et permet de visualiser rapidement grâce à une interface graphique les flux entrants et sortants. C’est le “wireshark” que l’on utilise sur Linux mais ici, sur Kubernetes.
NB: Kubeshark comme un outil de débuggage. Ce n’est en aucun cas un outil comme Istio qui lui est davantage “prod ready” et davantage sophistiqué.
Très simple.
sh <(curl -Ls https://kubeshark.co/install)
Kubeshark créé par défaut un namespace kubeshark. Si vous n’avez pas le droit de le faire, il faut déployer Kubeshark dans un namespace qui contient par exemple vos services à monitorer.
Le fichier de config doit être créé manuellement dans votre $HOME directory.
cd $HOME
mkdir .kubeshark
touch .kubeshark/config.yaml
Ensuite, on génère une config par défaut :
ks config > .kubeshark/config.yaml
On utilise “ks” pour kubeshark car l’outil nous propose de créer un alias. Plus court en effet. Pour ne pas vous perturber, on peut rester sur la commande “kubeshark”.
Si on a pas assez de droits et que l’on souhaite monitorer un pod en particulier dans le ns production :
kubeshark tap nom-du-pod --set selfnamespace=production
Sinon, pour l’ensemble des pods d’un namespace :
kubeshark tap -n production
Kubeshark se déploie dans notre cluster
Lancement du déploiement de Kubeshark dans notre cluster
Kubeshark va créer les pods et les services suivants :
On a donc des pods et des services.
Quand le déploiement de Kubeshark est terminé, le dashboard s’ouvre dans une fenêtre de votre navigateur. Ce n’est pas une bonne pratique mais pour tester, ça le fait. En revanche, ne commencez pas à trop jouer avec ce type de service qui s’apparente à un port-forward.
Beaucoup d’informations mais pour mieux identifier ce qu’il se passe au sein de notre cluster, nous allons cibler un endpoint en particulier. Nous avons une boutique en ligne et nous allons cibler le endpoint “/cart”.
On va éviter de cliquer et de refresh nos pages en frontend. On va lancer un stress test avec l’outil k6. La documentation d’installation de k6 est très bien rédigée.
Nous allons utiliser un script récupéré dans la doc de k6 pour lancer notre stress test et nous allons tout simplement adapter l’url dans ce fichier js.
import { check, sleep } from "k6";
import http from "k6/http";
// Test configuration
export const options = {
thresholds: {
// Assert that 99% of requests finish within 3000ms.
http_req_duration: ["p(99) < 3000"],
},
// Ramp the number of virtual users up and down
stages: [
{ duration: "30s", target: 15 },
{ duration: "1m", target: 15 },
{ duration: "20s", target: 0 },
],
};
// Simulated user behavior
export default function () {
let res = http.get("https://istio.127.0.0.1.sslip.io/cart");
// Validate response status
check(res, { "status was 200": (r) => r.status == 200 });
sleep(1);
}
L’url que je souhaite tester est bien évidemment https://istio.127.0.0.1.sslip.io/cart
On enregistre notre code dans un fichier test-frontend-k6.js et on lance le test :
k6 run test-frontend-k6.js --insecure-skip-tls-verify
Quelques instants plus tard, on a le résultat de l’exécution de notre test.
Résultat du test de charge k6
Si on se rends à nouveau dans le dashboard, on va avoir des difficultés pour identifier les flux, tant les requêtes de type health check nous polluent.
On va devoir utiliser les filtres de Kubeshark mais pas de crainte à avoir. Je trouve l’outil très intuitif. Une documentation est intégrée en cliquant à droite de l’icône “Apply”.
On peut aussi analyser des requêtes et au survol, ajouter des filtres. Voici par exemple des requêtes que l’on souhaite isoler.
On peut vérifier les entêtes pour cibler notre outil de stress test et le rajouter au filtre.
Le filtre est mis à jour
Au final, on va utiliser ce filtre, dans mon exemple, pour avoir du GET et du POST :
http and request.headers[« User-Agent »] == « python-requests/2.28.2 » and request.path == « /cart » and (request.method == « GET » or request.method == « POST »)
Et voici nos urls (liste non complète) qui remontent sans “friture”.
Si on clique sur une requête, on accède à des informations pertinentes comme les entêtes (requêtes et réponse), la durée de la réponse, le microservice concerné (ici “frontend”), etc.
Supprimer le déploiement Kubeshark
Quand vous avez terminé votre débuggage, vous pouvez enlever toute trace de Kubeshark avec une seule commande.
kubeshark clean -s production
Très facile à installer et opensource, Kubeshark est un outil pratique pour analyser et filtrer les flux réseau dans votre cluster K8s, au sein d’un namespace pour débugger vos applications. Un outil qui gagne à être connu.