Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Evitare gli errori OOM

Windows non dispone di un process killer che elimina i problemi di memoria esaurita come Linux. Windows considera sempre tutte le allocazioni di memoria in modalità utente come virtuali e i file di pagina sono obbligatori. L'effetto finale è che Windows non raggiungerà le condizioni di memoria esaurite allo stesso modo di Linux. I processi passeranno da una pagina all'altra su disco anziché essere soggetti alla chiusura della memoria (OOM). Se la memoria è sovradimensionata e tutta la memoria fisica è esaurita, il paging può rallentare le prestazioni.

Sistema di prenotazione e memoria Kubelet

A differenza di Linux, dove --kubelet-reserve acquisisce la prenotazione delle risorse per i demoni di sistema Kubernetes come kubelet, container runtime, ecc.; e --system-reserve acquisisce la prenotazione delle risorse per i demoni di sistema operativo come sshd, udev e così via. In Windows questi flag non acquisiscono e non impostano limiti di memoria su kubelet o sui processi in esecuzione sul nodo.

Tuttavia, puoi combinare questi flag per ridurre la capacità sul nodo con il limite delle risorse di memoria Pod manifest per controllare l'allocazione della memoria per pod. NodeAllocatable Questa strategia consente di controllare meglio l'allocazione della memoria e di disporre di un meccanismo per ridurre al minimo l'esaurimento della memoria (OOM) sui nodi Windows.

Nei nodi Windows, è consigliabile riservare almeno 2 GB di memoria per il sistema operativo e il processo. Utilizzare --kubelet-reserve and/or --system-reserve per ridurre NodeAllocatable.

Seguendo la documentazione dei nodi Self-managed Windows di Amazon EKS, utilizza il CloudFormation modello per avviare un nuovo gruppo di nodi Windows con personalizzazioni della configurazione kubelet. CloudFormation Ha un elemento chiamato BootstrapArguments che è lo stesso di. KubeletExtraArgs Da utilizzare con i seguenti flag e valori:

--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"

Se eksctl è lo strumento di distribuzione, consulta la seguente documentazione per personalizzare la configurazione di kubelet https://eksctl.io/usage/customizing-the-kubelet/

Requisiti di memoria per contenitori Windows

Secondo la documentazione Microsoft, un'immagine di base di Windows Server per NANO richiede almeno 30 MB, mentre Server Core richiede 45 MB. Questi numeri aumentano man mano che si aggiungono componenti di Windows come .NET Framework, Web Services come IIS e applicazioni.

È essenziale conoscere la quantità minima di memoria richiesta dall'immagine del contenitore Windows, ovvero l'immagine di base più i relativi livelli di applicazione, e impostarla come quella del contenitore resources/requests nelle specifiche del pod. È inoltre necessario impostare un limite per evitare che i pod consumino tutta la memoria disponibile del nodo in caso di problemi con l'applicazione.

Nell'esempio seguente, quando lo scheduler Kubernetes tenta di posizionare un pod su un nodo, le richieste del pod vengono utilizzate per determinare quale nodo dispone di risorse sufficienti per la pianificazione.

 spec:
  - name: iis
    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
    resources:
      limits:
        cpu: 1
        memory: 800Mi
      requests:
        cpu: .1
        memory: 128Mi

Conclusioni

L'utilizzo di questo approccio riduce al minimo i rischi di esaurimento della memoria ma non impedisce che ciò accada. Utilizzando Amazon CloudWatch Metrics, puoi impostare avvisi e correzioni in caso di esaurimento della memoria.