Containerisieren Ihrer Java-Anwendungen für Kubernetes
In diesem Artikel wird beschrieben, wie Sie Ihre Java-Anwendungen für die Bereitstellung auf Kubernetes containern.
Anleitungen zu Containerspeicher, JVM-Heap-Speicher, Garbage Collector (GCs) und vCPU-Kernen finden Sie unter Containerisieren Ihrer Java-Anwendungen.
Ermitteln der entsprechenden VM-SKU für den Kubernetes-Knotenpool
Ermitteln Sie, ob der Kubernetes-Knotenpool oder -Pools, die für Ihren Cluster verfügbar sind, in den Containerspeicher und die vCPU-Kerne passen, die Sie verwenden möchten. Wenn der Knotenpool die Anwendung hosten kann, fahren Sie mit dem Vorgang fort. Stellen Sie andernfalls einen Knotenpool bereit, der für die Menge des Containerspeichers und die Anzahl der vCPU-Kerne geeignet ist, die Sie verwenden.
Denken Sie daran, dass die Kosten einer VM-SKU proportional zur Anzahl der Kerne und der Menge des Arbeitsspeichers sind. Nachdem Sie den Ausgangspunkt in Bezug auf vCPUs und Speicher für eine Containerinstanz ermittelt haben, bestimmen Sie, ob Sie die Anforderungen Ihrer Anwendung nur durch horizontale Skalierung erfüllen können. Für zuverlässige, always-on-Systeme müssen mindestens zwei Replikate verfügbar sein. Skalieren Sie nach Bedarf nach oben und unten.
Festlegen von CPU-Anforderungen und -Grenzwerten
Wenn Sie die CPU einschränken müssen, stellen Sie sicher, dass Sie denselben Wert sowohl für die Bereitstellungsdatei als auch limits
requests
für die Bereitstellungsdatei anwenden. Das JVM passt seine Laufzeit nicht dynamisch an, z. B. die GC- und andere Threadpools. Die JVM liest die Anzahl der Prozessoren, die nur während der Startzeit verfügbar sind.
Tipp
Legen Sie denselben Wert für CPU-Anforderungen und CPU-Grenzwerte fest.
containers:
- image: myimage
name: myapp
resources:
limits:
cpu: "2"
requests:
cpu: "2"
Grundlegendes zu verfügbaren JVM-Prozessoren
Wenn der HotSpot-JVM in OpenJDK identifiziert, dass er in einem Container ausgeführt wird, verwendet es Werte, z cpu_quota
. B. und cpu_period
um zu bestimmen, wie viele Prozessoren verfügbar sind. Im Allgemeinen werden alle Werte bis zu 1000m
Millcores als einzelne Prozessormaschine identifiziert. Jeder Wert zwischen 1001m
und 2000m
wird als dualer Prozessorcomputer und so weiter identifiziert. Diese Informationen sind über die API Runtime.getRuntime().availableProcessors()verfügbar. Dieser Wert kann auch von einigen der gleichzeitigen GCs verwendet werden, um ihre Threads zu konfigurieren. Andere APIs, Bibliotheken und Frameworks können diese Informationen auch zum Konfigurieren von Threadpools verwenden.
Kubernetes CPU-Kontingente beziehen sich auf die Zeit, die ein Prozess in der CPU aufwendet, und nicht die Anzahl der cpUs, die für den Prozess verfügbar sind. Multithreadlaufzeiten wie der JVM können weiterhin mehrere Prozessoren gleichzeitig mit mehreren Threads verwenden. Selbst wenn ein Container einen Grenzwert für eine vCPU hat, kann der JVM angewiesen werden, zwei oder mehr verfügbare Prozessoren anzuzeigen.
Um den JVM über die genaue Anzahl der Prozessoren zu informieren, die es in einer Kubernetes-Umgebung sehen sollte, verwenden Sie das folgende JVM-Flag:
-XX:ActiveProcessorCount=N
Festlegen von Speicheranforderungen und -grenzwerten
Legen Sie die Speichergrenzwerte auf die Menge fest, die Sie zuvor festgelegt haben. Stellen Sie sicher, dass die Anzahl der Speicherbeschränkungen der Containerspeicher und NICHT der JVM-Heap-Speicherwert ist.
Tipp
Legen Sie die Speicheranforderungen auf die Speicherbeschränkungen fest.
containers:
- name: myimage
image: myapp
resources:
limits:
memory: "4Gi"
requests:
memory: "4Gi"
Festlegen der JVM-Argumente in der Bereitstellungsdatei
Denken Sie daran, den JVM-Heapspeicher auf den Betrag festzulegen, den Sie zuvor ermittelt haben. Es wird empfohlen, diesen Wert als Umgebungsvariable zu übergeben, damit Sie ihn ganz einfach ändern können, ohne das Containerimage neu erstellen zu müssen.
containers:
- name: myimage
image: myapp
env:
- name: JAVA_OPTS
value: "-XX:+UseParallelGC -XX:MaxRAMPercentage=75"
Nächste Schritte
- Strategien für die Java-Containerisierung
- Jakarta EE für Azure-Containerlaufzeiten
- Oracle WebLogic Server
- IBM WebSphere Liberty, Open Liberty und traditionelle WebSphere