o que ? Essa é a chamada Service mesh, uma tecnologia que adiciona uma camada de abstração sobre a rede. Interceptamos todo ou parte do tráfego no cluster e executamos um determinado conjunto de operações com ele. Qual deles? Por exemplo, fazemos roteamento inteligente ou implementamos a abordagem do disjuntor, podemos organizar “implantação canário”, comutando parcialmente o tráfego para uma nova versão do serviço, ou podemos limitar as interações externas e controlar todas as viagens do cluster para o rede externa. É possível definir regras de política para controlar viagens entre diferentes microsserviços. Por fim, podemos obter todo o mapa de interação da rede e tornar a coleção unificada de métricas completamente transparente para os aplicativos.
Você pode ler sobre o mecanismo de trabalho em . O Istio é uma ferramenta realmente poderosa que permite resolver muitas tarefas e problemas. Neste artigo, gostaria de responder às principais dúvidas que geralmente surgem ao começar a usar o Istio. Isso ajudará você a lidar com isso mais rapidamente.
Como funciona
O Istio consiste em duas áreas principais - o plano de controle e o plano de dados. O plano de controle contém os componentes principais que garantem o funcionamento correto do resto. Na versão atual (1.0) o plano de controle possui três componentes principais: Pilot, Mixer, Citadel. Não vamos considerar o Citadel, é necessário gerar certificados para garantir o TLS mútuo entre os serviços. Vamos dar uma olhada mais de perto no dispositivo e na finalidade do Pilot e do Mixer.
O Pilot é o principal componente de controle que distribui todas as informações sobre o que temos no cluster - serviços, seus endpoints e regras de roteamento (por exemplo, regras para implantação do Canary ou regras do disjuntor).
Mixer é um componente de plano de controle opcional que fornece a capacidade de coletar métricas, logs e qualquer informação sobre interação de rede. Ele também monitora o cumprimento das regras da Política e o cumprimento dos limites tarifários.
O plano de dados é implementado usando contêineres de proxy sidecar. Poderoso é usado por padrão. . Ele pode ser substituído por outra implementação, como nginx (nginmesh).
Para que o Istio funcione de forma totalmente transparente às aplicações, existe um sistema de injeção automática. A implementação mais recente é adequada para as versões 1.9+ do Kubernetes (webhook de admissão mutacional). Para Kubernetes versões 1.7, 1.8 é possível usar o Initializer.
Os contêineres sidecar são conectados ao Pilot usando o protocolo GRPC, que permite otimizar o modelo push para alterações que ocorrem no cluster. O GRPC é usado no Envoy desde a versão 1.6, no Istio é usado desde a versão 0.8 e é um piloto-agente - um golang wrapper sobre o enviado que configura as opções de inicialização.
Pilot e Mixer são componentes completamente sem estado, todo o estado é mantido na memória. A configuração para eles é definida na forma de Kubernetes Custom Resources, que são armazenados no etcd.
O Istio-agent obtém o endereço do Pilot e abre um fluxo GRPC para ele.
Como eu disse, o Istio implementa todas as funcionalidades de forma totalmente transparente para os aplicativos. Vamos ver como. O algoritmo é este:
- Implantando uma nova versão do serviço.
- Dependendo da abordagem de injeção de contêiner sidecar, o contêiner istio-init e o contêiner istio-agent (envoy) são adicionados no estágio de aplicação da configuração ou já podem ser inseridos manualmente na descrição da entidade Kubernetes Pod.
- O contêiner istio-init é um script que aplica as regras do iptables ao pod. Há duas opções para configurar o tráfego a ser agrupado em um contêiner istio-agent: usar regras de redirecionamento iptables ou . No momento da escrita, a abordagem padrão é com regras de redirecionamento. No istio-init é possível configurar qual tráfego deve ser interceptado e enviado ao istio-agent. Por exemplo, para interceptar todo o tráfego de entrada e saída, você precisa definir os parâmetros
-iи-bem significado*. Você pode especificar portas específicas para interceptar. Para não interceptar uma sub-rede específica, você pode especificá-la usando o sinalizador-x. - Depois que os contêineres init são executados, os principais são lançados, incluindo o piloto-agente (enviado). Ele se conecta ao Pilot já implantado via GRPC e recebe informações sobre todos os serviços e políticas de roteamento existentes no cluster. De acordo com os dados recebidos, ele configura os clusters e os atribui diretamente aos endpoints de nossas aplicações no cluster Kubernetes. Também é necessário observar um ponto importante: o envoy configura dinamicamente os ouvintes (IP, pares de portas) que ele começa a ouvir. Portanto, quando as solicitações entram no pod, são redirecionadas usando as regras do iptables de redirecionamento no sidecar, o envoy já pode processar com êxito essas conexões e entender onde fazer o proxy do tráfego. Também nesta fase, as informações são enviadas para o Mixer, que veremos mais adiante, e os spans de rastreamento são enviados.
Como resultado, obtemos toda uma rede de servidores proxy Envoy que podemos configurar a partir de um ponto (Pilot). Todas as solicitações de entrada e saída passam pelo enviado. Além disso, apenas o tráfego TCP é interceptado. Isso significa que o IP do serviço Kubernetes é resolvido usando kube-dns sobre UDP sem alteração. Em seguida, após a resolução, a solicitação de saída é interceptada e processada pelo envoy, que já decide para qual endpoint a solicitação deve ser enviada (ou não enviada, no caso de políticas de acesso ou disjuntor do algoritmo).
Descobrimos o Pilot, agora precisamos entender como o Mixer funciona e por que ele é necessário. Você pode ler a documentação oficial para isso .
O Mixer em sua forma atual consiste em dois componentes: istio-telemetry, istio-policy (antes da versão 0.8, era um componente istio-mixer). Ambos são misturadores, cada um responsável por sua própria tarefa. A telemetria do Istio recebe informações sobre quem vai aonde e com quais parâmetros dos contêineres de relatórios secundários via GRPC. Istio-policy aceita solicitações de verificação para verificar se as regras da política foram atendidas. As verificações de políticas, é claro, não são realizadas para cada solicitação, mas são armazenadas em cache no cliente (no sidecar) por um determinado tempo. As verificações de relatório são enviadas como solicitações em lote. Vamos ver como configurar e quais parâmetros devem ser enviados um pouco mais tarde.
O Mixer deve ser um componente altamente disponível que garante um trabalho ininterrupto na montagem e processamento de dados de telemetria. O sistema é obtido como resultado como um buffer de vários níveis. Inicialmente, os dados são armazenados em buffer no lado sidecar dos contêineres, depois no lado do mixer e depois enviados para os chamados back-ends do mixer. Como resultado, se algum dos componentes do sistema falhar, o buffer aumenta e é liberado após a restauração do sistema. Os back-ends do mixer são pontos finais para enviar dados de telemetria: statsd, newrelic, etc. Você pode escrever seu próprio back-end, é bem simples, e veremos como fazê-lo.
Para resumir, o esquema para trabalhar com istio-telemetria é o seguinte.
- O serviço 1 envia uma solicitação ao serviço 2.
- Ao sair do serviço 1, a solicitação é agrupada em seu próprio sidecar.
- O enviado sidecar monitora como a solicitação vai para o serviço 2 e prepara as informações necessárias.
- Em seguida, envia para istio-telemetry usando uma solicitação de relatório.
- O Istio-telemetry determina se este Relatório deve ser enviado para os backends, para quais e quais dados devem ser enviados.
- Istio-telemetry envia dados de relatório para o back-end, se necessário.
Agora vamos ver como implantar o Istio no sistema, composto apenas pelos componentes principais (Pilot e sidecar envoy).
Primeiro, vamos ver a configuração principal (malha) que o Pilot lê:
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 principais componentes de controle (plano de controle) estarão localizados no namespace istio-system no Kubernetes.
No mínimo, precisamos apenas implantar o Pilot. Para isso usamos
E configuraremos manualmente o sidecar de injeção do contêiner.
Contêiner de inicialização:
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 tudo comece com sucesso, você precisa criar um ServiceAccount, ClusterRole, ClusterRoleBinding, CRD para Pilot, cujas descrições podem ser encontradas .
Como resultado, o serviço no qual injetamos o sidecar com o enviado deve iniciar com êxito, receber todas as descobertas do piloto e processar as solicitações.
É importante entender que todos os componentes do plano de controle são aplicativos sem estado e podem ser dimensionados horizontalmente sem problemas. Todos os dados são armazenados no etcd na forma de descrições personalizadas dos recursos do Kubernetes.
Além disso, o Istio (ainda experimental) tem a capacidade de executar fora do cluster e a capacidade de observar e atrapalhar a descoberta de serviços entre vários clusters do Kubernetes. Você pode ler mais sobre isso .
Para uma instalação de vários clusters, esteja ciente das seguintes limitações:
- O CIDR de pod e o CIDR de serviço devem ser exclusivos em todos os clusters e não devem se sobrepor.
- Todos os pods CIDR devem ser acessíveis de qualquer pods CIDR entre clusters.
- Todos os servidores da API do Kubernetes devem ser acessíveis uns aos outros.
Estas são as informações iniciais para ajudá-lo a começar a usar o Istio. No entanto, ainda existem muitas armadilhas. Por exemplo, recursos de roteamento de tráfego externo (fora do cluster), abordagens para depurar sidecars, criação de perfil, configuração de um mixer e gravação de um back-end de mixer personalizado, configuração de um mecanismo de rastreamento e sua operação usando o envoy.
Tudo isso vamos considerar nas próximas publicações. Faça suas perguntas, tentarei cobri-las.
Fonte: habr.com