{"id":94262,"date":"2020-09-14T19:42:34","date_gmt":"2020-09-14T17:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod"},"modified":"2020-09-14T19:42:34","modified_gmt":"2020-09-14T17:42:34","slug":"kak-poluchit-dostup-k-resursam-kubernetes-pod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","title":{"rendered":"Come ottenere accesso alle risorse del Pod Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Come ottenere accesso alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/3d6760d512ef456daad121f7d1ddbcf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/tohad\/art\/The-Reward-549720998\"><i>The Reward by Tohad<\/i><\/a><\/noindex><\/p>\n<p>All'inizio del lavoro con Kubernetes si tende spesso a dimenticare di configurare le risorse dei container. In questa fase \u00e8 sufficiente assicurarsi che l'immagine Docker funzioni e che possa essere distribuita nel cluster Kubernetes.<\/p>\n<p>Ma in seguito l'applicazione deve essere distribuita nel cluster di produzione insieme ad altre applicazioni. Per fare ci\u00f2 \u00e8 necessario allocare risorse per il container e assicurarsi che siano sufficienti per l'avvio e il funzionamento dell'applicazione, senza causare problemi ad altre applicazioni in esecuzione.<\/p>\n<p>Team <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Kubernetes aaS di Mail.ru<\/a><\/noindex> ha tradotto un articolo sulle risorse dei container (CPU &amp; MEM), richieste e limitazioni delle risorse. Scoprirete quali vantaggi offrono queste configurazioni e cosa succede se non vengono impostate.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Risorse di calcolo<\/h2>\n<p>\nAbbiamo due tipi di risorse con le seguenti unit\u00e0:<\/p>\n<ul>\n<li>Processore centrale (CPU) \u2014 core;<\/li>\n<li>Memoria (MEM) \u2014 byte.<\/li>\n<\/ul>\n<p>\nLe risorse vengono specificate per ogni container. Nel seguente file YAML del Pod vedrete una sezione risorse, che contiene le risorse richieste e quelle massime:<\/p>\n<ul>\n<li>Risorse richieste del Pod = somma delle risorse richieste di tutti i container;<\/li>\n<li>Risorse massime del Pod = somma delle risorse massime di tutti i container.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\nkind: Pod\nmetadata:\n  name: backend-pod-name\n  labels:\n    application: backend\nspec:\n  containers:\n    \u2014 name: main-container\n      image: my-backend\n      tag: v1\n      ports:\n      \u2014 containerPort: 8080\n      resources:\n        requests:\n          cpu: 0.2 # CPU RICHIESTO: 200m core\n          memory: \"1Gi\" # MEM RICHIESTO: 1Gi\n        limits:\n          cpu: 1 # UTILIZZO MAX CPU: 1 core\n          memory: \"1Gi\" # UTILIZZO MAX MEM:  1Gi\n    \u2014 name: other-container\n      image: other-app\n      tag: v1\n      ports:\n      \u2014 containerPort: 8000\n      resources:\n        requests:\n          cpu: \"200m\" # CPU RICHIESTO: 200m core\n          memory: \"0.5Gi\" # MEM RICHIESTO: 0.5Gi\n        limits:\n          cpu: 1 # UTILIZZO MAX CPU: 1 core\n          memory: \"1Gi\" # UTILIZZO MAX MEM:  1Gi<\/code><\/pre>\n<p>Esempio di risorse richieste e massime<\/p>\n<p>Campo <code>resources.requested<\/code> dalla specifica del Pod \u2014 uno degli elementi utilizzati per cercare il nodo corretto. Gi\u00e0 su di esso si pu\u00f2 pianificare la distribuzione del Pod. Come viene cercato il nodo adatto?<\/p>\n<p>Kubernetes \u00e8 composto da diversi componenti, tra cui il nodo principale o nodo master (Kubernetes Control Plane). Nel nodo master ci sono diversi processi: kube-apiserver, kube-controller-manager e kube-scheduler. <\/p>\n<p>Il processo kube-scheduler \u00e8 responsabile della revisione dei nuovi pod creati e della ricerca dei nodi di lavoro idonei che soddisfano tutte le richieste dei pod, comprese quelle relative alla quantit\u00e0 di risorse richieste. L'elenco dei nodi trovati da kube-scheduler viene classificato. Il pod \u00e8 pianificato su un nodo con il punteggio pi\u00f9 alto.<\/p>\n<p><img decoding=\"async\" alt=\"Come ottenere accesso alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/b489991a3cbbd5359c99701886d488e5.jpg\" style=\"display:block;margin: 0 auto;\" \/>Dove sar\u00e0 collocato il pod viola?<\/p>\n<p>Nell'immagine si pu\u00f2 vedere che kube-scheduler deve pianificare un nuovo pod viola. Il cluster Kubernetes contiene due nodi: A e B. Come si pu\u00f2 notare, kube-scheduler non pu\u00f2 pianificare il pod sul nodo A \u2014 le risorse disponibili (non richieste) non soddisfano le richieste del pod viola. Pertanto, la memoria richiesta dal pod viola di 1 GB non pu\u00f2 essere allocata sul nodo A, poich\u00e9 la memoria disponibile \u00e8 di 0,5 GB. Ma il nodo B ha risorse sufficienti. Infine, kube-scheduler decide che la destinazione del pod viola \u00e8 il nodo B.<\/p>\n<p>Ora sappiamo come le risorse richieste influenzano la scelta del nodo per l'esecuzione del pod. Ma come influiscono le risorse limite?<\/p>\n<p>Le risorse limite sono il confine che CPU\/MEM non possono oltrepassare. Tuttavia, la risorsa CPU \u00e8 flessibile, quindi i container che raggiungono i limiti della CPU non porteranno alla chiusura del pod. Al contrario, si attiver\u00e0 il throttling della CPU. Se invece viene raggiunto il limite di utilizzo della MEM, il container sar\u00e0 fermato per OOM-Killer e riavviato, se consentito dalla configurazione RestartPolicy.<\/p>\n<h2>Risorse richieste e limiti in dettagli<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Come ottenere accesso alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/22e672100940e8895ae42a56a681111f.jpg\" style=\"display:block;margin: 0 auto;\" \/>Relazione tra risorse Docker e Kubernetes<\/p>\n<p>Il modo migliore per spiegare come funzionano le risorse richieste e quelle limite \u00e8 rappresentare la relazione tra Kubernetes e Docker. Nell'immagine sopra puoi vedere come sono collegate le aree di Kubernetes e i flag di avvio di Docker.<\/p>\n<h2>Memoria: richiesta e limite<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     memory: \"0.5Gi\"\n   limits:\n     memory: \"1Gi\"\n<\/code><\/pre>\n<p>\nCome accennato sopra, la memoria \u00e8 misurata in byte. Basandoci sulla <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-resources-containers\/#meaning-of-memory\">documentazione Kubernetes<\/a><\/noindex>, possiamo specificare la memoria come un numero. Di solito \u00e8 un intero, ad esempio 2678 \u2014 cio\u00e8 2678 byte. Si possono anche usare suffissi. <code>G<\/code> e <code>Gi<\/code>, l'importante \u00e8 ricordare che non sono equivalenti. Il primo \u00e8 decimale, mentre il secondo \u00e8 binario. Come esempio, citato nella documentazione di k8s: <code>128974848<\/code>, <code>129e6<\/code>, <code>129M<\/code>, <code>123Mi<\/code> \u2014 sono praticamente equivalenti.<\/p>\n<p>L'opzione Kubernetes <code>limits.memory<\/code> corrisponde al flag <code>--memory<\/code> di Docker. Nel caso di <code>request.memory<\/code> la freccia per Docker non \u00e8 presente, poich\u00e9 Docker non utilizza questo campo. Puoi chiederti se ne hai bisogno? S\u00ec, ne hai bisogno. Come ho gi\u00e0 detto, il campo \u00e8 importante per Kubernetes. Basandosi sulle informazioni in esso contenute, kube-scheduler decide a quale nodo pianificare il Pod.<\/p>\n<p><strong>Cosa succede se si richiede troppa poca memoria?<\/strong><\/p>\n<p>Se il contenitore raggiunge i limiti di memoria richiesti, il Pod viene inserito in un gruppo di Pod che vengono bloccati in caso di insufficienza di memoria nel nodo.<\/p>\n<p><strong>Cosa succede se si imposta un limite di memoria troppo basso?<\/strong><\/p>\n<p>Se il contenitore supera il limite di memoria, verr\u00e0 terminato per motivo di OOM-Killed. Sar\u00e0 riavviato, se possibile, in base a RestartPolicy, dove il valore predefinito \u00e8 <code>Always<\/code>.<\/p>\n<p><strong>Cosa succede se non si specifica la memoria richiesta?<\/strong><\/p>\n<p>Kubernetes prender\u00e0 il limite come valore predefinito.<\/p>\n<p><strong>Cosa pu\u00f2 succedere se non si specifica la memoria limite?<\/strong><\/p>\n<p>Il contenitore non ha restrizioni, pu\u00f2 utilizzare tutta la memoria che vuole. Se inizia a utilizzare tutta la memoria disponibile nel nodo, verr\u00e0 ucciso da OOM. Poi il contenitore verr\u00e0 riavviato, se possibile, in base a RestartPolicy.<\/p>\n<p><strong>Cosa succede se non si specificano i limiti di memoria?<\/strong><\/p>\n<p>Questo \u00e8 il peggior scenario: lo scheduler non sa quante risorse sono necessarie al contenitore, e questo pu\u00f2 causare seri problemi nel nodo. In questo caso, sarebbe utile avere dei limiti predefiniti nello spazio dei nomi (impostati da LimitRange). Non ci sono limiti predefiniti: il Pod non ha restrizioni, pu\u00f2 utilizzare tutta la memoria che desidera.<\/p>\n<p>Se la memoria richiesta \u00e8 superiore a quella disponibile nel nodo, il Pod non verr\u00e0 pianificato. \u00c8 importante ricordare che <code>Requests.memory<\/code> non \u00e8 un valore minimo. \u00c8 una descrizione della quantit\u00e0 di memoria necessaria per il funzionamento continuo del contenitore. <\/p>\n<p>Di solito si consiglia di impostare lo stesso valore per <code>request.memory<\/code> e <code>limit.memory<\/code>. In questo modo, Kubernetes non pianificher\u00e0 un Pod su un nodo che ha abbastanza memoria per avviare il Pod, ma non abbastanza per farlo funzionare. Tieni presente: nella pianificazione dei Pod, Kubernetes considera solo <code>requests.memory<\/code>, ma <code>limits.memory<\/code> non considera.<\/p>\n<h2>CPU: richiesta e limite<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     cpu: 1\n   limits:\n     cpu: \"1200m\"\n<\/code><\/pre>\n<p>\nPer la CPU \u00e8 tutto un po' pi\u00f9 complicato. Ritornando all'immagine della relazione tra Kubernetes e Docker, si pu\u00f2 notare che <code>request.cpu<\/code> corrisponde a <code>--cpu-shares<\/code>, mentre <code>limit.cpu<\/code> corrisponde al flag <code>cpus<\/code> in Docker.<\/p>\n<p>La CPU, richiesta da Kubernetes, viene moltiplicata per 1024 \u2014 la proporzione dei cicli CPU. Se desideri richiedere 1 core completo, devi aggiungere <code>cpu: 1<\/code>, come mostrato sopra. <\/p>\n<p>Richiedere un core intero (proporzione = 1024) non significa che il tuo container lo ricever\u00e0. Se il tuo host ha solo un core, e stai utilizzando pi\u00f9 di un container, tutti i container devono condividere la CPU disponibile tra loro. Come funziona? Diamo un'occhiata all'immagine.<\/p>\n<p><img decoding=\"async\" alt=\"Come ottenere accesso alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/7f4b20642708ef3a7e773d7900161267.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nRichiesta CPU \u2014 sistema con un core<\/p>\n<p>Immaginiamo di avere un sistema host con un core, su cui sono in esecuzione dei container. Mamma (Kubernetes) ha cotto una torta (CPU) e vuole condividerla tra i suoi figli (container). Tre bambini vogliono una torta intera (proporzione = 1024), un altro bambino ne vuole met\u00e0 (512). Mamma vuole essere giusta e fa un semplice calcolo.<\/p>\n<pre><code class=\"plaintext\"># \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0445\u043e\u0442\u044f\u0442 \u0434\u0435\u0442\u0438?\n# 3 \u0440\u0435\u0431\u0435\u043d\u043a\u0430 \u0445\u043e\u0442\u044f\u0442 \u043f\u043e \u0446\u0435\u043b\u043e\u043c\u0443 \u043f\u0438\u0440\u043e\u0433\u0443 \u0438 \u0435\u0449\u0435 \u043e\u0434\u0438\u043d \u0445\u043e\u0447\u0435\u0442 \u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0443 \u043f\u0438\u0440\u043e\u0433\u0430\ncakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5\n# \u0412\u044b\u0440\u0430\u0436\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f \u0442\u0430\u043a:\n3 (\u0440\u0435\u0431\u0435\u043d\u043a\u0430\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430) * 1 (\u0446\u0435\u043b\u044b\u0439 \u043f\u0438\u0440\u043e\u0433\/\u043f\u043e\u043b\u043d\u043e\u0435 \u044f\u0434\u0440\u043e) + 1 (\u0440\u0435\u0431\u0435\u043d\u043e\u043a\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440) * 0.5 (\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u043f\u0438\u0440\u043e\u0433\u0430\/\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u044f\u0434\u0440\u0430)\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0438\u0441\u043f\u0435\u0447\u0435\u043d\u043e?\navailableCakesNumber = 1\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u0430 (\u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e) \u0434\u0435\u0442\u0438 \u0440\u0435\u0430\u043b\u044c\u043d\u043e \u043c\u043e\u0433\u0443\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c?\nnewMaxRequest = 1 \/ 3.5 =~ 28%<\/code><\/pre>\n<p>\nSecondo i calcoli, tre bambini riceveranno il 28% di un core, e non un core intero. Il quarto bambino ricever\u00e0 il 14% di un core intero, e non met\u00e0. Ma tutto sar\u00e0 diverso se hai un sistema multicore.<\/p>\n<p><img decoding=\"async\" alt=\"Come ottenere accesso alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/7bf71d97add9adcf7cf0260941526590.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nRichiesta CPU \u2014 sistema multicore (4)<\/p>\n<p>Nell'immagine sopra, si vede che tre bambini vogliono una torta intera, mentre uno ne vuole met\u00e0. Poich\u00e9 mamma ha cotto quattro torte, ciascuno dei suoi bambini ricever\u00e0 quanto desidera. In un sistema multicore, le risorse della CPU sono distribuite su tutti i core disponibili. Se un container \u00e8 limitato a meno di un core intero, pu\u00f2 comunque utilizzarlo al 100%. <\/p>\n<p>I calcoli sopra riportati sono semplificati per comprendere come la CPU venga distribuita tra i container. Certamente, oltre ai container stessi, ci sono anche altri processi che utilizzano risorse della CPU. Quando i processi all'interno di un container sono inattivi, altri possono utilizzare le sue risorse. <code>CPU: \"200m\"<\/code> corrisponde a <code>CPU: 0,2<\/code>, che equivale a circa il 20% di un core.<\/p>\n<p>Ora parliamo di <code>limit.cpu<\/code>. La CPU, limitata da Kubernetes, viene moltiplicata per 100. Il risultato \u00e8 il numero di tempo che il container pu\u00f2 utilizzare ogni 100 \u00b5s (<code>cpu-period<\/code>). <\/p>\n<p><code>limit.cpu<\/code> corrisponde al flag Docker <code>--cpus<\/code>. Questa \u00e8 una nuova combinazione di vecchi <code>--cpu-period<\/code> e <code>--cpu-quota<\/code>. Impostandolo, indichiamo quante risorse CPU disponibili il container pu\u00f2 utilizzare al massimo fino a quando non inizia il throttling:<\/p>\n<ul>\n<li><strong>cpus<\/strong> \u2014 combinazione <code>cpu-period<\/code> e <code>cpu-quota. cpus = 1.5<\/code> \u00e8 equivalente all'impostazione <code>cpu-period = 100000<\/code> e <code>cpu-quota = 150000<\/code>;<\/li>\n<li><strong>cpu-period<\/strong> \u2014 periodo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Completely_Fair_Scheduler\">pianificatore CPU CFS<\/a><\/noindex>, di default 100 microsecondi;<\/li>\n<li><strong>cpu-quota<\/strong> \u2014 il numero di microsecondi all'interno <code>cpu-period<\/code>, di cui \u00e8 limitato il contenitore.<\/li>\n<\/ul>\n<p>\n<strong>Cosa succede se si richiede una quantit\u00e0 di CPU insufficiente?<\/strong><\/p>\n<p>Se il contenitore ha bisogno di pi\u00f9 risorse di quelle impostate, ruber\u00e0 CPU ad altri processi.<\/p>\n<p><strong>Cosa succede se si imposta un limite CPU insufficiente?<\/strong><\/p>\n<p>Poich\u00e9 la risorsa CPU \u00e8 regolata, si attiver\u00e0 il throttling.<\/p>\n<p><strong>Cosa succede se non si specifica la richiesta CPU?<\/strong><\/p>\n<p>Come nel caso della memoria, il valore della richiesta \u00e8 uguale al limite.<\/p>\n<p><strong>Cosa succede se non si specifica il limite CPU?<\/strong><\/p>\n<p>Il contenitore utilizzer\u00e0 tutto il CPU di cui ha bisogno. Se nella namespace \u00e8 definita una politica CPU predefinita (LimitRange), verr\u00e0 utilizzato anche per il contenitore.<\/p>\n<p><strong>Cosa succede se non si specifica n\u00e9 la richiesta n\u00e9 il limite CPU?<\/strong><\/p>\n<p>Come nel caso della memoria, questo \u00e8 lo scenario peggiore. Il pianificatore non sa quante risorse sono necessarie per il vostro contenitore, e questo pu\u00f2 causare gravi problemi nel nodo. Per evitarlo, \u00e8 necessario impostare i limiti predefiniti per le namespaces (LimitRange).<\/p>\n<p>Ricorda: se richiedi pi\u00f9 CPU di quanta ne possano fornire i nodi, il Pod non sar\u00e0 programmato. <code>Requests.cpu<\/code> \u2014 non un valore minimo, ma un valore sufficiente per avviare il Pod e funzionare senza interruzioni. Se l'applicazione non esegue calcoli complessi, la scelta migliore \u00e8 impostare <code>request.cpu &lt;= 1<\/code> e avviare tutte le repliche necessarie.<\/p>\n<h2>La quantit\u00e0 ideale di risorse richieste o di limite delle risorse<\/h2>\n<p>\nAbbiamo appreso riguardo il limite delle risorse di elaborazione. Ora \u00e8 giunto il momento di rispondere alla domanda: \"Quante risorse necessita il mio Pod per eseguire l'applicazione senza problemi? Qual \u00e8 la quantit\u00e0 ideale?\". <\/p>\n<p>Sfortunatamente, non ci sono risposte definitive a queste domande. Se non sai come funziona la tua applicazione, quanta CPU o memoria richiede, la scelta migliore \u00e8 fornire all'applicazione molta memoria e CPU, e poi eseguire test di prestazioni.<\/p>\n<p>Oltre ai test di prestazioni, osserva il comportamento dell'applicazione per una settimana attraverso il monitoraggio. Se dai grafici emerge che la tua applicazione consuma meno risorse di quelle richieste, puoi ridurre la quantit\u00e0 di CPU o memoria richiesta.<\/p>\n<p>Ad esempio, guarda questo <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/grafana\/dashboards\/7187\">dashboard Grafana<\/a><\/noindex>. Mostra la differenza tra le risorse richieste o il limite delle risorse e l'attuale utilizzo delle risorse.<\/p>\n<h2>Conclusione<\/h2>\n<p>\nLa richiesta e il limite delle risorse aiutano a mantenere operativo il cluster Kubernetes. Una corretta configurazione dei limiti minimizza i costi e mantiene costantemente le applicazioni in funzione.<\/p>\n<p>In sintesi, ci sono diversi aspetti da considerare:<\/p>\n<ol>\n<li>Le risorse richieste sono la configurazione che viene presa in considerazione durante l'avvio (quando Kubernetes pianifica il posizionamento dell'applicazione). Al contrario, il limite delle risorse \u00e8 importante durante il funzionamento \u2014 quando l'applicazione \u00e8 gi\u00e0 in esecuzione su un nodo.<\/li>\n<li>Rispetto alla memoria, la CPU \u00e8 una risorsa regolabile. In caso di carenza di CPU, il tuo Pod non terminer\u00e0 l'esecuzione, sar\u00e0 attivato il meccanismo di throttling.<\/li>\n<li>Le risorse richieste e il limite delle risorse non sono valori minimi e massimi! Definendo le risorse richieste, garantisci che l'applicazione funzioni senza problemi.<\/li>\n<li>Una buona prassi \u00e8 impostare la richiesta di memoria pari al limite di memoria.<\/li>\n<li>\u00c8 utile impostare la richiesta di <code>CPU &lt;=1<\/code>, se l'applicazione non esegue calcoli complessi.<\/li>\n<li>Se richiedi pi\u00f9 risorse di quelle disponibili sul nodo, il Pod non sar\u00e0 mai pianificato su quel nodo.<\/li>\n<li>Per determinare il giusto numero di risorse richieste\/lavorative, utilizza il collaudo delle prestazioni e il monitoraggio.<\/li>\n<\/ol>\n<p>\nSpero che questo articolo ti aiuti a comprendere il concetto base dei limiti delle risorse. E potrai applicare queste conoscenze nel tuo lavoro.<\/p>\n<p>Buona fortuna!<\/p>\n<p><strong>Cosa leggere ancora:<\/strong><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/500504\/\">Osservabilit\u00e0 SRE: spazi dei nomi e struttura delle metriche<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/blog\/poleznye-instrumenty-dlya-kubernetes\">90+ strumenti utili per Kubernetes: distribuzione, gestione, monitoraggio, sicurezza e altro ancora<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tele.click\/k8s_mail\">Il nostro canale Intorno a Kubernetes su Telegram<\/a><\/noindex>.<\/li>\n<\/ol>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/516014\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>The Reward by Tohad \u0412 \u043d\u0430\u0447\u0430\u043b\u0435 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 Kubernetes \u043e\u0431\u044b\u0447\u043d\u043e \u0437\u0430\u0431\u044b\u0432\u0430\u044e\u0442 \u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432. \u041d\u0430 \u044d\u0442\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u0440\u0430\u0437 Docker \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0438 \u0435\u0433\u043e \u043c\u043e\u0436\u043d\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u041d\u043e \u043f\u043e\u0437\u0434\u043d\u0435\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u043c\u0438. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043d\u0443\u0436\u043d\u043e \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0438 \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94262","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-09-14T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-14T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come accedere alle risorse del Pod Kubernetes | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-14T17:42:34+00:00","article:modified_time":"2020-09-14T17:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94262","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:30:27","updated":"2022-10-02 18:20:09","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/94262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=94262"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/94262\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/94263"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=94262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=94262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=94262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}