Neste artigo, descreverei nossa experiência de migração do Preply para o Kubernetes, como e por que fizemos isso, quais dificuldades encontramos e quais vantagens obtivemos.
Kubernetes para Kubernetes? Não, requisitos de negócios!
Em torno de Kubernetes, há muita publicidade e por boas razões. Muitas pessoas dizem que isso resolverá todos os problemas, algumas dizem que provavelmente você não precisa do Kubernetes . A verdade, é claro, está algures no meio.
No entanto, todas essas discussões sobre onde e quando o Kubernetes é necessário merecem um artigo separado. Agora vou falar um pouco sobre nossos requisitos de negócios e como a Preply funcionou antes da migração para o Kubernetes:
- Quando usamos o fluxo Skullcandy , tínhamos muitos galhos, todos eles mesclados em um galho comum chamado
stage-rc , implantado no palco. A equipe de controle de qualidade testou esse ambiente, depois de testar a ramificação que era alegre no mestre e o mestre implantado no produto. Todo o procedimento levou cerca de 3-4 horas e conseguimos implantar de 0 a 2 vezes por dia - Quando implantamos o código quebrado no produto, tivemos que reverter todas as alterações incluídas na versão mais recente. Também foi difícil descobrir qual alteração quebrou nosso produto
- Usamos o AWS Elastic Beanstalk para hospedar nosso aplicativo. Cada implantação do Beanstalk no nosso caso levou 45 minutos (todo o pipeline juntamente com os testes foram executados em 90 minutos ). A reversão para a versão anterior do aplicativo levou 45 minutos
Para melhorar nossos produtos e processos na empresa, queríamos:
- Divida um monólito em microsserviços
- Implante mais rápido e com mais frequência
- Retroceda mais rapidamente
- Mude nosso processo de desenvolvimento porque pensamos que não era mais eficaz
Nossas necessidades
Mudamos o processo de desenvolvimento
Para implementar nossas inovações com o fluxo Skullcandy, precisávamos criar um ambiente dinâmico para cada filial. Em nossa abordagem com a configuração de aplicativos no Elastic Beanstalk, era difícil e caro fazer isso. Queríamos criar ambientes que:
- Implantado de forma rápida e fácil (de preferência contêineres)
- Trabalhou em instâncias spot
- Eles eram tão parecidos com prod
Decidimos mudar para o desenvolvimento baseado em tronco. Com sua ajuda, cada recurso possui uma ramificação separada, que, independentemente do restante, pode ser mesclada em um mestre. Uma ramificação principal pode ser implantada a qualquer momento.
Desenvolvimento baseado em git-flow e tronco
Implante mais rápido e com mais frequência
O novo processo baseado em tronco nos permitiu entregar inovações para a filial principal mais rapidamente, uma após a outra. Isso nos ajudou muito no processo de encontrar código quebrado no produto e revertê-lo. No entanto, o tempo de implantação ainda era de 90 minutos e o tempo de reversão era de 45 minutos, por isso não foi possível implantar com mais frequência 4-5 vezes por dia.
Também encontramos dificuldades ao usar a arquitetura de serviço no Elastic Beanstalk. A solução mais óbvia foi usar contêineres e instrumentos para orquestrá-los. Além disso, já tínhamos experiência no uso do Docker e do docker-composite para desenvolvimento local.
Nosso próximo passo foi pesquisar os populares orquestradores de contêineres:
- AWS ECS
- Enxame
- Mesos Apache
- Nomad
- Kubernetes
Decidimos ficar no Kubernetes, e é por isso. Entre os orquestradores em questão, todos tiveram algumas falhas importantes: o ECS é uma solução dependente de fornecedor, o Swarm já perdeu os louros do Kubernetes, o Apache Mesos parecia uma nave espacial para nós com seus tratadores. Nomad parecia interessante, mas se revelou totalmente apenas em integração com outros produtos Hashicorp, também ficamos desapontados com o fato de os namespaces no Nomad terem sido pagos.
Apesar de seu alto limiar de entrada, o Kubernetes é o padrão de fato na orquestração de contêineres. O Kubernetes como serviço está disponível na maioria dos principais provedores de nuvem. A orquestra está em desenvolvimento ativo, possui uma grande comunidade de usuários e desenvolvedores e boa documentação.
Esperávamos migrar totalmente nossa plataforma para o Kubernetes em 1 ano. Dois engenheiros de plataforma sem experiência no Kubernetes estavam envolvidos na migração de inicialização parcial.
Usando o Kubernetes
Começamos com a prova de conceito, criamos um cluster de teste e documentamos tudo o que fizemos em detalhes. Decidimos usar o kops , já que em nossa região naquele momento o EKS ainda não estava disponível (na Irlanda, foi anunciado em setembro de 2018 ).
Enquanto trabalhamos com o cluster, testamos o autoscaler de cluster , o gerente de certificação Prometheus, integrações com o Hashicorp Vault, Jenkins e muito mais. Jogamos com estratégias de atualização sem interrupção, enfrentamos vários problemas de rede, em particular com o DNS , e reforçamos nosso conhecimento em clustering de cluster.
Eles usaram instâncias spot para otimizar os custos de infraestrutura. Para receber notificações sobre problemas spot , eles usaram o kube-spot-termination-handler-handler , o Spot Instance Advisor pode ajudá-lo a escolher o tipo de instância spot.
Iniciamos a migração do fluxo Skullcandy para o desenvolvimento baseado em tronco, onde lançamos um estágio dinâmico para cada solicitação pull, o que nos permitiu reduzir o tempo de entrega de novos recursos de 4-6 para 1-2 horas .
Github hook lança criação de ambiente dinâmico para solicitação pull
Usamos um cluster de teste para esses ambientes dinâmicos, cada ambiente estava em um espaço para nome separado. Os desenvolvedores tiveram acesso ao Painel Kubernetes para depurar seu código.
Estamos felizes por termos começado a se beneficiar do Kubernetes após apenas 1-2 meses desde o início de seu uso.
Clusters de estágio e venda
Nossas configurações para clusters de estágio e produto:
- kops e Kubernetes 1.11 (a versão mais recente no momento da criação do cluster)
- Três nós principais em diferentes zonas de acesso
- Topologia de rede privada com bastião dedicado, Calico CNI
- O Prometheus para coletar métricas é implantado no mesmo cluster que o PVC (vale a pena considerar que não armazenamos métricas por um longo tempo)
- Agente de Datadog para APM
- Dex + dex-k8s-authenticator para fornecer acesso ao cluster para desenvolvedores
- Os nós para o cluster de estágio funcionam em instâncias spot
Ao trabalhar com clusters, encontramos vários problemas. Por exemplo, as versões do agente Nginx Ingress e Datadog diferiam nos clusters. Em relação a isso, algumas coisas funcionavam no cluster de estágio, mas não funcionavam no prod. Portanto, decidimos fazer a conformidade total das versões de software nos clusters para evitar esses casos.
Migrando Prod para Kubernetes
Os clusters de palco e alimentos estão prontos e estamos prontos para iniciar a migração. Usamos monorepa com a seguinte estrutura:
. ├── microservice1 │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── microservice2 │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── microserviceN │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── helm │ ├── microservice1 │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml │ ├── microservice2 │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml │ ├── microserviceN │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml └── Jenkinsfile
O Jenkinsfile raiz contém uma tabela de correspondência entre o nome do microsserviço e o diretório em que seu código está localizado. Quando o desenvolvedor retém a solicitação de recebimento para o mestre, uma tag é criada no GitHub, essa tag é implantada no produto usando o Jenkins de acordo com o arquivo Jenkins.
O diretório helm/ contém gráficos HELM com dois arquivos de valores separados para estágio e venda. Usamos o Skaffold para implantar muitos gráficos HELM no palco. Tentamos usar o quadro geral, mas enfrentamos o fato de que é difícil de escalar.
De acordo com o aplicativo de doze fatores, cada novo microsserviço no produto grava logs no stdout, lê segredos do Vault e possui um conjunto básico de alertas (verificação do número de lares em funcionamento, quinhentos erros e latência na entrada).
Independentemente de importarmos ou não novos recursos para microsserviços, no nosso caso, toda a funcionalidade principal está no monólito do Django e esse monólito ainda funciona no Elastic Beanstalk.
Divida o monólito em microsserviços // The Vigeland Park em Oslo
Usamos o AWS Cloudfront como uma CDN e, com ele, uma implantação de canário durante toda a migração. Começamos a migrar o monólito para o Kubernetes e testá-lo em algumas versões de idiomas e nas páginas internas do site (como o painel de administração). Um processo de migração semelhante nos permitiu detectar bugs no produto e aperfeiçoar nossas implantações em apenas algumas iterações. Ao longo de algumas semanas, monitoramos o estado da plataforma, carga e monitoramento e, no final, 100% do tráfego de vendas foi transferido para o Kubernetes.
Depois disso, fomos completamente capazes de abandonar o uso do Elastic Beanstalk.
Sumário
A migração completa levou 11 meses, como mencionei acima, planejamos cumprir o prazo de 1 ano.
Na verdade, os resultados são óbvios:
- O tempo de implantação diminuiu de 90 minutos para 40 minutos
- O número de implantações aumentou de 0-2 para 10-15 por dia (e ainda está crescendo!)
- O tempo de reversão diminuiu de 45 para 1-2 minutos
- Podemos facilmente fornecer novos microsserviços ao produto
- Arrumamos nosso monitoramento, registro, gerenciamento de segredos, centralizamos e os descrevemos como código
Foi uma experiência muito legal de migração e ainda estamos trabalhando em muitas melhorias na plataforma. Certifique-se de ler o artigo interessante sobre a experiência com Kubernetes da Jura, ele foi um desses engenheiros da YAML envolvidos na implementação do Kubernetes no Preply.