Conteneuriser vos applications Java pour Kubernetes
Cet article explique comment conteneuriser vos applications Java pour le déploiement sur Kubernetes.
Pour obtenir des conseils sur la mémoire du conteneur, la mémoire du tas JVM, les garbage collectors (GCS) et les cœurs de processeur virtuel, consultez Containerize vos applications Java.
Déterminer la référence SKU de machine virtuelle appropriée pour le pool de nœuds Kubernetes
Déterminez si le pool de nœuds Kubernetes ou les pools disponibles pour votre cluster peuvent correspondre aux cœurs de mémoire du conteneur et de processeurs virtuels que vous envisagez d’utiliser. Si le pool de nœuds peut héberger l’application, continuez. Sinon, provisionnez un pool de nœuds approprié pour la quantité de mémoire du conteneur et le nombre de cœurs de processeurs virtuels que vous ciblez.
N’oubliez pas que le coût d’une référence SKU de machine virtuelle est proportionnel au nombre de cœurs et à la quantité de mémoire. Après avoir déterminé votre point de départ en termes de processeurs virtuels et de mémoire pour une instance de conteneur, déterminez si vous pouvez répondre aux besoins de votre application en mettant à l’échelle horizontale uniquement. Pour les systèmes fiables et toujours activés, un minimum de deux réplicas doit être disponible. Effectuez un scale-up et un scale-out en fonction des besoins.
Définir les demandes et limites du processeur
Si vous devez limiter le processeur, vérifiez que vous appliquez la même valeur pour les deux limits
et requests
dans le fichier de déploiement. La machine virtuelle JVM n’ajuste pas dynamiquement son runtime, comme le GC et d’autres pools de threads. La machine virtuelle JVM lit le nombre de processeurs disponibles uniquement pendant le temps de démarrage.
Conseil
Définissez la même valeur pour les demandes d’UC et les limites du processeur.
containers:
- image: myimage
name: myapp
resources:
limits:
cpu: "2"
requests:
cpu: "2"
Comprendre les processeurs JVM disponibles
Lorsque la JVM HotSpot dans OpenJDK identifie qu’elle s’exécute à l’intérieur d’un conteneur, elle utilise des valeurs telles que cpu_quota
et cpu_period
pour déterminer le nombre de processeurs disponibles. En règle générale, toutes les valeurs jusqu’à 1000m
millicores sont identifiées comme une seule machine de processeur. Toute valeur entre 1001m
et 2000m
est identifiée comme une machine double processeur, et ainsi de suite. Ces informations sont disponibles via l’API Runtime.getRuntime().availableProcessors(). Cette valeur peut également être utilisée par certains des contrôleurs de groupe simultanés pour configurer leurs threads. D’autres API, bibliothèques et frameworks peuvent également utiliser ces informations pour configurer des pools de threads.
Les quotas d’UC Kubernetes sont liés au temps passé par un processus dans l’UC, et non au nombre de processeurs disponibles pour le processus. Les runtimes multithreads tels que la machine virtuelle JVM peuvent toujours utiliser plusieurs processeurs simultanément, avec plusieurs threads. Même si un conteneur a une limite d’un processeur virtuel, la machine virtuelle JVM peut être chargée de voir deux processeurs disponibles ou plus.
Pour informer la machine virtuelle JVM du nombre exact de processeurs qu’elle doit voir dans un environnement Kubernetes, utilisez l’indicateur JVM suivant :
-XX:ActiveProcessorCount=N
Définir la demande de mémoire et les limites
Définissez les limites de mémoire sur la quantité que vous avez déterminée précédemment. Vérifiez que le nombre de limites de mémoire est la mémoire du conteneur et non la valeur de mémoire du tas JVM.
Conseil
Définissez les demandes de mémoire égales aux limites de mémoire.
containers:
- name: myimage
image: myapp
resources:
limits:
memory: "4Gi"
requests:
memory: "4Gi"
Définir les arguments JVM dans le fichier de déploiement
N’oubliez pas de définir la mémoire du tas JVM sur la quantité que vous avez déterminée précédemment. Nous vous recommandons de passer cette valeur en tant que variable d’environnement afin de pouvoir le modifier facilement sans avoir à reconstruire l’image conteneur.
containers:
- name: myimage
image: myapp
env:
- name: JAVA_OPTS
value: "-XX:+UseParallelGC -XX:MaxRAMPercentage=75"
Étapes suivantes
- Stratégies de conteneurisation Java
- Jakarta EE sur les runtimes de conteneurs Azure
- Oracle WebLogic Server
- IBM WebSphere Liberty, Open Liberty et WebSphere traditionnel