Istio

Démarrage avec Istio sur cegedim.cloud — modes sidecar et ambient mesh

Istio supporte la Gateway API comme modèle d'ingress et de gestion du trafic principal. Il peut être utilisé comme unique stack ingress (choisi à la création du cluster) ou installé en complément sur des clusters utilisant NGF ou Traefik.

Ce guide couvre les deux modes de fonctionnement : sidecar et ambient. Utilisez le tableau comparatif ci-dessous pour choisir le mode adapté à votre workload.

Mode Sidecar vs Mode Ambient

	Sidecar	Ambient
Emplacement du proxy	Injecté en tant que conteneur à l'intérieur de chaque pod	Fonctionne comme un ztunnel au niveau du nœud, hors des pods
Enrôlement	Label istio-injection=enabled sur le namespace, les pods doivent redémarrer	Label istio.io/dataplane-mode=ambient, pas de redémarrage nécessaire
Gestion du trafic L7	Intégrée — le sidecar la gère directement	Nécessite un waypoint proxy
Overhead ressources	CPU/mémoire par pod pour chaque sidecar Envoy	ztunnel partagé par nœud
VirtualService / DestinationRule	Natif	Via waypoint uniquement
CRDs Gateway API requis	Non	Oui

Ce que la plateforme fournit

Vous n'avez pas besoin d'installer ou de configurer quoi que ce soit au niveau du cluster. Les composants suivants sont déployés et gérés par l'équipe plateforme :

Composant	Namespace	Rôle	Mode
Istiod	istio-system	Plan de contrôle	Les deux
istio-ingressgateway	istio-ingress	Point d'entrée ingress nord-sud	Les deux
Istio CNI	istio-system	Enrôlement des pods en mode ambient	Ambient uniquement
ztunnel	istio-system	mTLS L4 / proxy au niveau du nœud	Ambient uniquement

Chaque cluster cegedim.cloud est fronté par un load balancer F5 BigIP qui gère le DNS wildcard (*.{{ cluster-name }}.ccs.cegedim.cloud), la terminaison TLS et le forwarding L4 vers les pods istio-ingressgateway. Remplacez {{ cluster-name }} par le nom réel de votre cluster (ex. prod-paris, staging-lyon) dans tous les exemples ci-dessous.

---

Mode Sidecar

En mode sidecar, un conteneur proxy Envoy est injecté aux côtés de chacun de vos pods applicatifs. Il gère le mTLS, l'observabilité et la gestion du trafic L7 directement — aucun waypoint proxy supplémentaire n'est nécessaire.

Étape 1 — Addons d'observabilité (optionnel)

Déployer Prometheus et Kiali pour les métriques et la visualisation de la topologie :

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/kiali.yaml

Exposer Kiali via la gateway d'ingress plateforme :

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: cgdm-kiali
  namespace: istio-ingress
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "kiali.{{ cluster-name }}.ccs.cegedim.cloud"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: cgdm-kiali
  namespace: istio-ingress
spec:
  hosts:
  - "kiali.{{ cluster-name }}.ccs.cegedim.cloud"
  gateways:
  - cgdm-kiali
  http:
  - route:
    - destination:
        host: kiali.istio-system.svc.cluster.local
        port:
          number: 20001
EOF

Kiali sera disponible à l'adresse https://kiali.{{ cluster-name }}.ccs.cegedim.cloud.

Étape 2 — Activer l'injection du sidecar

Labelliser votre namespace pour activer l'injection automatique du sidecar Envoy :

kubectl label namespace default istio-injection=enabled

Vérifier :

kubectl get namespace default --show-labels

La sortie attendue inclut istio-injection=enabled.

Contrairement au mode ambient, les pods existants doivent être redémarrés pour recevoir l'injection du sidecar. Le label ne prend effet que pour les pods nouvellement créés.

Étape 3 — Déployer votre application

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/bookinfo/platform/kube/bookinfo.yaml

Vérifier que tous les pods tournent avec 2 conteneurs chacun (app + sidecar Envoy) :

kubectl get pods

La sortie attendue affiche 2/2 READY pour chaque pod :

NAME                              READY   STATUS    RESTARTS   AGE
details-v1-xxx                    2/2     Running   0          ...
productpage-v1-xxx                2/2     Running   0          ...
ratings-v1-xxx                    2/2     Running   0          ...
reviews-v1-xxx                    2/2     Running   0          ...

Étape 4 — Connecter l'ingress depuis la gateway plateforme

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: cgdm-bookinfo
  namespace: istio-ingress
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookinfo.{{ cluster-name }}.ccs.cegedim.cloud"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: cgdm-bookinfo
  namespace: istio-ingress
spec:
  hosts:
  - "bookinfo.{{ cluster-name }}.ccs.cegedim.cloud"
  gateways:
  - cgdm-bookinfo
  http:
  - route:
    - destination:
        host: productpage.default.svc.cluster.local
        port:
          number: 9080
EOF

Flux d'ingress complet :

https://bookinfo.{{ cluster-name }}.ccs.cegedim.cloud
  → BigIP (terminaison TLS)
  → istio-ingressgateway (DaemonSet, istio-ingress)
  → productpage.default.svc.cluster.local:9080

Étape 5 — Vérifier

curl https://bookinfo.{{ cluster-name }}.ccs.cegedim.cloud/productpage

Étape 6 — Observabilité avec Kiali

Accédez à https://kiali.{{ cluster-name }}.ccs.cegedim.cloud, naviguez vers Graph et sélectionnez le namespace default pour visualiser le trafic en temps réel entre les services.

Générer du trafic continu pour alimenter le graphe :

while true; do curl -sSI -o /dev/null https://bookinfo.{{ cluster-name }}.ccs.cegedim.cloud/productpage; done

Étape 7 — Gestion du trafic L7

En mode sidecar, la gestion du trafic L7 est intégrée — le sidecar Envoy gère le routage directement. Aucun waypoint proxy n'est nécessaire.

Définir des subsets avec DestinationRule :

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
EOF

Répartition du trafic avec VirtualService — 90% vers reviews-v1, 10% vers reviews-v3 :

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v3
      weight: 10
EOF

Vérifier dans Kiali — la vue Graph affichera le trafic pondéré vers chaque version.

Nettoyage — Mode Sidecar

# Étape 7 — Gestion du trafic
kubectl delete virtualservice reviews
kubectl delete destinationrule reviews

# Étape 4 — Câblage ingress
kubectl delete gateway.networking.istio.io cgdm-bookinfo -n istio-ingress
kubectl delete virtualservice cgdm-bookinfo -n istio-ingress

# Étape 3 — Application
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/bookinfo/platform/kube/bookinfo.yaml

# Étape 2 — Désactiver l'injection du sidecar
kubectl label namespace default istio-injection-

# Étape 1 — Addons d'observabilité
kubectl delete gateway.networking.istio.io cgdm-kiali -n istio-ingress
kubectl delete virtualservice cgdm-kiali -n istio-ingress
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/kiali.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/prometheus.yaml

---

Mode Ambient

En mode ambient, il n'y a pas de conteneurs sidecar. Un ztunnel au niveau du nœud gère le mTLS L4 de manière transparente pour tous les pods enrôlés — aucun redémarrage de pod n'est nécessaire. La gestion du trafic L7 nécessite le déploiement d'un waypoint proxy optionnel par namespace.

Étape 1 — Prérequis

CRDs Gateway API (canal expérimental) requis pour l'ambient mesh :

kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/experimental-install.yaml

Addons d'observabilité (optionnel) :

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/kiali.yaml

Exposer Kiali :

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: cgdm-kiali
  namespace: istio-ingress
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "kiali.{{ cluster-name }}.ccs.cegedim.cloud"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: cgdm-kiali
  namespace: istio-ingress
spec:
  hosts:
  - "kiali.{{ cluster-name }}.ccs.cegedim.cloud"
  gateways:
  - cgdm-kiali
  http:
  - route:
    - destination:
        host: kiali.istio-system.svc.cluster.local
        port:
          number: 20001
EOF

Kiali sera disponible à l'adresse https://kiali.{{ cluster-name }}.ccs.cegedim.cloud.

Étape 2 — Enrôler votre namespace

Labelliser votre namespace pour rejoindre l'ambient mesh. Le ztunnel interceptera automatiquement tout le trafic des pods avec mTLS :

kubectl label namespace default istio.io/dataplane-mode=ambient

Vérifier :

kubectl get namespace default --show-labels

La sortie attendue inclut istio.io/dataplane-mode=ambient.

Les pods existants n'ont pas besoin d'être redémarrés. Le ztunnel les prend en charge immédiatement.

Étape 3 — Déployer votre application

Aucune annotation sidecar requise :

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/bookinfo/platform/kube/bookinfo.yaml

Vérifier que tous les pods tournent :

kubectl get pods

Étape 4 — Exposer votre application via la Gateway API

Créer une ressource Gateway dans votre namespace applicatif. Istiod auto-provisionnera un pod et un service gateway dédiés :

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
  annotations:
    networking.istio.io/service-type: ClusterIP
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
EOF

Puis créer une HTTPRoute :

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo
spec:
  parentRefs:
  - name: bookinfo-gateway
  rules:
  - matches:
    - path:
        type: Exact
        value: /productpage
    - path:
        type: PathPrefix
        value: /static
    - path:
        type: Exact
        value: /login
    - path:
        type: Exact
        value: /logout
    - path:
        type: PathPrefix
        value: /api/v1/products
    backendRefs:
    - name: productpage
      port: 9080
EOF

Le service gateway auto-provisionné sera nommé bookinfo-gateway-istio dans le namespace default.

Étape 5 — Connecter l'ingress depuis la gateway plateforme

Soumettre le manifest suivant à l'équipe plateforme (ou l'appliquer vous-même si vous avez accès au namespace istio-ingress) :

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: cgdm-bookinfo
  namespace: istio-ingress
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookinfo.{{ cluster-name }}.ccs.cegedim.cloud"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: cgdm-bookinfo
  namespace: istio-ingress
spec:
  hosts:
  - "bookinfo.{{ cluster-name }}.ccs.cegedim.cloud"
  gateways:
  - cgdm-bookinfo
  http:
  - route:
    - destination:
        host: bookinfo-gateway-istio.default.svc.cluster.local
        port:
          number: 80
EOF

Flux d'ingress complet :

https://bookinfo.{{ cluster-name }}.ccs.cegedim.cloud
  → BigIP (terminaison TLS)
  → istio-ingressgateway (DaemonSet, istio-ingress)
  → bookinfo-gateway-istio.default.svc.cluster.local
  → productpage:9080

Alternative — chemin d'ingress dédié : Définissez networking.istio.io/service-type: NodePort sur votre ressource Gateway (Étape 4) et demandez à l'équipe plateforme de créer un virtual server BigIP dédié. Cela offre à votre application un chemin d'ingress totalement indépendant, sans passer par l'istio-ingressgateway partagé.

Étape 6 — Vérifier

curl https://bookinfo.{{ cluster-name }}.ccs.cegedim.cloud/productpage

Étape 7 — Observabilité avec Kiali

Accédez à https://kiali.{{ cluster-name }}.ccs.cegedim.cloud, naviguez vers Graph et sélectionnez le namespace default.

Générer du trafic continu pour alimenter le graphe :

while true; do curl -sSI -o /dev/null https://bookinfo.{{ cluster-name }}.ccs.cegedim.cloud/productpage; done

Étape 8 — Gestion du trafic L7 avec waypoint

Par défaut, le ztunnel ne gère que le trafic L4 (mTLS, TCP). Pour les fonctionnalités L7 (répartition du trafic, routage par en-têtes, retries), déployez un waypoint proxy dans votre namespace.

Déployer le waypoint :

istioctl waypoint apply --namespace default --enroll-namespace

Vérifier :

kubectl get deployment waypoint -n default
kubectl get namespace default --show-labels | grep use-waypoint

Déployer les services par version (requis pour la répartition du trafic) :

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/bookinfo/platform/kube/bookinfo-versions.yaml

Répartition du trafic avec HTTPRoute — pointez parentRefs vers le Service (pas une Gateway). Le waypoint intercepte et applique les règles de routage :

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: reviews
    port: 9080
  rules:
  - backendRefs:
    - name: reviews-v1
      port: 9080
      weight: 90
    - name: reviews-v3
      port: 9080
      weight: 10
EOF

Vérifier dans Kiali — la vue Graph affichera le trafic pondéré vers chaque version.

Nettoyage — Mode Ambient

# Étape 8 — Gestion du trafic
kubectl delete httproute reviews
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/bookinfo/platform/kube/bookinfo-versions.yaml
istioctl waypoint delete waypoint --namespace default
kubectl label namespace default istio.io/use-waypoint-

# Étape 5 — Câblage ingress
kubectl delete gateway.networking.istio.io cgdm-bookinfo -n istio-ingress
kubectl delete virtualservice cgdm-bookinfo -n istio-ingress

# Étapes 3 & 4 — Application et gateway
kubectl delete httproute bookinfo
kubectl delete gateway bookinfo-gateway
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/bookinfo/platform/kube/bookinfo.yaml

# Étape 2 — Désinscrire le namespace
kubectl label namespace default istio.io/dataplane-mode-

# Étape 1 — Addons d'observabilité
kubectl delete gateway.networking.istio.io cgdm-kiali -n istio-ingress
kubectl delete virtualservice cgdm-kiali -n istio-ingress
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/kiali.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.30/samples/addons/prometheus.yaml

Pour aller plus loin

Getting StartedIstio

Getting StartedIstio