Remarque perev. : L'enthousiasme que nos chefs d'équipe ont éprouvé lorsqu'ils ont vu ce matériel sur le blog IBM Cloud - une sorte d '"extension" de la légendaire application à douze facteurs, - parle de lui-même. Les questions posées par l'auteur ne sont pas seulement à l'oreille, mais vraiment vitales, c'est-à-dire pertinentes dans la vie de tous les jours. Leur compréhension est utile non seulement pour les ingénieurs DevOps, mais aussi pour les développeurs créant des applications modernes fonctionnant dans Kubernetes.La méthodologie d'
application à 12 facteurs bien connue est un ensemble de règles clairement définies pour le développement de microservices. Ils sont largement utilisés pour exécuter, faire évoluer et déployer des applications. Sur la plateforme IBM Cloud Private, nous suivons les 12 mêmes principes lors du développement d'applications conteneurisées. L'article «
Kubernetes & 12-factor apps » décrit les spécificités de l'utilisation de ces 12 facteurs (ils sont pris en charge par le modèle d'orchestration des conteneurs Kubernetes).
En réfléchissant aux principes de développement de microservices conteneurisés qui fonctionnent sous le contrôle de Kubernetes, nous sommes arrivés à la conclusion suivante: les 12 facteurs ci-dessus sont tout à fait vrais, mais d'autres sont également extrêmement importants pour l'organisation d'un environnement de production:
- observable
- prévisibilité (programmable) ;
- possibilité de mise à jour (évolutive) ;
- privilèges minimum
- contrôlabilité (vérifiable) ;
- sécurité (sécurisable) ;
- mesurable
Arrêtons-nous sur ces principes et essayons d'évaluer leur signification. Pour maintenir l'uniformité, nous les ajoutons à ceux existants - en conséquence, nous commencerons par XIII ...
Principe XIII: observabilité
Les candidatures doivent fournir des informations sur leur état actuel et leurs indicateurs.Les systèmes distribués peuvent être difficiles à gérer car de nombreux microservices sont intégrés dans une application. En effet, les différents engrenages doivent se déplacer de concert pour que le mécanisme (application) fonctionne. Si une défaillance se produit dans l'un des microservices, le système doit automatiquement la détecter et la corriger. Kubernetes fournit d'excellents mécanismes de sauvetage, tels que des
tests de préparation et de
vivacité .
Avec leur aide, Kubernetes s'assure que l'application est prête à recevoir du trafic. Si la préparation échoue, Kubernetes cesse d'envoyer du trafic vers le pod jusqu'à ce que le prochain test montre que le pod est prêt.
Supposons que nous ayons une application composée de 3 microservices: frontend, logique métier et une base de données. Pour que l'application fonctionne, avant d'accepter le trafic, le frontend doit s'assurer que la logique métier et les bases de données sont prêtes. Cela peut être fait en utilisant le test de préparation - il vous permet de vous assurer que toutes les dépendances fonctionnent.
L'animation montre que les demandes au pod ne sont pas envoyées jusqu'à ce que le test de préparation montre sa disponibilité:
Test de préparation en action: Kubernetes utilise une sonde de préparation pour vérifier si les pods sont prêts à recevoir du traficIl existe trois types de tests: à l'aide de requêtes HTTP, TCP et de commandes. Vous pouvez contrôler la configuration des tests, par exemple, indiquer la fréquence des démarrages, les seuils de réussite / d'échec et le temps d'attente pour une réponse. Dans le cas des tests de vivacité, vous devez définir un paramètre très important -
initialDelaySeconds . Assurez-vous que le test ne démarre que lorsque l'application est prête. Si ce paramètre n'est pas défini correctement, l'application redémarrera constamment. Voici comment cela peut être implémenté:
livenessProbe: # an http probe httpGet: path: /readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5
Grâce à des tests de vivacité, Kubernetes vérifie si votre application est en cours d'exécution. Si l'application fonctionne normalement, Kubernetes ne fait rien. S'il "meurt", Kubernetes supprime le pod et en démarre un nouveau en retour. Cela correspond aux besoins des microservices sans état et à leur recyclabilité (
facteur IX, jetabilité ). L'animation ci-dessous illustre une situation où Kubernetes redémarre le pod après avoir échoué au test de vivacité:
Test de vivacité en action: Kubernetes vérifie si les gousses sont «vivantes» avec luiL'énorme avantage de ces tests est que vous pouvez déployer des applications dans n'importe quel ordre sans vous soucier des dépendances.
Cependant, nous avons constaté que ces tests ne sont pas suffisants pour l'environnement de production. En règle générale, les applications ont leurs propres mesures qui doivent être suivies, par exemple, le nombre de transactions par seconde. Les clients définissent des seuils pour eux et configurent les notifications. IBM Cloud Private comble cette lacune avec la pile de surveillance hautement sécurisée de Prometheus et Grafana avec un système de contrôle d'accès basé sur les rôles. Voir la section de
surveillance des clusters IBM Cloud Private pour plus d'informations.
Prometheus collecte des données cibles à partir de métriques de point final. Votre application doit spécifier des mesures de point de terminaison à l'aide de l'annotation suivante:
prometheus.io/scrape: 'true'
Après cela, Prometheus détecte automatiquement le point de terminaison et collecte des métriques à partir de celui-ci (comme indiqué dans l'animation suivante):
Collection de métriques personnaliséesRemarque perev. : Il serait plus correct de tourner les flèches dans la direction opposée, puisque Prométhée marche et interroge les points d'extrémité, et Grafana lui-même prend des données de Prométhée, mais dans le sens d'une illustration générale, ce n'est pas si critique.Principe XIV: prévisibilité
Les applications doivent fournir une prévisibilité des besoins en ressources.Imaginez qu'un guide ait choisi votre équipe pour expérimenter un projet Kubernetes. Vous avez travaillé dur pour créer un environnement approprié. Le résultat est une application qui démontre un temps de réponse et des performances exemplaires. Puis une autre équipe s'est jointe aux travaux. Elle a créé son application et l'a lancée dans le même environnement. Après le lancement de la deuxième application, les performances de la première ont soudainement diminué. Dans ce cas, la raison de ce comportement doit être recherchée dans les ressources informatiques (CPU et mémoire) disponibles pour vos conteneurs. Forte probabilité de leur carence. La question se pose: comment garantir l'allocation des ressources informatiques nécessaires à l'application?
Kubernetes a une excellente option qui vous permet de définir des ressources minimales et des restrictions pour les conteneurs. Les minimums sont garantis. Si un conteneur nécessite une ressource, Kubernetes l'exécute uniquement sur l'hôte que cette ressource peut fournir. En revanche, la limite supérieure garantit que l'appétit du récipient ne dépasse jamais une certaine valeur.
Minimums et restrictions pour les conteneursL'extrait de code YAML suivant montre le réglage des ressources informatiques:
resources: requests: memory: "64Mi" cpu: "150m" limits: memory: "64Mi" cpu: "200m"
Remarque perev. : Pour plus d'informations sur la fourniture de ressources dans Kubernetes, les demandes et les limites, consultez notre récent rapport et sa revue, « Autoscaling and Resource Management in Kubernetes », ainsi que la documentation K8s .Une autre opportunité intéressante pour les administrateurs dans un environnement de production consiste à définir des quotas pour l'
espace de
noms . Si le quota est défini, Kubernetes ne créera pas de conteneurs pour lesquels la demande / les limites ne sont pas définies dans cet espace de noms. Un exemple de définition de quotas pour l'espace de noms peut être vu dans la figure ci-dessous:
Quotas pour les espaces de nomsPrincipe XV. Mise à jour
Les applications doivent mettre à jour les formats de données des générations précédentes.Il est souvent nécessaire de corriger une application de production qui fonctionne afin d'éliminer une vulnérabilité ou d'étendre les fonctionnalités. Il est important que la mise à jour se fasse sans interruption de travail. Kubernetes fournit
un mécanisme de mise à jour continue qui vous permet de mettre à jour votre application sans interruption. En utilisant ce mécanisme, vous pouvez mettre à jour par pod à la fois sans arrêter l'ensemble du service. Voici une représentation schématique de ce processus (sur elle l'application est mise à jour vers la deuxième version):
Un exemple de description YAML correspondante:
minReadySeconds: 5 strategy: # , type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
Faites attention aux
maxSurge maxUnavailable et
maxSurge :
maxUnavailable - un paramètre facultatif qui définit le nombre maximal de pods qui peuvent ne pas être disponibles pendant le processus de mise à jour. Bien qu'il soit facultatif, il vaut toujours la peine de définir une valeur spécifique pour garantir la disponibilité du service;maxSurge est un autre paramètre facultatif mais critique. Il définit le nombre maximal de pods qui peuvent être créés au-delà du nombre souhaité.
Principe XVI: Privilèges minimaux
Les conteneurs doivent fonctionner avec un minimum de privilèges.Cela semble pessimiste, mais vous devez considérer chaque résolution du conteneur comme une vulnérabilité potentielle (voir l'illustration). Par exemple, si le conteneur s'exécute en tant que root, toute personne y ayant accès peut y injecter un processus malveillant. Kubernetes fournit une
politique de sécurité des pods (PSP) pour restreindre l'accès au système de fichiers, au port hôte, aux capacités Linux, etc. IBM Cloud Private propose un ensemble prêt à l'emploi de PSP qui se lie aux conteneurs lorsqu'ils sont provisionnés dans l'espace de noms. Pour plus d'informations, voir
Utilisation d'espaces de noms avec des stratégies de sécurité de pod .
Toute résolution est un vecteur d'attaque potentielPrincipe XVII: contrôlabilité
Vous devez savoir qui, quoi, où et quand pour toutes les opérations critiques.La contrôlabilité est essentielle à toute opération avec un cluster ou une application Kubernetes. Par exemple, si l'application traite les transactions par carte de crédit, vous devez activer un audit afin d'avoir une trace de contrôle de chaque transaction. IBM Cloud Private utilise la
fédération de données d'audit du cloud (CADF) standard de l'industrie, qui est invariante à des implémentations cloud spécifiques. Pour plus d'informations, voir
Journalisation d'audit dans IBM Cloud Private .
Un événement CADF contient les données suivantes:
initiator_id - ID de l'utilisateur qui a effectué l'opération;target_uri - URI CADF cible (par exemple: données / sécurité / projet);action - l' action effectuer, généralement l' operation: resource_type .
Principe XVIII: Sécurité (identification, réseau, portée, certificats)
Il est nécessaire de protéger l'application et les ressources des étrangers.Cet article mérite un article séparé. Il suffit de dire que les applications de production nécessitent une protection de bout en bout. IBM Cloud Private prend les mesures suivantes pour garantir la sécurité des environnements de production:
- authentification: vérification d'identité;
- autorisation: vérification d'accès utilisateur authentifié;
- gestion des certificats: travailler avec des certificats numériques, y compris la création, le stockage et le renouvellement;
- protection des données: garantir la sécurité des données transmises et stockées;
- sécurité et isolation du réseau: empêcher l'accès au réseau par des utilisateurs et des processus non autorisés;
- conseiller en vulnérabilité: identification des vulnérabilités dans les images;
- Conseiller en mutation: Détection de mutations dans des conteneurs.
Pour plus d'informations, voir le
IBM Cloud Private Security Guide .
Le gestionnaire de certificats est particulièrement important.
Ce service chez IBM Cloud Private est basé sur le
projet open
source Jetstack . Le gestionnaire de certificats vous permet d'émettre et de gérer des certificats pour les services exécutés sur IBM Cloud Private. Il prend en charge les certificats publics et auto-signés, s'intègre pleinement avec
kubectl et le contrôle d'accès basé sur les rôles.
Principe XIX: Mesurabilité
L'utilisation de l'application devrait être mesurable aux fins des quotas et des règlements entre les ministères.En fin de compte, les entreprises doivent payer les coûts informatiques (voir la figure ci-dessous). Les ressources informatiques dédiées à l'exécution des conteneurs doivent être mesurables et les organisations utilisant le cluster doivent être responsables. Assurez-vous de suivre le principe XIV - Prévisibilité. IBM Cloud Private propose un
service de comptabilité qui collecte des données sur les ressources informatiques de chaque conteneur et les combine au niveau de l'espace de noms pour des calculs ultérieurs (dans le cadre de showbacks ou de refacturations).
L'utilisation de l'application doit être mesurable.Conclusion
J'espère que vous avez aimé le sujet abordé dans cet article et que vous avez noté les facteurs que vous utilisez déjà et que vous avez pensé à ceux qui sont encore en marge.
Pour plus d'informations, je vous recommande de vous familiariser avec l'
enregistrement de notre performance au KubeCon 2019 à Shanghai. Dans ce document,
Michael Elder et
moi discutons des principes 12 + 7 pour l'orchestration de conteneurs basée sur Kubernetes.
PS du traducteur
Lisez aussi dans notre blog: