# K8s - Architecture

Il existe 2 topologies possibles pour le cluster K8s fourni par **cegedim.cloud** :

* **Standard** : les charges de travail sont déployées dans un seul centre de données, mais protégées contre un sinistre du centre de données en utilisant un centre de données secondaire comme basculement.
* **Haute Disponibilité** : les charges de travail sont déployées entre deux centres de données. Si un multi-réplica est utilisé et que la charge de travail est bien distribuée, aucune interruption de service ne se produit lorsqu'un centre de données est hors service.

## Topologies <a href="#kubernetesarchitecture-topologies" id="kubernetesarchitecture-topologies"></a>

### Topologie de calcul <a href="#kubernetesarchitecture-topologiedecalcul" id="kubernetesarchitecture-topologiedecalcul"></a>

**cegedim.cloud** fournit une topologie de calcul basée sur :

* Région : une paire de centres de données
* Area : isolation du réseau d'infrastructure entre les locataires
* Zones de disponibilité : à l'intérieur d'une Area, infrastructure isolée pour le calcul et le stockage.

<figure><picture><source srcset="https://1991151216-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fu3cmMjeBxFoEweG69ePZ%2Fuploads%2Fgit-blob-68db116120e201cd71d01155562fb03442d30cb6%2Fdarkfr.png?alt=media" media="(prefers-color-scheme: dark)"><img src="https://1991151216-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fu3cmMjeBxFoEweG69ePZ%2Fuploads%2Fgit-blob-4be9a0b770be1f1b65b8192cd7b8d8365f72cd5c%2Flightfr.png?alt=media" alt="" width="563"></picture><figcaption><p>Topologie de calcul</p></figcaption></figure>

### Topologies des clusters Kubernetes <a href="#kubernetesarchitecture-topologiesdesclusterskubernetes" id="kubernetesarchitecture-topologiesdesclusterskubernetes"></a>

Les clusters Kubernetes peuvent être déployés à l'aide de 2 topologies :

<table data-full-width="true"><thead><tr><th>Topologies</th><th>Centre de données des masters</th><th>Centre de données des workers</th><th>Zones de disponibilité des workers</th><th>Zones de disponibilité du cluster</th><th data-type="checkbox">Protection reprise après sinistre</th><th>Recovery Time Objective (RTO)</th></tr></thead><tbody><tr><td>Standard</td><td>1</td><td>1</td><td>2</td><td>2</td><td>true</td><td>4h</td></tr><tr><td>Haute Disponibilité</td><td>3</td><td>2</td><td>3</td><td>4</td><td>true</td><td>0 - 15 min</td></tr></tbody></table>

En fonction de vos exigences en termes de RTO et de coûts, vous pouvez choisir la topologie la mieux adaptée à vos besoins.

### Disponibilité des topologies

<table data-full-width="true"><thead><tr><th>Topology</th><th data-type="checkbox">EB-EMEA</th><th data-type="checkbox">EB-HDS</th><th data-type="checkbox">ET-EMEA</th><th data-type="checkbox">ET-HDS</th></tr></thead><tbody><tr><td>Standard</td><td>true</td><td>true</td><td>true</td><td>true</td></tr><tr><td>High Availability</td><td>true</td><td>false</td><td>true</td><td>false</td></tr></tbody></table>

Pour plus de détails sur la topologie de haute disponibilité, veuillez suivre cette page : [haute-disponibilite](https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-didacticiels/haute-disponibilite "mention")

### Clés de topologie <a href="#kubernetesarchitecture-clesdetopologie" id="kubernetesarchitecture-clesdetopologie"></a>

**cegedim.cloud** utilise des clés topologiques standard :

<table><thead><tr><th width="457">Clé</th><th>Composant</th></tr></thead><tbody><tr><td>topology.kubernetes.io/region</td><td>Région</td></tr><tr><td>topology.kubernetes.io/zone</td><td>Zone de disponibilité</td></tr><tr><td>kubernetes.io/hostname</td><td>FQDN du noeud</td></tr></tbody></table>

## Composants et versions <a href="#kubernetesarchitecture-composantsetversions" id="kubernetesarchitecture-composantsetversions"></a>

**cegedim.cloud** utilise **RKE2** (Rancher Kubernetes Engine 2) comme distribution Kubernetes. RKE2 est une distribution Kubernetes entièrement conforme qui se concentre sur la sécurité et la conformité dans le secteur du gouvernement fédéral américain.

Voici la liste des composants et des outils qui sont déployés dans un cluster standard livré :

| Composants              | Versions                                          |
| ----------------------- | ------------------------------------------------- |
| Distribution Kubernetes | RKE2                                              |
| Rancher                 | 2.12                                              |
| Kubernetes              | 1.33                                              |
| Ingress controllers     | ingress-nginx 1.12.1, traefik 3.3.4, istio 1.24.1 |
| Prometheus              | 2.53.1                                            |
| Grafana                 | 11.1.0                                            |
| Helm                    | 3.17.0                                            |
| CSI Ceph                | 3.14.0                                            |
| Node OS                 | Ubuntu 24.04                                      |

## Architecture réseau <a href="#kubernetesarchitecture-architecturereseau" id="kubernetesarchitecture-architecturereseau"></a>

{% hint style="info" %}
L'architecture réseau suivante est décrite en utilisant le **contrôleur ingress Nginx**. La configuration est légèrement différente avec Traefik ou Istio, mais l'architecture globale et les concepts restent les mêmes.
{% endhint %}

Voici un schéma avec tous les composants du réseau expliqués :

### Flux sortants <a href="#kubernetesarchitecture-fluxsortants" id="kubernetesarchitecture-fluxsortants"></a>

<figure><img src="https://1991151216-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fu3cmMjeBxFoEweG69ePZ%2Fuploads%2Fgit-blob-9357d430e42b6f04a40c5d0a6dfac66e15aad4b1%2Fk8s-network-outbound.png?alt=media" alt=""><figcaption></figcaption></figure>

* Deux pods de 2 namespaces appartenant au même projet Rancher peuvent communiquer entièrement entre eux.
* Deux pods de 2 namespaces appartenant à deux projets Rancher différents ne peuvent pas communiquer à moins que l'utilisateur ne définisse une Network Policy dédiée à ce besoin.
* Les pods d'un projet Rancher nommé System peuvent communiquer avec les pods d'autres projets Rancher.
* Les pods ne peuvent envoyer des requêtes qu'aux serveurs du même VLAN, à moins qu'une règle d'ouverture de réseau spécifique ne soit configurée entre les deux VLANs.
* Les pods ne peuvent pas envoyer de requêtes à Internet à moins qu'un proxy ne soit configuré à l'intérieur du pod ou qu'une règle d'ouverture de réseau spécifique ne soit configurée pour le VLAN concerné.

### Flux entrants <a href="#kubernetesarchitecture-fluxentrants" id="kubernetesarchitecture-fluxentrants"></a>

<figure><img src="https://1991151216-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fu3cmMjeBxFoEweG69ePZ%2Fuploads%2Fgit-blob-aed2ce31df1c1c197f4e1a8c4026f9747ef9263d%2Fk8s-network-inbound.png?alt=media" alt=""><figcaption></figcaption></figure>

* Les requêtes vers le serveur kube api-server peuvent faire l'objet d'un reverse proxy par l'URL Rancher.
* La charge de travail hébergée par les pods ne peut pas être directement accessible depuis l'extérieur du cluster K8S, mais via une couche ingress pour le protocole HTTP ou via un service NodePort pour le protocole TCP avec un Load Balancer respectif.

### Ingress Controller : nginx <a href="#kubernetesarchitecture-ingresscontroller-nginx" id="kubernetesarchitecture-ingresscontroller-nginx"></a>

nginx est l'ingress controller déployé pour exposer vos workloads. Vous pouvez trouver la documentation pertinente sur le Github officiel à l'adresse :

{% embed url="<https://github.com/nginxinc/kubernetes-ingress>" %}

Deux ingress controllers sont déployés :

* Un exposé au réseau interne de Cegedim
  * Nom de la charge de travail : nginx-int-ingress-nginx-controller
  * Écoute sur chaque nœud ingress sur le port :80
  * Classe d'entrée : "nginx" (par défaut, aucune classe d'entrée ne doit être spécifiée)
* Un exposé à internet
  * Nom de la charge de travail : nginx-ext-ingress-nginx-controller
  * Écoute sur chaque nœud ingress sur le port :8081
  * Classe d'entrée : nginx-ext
    * en utilisant l'annotation : kubernetes.io/ingress.class: "nginx-ext"

### Équilibrage de charge, DNS et certificats <a href="#kubernetesarchitecture-equilibragedecharge-dnsetcertificats" id="kubernetesarchitecture-equilibragedecharge-dnsetcertificats"></a>

Un cluster K8s est livré avec :

* Un Elastic Secured Endpoint, géré par des appliances F5, exposant la charge de travail K8s au réseau interne de Cegedim (une fois que vous êtes connecté au LAN de Cegedim, soit physiquement, soit par VPN).
* Une résolution DNS `*.<votreclustername>.ccs.cegedim.cloud` vers ce point d'accès.
* Un certificat SSL `*.<votreclustername>.ccs.cegedim.cloud` configuré

### Demande de configuration spécifique <a href="#kubernetesarchitecture-demandedeconfigurationspecifique" id="kubernetesarchitecture-demandedeconfigurationspecifique"></a>

Vous pouvez utiliser ITCare en cas de besoin d'une configuration spécifique :

* Exposition de vos charges de travail à Internet ou à un lien privé
* Utilisation d'un FQDN spécifique pour déployer votre charge de travail
* Utilisation d'un certificat spécifique pour déployer votre charge de travail
* Utilisation de Traefik comme fournisseur Ingress au lieu de nginx
* Ajout d'autres fournisseurs Ingress
* Accès aux ressources en dehors du cluster

## Options de Personnalisation du Cluster <a href="#kubernetesarchitecture-optionsdepersonnalisationducluster" id="kubernetesarchitecture-optionsdepersonnalisationducluster"></a>

Lors de la création d'un nouveau cluster Kubernetes, **cegedim.cloud** vous offre la flexibilité de personnaliser les composants réseau clés en fonction de vos besoins spécifiques et des caractéristiques de vos charges de travail.

### Sélection du Fournisseur CNI <a href="#kubernetesarchitecture-selectiondufournisseurcni" id="kubernetesarchitecture-selectiondufournisseurcni"></a>

Vous pouvez sélectionner parmi les fournisseurs de Container Network Interface (CNI) suivants lors du provisionnement de votre cluster :

| Fournisseur CNI | Description                                                                                      | Nœuds Maximum |
| --------------- | ------------------------------------------------------------------------------------------------ | ------------- |
| **Canal**       | Combinaison de Calico et Flannel, fournissant l'application de politiques et un réseau simplifié | 200 nœuds     |
| **Calico**      | Solution de réseau avancée et de politique réseau avec haute évolutivité                         | 2 000 nœuds   |
| **Cilium**      | Réseau, observabilité et sécurité basés sur eBPF avec hautes performances                        | 2 000 nœuds   |

{% hint style="info" %}
La sélection du fournisseur CNI doit être basée sur les exigences de taille de votre cluster et vos besoins réseau spécifiques. Pour les clusters nécessitant plus de 200 nœuds, Calico ou Cilium est recommandé.
{% endhint %}

{% hint style="warning" %}
Lors de l'utilisation de **Cilium** comme fournisseur CNI, **kube-proxy** n'est pas déployé. Cilium remplace la fonctionnalité de kube-proxy par son implémentation basée sur eBPF, offrant des performances et une efficacité améliorées.
{% endhint %}

#### Quand Choisir Chaque Fournisseur CNI

**Canal (Calico + Flannel)**

* Déploiements standard nécessitant jusqu'à 200 nœuds
* Stabilité éprouvée avec réseau simplifié
* Exigences de conformité FIPS 140-2
* Choix par défaut pour la plupart des cas d'usage

**Calico**

* Déploiements à grande échelle (200-2 000 nœuds)
* Exigences avancées de politique réseau
* Exigences de haute évolutivité

**Cilium**

* Charges de travail haute performance nécessitant un débit maximum
* Besoins avancés d'observabilité et de surveillance
* Fonctionnalités de réseau et de sécurité basées sur eBPF
* Déploiements à grande échelle (200-2 000 nœuds) avec performances améliorées
* Clusters où l'élimination de la surcharge de kube-proxy est bénéfique

### Sélection du Fournisseur Ingress <a href="#kubernetesarchitecture-selectiondufournisseuringress" id="kubernetesarchitecture-selectiondufournisseuringress"></a>

Vous pouvez choisir votre contrôleur Ingress préféré pour gérer l'accès externe aux services au sein de votre cluster :

| Fournisseur Ingress | Description                                                                                                                        |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Nginx**           | Contrôleur ingress standard de l'industrie avec des fonctionnalités robustes et un large support communautaire (option par défaut) |
| **Traefik**         | Contrôleur ingress cloud-native moderne avec découverte automatique des services                                                   |
| **Istio**           | Service mesh fournissant une gestion avancée du trafic, de la sécurité et des capacités d'observabilité                            |

{% hint style="info" %}
Pour demander un fournisseur CNI ou Ingress spécifique lors de la création du cluster, veuillez spécifier vos besoins via ITCare lors de la commande de votre cluster Kubernetes.
{% endhint %}

## Hardening des clusters <a href="#kubernetesarchitecture-hardeningdesclusters" id="kubernetesarchitecture-hardeningdesclusters"></a>

Pour plus d'informations concernant le hardening de Kubernetes, nous vous invitons à consulter cette page : [hardening](https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-architecture/hardening "mention")

## Stockage persistant <a href="#kubernetesarchitecture-stockagepersistant" id="kubernetesarchitecture-stockagepersistant"></a>

Pour plus d'informations sur la solution de stockage persistant disponible pour les clusters Kubernetes de **cegedim.cloud**, veuillez suivre cette page : [stockage-persistant](https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-architecture/stockage-persistant "mention")


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.