{"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":"

Che cos'\u00e8 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 risolve molte esigenze 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 comprenderlo pi\u00f9 rapidamente.<\/p>\n

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

Principio di funzionamento<\/h3>\n

\nIstio \u00e8 composto da due aree principali: control plane e data plane. Il control plane comprende 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 ci soffermeremo su Citadel, che serve per generare certificati per garantire il funzionamento di mutual TLS tra i servizi. Esaminiamo pi\u00f9 nel dettaglio la struttura e la funzione di Pilot e Mixer.<\/p>\n

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

Mixer \u00e8 un componente facoltativo del control plane che fornisce la possibilit\u00e0 di raccogliere metriche, log e qualsiasi informazione sulle interazioni di rete. Inoltre, monitora il rispetto delle policy e dei limiti di frequenza.<\/p>\n

Il data plane viene implementato tramite contenitori sidecar proxy. Di default, utilizza un potente proxy server envoy<\/a><\/noindex>. Pu\u00f2 essere sostituito con un'altra implementazione, come nginx (nginmesh).<\/p>\n

Per rendere Istio 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 1.7 e 1.8 di Kubernetes, \u00e8 possibile utilizzare Initializer.<\/p>\n

I contenitori sidecar si connettono a Pilot tramite il protocollo GRPC, che consente di ottimizzare il modello di push delle modifiche nel cluster. GRPC \u00e8 stato introdotto in Envoy a partire dalla versione 1.6, e in Istio \u00e8 utilizzato dalla versione 0.8 ed \u00e8 rappresentato dal pilot-agent, un wrapper in golang sopra 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 come Kubernetes Custom Resources, che vengono salvate in etcd.
\nIstio-agent riceve l'indirizzo di Pilot e apre uno stream GRPC verso di esso. <\/p>\n

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

    \n
  1. Deployamo una nuova versione del servizio.<\/li>\n
  2. A seconda dell'approccio di iniezione, il contenitore sidecar viene aggiunto con il contenitore istio-init e il contenitore istio-agent (envoy) durante l'applicazione della configurazione, oppure possono gi\u00e0 essere stati manualmente inseriti nella descrizione dell'entity Pod di Kubernetes.<\/li>\n
  3. Il contenitore istio-init \u00e8 uno script che applica le regole iptables per il pod. Ci sono due varianti per configurare l'instradamento del traffico verso il contenitore istio-agent: utilizzare regole di redirect iptables, oppure TPROXY<\/a><\/noindex>. Al momento della scrittura dell'articolo, viene utilizzato per default l'approccio con le regole di redirect. In istio-init \u00e8 possibile configurare quale traffico deve essere intercettato e inviato a istio-agent. Ad esempio, per intercettare tutto il traffico in entrata e in uscita, \u00e8 necessario impostare i parametri. -i<\/code> e -b<\/code> su *<\/code>. \u00c8 possibile specificare porte specifiche da intercettare. Se si desidera non intercettare una determinata sottorete, \u00e8 possibile indicarla tramite un flag. -x<\/code>.<\/li>\n
  4. Dopo l'esecuzione dei contenitori init, vengono avviati quelli principali, incluso pilot-agent (envoy). Questo si connette 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 specifica gli endpoint delle nostre applicazioni nel cluster Kubernetes. \u00c8 importante notare che envoy configura dinamicamente gli listeners (coppie IP, porta) che inizia a monitorare. Pertanto, quando le richieste entrano nel pod, vengono reindirizzate tramite le regole di redirect iptables nel sidecar, e envoy \u00e8 gi\u00e0 in grado di gestire queste connessioni e capire dove deve inoltrare il traffico. In questa fase avviene anche l'invio delle informazioni a Mixer, che vedremo dopo, e l'invio di span di tracciamento.<\/li>\n<\/ol>\n

    \nIl risultato \u00e8 una rete di proxy server envoy, che possiamo configurare da un unico punto (Pilot). Tutte le richieste in entrata e in uscita passano attraverso envoy. Tuttavia, solo il traffico TCP viene intercettato. Questo significa che l'IP del servizio Kubernetes viene risolto tramite kube-dns in UDP senza modifiche. Solo dopo la risoluzione avviene l'intercettazione della richiesta in uscita e la sua elaborazione da parte di envoy, che decide a quale endpoint deve essere inviata la richiesta (o non inviata, nel caso di politiche di accesso o attivazione dell'algoritmo del circuit breaker).<\/p>\n

    Ora che abbiamo chiarito Pilot, 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 il mixer, ognuno responsabile per il proprio compito. Istio telemetry riceve informazioni sui Report dai contenitori sidecar tramite GRPC riguardo a chi si sta connettendo e con quali parametri. Istio-policy gestisce le richieste di Check per verificare il rispetto delle regole Policy. I controlli delle Policy non vengono effettuati per ogni richiesta, ma sono memorizzati nella cache lato client (nel sidecar) per un certo periodo. I Report vengono inviati come richieste batch. Vedremo pi\u00f9 tardi come configurarlo e quali parametri inviare esattamente. <\/p>\n

    Il Mixer \u00e8 progettato come un componente ad alta disponibilit\u00e0, che garantisce un funzionamento continuo nella raccolta e nell'elaborazione dei dati di telemetry. Il sistema si configura quindi come un buffer multilivello. Inizialmente, i dati vengono memorizzati sul lato dei contenitori sidecar, poi sul lato del 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, il funzionamento di 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 sidecar.<\/li>\n
    3. Il sidecar envoy monitora il percorso della richiesta verso il servizio 2 e prepara le informazioni necessarie.<\/li>\n
    4. Poi le invia a istio-telemetry tramite una richiesta Report.<\/li>\n
    5. Istio-telemetry determina se inviare questo Report ai backend, a 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 implementare un sistema Istio composto solo dai componenti principali (Pilot e sidecar envoy).<\/p>\n

      Per iniziare, diamo 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    # non abilitiamo ancora l'invio delle informazioni di tracing (pilot configurer\u00e0 gli envoy in modo che l'invio non avvenga)\n    enableTracing: false\n\n    # non specifichiamo ancora gli endpoint del mixer, per evitare che i contenitori sidecar inviino informazioni l\u00ec\n    #mixerCheckServer: istio-policy.istio-system:15004\n    #mixerReportServer: istio-telemetry.istio-system:15004\n\n    # impostiamo l'intervallo di tempo per il quale l'envoy interrogher\u00e0 nuovamente il Pilot (questo \u00e8 per la vecchia versione dell'envoy proxy)\n    rdsRefreshDelay: 5s\n\n    # configurazione predefinita per l'envoy sidecar\n    defaultConfig:\n      # simile a rdsRefreshDelay\n      discoveryRefreshDelay: 5s\n\n      # lasciamo il percorso di configurazione e l'eseguibile envoy per il modo predefinito\n      configPath: \"\/etc\/istio\/proxy\"\n      binaryPath: \"\/usr\/local\/bin\/envoy\"\n\n      # nome predefinito del container sidecar avviato (utilizzato, ad esempio, nei nomi dei servizi durante l'invio di 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      # sono utilizzate di default le regole REDIRECT di iptables. Puoi cambiarle in TPROXY.\n      #interceptionMode: REDIRECT\n\n      # Porta su cui verr\u00e0 avviata la pannello di amministrazione di ciascun container sidecar (envoy)\n      proxyAdminPort: 15000\n\n      # indirizzo a cui verranno inviati i trace secondo il protocollo zipkin (all'inizio abbiamo disabilitato l'invio stesso, quindi questo campo non verr\u00e0 utilizzato attualmente)\n      zipkinAddress: tracing-collector.tracing:9411\n\n      # indirizzo statsd per inviare metriche dai 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 scoperta di servizi a tutti i contenitori sidecar\n      discoveryAddress: istio-pilot.istio-system:15007\n<\/code><\/pre>\n
      \nTutti i componenti principali di controllo (control plane) saranno collocati nel namespace istio-system in Kubernetes.<\/p>\n
      Minimamente dobbiamo implementare solo Pilot. Per fare ci\u00f2, utilizzeremo questa configurazione.<\/a><\/noindex><\/p>\n
      E configureremo manualmente l'iniezione del container sidecar.<\/p>\n
      Inizializzazione del container:<\/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 avviare tutto con successo, \u00e8 necessario creare un ServiceAccount, ClusterRole, ClusterRoleBinding, 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 con successo, ricevere tutte le informazioni di discovery dal pilota e gestire le richieste.<\/p>\n
      \u00c8 importante comprendere che tutti i componenti del control plane sono applicazioni stateless e possono essere facilmente scalati orizzontalmente. Tutti i dati sono archiviati in etcd sotto forma di risorse personalizzate di Kubernetes.<\/p>\n
      Istio offre anche (per ora in modo sperimentale) la possibilit\u00e0 di eseguire al di fuori del cluster e di visualizzare e condividere la service discovery tra pi\u00f9 cluster di Kubernetes. Maggiori dettagli possono essere letti. qui<\/a><\/noindex>.<\/p>\n
      In caso di installazione multi-cluster, 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 di Kubernetes devono essere accessibili l'uno all'altro.<\/li>\n<\/ol>\n
        \nQueste sono informazioni preliminari che ti aiuteranno a iniziare a lavorare con Istio. Tuttavia, ci sono ancora molte insidie. Ad esempio, particolarit\u00e0 del routing del traffico esterno (verso l'esterno del cluster), approcci al debug dei sidecar, profiling, configurazione del mixer e scrittura di un mixer backend personalizzato, configurazione del meccanismo di tracing e il suo funzionamento attraverso envoy.
        \nTutto questo sar\u00e0 trattato nei prossimi articoli. Fai le tue domande, cercher\u00f2 di affrontarle.
        \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 una cosiddetta service mesh, una tecnologia che aggiunge un livello di astrazione sopra la 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}]}}