Como iniciar o Istio usando o Kubernetes na produção. Parte 1

O que é o Istio ? Essa é a chamada malha de serviço, uma tecnologia que adiciona uma camada de abstração na rede. Interceptamos todo ou parte do tráfego no cluster e executamos um conjunto específico de operações com ele. Qual? Por exemplo, fazemos roteamento inteligente ou implementamos a abordagem do disjuntor, podemos organizar uma "implantação de canário", alternando parcialmente o tráfego para uma nova versão do serviço e podemos limitar as interações externas e controlar todas as viagens do cluster para a rede externa. É possível definir regras de política para controlar campanhas entre diferentes microsserviços. Por fim, podemos obter todo o mapa de interação pela rede e tornar a coleção unificada de métricas completamente transparente para aplicativos.

Sobre o mecanismo de trabalho pode ser encontrado na documentação oficial . O Istio é uma ferramenta realmente poderosa que pode resolver muitos problemas e problemas. Neste artigo, gostaria de responder às perguntas básicas que geralmente surgem no início do trabalho com o Istio. Isso ajudará você a lidar com isso mais rapidamente.

Princípio de funcionamento

O Istio consiste em duas zonas principais - plano de controle e plano de dados. O plano de controle contém os principais componentes que garantem a operação correta do restante. Na versão atual (1.0), o plano de controle possui três componentes principais: Pilot, Mixer, Citadel. Não consideraremos o Citadel, é necessário gerar certificados para garantir TLS mútuo entre os serviços. Vamos dar uma olhada no dispositivo e na finalidade do Pilot and Mixer.



O piloto é o principal componente de controle que divulga todas as informações sobre o que temos no cluster - serviços, seus pontos de extremidade e regras de roteamento (por exemplo, regras para implantação do Canary ou regras do disjuntor).

Misturador - um componente opcional do plano de controle, que fornece a capacidade de coletar métricas, logs e qualquer informação sobre interações na rede. Ele também monitora a conformidade com as regras da política e a conformidade com os limites de taxa.

O plano de dados é implementado usando contêineres proxy de side-car. Por padrão, o poderoso servidor proxy enviado é usado . Pode ser substituído por outra implementação, por exemplo nginx (nginmesh).

Para que o Istio funcione de forma totalmente transparente para aplicativos, existe um sistema de injeção automática. A implementação mais recente é adequada para versões do Kubernetes 1.9+ (webhook de admissão mutacional). Para as versões 1.7, 1.8 do Kubernetes, é possível usar o Inicializador.

Os contêineres laterais são conectados ao Pilot por meio do protocolo GRPC, que permite otimizar o modelo de envio das mudanças que ocorrem no cluster. O GRPC começou a ser usado no Envoy desde a versão 1.6, no Istio, desde a versão 0.8 e é um agente piloto - um invólucro no golang sobre o enviado que configura os parâmetros de inicialização.

Piloto e Mixer são componentes completamente sem estado, todo o estado é mantido na memória. A configuração para eles é especificada como Recursos Personalizados do Kubernetes, que são salvos no etcd.
O Istio-agent recebe o endereço Pilot e abre um fluxo GRPC para ele.

Como eu disse, o Istio implementa toda a funcionalidade completamente transparente para os aplicativos. Vamos descobrir como. O algoritmo é o seguinte:

1. Implante uma nova versão do serviço.
2. Dependendo da abordagem de injeção do contêiner lateral, um contêiner istio-init e um contêiner istio-agente (enviado) são adicionados no estágio de aplicação da configuração ou já podem ser inseridos manualmente na descrição do Pod da entidade Kubernetes.
3. O contêiner istio-init é um script que aplica as regras do iptables para a lareira. Há duas opções para configurar a quebra de tráfego no contêiner istio-agent: use as regras de redirecionamento de iptables ou TPROXY . No momento da escrita, é usada a abordagem padrão com regras de redirecionamento. No istio-init, é possível configurar qual tráfego precisa ser interceptado e roteado para o istio-agent. Por exemplo, para interceptar todo o tráfego de entrada e saída, você precisa definir os parâmetros -i e -b como * . Você pode especificar portas específicas a serem interceptadas. Para não interceptar uma sub-rede específica, você pode especificá-la usando o sinalizador -x .
4. Após a execução dos contêineres init, 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 pontos finais de nossos aplicativos no cluster Kubernetes. Também vale a pena notar um ponto importante: o enviado configura dinamicamente ouvintes (IP, pares de portas) que ele começa a ouvir. Portanto, quando as solicitações entram no pod, elas são redirecionadas usando as regras de redirecionamento de iptables no side-car, o enviado já pode processar com êxito essas conexões e entender onde o tráfego de proxy deve ser continuado. Também nesta fase, as informações são enviadas para o Mixer, que discutiremos mais adiante, e enviando intervalos de rastreamento.

Como resultado, obtemos toda uma rede de servidores proxy enviados, 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 resolve usando o kube-dns sobre UDP sem alterar. Em seguida, após a resolução, a solicitação de saída é interceptada e processada pelo enviado, que já decide para qual terminal enviar a solicitação (ou não, no caso de políticas de acesso ou acionamento de algoritmos de disjuntor).

Com o Pilot resolvido, agora você precisa entender como o Mixer funciona e por que ele é necessário. Você pode ler a documentação oficial aqui .

O misturador em sua forma atual consiste em dois componentes: istio-telemetria, istio-policy (antes da versão 0.8, era um componente do istio-mixer). Ambos são misturadores, cada um dos quais é responsável por sua tarefa. A telemetria Istio recebe via GRPC do sidecar Report containers informações sobre quem vai aonde e com quais parâmetros. O Istio-policy aceita pedidos de verificação para verificar se as regras de política são atendidas. As verificações poilicy são realizadas, é claro, não para cada solicitação, mas são armazenadas em cache no cliente (no side-car) por um certo tempo. As verificações de relatório são enviadas por solicitações em lote. Veremos um pouco mais tarde como configurar e quais parâmetros você precisa enviar.

O Mixer deve ser um componente altamente disponível que fornece trabalho ininterrupto na coleta e processamento de dados de telemetria. O sistema é um buffer de vários níveis. Inicialmente, os dados são armazenados em buffer no lado lateral dos contêineres, depois no lado do misturador e depois enviados para os chamados backends do misturador. Como resultado, se algum componente do sistema falhar, o buffer aumenta e trava após a recuperação do sistema. Os backends do misturador são os pontos finais para o envio de dados de telemetria: statsd, newrelic etc. Você pode escrever seu back-end, é bem simples, e veremos como fazê-lo.



Resumindo, o esquema de trabalho com istio-telemetria é o seguinte.

1. O serviço 1 envia uma solicitação para o serviço 2.
2. Ao sair do serviço 1, a solicitação é agrupada em seu próprio carro lateral.
3. O enviado do side-car monitora como a solicitação de serviço 2 passa e prepara as informações necessárias.
4. Em seguida, envia-o para istio-telemetria usando a solicitação de relatório.
5. A Istio-telemetria determina se deve enviar este relatório para back-end, para quais dados e quais dados enviar.
6. A Istio-telemetria envia os dados do relatório para o back-end, se necessário.

Agora vamos ver como implantar no sistema Istio, consistindo apenas dos componentes principais (piloto e enviado lateral).

Primeiro, vejamos 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 do plano de controle estão localizados no sistema de namespace istio no Kubernetes.

No mínimo, precisamos implantar apenas o Pilot. Para fazer isso, usaremos essa configuração.

E configure manualmente o carro lateral de injeção do contêiner.

Container inicial:

 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 carro lateral:

  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 obter ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, cujas descrições podem ser encontradas aqui .

Como resultado, o serviço no qual injetamos o side-car com enviado deve iniciar com êxito, obter toda a descoberta 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 estão no etcd como descrições personalizadas dos recursos do Kubernetes.

O Istio também (até agora experimentalmente) tem a capacidade de executar fora do cluster e a capacidade de observar e se atrapalhar na descoberta de serviços entre vários clusters do Kubernetes. Você pode ler mais sobre isso aqui .

Para uma instalação com vários clusters, as seguintes restrições devem ser consideradas:

1. O CIDR do pod e o CIDR de serviço devem ser exclusivos em todos os clusters e não devem se sobrepor.
2. Todos os CIDRs de Pods devem estar disponíveis em qualquer CIDRs de Pods entre clusters.
3. Todos os servidores da API do Kubernetes devem estar acessíveis um ao outro.

Esta é a informação inicial para ajudá-lo a começar com o Istio. No entanto, ainda existem muitas armadilhas. Por exemplo, recursos de roteamento de tráfego externo (para a parte externa do cluster), abordagens para depuração de sidecar, criação de perfil, configuração de um mixer e gravação de um backend de mixer personalizado, configuração de um mecanismo de rastreamento e sua operação usando o enviado.
Vamos considerar tudo isso nas seguintes publicações. Faça suas perguntas, tentarei cobri-las.