Usamos o envoy como um proxy de ponta que redireciona o tráfego de entrada para vários clusters kubernetes (para novos serviços) e para os back-ends da arquitetura legada do patrimônio histórico. Aqueles. ele combina as funções de um balanceador comum e ponto de terminação SSL e gateway de API.
Antes do enviado, tínhamos nginx lá, como muitos outros. Software legal, eu gosto. Toda a história com o envoy começou no momento em que os microsserviços começaram em grande número e até mesmo os modelos ansible não o salvaram do aumento do tempo gasto no gerenciamento da configuração do nginx. Levou muito tempo para implantar, além disso, os administradores foram desencorajados de solicitações monótonas como "consiga um domínio para um novo serviço". A automação Better ™ era claramente necessária. Idealmente, para que quem precisa iniciar algo possa fazê-lo sozinho e de preferência no mesmo local onde configurou outros parâmetros do seu serviço. Além disso, eu queria mais transparência no que acontece dentro do proxy frontal e no segmento entre ele e os upstreams, e mais recursos de balanceamento nativos (solicitações repetitivas de diferentes tipos, exclusão de hosts não íntegros sob certas condições, verificações de ajuda). E atraiu tecnologia de ponta,é claro.
Resumindo, aqui está uma tradução do artigo sobre a transição do Dropbox para o enviado, há muitos detalhes sobre sua comparação com o nginx. Contarei mais sobre as impressões pessoais dos resultados da transição.
O fato mais importante e óbvio para quem já conhece o uso de software escalável: esteja preparado para pagar por isso. O aumento da complexidade da configuração (plano de dados + plano de controle), e se houver upstreams não apenas no kubernetes, talvez até mesmo escrevendo seu próprio plano de controle. Além disso, no caso do enviado especificamente, pela relativa juventude do software e, portanto, pela ausência de alguns recursos comuns do nginx + um aumento na frequência de atualizações, se esses recursos forem adicionados a eles. Por exemplo, pode acontecer que nas opções padrão não haja um padrão para nginx combinando barras em: path, removendo a porta do cabeçalho do Host ou, Deus me perdoe, reescrita por regexp. Por hoje, tudo desta lista já foi adicionado, mas você certamente encontrará outra coisa.
Coisas positivas
Documentação horrível! Do lado positivo, a equipe do enviado finalmente contratou um redator de tecnologia no final do ano passado e as coisas se tornaram muito mais amigáveis. No mínimo, você não precisa mais estudar a forma de processar uma solicitação através do código-fonte e encontrar uma descrição do trabalho de algumas opções exclusivamente nas respostas do seu problema. E para encontrar as opções por si mesmas, seja um google master de nível 80. Agora, muito disso está no passado, embora os autores ainda não se preocupem em marcar em qual versão do enviado esta ou aquela opção apareceu, ou por links para o problema nas notas de lançamento, mas pelo menos eles começaram a destacar a lista de mudanças significativas em lançamentos em uma seção dedicada, você pode ver que há progresso.
Telemetria estendida
Aqui todas as esperanças foram justificadas, agora nosso painel grafana do enviado mata todos os navegadores que não estão preparados com uma série de gráficos. Mas, falando sério, agora você pode monitorar convenientemente o que está acontecendo com o tráfego em todos os estágios de sua passagem. Isso ajuda especialmente em histórias de detetive emocionantes - investigações após incidentes. E, claro, a definição de anomalias.
Anomalia: "Olá". Um fragmento do painel do mesmo enviado grafana.
Avião de controle
Bem, e o mais importante, para o qual tudo foi iniciado, resolvemos o problema do controle automático de rota. Duas palavras sobre a abordagem, se alguém não estiver no assunto: o plano de controle funciona como um controlador de dados, gerencia seu armazenamento e cria um config, que é então enviado ao enviado (plano de dados sem estado).
Se você tiver apenas um kubernetes como back-end, poderá usar um plano de controle pronto do tipo embaixador. Mas tínhamos que gerenciar a infraestrutura antiga também, além de haver vários clusters. Então, eu tive que pegar uma das implementações de API de plano de dados propostas pelo projeto enviado e bagunçar todos os recursos de que precisamos, conectando esta parte da infraestrutura com automação no kubernetes, mas este é um tópico para outra história interessante.
Impressões do processo de mudança para enviado - "por alguma razão, não houve problemas especiais, muito suspeitos."
Resumindo, por onde começar e para o que estar pronto imediatamente. Depois de meditar sobre a documentação do enviado e aceitar a futilidade da existência, pegamos dois hosts virtuais do antigo front proxy (o mais simples e mais típico, e o mais extenso), os iniciamos no enviado, escolhendo as opções ao longo do caminho.
A principal coisa a ter em mente aqui é que as abordagens para escrever configurações entre o nginx e o envoy são muito diferentes, ou seja, devemos estar preparados para curvas bruscas do formulário: em vez de duas entradas simples de permitir / negar, escrevemos 26 linhas da árvore de regras RBAC. Em geral, aceitar que uma pequena explosão aqui é normal, já que a configuração do enviado é feita com prioridade na conveniência da automação, e não na legibilidade humana.
Você pode precisar montar uma folha de dicas para o mapeamento de opções e certificar-se de que eles realmente façam o que você pensa que fazem. Certa vez, chegamos à conclusão de que o mecanismo de combinação de barras no URL (mesmo quando já foi adicionado ao enviado) funciona de forma diferente: no nginx não mudou: o caminho, que foi enviado para o upstream, e no enviado, um completo a reescrita ocorreu e tudo ficaria bem, mas com essa reescrita, surgiu um bug que mudou: caminho completamente para o jogo, bem, em geral, depois do nosso problema também foi corrigido, mas tome cuidado.
A propósito, sobre os problemas - não posso deixar de mencionar mais uma impressão positiva.
Comunidade amigável e desenvolvedores
Como o envoy é um código aberto hospedado por CNCF, tradicionalmente você pode simplesmente entrar no GitHub do projeto e sugerir sua melhoria ou fazer uma pergunta. Os problemas são um número selvagem, os desenvolvedores claramente não têm mãos suficientes, mas ao mesmo tempo, a pior coisa que pode acontecer com a sua pergunta é que ela seja ignorada. Embora na maioria das vezes, pelo menos alguma coisa, mas eles respondem, mesmo que seja algo curto no espírito de "desculpe, não planejamos fazer isso." Sem toxicidade, mesmo que perguntas de novatos, atmosfera muito amigável.
Tópicos atmosféricos, especialmente corgis. Captura de tela do repositório público enviado em github.com
Bem, como de costume - solicitações pull são bem-vindas. Eles ajudam mesmo aqueles que não são particularmente bons em C ++. Existem também vários problemas marcados com a tag de iniciante, caso alguém queira contribuir e não saiba por onde começar.
Além do GitHub, também há boletins informativos por e-mail e folga, mas o último costuma ser uma bagunça. :)
Dos eventos, realiza-se a EnvoyCon, que, no entanto, já está online, mas ainda assim recomendo.
Resultado
Em geral, você não precisa de enviado apenas porque é moderno e jovem, "todo mundo passa por cima" e o fundador tem um penteado engraçado. Fique onde estava até apertar. Se você tem uma startup ou apenas um projeto pequeno, é definitivamente melhor deixar o nginx, porque é simples e fofo. O principal é começar por aí.
Se houver muitos serviços, muitos desenvolvedores, existem kubernetes e todas as compensações no artigo acima não o incomodam - você pode pensar e tentar.
Boa sorte e talvez até a EnvoyCon!