Java-alkalmazások tárolóba helyezése a Kuberneteshez
Ez a cikk bemutatja, hogyan tárolózhatja a Java-alkalmazásokat a Kubernetesen való üzembe helyezéshez.
A tárolómemória, a JVM-halommemória, a szemétgyűjtők (GCs- és vCPU-magok) ismertetését a Java-alkalmazások tárolóba helyezése című témakörben talál.
A Kubernetes-csomópontkészlet megfelelő virtuálisgép-termékváltozatának meghatározása
Határozza meg, hogy a Kubernetes-csomópontkészlet vagy a fürt számára elérhető készletek elférnek-e a használni kívánt tárolómemória és vCPU-magok számára. Ha a csomópontkészlet képes üzemeltetni az alkalmazást, folytassa a műveletet. Ellenkező esetben olyan csomópontkészletet építhet ki, amely megfelel a tárolómemória mennyiségének és a megcélzott vCPU-magok számának.
Ne feledje, hogy a virtuálisgép-termékváltozat költsége arányos a magok számával és a memória mennyiségével. Miután meghatározta a kiindulási pontot egy tárolópéldány virtuális processzorai és memóriája tekintetében, határozza meg, hogy csak horizontális skálázással tudja-e kielégíteni az alkalmazás igényeit. A megbízható, mindig elérhető rendszerekhez legalább két replikának kell rendelkezésre állnia. Igény szerint vertikális fel- és kiskálázás.
CPU-kérések és -korlátok beállítása
Ha korlátoznia kell a processzort, győződjön meg arról, hogy ugyanazt az értéket alkalmazza mind az üzembehelyezési fájlban, mind limits
requests
a központi telepítési fájlban. A JVM nem módosítja dinamikusan a futtatókörnyezetét, például a GC-t és más szálkészleteket. A JVM csak indítási idő alatt olvassa be a rendelkezésre álló processzorok számát.
Tipp.
Állítsa be ugyanazt az értéket a CPU-kérésekhez és a CPU-korlátokhoz.
containers:
- image: myimage
name: myapp
resources:
limits:
cpu: "2"
requests:
cpu: "2"
Az elérhető JVM-processzorok ismertetése
Amikor az OpenJDK-ban a HotSpot JVM azonosítja, hogy egy tárolón belül fut, olyan értékeket használ, mint cpu_quota
például a cpu_period
rendelkezésre álló processzorok számának meghatározása. Általánosságban elmondható, hogy 1000m
a legfeljebb millicore értékű értékek egyetlen processzorgépként vannak azonosítva. Minden érték 1001m
2000m
kettős processzoros gépként van azonosítva, és így tovább. Ez az információ az API Runtime.getRuntime().availableProcessors()-on keresztül érhető el. Ezt az értéket az egyidejűleg használt számítógépek némelyike is használhatja a szálak konfigurálásához. Más API-k, kódtárak és keretrendszerek is felhasználhatják ezeket az információkat a szálkészletek konfigurálásához.
A Kubernetes CPU-kvótái a folyamat processzorban töltött idejéhez kapcsolódnak, és nem a folyamat számára elérhető CPU-k számához. A többszálas futtatókörnyezetek, például a JVM, egyszerre több processzort is használhatnak, több szállal. Még akkor is, ha egy tároló legfeljebb egy vCPU-ra van korlátozva, a JVM-nek két vagy több elérhető processzort kell látnia.
Ha tájékoztatni szeretné a JVM-et arról, hogy pontosan hány processzort kell látnia Egy Kubernetes-környezetben, használja a következő JVM-jelzőt:
-XX:ActiveProcessorCount=N
Memóriakérelmek és -korlátok beállítása
Állítsa be a memóriakorlátokat a korábban meghatározott mennyiségre. Győződjön meg arról, hogy a memóriakorlátok száma a tárolómemória, és NEM a JVM halommemória értéke.
Tipp.
Állítsa be a memóriakorlátokkal egyenlő memóriakérelmeket.
containers:
- name: myimage
image: myapp
resources:
limits:
memory: "4Gi"
requests:
memory: "4Gi"
A JVM-argumentumok beállítása az üzembehelyezési fájlban
Ne felejtse el beállítani a JVM halommemóriát a korábban meghatározott mennyiségre. Azt javasoljuk, hogy adja át ezt az értéket környezeti változóként, így egyszerűen módosíthatja anélkül, hogy újra kellene építenie a tárolólemezképet.
containers:
- name: myimage
image: myapp
env:
- name: JAVA_OPTS
value: "-XX:+UseParallelGC -XX:MaxRAMPercentage=75"
További lépések
- Java-tárolókradiációs stratégiák
- Jakarta Enterprise kiadás Azure-tároló futtatókörnyezetekben
- Oracle WebLogic-kiszolgáló
- IBM WebSphere Liberty, Open Liberty és hagyományos WebSphere
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: