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

Question

Ce qui est considéré comme une bonne pratique avec K8S pour la gestion de plusieurs environnements (contrôle de la qualité, la mise en scène, Production, Dev, etc)?

Par exemple, dire qu'une équipe est de travailler sur un produit qui nécessite le déploiement de quelques Api, avec une application front-end. Habituellement, cela nécessite au moins 2 environnements:

• Mise en scène: Pour les itérations/tests et de validation avant de le relâcher pour le client
• La Production: l'environnement, le client a accès. Doit contenir stable et bien testé les fonctionnalités.

Donc, en supposant que l'équipe est à l'aide de Kubernetes, ce serait une bonne pratique pour accueillir ces environnements? Ce présent, nous avons envisagé deux options:

1. Utiliser un K8s cluster pour chaque environnement
2. Utilisez uniquement un K8s de cluster et de les conserver dans des espaces de noms différents.

(1) Semble la plus sûre options, car il minimise les risques d'une possible erreur humaine et les pannes, ce qui pourrait mettre l'environnement de production en péril. Toutefois, cela vient avec le coût de la maîtrise des machines et aussi le coût de plus la gestion de l'infrastructure.

(2) Ressemble, il simplifie l'infrastructure de déploiement et de gestion, car il est l'un cluster unique, mais il pose quelques questions comme:

• Comment assurez-vous qu'une erreur humaine peut avoir un impact sur l'environnement de production?
• Comment faire en sorte qu'une charge élevée dans l'environnement intermédiaire ne sera pas la cause d'une perte de performance dans l'environnement de production?

Il pourrait y avoir d'autres préoccupations, je suis donc à atteindre le K8s de la communauté sur StackOverflow d'avoir une meilleure compréhension de la façon de traiter avec ce genre de défis.

Answer 1

Plusieurs Clusters Considérations

Jetez un oeil à ce blog: Liste de contrôle: les avantages et les inconvénients de l'utilisation de plusieurs Kubernetes de clusters et de la façon de répartir les charges de travail entre eux.

J'aimerais souligner quelques-uns des avantages/inconvénients:

Raisons d'avoir plusieurs clusters

• Séparation de la production/développement/test: surtout pour tester une nouvelle version de Kubernetes, d'un service de maillage, d'autres logiciel de cluster
• Conformité: selon certaines règles, certaines applications doivent fonctionner en groupes distincts/séparer les Vpn
• Une meilleure isolation pour sécurité
• Nuage/prem: pour diviser la charge sur site services

Raisons pour avoir un seul cluster

• Réduire le programme d'installation, d'entretien et d'administration les frais généraux
• Améliorer l'utilisation
• La réduction des coûts

En considérant un pas trop cher à l'environnement, avec une moyenne de maintenance, tout en assurant la sécurité de l'isolement pour les applications de production, je vous recommande:

• 1, groupe pour le développement et la mise en scène (séparés par des espaces de noms, peut-être même isolé, à l'aide de Stratégies de Réseau, comme dans Calico)
• 1 cluster pour la PROD

L'Environnement De La Parité

C'est une bonne pratique pour maintenir le développement, la mise en scène et la production aussi semblables que possible:

Les différences entre la sauvegarde de services pour que les minuscules incompatibilités des cultures, provoquant le code qui a travaillé et passé les tests en cours de développement ou la mise en place pour échouer dans la production. Ces types d'erreurs de créer des frictions que disincentivizes déploiement continu.

Combiner une puissante CI/CD outil de la barre. Vous pouvez utiliser la flexibilité de la barre de valeurs pour définir les configurations par défaut, tout en substituant les configs qui diffèrent d'un milieu à l'autre.

GitLab CI/CD avec AutoDevops a un puissant intégration avec Kubernetes, qui vous permet de gérer plusieurs Kubernetes clusters déjà avec barre d'appui.

La gestion de plusieurs clusters (kubectl d'interactions)

Lorsque vous travaillez avec plusieurs Kubernetes grappes, il est facile de gâcher avec des contextes et exécutez kubectl dans le mauvais cluster. Au-delà de que, Kubernetes a des restrictions pour les versions décalage entre la client (kubectl) et le serveur (kubernetes master), afin d'exécuter des commandes dans le bon contexte, ne signifie pas l'exécution de la bonne version du client.

Pour surmonter ce:

• Utiliser asdf de gérer plusieurs kubectl versions
• Définir l' KUBECONFIG env var pour changer entre plusieurs kubeconfig fichiers
• Utiliser kube-ps1 de garder une trace de votre contexte actuel/espace de noms
• Utiliser kubectx et kubens de changement rapide entre les grappes et les espaces de noms
• Utiliser des alias pour les combiner ensemble

Jetez un oeil à cet article, il explique comment le faire: à l'Aide de différents kubectl versions avec plusieurs clusters Kubernetes

Je vous recommande cette lecture: la maîtrise de la KUBECONFIG fichier

Answer 2

Certainement utiliser un groupe séparé pour le développement et la création de docker images, de sorte que votre mise en scène/les pôles de production peut être verrouillé de vue de la sécurité. Si vous utilisez des groupes distincts pour staging + production est à vous de décider fondée sur le risque/coût - certainement en les gardant séparés permettra d'éviter staging affectant production.

Je voudrais aussi vous recommandons vivement d'utiliser GitOps pour promouvoir les versions de vos applications entre vos environnements.

Afin de minimiser l'erreur humaine moi aussi je vous recommande de regarder dans automatiser autant que possible pour votre CI/CD et de promotion.

Voici une démo de comment automatiser CI/CD avec plusieurs environnements sur Kubernetes à l'aide de GitOps pour la promotion entre les environnements et Aperçu des Environnements de Tirer la Demande qui a été fait en direct sur GKE si Jenkins X prend en charge la plupart des kubernetes clusters

Answer 3

Cela dépend de ce que vous souhaitez tester dans chacun des scénarios. En général, je voudrais essayer d'éviter l'exécution de scénarios de tests sur le cluster de production afin d'éviter les effets secondaires (impact sur les performances, etc.).

Si votre intention est de tester avec une mise en scène du système qui imite exactement le système de production , je recommanderais de tir jusqu'à une réplique exacte de la totalité du cluster et l'arrêter après que vous avez terminé le test et déplacer les déploiements de production.

Si votre but est de tester un système de mise en scène qui permet de tester l'application à déployer, je voudrais exécuter une petite mise en scène cluster en permanence et de mettre à jour les déploiements (avec aussi une version réduite de la déploiements) tel que requis pour les essais en continu.

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

Answer 4

Il est clair que, en gardant le cluster de production en dehors de la mise en scène, le risque potentiel d'erreurs affectant les services de production est réduite. Toutefois, cela arrive à un coût de plus de l'infrastructure/gestion de la configuration, car il nécessite au moins:

• au moins 3 masters pour le cluster de production et d'au moins un maître de la mise en scène d'un
• 2 Kubectl fichiers de configuration pour être ajouté à la CI/CD système

N'oublions pas non plus qu'il pourrait y avoir plus d'un environnement. Pour exemple, j'ai travaillé dans des sociétés où il y a au moins 3 environnements:

• QA: Cela où l'on fait tous les jours déploie et où nous avons fait de notre contrôle qualité interne avant de le relâcher pour le client)
• Client QA: le Présent où nous avons déployé avant le déploiement de la production, de sorte que le client peut valider l'environnement avant la mise en production)
• La Production: la production des services sont déployés.

Je pense éphémère/à la demande des grappes de sens, mais seulement pour certains cas d'utilisation (charge/essais de performance ou « très grande » intégration/de fin à la fin de l'essai), mais pour les plus persistants/collant les environnements que je vois une surcharge qui pourrait être réduite par l'exécution dans un seul cluster.

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

Answer 5

À moins que le respect ou d'autres s'y opposent, je préfère un cluster unique pour tous les environnements. Avec cette approche, l'attention des points sont les suivants:

• Assurez-vous aussi de groupe de nœuds par l'environnement à l'aide d'étiquettes. Vous pouvez ensuite utiliser l' nodeSelector sur les ressources pour s'assurer qu'ils sont en cours d'exécution sur des nœuds spécifiques. Cela permettra de réduire les chances de (excédent) de la consommation de ressources qui déborde entre les environnements.

• Traiter vos espaces de sous-réseaux et d'interdire toute sortie/pénétration de trafic par défaut. Voir https://kubernetes.io/docs/concepts/services-networking/network-policies/.

• Avoir une stratégie pour la gestion des comptes de service. ClusterRoleBindings implique quelque chose de différent si l'un des clusters hôtes plus d'un environnement.

• Utiliser un examen lors de l'utilisation d'outils comme la Barre. Certains graphiques de manière flagrante installer les comptes de service à l'échelle de la grappe des autorisations, mais des autorisations pour les comptes de service devrait être limitée à l'environnement dans lequel ils sont.