10 bonnes pratiques Kubernetes pour une meilleure orchestration des conteneurs

Parlons de certaines des meilleures pratiques à suivre lors de l'utilisation de Kubernetes.

Kubernetes est une plate-forme d'orchestration de conteneurs open source qui automatise le déploiement de conteneurs, la mise à l'échelle continue et la réduction de l'échelle, l'équilibrage de la charge des conteneurs et bien d'autres choses.

Puisque la conteneurisation est utilisée sur de nombreux serveurs de production avec des milliers de conteneurs, il devient très important de bien les gérer, et c'est ce que Kubernetes t.

Si vous utilisez Kubernetes, vous devez adopter les meilleures pratiques pour une meilleure orchestration des conteneurs.

Voici une liste de certaines des meilleures pratiques Kubernetes que vous devez suivre.

# 1. Définir les demandes de ressources et les limites

Lorsque vous déployez une grande application sur un cluster de production avec des ressources limitées où les nœuds manquent de mémoire ou de processeur, l'application cesse de fonctionner. Ce temps d'arrêt de l'application peut avoir un impact énorme sur l'entreprise. Mais vous pouvez résoudre ce problème en ayant des demandes de ressources et des limites.

Les demandes et les limites de ressources sont les mécanismes de Kubernetes pour contrôler l'utilisation des ressources telles que la mémoire et le processeur. Si un pod consomme tout le processeur et la mémoire, les autres pods seront privés de ressources et ne pourront pas exécuter l'application. Par conséquent, vous devez définir des demandes de ressources et des limites sur les pods pour augmenter la fiabilité.

Juste pour info, la limite sera toujours supérieure à la demande. Votre conteneur ne s'exécutera pas si votre requête est supérieure à la limite définie. Vous pouvez définir des demandes et des limites pour chaque conteneur d'un pod. Le processeur est défini en millicores et la mémoire en octets (mégaoctet / mégaoctet).

Vous trouverez ci-dessous un exemple de définition d'une limite à 500 millicores de processeur et 128 mégaoctets, et de définition d'un quota pour les demandes à 300 millicores de processeur et 64 mégaoctets.

containers:
- name: prodcontainer1
    image: ubuntu
    resources:
        requests:
            memory: “64Mi”
            cpu: “300m”
        limits:                              
            memory: “128Mi”
            cpu: “500m”

# 2. Utilisez la vivacité et la préparation

Les bilans de santé sont très importants dans Kubernetes.

Il fournit deux types de contrôles de santé - Préparation sondes et Vivacité sondes.

Les sondes de disponibilité sont utilisées pour vérifier si l'application est prête à commencer à diffuser du trafic ou non. Cette sonde doit passer dans Kubernetes avant de commencer à envoyer le trafic vers le pod exécutant l'application à l'intérieur d'un conteneur. Kubernetes arrêtera d'envoyer le trafic vers le pod jusqu'à ce que cette vérification de l'état de préparation échoue.

Les sondes de vivacité sont utilisées pour vérifier si l'application est toujours en cours d'exécution (active) ou si elle s'est arrêtée (morte). Si l'application fonctionne correctement, Kubernetes ne fait rien. Si votre application est morte, Kubernetes lancera un nouveau pod et y exécutera l'application.

Si ces vérifications ne sont pas effectuées correctement, les pods peuvent être arrêtés ou commencer à recevoir les demandes des utilisateurs avant même qu'ils ne soient prêts.

Il existe trois types de sondes qui peuvent être utilisées pour les contrôles de vivacité et de préparation - HTTP, Commander, et TCP.

Permettez-moi de montrer un exemple de la plus courante qui est la sonde HTTP.

Ici, votre application aura un serveur HTTP à l'intérieur. Lorsque Kubernetes interroge un chemin vers le serveur HTTP et obtient une réponse HTTP, il marquera que l'application est saine, sinon défectueuse.

apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
     livenessProbe:
       httpGet:
         path: /prodhealth
         port: 8080

# 3. Créer des images de petits conteneurs

Il est préférable d'utiliser des images de conteneur plus petites car cela prend moins de stockage et vous pourrez extraire et créer les images plus rapidement. Étant donné que la taille de l'image sera plus petite, les chances d'attaques de sécurité seront également moindres.

Il existe deux façons de réduire la taille du conteneur: en utilisant une image de base plus petite et un modèle de générateur. Actuellement, la dernière image de base de NodeJS fait 345 Mo, alors que l'image alpine NodeJS est de seulement 28 Mo, plus de dix fois plus petite. Par conséquent, utilisez toujours les images plus petites et ajoutez les dépendances requises pour exécuter votre application.

Pour réduire encore plus la taille des images de conteneur, vous pouvez utiliser un modèle de générateur. Le code est construit dans le premier conteneur, puis le code compilé est conditionné dans le conteneur final sans tous les compilateurs et outils nécessaires pour rendre le code compilé, ce qui rend l'image du conteneur encore plus petite.

# 4. Accorder des niveaux d'accès sécurisés (RBAC)

Disposer d'un cluster Kubernetes sécurisé est très important.

L'accès au cluster doit être bien configuré. Vous devez définir le nombre de requêtes par utilisateur par seconde / minute / heure, les sessions simultanées autorisées par adresse IP, la taille de la requête et la limite des chemins et des noms d'hôte. Cela aidera à protéger le cluster de Les attaques DDoS.

Les développeurs et ingénieurs DevOps travaillant sur un cluster Kubernetes doivent disposer d'un niveau d'accès défini. La fonctionnalité de contrôle d'accès basé sur les rôles (RBAC) de Kubernetes est utile ici. Vous pouvez utiliser des rôles et des rôles de cluster pour définir les profils d'accès. Pour faciliter la configuration de RBAC, vous pouvez utiliser l'open source rbac-gestionnaires disponible pour vous aider à simplifier la syntaxe ou à utiliser Rancher, il fournit RBAC par défaut.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Les secrets Kubernetes stockent des informations confidentielles telles que les jetons d'authentification, les mots de passe et les clés ssh. Vous ne devez jamais vérifier les secrets de Kubernetes sur le IaC référentiel, sinon, il sera exposé à ceux sur qui a accès à votre référentiel git.

DevSecOps est un mot à la mode maintenant qui parle de DevOps et de la sécurité. Les organisations adoptent la tendance car elles en comprennent l'importance.

# 5. Garder à jour

Il est recommandé de toujours avoir la dernière version de Kubernetes installée sur le cluster.

La dernière version de Kubernetes comprend de nouvelles fonctionnalités, des mises à jour des fonctionnalités précédentes, des mises à jour de sécurité, des corrections de bogues, etc. Si vous utilisez Kubernetes avec un fournisseur de cloud, la mise à jour devient très simple.

# 6. Utiliser les espaces de noms

Kubernetes propose trois espaces de noms différents - défaut, système kube, et kube-public.

Ces espaces de noms jouent un rôle très important dans un cluster Kubernetes pour l'organisation et la sécurité entre les équipes.

Il est logique d'utiliser l'espace de noms par défaut si vous êtes une petite équipe travaillant seulement 5 à 10 microservices. Mais une équipe en croissance rapide ou une grande organisation aura plusieurs équipes travaillant sur un environnement de test ou de production, de sorte que chaque équipe doit disposer d'un espace de noms distinct pour une gestion plus facile.

S'ils ne le font pas, ils peuvent finir par écraser ou perturber accidentellement l'application / la fonctionnalité d'une autre équipe sans même s'en rendre compte. Il est suggéré de créer plusieurs espaces de noms et de les utiliser pour segmenter vos services en blocs gérables.

Voici un exemple de création de ressources dans un espace de noms:

apiVersion: v1
kind: Pod
metadata:
   name: pod01
namespace: prod
   labels:
      image: pod01
spec:
   containers:
- name: prod01
  Image: ubuntu

# 7. Utiliser des étiquettes

Au fur et à mesure que vos déploiements Kubernetes se développent, ils comprendront invariablement plusieurs services, pods et autres ressources. Leur suivi peut devenir fastidieux. Il est encore plus difficile de décrire Kubernetes comment ces diverses ressources interagissent, comment vous voulez qu'elles soient répliquées, mises à l'échelle et gérées. Les libellés dans Kubernetes sont très utiles pour résoudre ces problèmes.

Les libellés sont des paires clé-valeur utilisées pour organiser les éléments dans l'interface Kubernetes.

Par exemple, app: kube-app, phase: test, role: front-end. Ils sont utilisés pour décrire Kubernetes comment les différents objets et ressources du cluster fonctionnent ensemble.

apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 labels:
   environment: testing
   team: test01
spec:
 containers:
   - name: test01
     image: "Ubuntu"
     resources:
       limits:
        cpu: 1

Ainsi, vous pouvez réduire la douleur de la production Kubernetes en étiquetant toujours les ressources et les objets.

# 8. Enregistrement d'audit

Pour identifier les menaces dans le cluster Kubernetes, l'audit des journaux est très important. L'audit aide à répondre à des questions telles que ce qui s'est passé, pourquoi cela s'est produit, qui l'a fait, etc.

Toutes les données liées aux requêtes adressées à kube-apiserver sont stockées dans un fichier journal appelé audit.log. Ce fichier journal est structuré au format JSON.

Dans Kubernetes, par défaut, le journal d'audit est stocké dans <em>/var/log/audit.log</em> et la politique d'audit est présente à <em>/etc/kubernetes/audit-policy.yaml</em>.

Pour activer la journalisation d'audit, démarrez le kube-apiserver avec ces paramètres:

--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log

Voici un exemple audit.log fichier configuré pour consigner les modifications dans les pods:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
   - level: Metadata
     resources:
     - group: ""
      resources: ["pods/log", "pods/status"]

Vous pouvez toujours revenir en arrière et vérifier les journaux d'audit en cas de problème dans le cluster Kubernetes. Cela vous aidera à restaurer l'état correct du cluster.

# 9. Appliquer les règles d'affinité (nœud / pod)

Il existe deux mécanismes dans Kubernetes pour mieux associer les pods aux nœuds - Cosse et Nœud affinité. Il est recommandé d'utiliser ces mécanismes pour de meilleures performances.

À l'aide de l'affinité de nœud, vous pouvez planifier des pods sur les nœuds en fonction de critères définis. Selon les exigences du pod, le nœud correspondant est sélectionné et affecté dans un cluster Kubernetes.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
spec:
  affinity:
    nodeAffinity:    
preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 2
        preference:        
matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: ubuntu
    image: ubuntu
    imagePullPolicy: IfNotPresent

À l'aide de l'affinité de pod, vous pouvez planifier plusieurs pods sur le même nœud (pour améliorer la latence) ou décider de conserver les pods sur des nœuds séparés (pour une haute disponibilité) pour augmenter les performances.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod
spec:
  affinity:
    podAffinity:
     
requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
         
matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: ubuntu-pod
    image: ubuntu

Après avoir analysé la charge de travail de votre cluster, vous devez décider de la stratégie d'affinité à utiliser.

# 10. Résiliation de Kubernetes

Kubernetes met fin aux pods lorsqu'ils ne sont plus nécessaires. Vous pouvez l'initier via une commande ou un appel API, les pods sélectionnés passent à l'état de terminaison et aucun trafic n'est envoyé à ces pods. Un message SIGTERM est ensuite envoyé à ces pods, après quoi les pods s'éteignent.

Les pods se terminent correctement, par défaut la période de grâce est de 30 secondes. Si les pods sont toujours en cours d'exécution, Kubernetes envoie un message SIGKILL qui arrête de force les pods. Enfin, ces pods sont supprimés par Kubernetes du serveur d'API sur la machine maître.

Si vos pods prennent toujours plus de 30 secondes, vous pouvez augmenter cette période de grâce à 45 ou 60 secondes.

apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
  terminationGracePeriodSeconds: 60

Conclusion

J'espère que ces bonnes pratiques vous aideront à mieux orchestration de conteneurs en utilisant Kubernetes. Allez-y et essayez de les implémenter dans votre cluster Kubernetes pour de meilleurs résultats.

Ensuite, explorez le meilleur Outils Kubernetes pour le succès DevOps.