Containerizzare le applicazioni Java per Kubernetes
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.
Tenere presente che 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"
Passaggi successivi
- strategie di containerizzazione Java
- Jakarta EE nei runtime dei contenitori di Azure
- Oracle WebLogic Server
- IBM WebSphere Liberty, Open Liberty e WebSphere tradizionale