istioctl install est le moyen le plus rapide de faire tourner un mesh pour apprendre ou tester en local, mais Helm est la méthode officiellement recommandée par Istio pour une installation de production que vous comptez gérer, versionner et personnaliser dans le temps. Ce guide installe Istio avec Helm, et couvre ce qui a remplacé l’Istio Operator pour le type de personnalisation fine vers lequel les documents plus anciens vous orientent.

Une remarque avant de commencer : l’Istio Operator a disparu

Istio livrait autrefois un Istio Operator dans le cluster : un contrôleur qui surveillait une ressource personnalisée IstioOperator et réconciliait le cluster pour qu’il lui corresponde. Si vous avez vu des tutoriels, des supports de certification ou d’anciennes documentations construits autour de l’export d’un profil vers un fichier YAML IstioOperator que l’on applique, c’est ce qu’ils décrivent. L’operator dans le cluster a été déprécié dans Istio 1.23 et entièrement supprimé dans 1.24. Il n’existe plus dans les versions actuelles d’Istio.

Ce qui l’a remplacé est plus direct : les fichiers de values Helm. La même personnalisation qui passait par une ressource IstioOperator, activer une gateway, ajuster les demandes de ressources, modifier les paramètres d’un composant, s’exprime désormais sous forme de values Helm et s’applique avec helm install ou helm upgrade, comme vous personnaliseriez n’importe quel autre chart Helm. Si vous étudiez à partir de supports qui présentent l’Operator comme essentiel, considérez que le concept sous-jacent (personnaliser les paramètres dans un fichier, l’appliquer, Istio réconcilie pour y correspondre) reste valable, mais traduisez le mécanisme vers Helm.

Installer les trois charts principaux

L’installation d’Istio avec Helm est répartie en trois charts, installés dans l’ordre :

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

# 1. CRD et ressources à l'échelle du cluster
helm install istio-base istio/base -n istio-system --create-namespace

# 2. Le plan de contrôle (istiod)
helm install istiod istio/istiod -n istio-system --wait

# 3. La gateway d'ingress (optionnelle, si vous avez besoin d'une entrée de trafic externe)
helm install istio-ingressgateway istio/gateway -n istio-system

istio-base installe les CustomResourceDefinitions et les ressources RBAC à l’échelle du cluster dont dépend tout le reste, et doit donc passer en premier. istiod est le plan de contrôle lui-même. Le chart gateway n’est nécessaire que si vous voulez une gateway d’ingress (ou d’egress) gérée ; un mesh avec seulement du trafic de sidecar à sidecar peut s’en passer.

kubectl get pods -n istio-system
helm list -n istio-system

Vous devriez voir istiod et, s’il est installé, la gateway en Running, et helm list devrait afficher les trois releases.

Personnaliser les paramètres avec des values

Chaque chart accepte ses propres values, que l’on découvre comme pour n’importe quel chart Helm :

helm show values istio/istiod > istiod-values.yaml

Modifiez le fichier, puis installez (ou mettez à niveau) avec lui :

helm upgrade istiod istio/istiod -n istio-system -f istiod-values.yaml

Personnalisations courantes : requêtes et limites de ressources pour istiod ou les gateways, activation d’une gateway d’egress (désactivée par défaut sur la plupart des profils), ou ajustement de paramètres à l’échelle du mesh sous meshConfig. Tout ce que l’Istio Operator vous permettait de configurer via spec.components ou spec.meshConfig a un équivalent en values Helm ; la documentation d’installation Helm d’Istio est la référence faisant autorité sur les values qui correspondent à quel comportement pour la version que vous exécutez.

Appliquer un changement

helm upgrade istiod istio/istiod -n istio-system -f istiod-values.yaml

Même schéma que pour toute autre mise à niveau Helm : modifiez les values, relancez helm upgrade, et Helm réconcilie les ressources en place pour qu’elles correspondent. Il n’y a pas d’étape séparée « appliquer la configuration de l’operator » comme le décrivent les anciens supports ; le helm upgrade est l’étape d’application.

Désinstaller

helm uninstall istio-ingressgateway -n istio-system
helm uninstall istiod -n istio-system
helm uninstall istio-base -n istio-system
kubectl delete namespace istio-system

Contrairement à istioctl uninstall --purge, qui supprime tout en une commande, l’approche Helm désinstalle chaque release individuellement, à peu près dans l’ordre inverse de leur installation, car les charts ultérieurs peuvent dépendre de ressources créées par le chart de base.