No último
artigo, examinamos os componentes básicos do Service Mesh Istio, nos familiarizamos com o sistema e respondemos às perguntas básicas que geralmente surgem no início do trabalho com o Istio. Nesta parte, veremos como organizar a coleta de informações de rastreamento na rede.
A primeira coisa que muitos desenvolvedores e administradores de sistema encontram quando ouvem as palavras Service Mesh está rastreando. De fato, adicionamos um servidor proxy especial a cada nó da rede através do qual todo o tráfego TCP passa. Parece que agora você pode facilmente enviar informações sobre todas as interações de rede na rede. Infelizmente, na realidade, existem muitas nuances que devem ser levadas em consideração. Vamos olhar para eles.
Equívoco número um: podemos obter dados de viagens pela rede gratuitamente
De fato, relativamente livre, só podemos conectar os nós do nosso sistema por setas e a taxa de dados que passa entre os serviços (de fato, apenas o número de bytes por unidade de tempo). No entanto, na maioria dos casos, nossos serviços se comunicam usando algum tipo de protocolo no nível do aplicativo, como HTTP, gRPC, Redis e assim por diante. E, é claro, queremos ver as informações de rastreamento precisamente de acordo com esses protocolos, queremos ver a taxa de solicitações e não a taxa de dados. Queremos entender a latência de solicitações pelo nosso protocolo. Por fim, queremos ver o caminho completo pelo qual a solicitação entra no nosso sistema e recebe uma resposta do usuário. Este problema não é tão facilmente resolvido.
Para começar, vejamos como o envio de extensões de rastreamento se parece do ponto de vista da arquitetura no Istio. Como lembramos da primeira parte, o Istio possui um componente separado para coletar telemetria, chamado Mixer. No entanto, na versão atual 1.0. * O envio é feito diretamente de servidores proxy, ou seja, com o proxy enviado. O proxy Envoy suporta o envio de extensões de rastreamento por meio do protocolo zipkin imediatamente. Outros protocolos podem ser conectados, mas apenas através do plugin. Com o Istio, obtemos imediatamente o proxy enviado e montado, que suporta apenas o protocolo zipkin. Se quisermos usar, por exemplo, o protocolo Jaeger e enviar extensões de rastreamento via UDP, precisaremos montar nossa imagem istio-proxy. Há suporte para plug-ins personalizados para istio-proxy, no entanto, ele ainda está na versão alfa. Portanto, se quisermos fazer sem muitas configurações personalizadas, a gama de tecnologias usadas para armazenar e receber intervalos de rastreamento é reduzida. Dos principais sistemas, de fato, agora você pode usar o próprio Zipkin, ou Jaeger, mas enviar tudo para lá usando um protocolo compatível com zipkin (que é muito menos eficiente). O próprio protocolo zipkin envolve o envio de todas as informações de rastreamento aos coletores usando o protocolo HTTP, o que é bastante caro.
Como eu disse, queremos rastrear protocolos no nível do aplicativo. E isso significa que os servidores proxy próximos a cada serviço devem entender que tipo de interação está acontecendo agora. Por padrão, o Istio define o tipo para todas as portas TCP simples, o que significa que nenhum rastreamento será enviado. Para que os rastreamentos sejam enviados, você deve primeiro habilitar esta opção na configuração principal da malha e, muito importante, renomear todas as portas das entidades de serviço do kubernetes, de acordo com o protocolo usado no serviço. Isto é, por exemplo, assim:
apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 name: http selector: app: nginx
Você também pode usar nomes compostos, como http-magic (o Istio vê http e reconhece essa porta como ponto de extremidade http). O formato é: proto-extra.
Para não corrigir um grande número de configurações para definir um protocolo, você pode usar uma solução alternativa suja: para corrigir um componente Pilot no momento em que ele apenas
executa a lógica de definição de protocolo . No final, é claro, você precisará alterar essa lógica para padrão e acessar a convenção de nomenclatura para todas as portas.
Para entender se o protocolo está realmente definido corretamente, você precisa acessar qualquer um dos contêineres laterais com o proxy envoy e fazer uma solicitação para a porta administrativa da interface do enviado com location / config_dump. Na configuração resultante, você precisa observar a operação de campo de serviço desejada. É usado no Istio como um identificador para onde a solicitação está indo. Para personalizar o valor desse parâmetro no Istio (nós o veremos em nosso sistema de rastreamento), é necessário especificar o sinalizador serviceCluster no estágio de lançamento do contêiner de side-car. Por exemplo, pode ser calculado desta forma a partir de variáveis obtidas nos kubernetes da API descendente:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')Um bom exemplo para entender como o rastreamento funciona no enviado está
aqui .
O próprio terminal para o envio de extensões de rastreamento também deve ser especificado nos sinalizadores de início do proxy enviado, por exemplo:
--zipkinAddress tracing-collector.tracing:9411Equívoco número dois: podemos obter de maneira barata as trilhas completas da passagem de solicitações para o sistema fora da caixa
Infelizmente, isso não é verdade. A complexidade da implementação depende de como você já implementou a interação dos serviços. Porque
O fato é que, para que o istio-proxy entenda a correspondência de solicitações recebidas de um serviço com aquelas provenientes do mesmo serviço, não basta interceptar todo o tráfego. Você precisa ter algum tipo de identificador de link. O proxy proxy do Envoy usa cabeçalhos especiais, segundo os quais o enviado entende qual solicitação de serviço específica gera solicitações específicas para outros serviços. Lista desses cabeçalhos:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- amostra x-b3,
- x-b3-flags,
- x-ot-span-context.
Se você tem um único ponto, por exemplo, um cliente base onde você pode adicionar essa lógica, tudo está bem, basta aguardar que todos os clientes atualizem essa biblioteca. Mas se você tiver um sistema muito heterogêneo e não houver unificação na campanha de serviços para serviços pela rede, isso provavelmente será um grande problema. Sem a adição dessa lógica, todas as informações de rastreamento serão apenas "irmãos". Ou seja, obtemos todas as interações entre serviços, mas elas não serão coladas em uma única cadeia de passagem pela rede.
Conclusão
O Istio fornece uma ferramenta conveniente para coletar informações de rastreamento na rede, no entanto, você deve entender que, para a implementação, será necessário adaptar seu sistema e levar em conta os recursos da implementação do Istio. Como resultado, você precisa resolver dois pontos principais: determinar o protocolo da camada de aplicativo (que deve ser suportado pelo proxy enviado) e configurar o encaminhamento de informações sobre a conectividade de solicitações ao serviço a partir de solicitações do serviço (usando cabeçalhos, no caso do protocolo HTTP). Quando esses problemas são resolvidos, obtemos uma ferramenta poderosa que permite coletar informações de forma transparente da rede, mesmo em sistemas muito heterogêneos, escritos em muitas linguagens e estruturas diferentes.
No próximo artigo sobre o Service Mesh, consideraremos um dos maiores problemas do Istio - alto consumo de memória de cada contêiner proxy lateral e discutiremos como lidar com ele.