{"id":36484,"date":"2019-10-31T22:11:54","date_gmt":"2019-10-31T19:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises\/"},"modified":"2019-10-31T22:11:54","modified_gmt":"2019-10-31T19:11:54","slug":"kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Aventura com Kubernetes na Dailymotion: criando infraestrutura nas nuvens + no local","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Aventura
\n
\nNota do tradutor.<\/b>: Dailymotion \u2014 um dos maiores servi\u00e7os de hospedagem de v\u00eddeo do mundo e, portanto, um usu\u00e1rio not\u00e1vel do Kubernetes. Neste material, o arquiteto de sistemas David Donchez compartilha os resultados da cria\u00e7\u00e3o da plataforma de produ\u00e7\u00e3o da empresa com base no K8s, que come\u00e7ou como uma instala\u00e7\u00e3o em nuvem no GKE e terminou como uma solu\u00e7\u00e3o h\u00edbrida, permitindo obter melhor tempo de resposta e economizar em custos de infraestrutura.<\/i><\/p>\n

Ao tomar a decis\u00e3o de reestruturar a API principal Dailymotion<\/a><\/noindex> tr\u00eas anos atr\u00e1s, quer\u00edamos desenvolver uma maneira mais eficiente de implantar aplica\u00e7\u00f5es e facilitar os processos de desenvolvimento e produ\u00e7\u00e3o.<\/a><\/noindex>Para isso, decidimos usar uma plataforma de orquestra\u00e7\u00e3o de cont\u00eaineres e naturalmente escolhemos o Kubernetes.<\/p>\n

Por que vale a pena criar uma plataforma pr\u00f3pria baseada em Kubernetes?<\/a><\/noindex><\/p>\n

API de n\u00edvel de produ\u00e7\u00e3o em tempo recorde com a ajuda do Google Cloud<\/h2>\n

<\/p>\n

Summer 2016<\/p><\/blockquote>\n

\nTr\u00eas anos atr\u00e1s, logo ap\u00f3s a aquisi\u00e7\u00e3o do Dailymotion pela Vivendi,<\/a><\/noindex>, nossas equipes de engenharia se concentraram em um \u00fanico objetivo global: criar um produto totalmente novo da Dailymotion.<\/p>\n

Ap\u00f3s uma an\u00e1lise de cont\u00eaineres, solu\u00e7\u00f5es de orquestra\u00e7\u00e3o e nossa experi\u00eancia anterior, percebemos que o Kubernetes era a escolha certa. Parte dos desenvolvedores j\u00e1 tinha familiaridade com os conceitos b\u00e1sicos e sabia como us\u00e1-lo, o que foi uma grande vantagem para a transforma\u00e7\u00e3o da infraestrutura.<\/p>\n

Em termos de infraestrutura, era necess\u00e1ria uma sistema potente e flex\u00edvel para a hospedagem de novos tipos de aplica\u00e7\u00f5es cloud-native. Optamos por permanecer na nuvem no in\u00edcio de nossa jornada para construir uma plataforma local o mais confi\u00e1vel poss\u00edvel. Decidimos implantar nossas aplica\u00e7\u00f5es usando o Google Kubernetes Engine, embora soub\u00e9ssemos que, mais cedo ou mais tarde, mudar\u00edamos para nossos pr\u00f3prios datacenters e aplicar\u00edamos uma estrat\u00e9gia h\u00edbrida.<\/p>\n

Por que escolhemos o GKE?<\/h3>\n

\nTomamos essa decis\u00e3o principalmente por raz\u00f5es t\u00e9cnicas. Al\u00e9m disso, era necess\u00e1rio fornecer rapidamente uma infraestrutura que atendesse \u00e0s necessidades comerciais da empresa. T\u00ednhamos alguns requisitos para a implanta\u00e7\u00e3o de aplica\u00e7\u00f5es, como distribui\u00e7\u00e3o geogr\u00e1fica, escalabilidade e resili\u00eancia.<\/p>\n

\"Aventura
\nClusters GKE na Dailymotion<\/i><\/p>\n

Como o Dailymotion \u00e9 uma plataforma de v\u00eddeo acess\u00edvel em todo o mundo, est\u00e1vamos muito motivados a melhorar a qualidade do servi\u00e7o, reduzindo o tempo de espera. (lat\u00eancia)<\/i>Antes, nossa API<\/a><\/noindex> estava dispon\u00edvel apenas em Paris, o que era sub\u00f3timo. Gostaria de poder implantar aplicativos n\u00e3o apenas na Europa, mas tamb\u00e9m na \u00c1sia e nos EUA.<\/p>\n

Essa sensibilidade \u00e0 lat\u00eancia significou que ter\u00edamos que trabalhar seriamente na arquitetura de rede da plataforma. Enquanto a maioria dos servi\u00e7os em nuvem for\u00e7ava a cria\u00e7\u00e3o de sua pr\u00f3pria rede em cada regi\u00e3o e depois conect\u00e1-las atrav\u00e9s de VPN ou algum servi\u00e7o gerenciado, o Google Cloud permitia a cria\u00e7\u00e3o de uma \u00fanica rede totalmente rote\u00e1vel, abrangendo todas as regi\u00f5es do Google. Isso \u00e9 uma grande vantagem em termos de opera\u00e7\u00e3o e efici\u00eancia do sistema.<\/p>\n

Al\u00e9m disso, os servi\u00e7os de rede e balanceadores de carga do Google Cloud funcionam perfeitamente. Eles simplesmente permitem que voc\u00ea utilize endere\u00e7os IP p\u00fablicos arbitr\u00e1rios de cada regi\u00e3o, e o maravilhoso protocolo BGP cuida do resto (ou seja, redireciona os usu\u00e1rios para o cluster mais pr\u00f3ximo). \u00c9 evidente que, em caso de falha, o tr\u00e1fego ser\u00e1 automaticamente redirecionado para outra regi\u00e3o sem qualquer interven\u00e7\u00e3o humana.<\/p>\n

\"Aventura
\nMonitoramento de balanceamento de carga no Google<\/i><\/p>\n

Nossa plataforma tamb\u00e9m utiliza ativamente GPUs. O Google Cloud permite us\u00e1-las de forma bastante eficiente diretamente em clusters Kubernetes.<\/p>\n

Na \u00e9poca, a equipe de infraestrutura se concentrava principalmente na antiga pilha implantada em servidores f\u00edsicos. Foi por isso que o uso de servi\u00e7os gerenciados (incluindo componentes mestres do Kubernetes) atendia \u00e0s nossas necessidades e permitia treinar as equipes para trabalhar com clusters locais.<\/p>\n

Como resultado, conseguimos come\u00e7ar a aceitar tr\u00e1fego de produ\u00e7\u00e3o na infraestrutura do Google Cloud apenas seis meses ap\u00f3s o in\u00edcio do trabalho.<\/p>\n

No entanto, apesar de uma s\u00e9rie de vantagens, trabalhar com um provedor de nuvem acarreta certos custos, que podem aumentar dependendo da carga. \u00c9 por isso que analisamos cuidadosamente cada servi\u00e7o gerenciado utilizado, planejando implementar esses servi\u00e7os no local no futuro. Na verdade, a implementa\u00e7\u00e3o de clusters locais come\u00e7ou no final de 2016 e, na mesma \u00e9poca, foi iniciada uma estrat\u00e9gia h\u00edbrida.<\/p>\n

Lan\u00e7amento da plataforma local de orquestra\u00e7\u00e3o de cont\u00eaineres Dailymotion<\/h2>\n

<\/p>\n

Outono de 2016<\/p><\/blockquote>\n

\nEm condi\u00e7\u00f5es em que toda a pilha estava pronta para produ\u00e7\u00e3o, e o trabalho com a API continuava<\/a><\/noindex>, era hora de se concentrar nos clusters regionais.<\/p>\n

Naquele momento, os usu\u00e1rios visualizavam mais de 3 bilh\u00f5es de v\u00eddeos mensalmente. Certamente, nossa pr\u00f3pria e extensa Rede de Distribui\u00e7\u00e3o de Conte\u00fado j\u00e1 estava em funcionamento h\u00e1 v\u00e1rios anos. Quer\u00edamos aproveitar essa circunst\u00e2ncia e implantar clusters Kubernetes nos Data Centers existentes.<\/p>\n

A infraestrutura do Dailymotion contava com mais de 2,5 mil servidores distribu\u00eddos em seis data centers. Todos eles s\u00e3o configurados usando Saltstack. Come\u00e7amos a preparar todas as receitas necess\u00e1rias para criar os n\u00f3s mestres e workers, bem como o cluster etcd.<\/p>\n

\"Aventura
\n<\/p>\n

Parte de rede<\/h3>\n

\nNossa rede \u00e9 completamente rote\u00e1vel. Cada servidor anuncia seu IP na rede usando Exabgp. Comparamos v\u00e1rios plugins de rede e o \u00fanico que atendia a todas as necessidades (devido \u00e0 abordagem usada no n\u00edvel L3) foi Calico<\/a><\/noindex>. Ele se integrou perfeitamente ao modelo de rede existente da infraestrutura.<\/p>\n

Como quer\u00edamos usar todos os elementos da infraestrutura dispon\u00edveis, foi fundamental entender nossa pr\u00f3pria ferramenta de rede (utilizada em todos os servidores): utiliz\u00e1-la para anunciar os intervalos de endere\u00e7os IP na rede com os n\u00f3s do Kubernetes. Permitimos que o Calico atribu\u00edsse endere\u00e7os IP aos pods, mas n\u00e3o a utilizamos e ainda n\u00e3o a utilizamos para sess\u00f5es BGP no equipamento de rede. De fato, a rotea\u00e7\u00e3o \u00e9 realizada pelo Exabgp, que anuncia as sub-redes utilizadas pelo Calico. Isso nos permite acessar qualquer pod a partir da rede interna (especialmente dos balanceadores de carga).<\/p>\n

Como gerenciamos o tr\u00e1fego de ingress<\/h3>\n

\nPara redirecionar as solicita\u00e7\u00f5es de entrada para o servi\u00e7o apropriado, decidimos usar o Ingress Controller devido \u00e0 sua integra\u00e7\u00e3o com os recursos de ingress do Kubernetes.<\/p>\n

Tr\u00eas anos atr\u00e1s, o nginx-ingress-controller era o controlador mais maduro: O Nginx j\u00e1 estava em uso h\u00e1 bastante tempo e era conhecido por sua estabilidade e desempenho.<\/p>\n

Em nosso sistema, decidimos colocar os controladores em servidores blade dedicados de 10 gigabits. Cada controlador estava conectado ao endpoint do kube-apiserver do respectivo cluster. Nestes servidores, o Exabgp tamb\u00e9m era usado para anunciar endere\u00e7os IP p\u00fablicos ou privados. A topologia de nossa rede permite que utilizemos o BGP desses controladores para rotear todo o tr\u00e1fego diretamente para os pods, sem a utiliza\u00e7\u00e3o de servi\u00e7os do tipo NodePort. Essa abordagem ajuda a evitar o tr\u00e1fego horizontal entre os n\u00f3s e aumenta a efici\u00eancia.<\/p>\n

\"Aventura
\nTr\u00e1fego da internet para os pods<\/i><\/p>\n

Agora que entendemos nossa plataforma h\u00edbrida, podemos nos aprofundar no processo de migra\u00e7\u00e3o de tr\u00e1fego.<\/p>\n

Migra\u00e7\u00e3o de tr\u00e1fego do Google Cloud para a infraestrutura do Dailymotion<\/h2>\n

<\/p>\n

Outono de 2018<\/p><\/blockquote>\n

\nAp\u00f3s quase dois anos de cria\u00e7\u00e3o, teste e configura\u00e7\u00e3o, finalmente temos uma pilha completa de Kubernetes pronta para receber parte do tr\u00e1fego.<\/p>\n

\"Aventura
\n
\nA estrat\u00e9gia atual de roteamento \u00e9 bastante simples, mas atende bem \u00e0s necessidades. Al\u00e9m de IPs p\u00fablicos (no Google Cloud e no Dailymotion), utilizamos o AWS Route 53 para definir pol\u00edticas e redirecionar usu\u00e1rios para o cluster de nossa escolha.<\/p>\n

\"Aventura
\nExemplo de pol\u00edtica de roteamento usando Route 53<\/i><\/p>\n

Com o Google Cloud, isso \u00e9 f\u00e1cil, pois utilizamos um \u00fanico IP para todos os clusters e o usu\u00e1rio \u00e9 redirecionado para o cluster GKE mais pr\u00f3ximo. Para nossos clusters, a tecnologia \u00e9 diferente, pois seus IPs s\u00e3o distintos.<\/p>\n

Durante a migra\u00e7\u00e3o, buscamos redirecionar solicita\u00e7\u00f5es regionais para os clusters correspondentes e avaliamos os benef\u00edcios dessa abordagem.<\/p>\n

Uma vez que nossos clusters GKE est\u00e3o configurados para escalonamento autom\u00e1tico usando M\u00e9tricas Personalizadas, eles aumentam\/reduzem a capacidade com base no tr\u00e1fego de entrada.<\/p>\n

Em condi\u00e7\u00f5es normais, todo o tr\u00e1fego regional \u00e9 direcionado ao cluster local, enquanto o GKE serve como um backup em caso de problemas (check-ups de sa\u00fade s\u00e3o realizados pelo Route 53).<\/p>\n

\u2026<\/h2>\n

\nNo futuro, queremos automatizar completamente as pol\u00edticas de roteamento para ter uma estrat\u00e9gia h\u00edbrida aut\u00f4noma que melhore continuamente a disponibilidade para os usu\u00e1rios. Em termos de vantagens: os custos com nuvem diminu\u00edram significativamente e conseguimos at\u00e9 reduzir o tempo de resposta da API. Confiamos na plataforma de nuvem resultante e estamos prontos para redirecionar mais tr\u00e1fego para ela, se necess\u00e1rio.<\/p>\n

P.S. do tradutor<\/h2>\n

\nVoc\u00ea tamb\u00e9m pode estar interessado em outra publica\u00e7\u00e3o recente do Dailymotion sobre Kubernetes. Ela aborda a implanta\u00e7\u00e3o de aplica\u00e7\u00f5es com Helm em m\u00faltiplos clusters Kubernetes e foi publicado<\/a><\/noindex> cerca de um m\u00eas atr\u00e1s.<\/p>\n

Confira tamb\u00e9m em nosso blog:<\/p>\n