Condividi tramite


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