Description

cegedim.cloud fournit des clusters Kubernetes gérés, avec le plus haut niveau de sécurité et de résilience intégré.

En utilisant ces clusters, vous pouvez déployer vos workloads Kubernetes standards dans les centres de données cegedim.cloud afin de maximiser la disponibilité de vos applications.

cegedim.cloud fournit également une console Rancher, où vous pouvez gérer vos workloads, et configurer les capacités d'observabilité intégrées (Logging et Métrologie) pour la connecter à vos propres plateformes (Grafana, ElasticSearch...).

Container en tant que Service

Les principaux objectifs du projet Container en tant que Service sont :

• Capacité à fournir des clusters Kubernetes de dernière génération à la demande.

• Application Stateful supportée

• Prise en charge des volumes persistants avec Auto-Provisioning et Haute Disponibilité

• Respecter les normes réseau, les règles de stockage et de sécurité.

• Une sécurité renforcée

• Système de surveillance et de métriques intégré à la demande pour chaque application

• Prise en charge des règles de réseau dynamiques

Pour plus d'information, veuillez consulter la page K8s - Architecture.

Facturation

La facturation est mensuelle et basée sur le nombre de nœuds et sur les coûts supplémentaires tel que le stockage et la sauvegarde.

L'estimation des coûts pour un cluster Kubernetes est disponible via votre Service Delivery Manager.

Contexte et motivation

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.

La solution cegedim.cloud

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.

Comment désactiver / activer le hardening

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

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 :

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

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 :

Composants et versions

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

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

Introduction

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 :

Versions

Classe de stockage

Haute disponibilité

Caractéristiques du CSI

Snapshot et restauration de PVC dans Kubernetes

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 :

Comment savoir si j'ai un snapshotclass actif sur mon cluster ?

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 :

$ kubectl get sc
NAME                 PROVISIONER           RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
cgdm-rwo (default)   rbd.csi.ceph.com      Delete          Immediate           true                   57d
$ kubectl get  volumesnapshotclass
NAME       DRIVER                DELETIONPOLICY   AGE
cgdm-rwo   rbd.csi.ceph.com      Delete           36d

Comment lister les CSI disponibles dans mon cluster ?

Pour répertorier tous les CSI disponibles dans un cluster Kubernetes, procédez comme suit :

kubectl get sc
NAME               PROVISIONER      RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
cgdm-rwo (default) rbd.csi.ceph.com Delete        Immediate         true                 42d

Voici une correspondance entre la classe de stockage et le CSI :

Débuter

Se connecter à l'UI Rancher

cegedim.cloud utilise Rancher comme plateforme de gestion de Kubernetes.

Rancher supporte la même authentification SSO que ITCare.

Instances Rancher

Selon la localisation de votre cluster, Rancher est accessible avec les URL suivantes :

Dans ITCare, vous pouvez trouver l'URL de votre cluster dans la page de détail de celui-ci :

Se connecter à Rancher

Rancher demandera une authentification lors de la première connexion : cliquez simplement sur "Login with Keycloak".

Vous serez ensuite redirigé vers la mire de connexion :

Une fois connecté, vous devriez avoir un écran listant tous les clusters auxquels vous avez accès :

Si l'interface se coince après l'authentification, merci d'essayer ces liens :

• https://k8s-et.cegedim.cloud/dashboard/home

• https://k8s-et.cegedim.cloud/dashboard/home

Si lors de la première connexion vous ne voyez pas votre cluster dans la liste des clusters, vous pouvez vous déconnecter et vous reconnecter.

Gérer vos préférences

Vous pouvez gérer vos préférences d'interface utilisateur (thème sombre, nombre de lignes par tableau...) en configurant vos préférences utilisateur. Veuillez vous référer ici à la documentation complète ci-dessous.

Configurer kubectl

Afin de se connecter au cluster en utilisant la CLI, vous avez deux options :

• par kubectl normal à distance

• en utilisant rancher online kubectl.

Les deux sont disponibles en accédant à la page "cluster" dans Rancher.

Il y a deux façons de le faire :

• Cliquez sur le nom du cluster dans la liste des clusters.

• Cliquez sur le nom du cluster dans le menu supérieur gauche.

En utilisant le fichier de configuration kubectl

Une fois sur la page d'accueil du cluster, vous pouvez télécharger le "KubeConfig File" :

Ou bien juste copier le contenu du "Kubeconfig File" :

Cette configuration peut être mélangée avec d'autres configurations kubectl.

L'authentification peut être partagée avec tout cluster géré par la même instance de rancher.

Utilisation du cli web

Une fois sur la page d'accueil du cluster, vous pouvez utiliser le web CLI en cliquant sur l'icône ci-dessous:

Cela devrait lancer un shell web comme celui-ci :

Obtenir un jeton API

La gestion des jetons est disponible juste en dessous de l'avatar de l'utilisateur :

Portée des jetons

Il existe deux champs d'application :

• no-scope : global scope : utilisé pour interagir avec l'API globale de Rancher

• cluster-scoped : jeton dédié à l'accès à un cluster spécifique

Cycle de vie des jetons

Les jetons peuvent avoir des cycles de vie différents :

• Une durée de vie illimitée, il suivra le cycle de vie du compte qui lui est rattaché

• Une durée limitée

Gestion des nœuds

Redimensionner un cluster

Vous pouvez utiliser ITCare pour ajouter ou supprimer des nœuds à votre cluster.

Gérer les Namespaces

Comprendre les projets - Un concept de Rancher

Rancher gère les espaces de noms via project, qui est un concept n'existant spécifiquement que dans les clusters Kubernetes gérés par Rancher.

Le projet n'est pas une ressource native de Kubernetes. Par défaut, un cluster Kubernetes est provisionné avec 2 projets :

• System : contenant les espaces de noms des composants principaux comme : kube-system, etc.

• Default : contenant l'espace de noms "par défaut".

Les utilisateurs sont libres de créer d'autres projets si nécessaire. En se basant sur le niveau du projet, Rancher offre une automatisation intégrée comme : l'octroi de droits d'accès, l'isolation du réseau, etc.

Les utilisateurs sont fortement encouragés à classer les espaces de noms dans un projet.

Comment créer correctement un espace de noms

• Passer à la vue projet

• Créer un nouvel espace de noms à partir de la vue du projet

• Insérez un nom unique et remplissez les autres champs si nécessaire, puis cliquez sur "Créer"

Gestion des droits

cegedim.cloud recommande et supporte officiellement la gestion des droits d'accès via les groupes AD.

Seuls les groupes AD commençant par G_EMEA_* et G_K8_* sont connus par Rancher.

Par défaut, lors de la création d'un cluster :

• Le rôle d'utilisateur standard est donné au groupe G_K8_<NOM_DU_CLUSTER>_USERS qui contient les power users du Cloud associé.

• Le rôle d'administrateur est attribué au groupe G_K8_<NOM_DU_CLUSTER>_ADMINS qui est vide par défaut et peut être complété par des utilisateurs compétents et certifiés via un ticket ITCare vers l'équipe de support AD.

Par exemple, l’utilisateur user1@cegedim.com a besoin d’accès standard au cluster test-preprod, il doit faire une demande pour l'ajouter dans le groupe AD nommé G_K8_TEST_PREPROD_USERS.

Lorsque les utilisateurs créent un nouveau projet, en tant que propriétaire par défaut, ils sont libres de lier n'importe quel rôle à n'importe quel groupe AD dans le cadre de ce projet.

Si les rôles prédéfinis de Rancher ne peuvent pas répondre à vos besoins, veuillez contacter les administrateurs de votre cluster pour configurer un rolebinding personnalisé ou un clusterrolebinding.

Gérer les droits

Gestion des droits au niveau du projet

Dans cette partie, nous supposerons que les droits sont donnés à un groupe et non à un utilisateur.

Pour gérer les droits sur un projet, il existe deux moyens : L'interface utilisateur ou l'API.

L'un des rôles les plus élevés que vous pouvez attribuer est "Project Admin".

Utilisation de l'interface utilisateur

Éditez le projet dont vous êtes propriétaire ou sur lequel vous avez suffisamment de droits accordé par le propriétaire.

Sélectionnez le groupe et le rôle dans la formulaire.

Utilisation de l'API

En utilisant l'API, c'est assez simple. Vous aurez d'abord besoin de quelques paramètres :

• Obtenir l'ID du projet

Pour obtenir l'ID du projet, vous pouvez utiliser l'explorateur d'API en utilisant simplement le bouton "View in API".

curl --request GET \
 --url https://k8s-eb.cegedim.cloud/v3/projects \
 --header 'authorization: Bearer token-tttt:token-of-doom'

• Obtenir l'ID du rôle

Pour obtenir l'ID du rôle, il se peut que vous ne soyez pas autorisé à l'afficher via l'interface utilisateur, mais vous l'obtiendrez via cette requête API :

curl --request GET \
--url https://rancher-staging.cegedim.cloud/v3/roleTemplates?name=Project%20Admin\
--header 'authorization: Bearer token-tttt:token-of-doom'

• Donner des autorisations

En utilisant votre clé API, vous pouvez faire une demande POST pour créer le lien de rôle :

curl --request POST \
--url https://k8s-eb.cegedim.cloud/v3/projectRoleTemplateBindings \
--header 'authorization: Bearer token-tttt:token-of-doom' \
--header 'content-type: application/json' \
--data '{
"projectId": "c-6t7f4:p-d43l6",
"namespaceId":"",
"groupPrincipalId":"keycloakoidc_group_group://G_EMEA_DUPER_GROUP",
"roleTemplateId": "project-owner"
}'

Vérification de compatibilité avant une mise à jour de version Kubernetes

Contexte

Les version api de ressources Kubernetes peuvent être obsolètes, voire supprimés lors de la mise à jour de version Kubernetes.

Il y a une risque de cassure si vous avez des ressources avec une version api supprimé dans la nouvelle version de Kubernetes.

Pour éviter cela, une des solutions est d'utiliser l'outil "kubent" pour vérifier la compatibilité .

Kubent détecte les objets obsolètes du cluster Kubernetes. Vous devez migrer/modifier les ressources identifiés avant la mise à jour de version Kubernetes.

Démarrage rapide

Pour installer kubent :

sh -c "$(curl -sSL 'https://git.io/install-kubent')"

Pour identifier les objets obsolètes qui vont être supprimés dans la prochain version Kubernetes :

kubent [--context my-cluster]

Un exemple de l'output :

...
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND                       NAMESPACE      NAME                                   API_VERSION                         REPLACE_WITH (SINCE)
Ingress                    <undefined>     toto                                 networking.k8s.io/v1beta1           networking.k8s.io/v1 (1.19.0)
...

Dans ce tutoriel, si votre cluster est planifié pour une mise à jour vers version Kubernetes 1.22, vous devez migrer votre resource ingress nommé "toto" de version api networking.k8s.io/v1beta1 vers networking.k8s.io/v1 avant la mise à jour.

Cette migration peut impliquer une modification des champs supplémentaires de la ressource. Veillez consulter la documentation officielle :

Configurer le transfert et la centralisation des logs vers un cluster OpenSearch

Contexte

Dans cet exemple, nous allons configurer le transfert de logs d'un cluster Kubernetes vers un cluster OpenSearch.

• Le cluster OpenSearch est dans cet exemple my-cluster.es.cegedim.cloud

• Le nom de la sortie du cluster est my-cluster-output.

Configuration du logging Banzai

Dans Rancher, sous Logging > ClusterOutput et Logging > Output, modifiez la configuration YAML et changez ceci :

    port: 443
    log_es_400_reason: true # useful to debug when no log is received in Opne Search / ELK
    suppress_type_name: true
    # Add this if the target is an Open Search cluster
    default_elasticsearch_version: "7"
    verify_es_version_at_startup: false

ClusterFlow/ClusterOutput présentent de nombreux problèmes lors de l'envoi de logs à OpenSearch / ELK cluster : Conflit de type de valeur attendue avec la même clé (par exemple, une valeur changée de "long" à "string" sera rejetée par OpenSearch / ELK Cluster).

Cela peut se produire isi vous avez activé Dynatrace.

Voici des exemples complets de la spécification ClusterOutput/Output pour ElasticSearch et OpenSearch :

spec:
  elasticsearch:
    buffer:
      chunk_limit_size: 256m
      compress: gzip
      flush_at_shutdown: true
      flush_interval: 60s
      flush_mode: interval
      flush_thread_count: 2
      queue_limit_length: 96
      retry_forever: true
      type: file
    flatten_hashes: true
    host: {{ ELK URL }}
    include_tag_key: true
    log_es_400_reason: true
    logstash_format: true
    logstash_prefix: {{ prefix }}
    password:
      valueFrom:
        secretKeyRef:
          key: password
          name: {{ ELK credentials }}
    port: 443
    reconnect_on_error: true
    reload_connections: false
    reload_on_failure: true
    request_timeout: 30s
    scheme: https
    ssl_verify: false
    suppress_type_name: true
    user: {{ username }}
    default_elasticsearch_version: "7"
    verify_es_version_at_startup: false

spec:
  elasticsearch:
    buffer:
      chunk_limit_size: 256m
      compress: gzip
      flush_at_shutdown: true
      flush_interval: 60s
      flush_mode: interval
      flush_thread_count: 2
      queue_limit_length: 96
      retry_forever: true
      type: file
    flatten_hashes: true
    host: {{ ELK URL }}
    include_tag_key: true
    log_es_400_reason: true
    logstash_format: true
    logstash_prefix: {{ prefix }}
    password:
      valueFrom:
        secretKeyRef:
          key: password
          name: {{ ELK credentials }}
    port: 443
    reconnect_on_error: true
    reload_connections: false
    reload_on_failure: true
    request_timeout: 30s
    scheme: https
    ssl_verify: false
    suppress_type_name: true
    user: {{ username }}

Recommandations en matière de migration

Il y a deux options :

• Migration vers Flow/ClusterOutput : poussera tous les logs des espaces de noms vers le même index OpenSearch.

• Migration vers Flow/Output : poussera les logs des espaces de noms séparés vers des index OpenSearch dédiés.

Migration de ClusterFlow/ClusterOutput vers Flow/ClusterOutput

Créer un fichier avec tous les espaces de noms :

mkdir -p log-config
kubectl get ns --no-headers |grep -v kube-system|\
grep -v cattle|\
grep -v dynatrace|\
grep -v ceg-it|\
grep -v ingress-nginx|awk '{print $1}' > namespaces.txt
# review namespaces.txtD

Créer des fichiers K8s YAML pour configurer les logs sur tous les espaces de noms :

while read LOG_NS
do
  cat <<EOF>> log-config/"configuration-"$LOG_NS".yaml"
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: all-namespace-logs
  namespace: $LOG_NS
spec:
  filters:
  - dedot:
      de_dot_nested: true
      de_dot_separator: '-'
  globalOutputRefs:
  - my-cluster-output
EOF
done < namespaces.txt
# review content of folder log-config

Appliquer la configuration :

kubectl apply -f log-config

Migration de ClusterFlow/ClusterOutput vers Flow/Output

Créer un fichier avec tous les espaces de noms :

mkdir -p log-config
kubectl get ns --no-headers |grep -v kube-system|\
grep -v cattle|\
grep -v dynatrace|\
grep -v ceg-it|\
grep -v ingress-nginx|awk '{print $1}' > namespaces.txt
# review namespace.txt

Créer des fichiers K8S YAML :

while read LOG_NS
do
  kubectl -n cattle-logging-system get secret {{ ELK credentials }} -o json \
 | jq 'del(.metadata["namespace","creationTimestamp","resourceVersion","selfLink","uid"])' \
 | kubectl apply -n $LOG_NS -f -
  cat <<EOF>> log-config/"configuration-"$LOG_NS".yaml"
apiVersion: logging.banzaicloud.io/v1beta1
kind: Output
metadata:
  name: all-ns
  namespace: $LOG_NS
spec:
  elasticsearch:
    buffer:
      chunk_limit_size: 256m
      compress: gzip
      flush_at_shutdown: true
      flush_interval: 60s
      flush_mode: interval
      flush_thread_count: 2
      queue_limit_length: 96
      retry_forever: true
      type: file
    flatten_hashes: true
    host: my-cluster.es.cegedim.cloud
    include_tag_key: true
    log_es_400_reason: true
    logstash_format: true
    logstash_prefix: {{ prefix }}
    password:
      valueFrom:
        secretKeyRef:
          key: password
          name: {{ ELK credentials }}
    port: 443
    reconnect_on_error: true
    reload_connections: false
    reload_on_failure: true
    request_timeout: 30s
    scheme: https
    ssl_verify: false
    suppress_type_name: true
    user: {{ username }}
---
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: all-namespace-logs
  namespace: $LOG_NS
spec:
  filters:
  - dedot:
      de_dot_nested: true
      de_dot_separator: '-'
  globalOutputRefs: []
  localOutputRefs:
  - all-ns
EOF
done < namespaces.txt
# review content of folder log-config

Appliquer la configuration :

kubectl apply -f log-config

Déboguer si la perte de logs persiste

Aucun tampon important ne devrait se produire si tout se passe bien. Vérifions le

kubectl -n cattle-logging-system get po -l app.kubernetes.io/name=fluentd -o name|awk '{print $1}'|xargs -I {} sh -c "kubectl -n cattle-logging-system exec {} -c fluentd -- du -hs /buffers"

Vérifions les 5 dernières lignes du journal de Fluentd :

kubectl -n cattle-logging-system get po -l app.kubernetes.io/name=fluentd -o name|awk '{print $1}'|xargs -I {} sh -c "kubectl -n cattle-logging-system exec {} -c fluentd -- tail -5  /fluentd/log/out"

Jetez un coup d'œil dans /fluentd/log/out à l'intérieur du pod fluentd, mais la plupart du temps, ce qui suit vous aidera :

kubectl -n cattle-logging-system get po -l app.kubernetes.io/component=fluentd --no-headers|awk '{print $1}'|xargs -I {} sh -c "kubectl -n cattle-logging-system exec -it  {} -c fluentd -- cat /fluentd/log/out|grep 'Rejected'"

2023-01-20 10:53:38 +0000 [warn]: #0 send an error event to @ERROR: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch [error type]: mapper_parsing_exception [reason]: 'failed to parse field [stack_trace] of type [text] in document with id 'L7fQzoUBIs35W4-JCcJQ'. Preview of field's value: '{source=    at reconcileChildFibers (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:14348:23)}''" location=nil tag="kubernetes.var.log.containers.log-service-deployment-57747558f8-52jgx_my-application_log-service-6c560e016f7241b3231b96ed358390d8a2170b175833a695705c952183dcda5e.log" time=2023-01-20 10:52:33.431659917 +0000

Il est facile d'identifier le pod à l'origine du problème :

kubectl get po -A |grep log-service-deployment-57747558f8
                  my-application                         log-service-deployment-57747558f8-52jgx                          1/1     Running                 0          4d20h

Il faut comprendre que l'erreur n'est pas dans Kubernetes, c'est le conteneur qui produit des logs incohérents au format json. Ensuite, OpenSearch rejette les journaux envoyés. Banzai réessayera et tôt ou tard, le débordement arrivera.

Sources :

Une solution à court terme peut être choisie ci-dessous :

• Retirer le pod du flux (exclusion du pod) ou désactiver l'ensemble du flux de l'espace de noms concerné.

• Nettoyer l'index lié dans le serveur ES

Solution à long terme :

• Adapter l'application pour produire un journal plus cohérent

• Voir s'il est possible de configurer ES pour qu'il ignore gentiment, mais ne rejette pas, le paquet entier envoyé par Banzai.

Ce guide présente l'ensemble des éléments de configuration nécessaires pour améliorer la disponibilité et la continuité de service de vos applications déployées dans un cluster Kubernetes managés par cegedim.cloud.

Il s'agit d'un guide indispensable pour que votre stratégie de reprise après sinistre réponde aux exigences de cegedim.cloud.

Comment configurer les déploiements pour tirer parti des capacités HA ?

Une fois votre cluster Kubernetes configuré pour fonctionner selon la topologie de haute disponibilité (HA), certaines bonnes pratiques de configuration sont nécessaires pour permettre à vos applications :

• pour fonctionner de façon simultanée sur tous les centres de données de la région.

• de disposer d'une capacité suffisante dans tous les centres de données en cas de catastrophe sur l'un d'entre eux

Configuration du déploiement

Pour rappel, les nœuds des clusters Kubernetes sont répartis dans 3 zones de disponibilité (AZ) et 2 centres de données :

• AZ "A" et "B" fonctionnent sur le centre de données primaire.

• AZ "C" fonctionne sur le centre de données secondaire.

Nombre de répliques

Pour les services sans état qui prennent en charge la mise à l'échelle, la meilleure pratique consiste à faire fonctionner au moins trois pods :

Anti-affinité

Ces 3 pods doivent être correctement configurés pour qu'au moins un pod fonctionne sur chaque zone de disponibilité :

Nous utilisons preferedDuringSchedulingIgnoredDuringExecution et non requiredDuringSchedulingIgnoredDuringExecution car nous voulons que cette exigence soit "souple" : Kubernetes permettra alors de programmer plusieurs pods sur la même AZ si vous exécutez plus de répliques que d'AZ, ou en cas de défaillance d'une zone.

Contraintes d'étalement pour les pods

Comment dimensionner votre cluster HA ?

Si vous utilisez la topologie de cluster haute disponibilité, votre objectif est de déployer des applications résilientes en cas de panne du centre de données.

Cette page décrit quelques bonnes pratiques pour déterminer le dimensionnement des nœuds de travail pour chaque zone de disponibilité où vos charges de travail sont exécutées.

Réfléchir au "pire des scénarios".

Pour rappel, Kubernetes Cluster est déployé dans 3 zones de disponibilité, et 2 centres de données. Dans le pire des cas, une seul zone de disponibilité fonctionnera si le centre de données primaire subit un sinistre majeur.

C'est l'hypothèse à prendre en compte pour déterminer le dimensionnement "nominal", que l'on peut appeler "Si le centre de données primaire tombe en panne, de quelle capacité de CPU / RAM ai-je besoin pour continuer à faire fonctionner mon application ?".

Définir la capacité nominale

Comprendre vos besoins

Pour déterminer cette capacité, puis les nœuds de travail déployés dans la zone de disponibilité "C" (combien, et avec quelles ressources), vous aurez besoin de 3 paramètres :

Calculer le dimensionnement

Vous avez alors deux possibilités pour calculer la taille :

• Au niveau de la granularité "Cluster Level": si vous débutez le processus et que vos charges de travail ne sont pas aussi complexes ou variables, utilisez cette option :

  • Déterminer un MBCO global pour les déploiements croisés

  • Additionner toutes les demandes de ressources des pods pour obtenir un numéro unique.

  • Additionner toutes les ressources utilisées par les pods pour obtenir un nombre unique.

• Au niveau de la granularité "Pod Level" : Si vous voulez que le dimensionnement soit parfaitement adapté et que vous en avez le temps, prenez le temps de déterminer ces paramètres pour chaque déploiement de votre cluster Kubernetes, car le MBCO peut varier ! Par exemple :

  • Une application web nécessitera un MBCO avec 100 %.

  • Un cache nécessitera un MBCO de 50%.

  • Une fonctionnalité "agréable à avoir" ou un outil interne peut être à 0 %.

Utilisation de la granularité au niveau des clusters

Si vous avez additionné toutes les demandes et l'utilisation, et que vous avez déterminé le MBCO au niveau du "cluster", vous pouvez utiliser cette formule simple pour calculer le dimensionnement requis pour l'AZ "C" dans le centre de données secondaire :

Utilisation de la granularité "Pod

Si vous avez déterminé un MBCO par déploiement, vous devrez calculer votre dimensionnement avec une formule plus complexe :

Ajustez vos descripteurs de déploiement

Une fois que vous avez calculé votre MBCO, il est important de tirer parti des capacités de Kubernetes (QoS, notamment PodDisruptionBudget) pour que votre déploiement suive votre décision.

Ajustez la taille de votre groupe

Utilisez ITCare ou demandez l'aide de notre support pour dimensionner votre cluster.

Comment utiliser la QoS et la disponibilité garantie de Kubernetes ?

Au cours de cette phase, vous devrez hiérarchiser vos actifs et définir les composants qui sont essentiels à la disponibilité de vos services.

connaître l'utilisation de vos ressources, une fois le déploiement effectué, il est bon d'observer la consommation de ressources de votre charge de travail.

Qualité du service

Dans Kubernetes il y a 3 classes de QoS :

• Garantie

• Burstable

• BestEffort

Pour les charges de travail critiques, vous pouvez utiliser la QOS "garantie", qui définit simplement les limites de ressources égales aux demandes de ressources :

Pour les charges de travail moins critiques, vous pouvez utiliser le QOS "Burstable", qui définira les limites de ressources et les demandes.

Budget pour la perturbation des pods

Le budget de perturbation des pods vous permettra de configurer votre tolérance aux pannes et le nombre de pannes que votre application peut supporter avant d'être indisponible.

Stateless

Avec une charge de travail sans état, l'objectif est d'avoir un nombre minimum de pods disponibles à tout moment, pour ce faire vous pouvez définir un simple budget de perturbation des pods :

Stateful

Avec une charge de travail à état, le but est d'avoir un nombre maximum de pods indisponibles à tout moment, afin de maintenir le quorum par exemple :

Horizontal Pod Autoscaler

Scénarios de trafic élevé :