Kubernetes (ou k8) est un outil très populaire et performant qui répond à un besoin crucial de l’environnement applicatif : comment faire fonctionner un container sur un serveur ? Cependant, débuter sur Kubernetes peut entrainer des problèmes ou des questionnements qui sont, pour la plupart, communs à tous les devops débutant avec l’outil. Dans cet article, nous vous aidons à dépanner votre solution Kubernetes.
Je veux faire fonctionner un container kubernetes
Vous avez travaillé sur un nouveau projet (dont le nom de code est Ambient) et il est maintenant prêt à être déployé. Vous construisez donc une image container pour l’exécuter (Ambient-backend) et vous devez ensuite déployer le container dans votre cluster Kubernetes.
Pour cela, il faut définir un pod. Les pod sont la plus petite unité de kubernetes et contiennent un ou plusieurs containers. Définissez le pod comme ceci :
apiVersion: v1
kind: Pod
metadata:
name: Ambient-backend
spec:
containers:
- name: Ambient-backend
image: Ambient-backend:1.14.2
ports:
- containerPort: 80
Ceci est un exemple de fichier YAML définissant une ressource Kubernetes que vous pouvez déployer sur votre cluster. Toutes les ressources ont 4 propriétés :
- apiVersion : quelle version de la ressource utiliser
- Kind : toutes les ressources ont un type (ici un pod)
- metadata : paire de valeurs utilisées pour organiser les ressources de votre cluster
- sepc : les détails de la ressource que vous déployez. Par exemple, le type de ressource Pod doit avoir une clé containers avec un tableau de containers, chacun d’entre eux ayant une image.
Une fois ce fichier enregistré en tant que pod.yaml vous pouvez le déployer en exécutant kubectl apply -f pod.yaml.
Que fait mon pod kubernetes ?
Vous avez déployé votre pod mais fonctionne-t-il ? Fait-il bien ce que vous attendez de lui ? Vous pouvez utiliser kubectl pour inspecter votre pod.
Vous pouvez associer kubectl à votre lettre k dans le terminal. Cette fonction sera très souvent utilisée dans le monitoring de vos clusters et cela vous fera gagner un temps précieux. Vous pouvez exécuter k get pods pour voir une liste des pods que vous avez déployés, k describe pod pour voir plus d’informations sur ce pod.
Comment redémarrer ses container en cas de crash ?
Votre projet avance, mais il tombe régulièrement en panne. Or, c’est un service important et il doit automatiquement redémarrer lorsque cela arrive. C’est là que la puissance du service déclaratif (et non pas impératif) de Kubernetes prend tout son sens.
Vous déclarez que ce pod doit être en cours d’exécution dans votre fichier .yaml et si jamais ce n’est pas le cas, Kubernetes fera tout son possible pour réparer le pod. Si un pod se plante, Kubernetes le fera redémarrer, car cela ramènera le cluster à l’état prévu pour celui-ci. La politique de redémarrage de base de kubernetes est très logique mais vous pouvez la personnaliser si vous le souhaitez.
Mes Containers ne doivent pas avoir de downtime en cas de crash
Kubernetes redémarre le backend du projet Ambient lorsqu’il crash mais cela entraine un downtime de quelques secondes voir minutes en cas de crashs répété. Vous aimeriez donc que le backend soit disponible même en cas de plantage et redémarrage.
Le moyen le plus simple d’y parvenir est d’utiliser des répliques. Cela consiste à exécuter le même container plusieurs fois simultanément. Si une réplique tombe en panne, les autres peuvent ainsi prendre le relais. Pour configurer des répliques sur Kubernetes, utilisez un déploiement :
# Champs standard de Kubernetes pour toutes les ressources : apiVersion, kind, metadata, spec.apiVersion: apps/v1
kind: Deployment
metadata:
name: Ambient-backend-deployment
labels:
app: Ambient-backend
# Le "spec" est l'endroit où sont définis les éléments spécifiques au déploiement.
spec:
replicas: 3
# Le "selector" définit les pods qui seront gérés par ce déploiement.
# Nous disons à Kubernetes de répliquer le pod correspondant à l'étiquette `app : Ambient`
selector:
matchLabels:
app: Ambient
role: backend
# Le "template" définit un pod qui sera géré par ce déploiement.
template :
metadata :
# Assurez-vous que les étiquettes du pod correspondent aux étiquettes que le déploiement sélectionne (voir ci-dessus).
labels:
app: Ambient
role: backend
# Le Pod a sa propre spécification, à l'intérieur de la spécification du déploiement.
# Cette spécification définit les conteneurs que le Pod doit exécuter.
spec:
containers:
- name: Ambient-backend
image: Ambient-backend:1.14.2
ports:
- containerPort: 80
Un déploiement gère un ensemble de pods. L’exemple ci-dessus gère ceux portant l’étiquette app : Ambient en s’assurant qu’il y a toujours 3 répliques de ce pod.
Si vous utilisez ce code, vous remarquerez que pendant un bref instant aucune des répliques ne fonctionnent pas immédiatement puisqu’il ne les crée pas explicitement. Kubernetes étant un environnement déclaratif, il va remarquer que son environnement ne correspond pas à l’état déclaré et souhaité, et va donc faire en sorte de corriger cela tout seul.
Je veux récupérer des métriques sur mon cluster
Afin d’administrer votre cluster au mieux, vous souhaitez surement récolter des données sur la latence ou le nombre de réponses HTTPS. Pour cela, vous pouvez utiliser un service extérieur au risque de devoir taper toutes vos métriques dans chaque service à la main en cas de panne de celui-ci.
Les Ingresscontrollers sont une excellente alternative aux outils externes. Ils permettent de récupérer des métriques dans un fichier spécial appelé Prometheus et de les afficher de manière graphique. Cela permet de gagner du temps, car vous n’aurez pas à implanter d’outils externes et de connaitre en temps réel l’état de votre cluster.
De manière générale, les applications Web sont confrontées aux mêmes problèmes, quel que soit l’endroit où elles sont déployées. La gestion et l’équilibrage de la charge entre les répliques, la limitation des privilèges réseau, les mises à niveau sans temps d’arrêt : aucun de ces problèmes n’est propre à Kubernetes.
Vous savez peut-être déjà comment les résoudre dans votre modèle de déploiement préféré. Il suffit alors de traduire les solutions standard en jargon Kubernetes (pods, déploiements, etc.).
Si vous souhaitez en connaître davantage sur cet orchestrateur de conteneurs, nos articles « Comment se former sur Kubernetes ? » et « Comment se former sur Kubernetes gratuitement ? » vous seront d’une grande aide.