web-dev-qa-db-fra.com

Plusieurs environnements (Staging, QA, production, etc.) avec Kubernetes

Qu'est-ce qui est considéré comme une bonne pratique avec K8S pour gérer plusieurs environnements (QA, Staging, Production, Dev, etc.)?

Par exemple, supposons qu'une équipe travaille sur un produit nécessitant le déploiement de quelques API, ainsi que d'une application frontale. Généralement, cela nécessite au moins 2 environnements:

  • Staging: pour les itérations/tests et la validation avant la publication sur le client
  • Production: C'est l'environnement auquel le client a accès. Devrait contenir des fonctionnalités stables et bien testées.

En supposant que l’équipe utilise Kubernetes, quelle serait la bonne pratique pour héberger ces environnements? Jusqu'ici, nous avons envisagé deux options:

  1. Utiliser un cluster K8s pour chaque environnement
  2. Utilisez un seul cluster K8 et conservez-les dans différents espaces de noms.

(1) Il semble que les options les plus sûres, car elles minimisent les risques d’erreurs humaines et de défaillances de la machine susceptibles de mettre en danger l’environnement de production. Toutefois, cela entraîne des coûts supplémentaires en termes de nombre de machines maîtres et de gestion de l’infrastructure.

(2) On dirait que cela simplifie la gestion de l'infrastructure et du déploiement, car il n'y a qu'un seul cluster, mais soulève quelques questions, telles que:

  • Comment s'assurer qu'une erreur humaine pourrait avoir un impact sur l'environnement de production?
  • Comment s'assurer qu'une charge élevée dans l'environnement de transfert ne causera pas de perte de performance dans l'environnement de production?

Il y a peut-être d'autres préoccupations, aussi je contacte la communauté K8 sur StackOverflow pour mieux comprendre comment les gens gèrent ce type de défis.

kubernetes
74
Yoanis Gil

Utilisez sans aucun doute un cluster distinct pour le développement et la création d’images de menu fixe afin que vos clusters de transfert/production puissent être verrouillés pour des raisons de sécurité. Si vous utilisez des grappes distinctes pour staging + production est à vous de décider en fonction du risque/coût - les garder séparés vous aidera certainement à éviter staging d'affecter production.

Je vous recommande également fortement d'utiliser GitOps pour promouvoir les versions de vos applications entre vos environnements.

Pour minimiser les erreurs humaines, je vous recommande également de rechercher autant que possible l'automatisation de votre CI/CD et de votre promotion.

Voici ne démonstration de l'automatisation de CI/CD avec plusieurs environnements sur Kubernetes à l'aide de GitOps pour la promotion entre les environnements et les environnements de prévisualisation sur les demandes d'extraction, effectuée en direct sur GKE bien que Jenkins X prenne en charge la plupart des clusters de Kubernetes.

18
James Strachan

Cela dépend de ce que vous voulez tester dans chacun des scénarios. En général, j'essaie d'éviter d'exécuter des scénarios de test sur le cluster de production afin d'éviter des effets secondaires inutiles (impact sur les performances, etc.).

Si votre intention est de tester avec un système de transfert qui imite exactement le système de production, je vous recommanderais d'activer une réplique exacte du cluster complet et de l'éteindre une fois que vous avez terminé les tests et que les déploiements passent en production. .

Si votre objectif est de tester un système de transfert qui permet tester l'application de déployer, j'exécuterais en permanence un cluster de transfert intermédiaire plus petit et mettrais à jour les déploiements (avec également une version réduite des déploiements) comme requis pour les tests continus .

Pour contrôler les différents clusters, je préfère avoir une machine ci/cd distincte qui ne fait pas partie du cluster mais qui est utilisée pour allumer et éteindre des clusters, ainsi que pour effectuer un travail de déploiement, lancer des tests, etc. Cela permet de configurer et d'arrêter les clusters. grappes dans le cadre de scénarios de tests automatisés.

11
Oswin Noetzelmann

Considérations sur plusieurs clusters

Jetez un coup d'œil à ce billet de blog: liste de contrôle: avantages et inconvénients de l'utilisation de plusieurs clusters Kubernetes et de la répartition des charges de travail entre eux .

Je voudrais souligner certains des avantages/inconvénients:

Raisons d'avoir plusieurs grappes

  • Séparation production/développement/test: spécialement pour tester une nouvelle version de Kubernetes, un maillage de service, d’un autre logiciel de cluster
  • Conformité: selon certaines réglementations, certaines applications doivent être exécutées dans des clusters/VPN distincts
  • Meilleure isolation pour la sécurité
  • Cloud/sur site: pour répartir la charge entre des services sur site

Raisons d'avoir un seul cluster

  • Réduire les coûts d'installation, de maintenance et d'administration
  • Améliorer l'utilisation
  • Réduction des coûts

Considérant un environnement pas trop coûteux, avec une maintenance moyenne, tout en assurant toujours l'isolation de sécurité pour les applications de production, je recommanderais:

  • 1 cluster pour DEV et STAGING (séparés par des espaces de noms, peut-être même isolés, à l'aide de règles de réseau, comme dans Calico)
  • 1 cluster pour PROD

Environnement Parité

C'est un bonne pratique pour garder le développement, la mise en scène et la production aussi similaires que possible:

Les différences entre les services de support signifient que de minuscules incompatibilités apparaissent, faisant échouer le code qui a fonctionné et qui a réussi les tests de développement ou de mise en scène. Ces types d'erreur créent des frictions qui découragent le déploiement continu.

Combinez un puissant outil CI/CD avec barre. Vous pouvez utiliser la flexibilité de valeurs de barre pour définir les configurations par défaut, en remplaçant simplement les configurations qui diffèrent d’un environnement à l’autre.

GitLab CI/CD avec AutoDevops possède une intégration puissante avec Kubernetes, ce qui vous permet de gérer plusieurs clusters Kubernetes déjà avec un support helm.

Gestion de plusieurs clusters (kubectl interactions)

Lorsque vous travaillez avec plusieurs clusters Kubernetes, il est facile de déconner avec les contextes et d’exécuter kubectl dans le mauvais cluster. Au-delà de cela, Kubernetes a restrictions pour incompatibilité de version entre le client (kubectl) et le serveur (maître kubernetes). Par conséquent, exécuter des commandes dans le bon contexte ne signifie pas exécuter la bonne version du client.

Pour surmonter ceci:

  • Utilisez asdf pour gérer plusieurs versions de kubectl
  • Définissez le KUBECONFIG env var pour changer entre plusieurs fichiers kubeconfig
  • Utilisation kube-ps1 pour suivre votre contexte/espace de noms actuel
  • Utilisez kubectx et kubens pour changer rapidement de clusters/espaces de noms
  • Utilisez des alias pour les combiner tous ensemble

Jetez un oeil à cet article, il explique comment faire cela: tilisation de différentes versions de kubectl avec plusieurs clusters Kubernetes

Je recommande également cette lecture: Maîtriser le fichier KUBECONFIG

6
Eduardo Baitello

Il est clair qu'en gardant le cluster de production à l'écart du groupe de stockage intermédiaire, le risque d'erreur potentielle ayant une incidence sur les services de production est réduit. Cependant, cela implique un coût supplémentaire en termes de gestion d’infrastructure/configuration, car cela nécessite au minimum:

  • au moins 3 maîtres pour le cluster de production et au moins un maître pour le serveur intermédiaire
  • 2 fichiers de configuration Kubectl à ajouter au système CI/CD

N'oublions pas non plus qu'il pourrait y avoir plus d'un environnement. Par exemple, j'ai travaillé dans des entreprises où il existe au moins 3 environnements:

  • QA: C’est là que nous avons effectué des déploiements quotidiens et que nous avons effectué notre assurance qualité interne avant de communiquer au client)
  • Assurance qualité du client: nous avons déployé ce processus avant de le déployer en production afin que le client puisse valider l'environnement avant de le mettre en production.
  • Production: C'est là que les services de production sont déployés.

Je pense que les clusters éphémères/à la demande ont du sens, mais seulement dans certains cas d'utilisation (test de charge/performance ou de très "grands" tests d'intégration/de bout en bout), mais pour les environnements plus persistants/collants, je vois un temps système qui pourrait être réduit. en les exécutant dans un seul cluster.

Je suppose que je voulais contacter la communauté k8s pour voir quels modèles sont utilisés pour de tels scénarios tels que ceux que j'ai décrits.

6
Yoanis Gil

Sauf indication contraire de la conformité ou d'autres exigences, je privilégie un cluster unique pour tous les environnements. Avec cette approche, les points d’attention sont:

  • Assurez-vous également de regrouper les nœuds par environnement à l'aide d'étiquettes. Vous pouvez ensuite utiliser nodeSelector sur des ressources pour vous assurer qu'elles fonctionnent sur des nœuds spécifiques. Cela réduira les risques de dépassement de la consommation de ressources (en excès) entre les environnements.

  • Traitez vos espaces de noms comme des sous-réseaux et interdisez tout trafic de sortie/entrée par défaut. Voir https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

  • Ayez une stratégie pour gérer les comptes de service. ClusterRoleBindings implique quelque chose de différent si un cluster héberge plus d'un environnement.

  • Faites preuve de vigilance lorsque vous utilisez des outils tels que Helm. Certains graphiques installent de manière flagrante des comptes de service avec des autorisations pour l'ensemble du cluster, mais les autorisations d'accès aux comptes de service doivent être limitées à l'environnement dans lequel elles se trouvent.

2
Cochise Ruhulessin

Je pense que l’exploitation d’un seul cluster a du sens car elle réduit les frais généraux, ainsi que la surveillance. Cependant, vous devez vous assurer de placer les stratégies de réseau, le contrôle d'accès en place.

Stratégie réseau: interdire à la charge de travail de l'environnement dev/qa d'interagir avec les magasins prod/staging.

Contrôle d'accès - qui ont accès à différentes ressources d'environnement à l'aide de ClusterRoles, Roles, etc.

0
Akash Sharma