> For the complete documentation index, see [llms.txt](https://academy.cegedim.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-architecture/gateway-api/gateway-api-istio.md).

# 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 :

```bash
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 :

```bash
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 :

```bash
kubectl label namespace default istio-injection=enabled
```

Vérifier :

```bash
kubectl get namespace default --show-labels
```

La sortie attendue inclut `istio-injection=enabled`.

{% hint style="warning" %}
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.
{% endhint %}

### Étape 3 — Déployer votre application

```bash
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) :

```bash
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

```bash
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

```bash
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 :

```bash
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 :**

```bash
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` :

```bash
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

```bash
# É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 :

```bash
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) :

```bash
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 :

```bash
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 :

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

Vérifier :

```bash
kubectl get namespace default --show-labels
```

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

{% hint style="info" %}
Les pods existants **n'ont pas besoin d'être redémarrés**. Le ztunnel les prend en charge immédiatement.
{% endhint %}

### Étape 3 — Déployer votre application

Aucune annotation sidecar requise :

```bash
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 :

```bash
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 :

```bash
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` :

```bash
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
```

{% hint style="info" %}
Le service gateway auto-provisionné sera nommé `bookinfo-gateway-istio` dans le namespace `default`.
{% endhint %}

### É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`) :

```bash
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
```

{% hint style="info" %}
**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é.
{% endhint %}

### Étape 6 — Vérifier

```bash
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 :

```bash
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 :**

```bash
istioctl waypoint apply --namespace default --enroll-namespace
```

Vérifier :

```bash
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) :

```bash
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 :

```bash
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

```bash
# É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

{% embed url="<https://istio.io/latest/docs/setup/getting-started/>" %}

{% embed url="<https://istio.io/latest/docs/ambient/getting-started/>" %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-architecture/gateway-api/gateway-api-istio.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.