{"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\/es\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","title":{"rendered":"C\u00f3mo implementar Istio usando Kubernetes en producci\u00f3n. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Qu\u00e9 es 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

Se puede leer sobre el mecanismo de funcionamiento en documentaci\u00f3n oficial<\/a><\/noindex>. Istio es realmente una herramienta poderosa que permite resolver numerosas tareas y problemas. En este art\u00edculo, me gustar\u00eda responder a las preguntas m\u00e1s comunes que suelen surgir al comenzar a trabajar con Istio. Esto le ayudar\u00e1 a comprenderlo m\u00e1s r\u00e1pidamente.<\/p>\n

\"C\u00f3mo
\n<\/a><\/noindex><\/p>\n

Principio de funcionamiento.<\/h3>\n

\nIstio consta de dos \u00e1reas principales: el plano de control y el plano de datos. El plano de control contiene los componentes clave que aseguran el correcto funcionamiento de los dem\u00e1s. En la versi\u00f3n actual (1.0), el plano de control tiene tres componentes principales: Pilot, Mixer y Citadel. No analizaremos Citadel, ya que se utiliza para generar certificados que garantizan el funcionamiento de mutual TLS entre servicios. Veamos en detalle la estructura y el prop\u00f3sito de Pilot y Mixer.<\/p>\n

\"C\u00f3mo
\n
\nPilot es el componente principal de gesti\u00f3n que distribuye toda la informaci\u00f3n sobre lo que tenemos en el cl\u00faster: servicios, sus puntos finales y reglas de enrutamiento (por ejemplo, reglas para despliegues Canary o reglas de circuit breaker).<\/p>\n

Mixer es un componente opcional del plano de control que permite la recolecci\u00f3n de m\u00e9tricas, registros y cualquier informaci\u00f3n sobre la interacci\u00f3n en red. Tambi\u00e9n supervisa el cumplimiento de las reglas de pol\u00edticas y los l\u00edmites de tasa.<\/p>\n

El plano de datos se implementa mediante contenedores sidecar proxy. Por defecto, se utiliza un potente servidor proxy envoy<\/a><\/noindex>. Puede ser reemplazado por otra implementaci\u00f3n, como nginx (nginmesh).<\/p>\n

Para que Istio funcione de manera completamente transparente para las aplicaciones, existe un sistema de inyecci\u00f3n autom\u00e1tica. La \u00faltima implementaci\u00f3n es adecuada para versiones de Kubernetes 1.9+ (mutational admission webhook). Para las versiones de Kubernetes 1.7 y 1.8, existe la opci\u00f3n de utilizar Initializer.<\/p>\n

Los contenedores sidecar se conectan a Pilot a trav\u00e9s del protocolo GRPC, que permite optimizar el modelo de env\u00edo de cambios que ocurren en el cl\u00faster. GRPC comenz\u00f3 a utilizarse en Envoy a partir de la versi\u00f3n 1.6, en Istio se utiliza desde la versi\u00f3n 0.8 y consiste en un pilot-agent, que es una envoltura en golang sobre envoy que configura los par\u00e1metros de lanzamiento.<\/p>\n

Pilot y Mixer son componentes completamente stateless, manteniendo todo el estado en memoria. La configuraci\u00f3n para ellos se establece en forma de Recursos Personalizados de Kubernetes, que se almacenan en etcd.
\nEl Istio-agent obtiene la direcci\u00f3n de Pilot y abre un flujo GRPC hacia \u00e9l. <\/p>\n

Como ya mencion\u00e9, Istio implementa toda la funcionalidad de forma completamente transparente para las aplicaciones. Vamos a analizar c\u00f3mo. El algoritmo es el siguiente:<\/p>\n

    \n
  1. Desplegamos una nueva versi\u00f3n del servicio.<\/li>\n
  2. Dependiendo del enfoque de inyecci\u00f3n, se a\u00f1aden los contenedores istio-init e istio-agent (envoy) en la etapa de aplicaci\u00f3n de la configuraci\u00f3n, o pueden haber sido insertados manualmente en la descripci\u00f3n de la entidad Pod de Kubernetes.<\/li>\n
  3. El contenedor istio-init es un script que aplica reglas de iptables para el pod. Hay dos opciones para configurar la redirecci\u00f3n del tr\u00e1fico en el contenedor istio-agent: usar reglas de redirecci\u00f3n de iptables, o TPROXY<\/a><\/noindex>. En el momento de redactar este art\u00edculo, por defecto se utiliza el enfoque con reglas de redirecci\u00f3n. En istio-init hay la posibilidad de configurar qu\u00e9 tr\u00e1fico debe ser interceptado y dirigido al istio-agent. Por ejemplo, para interceptar todo el tr\u00e1fico entrante y saliente, es necesario establecer los par\u00e1metros , el intervalo entre el env\u00edo de paquetes.<\/code> y -b<\/code> en *<\/code>. Se pueden especificar puertos concretos que deben ser interceptados. Para no interceptar una subred espec\u00edfica, se puede indicar mediante la opci\u00f3n -x<\/code>.<\/li>\n
  4. Despu\u00e9s de que se ejecutan los contenedores init, se inician los principales, incluido el pilot-agent (envoy). Se conecta al Pilot ya desplegado por GRPC y obtiene informaci\u00f3n sobre todos los servicios existentes y pol\u00edticas de enrutamiento en el cl\u00faster. Seg\u00fan los datos recibidos, configura los cl\u00fasteres y asigna directamente los endpoints de nuestras aplicaciones en el cl\u00faster de Kubernetes. Tambi\u00e9n es importante se\u00f1alar un punto clave: envoy configura din\u00e1micamente los listeners (pares de IP, puerto) que comienza a escuchar. Por lo tanto, cuando las solicitudes entran en el pod, son redirigidas mediante reglas de iptables al sidecar, y envoy puede procesar estas conexiones con \u00e9xito y entender a d\u00f3nde debe dirigir el tr\u00e1fico. En esta etapa tambi\u00e9n se env\u00edan datos al Mixer, que veremos m\u00e1s adelante, y se env\u00edan spans de trazado.<\/li>\n<\/ol>\n

    \nEn consecuencia, obtenemos toda una red de servidores proxy envoy que podemos configurar desde un solo punto (Pilot). Todas las solicitudes entrantes y salientes pasan a trav\u00e9s de envoy. Adem\u00e1s, solo se intercepta el tr\u00e1fico TCP. Esto significa que la IP del servicio de Kubernetes se resuelve mediante kube-dns a trav\u00e9s de UDP sin cambios. Luego, despu\u00e9s de la resoluci\u00f3n, se intercepta la solicitud saliente y se procesa por envoy, que ya decide a qu\u00e9 endpoint debe enviar la solicitud (o no enviarla, en caso de pol\u00edticas de acceso o activaci\u00f3n del algoritmo de cortocircuito).<\/p>\n

    Ahora que hemos entendido el Pilot, necesitamos comprender c\u00f3mo funciona el Mixer y por qu\u00e9 es necesario. Se puede leer la documentaci\u00f3n oficial sobre esto. aqu\u00ed<\/a><\/noindex>.<\/p>\n

    Mixer en su forma actual consiste en dos componentes: istio-telemetry e istio-policy (hasta la versi\u00f3n 0.8, esto era un solo componente, istio-mixer). Ambos representan un mixer, cada uno de los cuales tiene su propia funci\u00f3n. Istio telemetry recibe a trav\u00e9s de GRPC desde los contenedores sidecar Report la informaci\u00f3n sobre a d\u00f3nde va cada uno y con qu\u00e9 par\u00e1metros. Istio-policy recibe solicitudes de Check para verificar si se cumplen las reglas de Policy. Las verificaciones de Policy se realizan, por supuesto, no para cada solicitud, sino que se almacenan en cach\u00e9 en el cliente (en el sidecar) durante un tiempo determinado. Los check de Report se env\u00edan en solicitudes por lotes. C\u00f3mo configurarlo y qu\u00e9 par\u00e1metros deben enviarse lo veremos un poco m\u00e1s adelante. <\/p>\n

    Mixer est\u00e1 dise\u00f1ado como un componente de alta disponibilidad que asegura un funcionamiento ininterrumpido en la recopilaci\u00f3n y procesamiento de datos de telemetr\u00eda. El sistema resulta ser, en \u00faltima instancia, un b\u00fafer de m\u00faltiples niveles. Inicialmente, los datos se almacenan en b\u00fafer en el lado de los contenedores sidecar, luego en el lado del mixer y despu\u00e9s se env\u00edan a los llamados mixer backends. En consecuencia, si alg\u00fan componente del sistema falla, el b\u00fafer crece y, tras la recuperaci\u00f3n del sistema, se vac\u00eda. Los mixer backends representan puntos finales para el env\u00edo de datos de telemetr\u00eda: statsd, newrelic, etc. Se puede escribir un backend propio, es bastante sencillo, y veremos c\u00f3mo hacerlo.<\/p>\n

    \"C\u00f3mo
    \n
    \nEn resumen, el esquema de trabajo con istio-telemetry es el siguiente.<\/p>\n

      \n
    1. El servicio 1 env\u00eda una solicitud al servicio 2.<\/li>\n
    2. Al salir del servicio 1, la solicitud se envuelve en su propio sidecar.<\/li>\n
    3. El sidecar envoy supervisa c\u00f3mo transcurre la solicitud hacia el servicio 2 y prepara la informaci\u00f3n necesaria.<\/li>\n
    4. Luego la env\u00eda a istio-telemetry a trav\u00e9s de una solicitud de Report.<\/li>\n
    5. Istio-telemetry determina si es necesario enviar este Report a los backends, a cu\u00e1les espec\u00edficamente y qu\u00e9 datos deben enviarse.<\/li>\n
    6. Istio-telemetry env\u00eda los datos de Report a los backends si es necesario.<\/li>\n<\/ol>\n

      \nAhora veamos c\u00f3mo desplegar en el sistema Istio que consta solo de los componentes principales (Pilot y sidecar envoy).<\/p>\n

      Primero, veamos la configuraci\u00f3n principal (mesh) que lee 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    # por el momento no habilitamos el env\u00edo de informaci\u00f3n de tracing (pilot configurar\u00e1 los envoy de tal manera que no se enviar\u00e1)\n    enableTracing: false\n\n    # por el momento no especificamos los endpoints de mixer para que los contenedores sidecar no env\u00eden informaci\u00f3n all\u00ed\n    #mixerCheckServer: istio-policy.istio-system:15004\n    #mixerReportServer: istio-telemetry.istio-system:15004\n\n    # establecemos el intervalo de tiempo con el que envoy volver\u00e1 a preguntar a Pilot (esto es para la versi\u00f3n antigua del proxy envoy)\n    rdsRefreshDelay: 5s\n\n    # configuraci\u00f3n por defecto para el sidecar de envoy\n    defaultConfig:\n      # similar a rdsRefreshDelay\n      discoveryRefreshDelay: 5s\n\n      # dejamos por defecto (ruta a la configuraci\u00f3n y al binario de envoy)\n      configPath: \"\/etc\/istio\/proxy\"\n      binaryPath: \"\/usr\/local\/bin\/envoy\"\n\n      # nombre por defecto del contenedor sidecar en ejecuci\u00f3n (se utiliza, por ejemplo, en los nombres de servicio al enviar spans de tracing)\n      serviceCluster: istio-proxy\n\n      # tiempo que esperar\u00e1 envoy antes de forzar el cierre de todas las conexiones establecidas\n      drainDuration: 45s\n      parentShutdownDuration: 1m0s\n\n      # por defecto se utilizan las reglas REDIRECT de iptables. Se puede cambiar a TPROXY.\n      #interceptionMode: REDIRECT\n\n      # Puerto en el que se ejecutar\u00e1 el panel de administraci\u00f3n de cada contenedor sidecar (envoy)\n      proxyAdminPort: 15000\n\n      # direcci\u00f3n a la que se enviar\u00e1n los traces mediante el protocolo zipkin (al principio deshabilitamos el env\u00edo, por lo que este campo no se utilizar\u00e1 actualmente)\n      zipkinAddress: tracing-collector.tracing:9411\n\n      # direcci\u00f3n statsd para enviar m\u00e9tricas de los contenedores de envoy (deshabilitado)\n      # statsdUdpAddress: aggregator:8126\n\n      # deshabilitamos el soporte para la opci\u00f3n Mutual TLS\n      controlPlaneAuthPolicy: NONE\n\n      # direcci\u00f3n en la que escuchar\u00e1 istio-pilot para informar sobre el descubrimiento de servicios a todos los contenedores sidecar\n      discoveryAddress: istio-pilot.istio-system:15007\n<\/code><\/pre>\n
      \nColocaremos todos los componentes principales de control (control plane) en el namespace istio-system en Kubernetes.<\/p>\n
      M\u00ednimamente necesitamos desplegar solo Pilot. Para ello utilizaremos esta configuraci\u00f3n.<\/a><\/noindex><\/p>\n
      Y configuraremos manualmente el inyectado del contenedor sidecar.<\/p>\n
      Contenedor Init:<\/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
      \nY sidecar:<\/p>\n
             nombre: 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
      \nPara que todo funcione correctamente, es necesario crear un ServiceAccount, ClusterRole, ClusterRoleBinding, y CRD para Pilot, cuya descripci\u00f3n se puede encontrar aqu\u00ed<\/a><\/noindex>. <\/p>\n
      Como resultado, el servicio en el que inyectamos el sidecar con envoy debe iniciarse correctamente, obtener todo el descubrimiento del piloto y manejar las solicitudes.<\/p>\n
      Es importante entender que todos los componentes del plano de control son aplicaciones sin estado y se pueden escalar horizontalmente sin problemas. Todos los datos se almacenan en etcd en forma de definiciones de recursos personalizados de Kubernetes.<\/p>\n
      Adem\u00e1s, Istio (por ahora experimentalmente) tiene la posibilidad de ejecutarse fuera del cl\u00faster y la capacidad de ver y compartir el descubrimiento de servicios entre varios cl\u00fasteres de Kubernetes. Puede leer m\u00e1s sobre esto aqu\u00ed<\/a><\/noindex>.<\/p>\n
      Al realizar una instalaci\u00f3n multicl\u00faster, se deben tener en cuenta las siguientes limitaciones:<\/p>\n
        \n
      1. El Pod CIDR y el Service CIDR deben ser \u00fanicos en todos los cl\u00fasteres y no deben superponerse.<\/li>\n
      2. Todos los Pod CIDR deben ser accesibles desde cualquier Pod CIDR entre cl\u00fasteres.<\/li>\n
      3. Todos los servidores API de Kubernetes deben ser accesibles entre s\u00ed.<\/li>\n<\/ol>\n
        \nEsta es informaci\u00f3n inicial que le ayudar\u00e1 a comenzar a trabajar con Istio. Sin embargo, hay muchos otros aspectos a tener en cuenta. Por ejemplo, caracter\u00edsticas del enrutamiento del tr\u00e1fico externo (fuera del cl\u00faster), enfoques para depurar sidecars, perfiles, configuraci\u00f3n del mixer y la escritura de un backend de mixer personalizado, la configuraci\u00f3n del mecanismo de tracing y su funcionamiento con envoy.
        \nTodo esto lo veremos en pr\u00f3ximas publicaciones. Hagan sus preguntas, intentar\u00e9 abordarlas.
        \n
        Fuente:         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\udd47C\u00f3mo implementar Istio usando Kubernetes en producci\u00f3n. Parte 1 | ProHoster","description":"\u00bfQu\u00e9 es Istio? Es lo que se conoce como un Service mesh, una tecnolog\u00eda que a\u00f1ade un nivel de abstracci\u00f3n sobre la red.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/32766","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=32766"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/32766\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/24545"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=32766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=32766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=32766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}