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
Topologie de calcul
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.
Topologies des clusters Kubernetes
Les clusters Kubernetes peuvent être déployés à l'aide de 2 topologies :
Standard
1
1
2
2
4h
Haute Disponibilité
3
2
3
4
0 - 15 min
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
Standard
High Availability
Pour plus de détails sur la topologie de haute disponibilité, veuillez suivre cette page : Haute Disponibilité
Clés de topologie
cegedim.cloud utilise des clés topologiques standard :
topology.kubernetes.io/region
Région
topology.kubernetes.io/zone
Zone de disponibilité
kubernetes.io/hostname
FQDN du noeud
Composants et versions
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é :
Distribution Kubernetes
RKE2
Rancher
2.11
Kubernetes
1.32
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
Voici un schéma avec tous les composants du réseau expliqués :
Flux sortants
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
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
nginx est l'ingress controller déployé pour exposer vos workloads. Vous pouvez trouver la documentation pertinente sur le Github officiel à l'adresse :
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
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.cloudvers ce point d'accès.Un certificat SSL
*.<votreclustername>.ccs.cegedim.cloudconfiguré
Demande de configuration spécifique
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
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
Vous pouvez sélectionner parmi les fournisseurs de Container Network Interface (CNI) suivants lors du provisionnement de votre cluster :
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
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.
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
Vous pouvez choisir votre contrôleur Ingress préféré pour gérer l'accès externe aux services au sein de votre cluster :
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é
Hardening des clusters
Pour plus d'informations concernant le hardening de Kubernetes, nous vous invitons à consulter cette page : Hardening
Stockage persistant
Pour plus d'informations sur la solution de stockage persistant disponible pour les clusters Kubernetes de cegedim.cloud, veuillez suivre cette page : Stockage Persistant
Last updated