Observação. trad.: Dailymotion é um dos maiores serviços de hospedagem de vídeo do mundo e, portanto, um usuário notável do Kubernetes. Neste material, o arquiteto de sistemas David Donchez compartilha os resultados da criação da plataforma de produção da empresa baseada em K8s, que começou com uma instalação em nuvem no GKE e terminou como uma solução híbrida, que permitiu melhores tempos de resposta e economia em custos de infraestrutura.
Decidindo reconstruir a API principal há três anos, queríamos desenvolver uma maneira mais eficiente de hospedar aplicativos e facilitar . Para isso, decidimos utilizar uma plataforma de orquestração de containers e naturalmente escolhemos o Kubernetes.
Por que vale a pena construir sua própria plataforma baseada em Kubernetes?
API de nível de produção rapidamente usando o Google Cloud
Verão 2016
Três anos atrás, imediatamente após a compra do Dailymotion pela , nossas equipes de engenharia estão focadas em um objetivo global: criar um produto Dailymotion completamente novo.
Com base na nossa análise de containers, soluções de orquestração e na nossa experiência passada, estamos convencidos de que o Kubernetes é a escolha certa. Alguns desenvolvedores já entendiam os conceitos básicos e sabiam como utilizá-los, o que foi uma grande vantagem para a transformação da infraestrutura.
Do ponto de vista da infraestrutura, era necessário um sistema poderoso e flexível para hospedar novos tipos de aplicativos nativos da nuvem. Optamos por permanecer na nuvem no início de nossa jornada para que pudéssemos construir a plataforma local mais robusta possível com tranquilidade. Decidimos implantar nossos aplicativos usando o Google Kubernetes Engine, embora soubéssemos que mais cedo ou mais tarde mudaríamos para nossos próprios data centers e aplicaríamos uma estratégia híbrida.
Por que você escolheu o GKE?
Fizemos esta escolha principalmente por razões técnicas. Além disso, foi necessário disponibilizar rapidamente uma infraestrutura que atenda às necessidades de negócio da empresa. Tínhamos alguns requisitos para hospedagem de aplicações, como distribuição geográfica, escalabilidade e tolerância a falhas.
Clusters do GKE no Dailymotion
Como o Dailymotion é uma plataforma de vídeo disponível mundialmente, queríamos muito melhorar a qualidade do serviço reduzindo o tempo de espera (latência). mais cedo estava disponível apenas em Paris, o que era abaixo do ideal. Queria poder hospedar aplicações não só na Europa, mas também na Ásia e nos EUA.
Essa sensibilidade à latência significava que um trabalho sério teria que ser feito na arquitetura de rede da plataforma. Embora a maioria dos serviços em nuvem obrigue você a criar sua própria rede em cada região e depois conectá-las por meio de uma VPN ou algum tipo de serviço gerenciado, o Google Cloud permitiu que você criasse uma rede única totalmente roteável cobrindo todas as regiões do Google. Esta é uma grande vantagem em termos de operação e eficiência do sistema.
Além disso, os serviços de rede e balanceadores de carga do Google Cloud fazem um excelente trabalho. Eles simplesmente permitem que você use endereços IP públicos arbitrários de cada região, e o maravilhoso protocolo BGP cuida do resto (ou seja, redireciona os usuários para o cluster mais próximo). Obviamente, em caso de falha, o tráfego irá automaticamente para outra região sem qualquer intervenção humana.
Monitorando o balanceamento de carga do Google
Nossa plataforma também faz uso intenso de GPUs. O Google Cloud permite que você os use de forma muito eficaz diretamente em clusters Kubernetes.
Na época, a equipe de infraestrutura estava focada principalmente na pilha legada implantada em servidores físicos. É por isso que o uso de um serviço gerenciado (incluindo mestres Kubernetes) atendeu aos nossos requisitos e nos permitiu treinar equipes para trabalhar com clusters locais.
Como resultado, conseguimos começar a receber tráfego de produção na infraestrutura do Google Cloud apenas 6 meses após o início dos trabalhos.
No entanto, apesar de uma série de vantagens, trabalhar com um fornecedor de cloud está associado a determinados custos, que podem aumentar dependendo da carga. É por isso que analisamos cuidadosamente cada serviço gerenciado que utilizamos, na esperança de implementá-los localmente no futuro. Na verdade, a implementação de clusters locais começou no final de 2016 e a estratégia híbrida foi iniciada ao mesmo tempo.
Lançamento da plataforma de orquestração de contêineres locais Dailymotion
Outono '2016
Em condições em que toda a pilha estava pronta para produção e trabalhando na API , era altura de nos concentrarmos nos clusters regionais.
Naquela época, os usuários assistiam a mais de 3 bilhões de vídeos todos os meses. É claro que temos nossa própria extensa rede de distribuição de conteúdo há muitos anos. Queríamos aproveitar essa circunstância e implantar clusters Kubernetes em data centers existentes.
A infraestrutura do Dailymotion era composta por mais de 2,5 mil servidores em seis data centers. Todos eles são configurados usando Saltstack. Começamos a preparar todas as receitas necessárias para a criação de nós mestres e de trabalho, bem como um cluster etcd.
Parte da rede
Nossa rede está completamente roteada. Cada servidor anuncia seu IP na rede usando Exabgp. Comparamos vários plugins de rede e o único que satisfez todas as necessidades (devido à abordagem L3 utilizada) foi . Ele se encaixa perfeitamente no modelo de infraestrutura de rede existente.
Como queríamos usar todos os elementos de infraestrutura disponíveis, a primeira coisa que tivemos que fazer foi descobrir nosso utilitário de rede local (usado em todos os servidores): usá-lo para anunciar intervalos de endereços IP na rede com nós Kubernetes. Permitimos que o Calico atribuísse endereços IP aos pods, mas não o usamos e ainda não o usamos para sessões BGP em equipamentos de rede. Na verdade, o roteamento é feito pelo Exabgp, que anuncia as sub-redes usadas pelo Calico. Isso nos permite acessar qualquer pod da rede interna (e em particular dos balanceadores de carga).
Como gerenciamos o tráfego de entrada
Para redirecionar as solicitações recebidas para o serviço desejado, optou-se pela utilização do Ingress Controller devido à sua integração com os recursos de entrada do Kubernetes.
Três anos atrás, o nginx-ingress-controller era o controlador mais maduro: o Nginx já existia há muito tempo e era conhecido por sua estabilidade e desempenho.
Em nosso sistema, decidimos colocar os controladores em servidores blade dedicados de 10 Gigabits. Cada controlador foi conectado ao endpoint kube-apiserver do cluster correspondente. Esses servidores também usaram o Exabgp para anunciar endereços IP públicos ou privados. Nossa topologia de rede nos permite usar o BGP desses controladores para rotear todo o tráfego diretamente para os pods sem usar um serviço como o NodePort. Essa abordagem ajuda a evitar o tráfego horizontal entre nós e melhora a eficiência.
Movimento de tráfego da Internet para pods
Agora que entendemos nossa plataforma híbrida, podemos nos aprofundar no próprio processo de migração de tráfego.
Migração de tráfego do Google Cloud para infraestrutura do Dailymotion
Outono '2018
Depois de quase dois anos de construção, testes e ajustes, finalmente temos uma pilha completa do Kubernetes pronta para aceitar algum tráfego.
A estratégia de roteamento atual é bastante simples, mas suficiente para atender às necessidades. Além dos IPs públicos (no Google Cloud e Dailymotion), o AWS Route 53 é usado para definir políticas e redirecionar usuários para o cluster de nossa escolha.
Exemplo de política de roteamento usando Route 53
Com o Google Cloud isso é fácil, pois compartilhamos um único IP em todos os clusters e o usuário é redirecionado para o cluster do GKE mais próximo. Para nossos clusters a tecnologia é diferente, pois seus IPs são diferentes.
Durante a migração, procuramos redirecionar as solicitações regionais para os clusters apropriados e avaliamos os benefícios desta abordagem.
Como nossos clusters do GKE são configurados para escalonamento automático usando métricas personalizadas, eles aumentam/reduzem com base no tráfego de entrada.
No modo normal, todo o tráfego regional é direcionado para o cluster local, e o GKE serve como reserva em caso de problemas (os exames de saúde são realizados pela Rota 53).
...
No futuro, queremos automatizar totalmente as políticas de roteamento para alcançar uma estratégia híbrida autônoma que melhore continuamente a acessibilidade dos usuários. Do lado positivo, os custos da nuvem foram significativamente reduzidos e os tempos de resposta da API foram reduzidos. Confiamos na plataforma de nuvem resultante e estamos prontos para redirecionar mais tráfego para ela, se necessário.
PS do tradutor
Você também pode estar interessado em outra postagem recente do Dailymotion sobre Kubernetes. É dedicado à implantação de aplicativos com Helm em muitos clusters Kubernetes e mais ou menos um mês atrás.
Leia também em nosso blog:
- «".
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «".
Fonte: habr.com