![\"Nove](\"\/wp-content\/uploads\/2020\/10\/92dc510aa9d785a31d310816b18bf854.png\")
<\/p>\n<\/p>\n
Ciao a tutti! Mi chiamo Oleg Sidorenko, lavoro per l'azienda DomClick come responsabile del team infrastrutturale. Da pi\u00f9 di tre anni utilizziamo 'Kubik' in produzione e in questo periodo abbiamo attraversato molti momenti interessanti con esso. Oggi vi racconter\u00f2 come, con un approccio corretto, si pu\u00f2 estrarre ancora pi\u00f9 prestazioni da un Kubernetes 'vanilla' per il vostro cluster. Pronti, partenza, via! <\/p>\n
Tutti voi sapete bene che Kubernetes \u00e8 un sistema scalabile open source per l'orchestrazione di container; o meglio, 5 binari che fanno magia gestendo il ciclo di vita dei vostri microservizi in un ambiente server. Inoltre, \u00e8 uno strumento piuttosto flessibile, che pu\u00f2 essere assemblato come un costruttore Lego, per una massima personalizzazione in base a diverse esigenze.<\/p>\n
E sembrerebbe tutto a posto: aggiungi i server al cluster, come legna da ardere in un caminetto, e non preoccuparti. Ma se ti preme l'ecologia, potresti pensare: \"Come posso mantenere il fuoco acceso nel camino e allo stesso tempo preservare la foresta?\". In altre parole, come trovare modi per migliorare l'infrastruttura e ridurre i costi.<\/p>\n
![\"Nove](\"\/wp-content\/uploads\/2020\/10\/91e2e60b47ee985b024532c8b685230c.png\")
<\/p>\n
Uno dei metodi pi\u00f9 banali ma efficaci \u00e8 l'introduzione di requests\/limits. Suddividi le applicazioni per namespaces, e i namespaces per team di sviluppo. Imposta i valori di consumo di tempo CPU, memoria e storage effimero per l'applicazione prima della distribuzione.<\/p>\n
resources:\n requests:\n memory: 2Gi\n cpu: 250m\n limits:\n memory: 4Gi\n cpu: 500m<\/code><\/pre>\nSperimentando, abbiamo concluso che non vale la pena gonfiare le richieste dai limiti di oltre due volte. Il volume del cluster \u00e8 calcolato in base alle richieste, e se imposti per le applicazioni differenze nelle risorse, ad esempio, da 5 a 10 volte, immagina cosa succeder\u00e0 al tuo nodo quando si riempir\u00e0 di pod e ricever\u00e0 improvvisamente un carico. Niente di buono. Al minimo, throttling; al massimo, ti dirai addio al worker e avrai un carico ciclico sugli altri nodi dopo che i pod inizieranno a migrare.<\/p>\n
Inoltre, utilizzando limitranges<\/code> puoi impostare fin da subito i valori delle risorse per il container \u2014 minimi, massimi e predefiniti:<\/p>\n\u279c ~ kubectl descrivi limitranges --namespace ops\nNome: limit-range\nNamespace: ops\nTipo Risorsa Min Max Richiesta Predefinita Limite Predefinito Rapporto Massimo Limite\/Richiesta\n---- -------- --- --- ------------------- ---------------- --------------------------\nContainer cpu 50m 10 100m 100m 2\nContainer ephemeral-storage 12Mi 8Gi 128Mi 4Gi -\nContainer memory 64Mi 40Gi 128Mi 128Mi 2<\/code><\/pre>\nNon dimenticate di limitare le risorse del namespace affinch\u00e9 un team non possa utilizzare tutte le risorse del cluster:<\/p>\n
\u279c ~ kubectl descrivi resourcequotas --namespace ops\nNome: resource-quota\nNamespace: ops\nRisorsa Utilizzato Massimo\n-------- ---- ----\nlimits.cpu 77250m 80\nlimits.memory 124814367488 150Gi\npods 31 45\nrequests.cpu 53850m 80\nrequests.memory 75613234944 150Gi\nservices 26 50\nservices.loadbalancers 0 0\nservices.nodeports 0 0<\/code><\/pre>\nCome si evince dalla descrizione resourcequotas<\/code>, se il team ops desidera distribuire pod che consumeranno altri 10 cpu, il pianificatore non consentir\u00e0 di farlo e restituir\u00e0 un errore:<\/p>\nErrore durante la creazione: i pod \"nginx-proxy-9967d8d78-nh4fs\" sono vietati: superato il limite: resource-quota, richiesto: limits.cpu=5, requests.cpu=5, utilizzato: limits.cpu=77250m, requests.cpu=53850m, limitato: limits.cpu=10, requests.cpu=10<\/code><\/pre>\nPer risolvere un problema simile si pu\u00f2 scrivere uno strumento, ad esempio, come