Kubernetes oomkilled
Prérequis
Pour utiliser les services Kubernetes, vous aurez besoin d'un cluster Minikube. Vous devrez configurer un cluster Minikube sur votre système pour faire fonctionner cette technique. Pour configurer un cluster Minikube, utilisez le terminal de la ligne de commande. Il peut être utilisé de deux manières. Recherchez «Terminal» dans la section de recherche de programme de votre système. Ctrl + Alt + T est un raccourci clavier qui peut être utilisé pour ceci:
Au moins 300 MIB de mémoire doivent être disponibles sur chaque nœud de votre cluster. Vous devrez avoir le service de métriques-serveur dans votre cluster pour certaines tâches sur cette page. Vous pouvez ignorer ces étapes si le serveur de métriques fonctionne déjà. Maintenant, saisissez la commande annexe suivante.
Utilisez maintenant la commande jointe.
La réponse guide les mesures.k8.IO Si l'API de métriques de ressources est accessible, comme indiqué dans la capture d'écran ci-dessus.
Étapes pour créer un espace de noms
Faites un espace de noms pour les ressources que vous créez ici pour les séparer du reste de votre cluster.
Un nouveau pod est formé, comme vous pouvez le voir ci-dessous.
Fournir le champ Ressources: Demandes dans le manifeste de la ressource du conteneur afin de définir une demande de mémoire. Inclure des ressources: limites pour fixer une limite de RAM. Vous concelerez une pod avec un conteneur. Le conteneur a une demande de mémoire de 100 MIB et une limite de mémoire de 200 MIB. Le fichier de configuration du pod est le suivant:
Lorsque le conteneur démarre, la section Args du fichier de configuration fournit ses paramètres. Les options «-vm-octets» et «150m» instruisent le conteneur pour allouer 150 MIB de RAM.
Ci-dessous, vous pouvez voir que nous avons créé le pod:
Cette commande vérifiera si le conteneur de pod est opérationnel:
Selon le résultat, le conteneur unique du pod a une demande de mémoire de 100 MIB et une limite de mémoire de 200 MIB.
Pour obtenir les mesures de la pod, exécutez la commande Kubectl Top.
Comment la limite de mémoire d'un conteneur peut-elle être dépassée?
Si le nœud semble avoir suffisamment de mémoire, un conteneur peut dépasser sa demande de mémoire. D'un autre côté, un conteneur ne peut pas utiliser plus de mémoire qu'il n'a. Si un conteneur prend plus de mémoire que ce qui est affecté, il sera résilié. Le conteneur sera supprimé s'il continue d'utiliser la mémoire au-dessus de sa limite. Le kubelet redémarre un conteneur terminé s'il peut être repris, tout comme toute autre forme d'échec de l'exécution.
Ici, nous allons créer un pod. Ce pod essaiera d'allouer plus de mémoire qu'il n'a déjà.
Le fichier de configuration pour un pod avec un conteneur et une demande de mémoire de 50 MIB et une limite de mémoire de 100 MIB sont les suivants:
Selon la section Args du fichier de configuration, le conteneur tentera d'allouer 250 MIB de RAM, significativement au-dessus de la limite de 100 MIB.
Encore une fois, nous avons créé le pod ici.
Ici, vous pouvez afficher les informations complètes du pod. Le conteneur est en cours d'exécution ou non à ce stade. La répétition de la commande précédente jusqu'à ce que le conteneur soit tué est requis:
Obtenez un aperçu plus approfondi du statut du conteneur. Selon la sortie, le conteneur a été détruit car il a manqué de mémoire.
Dans cet exemple, le kubelet redémarre le conteneur car il peut être redémarré. Répétez cette commande plusieurs fois pour s'assurer que le conteneur est tué et redémarré régulièrement. Selon la sortie, le conteneur est tué, restauré, tué à nouveau, initié à nouveau, etc.
La commande suivante vous permet de visualiser des informations complètes liées à l'historique du pod.
Le résultat révèle que le conteneur démarre et s'arrête constamment:
Ici, vous pouvez afficher les informations détaillées sur les nœuds de votre cluster:
Un enregistrement du conteneur tué en raison d'un problème hors mémoire est inclus dans la sortie:
Cette commande supprime le pod, comme vous pouvez le voir ci-dessous.
Que devriez-vous faire si vous avez une demande de mémoire trop grande pour vos nœuds?
Les demandes de mémoire et les limitations sont généralement liées à des conteneurs, mais il est également utile de considérer les pods comme ayant des demandes de mémoire et des restrictions. La demande de mémoire est définie comme le total de tous les besoins de mémoire pour tous les conteneurs du pod.
Les gousses sont programmées et maintenues via des demandes.
Ici, nous allons construire un pod avec une demande de mémoire plus grande que n'importe quel nœud de la capacité de votre cluster.
Voici le fichier de configuration d'un pod, y compris un conteneur et un besoin de mémoire GIB de 1000, qui est probablement plus que n'importe quel nœud de votre cluster peut gérer.
La commande Appliquer suivante crée le pod, comme vous pouvez le voir.
Utilisez maintenant la commande `` get pod ''. L'état du pod est en attente (voir la sortie). Le pod n'est pas réglé pour fonctionner sur n'importe quel nœud et restera en attente indéfiniment.
Cette commande vous aidera à voir plus de détails sur la cosse, y compris les événements à venir:
La sortie démontre que le conteneur ne peut pas être planifié car les nœuds n'ont pas assez de mémoire:
Que se passe-t-il si vous ne spécifiez pas de limite de mémoire?
L'un des scénarios suivants se produit si vous ne définissez pas de limite de mémoire pour un conteneur:
- Le conteneur n'a aucune limite à la quantité de RAM qu'elle peut utiliser. Le tueur Oom pourrait être déclenché si le conteneur consomme toute la mémoire disponible sur le nœud où il a fonctionné. En outre, Acontainer sans contraintes de ressources aura un risque plus élevé d'être tué en cas de kill oom.
- Le conteneur est exécuté dans un espace de noms avec une limite de mémoire par défaut, et la limite par défaut est appliquée au conteneur automatiquement. Les administrateurs de cluster peuvent utiliser un limite pour définir un numéro par défaut pour la limite de mémoire.
Conclusion:
Nous avons examiné de plus près l'erreur de Kubernetes Oomkilled dans cet article. Il aide Kubernetes à gérer la mémoire tout en planifiant des pods et décider des gousses à détruire lorsque les ressources deviennent rares.