Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Éviter les erreurs OOM
Windows ne dispose pas d'un outil de destruction des processus par manque de mémoire, contrairement à Linux. Windows traite toujours toutes les allocations de mémoire en mode utilisateur comme virtuelles et les fichiers de page sont obligatoires. L'effet net est que Windows n'atteindra pas les limites de mémoire de la même manière que Linux. Les processus afficheront une page sur le disque au lieu d'être soumis à une interruption de mémoire insuffisante (OOM). Si la mémoire est surprovisionnée et que toute la mémoire physique est épuisée, la pagination peut ralentir les performances.
Système de réservation et mémoire Kubelet
Différent de Linux, où vous --kubelet-reserve pouvez capturer la réservation de ressources pour les démons système Kubernetes tels que Kubelet, Container Runtime, etc. et --system-reserve capturer la réservation de ressources pour les démons du système d'exploitation tels que sshd, udev, etc. Sous Windows, ces indicateurs ne capturent pas et ne définissent pas de limites de mémoire sur Kubelet ou les processus exécutés sur le nœud.
Cependant, vous pouvez combiner ces indicateurs NodeAllocatable pour réduire la capacité du nœud avec la limite de ressources mémoire du manifeste du pod afin de contrôler l'allocation de mémoire par pod. Grâce à cette stratégie, vous pouvez mieux contrôler l'allocation de mémoire et disposer d'un mécanisme pour minimiser l'épuisement de la mémoire (OOM) sur les nœuds Windows.
Sur les nœuds Windows, il est recommandé de réserver au moins 2 Go de mémoire pour le système d'exploitation et le processus. Utiliser --kubelet-reserve and/or --system-reserve pour réduire NodeAllocatable.
Conformément à la documentation des nœuds Self-managed Windows Amazon EKS, utilisez le CloudFormation modèle pour lancer un nouveau groupe de nœuds Windows avec des personnalisations de la configuration de kubelet. CloudFormation Il possède un élément appelé BootstrapArguments qui est le même queKubeletExtraArgs. À utiliser avec les indicateurs et valeurs suivants :
--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"
Si eksctl est l'outil de déploiement, consultez la documentation suivante pour personnaliser la configuration de kubelet https://eksctl.io/usage/customizing-the-kubelet/
Exigences relatives à la mémoire des conteneurs Windows
Selon la documentation Microsoft
Il est essentiel que vous connaissiez la quantité minimale de mémoire requise par votre image de conteneur Windows, c'est-à-dire l'image de base et ses couches d'application, et que vous la définissiez comme conteneur resources/requests dans la spécification du pod. Vous devez également définir une limite pour éviter que les pods ne consomment toute la mémoire de nœud disponible en cas de problème d'application.
Dans l'exemple ci-dessous, lorsque le planificateur Kubernetes essaie de placer un pod sur un nœud, les requêtes du pod sont utilisées pour déterminer quel nœud dispose de suffisamment de ressources disponibles pour la planification.
spec: - name: iis image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 resources: limits: cpu: 1 memory: 800Mi requests: cpu: .1 memory: 128Mi
Conclusion
L'utilisation de cette approche permet de minimiser les risques d'épuisement de la mémoire mais n'empêche pas que cela se produise. À l'aide d'Amazon CloudWatch Metrics, vous pouvez configurer des alertes et des mesures correctives en cas d'épuisement de la mémoire.