Nota perev. : Dailymotion é um dos maiores serviços de hospedagem de vídeo do mundo e, portanto, um usuário notável do Kubernetes. Neste artigo, o arquiteto de sistema David Donchez compartilha os resultados da criação de uma plataforma de produção para a empresa baseada nos K8s, que começou com uma instalação em nuvem no GKE e terminou como uma solução híbrida, que permitiu obter melhor tempo de reação e economizar em custos de infraestrutura.Ao decidir reconstruir a API principal do
Dailymotion, três anos atrás, queríamos desenvolver uma maneira mais eficiente de hospedar aplicativos e facilitar
os processos de desenvolvimento e produção . Para esse fim, decidimos usar a plataforma de orquestração de contêineres e naturalmente escolhemos o Kubernetes.
Por que vale a pena criar sua própria plataforma baseada no Kubernetes?
API no nível da produção o mais rápido possível usando o Google Cloud
Verão de 2016
Três anos atrás, logo após a
Vivendi comprar o Dailymotion, nossas equipes de engenharia se concentraram em um objetivo global: criar um produto Dailymotion completamente novo.
Com base na análise de contêineres, soluções de orquestração e nossa experiência passada, garantimos que o Kubernetes é a escolha certa. Alguns desenvolvedores já tinham uma idéia dos conceitos básicos e sabiam usá-lo, o que era 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, a fim de construir com calma a plataforma local mais confiável. Eles decidiram implantar seus aplicativos usando o Google Kubernetes Engine, embora soubessem que mais cedo ou mais tarde mudaríamos para nossos próprios data centers e aplicaríamos uma estratégia híbrida.
Por que escolher o GKE?
Fizemos essa escolha principalmente por razões técnicas. Além disso, era necessário fornecer rapidamente a infraestrutura que atenda às necessidades dos negócios da empresa. Tínhamos alguns requisitos de aplicação, como distribuição geográfica, escalabilidade e tolerância a falhas.
Clusters GKE no DailymotionComo o Dailymotion é uma plataforma de vídeo disponível em todo o mundo, realmente queríamos melhorar a qualidade do serviço, reduzindo a
latência . Anteriormente,
nossa API estava disponível apenas em Paris, o que não era o ideal. Eu queria poder hospedar aplicativos não apenas na Europa, mas também na Ásia e nos Estados Unidos.
Essa sensibilidade a atrasos significava que teríamos que trabalhar seriamente na arquitetura de rede da plataforma. Enquanto a maioria dos serviços em nuvem os forçava a criar sua própria rede em cada região e depois conectá-los por meio de uma VPN ou de um determinado serviço gerenciado, o Google Cloud possibilitou a criação de uma rede unificada totalmente roteável, cobrindo todas as regiões do Google. Essa é uma grande vantagem em termos de operação e eficiência do sistema.
Além disso, os serviços de rede e os 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, no caso de uma falha, o tráfego irá automaticamente para outra região sem nenhuma intervenção humana.
Monitoramento de balanceamento de carga do GoogleNossa plataforma também usa ativamente processadores gráficos. O Google Cloud torna extremamente eficiente usá-los diretamente nos clusters do Kubernetes.
Naquela época, a equipe de infraestrutura se concentrava principalmente na pilha antiga implantada em servidores físicos. É por isso que o uso de um serviço gerenciado (incluindo os componentes principais do Kubernetes) atendeu aos nossos requisitos e nos permitiu treinar equipes no trabalho com clusters locais.
Como resultado, começamos a aceitar o tráfego de produção na infraestrutura do Google Cloud apenas 6 meses após o início do trabalho.
No entanto, apesar de várias vantagens, trabalhar com um provedor de nuvem está associado a certos custos, que podem aumentar dependendo da carga. É por isso que analisamos cuidadosamente cada serviço gerenciado usado, na esperança de implementá-los no local no futuro. De fato, a introdução de clusters locais começou no final de 2016 e, ao mesmo tempo, uma estratégia híbrida foi iniciada.
Lançamento da plataforma de orquestração de contêineres locais Dailymotion
Outono de 2016
Em condições em que toda a pilha estava pronta para produção e o trabalho na API
continuava , havia tempo para se concentrar nos clusters regionais.
Naquela época, os usuários assistiam a mais de 3 bilhões de vídeos por mês. Obviamente, temos administrado nossa própria rede de entrega de conteúdo ramificada há anos. Queríamos tirar proveito dessa circunstância e implantar clusters Kubernetes em data centers existentes.
A infraestrutura do Dailymotion totalizou mais de 2,5 mil servidores em seis data centers. Todos são configurados usando Saltstack. Começamos a preparar todas as receitas necessárias para a criação de nós principais e de trabalhadores, bem como um cluster etcd.
Parte da rede
Nossa rede é totalmente roteável. Cada servidor anuncia seu IP na rede usando o Exabgp. Comparamos vários plug-ins de rede e o
Calico era o único que satisfazia todas as necessidades (devido à abordagem usada no nível L3). Ele se encaixa perfeitamente no modelo de infraestrutura de rede existente.
Como eu queria usar todos os elementos de infraestrutura disponíveis, antes de tudo, tive que lidar com nosso utilitário de rede doméstico (usado em todos os servidores): use-o para anunciar intervalos de endereços IP em uma rede com nós do Kubernetes. Permitimos que o Calico atribua endereços IP a pods, mas não o utilizou e ainda não o usa para sessões BGP em equipamentos de rede. De fato, o roteamento é tratado 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, foi decidido usar o Ingress Controller devido à sua integração com os recursos de entrada do Kubernetes.
Há três anos, o nginx-ingress-controller era o controlador mais maduro: o Nginx é usado há muito tempo e é 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 terminal do kube-apiserver do cluster correspondente. O Exabgp também foi usado nesses servidores para anunciar endereços IP públicos ou privados. A topologia de nossa 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 os nós e melhora a eficiência.
O movimento do tráfego da Internet para podsAgora que você descobriu nossa plataforma híbrida, pode se aprofundar no processo de migração de tráfego.
Migrando o tráfego do Google Cloud para a infraestrutura Dailymotion
Outono 2018
Após quase dois anos de criação, teste e configuração, finalmente conseguimos uma pilha Kubernetes completa, pronta para receber parte do tráfego.
A atual estratégia de roteamento é bastante simples, mas satisfaz bastante as necessidades. Além do IP público (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 a rota 53Com o Google Cloud, é fácil, porque usamos um único IP para todos os clusters e o usuário é redirecionado para o cluster GKE mais próximo. A tecnologia é diferente para nossos clusters porque seus IPs são diferentes.
Durante a migração, procuramos redirecionar solicitações regionais para os respectivos clusters e avaliamos as vantagens dessa abordagem.
Como nossos clusters GKE são configurados para escalar automaticamente usando métricas personalizadas, eles aumentam / diminuem a potência, dependendo do tráfego recebido.
No modo normal, todo o tráfego regional é direcionado ao cluster local e o GKE serve como reserva em caso de problemas (as verificações de saúde são realizadas pela Rota 53).
...
No futuro, queremos automatizar completamente as políticas de roteamento para obter uma estratégia híbrida autônoma que melhore constantemente a acessibilidade do usuário. Quanto às vantagens: o custo da nuvem foi significativamente reduzido e até o tempo de resposta da API foi reduzido. Confiamos na plataforma de nuvem resultante e estamos prontos para redirecionar mais tráfego para ela, se necessário.
PS do tradutor
Talvez você também esteja interessado em outra publicação recente do Dailymotion sobre o Kubernetes. Ele é dedicado à implantação de aplicativos Helm em muitos clusters do Kubernetes e
foi publicado há cerca de um mês.
Leia também em nosso blog: