Utilizzo della CPU Kubernetes in conflitto e metriche del contenitore Docker

Di recente abbiamo passato il nostro ambiente di produzione a Kubernetes. Vorrei applicare i limiti della CPU sui contenitori. Sto ricevendo metriche CPU contrastanti che non si adattano insieme. Ecco la mia configurazione:

• Agenti DataDog in esecuzione come a Daemonset
• Applicazioni esistenti in esecuzione senza limiti CPU
• I contenitori in questione sono applicazioni Ruby multi-thread
• Due parametri: kubernetes.cpu.usage.{avg,max}edocker.cpu.usage
• c4.xlarge nodi cluster (4 vCPU o 4000m in termini di Kubernetes)

kubernetes.cpu.usage.maxriporta ~ 600 m per i contenitori in questione. docker.cpu.usageriporta ~ 60%. Ne consegue che un limite della CPU di 1000 m sarebbe una capacità più che sufficiente durante il normale funzionamento.

Ho impostato il limite a 1000m. Quindi docker.container.throttlesaumenta in modo significativo kubernetes.cpu.usage.maxe docker.cpu.usageresta invariato. Durante questo periodo, il sistema è caduto in ginocchio. Questo non ha senso per me.

Ho studiato le statistiche di Docker. Sembra che docker stats(e l'API sottostante) normalizzino il carico in base ai core della CPU. Quindi, nel mio caso, docker.cpu.usagedel 60% arriva (4000m * 0,60) a 2400m in termini di Kubernetes. Tuttavia, ciò non è correlato ai numeri di Kubernetes. Ho fatto un altro esperimento per verificare la mia ipotesi che i numeri di Kubernetes siano errati. Ho impostato il limite a 2600 m (per un po 'di spazio in più). Ciò non ha comportato alcun throttles. Tuttavia Kubernetes ha osservato che l'utilizzo della CPU non è cambiato. Questo mi lascia confuso.

Quindi le mie domande sono:

• Ti sembra un bug in Kubernetes (o qualcosa nello stack?)
• La mia comprensione è corretta?

La mia domanda di follow-up riguarda come determinare correttamente la CPU per le applicazioni Ruby. Un contenitore utilizza Puma. Questo è un server web multi-thread con una quantità configurabile di thread. Le richieste HTTP sono gestite da uno dei thread. La seconda applicazione è un server dell'usato che utilizza il server thread. Ogni connessione TCP in entrata è gestita dal proprio thread. Il thread termina alla chiusura della connessione. Ruby come GIL (Global Interpreter Lock), quindi solo un thread può eseguire il codice Ruby alla volta. Ciò consente a più thread di eseguire IO e cose del genere.

Penso che l'approccio migliore sia limitare il numero di thread in esecuzione in ciascuna applicazione e approssimare i limiti della CPU Kubernetes in base al numero di thread. I processi non stanno biforcando, quindi è più difficile prevedere l'utilizzo totale della CPU.

La domanda qui è: come prevedere correttamente l'utilizzo della CPU e i limiti per queste applicazioni?

Più cose qui:

1. Sei su AWS ec2, quindi qualsiasi cosa tu stia facendo sulla tua istanza per misurare la CPU, sta calcolando la CPU a livello di hypervisor e non a livello di istanza. Per fare questo, esegui qualsiasi test di carico e controlla iostat -ct 1 e l'utilizzo della CPU in cloudwatch. L'utilizzo della CPU in cloudwatch è sempre maggiore del 10-20% rispetto a quanto riportato da iostat e questo perché iostat fornirà l'utilizzo della CPU a livello di hypervisor.

2. Come docker per vedere come si confrontano le metriche di kubernet e docker, suggerisco di eseguire i contenitori con --cpuset = 1 o qualsiasi numero per consentire a tutti i contenitori di utilizzare solo un singolo vCPU.

3. Anche in AWS 1 CPU = 2vcpu. È hyperthreaded a 2. Puoi forse tenerne conto durante il calcolo.

4. Infine, la metrica migliore da utilizzare per visualizzare l'utilizzo della CPU per una particolare applicazione è l'utilizzo di htop e la correlazione con le metriche di cloudwatch.

5. Ho anche osservato a volte il demone docker agganciarsi a una delle CPU virtuali e quindi quando lo stai riducendo a 1000m, forse l'intero setup sta rallentando perché la riduzione sta avvenendo su uno dei vpcus. Puoi usare mpstat per entrare nei dettagli di questo.

6. Infine a livello di host è possibile bloccare la finestra mobile su una singola CPU e osservare di più.

Spero che questo ti avvicini un po 'di più. Aggiornami se hai già trovato una soluzione.