{"id":32766,"date":"2019-10-31T21:48:48","date_gmt":"2019-10-31T18:48:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1\/"},"modified":"2019-10-31T21:48:48","modified_gmt":"2019-10-31T18:48:48","slug":"kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","title":{"rendered":"Come avviare Istio utilizzando Kubernetes in produzione. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cosa sono Istio<\/a><\/noindex>? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e. \u041c\u044b \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u0435\u043c \u0432\u0435\u0441\u044c \u0438\u043b\u0438 \u0447\u0430\u0441\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0441 \u043d\u0438\u043c. \u041a\u0430\u043a\u043e\u0439 \u0438\u043c\u0435\u043d\u043d\u043e? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0435\u043b\u0430\u0435\u043c \u0443\u043c\u043d\u044b\u0439 \u0440\u043e\u0443\u0442\u0438\u043d\u0433, \u0438\u043b\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434 circuit breaker, \u043c\u043e\u0436\u0435\u043c \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u00abcanary deployment\u00bb, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043d\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u0430, \u0430 \u043c\u043e\u0436\u0435\u043c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0438 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u043f\u043e\u0445\u043e\u0434\u044b \u0438\u0437 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0432\u043e \u0432\u043d\u0435\u0448\u043d\u044e\u044e \u0441\u0435\u0442\u044c. \u0415\u0441\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0437\u0430\u0434\u0430\u0432\u0430\u0442\u044c policy \u043f\u0440\u0430\u0432\u0438\u043b\u0430 \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u043f\u043e\u0445\u043e\u0434\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0440\u0430\u0437\u043d\u044b\u043c\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c\u0438. \u041d\u0430\u043a\u043e\u043d\u0435\u0446, \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0432\u0441\u044e \u043a\u0430\u0440\u0442\u0443 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u043f\u043e \u0441\u0435\u0442\u0438 \u0438 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0443\u043d\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e \u0434\u043b\u044f \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439.<\/p>\n

Puoi leggere del meccanismo di funzionamento in documentazione ufficiale<\/a><\/noindex>. Istio \u00e8 davvero uno strumento potente che consente di risolvere numerosi compiti e problemi. In questo articolo, vorrei rispondere alle domande principali che di solito sorgono all'inizio dell'utilizzo di Istio. Questo ti aiuter\u00e0 a comprendere meglio come funziona.<\/p>\n

\"Come
\n<\/a><\/noindex><\/p>\n

Il principio di funzionamento<\/h3>\n

\nIstio \u00e8 composto da due aree principali: il control plane e il data plane. Il control plane include i componenti principali che garantiscono il corretto funzionamento degli altri. Nella versione attuale (1.0), il control plane ha tre componenti principali: Pilot, Mixer, Citadel. Non tratteremo Citadel, poich\u00e9 \u00e8 necessario per la generazione dei certificati per garantire il funzionamento del mutual TLS tra i servizi. Diamo un'occhiata pi\u00f9 da vicino alla struttura e alla funzionalit\u00e0 di Pilot e Mixer.<\/p>\n

\"Come
\n
\nPilot \u00e8 il principale componente di gestione, che distribuisce tutte le informazioni su ci\u00f2 che abbiamo nel cluster: servizi, i loro endpoint e le regole di routing (ad esempio, regole per il Canary deployment o regole per il circuit breaker).<\/p>\n

Mixer \u00e8 un componente opzionale del control plane che offre la possibilit\u00e0 di raccogliere metriche, log e qualsiasi informazione sulle interazioni di rete. Inoltre, si occupa di monitorare il rispetto delle regole della Policy e dei limiti di rate.<\/p>\n

Il data plane viene implementato tramite container sidecar proxy. Per impostazione predefinita, viene utilizzato un potente proxy server envoy<\/a><\/noindex>. Pu\u00f2 essere sostituito con un'altra implementazione, come nginx (nginmesh).<\/p>\n

Affinch\u00e9 Istio funzioni in modo completamente trasparente per le applicazioni, esiste un sistema di inject automatico. L'ultima implementazione \u00e8 adatta per le versioni di Kubernetes 1.9+ (mutational admission webhook). Per le versioni di Kubernetes 1.7 e 1.8, \u00e8 possibile utilizzare l'Initializer.<\/p>\n

I container sidecar si connettono a Pilot tramite il protocollo GRPC, che consente di ottimizzare il modello di push delle modifiche avvenute nel cluster. GRPC \u00e8 stato utilizzato in Envoy a partire dalla versione 1.6, ed \u00e8 utilizzato in Istio dalla versione 0.8, ed \u00e8 rappresentato da pilot-agent - un wrapper su golang per envoy, che configura i parametri di avvio.<\/p>\n

Pilot e Mixer sono componenti completamente stateless, mantenendo tutto lo stato in memoria. La configurazione per loro \u00e8 definita sotto forma di Kubernetes Custom Resources, che vengono salvate in etcd.
\nIstio-agent riceve l'indirizzo di Pilot e apre uno stream GRPC a esso. <\/p>\n

Come ho gi\u00e0 detto, Istio implementa tutta la funzionalit\u00e0 in modo completamente trasparente per le applicazioni. Vediamo come. L'algoritmo \u00e8 il seguente:<\/p>\n

    \n
  1. Deployiamo una nuova versione del servizio.<\/li>\n
  2. A seconda dell'approccio di inserimento del contenitore sidecar, vengono aggiunti il contenitore istio-init e il contenitore istio-agent (envoy) durante l'applicazione della configurazione, oppure possono gi\u00e0 essere stati inseriti manualmente nella descrizione dell'entit\u00e0 Pod di Kubernetes.<\/li>\n
  3. Il contenitore istio-init \u00e8 uno script che applica le regole iptables per il pod. Ci sono due opzioni per configurare l'incapsulamento del traffico nel contenitore istio-agent: utilizzare le regole di redirect di iptables oppure TPROXY<\/a><\/noindex>. Al momento della scrittura dell'articolo, per impostazione predefinita viene utilizzato l'approccio con le regole di redirect. Nel contenitore istio-init c'\u00e8 la possibilit\u00e0 di configurare quale traffico deve essere intercettato e diretto all'istio-agent. Ad esempio, per intercettare tutto il traffico in entrata e in uscita, \u00e8 necessario impostare i parametri -i<\/code> e -b<\/code> a valore *<\/code>. \u00c8 possibile specificare porte specifiche che devono essere intercettate. Per non intercettare una determinata sottorete, \u00e8 possibile indicarla con il flag -x<\/code>.<\/li>\n
  4. Dopo l'esecuzione dei contenitori init, vengono avviati i contenitori principali, incluso pilot-agent (envoy). Si collega a Pilot gi\u00e0 distribuito tramite GRPC e riceve informazioni su tutti i servizi esistenti e le politiche di routing nel cluster. Sulla base delle informazioni ricevute, configura i cluster e definisce direttamente gli endpoint delle nostre applicazioni nel cluster Kubernetes. \u00c8 importante notare un aspetto cruciale: envoy configura dinamicamente i listeners (coppie IP, porta) che inizia ad ascoltare. Pertanto, quando le richieste entrano nel pod, vengono reindirizzate tramite le regole di redirect iptables nel sidecar, envoy pu\u00f2 gi\u00e0 gestire con successo queste connessioni e comprendere dove deve indirizzare il traffico successivamente. In questa fase avviene anche l'invio di informazioni a Mixer, che esamineremo pi\u00f9 avanti, e l'invio degli span di tracciamento.<\/li>\n<\/ol>\n

    \nAlla fine otteniamo una rete intera di server proxy envoy, che possiamo configurare da un'unica posizione (Pilot). Tutte le richieste in entrata e in uscita passano attraverso envoy. Inoltre, viene intercettato solo il traffico TCP. Ci\u00f2 significa che l'IP del servizio Kubernetes viene risolto tramite kube-dns utilizzando UDP senza alcuna modifica. Solo dopo la risoluzione avviene l'intercettazione della richiesta in uscita e l'elaborazione da parte di envoy, che decide gi\u00e0 a quale endpoint deve inviare la richiesta (o non inviare, nel caso di politiche di accesso o dell'attivazione dell'algoritmo del circuit breaker).<\/p>\n

    Abbiamo chiarito il funzionamento di Pilot, ora dobbiamo capire come funziona Mixer e a cosa serve. Puoi leggere la documentazione ufficiale su di esso. qui<\/a><\/noindex>.<\/p>\n

    Il mixer, nella sua forma attuale, \u00e8 composto da due componenti: istio-telemetry e istio-policy (fino alla versione 0.8 era un unico componente, istio-mixer). Entrambi rappresentano un mixer, ciascuno dei quali \u00e8 responsabile del proprio compito. Istio telemetry riceve via GRPC dai container sidecar informazioni su chi va dove e con quali parametri. Istio-policy riceve richieste di controllo per verificare la conformit\u00e0 alle regole della Policy. I controlli della Policy vengono eseguiti, ovviamente, non su ogni richiesta, ma vengono memorizzati nella cache sul client (nel sidecar) per un certo periodo di tempo. I report vengono inviati in batch. Vedremo pi\u00f9 tardi come configurare e quali parametri inviare esattamente. <\/p>\n

    Il mixer \u00e8 previsto come componente ad alta disponibilit\u00e0, che garantisce un funzionamento continuo per la raccolta e l'elaborazione dei dati di telemetria. Risultando, alla fine, un buffer multi-level. I dati vengono inizialmente memorizzati nella cache lato container sidecar, poi lato mixer e infine inviati ai cosiddetti mixer backend. Di conseguenza, se uno dei componenti del sistema fallisce, il buffer cresce e dopo il ripristino del sistema viene svuotato. I mixer backend rappresentano i punti finali per l'invio dei dati di telemetria: statsd, newrelic, ecc. \u00c8 possibile scrivere il proprio backend, \u00e8 abbastanza semplice, e vedremo come farlo.<\/p>\n

    \"Come
    \n
    \nIn sintesi, lo schema di lavoro con istio-telemetry \u00e8 il seguente.<\/p>\n

      \n
    1. Il servizio 1 invia una richiesta al servizio 2.<\/li>\n
    2. All'uscita dal servizio 1, la richiesta viene incapsulata nel suo stesso sidecar.<\/li>\n
    3. Il sidecar envoy monitora il transito della richiesta nel servizio 2 e prepara le informazioni necessarie.<\/li>\n
    4. Successivamente, le invia a istio-telemetry tramite una richiesta di report.<\/li>\n
    5. Istio-telemetry determina se \u00e8 necessario inviare questo report ai backend, quali esattamente e quali dati devono essere inviati.<\/li>\n
    6. Istio-telemetry invia i dati di report al backend se necessario.<\/li>\n<\/ol>\n

      \nOra vediamo come distribuire in un sistema Istio composto solo dai componenti principali (Pilot e sidecar envoy).<\/p>\n

      Iniziamo a dare un'occhiata alla configurazione principale (mesh) che legge Pilot:<\/p>\n

      apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: istio\n  namespace: istio-system\n  labels:\n    app: istio\n    service: istio\ndata:\n  mesh: |-\n\n    # per ora non abilitiamo l'invio delle informazioni di tracing (il pilot configurer\u00e0 gli envoy in modo che l'invio non avvenga)\n    enableTracing: false\n\n    # per ora non specifichiamo gli endpoint del mixer, affinch\u00e9 i contenitori sidecar non inviino informazioni l\u00ec\n    #mixerCheckServer: istio-policy.istio-system:15004\n    #mixerReportServer: istio-telemetry.istio-system:15004\n\n    # impostiamo un intervallo di tempo con cui l'envoy interrogher\u00e0 nuovamente il Pilot (questo \u00e8 per la vecchia versione del proxy envoy)\n    rdsRefreshDelay: 5s\n\n    # configurazione predefinita per il sidecar envoy\n    defaultConfig:\n      # similmente a rdsRefreshDelay\n      discoveryRefreshDelay: 5s\n\n      # lasciamo predefinito (percorso alla configurazione e binario envoy)\n      configPath: \"\/etc\/istio\/proxy\"\n      binaryPath: \"\/usr\/local\/bin\/envoy\"\n\n      # nome predefinito del contenitore sidecar in esecuzione (usato, ad esempio, nei nomi dei servizi quando si inviano tracing span)\n      serviceCluster: istio-proxy\n\n      # tempo che l'envoy attender\u00e0 prima di terminare forzatamente tutte le connessioni stabilite\n      drainDuration: 45s\n      parentShutdownDuration: 1m0s\n\n      # per impostazione predefinita vengono utilizzate le regole di REDIRECT iptables. Pu\u00f2 essere modificato in TPROXY.\n      #interceptionMode: REDIRECT\n\n      # Porta su cui verr\u00e0 avviata la pannello di amministrazione di ogni contenitore sidecar (envoy)\n      proxyAdminPort: 15000\n\n      # indirizzo a cui saranno inviati i trace secondo il protocollo zipkin (inizialmente abbiamo disabilitato l'invio stesso, quindi questo campo non verr\u00e0 utilizzato ora)\n      zipkinAddress: tracing-collector.tracing:9411\n\n      # indirizzo statsd per inviare metriche dei contenitori envoy (disabilitato)\n      # statsdUdpAddress: aggregator:8126\n\n      # disabilitiamo il supporto per l'opzione Mutual TLS\n      controlPlaneAuthPolicy: NONE\n\n      # indirizzo su cui istio-pilot ascolter\u00e0 per comunicare informazioni sulla discovery del servizio a tutti i contenitori sidecar\n      discoveryAddress: istio-pilot.istio-system:15007\n<\/code><\/pre>\n
      \nTutti i principali componenti di gestione (control plane) saranno collocati nel namespace istio-system in Kubernetes.<\/p>\n
      Minimamente dobbiamo distribuire solo il Pilot. Per questo utilizzeremo questa configurazione.<\/a><\/noindex><\/p>\n
      E configureremo manualmente l'iniezione del contenitore sidecar.<\/p>\n
      Contenitore di inizializzazione:<\/p>\n
      initContainers:\n - name: istio-init\n   args:\n   - -p\n   - \"15001\"\n   - -u\n   - \"1337\"\n   - -m\n   - REDIRECT\n   - -i\n   - '*'\n   - -b\n   - '*'\n   - -d\n   - \"\"\n   image: istio\/proxy_init:1.0.0\n   imagePullPolicy: IfNotPresent\n   resources:\n     limits:\n       memory: 128Mi\n   securityContext:\n     capabilities:\n       add:\n       - NET_ADMIN\n<\/code><\/pre>\n
      \nE sidecar:<\/p>\n
             name: istio-proxy\n       args:\n         - \"bash\"\n         - \"-c\"\n         - |\n           exec \/usr\/local\/bin\/pilot-agent proxy sidecar \n           --configPath \n           \/etc\/istio\/proxy \n           --binaryPath \n           \/usr\/local\/bin\/envoy \n           --serviceCluster \n           service-name \n           --drainDuration \n           45s \n           --parentShutdownDuration \n           1m0s \n           --discoveryAddress \n           istio-pilot.istio-system:15007 \n           --discoveryRefreshDelay \n           1s \n           --connectTimeout \n           10s \n           --proxyAdminPort \n           \"15000\" \n           --controlPlaneAuthPolicy \n           NONE\n         env:\n         - name: POD_NAME\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.name\n         - name: POD_NAMESPACE\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.namespace\n         - name: INSTANCE_IP\n           valueFrom:\n             fieldRef:\n               fieldPath: status.podIP\n         - name: ISTIO_META_POD_NAME\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.name\n         - name: ISTIO_META_INTERCEPTION_MODE\n           value: REDIRECT\n         image: istio\/proxyv2:1.0.0\n         imagePullPolicy: IfNotPresent\n         resources:\n           requests:\n             cpu: 100m\n             memory: 128Mi\n           limits:\n             memory: 2048Mi\n         securityContext:\n           privileged: false\n           readOnlyRootFilesystem: true\n           runAsUser: 1337\n         volumeMounts:\n         - mountPath: \/etc\/istio\/proxy\n           name: istio-envoy\n<\/code><\/pre>\n
      \nPer far funzionare tutto correttamente, \u00e8 necessario creare un ServiceAccount, un ClusterRole, un ClusterRoleBinding e una CRD per Pilot, le cui descrizioni possono essere trovate qui<\/a><\/noindex>. <\/p>\n
      Di conseguenza, il servizio in cui iniettiamo il sidecar con envoy deve avviarsi correttamente, ricevere tutte le informazioni di discovery dal pilota e gestire le richieste.<\/p>\n
      \u00c8 importante capire che tutti i componenti del control plane sono applicazioni stateless e possono essere scalati orizzontalmente senza problemi. Tutti i dati sono memorizzati in etcd sotto forma di descrizioni personalizzate delle risorse Kubernetes.<\/p>\n
      Inoltre, Istio (finora in modo sperimentale) offre la possibilit\u00e0 di essere eseguito al di fuori del cluster e di visualizzare e condividere la service discovery tra pi\u00f9 cluster Kubernetes. Maggiori informazioni sono disponibili qui<\/a><\/noindex>.<\/p>\n
      In un'installazione multicluster si devono considerare le seguenti limitazioni:<\/p>\n
        \n
      1. Il Pod CIDR e il Service CIDR devono essere unici per tutti i cluster e non devono sovrapporsi.<\/li>\n
      2. Tutti i Pod CIDR devono essere accessibili da qualsiasi Pod CIDR tra i cluster.<\/li>\n
      3. Tutti i server API Kubernetes devono essere accessibili l'uno all'altro.<\/li>\n<\/ol>\n
        \nQueste sono informazioni iniziali che ti aiuteranno ad avvicinarti al lavoro con Istio. Tuttavia, ci sono ancora molte insidie. Ad esempio, le peculiarit\u00e0 del routing del traffico esterno (fuori dal cluster), approcci per il debugging dei sidecar, profiling, configurazione del mixer e scrittura di un backend mixer personalizzato, configurazione del meccanismo di tracing e il suo funzionamento tramite envoy.
        \nEsamineremo tutto questo nei prossimi articoli. Inviate le vostre domande, cercher\u00f2 di rispondere.
        \n
        Fonte:         habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 Istio? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e. \u041c\u044b \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u0435\u043c \u0432\u0435\u0441\u044c \u0438\u043b\u0438 \u0447\u0430\u0441\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0441 \u043d\u0438\u043c. \u041a\u0430\u043a\u043e\u0439 \u0438\u043c\u0435\u043d\u043d\u043e? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0435\u043b\u0430\u0435\u043c \u0443\u043c\u043d\u044b\u0439 \u0440\u043e\u0443\u0442\u0438\u043d\u0433, \u0438\u043b\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434 circuit breaker, \u043c\u043e\u0436\u0435\u043c \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u00abcanary deployment\u00bb, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043d\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u0430, \u0430 \u043c\u043e\u0436\u0435\u043c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24545,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32766","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come avviare Istio utilizzando Kubernetes in produzione. Parte 1 | ProHoster","description":"Che cos'\u00e8 Istio? \u00c8 un cosiddetto Service mesh, una tecnologia che aggiunge un livello di astrazione sulla rete.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","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 \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c Istio, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f Kubernetes \u0432 production. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 Istio? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","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":"2019-10-31T18:48:48+00:00","article:modified_time":"2019-10-31T18:48:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32766","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":"2026-01-21 12:27:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:53:24","updated":"2026-01-21 12:27:19","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\/32766","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=32766"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/32766\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/24545"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=32766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=32766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=32766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}