{"id":97982,"date":"2020-10-23T14:42:15","date_gmt":"2020-10-23T12:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes"},"modified":"2020-11-18T00:58:47","modified_gmt":"2020-11-17T22:58:47","slug":"devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","title":{"rendered":"Nove consigli per migliorare le prestazioni di Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nove<\/p>\n

Ciao a tutti! Mi chiamo Oleg Sidorenkov e sono il responsabile del team infrastruttura presso DomKlik. Gestiamo \"Cubik\" in produzione da oltre tre anni e in questo periodo abbiamo vissuto molte esperienze interessanti. Oggi vi racconter\u00f2 come, con il giusto approccio, sia possibile ottenere ancora pi\u00f9 prestazioni dal vostro cluster utilizzando Kubernetes \"vanilla\". Pronti, partenza, via! <\/p>\n

Sapete tutti che Kubernetes \u00e8 un sistema scalabile open source per l'orchestrazione dei contenitori; oppure sono 5 binari che compiono magia gestendo il ciclo di vita dei vostri microservizi nell'ambiente server. Inoltre, \u00e8 uno strumento abbastanza flessibile, che pu\u00f2 essere assemblato come un costruttore Lego per una massima personalizzazione in base a diverse esigenze.<\/p>\n

E sembra tutto bene: inserisci i server nel cluster come legna da ardere nel camino e non ti preoccupi. Ma se sei attento all'ambiente, ti chiederai: \"Come posso mantenere il fuoco nel camino e risparmiare la foresta?\". In altre parole, come trovare modi per migliorare l'infrastruttura e ridurre i costi.<\/p>\n

1. Monitora le risorse dei team e delle applicazioni<\/h2>\n

\"Nove<\/p>\n

Uno dei metodi pi\u00f9 semplici ed efficaci \u00e8 l'introduzione di requests\/limits. Suddividete le applicazioni in namespace e i namespace in team di sviluppo. Assegnate ai vostri applicativi valori per il consumo di tempo di CPU, memoria e storage effimero prima del deploy.<\/p>\n

resources:\n   requests:\n     memory: 2Gi\n     cpu: 250m\n   limits:\n     memory: 4Gi\n     cpu: 500m<\/code><\/pre>\n
Dalla nostra esperienza, abbiamo concluso che non \u00e8 consigliabile gonfiare i requests oltre il doppio dei limits. La dimensione del cluster si basa sui requests, e se designate differenze nelle risorse delle applicazioni, ad esempio di 5-10 volte, immaginate cosa accadr\u00e0 al vostro nodo quando si riempir\u00e0 di pod e ricever\u00e0 improvvisamente un carico. Niente di buono. Al minimo, throttling; al massimo, dovrete dire addio al worker e affrontare un carico ciclico sugli altri nodi dopo che i pod inizieranno a migrare.<\/p>\n
Inoltre, grazie a limitranges<\/code> potete impostare per il container valori delle risorse \u2014 minimi, massimi e predefiniti:<\/p>\n
\u279c  ~ kubectl describe limitranges --namespace ops\nNome:       limit-range\nNamespace:  ops\nTipo        Risorsa            Min   Max   Richiesta predefinita  Limite predefinito  Massimo rapporto 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>\n
Non dimenticate di limitare le risorse del namespace affinch\u00e9 un singolo team non possa utilizzare tutte le risorse del cluster:<\/p>\n
\u279c  ~ kubectl describe 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>\n
Come si pu\u00f2 vedere dalla descrizione resourcequotas<\/code>, se il team ops desidera distribuire pod che consumeranno altri 10 cpu, il pianificatore non permetter\u00e0 di farlo e restituir\u00e0 un errore:<\/p>\n
Errore nella creazione: pods \"nginx-proxy-9967d8d78-nh4fs\" \u00e8 vietato: 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>\n
Per risolvere un problema simile, si pu\u00f2 scrivere uno strumento, ad esempio, come questo<\/a><\/noindex>, in grado di memorizzare e confermare lo stato delle risorse dei team.<\/p>\n
2. Seleziona lo storage file pi\u00f9 adatto<\/h2>\n
\"Nove<\/p>\n
Vorrei affrontare il tema dei volumi persistenti e del sistema di archiviazione delle nodi worker di Kubernetes. Spero che nessuno usi \"Kube\" su HDD in produzione, ma a volte anche un comune SSD non \u00e8 pi\u00f9 sufficiente. Ci siamo trovati di fronte al problema per cui i log sovraccaricavano il disco in termini di operazioni di input\/output, e qui le opzioni di soluzione sono piuttosto limitate: <\/p>\n