cegedim.cloud propose désormais une plateforme de stockage Ceph multi-locataires en tant que fournisseur de CSI avec les spécifications suivantes :
Les données sont répliquées 4 fois et réparties uniformément (à l'aide de Ceph Crush Map) sur 2 centres de données afin de garantir que, dans les scénarios de catastrophe, 2 répliques de données sont toujours disponibles.
Chaque cluster Kubernetes, en tant que client Ceph, dispose de son propre pool de données sur le serveur Ceph et consomme des services avec ses propres identifiants.
Seul le RBD Ceph CSI est fourni pour le moment.
De plus amples informations sur le Ceph CSI sont disponibles via le lien ci-dessous :
cegedim.cloud utilise External Snapshotter pour prendre des clichés et restaurer le PVC de vos clusters Kubernetes.
Toutes les informations relatives à cette application sont disponibles à l'adresse suivante :
Il est recommandé de nommer la classe d'instantanés d'après la classe de stockage. Il suffit d'exécuter la commande ci-dessous pour vérifier :
Pour répertorier tous les CSI disponibles dans un cluster Kubernetes, procédez comme suit :
Voici une correspondance entre la classe de stockage et le CSI :
Composant | Version |
---|---|
Nom | Description |
---|---|
EB | ET | |
---|---|---|
CSI Ceph-rbd | |
---|---|
Classes de stockage | CSI |
---|---|
Ceph Cluster
17.2.5
CSI Ceph
3.9.0
cgdm-rwo
Utiliser CSI Ceph rbd pour provisioner des volumes persistants ReadWriteOnce
cgdm-rwo
Ceph RBD
Réplication
x4
x4
Tolérance de panne : Une AZ indisponible
Tolérance de panne : Un DC indisponible
Approvisionnement de nouveaux PV
Remonter le PV existant
Compatible avec toutes les applications K8S
Montage multiple (RWX)
Redimensionnable
Aperçu
Tolérance de panne : perte de 1 AZ
Tolérance de panne : perte de 1 DC
Compatible avec K8S 1.22+
Compatible avec K8S 1.22-
Kubernetes dispose de fonctionnalités et de mécanismes intégrés pour maintenir en bonne santé les nœuds et les workoads kubernetes :
kube-scheduler décide sur quels nœuds placer les pods en fonction des ressources demandées par les pods et des ressources non réservées des nœuds.
kubelet Out-Of-Memory tue les pods qui consomment plus de ressources que les valeurs limitées définies dans la spécification (OOM killed).
Pour quelque raison que ce soit, si le nœud est à court de ressources, kubelet expulse les pods afin d'alléger la pression sur les nœuds (éviction des pods). La décision d'éviction des pods est basée sur la qualité de service des pods.
Gardez à l'esprit que cegedim.cloud fournit des clusters Kubernetes standard avec ces fonctionnalités et a qualifié les documentations officielles de Kubernetes ci-dessous :
Le problème se situe au niveau de l'application dans la vie réelle :
toutes les technologies ne sont pas nativement compatibles avec les conteneurs
les mesures d'utilisation des ressources collectées par le kubelet (ou l'exportateur de nœuds, etc.) ne sont pas en temps réel
les mesures d'utilisation des ressources ne sont pas prises en compte par le planificateur kube
kubelet, en tant que processus Linux, n'est pas toujours le processus le plus prioritaire, en particulier lorsque les nœuds n'ont plus de CPU.
L'incapacité à gérer les contraintes de ressources sur les nœuds par kubelet conduit à des défaillances de nœuds et au redéploiement de toutes les charges de travail correspondantes. Dans le pire des cas, un effet domino sur la défaillance des nœuds peut se produire.
cegedim.cloud fournit une solution de hardening appelée cgdm-hardening :
Un esclave de hardening de pods par nœuds de travail : écrit la consommation de CPU et de RAM dans une base de données centralisée.
Un pod de hardening-maître déployé sur les nœuds maîtres : il lit les métriques dans la base de données et prend des mesures en cas de crise.
L'empreinte de la pile de hardening sur les ressources est très faible
Le pod Hardening-master
peut agir selon deux modes :
Mode préventif (en tant qu'assistant du planificateur kube, mode par défaut) :
Place le taint cegedim.io/overload=true:NoSchedule pour éviter de placer plus de pods sur des nœuds sous pression (85% RAM ou 90% CPU). Lorsque le CPU est inférieur à 85% et que la RAM est inférieure à 80%, l'altération est supprimée.
Mode de protection (en tant qu'assistant du contrôleur de kube) :
Lorsque la consommation de RAM atteint 95 %, il tue les pods les plus récents, l'un après l'autre, pour soulager la pression. Il n'est pas activé par défaut.
Vous ne devez jamais utiliser la wildcard tolérance dans les applications, sinon l'effet préventif de cette solution ne sera pas valable.
Limitation : cette solution ne permet pas de protéger les nœuds qui tombent en panne en raison d'un pic d'utilisation extrêmement élevé du CPU pendant une période de temps très courte.
Le nouveau cluster Kubernetes sera provisionné avec le hardeing préventif activé.
Si les charges de travail déployées par les clients entraînent un grand nombre de défaillances de nœuds (TLS_K8_NODES), le mode de protection sera activé.
Le client peut désactiver ce hardening en créant un ticket requête dans ITCare.
Par conséquent, la vérification TLS_K8_NODES de centreon au niveau du cluster et la vérification de l'état de santé de centreon sur les nœuds de travail seront désactivées.
Cela signifie que les clients doivent redémarrer eux-mêmes les nœuds en cas de crise.
Le client peut réactiver ce hardening en faisant un ticket requête ITCare à tout moment.
Il existe 3 topologies possibles pour le cluster K8s fourni par cegedim.cloud :
Standalone : les charges de travail sont déployées dans un seul centre de données sans plan de reprise après sinistre.
Standard : les charges de travail sont toujours déployées dans un seul centre de données, mais elles sont protégées contre un désastre 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 dans deux centres de données et aucune interruption des services en cas de sinistre du centre de données ne peut être obtenue avec un déploiement multi-réplica correctement distribué.
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 zone, infrastructure isolée pour le calcul et le stockage.
Les clusters Kubernetes peuvent être déployés à l'aide de 2 topologies :
En fonction de vos exigences en termes de RTO et de coûts, vous pouvez choisir la topologie la mieux adaptée à vos besoins.
Pour plus de détails sur la topologie de haute disponibilité, veuillez suivre cette page : Haute Disponibilité
cegedim.cloud utilise des clés topologiques standard :
Depuis Kubernetes > 1.20, failure-domain.beta.kubernetes.io/zone est obsolète mais reste disponible en cas de préexistence. Seul topology.kubernetes.io/zone sera officiellement maintenu.
Voici la liste des composants et des outils qui sont déployés dans un cluster standard livré :
Voici un schéma avec tous les composants du réseau expliqués :
Deux pods de 2 namespaces appartenant au même projet Rancher peuvent communiquer entre eux.
Deux pods de 2 namespaces appartenant à deux projets Rancher différents ne peuvent pas communiquer entre eux à 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é.
Les requêtes vers le serveur api kube peuvent faire l'objet d'une proxy inverse 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 d'entrée pour le protocole HTTP ou via un service NodePort pour le protocole TCP avec un équilibreur de charge respectif.
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
ingress controller nginx
écoute sur chaque nœud de travail sur le port :80
il s'agit de la classe d'entrée par défaut (aucune classe d'entrée ne doit être spécifiée).
Un exposé à internet
nginx ingress controller - vous pouvez demander à avoir un ingress controller externe pour nginx.
écoute de chaque nœud de travail sur le port : 8081
cette ingress classe est : nginx-ext
en utilisant l'annotation : kubernetes.io/ingress.class:"nginx-ext"
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é
Vous pouvez utiliser ITCare en cas de besoin d'une configuration spécifique :
Exposition de vos charges de travail à l'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 d'intrusion au lieu de nginx
Ajout d'autres fournisseurs d'entrée
Accès aux ressources en dehors du cluster
Pour plus d'informations concernant le hardening de Kubernetes, nous vous invitons à consulter cette page : Hardening
Pour plus d'informations sur la solution de stockage persistant disponible pour cegedim.cloud de cegedim.cloud, veuillez suivre cette page : Stockage Persistant
Topologies | Centre de données des masters | Centre de données des workers | Zones de disponibilité des workers | Zones de disponibilité du cluster | Protection reprise après sinistre | Recovery Time Objective (RTO) |
---|---|---|---|---|---|---|
Topology | EB-EMEA | EB-HDS | ET-EMEA | ET-HDS |
---|---|---|---|---|
Clé | Composant |
---|---|
Composants | Versions |
---|---|
Standard
1
1
2
2
4h
Haute Disponibilité
3
2
3
4
0 - 5 min
Standard
High Availability
topology.kubernetes.io/region
Région
topology.kubernetes.io/zone
Zone de disponibilité
kubernetes.io/hostname
FQDN du noeud
Rancher
2.7.6
Kubernetes
1.26
Ingress controllers NGINX
1.9.0
Prometheus
2.38.0
Grafana
9.1.5
Helm
3.11.3
CSI Ceph
3.9.0
Node OS
Ubuntu 20.04
CNI - canal (Calico+Flannel)
3.25
Docker
20.10.8