Parlons de certaines des meilleures pratiques à suivre lors de l'utilisation de Kubernetes
Kubernetes est une plateforme open-source d'orchestration de conteneurs qui automatise le déploiement de conteneurs, la mise à l'échelle continue et le désétalement, l'équilibrage de la charge des conteneurs et bien d'autres choses encore
Étant donné que 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 qui fait Kubernetes
Si vous utilisez Kubernetes, vous devez adopter les meilleures pratiques pour une meilleure orchestration des conteneurs
Voici une liste des meilleures pratiques de Kubernetes que vous devez suivre
#1. Définissez les demandes et les limites de ressources
Lorsque vous déployez une grosse application sur un cluster de production avec des ressources limitées et que les nœuds manquent de mémoire ou de CPU, l'application s'arrête de fonctionner. Ce temps d'arrêt de l'application peut avoir un impact considérable sur l'entreprise. Mais vous pouvez résoudre ce problème en prévoyant des demandes et des limites de ressources
Les demandes et les limites de ressources sont les mécanismes de Kubernetes qui permettent de contrôler l'utilisation des ressources telles que la mémoire et l'unité centrale. Si un pod consomme tout le CPU et toute la mémoire, les autres pods seront privés de ressources et ne pourront pas exécuter l'application. Vous devez donc définir des demandes et des limites de ressources pour les modules afin d'accroître la fiabilité
Pour votre information, la limite sera toujours plus élevée que la demande. Votre conteneur ne fonctionnera pas si votre demande est supérieure à la limite définie. Vous pouvez définir des demandes et des limites pour chaque conteneur d'un module. L'unité centrale est définie en millicores et la mémoire en octets (mégaoctet/mébibyte)
Vous trouverez ci-dessous un exemple de définition d'une limite de 500 millicores de CPU et de 128 mégaoctets, et de définition d'un quota de requêtes de 300 millicores de CPU et de 64 mégaoctets
containers :
- name : prodcontainer1
image : ubuntu
resources :
requests :
memory : "64Mi"
cpu : "300m"
limits :
memory :
“
128Mi"
cpu : "500m"
#2. Utilisez livenessProbe et readinessProbe
Les contrôles de santé sont très importants dans Kubernetes
Il fournit deux types de contrôles de santé - Préparation sondes et Caractère vivant sondes
Les sondes de préparation sont utilisées pour vérifier si l'application est prête à servir le trafic ou non. Cette sonde doit être acceptée par Kubernetes avant qu'il ne commence à envoyer le trafic au pod exécutant l'application à l'intérieur d'un conteneur. Kubernetes cessera d'envoyer le trafic vers le pod tant que cette vérification de l'état de préparation n'aura pas échoué
Les sondes de vivacité sont utilisées pour vérifier si l'application est toujours en cours d'exécution (vivante) ou si elle s'est arrêtée (morte). Si l'application fonctionne correctement, Kubernetes ne fait rien. Si votre application est morte, Kubernetes lance un nouveau pod et y exécute l'application
Si ces vérifications ne sont pas effectuées correctement, les pods peuvent être interrompus ou commencer à recevoir des demandes d'utilisateurs avant même d'être prêts
Il existe trois types de sondes qui peuvent être utilisées pour les contrôles de disponibilité et d'état de préparation : HTTP, Commandement et TCP
Permettez-moi de vous montrer un exemple de la sonde la plus courante, à savoir la sonde HTTP
Dans ce cas, votre application comporte un serveur HTTP. Lorsque Kubernetes envoie un ping vers le serveur HTTP et obtient une réponse HTTP, il indique que l'application est saine, sinon elle est malsaine
apiVersion : v1 kind : Pod metadata : name : container10 spec : containers : - image : ubuntu name : container10 livenessProbe : httpGet : path : /prodhealth port : 8080
#3. Construire de petites images de conteneurs
Il est préférable d'utiliser des images de conteneurs plus petites parce qu'elles prennent moins de place et que vous serez en mesure d'extraire et de construire les images plus rapidement. La taille de l'image étant plus petite, les risques d'attaques de sécurité seront également plus élevés
Il existe deux façons de réduire la taille des conteneurs : en utilisant une image de base plus petite et un modèle de construction. Actuellement, la dernière image de base de NodeJS pèse 345 Mo, tandis que l'image alpine de NodeJS ne pèse que 28 Mo, soit plus de dix fois moins. Utilisez donc toujours les images les plus petites et ajoutez les dépendances nécessaires à l'exécution de votre application
Pour réduire encore davantage la taille des images de conteneurs, vous pouvez utiliser un modèle de construction. Le code est construit dans le premier conteneur, puis le code compilé est empaqueté dans le dernier conteneur sans tous les compilateurs et outils nécessaires pour réaliser le code compilé, ce qui rend l'image du conteneur encore plus petite
#4. Accordez des niveaux d'accès sûrs (RBAC)
Il est très important d'avoir un cluster Kubernetes sécurisé
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 des requêtes et la limite des chemins et des noms d'hôtes. Cela vous aidera à protéger le cluster contre les attaques DDoS
Les développeurs et les ingénieurs DevOps qui travaillent sur un cluster Kubernetes doivent avoir un niveau d'accès défini. La fonction de contrôle d'accès basé sur les rôles (RBAC) de Kubernetes est utile ici. Vous pouvez utiliser les rôles et les ClusterRoles pour définir les profils d'accès. Pour faciliter la configuration du RBAC, vous pouvez utiliser les gestionnaires rbac open-source disponibles pour vous aider à simplifier la syntaxe ou utiliser Rancher, qui fournit le RBAC par défaut
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : cluster-role
rules :
- apiGroups : [""]
resources : ["pods"]
verbs : ["get", "list"]
Kubernetes Secrets stocke 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 Kubernetes sur le dépôt IaC, sinon ils seront exposés à ceux qui ont accès à votre dépôt git
DevSecOps est un mot à la mode qui parle de DevOps et de sécurité. Les organisations adoptent cette tendance car elles en comprennent l'importance
#5. Restez à 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 de 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 facile
#6. Utilisez les espaces de noms
Kubernetes est livré avec trois espaces de noms différents : par 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 qui ne travaille que sur 5 à 10 microservices. Mais une équipe en pleine croissance ou une grande organisation aura plusieurs équipes travaillant sur un environnement de test ou de production, de sorte que chaque équipe doit avoir un espace de noms distinct pour faciliter la gestion
Si elle ne le fait pas, elle peut finir par écraser ou perturber accidentellement l'application/la fonctionnalité d'une autre équipe sans même s'en rendre compte. Il est conseillé de créer plusieurs espaces de noms et de les utiliser pour segmenter vos services en morceaux gérables
Voici un exemple de création de ressources à l'intérieur d'un espace de noms
apiVersion : v1
kind : Pod
metadata :
name : pod01
namespace : prod
labels :
image : pod01
spec :
containers :
–
name : prod01
Image : ubuntu
#7. Utiliser les étiquettes
Au fur et à mesure que vos déploiements Kubernetes se développent, ils incluront invariablement plusieurs services, pods et autres ressources. Le suivi de ces éléments peut s'avérer fastidieux. Il peut être encore plus difficile de décrire dans Kubernetes comment ces différentes ressources interagissent, comment vous voulez qu'elles soient répliquées, mises à l'échelle et entretenues. Les étiquettes dans Kubernetes sont très utiles pour résoudre ces problèmes
Les étiquettes 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 la façon dont 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"
ressources :
limites :
cpu : 1
Ainsi, vous pouvez réduire la douleur de la production Kubernetes en étiquetant toujours les ressources et les objets
#8. Journalisation de l'audit
Pour identifier les menaces dans le cluster Kubernetes, l'audit des journaux est très important. L'audit permet de répondre à des questions telles que ce qui s'est passé, pourquoi cela s'est passé, qui l'a fait se produire, etc
Toutes les données relatives aux demandes faites à 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 dans <em>/etc/kubernetes/audit-policy.yaml</em>
Pour activer la journalisation des audits, démarrez kube-apiserver avec ces paramètres
–
-audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log
Voici un exemple de fichier audit.log
configuré pour enregistrer les changements dans les pods
apiVersion : audit.k8s.io/v1
kind : Policy
omitStages :
- "RequestReceived"
rules :
- level : RequestResponse
resources :
- group : ""
resources : ["pods"]
- level : Metadata
resources :
- group : ""
ressources : ["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 à rétablir l'état correct du cluster
#9. Appliquer les règles d'affinité (Node/Pod)
Il existe deux mécanismes dans Kubernetes pour associer les pods aux nœuds d'une meilleure façon - Cosse et Nœud l'affinité. Il est recommandé d'utiliser ces mécanismes pour améliorer les performances
En utilisant 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 assigné 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
En utilisant l'affinité des pods, vous pouvez planifier plusieurs pods sur le même nœud (pour améliorer la latence) ou décider de garder les pods sur des nœuds séparés (pour la haute disponibilité) afin d'augmenter la performance
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. Terminaison de Kubernetes
Kubernetes termine les pods lorsqu'ils ne sont plus nécessaires. Vous pouvez l'initier par 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 alors envoyé à ces pods, après quoi les pods s'arrêtent
Les pods sont arrêtés de manière gracieuse, 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 les arrête de force. Enfin, ces pods sont supprimés par Kubernetes du serveur 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 orchestrer les conteneurs à l'aide de Kubernetes. Allez-y et essayez de les mettre en œuvre dans votre cluster Kubernetes pour obtenir de meilleurs résultats
Ensuite, découvrez les meilleurs outils Kubernetes pour une réussite DevOps.
-
Avi est un passionné de technologie avec une expertise dans les technologies en vogue telles que DevOps, Cloud Computing, Big Data et bien d'autres. Il est passionné par l'apprentissage des technologies de pointe et le partage de ses connaissances avec d'autres... en savoir plus