Kubernetes

Contexte

L’orchestrateur Maverics est une application Golang hautement extensible et évolutive pouvant fonctionner sur des serveurs « bare metal », des machines virtuelles et toutes les marques de clusters Kubernetes (K8s), version 1.24.0 et ultérieures. Bien qu’il ne soit pas possible de détailler tous les scénarios de moteur d’exécution, ce document a vocation à être utilisé avec le Helm Chart de l’orchestrateur pour présenter les meilleures pratiques et des conseils sur la configuration des Pods de l’orchestrateur sur un cluster de production K8s. Strata procède actuellement à des essais d’orchestrateurs sur AWS EKS et RedHat OpenShift sur AWS (ROSA).

Les conseils de configuration fournis peuvent être utilisés pour gérer et exécuter l’orchestrateur à l’aide du gestionnaire de paquets Helm axé sur les modèles pour les configurations plus complexes, ou de solutions plus légères et moins abstraites telles que Kustomize. Nous recommandons d’utiliser le Helm Chart de Strata, qui modélise les meilleures pratiques relatives au déploiement de l’orchestrateur. Des versions préliminaires du Chart sont disponibles pour une sélection de clients, la publication dans les référentiels publics étant prévue pour le quatrième trimestre 2023.

Recommandations d’architecture

Vous trouverez ci-après une liste de constructions et de composants K8s, ainsi que d’outils et de configurations recommandés susceptibles de rationaliser le déploiement et le fonctionnement des orchestrateurs sur les clusters K8s. Chacun des composants du Helm Chart de l’orchestrateur est décrit ci-dessous, des substitutions spécifiques au client étant possibles via, dans le cas du Helm, le fichier values.yaml.

Gestion des secrets

Kubernetes emploie sa fonction Secrets pour les informations confidentielles telles que les mots de passe, les clés et les jetons, mais la configuration par défaut n’offre pas des niveaux de protection et de chiffrement suffisants pour les secrets requis par l’orchestrateur (par exemple, les clés de chiffrement, les clés de signature, les secrets des clients).

Avant de déployer l’orchestrateur dans un environnement de production, suivez le guide Bonnes pratiques en matière de secrets Kubernetes pour vous assurer que les données sensibles enregistrées en tant que secrets sont aussi sécurisées que possible. En particulier :

• Activation du chiffrement au repos
• Configuration des règles RBAC pour un accès avec un minimum de privilèges
• Restriction de l’accès à un conteneur spécifique
• Utilisation d’un fournisseur externe de stockage de secrets (par exemple, AWS Secrets Manager)

StatefulSets

StatefulSet est l’objet de l’API de charge de travail particulièrement adapté aux applications qui nécessitent des identifiants de réseau fiables et uniques, un stockage stable et persistant, ainsi qu’un déploiement et une mise à l’échelle méthodiques et sans heurts.

L’utilisation de StatefulSets est nécessaire pour l’orchestrateur sur K8s car l’état de ce dernier est lié aux données d’identité telles que les sessions, les réclamations des utilisateurs, les jetons, etc. Les objets StatefulSets peuvent conserver une identité de rappel pour chaque orchestrateur, ce qui garantit qu’après une nouvelle planification, l’association entre un Pod et son volume reste intacte. Bien que les volumes ne soient actuellement pas utilisés, ils pourraient l’être dans le cadre du développement de futures fonctionnalités de l’orchestrateur.

Services

Les services permettent d’exposer les orchestrateurs s’exécutant sur un ensemble de Pods en tant que service réseau. Cela permet aux applications de référencer l’orchestrateur principal par nom de service, à l’instar du fonctionnement d’une entrée CNAME sur un équilibreur de charge ou d’une adresse IP virtuelle.

Politique réseau

Une configuration réseau adaptée à la sécurisation d’un orchestrateur doit garantir une protection appropriée du trafic en entrée, également appelé trafic nord/sud. Cela dépend fortement des politiques de sécurité du client et de la manière dont les orchestrateurs ont été configurés.

En ce qui concerne le trafic est/ouest, c’est-à-dire le trafic entre les services et des services vers les magasins de données, Strata utilise et recommande les fonctionnalités réseau améliorées de Calico pour permettre une gestion plus approfondie des politiques de mise en réseau des clusters. Le plugin Calico complète les fonctionnalités suivantes :

• Les politiques peuvent être appliquées aux Pods, aux conteneurs, aux machines virtuelles ou aux interfaces.
• Les règles peuvent comporter une action spécifique (telle qu’une restriction, une permission ou une journalisation).
• Les règles peuvent comporter des ports, des plages de ports, des protocoles, des attributs HTTP/ICMP, des IP, des sous-réseaux ou des sélecteurs de nœuds (tels que des hôtes ou des environnements).
• Le flux de trafic peut être contrôlé par des paramètres et des politiques DNAT.

L’objectif d’un orchestrateur étant de gérer le trafic sur la base de l’identité, les fonctionnalités étendues d’un outil tel que Calico peuvent contribuer à renforcer la sécurité des déploiements des orchestrateurs.

Actuellement, les politiques de réseau doivent être configurées en dehors de la bande à partir du Helm Chart de l’orchestrateur ; cependant, le Chart accède à toutes les données nécessaires pour les modéliser. Avec cet ajout, les clients qui utilisent une CNI prenant en charge les politiques de réseau bénéficieront d’une couche de sécurité supplémentaire dès le départ.

Budgets de perturbation des Pods (PDB, Pod Disruption Budgets)

Comme pour toute installation d’un orchestrateur de production, Strata recommande qu’une certaine forme de haute disponibilité soit toujours configurée pour s’assurer de la continuité du trafic des identités clés. La valeur par défaut du PDB pour l’orchestrateur est actuellement désactivée dans le fichier du Helm Chart values.yaml. Strata conseille toutefois à ses clients de procéder à cette configuration en fonction de leur tolérance aux interruptions volontaires des ReplicaSets et du nombre de ReplicaSets exécutant des orchestrateurs dans leur environnement spécifique.

ConfigMaps

Un ConfigMap est un objet d’API utilisé pour stocker des données non confidentielles dans des paires clé-valeur. Les Pods orchestrateurs peuvent utiliser les ConfigMaps en tant que variables d’environnement, arguments de ligne de commande ou fichiers de configuration dans un volume.

Les valeurs non secrètes définies lors du déploiement du Helm Chart de l’orchestrateur (par exemple, les options définies dans la section customConfig) sont enregistrées dans un ConfigMap dans l’espace de noms du déploiement.

Entrées

Il n’existe aucune restriction imposée par l’orchestrateur quant au choix des entrées. Strata emploie les équilibreurs de charge d’application d’AWS en guise de calque de contrôleur d’entrée dans les clusters internes de K8. L’orchestrateur a été testé avec les contrôleurs d’entrée ALB et Nginx.

Lors de la mise à l’échelle d’un orchestrateur vers plusieurs instances, le contrôleur d’entrée doit être configuré en fonction de l’affinité de la session ( « sessions permanentes ») pour s’assurer que la communication du canal avant avec les clients est acheminée vers le même orchestrateur de manière régulière.

Autoscaler horizontal des Pods (HPA, Horizontal Pod Autoscaler)

Strata recommande de commencer par un minimum de « 2 » et un maximum de « 5 ». Cela suppose un dimensionnement raisonnable du Pod de l’orchestrateur, par exemple 0,5 vCPU et 256 Mo de RAM. Il convient d’adapter le dimensionnement au fur et à mesure de l’ajout d’applications et de l’augmentation de la charge sur l’orchestrateur. Nous recommandons d’engager l’autoscaler à 70 % de la capacité du processeur.

Bonnes pratiques (en fonction de l’environnement)

Utilisation de règles anti-affinité

Les Pods de l’orchestrateur StatefulSet sont répartis sur différents nœuds, de sorte qu’une défaillance d’un seul nœud n’entraîne pas l’arrêt de plusieurs instances de l’orchestrateur. Ceci peut être configuré en remplaçant la valeur d’affinité par défaut dans le Helm Chart à l’aide du fichier de remplacement spécifique au client values.yaml.

Définition des requêtes de ressources et des limites

Cette fonction peut être activée en remplaçant le paramètre de ressources par défaut dans le Helm Chart à l’aide du fichier de remplacement spécifique au client values.yaml. Les limites appropriées dépendront de la manière dont l’orchestrateur sera déployé. Par exemple, lorsqu’il est configuré en tant que fournisseur OIDC, l’orchestrateur nécessitera des ressources différentes que lorsqu’il est configuré pour le trafic d’application proxy. Indépendamment de la configuration de l’orchestrateur, la quantité et le motif du trafic passant par l’orchestrateur influenceront fortement les besoins en ressources.

Utilisation de l’autoscaler horizontal des Pods (HPA, Horizontal Pod Autoscaler)

L’autoscaling horizontal des pods peut être activé et configuré dans le bloc autoscaling des valeurs Helm.

Lorsque l’orchestrateur est configuré en tant que proxy (App Gateway), les Pods peuvent être autoscalés à condition que l’entrée soit configurée pour les sessions permanentes. L’instance de l’orchestrateur conserve son cache de session localement, il est donc important que le trafic du canal avant pour les clients continue d’être acheminé vers la même instance.

Lorsque l’orchestrateur est configuré en tant que fournisseur OIDC, un cache doit être configuré (se référer à : Orchestrateur en tant que fournisseur OIDC) avant de définir replicaCount à une valeur supérieure à 1 ou d’activer l’autoscaler des Pods.

Orchestrateur en tant que fournisseur OIDC

Afin d’exécuter le fournisseur OIDC de l’orchestrateur avec plusieurs instances, un cache externe (par exemple Redis) ou un cache distribué de l’orchestrateur (actuellement en cours de développement) est nécessaire. Toutes les instances utilisant la même configuration de fournisseur OIDC doivent avoir accès au même cache de métadonnées.

Les instructions relatives à la configuration du cache externe varient en fonction de l’environnement. Les paramètres de configuration appropriés de l’orchestrateur seront fournis par un technicien d’assistance de Strata lors de la planification du déploiement.