istioctl est le moyen le plus rapide de faire tourner Istio sur un cluster, ce qui en fait le bon point de départ pour apprendre le mesh, même si Helm (couvert dans le guide suivant) convient mieux à une installation de production que vous gérerez sur le long terme. Ce guide installe Istio, confirme qu’il est sain et injecte un sidecar dans un vrai workload.

Avant d’installer : les ressources du cluster

Le plan de contrôle d’Istio et les gateways d’ingress/egress ont besoin de vraies ressources CPU et mémoire, plus que ce qu’un cluster local par défaut alloue généralement. Sur minikube en particulier, démarrez le cluster avec de la marge :

minikube start --cpus=4 --memory=8192

Des ressources sous-dimensionnées sont une source fréquente de Pods Istio bloqués en Pending ou en CrashLoopBackOff lors d’une première installation, ce qu’il vaut la peine d’écarter avant de dépanner quoi que ce soit d’autre.

Installer istioctl

Téléchargez la version correspondant à votre plateforme depuis la page des releases d’Istio, ou utilisez le script d’installation :

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl version --remote=false

La ligne export PATH ne s’applique qu’à votre session de shell courante ; ajoutez-la à votre profil de shell (~/.bashrc, ~/.zshrc) si vous voulez istioctl disponible dans chaque nouveau terminal sans répéter cette étape.

Installer Istio dans le cluster

istioctl install --set profile=demo -y

-y saute la demande de confirmation. Le profil demo installe le plan de contrôle ainsi que les gateways d’ingress et d’egress, avec des réglages de ressources assez légers pour un cluster local ; les installations de production partent généralement du profil default, plus léger, traité dans le guide Helm. Listez les profils disponibles si vous voulez voir ce que chacun inclut avant de choisir :

istioctl profile list

Confirmez l’installation :

kubectl get pods -n istio-system

Vous devriez voir istiod et, avec le profil demo, istio-ingressgateway et istio-egressgateway, tous en Running.

Confirmer que l’installation d’Istio n’a encore rien changé

Cela vaut la peine d’être vérifié explicitement, car cela surprend les gens la première fois : installer Istio n’a aucun effet sur les workloads existants. Aucun sidecar n’apparaît, rien ne change dans la façon dont vos applications s’exécutent, tant que vous n’avez pas explicitement activé l’injection. Istio qui dort dans le cluster ne vous coûte que les ressources consommées par son propre plan de contrôle et ses gateways, rien de plus.

Activer l’injection de sidecar pour un namespace

kubectl label namespace default istio-injection=enabled
kubectl get namespace default --show-labels

Cela n’affecte que les Pods créés après l’application du label. Pour les Pods qui existaient déjà dans ce namespace, recréez-les :

kubectl delete pods --all -n default
kubectl rollout restart deployment -n default

(Ou réappliquez les manifestes qui les ont créés à l’origine ; un simple kubectl delete suivi d’un kubectl apply des mêmes fichiers non modifiés fonctionne de la même manière ; rien dans les manifestes eux-mêmes n’a besoin de changer pour que l’injection s’applique.)

Confirmer qu’un sidecar a bien été injecté

kubectl get pods -n default

Un Pod doté de son sidecar affiche 2/2 sous READY au lieu de 1/1. Confirmez ce qu’est réellement ce second conteneur :

kubectl describe pod <pod-name> -n default

Vous devriez voir un init container istio-init (qui configure l’interception du trafic) et un conteneur istio-proxy aux côtés de celui de votre application, listés sous Containers dans la sortie.

Injecter manuellement un seul workload, sans étiqueter un namespace

Parfois, intégrer un namespace entier au mesh n’est pas ce que vous voulez, seulement un workload précis. istioctl kube-inject ajoute le sidecar à un manifeste avant son application, au lieu de s’appuyer sur l’injection automatique à l’échelle du namespace :

istioctl kube-inject -f my-deployment.yaml | kubectl apply -f -

C’est l’équivalent manuel de ce que déclenche automatiquement le label du namespace : une spec de sidecar, générée par istioctl et fusionnée dans votre manifeste, appliquée en une seule étape. Utile pour un namespace mêlant workloads intégrés au mesh et workloads qui ne le sont pas, où étiqueter tout le namespace en intégrerait plus que prévu.

Désinstaller

istioctl uninstall --purge -y
kubectl delete namespace istio-system

--purge supprime tout ce que l’installation a ajouté, y compris les ressources de profils autres que celui actuellement actif, ce qui compte si vous avez changé de profil pendant vos tests et voulez une suppression propre plutôt que des restes d’une installation antérieure.