{"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 accedere alle risorse del Pod Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Come accedere 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>Il Reward di Tohad<\/i><\/a><\/noindex><\/p>\n<p>All'inizio del lavoro con Kubernetes, di solito si dimentica 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 in un cluster di produzione insieme ad altre applicazioni. Per questo, \u00e8 necessario allocare risorse per il container e assicurarsi che siano sufficienti per avviare e far funzionare l'applicazione, senza che si verifichino problemi con le altre applicazioni in esecuzione.<\/p>\n<p>Team <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Kubernetes aaS di Mail.ru<\/a><\/noindex> ho tradotto un articolo sulle risorse dei container (CPU &amp; MEM), le richieste e i limiti delle risorse. Scoprirete quali vantaggi offrono queste impostazioni e cosa accade se non vengono configurate.<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 sono specificate per ogni container. Nel seguente file YAML di Pod, vedrete la sezione delle risorse che contiene le risorse richieste e quelle limite:<\/p>\n<ul>\n<li>Risorse richieste del Pod = somma delle risorse richieste di tutti i container;<\/li>\n<li>Risorse limite del Pod = somma delle risorse limite 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 # USO MAX CPU: 1 core\n          memory: \"1Gi\" # USO 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 # USO MAX CPU: 1 core\n          memory: \"1Gi\" # USO MAX MEM:  1Gi<\/code><\/pre>\n<p>Esempio di risorse richieste e limiti<\/p>\n<p>Campo <code>resources.requested<\/code> dallo specifica del Pod \u2014 uno degli elementi utilizzati per cercare il nodo corretto. Su di esso si pu\u00f2 pianificare il deployment del Pod. Come si trova il nodo appropriato?<\/p>\n<p>Kubernetes \u00e8 composto da diversi componenti, inclusi un nodo principale o master-node (Kubernetes Control Plane). Nel master-node ci sono diversi processi: kube-apiserver, kube-controller-manager e kube-scheduler. <\/p>\n<p>Il processo kube-scheduler si occupa di esaminare i nuovi pod creati e di cercare i nodi di lavoro compatibili con tutte le richieste dei pod, inclusi i requisiti relativi alle risorse richieste. L'elenco dei nodi trovati da kube-scheduler \u00e8 ordinato per punteggio. Il Pod viene pianificato sul nodo con il punteggio pi\u00f9 alto.<\/p>\n<p><img decoding=\"async\" alt=\"Come accedere alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/b489991a3cbbd5359c99701886d488e5.jpg\" style=\"display:block;margin: 0 auto;\" \/>Dove verr\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 esigenze del Pod viola. Infatti, l'1 GiB di memoria richiesto dal Pod viola non pu\u00f2 essere allocato sul nodo A, poich\u00e9 la memoria disponibile \u00e8 di 0,5 GiB. Tuttavia, il nodo B ha risorse sufficienti. Di conseguenza, kube-scheduler decide che la destinazione per il 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 un confine che CPU\/MEM non pu\u00f2 oltrepassare. Tuttavia, le risorse CPU sono flessibili, quindi i container che raggiungono i valori limite per CPU non porteranno alla terminazione del Pod. Invece, verr\u00e0 attivato il throttling della CPU. Se viene raggiunto il limite d'uso della MEM, il container verr\u00e0 arrestato per OOM-Killer e riavviato, se consentito dalla configurazione RestartPolicy.<\/p>\n<h2>Risorse richieste e limiti in dettaglio<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Come accedere alle risorse del Pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/22e672100940e8895ae42a56a681111f.jpg\" style=\"display:block;margin: 0 auto;\" \/>Collegamento delle risorse tra Docker e Kubernetes<\/p>\n<p>Il modo migliore per spiegare come funzionano le risorse richieste e i limiti \u00e8 rappresentare il collegamento tra Kubernetes e Docker. Nell'immagine sopra puoi vedere come sono collegati i campi 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 in precedenza, la memoria \u00e8 misurata in byte. Basandosi su <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-resources-containers\/#meaning-of-memory\">documentazione di Kubernetes<\/a><\/noindex>, possiamo specificare la memoria in forma numerica. Di solito \u00e8 un intero, ad esempio 2678 \u2014 cio\u00e8 2678 byte. \u00c8 possibile utilizzare anche i suffissi <code>G<\/code> e <code>Gi<\/code>, \u00e8 importante 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>Parametro Kubernetes <code>limits.memory<\/code> corrisponde al flag <code>--memory<\/code> di Docker. Nel caso di <code>request.memory<\/code> il puntatore per Docker \u00e8 assente, poich\u00e9 Docker non utilizza questo campo. Puoi chiederti se sia davvero necessario? S\u00ec, lo \u00e8. Come ho gi\u00e0 detto, il campo \u00e8 importante per Kubernetes. Sulla base delle informazioni contenute in esso, kube-scheduler decide su quale nodo pianificare il Pod.<\/p>\n<p><strong>Cosa succede se si imposta una richiesta di memoria insufficiente?<\/strong><\/p>\n<p>Se il contenitore raggiunge i limiti della memoria richiesta, il Pod viene messo in un gruppo di Pod che vengono arrestati in caso di mancanza 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 OOM-Killed. E verr\u00e0 riavviato, se possibile, in base a RestartPolicy, dove il valore predefinito \u00e8 <code>Always<\/code>.<\/p>\n<p><strong>Cosa succede se non viene specificata la memoria richiesta?<\/strong><\/p>\n<p>Kubernetes prender\u00e0 il limite e lo imposter\u00e0 come valore predefinito.<\/p>\n<p><strong>Cosa pu\u00f2 succedere se non viene specificata la memoria limite?<\/strong><\/p>\n<p>Il container non ha limiti, pu\u00f2 utilizzare quanta pi\u00f9 memoria desidera. Se inizia a utilizzare tutta la memoria disponibile del nodo, verr\u00e0 terminato da OOM. Successivamente, il container verr\u00e0 riavviato, se possibile, in base a RestartPolicy.<\/p>\n<p><strong>Cosa succede se non si specificano limiti di memoria?<\/strong><\/p>\n<p>Questo \u00e8 il peggior scenario: il pianificatore non sa quante risorse richiede il container e ci\u00f2 pu\u00f2 causare gravi problemi sul nodo. In questo caso, sarebbe utile avere limiti predefiniti nello spazio dei nomi (impostati tramite LimitRange). Non ci sono limiti predefiniti: il Pod non ha restrizioni, pu\u00f2 utilizzare quanta pi\u00f9 memoria desidera.<\/p>\n<p>Se la memoria richiesta \u00e8 superiore a quella che il nodo pu\u00f2 offrire, 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 container. <\/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 il Pod su un nodo che ha abbastanza memoria per avviare il Pod, ma non abbastanza per farlo funzionare. Ricordate: durante la pianificazione del Pod, Kubernetes considera solo <code>requests.memory<\/code>, e <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>\nCon il CPU \u00e8 tutto un po' pi\u00f9 complicato. Tornando 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 della CPU. Se desideri richiedere 1 core completo, devi aggiungere <code>cpu: 1<\/code>, come mostrato sopra. <\/p>\n<p>La richiesta di un core completo (proporzione = 1024) non significa che il tuo contenitore lo ricever\u00e0. Se il tuo computer host ha solo un core e utilizzi pi\u00f9 di un contenitore, tutti i contenitori devono condividere la CPU disponibile tra di loro. Come avviene questo? Diamo un'occhiata all'immagine.<\/p>\n<p><img decoding=\"async\" alt=\"Come accedere 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 i contenitori. Mamma (Kubernetes) ha cotto una torta (CPU) e vuole condividerla tra i bambini (contenitori). Tre bambini vogliono un'intera torta (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. Al quarto bambino andr\u00e0 il 14% di un core completo, e non la met\u00e0. Ma tutto sar\u00e0 diverso se hai un sistema multicore.<\/p>\n<p><img decoding=\"async\" alt=\"Come accedere 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 un intero dolce, mentre uno desidera la met\u00e0. Poich\u00e9 la mamma ha preparato quattro dolci, ciascuno dei suoi figli ricever\u00e0 quanto desidera. In un sistema multicore, le risorse della CPU sono distribuite su tutti i core disponibili. Se un contenitore \u00e8 limitato a meno di un core CPU completo, pu\u00f2 comunque utilizzarlo al 100%. <\/p>\n<p>I calcoli sopra riportati sono semplificati per far comprendere come la CPU venga distribuita tra i contenitori. Naturalmente, oltre ai contenitori stessi, ci sono altri processi che utilizzano anche le risorse della CPU. Quando i processi in un contenitore sono inattivi, altri possono utilizzare le sue risorse. <code>CPU: \"200m\"<\/code> corrisponde a <code>CPU: 0,2<\/code>, che significa 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 la quantit\u00e0 di tempo che il contenitore 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 il contenitore pu\u00f2 utilizzare al massimo prima che inizi 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 a impostare <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\">del pianificatore CPU CFS<\/a><\/noindex>, di default 100 microsecondi;<\/li>\n<li><strong>cpu-quota<\/strong> \u2014 numero di microsecondi dentro <code>cpu-period<\/code>, a cui il contenitore \u00e8 limitato.<\/li>\n<\/ul>\n<p>\n<strong>Cosa succede se si imposta una richiesta di CPU insufficiente?<\/strong><\/p>\n<p>Se il contenitore ha bisogno di pi\u00f9 di quanto impostato, ruber\u00e0 CPU ad altri processi.<\/p>\n<p><strong>Cosa succede se si imposta un limite di CPU insufficiente?<\/strong><\/p>\n<p>Poich\u00e9 la risorsa CPU \u00e8 regolabile, si attiver\u00e0 il throttling.<\/p>\n<p><strong>Cosa succede se non si specifica una richiesta di 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 un limite di CPU?<\/strong><\/p>\n<p>Il contenitore utilizzer\u00e0 tanta CPU quanta ne ha bisogno. Se nel namespace \u00e8 definita una politica CPU predefinita (LimitRange), questo limite verr\u00e0 utilizzato anche per il contenitore.<\/p>\n<p><strong>Cosa succede se non si specifica n\u00e9 richiesta n\u00e9 limite di CPU?<\/strong><\/p>\n<p>Come nel caso della memoria, questa \u00e8 la situazione peggiore. Il pianificatore non sa quante risorse sono necessarie per il tuo container e questo pu\u00f2 causare seri problemi sul nodo. Per evitarlo, \u00e8 necessario impostare limiti predefiniti per i namespace (LimitRange).<\/p>\n<p>Ricorda: se richiedi pi\u00f9 CPU di quanta ne possano fornire i nodi, il Pod non verr\u00e0 pianificato. <code>Requests.cpu<\/code> \u2014 non \u00e8 un valore minimo, ma un valore sufficiente per avviare il Pod e farlo funzionare senza problemi. Se l'applicazione non esegue calcoli complessi, la cosa migliore da fare \u00e8 impostare <code>request.cpu &lt;= 1<\/code> e avviare tante repliche quante necessarie.<\/p>\n<h2>La quantit\u00e0 ideale di risorse richieste o limite delle risorse<\/h2>\n<p>\nAbbiamo appreso riguardo al limite delle risorse computazionali. Ora \u00e8 il momento di rispondere alla domanda: \u00abQuante risorse sono necessarie affinch\u00e9 il mio Pod esegua l'applicazione senza problemi? Qual \u00e8 la quantit\u00e0 ideale?\u00bb. <\/p>\n<p>Sfortunatamente, non ci sono risposte definitive a queste domande. Se non si sa come funziona la propria applicazione, quanta CPU o memoria richiede, la cosa migliore da fare \u00e8 fornire molte risorse di memoria e CPU, e poi eseguire test di prestazione.<\/p>\n<p>Oltre ai test di prestazioni, monitora il comportamento dell'applicazione durante la settimana. Se dai grafici risulta che la tua applicazione consuma meno risorse di quelle richieste, puoi diminuire la quantit\u00e0 di CPU o memoria richiesta.<\/p>\n<p>Per 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 riduce al minimo i costi e mantiene costantemente le applicazioni in funzionamento.<\/p>\n<p>In sintesi, ci sono alcuni punti da tenere a mente:<\/p>\n<ol>\n<li>Le risorse richieste sono la configurazione considerata durante l'avvio (quando Kubernetes pianifica la collocazione 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 si fermer\u00e0, ma si attiver\u00e0 il meccanismo di throttling.<\/li>\n<li>Le risorse richieste e i limiti delle risorse non sono valori minimi e massimi! Definendo le risorse richieste, garantite che l'applicazione funzioni senza problemi.<\/li>\n<li>\u00c8 una buona pratica impostare la richiesta di memoria uguale al limite di memoria.<\/li>\n<li>\u00c8 bene impostare la richiesta di <code>CPU &lt;=1<\/code>, se l'applicazione non esegue calcoli complessi.<\/li>\n<li>Se richiedete pi\u00f9 risorse di quelle disponibili nel nodo, il Pod non sar\u00e0 mai programmato su quel nodo.<\/li>\n<li>Per determinare la quantit\u00e0 corretta di risorse richieste\/livelli di risorse, utilizzate i test di carico e il monitoraggio.<\/li>\n<\/ol>\n<p>\nSpero che questo articolo vi aiuti a comprendere il concetto fondamentale di limitazione delle risorse. E sarete in grado di applicare queste conoscenze nel vostro lavoro.<\/p>\n<p>Buona fortuna!<\/p>\n<p><strong>Cosa altro leggere:<\/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: deployment, gestione, monitoraggio, sicurezza e altro ancora<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tele.click\/k8s_mail\">Il nostro canale Attorno 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.0.1 - 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.0.1\" \/>\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}]}}