LogoLogo
cegedim.cloudITCareAPIPrivacy
Français
Français
  • Documentation
  • ITCare
    • ITCare, c'est quoi ?
      • Débuter avec ITCare
      • Démos
    • Enercare
      • Empreinte carbone
    • Notes de mise à jour
  • ITCare API
    • Aperçu
    • Authentication
    • Erreurs
    • Pagination
    • Reference API
      • Démarrage rapide
      • Analytics
        • Matomo
      • Changes
        • Changes
      • Compute
        • Application Servers
        • Backup Policies
        • Containers
        • Environments
        • Instances
        • Platform
        • Resource Filters
        • Resource Types
        • Resources
        • Services
        • Statuses
        • Tag Keys
        • Tag Values
        • Types
      • Databases
        • Databases
        • MariaDB
        • OpenSearch
        • PostgreSQL
        • Redis
        • SQL Server
      • Hardwares
        • Hardwares
      • Messaging
        • Apache Kafka
        • Message Brokers
        • RabbitMQ
      • Networking
        • Domains
        • Load Balancers
        • Network Clusters
        • Networks
      • Operations
        • Actions
        • Operations
      • Storage
        • Glusterfs
        • Overdrive
      • Topology
        • Topology
  • Services
    • Produits
    • Politique de support
    • Politique de patch
    • RACI
  • Analytique
    • Matomo
      • Matomo - Architecture
      • Matomo - Didacticiels
  • Calcul
    • Instances virtuelles
      • Instances virtuelles - Architectures
        • Linux - Renforcement
      • Instances virtuelles - Didacticiels
    • Conteneurs (K8s)
      • K8s - Architecture
        • Hardening
        • Stockage Persistant
      • K8s - Didacticiels
        • Haute Disponibilité
  • Bases de données
    • MariaDB
      • MariaDB - Architecture
      • MariaDB - Didacticiels
    • OpenSearch
      • OpenSearch - Architecture
        • v2 - Changements
      • OpenSearch - Didacticiels
    • PostgreSQL
      • PostgreSQL - Architecture
      • PostgreSQL - Didacticiels
      • PostgreSQL - Mise à jour
    • Redis
      • Redis - Architecture
      • Redis - Didacticiels
      • Redis - Mise à jour
    • SQL Server
      • SQL Server - Architecture
      • SQL Server - Didacticiels
  • Message
    • Apache Kafka
      • Apache Kafka - Architecture
      • Apache Kafka - Didacticiels
      • Apache Kafka - Mise à jour
    • RabbitMQ
      • RabbitMQ - Architecture
      • RabbitMQ - Didacticiels
    • SMS
      • SMS - Didacticiels
  • Securité
    • Advanced Vulnerability Assessment
    • Bot Defense
      • Bot Defense - Architecture
    • Campagne de Phishing
    • Data Masking
      • Data Masking - Didacticiels
  • Surveillance
    • ExtraHop
  • Stockage
    • GlusterFS
      • GlusterFS - Architecture
      • GlusterFS - Didacticiels
    • OverDrive
      • OverDrive - Architecture
    • Stockage Objet
      • Stockage Objet - Architecture
        • Compatibilité API S3
        • Limitation et bonnes pratiques
        • URL pré-signée
        • Politiques de Buckets
        • Configuration de cycle de vie
        • Object Lock
      • Stockage Objet - Didacticiels
        • Gérer des Objects Users
        • Gérer des versions dans un Bucket
        • Gérer l'accès à un Bucket
Powered by GitBook
On this page
  • Topologies
  • Topologie de calcul
  • Topologies des clusters Kubernetes
  • Disponibilité des topologies
  • Clés de topologie
  • Composants et versions
  • Architecture réseau
  • Flux entrants
  • Ingress Controller : nginx
  • Équilibrage de charge, DNS et certificats
  • Demande de configuration spécifique
  • Hardening des clusters
  • Stockage persistant
Export as PDF
  1. Calcul
  2. Conteneurs (K8s)

K8s - Architecture

PreviousConteneurs (K8s)NextHardening

Last updated 24 days ago

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é.

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 zone, 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 :

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)

Standard

1

1

2

2

4h

Haute Disponibilité

3

2

3

4

0 - 5 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

Topology
EB-EMEA
EB-HDS
ET-EMEA
ET-HDS

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 :

Clé
Composant

topology.kubernetes.io/region

Région

topology.kubernetes.io/zone

Zone de disponibilité

kubernetes.io/hostname

FQDN du noeud

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.

Composants et versions

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

Composants
Versions

Rancher

2.10.3

Kubernetes

1.31

Ingress controllers

ingress-nginx 1.12.0, traefik 3.3.4, istio 1.20.3

Prometheus

2.42.0

Grafana

9.1.5

Helm

3.16.1

CSI Ceph

3.11.0

Node OS

Ubuntu 22.04

CNI - canal (Calico+Flannel)

3.29.0

Docker

27.1.2

Architecture réseau

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é.

Flux entrants

  • 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.

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

    • 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"

É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.cloud vers ce point d'accès.

  • Un certificat SSL *.<votreclustername>.ccs.cegedim.cloud configuré

Demande de configuration spécifique

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

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 cegedim.cloud de cegedim.cloud, veuillez suivre cette page : Stockage Persistant

LogoGitHub - nginxinc/kubernetes-ingress: NGINX and NGINX Plus Ingress Controllers for KubernetesGitHub
Topologie de calcul