Environnements multiples (Staging, QA, production, etc.) avec Kubernetes

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

À titre d'exemple, disons qu'une équipe travaille sur un produit qui nécessite le déploiement de quelques API, ainsi qu'une application frontale. Habituellement, cela nécessitera au moins 2 environnements:

• Staging: pour les itérations / tests et la validation avant la publication au client
• Production: il s'agit de l'environnement auquel le client a accès. Doit contenir des fonctionnalités stables et bien testées.

Donc, en supposant que l'équipe utilise Kubernetes, quelle serait une bonne pratique pour héberger ces environnements? Jusqu'à présent, nous avons envisagé deux options:

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

(1) Semble les options les plus sûres car elle minimise les risques d'erreur humaine potentielle et de pannes de machines, qui pourraient mettre l'environnement de production en danger. Cependant, cela s'accompagne du coût d'un plus grand nombre de machines maîtres et également du coût d'une plus grande 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 cela soulève quelques questions telles que:

• Comment s'assurer qu'une erreur humaine peut avoir un impact sur l'environnement de production?
• Comment s'assurer qu'une charge élevée dans l'environnement intermédiaire ne causera pas de perte de performances dans l'environnement de production?

Il peut y avoir d'autres préoccupations, alors je contacte la communauté K8 sur StackOverflow pour mieux comprendre comment les gens font face à ce genre de défis.

Considérations relatives à plusieurs clusters

Jetez un œil à ce billet de blog de Vadim Eisenberg ( IBM / Istio ): Liste de contrôle: avantages et inconvénients de l'utilisation de plusieurs clusters Kubernetes, et comment répartir les charges de travail entre eux .

Je voudrais souligner certains des avantages / inconvénients:

Raisons d'avoir plusieurs clusters

• Séparation production / développement / test: notamment pour tester une nouvelle version de Kubernetes, d'un service mesh, d'autres logiciels de cluster
• Conformité: selon certaines réglementations, certaines applications doivent s'exécuter dans des clusters / VPN séparés
• Meilleur isolement pour la sécurité
• Cloud / on-premise: pour répartir la charge entre les services on-premise

Raisons d'avoir un seul cluster

• Réduisez les frais de configuration, de maintenance et d'administration
• Améliorez l'utilisation
• Réduction des coûts

Compte tenu d'un environnement pas trop cher, avec une maintenance moyenne, tout en assurant 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, en utilisant des stratégies réseau, comme dans Calico )
• 1 cluster pour PROD

Parité d'environnement

C'est une bonne pratique de 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 surgissent, entraînant l'échec du code qui a fonctionné et qui a réussi les tests de développement ou de préparation en production. Ces types d'erreurs créent des frictions qui découragent le déploiement continu.

Combinez un puissant outil CI / CD avec la barre . Vous pouvez utiliser la flexibilité des 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 a une intégration puissante avec Kubernetes, qui vous permet de gérer plusieurs clusters Kubernetes déjà avec la prise en charge de la barre.

Gérer plusieurs clusters ( kubectlinteractions)

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

Pour surmonter cela:

• Utilisez asdfpour gérer plusieurs kubectlversions
• Définissez laKUBECONFIG variable d'environnement pour changer entre plusieurs kubeconfigfichiers
• Utilisez kube-ps1pour garder une trace de votre contexte / espace de noms actuel
• Utilisez kubectxetkubens pour changer rapidement entre les clusters / espaces de noms
• Utilisez des alias pour les combiner tous ensemble

J'ai un article qui illustre comment y parvenir: Utilisation de différentes versions de kubectl avec plusieurs clusters Kubernetes

Je recommande également les lectures suivantes:

• Maîtriser le fichier KUBECONFIG par Ahmet Alp Balkan ( Google Engineer )
• Comment Zalando gère plus de 140 clusters Kubernetes par Henning Jacobs ( Zalando Tech )

Utilisez certainement un cluster distinct pour le développement et la création d'images docker afin que vos clusters de préparation / production puissent être verrouillés en termes de sécurité. Si vous utilisez des clusters séparés pourstaging + production appartient de décider fonction du risque / coût - certainement en les gardant séparés vous évitera d' stagingaffecter production.

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

Pour minimiser l'erreur humaine, je vous recommande également de vous pencher sur l'automatisation autant que possible pour votre CI / CD et votre promotion.

Voici une démonstration de la façon d'automatiser 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, qui a été effectuée en direct sur GKE bien que Jenkins X prenne en charge la plupart des clusters kubernetes

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

Si votre intention est de tester avec un système de mise en scène qui imite exactement le système de production préparation je vous recommanderais de lancer une réplique exacte du cluster complet et de l'arrêter après avoir testé et déplacé les déploiements en production.

Si votre objectif est de tester un système de test qui permet de tester l'application à déployer, j'exécuterais un cluster intermédiaire plus petit en permanence 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 séparée qui ne fait pas partie du cluster mais utilisée pour allumer et arrêter les clusters ainsi que pour effectuer des travaux de déploiement, lancer des tests, etc. Cela permet de configurer et d'arrêter clusters dans le cadre de scénarios de test automatisés.

Il est clair qu'en séparant le cluster de production de celui de mise en scène, le risque d'erreurs potentielles affectant les services de production est réduit. Cependant, cela a un coût de plus de gestion de l'infrastructure / configuration, car cela nécessite au moins:

• au moins 3 masters pour le cluster de production et au moins un master pour le staging one
• 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 y a au moins 3 environnements:

• QA: C'est là que nous avons fait des déploiements quotidiens et où nous avons fait notre QA interne avant de les publier au client)
• Client QA: c'est là que nous avons déployé avant le déploiement 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 pour certains cas d'utilisation (tests de charge / performance ou très «grande» intégration / tests de bout en bout) mais pour les environnements plus persistants / collants, je vois une surcharge qui pourrait être réduite 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 comme ceux que j'ai décrits.

À moins que la conformité ou d'autres exigences ne le dictent autrement, je privilégie un seul cluster pour tous les environnements. Avec cette approche, les points d'attention sont:

• Assurez-vous de regrouper également les nœuds par environnement à l'aide d'étiquettes. Vous pouvez ensuite utiliser les nodeSelectorressources on pour vous assurer qu'elles s'exécutent sur des nœuds spécifiques. Cela réduira les chances que la consommation (excessive) de ressources se répande entre les environnements.

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

• Avoir une stratégie de gestion des comptes de service. ClusterRoleBindingsimpliquent quelque chose de différent si un cluster héberge plus d'un environnement.

• Faites attention lorsque vous utilisez des outils comme Helm. Certains graphiques installent de manière flagrante des comptes de service avec des autorisations à l'échelle du cluster, mais les autorisations sur les comptes de service doivent être limitées à l'environnement dans lequel ils se trouvent.

Utiliser plusieurs clusters est la norme, à la liste même pour imposer une séparation forte entre production et «non-production».

Dans cet esprit, notez que GitLab 13.2 (juillet 2020) comprend désormais:

Déploiement de plusieurs clusters Kubernetes dans Core

L'utilisation de GitLab pour déployer plusieurs clusters Kubernetes avec GitLab nécessitait auparavant une licence Premium.
Notre communauté a parlé, et nous avons écouté: le déploiement sur plusieurs clusters est utile même pour les contributeurs individuels.
En fonction de vos commentaires, à partir de GitLab 13.2, vous pouvez déployer sur plusieurs groupes et clusters de projets dans Core.

Voir la documentation et le problème /

Je pense qu'exécuter un seul cluster a du sens car cela réduit les frais généraux, la surveillance. Mais, vous devez vous assurer de mettre en place des politiques réseau et un contrôle d'accès.

Stratégie réseau - pour interdire à la charge de travail de l'environnement de développement / qualité d'interagir avec les magasins de production / de préparation.

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