Meu nome é Viktor Yagofarov e estou desenvolvendo a plataforma Kubernetes na DomClick como gerente de desenvolvimento técnico na equipe de Ops (operações). Gostaria de falar sobre a estrutura de nossos processos Dev <-> Ops, sobre as funcionalidades de operar um dos maiores clusters k8s da Rússia, bem como sobre as práticas DevOps/SRE que nossa equipe utiliza.
Operações de equipe
A equipe de operações tem atualmente 15 pessoas. Três deles são responsáveis pelo escritório, dois trabalham em fuso horário diferente e estão disponíveis, inclusive à noite. Assim, alguém da Ops está sempre no monitoramento e pronto para responder a um incidente de qualquer complexidade. Não temos turnos noturnos, o que preserva nossa mentalidade e dá a todos a oportunidade de dormir o suficiente e passar momentos de lazer não apenas no computador.
Todos têm competências diferentes: networkers, DBAs, especialistas em pilha ELK, administradores/desenvolvedores Kubernetes, monitoramento, virtualização, especialistas em hardware, etc. Uma coisa une a todos - todos podem substituir qualquer um de nós até certo ponto: por exemplo, introduzir novos nós no cluster k8s, atualizar o PostgreSQL, escrever um pipeline CI / CD + Ansible, automatizar algo em Python / Bash / Go, conectar uma peça de hardware para DPC. Competências fortes em qualquer área não interferem na mudança do rumo da atividade e no início do bombeamento em alguma outra área. Por exemplo, consegui um emprego em uma empresa como especialista em PostgreSQL e agora minha principal área de responsabilidade são os clusters Kubernetes. Na equipe, qualquer crescimento é bem-vindo e o senso de ombro é muito desenvolvido.
A propósito, nós caçamos. Os requisitos para os candidatos são bastante padronizados. Para mim, pessoalmente, é importante que a pessoa se encaixe na equipe, não seja conflituosa, mas também saiba defender seu ponto de vista, queira se desenvolver e não tenha medo de fazer algo novo, de apresentar suas ideias. Além disso, são necessárias habilidades de programação em linguagens de script, conhecimento básico de Linux e inglês. O inglês é necessário apenas para que uma pessoa, no caso de um fakap, possa pesquisar no Google a solução do problema em 10 segundos, e não em 10 minutos. Com especialistas com profundo conhecimento do Linux, agora é muito difícil: engraçado, mas dois em cada três candidatos não conseguem responder à pergunta “O que é média de carga? Em que consiste? ”, E a questão“ Como coletar um dump principal de um programa sish ”é considerada algo do mundo dos super-humanos ... ou dinossauros. Temos que aguentar isso, porque normalmente as pessoas têm outras competências muito desenvolvidas, e vamos ensinar Linux. A resposta para a pergunta “por que um engenheiro DevOps precisa saber tudo isso no mundo moderno das nuvens” terá que ficar fora do escopo do artigo, mas em três palavras: tudo isso é necessário.
comando de ferramentas
A equipe de ferramentas desempenha um papel significativo na automação. Sua principal tarefa é criar ferramentas gráficas e CLI convenientes para desenvolvedores. Por exemplo, nosso desenvolvimento interno do Confer permite que você implemente um aplicativo no Kubernetes com apenas alguns cliques do mouse, configure seus recursos, chaves do cofre, etc. Existia o Jenkins + Helm 2, mas tive que desenvolver minha própria ferramenta para eliminar o copy-paste e trazer uniformidade ao ciclo de vida do software.
A equipe de operações não escreve pipelines para desenvolvedores, mas pode aconselhar sobre quaisquer problemas ao escrevê-los (alguns ainda têm o Helm 3).
DevOps
Quanto ao DevOps, vemos assim:
As equipes de desenvolvimento escrevem o código, implementam-no via Confer to dev -> qa/stage -> prod. É responsabilidade das equipes de Dev e Ops garantir que o código não fique lento e não gere erros. Durante o dia, o oficial de plantão da equipe de Ops deve responder a uma ocorrência com seu aplicativo, e à tarde e à noite, o administrador de plantão (Ops) deve acordar o desenvolvedor de plantão se tiver certeza de que o problema não é na infraestrutura. Todas as métricas e alertas no monitoramento aparecem de forma automática ou semiautomática.
A área de responsabilidade do Ops começa desde o momento em que o aplicativo é lançado até a produção, mas a responsabilidade do Dev não para por aí - fazemos uma coisa e estamos no mesmo barco.
Os desenvolvedores aconselham os administradores se eles precisam de ajuda para escrever um microsserviço administrativo (por exemplo, Go backend + HTML5), e os administradores aconselham os desenvolvedores sobre qualquer infraestrutura ou problemas relacionados ao k8s.
A propósito, não temos um monólito, apenas microsserviços. Seu número até agora flutua entre 900 e 1000 no cluster prod k8s, se medido pelo número Implantações. O número de pods oscila entre 1700 e 2000. Os pods no cluster prod estão agora em torno de 2000.
Não posso dar números exatos, pois monitoramos microsserviços desnecessários e os eliminamos de modo semiautomático. Acompanhar entidades desnecessárias no k8s nos ajuda o que economiza recursos e dinheiro.
Gestão de recursos
Monitoramento
O monitoramento informativo e construído com competência torna-se a pedra angular na operação de um grande cluster. Ainda não encontramos uma solução universal que cubra 100% de todas as necessidades de monitoramento, por isso rebitamos periodicamente diferentes soluções personalizadas neste ambiente.
- Zabbix. O bom e velho monitoramento, projetado principalmente para monitorar o estado geral da infraestrutura. Ele nos diz quando um nó morre por processador, memória, discos, rede e assim por diante. Nada sobrenatural, mas também temos um DaemonSet separado de agentes, com a ajuda dos quais, por exemplo, monitoramos o estado do DNS no cluster: procuramos pods coredns estúpidos, verificamos a disponibilidade de hosts externos. Parece que por que se preocupar com isso, mas em grandes volumes de tráfego esse componente é um sério ponto de falha. Anteriormente eu tenho como lutou com o desempenho do DNS no cluster.
- Operador Prometheus. Um conjunto de diferentes exportadores fornece uma excelente visão geral de todos os componentes do cluster. Em seguida, visualizamos tudo isso em grandes painéis no Grafana e usamos o alertmanager para notificações.
Outra ferramenta útil para nós é . Nós o escrevemos depois de várias vezes encontrarmos uma situação em que uma equipe sobrepôs o Ingress de outra equipe com seus caminhos, o que causou 50 vezes mais erros. Agora, antes de colocar em produção, os desenvolvedores verificam se não vão prejudicar ninguém, e para minha equipe essa é uma boa ferramenta para o diagnóstico inicial de problemas com o Ingresses. É engraçado que no começo foi escrito para administradores e parecia um tanto “desajeitado”, mas depois que os times de desenvolvimento se apaixonaram pela ferramenta, ela mudou muito e começou a não parecer “o administrador fez uma cara da web para administradores” . Em breve abandonaremos essa ferramenta e tais situações serão validadas antes mesmo do pipeline ser lançado.
Recursos da equipe em "Cubo"
Antes de prosseguir com os exemplos, vale explicar como temos a alocação de recursos para microsserviços.
Para entender quais equipes e em que quantidades usam seus recursos (processador, memória, SSD local), alocamos nossos próprios namespace no "Cubo" e limitar as suas capacidades máximas em termos de processador, memória e disco, tendo previamente discutido as necessidades das equipas. Assim, um comando, no caso geral, não bloqueará todo o cluster para implantação, alocando para si milhares de núcleos e terabytes de memória. Os acessos ao namespace são emitidos através do AD (usamos o RBAC). Os namespaces e seus limites são adicionados por meio de uma solicitação pull ao repositório GIT e, em seguida, tudo é implementado automaticamente por meio do pipeline Ansible.
Um exemplo de alocação de recursos por equipe:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Solicitações e limites
Ao cubo" SOLICITAÇÃO é o número de recursos reservados garantidos sob vagem (um ou mais contêineres docker) em um cluster. O limite é um máximo não garantido. Freqüentemente, você pode ver nos gráficos como alguma equipe definiu muitas solicitações para todos os seus aplicativos e não pode implantar o aplicativo no "Cubo", pois em seu namespace todas as solicitações já foram "gastas".
A saída correta dessa situação é observar o consumo real de recursos e compará-lo com o valor solicitado (Request).
As capturas de tela acima mostram que as CPUs "solicitadas" (Requested) são selecionadas para o número real de threads e os limites podem exceder o número real de threads da CPU =)
Agora vamos dar uma olhada em algum namespace (escolhi o namespace kube-system - o namespace do sistema para os componentes do próprio "Cubo") e ver a proporção do tempo do processador realmente usado e da memória para o solicitado:
É óbvio que há muito mais memória e CPU reservada para serviços do sistema do que realmente é usado. No caso do sistema kube, isso é justificado: aconteceu que o controlador de entrada nginx ou nodelocaldns no pico descansou na CPU e consumiu muita RAM, então aqui essa margem é justificada. Além disso, não podemos confiar nos gráficos das últimas 3 horas: é desejável ver métricas históricas por um longo período de tempo.
Foi desenvolvido um sistema de "recomendações". Por exemplo, aqui você pode ver quais recursos seriam melhores em aumentar os “limites” (a barra superior permitida) para que o “throttling” não ocorra: o momento em que o pod já gastou a CPU ou a memória pelo quantum de tempo alocado e está esperando até que seja "descongelado":
E aqui estão as vagens que devem moderar seus apetites:
Про estrangulamento + recursos de monitoramento, você pode escrever mais de um artigo, então tire suas dúvidas nos comentários. Em poucas palavras, posso dizer que a tarefa de automatizar tais métricas é muito difícil e requer muito tempo e balanceamento com funções “janela” e “CTE” Prometheus / VictoriaMetrics (esses termos estão entre aspas, pois não há quase nada disso no PromQL, e você tem que cercar consultas assustadoras em várias telas de texto e otimizá-las).
Como resultado, os desenvolvedores têm ferramentas para monitorar seus namespaces no "Cubo" e podem escolher onde e a que horas quais aplicativos podem "cortar" recursos e quais pods podem receber toda a CPU a noite toda.
Metodologias
Na empresa como agora elegante, aderimos ao DevOps- e SRE-praticante Quando uma empresa tem 1000 microsserviços, cerca de 350 developers e 15 admins para toda a infraestrutura, tem que “estar na moda”: por detrás de todos estes “chavões” existe uma necessidade urgente de automatizar tudo e todos, e os admins não devem ser um gargalo em processos.
Como Ops, fornecemos várias métricas e painéis para desenvolvedores relacionados à velocidade de resposta e erros de serviço.
Utilizamos metodologias como: , и combinando-os juntos. Tentamos minimizar o número de painéis para que fique claro qual serviço está degradando no momento (por exemplo, códigos de resposta por segundo, tempo de resposta no 99º percentil) e assim por diante. Assim que algumas novas métricas para painéis gerais se tornam necessárias, nós imediatamente as desenhamos e adicionamos.
Faz um mês que não desenho gráficos. Este é provavelmente um bom sinal: significa que a maioria dos “desejos” já foram implementados. Acontece que durante uma semana desenhei um novo gráfico pelo menos uma vez por dia.
O resultado resultante é valioso porque agora os desenvolvedores raramente vão aos administradores com perguntas “onde ver algum tipo de métrica”.
Implementação malha de serviço está chegando e deve facilitar muito a vida de todos, os colegas da Tools já estão perto de implementar o abstrato “Istio de uma pessoa saudável”: o ciclo de vida de cada requisição HTTP(s) ficará visível no monitoramento, e será sempre possível perceber “em que fase tudo quebrou” na interação interserviços (e não só). Assine notícias do hub DomClick. =)
Suporte à infraestrutura do Kubernetes
Historicamente, usamos a versão corrigida Kubespray - Ansible papel para implantação, extensão e atualização do Kubernetes. Em algum momento, o suporte para instalações não kubeadm foi cortado do ramo principal e o processo de transição para kubeadm não foi proposto. Como resultado, o Southbridge criou seu próprio fork (com suporte para kubeadm e uma solução rápida para problemas críticos).
O processo de atualização para todos os clusters k8s tem a seguinte aparência:
- Tomar Kubespray de Southbridge, verifique com nossa filial, merjim.
- Lançando a atualização para Estresse- "Cubo".
- Lançamos a atualização um nó de cada vez (no Ansible é "serial: 1") em Dev- "Cubo".
- Atualizando Incitar no sábado à noite, um nó de cada vez.
No futuro, há planos para substituir Kubespray para algo mais rápido e ir para kubeadm.
No total, temos três "Cubos": Stress, Dev e Prod. Pretendemos lançar outroHot Standby) Prod- "Cube" no segundo centro de dados. Estresse и Dev live em máquinas virtuais (oVirt for Stress e VMWare cloud for Dev). Incitar- "Cube" vive em "bare metal" (bare metal): são os mesmos nós com 32 threads de CPU, 64-128 GB de memória e 300 GB de SSD RAID 10 - são 50 no total. Três nós “finos” são dedicados aos “mestres” Incitar- "Cuba": 16 GB de memória, 12 threads de CPU.
Para vender, preferimos usar “bare metal” e evitar camadas desnecessárias como OpenStack: não precisamos de "vizinhos barulhentos" e CPU roubar tempo. E a complexidade da administração aumenta cerca de metade no caso do OpenStack interno.
Para CI/CD Cubic e outros componentes de infraestrutura, usamos um servidor GIT separado, Helm 3 atômico), Jenkins, Ansible e Docker. Adoramos ramificações de recursos e implementamos em diferentes ambientes do mesmo repositório.
Conclusão
É assim que, em termos gerais, o processo DevOps na DomClick se parece do lado de um engenheiro de operações. O artigo acabou sendo menos técnico do que eu esperava: portanto, acompanhe as notícias do DomClick no Habré: haverá mais artigos “hardcore” sobre Kubernetes e muito mais.
Fonte: habr.com