Chámome Viktor Yagofarov e estou a desenvolver a plataforma Kubernetes en DomClick como xestor de desenvolvemento técnico no equipo de operacións (operacións). Gustaríame falar sobre a estrutura dos nosos procesos Dev <-> Ops, sobre as características de operar un dos clústeres k8s máis grandes de Rusia, así como sobre as prácticas DevOps/SRE que usa o noso equipo.
Equipo Ops
O equipo de Operacións conta actualmente con 15 persoas. Tres deles son os responsables da oficina, dous traballan nun fuso horario diferente e están dispoñibles, incluso pola noite. Así, alguén de Ops está sempre no monitor e está preparado para responder a un incidente de calquera complexidade. Non temos quendas nocturnas, o que preserva a nosa mentalidade e dá a todos a oportunidade de durmir o suficiente e pasar o tempo de lecer non só ante o ordenador.
Todo o mundo ten diferentes competencias: redes, DBA, especialistas en pila ELK, administradores/desenvolvedores de Kubernetes, monitorización, virtualización, especialistas en hardware, etc. Unha cousa une a todos: todos poden substituír a calquera de nós ata certo punto: por exemplo, introducir novos nodos no clúster k8s, actualizar PostgreSQL, escribir unha canalización CI/CD + Ansible, automatizar algo en Python/Bash/Go, conectar unha peza. de hardware a DPC. As competencias fortes en calquera área non interfiren con cambiar a dirección da actividade e comezar a bombear nalgunha outra área. Por exemplo, conseguín un traballo nunha empresa como especialista en PostgreSQL, e agora a miña principal área de responsabilidade son os clústeres de Kubernetes. No equipo, calquera crecemento é só benvido e o sentido do ombreiro está moi desenvolvido.
Por certo, cazamos. Os requisitos para os candidatos son bastante estándar. Para min persoalmente é importante que unha persoa encaixe no equipo, non sexa conflitiva, pero tamén saiba defender o seu punto de vista, queira desenvolverse e non teña medo de facer algo novo, de ofrecer as súas ideas. Ademais, son necesarios coñecementos de programación en linguaxes de script, coñecementos básicos de Linux e inglés. O inglés é necesario só para que unha persoa no caso dun fakap poida buscar en Google a solución do problema en 10 segundos, e non en 10 minutos. Con especialistas con profundos coñecementos de Linux, agora é moi difícil: divertido, pero dous de cada tres candidatos non poden responder á pregunta "Que é a media de carga? En que consiste? ", E a pregunta "Como recoller un vertedoiro de núcleos dun programa sish" considérase algo do mundo dos superhumanos... ou dos dinosauros. Temos que aguantar isto, xa que normalmente a xente ten outras competencias moi desenvolvidas, e nós ensinaremos Linux. A resposta á pregunta "por que un enxeñeiro de DevOps necesita saber todo isto no mundo moderno das nubes" terá que quedar fóra do ámbito do artigo, pero en tres palabras: todo isto é necesario.
Comando de ferramentas
O equipo de Ferramentas xoga un papel importante na automatización. A súa tarefa principal é crear ferramentas gráficas e CLI convenientes para os desenvolvedores. Por exemplo, o noso desenvolvemento interno de Confer permítelle lanzar unha aplicación a Kubernetes con só uns poucos clics do rato, configurar os seus recursos, as claves da bóveda, etc. Antes había Jenkins + Helm 2, pero tiven que desenvolver a miña propia ferramenta para eliminar o copiar e pegar e uniformizar o ciclo de vida do software.
O equipo de Operacións non escribe canalizacións para desenvolvedores, pero pode aconsellar sobre calquera problema ao escribirlas (algúns aínda teñen Helm 3).
DevOps
En canto a DevOps, vémolo así:
Os equipos de desenvolvemento escriben código, desenvólveno mediante Confer to dev -> qa/stage -> prod. É responsabilidade dos equipos de desenvolvemento e operacións asegurarse de que o código non se ralentice e non produza erros. Durante o día, o oficial de servizo do equipo de Operacións debería responder a un incidente coa súa aplicación e, pola noite e pola noite, o administrador de servizo (Ops) debería espertar o programador de servizo se sabe con certeza que o problema non é. na infraestrutura. Todas as métricas e alertas da monitorización aparecen de forma automática ou semiautomática.
A área de responsabilidade de Ops comeza desde o momento en que a aplicación se lanza ata a produción, pero a responsabilidade de Dev non remata aí: facemos unha cousa e estamos no mesmo barco.
Os desenvolvedores aconsellan aos administradores se necesitan axuda para escribir un microservizo de administrador (por exemplo, Go backend + HTML5) e os administradores aconsellan aos desenvolvedores sobre calquera problema relacionado coa infraestrutura ou k8s.
Por certo, non temos un monólito en absoluto, só microservizos. O seu número ata agora oscila entre 900 e 1000 no clúster prod k8s, se se mide polo número despregamentos. O número de vainas oscila entre 1700 e 2000. As vainas do grupo de produtos son agora arredor de 2000.
Non podo dar números exactos, xa que monitorizamos microservizos innecesarios e cortamos nun modo semiautomático. Facer un seguimento das entidades innecesarias en k8s axúdanos que aforra recursos e cartos.
Xestión de recursos
Seguimento
O seguimento informativo e construído de forma competente convértese na pedra angular do funcionamento dun gran clúster. Aínda non atopamos unha solución universal que cubra o 100% de todas as necesidades de vixilancia, polo que remachamos periodicamente diferentes solucións personalizadas nesta contorna.
- Zabbix. Boa vixilancia antiga, que está deseñada principalmente para supervisar o estado xeral da infraestrutura. Indícanos cando un nodo morre polo procesador, a memoria, os discos, a rede, etc. Nada sobrenatural, pero tamén temos un DaemonSet separado de axentes, coa axuda do cal, por exemplo, supervisamos o estado DNS no clúster: buscamos pods coredns estúpidos, comprobamos a dispoñibilidade de hosts externos. Parece que por que molestarse por iso, pero en grandes volumes de tráfico este compoñente é un grave punto de falla. Antes teño como se enfrontou co rendemento de DNS no clúster.
- Operador Prometheus. Un conxunto de exportadores diferentes ofrece unha excelente visión xeral de todos os compoñentes do clúster. A continuación, visualizamos todo isto en grandes paneis en Grafana e usamos o alertmanager para as notificacións.
Outra ferramenta útil para nós é . Escribímolo despois de que varias veces atopamos unha situación na que un equipo superpuxo a entrada doutro equipo cos seus camiños, o que provocou erros 50x. Agora, antes de implantarse en produción, os desenvolvedores comproban que non prexudicarán a ninguén, e para o meu equipo esta é unha boa ferramenta para o diagnóstico inicial de problemas con Ingresses. É curioso que ao principio fose escrito para administradores e parecía bastante "torpe", pero despois de que os equipos de desenvolvemento se namoraron da ferramenta, cambiou moito e comezou a parecer non como "o administrador fixo unha cara web para os administradores" . Pronto abandonaremos esta ferramenta e tales situacións validaranse incluso antes de que se lance o gasoduto.
Recursos do equipo en "Cube"
Antes de continuar cos exemplos, convén explicar como temos a asignación de recursos microservizos.
Comprender que equipos e en que cantidades usan os seus recursos (procesador, memoria, SSD local), asignamos o noso propio espazo de nomes no "Cube" e limitar as súas máximas capacidades en canto a procesador, memoria e disco, xa que se comentaron previamente as necesidades dos equipos. En consecuencia, un comando, no caso xeral, non bloqueará todo o clúster para a súa implantación, asignando miles de núcleos e terabytes de memoria a si mesmo. Os accesos ao espazo de nomes emítense a través de AD (usamos RBAC). Os espazos de nomes e os seus límites engádense mediante unha solicitude de extracción ao repositorio de GIT e, a continuación, todo desprázase automaticamente a través da canalización de Ansible.
Un exemplo de asignación de recursos por equipo:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Solicitudes e límites
en cubos" Solicitude é o número de recursos reservados garantidos baixo pod (un ou máis contedores docker) nun clúster. O límite é un máximo non garantido. A miúdo podes ver nos gráficos como algún equipo fixo demasiadas solicitudes para todas as súas aplicacións e non pode implementar a aplicación no "Cubo", xa que baixo o seu espazo de nomes todas as solicitudes xa foron "gastadas".
A forma correcta de saír desta situación é mirar o consumo real de recursos e comparalo coa cantidade solicitada (Solicitude).
As capturas de pantalla anteriores mostran que as CPU "solicitadas" (solicitadas) están seleccionadas para o número real de fíos e os límites poden superar o número real de fíos de CPU =)
Agora vexamos máis de cerca algúns espazos de nomes (escollín o espazo de nomes kube-system - o espazo de nomes do sistema para os compoñentes do propio "Cubo") e vexamos a proporción do tempo e memoria do procesador realmente utilizados coa solicitada:
É obvio que hai moita máis memoria e CPU reservada para os servizos do sistema da que realmente se utiliza. No caso do sistema kube, isto está xustificado: ocorreu que o controlador de entrada nginx ou nodelocaldns no pico descansaron na CPU e comían moita memoria RAM, polo que aquí se xustifica esa marxe. Ademais, non podemos confiar nos gráficos das últimas 3 horas: é desexable ver as métricas históricas durante un gran período de tempo.
Desenvolveuse un sistema de "recomendacións". Por exemplo, aquí podes ver que recursos sería mellor elevar os "límites" (a barra superior permitida) para que non se produza o "estrangulamento": o momento no que o pod xa gastou a CPU ou a memoria durante o tempo asignado. e está esperando ata que sexa "desconxelado":
E aquí están as vainas que deberían moderar os seus apetitos:
en estrangulamento + recursos de seguimento, podes escribir máis dun artigo, así que fai preguntas nos comentarios. En poucas palabras, podo dicir que a tarefa de automatizar este tipo de métricas é moi difícil e require moito tempo e equilibrio coas funcións "ventá" e "CTE" Prometheus / VictoriaMetrics (estes termos están entre comiñas, xa que hai case nada como isto en PromQL, e tes que limitar as consultas asustadas en varias pantallas de texto e optimizalas).
Como resultado, os desenvolvedores dispoñen de ferramentas para supervisar os seus espazos de nomes no "Cube" e poden escoller onde e a que hora que aplicacións poden "cortar" os recursos e que pods poden recibir toda a CPU durante toda a noite.
Metodoloxías
En compañía coma agora de moda, adherímonos a DevOps- e SRE- practicante Cando unha empresa ten 1000 microservizos, uns 350 desenvolvedores e 15 administradores para toda a infraestrutura, hai que "estar de moda": detrás de todas estas "palabras de moda" hai unha necesidade urxente de automatizar todo e todo, e os administradores non deben ser un pescozo de botella. en procesos.
Como Ops, ofrecemos varias métricas e paneis de control para desenvolvedores relacionados coa velocidade de resposta do servizo e os erros do servizo.
Utilizamos metodoloxías como: , и combinándoos. Tentamos minimizar o número de paneis de mando para que a simple vista quede claro que servizo se está degradando actualmente (por exemplo, códigos de resposta por segundo, tempo de resposta no percentil 99), etc. En canto sexan necesarias algunhas métricas novas para os paneis xerais, debuxámolas e engadímolas inmediatamente.
Hai un mes que non debuxo gráficos. Probablemente este sexa un bo sinal: significa que a maioría dos "queres" xa foron implementados. Ocorreu que durante unha semana debuxei algún novo gráfico polo menos unha vez ao día.
O resultado resultante é valioso xa que agora os desenvolvedores raramente acuden aos administradores con preguntas "onde ver algún tipo de métricas".
Implementación Malla de servizo está á volta da esquina e debería facilitarlle moito a vida a todos, os compañeiros de Tools xa están preto de implementar o resumo “Istio of a healthy person”: o ciclo de vida de cada solicitude HTTP(s) estará visible no seguimento e sempre será posible comprender "en que fase se rompeu todo" na interacción entre servizos (e non só). Subscríbete ás noticias do centro de DomClick. =)
Soporte de infraestrutura de Kubernetes
Historicamente, usamos a versión parcheada Kubespray - Función Ansible para implantar, ampliar e actualizar Kubernetes. Nalgún momento, o soporte para instalacións non kubeadm foi cortado da rama principal e non se propuxo o proceso de transición a kubeadm. Como resultado, Southbridge fixo o seu propio fork (con soporte para kubeadm e unha solución rápida para problemas críticos).
O proceso de actualización para todos os clústeres k8s ten o seguinte aspecto:
- Tome Kubespray desde Southbridge, consulte coa nosa sucursal, merjim.
- Lanzando a actualización a Estrés- "Cubo".
- Lanzamos a actualización un nodo á vez (en Ansible isto é "serial: 1") dev- "Cubo".
- Actualizando Incitar o sábado á noite, un nodo á vez.
No futuro hai plans para substituír Kubespray a algo máis rápido e ir a kubeadm.
En total, temos tres "Cubos": Stress, Dev e Prod. Pensamos lanzar outroespera en quente) Prod- "Cube" no segundo centro de datos. Estrés и dev vivir en máquinas virtuais (oVirt for Stress e VMWare cloud for Dev). Incitar- "Cube" vive en "bare metal" (bare metal): estes son os mesmos nodos con 32 fíos de CPU, 64-128 GB de memoria e 300 GB de SSD RAID 10: hai 50 en total. Tres nodos "delgados" están dedicados aos "mestres" Incitar- "Cuba": 16 GB de memoria, 12 fíos de CPU.
Para vender, preferimos usar "metal desnudo" e evitar capas innecesarias como OpenStack: non necesitamos "veciños ruidosos" e CPU roubar o tempo. E a complexidade da administración aumenta preto da metade no caso de OpenStack interno.
Para CI/CD Cubic e outros compoñentes de infraestrutura usamos un servidor GIT separado, Helm 3 atómica), Jenkins, Ansible e Docker. Encántannos as ramas de funcións e implementar a diferentes ambientes desde o mesmo repositorio.
Conclusión
Así é como, en termos xerais, o proceso DevOps en DomClick parece desde o lado dun enxeñeiro de operacións. O artigo resultou ser menos técnico do que esperaba: polo tanto, segue as noticias de DomClick en Habré: haberá máis artigos "hardcore" sobre Kubernetes e moito máis.
Fonte: www.habr.com