Condividi tramite

Containerizzare le applicazioni Java per Kubernetes

  • Articolo

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 (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, effettuare il provisioning di 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 i sistemi always-on affidabili, è necessario che siano disponibili almeno due repliche. Aumentare e aumentare le prestazioni in base alle esigenze.

Impostare richieste e limiti della CPU

Se è necessario limitare la CPU, assicurarsi di applicare lo stesso valore sia per che limitsrequests 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"

Informazioni sui processori disponibili per 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 una singola macchina a 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(). Questo valore può essere usato anche da alcuni controller di dominio simultanei 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, possono comunque usare più processori contemporaneamente, con più thread. Anche se un contenitore ha un limite di una vCPU, la JVM può 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