Nota do tradutor.: 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 com base no K8s, que começou como uma instalação em nuvem no GKE e terminou como uma solução híbrida, permitindo obter melhor tempo de resposta e economizar em custos de infraestrutura.
Ao tomar a decisão de reestruturar a API principal três anos atrás, queríamos desenvolver uma maneira mais eficiente de implantar aplicações e facilitar Para isso, decidimos usar uma plataforma de orquestração de contêineres e naturalmente escolhemos o Kubernetes.
Por que vale a pena criar uma plataforma própria baseada em Kubernetes?
API de nível de produção em tempo recorde com a ajuda do Google Cloud
Summer 2016
Três anos atrás, logo após a aquisição do Dailymotion pela , nossas equipes de engenharia se concentraram em um único objetivo global: criar um produto totalmente novo da Dailymotion.
Após uma análise de contêineres, soluções de orquestração e nossa experiência anterior, percebemos que o Kubernetes era a escolha certa. Parte dos desenvolvedores já tinha familiaridade com os conceitos básicos e sabia como usá-lo, o que foi uma grande vantagem para a transformação da infraestrutura.
Em termos de infraestrutura, era necessária uma sistema potente e flexível para a hospedagem de novos tipos de aplicações cloud-native. Optamos por permanecer na nuvem no início de nossa jornada para construir uma plataforma local o mais confiável possível. Decidimos implantar nossas aplicações usando o Google Kubernetes Engine, embora soubéssemos que, mais cedo ou mais tarde, mudaríamos para nossos próprios datacenters e aplicaríamos uma estratégia híbrida.
Por que escolhemos o GKE?
Tomamos essa decisão principalmente por razões técnicas. Além disso, era necessário fornecer rapidamente uma infraestrutura que atendesse às necessidades comerciais da empresa. Tínhamos alguns requisitos para a implantação de aplicações, como distribuição geográfica, escalabilidade e resiliência.
Clusters GKE na Dailymotion
Como o Dailymotion é uma plataforma de vídeo acessível em todo o mundo, estávamos muito motivados a melhorar a qualidade do serviço, reduzindo o tempo de espera. (latência)Antes, estava disponível apenas em Paris, o que era subótimo. Gostaria de poder implantar aplicativos não apenas na Europa, mas também na Ásia e nos EUA.
Essa sensibilidade à latência significou que teríamos que trabalhar seriamente na arquitetura de rede da plataforma. Enquanto a maioria dos serviços em nuvem forçava a criação de sua própria rede em cada região e depois conectá-las através de VPN ou algum serviço gerenciado, o Google Cloud permitia a criação de uma única rede totalmente roteável, abrangendo todas as regiões do Google. Isso é 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 funcionam perfeitamente. Eles simplesmente permitem que você utilize 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). É evidente que, em caso de falha, o tráfego será automaticamente redirecionado para outra região sem qualquer intervenção humana.
Monitoramento de balanceamento de carga no Google
Nossa plataforma também utiliza ativamente GPUs. O Google Cloud permite usá-las de forma bastante eficiente diretamente em clusters Kubernetes.
Na época, a equipe de infraestrutura se concentrava principalmente na antiga pilha implantada em servidores físicos. Foi por isso que o uso de serviços gerenciados (incluindo componentes mestres do Kubernetes) atendia às nossas necessidades e permitia treinar as equipes para trabalhar com clusters locais.
Como resultado, conseguimos começar a aceitar tráfego de produção na infraestrutura do Google Cloud apenas seis meses após o início do trabalho.
No entanto, apesar de uma série de vantagens, trabalhar com um provedor de nuvem acarreta certos custos, que podem aumentar dependendo da carga. É por isso que analisamos cuidadosamente cada serviço gerenciado utilizado, planejando implementar esses serviços no local no futuro. Na verdade, a implementação de clusters locais começou no final de 2016 e, na mesma época, foi iniciada uma estratégia híbrida.
Lançamento da plataforma local de orquestração de contêineres Dailymotion
Outono de 2016
Em condições em que toda a pilha estava pronta para produção, e o trabalho com a API , era hora de se concentrar nos clusters regionais.
Naquele momento, os usuários visualizavam mais de 3 bilhões de vídeos mensalmente. Certamente, nossa própria e extensa Rede de Distribuição de Conteúdo já estava em funcionamento há vários anos. Queríamos aproveitar essa circunstância e implantar clusters Kubernetes nos Data Centers existentes.
A infraestrutura do Dailymotion contava com mais de 2,5 mil servidores distribuídos em seis data centers. Todos eles são configurados usando Saltstack. Começamos a preparar todas as receitas necessárias para criar os nós mestres e workers, bem como o cluster etcd.
Parte de rede
Nossa rede é completamente roteável. Cada servidor anuncia seu IP na rede usando Exabgp. Comparamos vários plugins de rede e o único que atendia a todas as necessidades (devido à abordagem usada no nível L3) foi . Ele se integrou perfeitamente ao modelo de rede existente da infraestrutura.
Como desejávamos utilizar todos os elementos disponíveis da infraestrutura, precisávamos antes de tudo entender nossa ferramenta de rede caseira (usada em todos os servidores): usá-la para anunciar faixas de endereços IP na rede com os nós Kubernetes. Permitimos que o Calico atribuísse endereços IP aos pods, mas não o utilizamos e até hoje não o usamos para sessões BGP no equipamento de rede. Na verdade, a roteamento é feito pelo Exabgp, que anuncia as sub-redes usadas pelo Calico. Isso nos permite acessar qualquer pod da rede interna (em particular, a partir dos balanceadores de carga).
Como gerenciamos o tráfego de ingress
Para redirecionar as solicitações de entrada para o serviço apropriado, decidimos usar o Ingress Controller devido à sua integração com os recursos de ingress do Kubernetes.
Três anos atrás, o nginx-ingress-controller era o controlador mais maduro: O Nginx já estava em uso há bastante tempo e era conhecido por sua estabilidade e desempenho.
Em nosso sistema, decidimos alocar controladores em servidores blade dedicados de 10 gigabits. Cada controlador se conectava ao endpoint do kube-apiserver do respectivo cluster. Esses servidores também usavam Exabgp para anunciar endereços IP públicos ou privados. A topologia da nossa rede permite usar BGP desses controladores para rotear todo o tráfego diretamente para os pods, sem usar serviços como NodePort. Essa abordagem ajuda a evitar o tráfego horizontal entre os nós e aumenta a eficiência.
Tráfego da internet para os pods
Agora que entendemos nossa plataforma híbrida, podemos nos aprofundar no processo de migração de tráfego.
Migração de tráfego do Google Cloud para a infraestrutura do Dailymotion
Outono de 2018
Após quase dois anos de criação, teste e configuração, finalmente temos uma pilha completa de Kubernetes pronta para receber parte do tráfego.
A estratégia atual de roteamento é bastante simples, mas atende bem às necessidades. Além de IPs públicos (no Google Cloud e no Dailymotion), utilizamos o AWS Route 53 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 utilizamos um único IP para todos os clusters e o usuário é redirecionado para o cluster GKE mais próximo. Para nossos clusters, a tecnologia é diferente, pois seus IPs são distintos.
Durante a migração, buscamos redirecionar solicitações regionais para os clusters correspondentes e avaliamos os benefícios dessa abordagem.
Uma vez que nossos clusters GKE estão configurados para escalonamento automático usando Métricas Personalizadas, eles aumentam/reduzem a capacidade com base no tráfego de entrada.
No modo normal, todo o tráfego regional é direcionado ao cluster local, enquanto o GKE serve como reserva em caso de problemas (os health checks são realizados pelo Route 53).
…
No futuro, queremos automatizar completamente as políticas de roteamento para ter uma estratégia híbrida autônoma que melhore continuamente a disponibilidade para os usuários. Em termos de vantagens: os custos com nuvem diminuíram significativamente e conseguimos até reduzir o tempo de resposta da API. Confiamos na plataforma de nuvem resultante e estamos prontos para redirecionar mais tráfego para ela, se necessário.
P.S. do tradutor
Você também pode estar interessado em outra publicação recente do Dailymotion sobre Kubernetes. Ela aborda a implantação de aplicações com Helm em múltiplos clusters Kubernetes e cerca de um mês atrás.
Confira também em nosso blog:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
