O que é ? Trátase da chamada Service mesh, unha tecnoloxía que engade unha capa de abstracción sobre a rede. Interceptamos todo ou parte do tráfico do clúster e realizamos un determinado conxunto de operacións con el. Cal? Por exemplo, facemos un enrutamento intelixente ou implementamos o enfoque de interruptor automático, podemos organizar o "despliegue canario", cambiando parcialmente o tráfico a unha nova versión do servizo, ou podemos limitar as interaccións externas e controlar todas as viaxes do clúster ao rede externa. É posible establecer regras de políticas para controlar as viaxes entre diferentes microservizos. Finalmente, podemos obter todo o mapa de interacción da rede e facer que a colección unificada de métricas sexa completamente transparente para as aplicacións.
Podes ler sobre o mecanismo de traballo en . Istio é unha ferramenta realmente poderosa que che permite resolver moitas tarefas e problemas. Neste artigo, gustaríame responder ás principais preguntas que adoitan xurdir ao comezar con Istio. Isto axudarache a xestionalo máis rápido.
Principio de funcionamento
Istio consta de dúas áreas principais: o plano de control e o plano de datos. O plano de control contén os principais compoñentes que aseguran o correcto funcionamento do resto. Na versión actual (1.0) o plano de control ten tres compoñentes principais: Piloto, Mixer, Citadel. Non consideraremos Citadel, é necesario xerar certificados para garantir o TLS mutuo entre servizos. Vexamos máis de cerca o dispositivo e o propósito de Pilot and Mixer.
Pilot é o principal compoñente de control que distribúe toda a información sobre o que temos no clúster: servizos, os seus extremos e regras de enrutamento (por exemplo, regras para o despregamento de Canary ou regras de interruptor de circuito).
O mesturador é un compoñente opcional do plano de control que ofrece a posibilidade de recoller métricas, rexistros e calquera información sobre a interacción da rede. Tamén supervisa o cumprimento das regras da Política e o cumprimento dos límites de tarifas.
O plano de datos implícase mediante contedores de proxy sidecar. Poderoso úsase por defecto. . Pódese substituír por outra implementación, como nginx (nginmesh).
Para que Istio funcione totalmente transparente para as aplicacións, hai un sistema de inxección automática. A implementación máis recente é adecuada para as versións de Kubernetes 1.9+ (webhook de admisión mutacional). Para as versións de Kubernetes 1.7, 1.8 é posible usar o Inicializador.
Os contedores sidecar están conectados a Pilot mediante o protocolo GRPC, que permite optimizar o modelo push para os cambios que se producen no clúster. GRPC utilízase en Envoy desde a versión 1.6, en Istio utilízase desde a versión 0.8 e é un axente piloto: un envoltorio de golang sobre Envoy que configura as opcións de lanzamento.
Pilot e Mixer son compoñentes completamente sen estado, todos os estados gárdanse na memoria. A configuración para eles establécese en forma de Recursos personalizados de Kubernetes, que se almacenan en etcd.
Istio-agent obtén o enderezo do piloto e ábrelle un fluxo GRPC.
Como dixen, Istio implementa todas as funcionalidades totalmente transparentes para as aplicacións. A ver como. O algoritmo é este:
- Implantación dunha nova versión do servizo.
- Dependendo do enfoque de inxección de contedores sidecar, o contedor istio-init e o contenedor istio-agent (envoy) engádense na fase de aplicación da configuración, ou xa se poden inserir manualmente na descrición da entidade Kubernetes Pod.
- O contenedor istio-init é un script que aplica as regras de iptables ao pod. Hai dúas opcións para configurar o tráfico para ser envolto nun contenedor istio-agent: usar regras de redirección de iptables ou . No momento de escribir este artigo, o enfoque predeterminado é con regras de redirección. En istio-init, é posible configurar que tráfico debe ser interceptado e enviado a istio-agent. Por exemplo, para interceptar todo o tráfico entrante e saínte, cómpre configurar os parámetros
-iи-ben significado*. Podes especificar portos específicos para interceptar. Para non interceptar unha subrede específica, pode especificala usando a marca-x. - Despois de executar os contedores de inicio, lánzanse os principais, incluído o piloto-axente (enviado). Conéctase ao piloto xa implantado a través de GRPC e recibe información sobre todos os servizos e políticas de enrutamento existentes no clúster. Segundo os datos recibidos, configura os clústeres e asígnaos directamente aos extremos das nosas aplicacións no clúster de Kubernetes. Tamén é necesario ter en conta un punto importante: envoy configura de forma dinámica os oíntes (IP, pares de portos) que comeza a escoitar. Polo tanto, cando as solicitudes entran no pod, son redirixidas usando as regras de iptables de redirección no sidecar, Envoy xa pode procesar con éxito estas conexións e comprender onde seguir proxy o tráfico. Tamén nesta fase envíase información ao Mixer, que veremos máis adiante, e envíanse os intervalos de trazado.
Como resultado, obtemos toda unha rede de servidores proxy de Envoy que podemos configurar desde un punto (Pilot). Todas as solicitudes entrantes e saíntes pasan por enviado. Ademais, só se intercepta o tráfico TCP. Isto significa que a IP do servizo de Kubernetes resólvese usando kube-dns sobre UDP sen cambiar. Despois, despois da resolución, a solicitude de saída é interceptada e procesada polo enviado, que xa decide a que punto final se debe enviar (ou non, no caso das políticas de acceso ou do interruptor automático do algoritmo).
Descubrimos Pilot, agora necesitamos entender como funciona Mixer e por que é necesario. Podes ler a documentación oficial para iso .
Mixer na súa forma actual consta de dous compoñentes: istio-telemetry, istio-policy (antes da versión 0.8 era un compoñente istio-mixer). Ambos son mesturadores, cada un dos cales é responsable da súa propia tarefa. Istio telemetry recibe información sobre quen vai a onde e con que parámetros dos contedores de informes sidecar a través de GRPC. Istio-policy acepta solicitudes de verificación para verificar que se cumpren as regras da política. Por suposto, as comprobacións de Poilicy non se realizan para todas as solicitudes, senón que se almacenan en caché no cliente (no sidecar) durante un tempo determinado. As comprobacións de informes envíanse como solicitudes por lotes. Vexamos como configurar e que parámetros se deben enviar un pouco máis tarde.
Suponse que o Mixer é un compoñente altamente dispoñible que garante un traballo ininterrompido na montaxe e procesamento de datos de telemetría. O sistema obtense como resultado como un búfer multinivel. Inicialmente, os datos almacénanse no lado do sidecar dos contedores, despois no lado do mesturador e despois envíanse aos chamados backends do mesturador. Como resultado, se algún dos compoñentes do sistema falla, o búfer crece e líbrase despois de restaurar o sistema. Os backends do mesturador son puntos finais para enviar datos de telemetría: statsd, newrelic, etc. Podes escribir o teu propio backend, é bastante sinxelo, e veremos como facelo.
En resumo, o esquema para traballar con istio-telemetría é o seguinte.
- O servizo 1 envía unha solicitude ao servizo 2.
- Ao abandonar o servizo 1, a solicitude envólvese no seu propio sidecar.
- Sidecar enviado supervisa como a solicitude vai ao servizo 2 e prepara a información necesaria.
- Despois envíao a istio-telemetry mediante unha solicitude de informe.
- Istio-telemetry determina se este Informe debe enviarse aos backends, a que e que datos deben enviarse.
- Istio-telemetry envía os datos do informe ao backend se é necesario.
Agora vexamos como despregar Istio no sistema, composto só polos compoñentes principais (piloto e enviado de sidecar).
Primeiro, vexamos a configuración principal (malla) que le Pilot:
apiVersion: v1
kind: ConfigMap
metadata:
name: istio
namespace: istio-system
labels:
app: istio
service: istio
data:
mesh: |-
# пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
enableTracing: false
# пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
#mixerCheckServer: istio-policy.istio-system:15004
#mixerReportServer: istio-telemetry.istio-system:15004
# ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
rdsRefreshDelay: 5s
# default конфигурация для envoy sidecar
defaultConfig:
# аналогично как rdsRefreshDelay
discoveryRefreshDelay: 5s
# оставляем по умолчанию (путь к конфигурации и бинарю envoy)
configPath: "/etc/istio/proxy"
binaryPath: "/usr/local/bin/envoy"
# дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
serviceCluster: istio-proxy
# время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
drainDuration: 45s
parentShutdownDuration: 1m0s
# по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
#interceptionMode: REDIRECT
# Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
proxyAdminPort: 15000
# адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
zipkinAddress: tracing-collector.tracing:9411
# statsd адрес для отправки метрик envoy контейнеров (отключаем)
# statsdUdpAddress: aggregator:8126
# выключаем поддержку опции Mutual TLS
controlPlaneAuthPolicy: NONE
# адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
discoveryAddress: istio-pilot.istio-system:15007
Todos os compoñentes de control principais (plano de control) estarán situados no sistema de espazo de nomes istio en Kubernetes.
Como mínimo, só necesitamos despregar Pilot. Para iso utilizamos
E configuraremos manualmente o sidecar de inxección do recipiente.
Contedor de inicio:
initContainers:
- name: istio-init
args:
- -p
- "15001"
- -u
- "1337"
- -m
- REDIRECT
- -i
- '*'
- -b
- '*'
- -d
- ""
image: istio/proxy_init:1.0.0
imagePullPolicy: IfNotPresent
resources:
limits:
memory: 128Mi
securityContext:
capabilities:
add:
- NET_ADMIN
E sidecar:
name: istio-proxy
args:
- "bash"
- "-c"
- |
exec /usr/local/bin/pilot-agent proxy sidecar
--configPath
/etc/istio/proxy
--binaryPath
/usr/local/bin/envoy
--serviceCluster
service-name
--drainDuration
45s
--parentShutdownDuration
1m0s
--discoveryAddress
istio-pilot.istio-system:15007
--discoveryRefreshDelay
1s
--connectTimeout
10s
--proxyAdminPort
"15000"
--controlPlaneAuthPolicy
NONE
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: INSTANCE_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: ISTIO_META_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: ISTIO_META_INTERCEPTION_MODE
value: REDIRECT
image: istio/proxyv2:1.0.0
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 2048Mi
securityContext:
privileged: false
readOnlyRootFilesystem: true
runAsUser: 1337
volumeMounts:
- mountPath: /etc/istio/proxy
name: istio-envoy
Para que todo comece con éxito, debes crear unha ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, cuxas descricións pódense atopar .
Como resultado, o servizo no que inxectamos sidecar con enviado debería comezar con éxito, recibir todos os descubrimentos do piloto e procesar as solicitudes.
É importante entender que todos os compoñentes do plano de control son aplicacións sen estado e pódense escalar horizontalmente sen problemas. Todos os datos almacénanse en etcd en forma de descricións personalizadas dos recursos de Kubernetes.
Ademais, Istio (aínda experimental) ten a capacidade de executarse fóra do clúster e a capacidade de ver e buscar o descubrimento de servizos entre varios clústeres de Kubernetes. Podes ler máis sobre isto .
Para unha instalación de varios clústeres, teña en conta as seguintes limitacións:
- Pod CIDR e Service CIDR deben ser únicos en todos os clústeres e non deben superpoñerse.
- Todos os Pods CIDR deben ser accesibles desde calquera Pod CIDR entre clústeres.
- Todos os servidores da API de Kubernetes deben ser accesibles entre si.
Esta é a información inicial para axudarche a comezar con Istio. Non obstante, aínda hai moitas trampas. Por exemplo, características de enrutamento de tráfico externo (fóra do clúster), enfoques para depurar sidecars, creación de perfiles, configuración dun mesturador e escritura dun backend de mesturador personalizado, configuración dun mecanismo de rastrexo e o seu funcionamento mediante Envoy.
Todo isto teremos en conta nas seguintes publicacións. Fai as túas preguntas, tentarei cubrilas.
Fonte: www.habr.com