Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive come inserire in contenitori le applicazioni Java per la distribuzione in Kubernetes. Per indicazioni sulla memoria del contenitore, la memoria heap JVM, i Garbage Collector e i core vCPU, vedere Containerize your Java applications.
Determinare lo SKU di macchina virtuale appropriato per il pool di nodi Kubernetes
Determinare se il pool di nodi o i pool di nodi Kubernetes disponibili per il cluster possono adattarsi alla memoria del contenitore e ai core vCPU che si intende usare. Se il pool di nodi può ospitare l'applicazione, continuare. In caso contrario, configurare un pool di nodi appropriato per la quantità di memoria del contenitore e il numero di core vCPU di destinazione.
Il costo di uno SKU di macchina virtuale è proporzionale al numero di core e alla quantità di memoria. Dopo aver determinato il punto di partenza in termini di vCPU e memoria per un'istanza del contenitore, determinare se è possibile soddisfare le esigenze dell'applicazione solo ridimensionando orizzontalmente. Per sistemi affidabili, sempre attivi, devono essere disponibili almeno due repliche. Aumentare verticalmente e orizzontalmente in base alle esigenze.
Impostare richieste e limiti della CPU
Se è necessario limitare la CPU, assicurarsi di applicare lo stesso valore sia per limits che per requests nel file di distribuzione. La JVM non regola in modo dinamico il runtime, ad esempio GC e altri pool di thread. La JVM legge il numero di processori disponibili solo durante l'avvio.
Suggerimento
Impostare lo stesso valore per le richieste cpu e i limiti della CPU.
containers:
- image: myimage
name: myapp
resources:
limits:
cpu: "2"
requests:
cpu: "2"
Comprendere i processori disponibili della JVM
Quando la JVM HotSpot in OpenJDK identifica che è in esecuzione all'interno di un contenitore, usa valori come cpu_quota e cpu_period per determinare il numero di processori disponibili. In generale, qualsiasi valore fino a 1000m millicores viene identificato come un computer con un solo processore. Qualsiasi valore tra 1001m e 2000m viene identificato come un computer a doppio processore e così via. Queste informazioni sono disponibili tramite l'API Runtime.getRuntime().availableProcessors(). Alcuni controller di dominio simultanei potrebbero anche usare questo valore per configurare i thread. Altre API, librerie e framework possono usare queste informazioni anche per configurare i pool di thread.
Le quote della CPU Kubernetes sono correlate alla quantità di tempo usata da un processo nella CPU e non al numero di CPU disponibili per il processo. I runtime multithread, ad esempio la JVM, potrebbero comunque usare più processori contemporaneamente, con più thread. Anche se un contenitore ha un limite di una vCPU, la JVM potrebbe essere incaricata di visualizzare due o più processori disponibili.
Per informare la JVM del numero esatto di processori visualizzati in un ambiente Kubernetes, usare il flag JVM seguente:
-XX:ActiveProcessorCount=N
Impostare i limiti e le richieste di memoria
Impostare i limiti di memoria sulla quantità determinata in precedenza. Assicurarsi che il numero di limiti di memoria sia la memoria del contenitore e NON il valore di memoria heap JVM.
Suggerimento
Impostare le richieste di memoria uguali ai limiti di memoria.
containers:
- name: myimage
image: myapp
resources:
limits:
memory: "4Gi"
requests:
memory: "4Gi"
Impostare gli argomenti JVM nel file di distribuzione
Ricordarsi di impostare la memoria dell'heap JVM sulla quantità determinata in precedenza. È consigliabile passare questo valore come variabile di ambiente in modo da poterlo modificare facilmente senza dover ricompilare l'immagine del contenitore.
containers:
- name: myimage
image: myapp
env:
- name: JAVA_OPTS
value: "-XX:+UseParallelGC -XX:MaxRAMPercentage=75"
Semplificare l'ottimizzazione di JVM con l'utilità di avvio dei comandi Azure per Java
Le sezioni precedenti impostano manualmente il numero di processori, le dimensioni dell'heap e il GC tramite i flag JVM. Se non si vogliono gestire queste impostazioni, l'utilità di avvio comandi di Azure per Java (jaz) può applicare automaticamente le impostazioni predefinite native del cloud. Legge all'avvio i limiti di memoria e CPU del cgroup del contenitore e seleziona automaticamente il dimensionamento ottimale dell'heap e i flag del GC.
Per usare lo strumento, sostituire il java comando con jaz nel comando di avvio del contenitore. Lo strumento è incluso nelle immagini del contenitore per il Microsoft Build di OpenJDK, quindi non è necessaria alcuna configurazione aggiuntiva:
# Use any Microsoft Build of OpenJDK base image
FROM mcr.microsoft.com/openjdk/jdk:25-ubuntu
# Add your application.jar
COPY application.jar /application.jar
# Use jaz to launch your Java application
CMD ["jaz", "-jar", "application.jar"]
Per le opzioni di installazione, gli ambienti supportati e i dettagli di configurazione, vedere Azure Command Launcher per Java.
Passaggi successivi
- strategie di containerizzazione Java
- Utilità di avvio comandi Azure per Java
- Jakarta EE nei runtime dei contenitori di Azure
- Oracle WebLogic Server
- IBM WebSphere Liberty, Open Liberty e WebSphere tradizionale