Comment utiliser Datree pour éviter les mauvaises configurations de Kubernetes

Kubernetes est un système complexe avec de nombreuses pièces mobiles. Des règles de configuration correctes sont essentielles pour que votre service fonctionne de manière fiable. Des erreurs peuvent se produire lorsque vous écrivez des manifestes Kubernetes à la main sans un processus de révision complet.

Datree est un outil basé sur des règles qui détecte automatiquement les problèmes dans vos manifestes. Vous pouvez l’utiliser pour découvrir les violations de politique sans quitter votre terminal, ce qui permet une approche cohérente de la configuration de Kubernetes.

Dans cet article, vous apprendrez à utiliser la CLI de Datree pour effectuer des analyses de manifeste à la demande. L’outil est gratuit et open-source mais soutenu par un tableau de bord en ligne qui vous permet de gérer de manière centralisée les politiques partagées par toute votre équipe. Ceci est gratuit pour les personnes interagissant avec jusqu’à deux nœuds tandis que les plans d’équipe commencent à 95 $ / mois avec une allocation de base de cinq nœuds.

Installation de la CLI Datree

Commencez par télécharger et configurer la CLI Datree à l’aide de son script d’installation. Cela fonctionne sur Linux et Mac :

$ curl https://get.datree.io | /bin/bash

Des instructions d’installation alternatives sont disponibles dans la documentation si vous utilisez Windows ou si vous souhaitez exécuter Datree en tant que conteneur Docker.

Vérifiez que la CLI est correctement installée en exécutant le datree commande sans aucun argument :

$ datree
Datree is a static code analysis tool for kubernetes files. Full code can be found at https://github.com/datreeio/datree
...

Vous pouvez maintenant commencer à analyser vos manifestes à la recherche d’erreurs.

Effectuer une vérification de stratégie

Copiez le YAML suivant et enregistrez-le sous datree-demo.yaml dans votre répertoire de travail :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      namespace: demo-deployment
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          readinessProbe:
            tcpSocket:
              port: 8080
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              cpu: "500m"
          ports:
            - containerPort: 80

Ce fichier YAML définit un objet de déploiement Kubernetes valide. Kubectl l’appliquera à votre cluster sans signaler d’erreur :

$ kubectl apply -f datree-demo.yaml
deployment/demo-deployment created

Il pourrait cependant y avoir des problèmes avec cette configuration. L’exécution de la CLI Datree les exposera. Utilisez le datree test commande pour effectuer une analyse de votre manifeste :

$ datree test datree-demo.yaml
>> File: datree-demo.yaml

[V] YAML validation
[V] Kubernetes schema validation

[X] Policy check

❌  Ensure each container image has a pinned (tag) version  [1 occurrence]
    - metadata.name: demo-deployment (kind: Deployment)
💡  Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future

❌  Ensure each container has a configured liveness probe  [1 occurrence]
    - metadata.name: demo-deployment (kind: Deployment)
💡  Missing property object `livenessProbe` - add a properly configured livenessProbe to catch possible deadlocks

❌  Ensure each container has a configured memory limit  [1 occurrence]
    - metadata.name: demo-deployment (kind: Deployment)
💡  Missing property object `limits.memory` - value should be within the accepted boundaries recommended by the organization

(Summary)

- Passing YAML validation: 1/1

- Passing Kubernetes (1.20.0) schema validation: 1/1

- Passing policy check: 0/1

+-----------------------------------+-----+
| Enabled rules in policy "Default" | 21  |
| Configs tested against policy     | 1   |
| Total rules evaluated             | 21  |
| Total rules skipped               | 0   |
| Total rules failed                | 3   |
| Total rules passed                | 18  |
+-----------------------------------+-----+

Datree a découvert trois violations de politique qui pourraient affecter votre cluster.

Interprétation des résultats d’analyse

Les analyses Datree examinent trois aspects de chaque manifeste :

• Validation YAML – La première vérification valide votre YAML pour l’exactitude. Aucune autre vérification n’est effectuée si votre fichier YAML contient des erreurs de syntaxe.
• Validation du schéma Kubernetes – Vérifie si le manifeste contient un objet Kubernetes légal. Les causes courantes de ces erreurs incluent les valeurs de champ non valides et l’imbrication incorrecte des objets.
• Contrôles de politique – C’est là que Datree teste un schéma d’objet Kubernetes valide contre les erreurs de configuration courantes. Les politiques identifient les problèmes potentiels et les optimisations manquantes afin que vous puissiez rendre votre cluster Kubernetes plus résilient.

Chaque rapport se termine par un tableau récapitulant le nombre de manifestes analysés, les règles utilisées et les échecs détectés.

Correction des erreurs de l’exemple de manifeste

L’analyse de l’exemple de manifeste fait apparaître trois erreurs : le conteneur image le champ n’utilise pas de balise épinglée, il n’y a pas livenessProbeet aucune limite de mémoire.

Le premier problème peut être résolu en utilisant une version d’image explicite telle que nginx:1.23. La dernière balise est risquée, car vous pourriez recevoir involontairement des modifications avec rupture, telles que 1.23 à 2.1.

L’erreur suivante peut être éliminée en ajoutant une sonde de vivacité. Ceux-ci permettent à Kubernetes de détecter le moment où vos conteneurs passent à un état d’échec. Le plan de contrôle redémarrera automatiquement le conteneur, réduisant ainsi la probabilité d’une panne de service.

Ajouter un nouveau livenessProbe champ au-dessus du readinessProbe:

livenessProbe:
  tcpSocket:
    port: 8080

Définissez enfin une limite de mémoire pour traiter le dernier avertissement. Bien que l’exemple de manifeste inclue des requêtes de CPU et de mémoire, ainsi qu’une limite de CPU, il n’y a pas de limite stricte sur la mémoire. Le conteneur peut consommer une mémoire RAM illimitée, créant potentiellement une situation de mémoire insuffisante dans votre cluster.

Le YAML révisé devrait ressembler à ceci :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      namespace: demo-deployment
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.23  
          livenessProbe:
            tcpSocket:
              port: 8080
          readinessProbe:
            tcpSocket:
              port: 8080
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          ports:
            - containerPort: 80

Répétez le datree test commande pour vérifier que votre déploiement réussit maintenant les contrôles de stratégie :

$ datree test datree-demo.yaml
(Summary)

- Passing YAML validation: 1/1

- Passing Kubernetes (1.20.0) schema validation: 1/1

- Passing policy check: 1/1

Règles de personnalisation

L’exemple utilisé jusqu’à présent s’appuie sur l’ensemble intégré de politiques par défaut de Datree. Celles-ci couvrent de nombreuses bonnes pratiques Kubernetes, telles que la configuration de sondes, l’utilisation de limites de ressources et l’évitement des API obsolètes.

Vous pouvez personnaliser les politiques en reliant la CLI Datree à votre tableau de bord en ligne. Ici, vous pouvez désactiver les politiques dont vous n’avez pas besoin et activer de nouvelles règles personnalisées pour mettre en œuvre les routines de votre organisation.

Le moyen le plus simple de se connecter à Datree est de suivre le lien affiché à la fin de la sortie de la CLI de Datree :

| See all rules in policy           | https://app.datree.io/login?t=bbY... |

La CLI génère automatiquement un jeton unique pour votre compte. Cliquez sur le lien, puis connectez-vous à Datree avec GitHub ou Google.

Vous serez redirigé vers le tableau de bord des politiques qui affiche toutes les politiques actives sur votre compte. Cliquez sur les boutons bascule dans la colonne « État » pour activer ou supprimer des politiques. Vos modifications s’appliqueront immédiatement aux nouvelles analyses. L’interface de ligne de commande télécharge automatiquement votre liste de stratégies avant de démarrer chaque test.

Le tableau de bord fournit également un historique des analyses que vous avez effectuées. Cliquez sur l’onglet « Historique » dans la barre latérale gauche pour récupérer les résultats de l’analyse précédente.

Analyse avec une stratégie spécifique

Datree a actuellement 60 règles intégrées qui fournissent des tests individuels. Les règles sont regroupées en groupes appelés stratégies. La stratégie par défaut est utilisée automatiquement. Il active 21 des 60 règles. Datree est également livré avec des politiques préconfigurées pour les configurations Argo et NSA Kubernetes.

Vous pouvez créer votre propre politique avec le bouton bleu « Créer une politique » dans le tableau de bord en ligne. Donnez un nom à votre stratégie et activez une ou plusieurs règles.

Pour démarrer une analyse avec une stratégie spécifique, ajoutez le --policy Indicateur CLI. Cela devrait être fourni le nom de la stratégie que vous souhaitez utiliser.

$ datree test --policy NSA datree-demo.yaml

Datree vous permet également de mettre en œuvre des tests personnalisés en ajoutant des règles entièrement nouvelles. Bien que la création de règles sorte du cadre de ce guide de démarrage, vous pouvez imposer que les déploiements aient des étiquettes spécifiques, un nombre minimum de répliques et utilisent des images d’un registre approuvé. Les règles sont définies au format JSON ou YAML à l’aide de la logique de schéma JSON.

Numérisation de plusieurs fichiers

La datree test La commande accepte un chemin de fichier ou un modèle glob. Vous pouvez analyser un répertoire de manifestes à l’aide de la syntaxe suivante :

datree test demo-dir/*.yaml

Tous les fichiers non valides correspondant à votre glob apparaîtront comme ayant échoué au contrôle de validation Datree YAML.

Authentification d’autres instances CLI

La CLI Datree se connecte à votre compte à l’aide d’un jeton d’authentification. Un nouveau jeton est généré automatiquement lorsque vous installez l’interface de ligne de commande. Il crée un nouveau compte la première fois qu’il est utilisé.

Vous devrez fournir manuellement votre jeton d’authentification existant si vous installez Datree sur une autre machine. Vous pouvez récupérer la valeur de la token champ dans votre ~/.datree/config.yaml dossier. Sinon, dirigez-vous vers le tableau de bord en ligne, cliquez sur votre photo de profil dans le coin supérieur droit, choisissez Paramètres dans le menu et passez à l’onglet « Gestion des jetons ».

De retour dans votre nouvelle instance CLI, utilisez la commande suivante pour ajouter votre jeton :

$ datree config set token <TOKEN_VALUE>

La CLI utilisera désormais les stratégies configurées dans votre compte. Les analyses commenceront également à apparaître sur l’écran Historique.

Utilisation de Datree sans accès au compte

Vous pouvez désactiver les fonctionnalités de connexion au compte de Datree CLI si vous êtes satisfait de l’ensemble de règles par défaut et ne souhaitez pas que les analyses communiquent avec les serveurs de Datree :

$ datree config set offline local

Cela supprime également la prise en charge de la validation du schéma Kubernetes.

Vous pouvez empêcher l’affichage d’analyses individuelles dans la page Historique de votre compte en définissant le paramètre --no-record drapeau dans la CLI.

$ datree test datree-demo.yaml --no-record

Sommaire

Datree automatise la détection des erreurs de configuration Kubernetes en proposant une simple CLI configurée de manière centralisée par un tableau de bord en ligne. Cela garantit que tous les membres de votre équipe testent leurs manifestes par rapport aux mêmes politiques, ce qui réduit le risque que des erreurs n’atteignent votre cluster. Vous pouvez intégrer Datree dans vos pipelines CI pour empêcher le déploiement de modifications contenant une violation de règle.

Datree est également disponible en tant que webhook d’admission Kubernetes qui bloquera activement les ressources non conformes. Les webhooks d’admission sont chargés de décider si de nouveaux objets peuvent être ajoutés à un cluster ; Datree rejettera tous les objets qui échouent à vos tests de politique. La configuration du webhook offre une certitude absolue que les ressources mal configurées ne peuvent pas être utilisées, même si un utilisateur applique manuellement un manifeste avec Kubectl.