Mi nombre es Viktor Yagofarov y estoy desarrollando la plataforma Kubernetes en DomClick como gerente de desarrollo técnico en el equipo de Operaciones. Me gustaría hablar sobre la estructura de nuestros procesos Dev <-> Ops, las características de operar uno de los clústeres k8 más grandes de Rusia, así como las prácticas de DevOps/SRE que aplica nuestro equipo.
Equipo de operaciones
El equipo de operaciones cuenta actualmente con 15 personas. Tres de ellos son responsables de la oficina, dos trabajan en diferentes husos horarios y están disponibles, incluso de noche. Por lo tanto, alguien de Operaciones está siempre en el monitor y listo para responder a un incidente de cualquier complejidad. No tenemos turnos de noche, lo que preserva nuestra psique y brinda a todos la oportunidad de dormir lo suficiente y pasar tiempo libre no solo frente al ordenador.
Cada uno tiene diferentes competencias: networkers, DBA, especialistas en pila ELK, administradores/desarrolladores de Kubernetes, monitoreo, virtualización, especialistas en hardware, etc. Una cosa une a todos: todos pueden reemplazar a cualquiera de nosotros hasta cierto punto: por ejemplo, introducir nuevos nodos en el clúster k8s, actualizar PostgreSQL, escribir una tubería CI/CD + Ansible, automatizar algo en Python/Bash/Go, conectar hardware a Centro de datos. Las sólidas competencias en cualquier área no le impiden cambiar su dirección de actividad y comenzar a mejorar en alguna otra área. Por ejemplo, me uní a una empresa como especialista en PostgreSQL y ahora mi principal área de responsabilidad son los clústeres de Kubernetes. En el equipo cualquier altura es bienvenida y el sentido de apalancamiento está muy desarrollado.
Por cierto, estamos cazando. Los requisitos para los candidatos son bastante estándar. Personalmente, para mí es importante que una persona encaje en el equipo, no tenga conflictos, pero también sepa defender su punto de vista, quiera desarrollarse y no tenga miedo de hacer algo nuevo y ofrezca sus ideas. Además, se requieren habilidades de programación en lenguajes de scripting, conocimientos de los conceptos básicos de Linux e inglés. Se necesita inglés simplemente para que una persona, en caso de una falsificación, pueda buscar en Google una solución al problema en 10 segundos, y no en 10 minutos. Ahora es muy difícil encontrar especialistas con conocimientos profundos de Linux: es curioso, pero dos de cada tres candidatos no pueden responder a la pregunta "¿Qué es la carga promedio?". ¿De qué está hecho?”, y la pregunta “¿Cómo montar un volcado de núcleo a partir de un programa en C” se considera algo del mundo de los superhombres... o de los dinosaurios. Tenemos que aguantar esto, ya que normalmente la gente tiene otras competencias muy desarrolladas, pero enseñaremos Linux. La respuesta a la pregunta "¿por qué un ingeniero de DevOps necesita saber todo esto en el mundo moderno de las nubes" deberá quedar fuera del alcance del artículo, pero en tres palabras: todo esto es necesario.
Herramientas de equipo
El equipo de Herramientas juega un papel importante en la automatización. Su tarea principal es crear herramientas gráficas y CLI convenientes para los desarrolladores. Por ejemplo, nuestra Conferencia de desarrollo interno le permite implementar literalmente una aplicación en Kubernetes con solo unos pocos clics del mouse, configurar sus recursos, claves desde la bóveda, etc. Anteriormente, existía Jenkins + Helm 2, pero tuve que desarrollar mi propia herramienta para eliminar copiar y pegar y aportar uniformidad al ciclo de vida del software.
El equipo de operaciones no escribe canales para desarrolladores, pero puede asesorar sobre cualquier problema relacionado con su redacción (algunas personas todavía tienen Helm 3).
DevOps
En cuanto a DevOps, lo vemos así:
Los equipos de desarrollo escriben el código y lo implementan a través de Confer to dev -> qa/stage -> prod. La responsabilidad de garantizar que el código no se ralentice y no contenga errores recae en los equipos de desarrollo y operaciones. Durante el día, la persona de turno del equipo de Operaciones debe, en primer lugar, responder a un incidente con su aplicación, y por la tarde y por la noche, el administrador de turno (Ops) debe despertar al desarrollador de turno si lo sabe. seguro que el problema no está en la infraestructura. Todas las métricas y alertas en el monitoreo aparecen de forma automática o semiautomática.
El área de responsabilidad de Ops comienza desde el momento en que la aplicación se implementa en producción, pero la responsabilidad de Dev no termina ahí: hacemos lo mismo y estamos en el mismo barco.
Los desarrolladores asesoran a los administradores si necesitan ayuda para escribir un microservicio de administración (por ejemplo, Go backend + HTML5), y los administradores asesoran a los desarrolladores sobre cualquier problema de infraestructura o relacionado con k8.
Por cierto, no tenemos ningún monolito, sólo microservicios. Su número hasta ahora fluctúa entre 900 y 1000 en el grupo prod k8s, si se mide en número Despliegues. El número de vainas fluctúa entre 1700 y 2000. Actualmente hay alrededor de 2000 vainas en el grupo de productos.
No puedo dar cifras exactas, ya que monitoreamos los microservicios innecesarios y los eliminamos de forma semiautomática. K8s nos ayuda a realizar un seguimiento de entidades innecesarias , lo que ahorra muchos recursos y dinero.
Administracion de recursos
Monitoreo
Un seguimiento bien estructurado e informativo se convierte en la piedra angular del funcionamiento de un gran clúster. Aún no hemos encontrado una solución universal que cubra el 100% de todas las necesidades de monitorización, por lo que periódicamente creamos diferentes soluciones personalizadas en este entorno.
- Zabbix. Buen seguimiento antiguo, cuyo objetivo principal es realizar un seguimiento del estado general de la infraestructura. Nos indica cuándo muere un nodo en términos de procesamiento, memoria, discos, red, etc. Nada sobrenatural, pero también tenemos un DaemonSet separado de agentes, con la ayuda del cual, por ejemplo, monitoreamos el estado de DNS en el clúster: buscamos pods de coredns estúpidos, verificamos la disponibilidad de hosts externos. Parecería que por qué molestarse con esto, pero con grandes volúmenes de tráfico, este componente es un grave punto de falla. Yo ya , cómo luché con el rendimiento de DNS en un clúster.
- Operador Prometeo. Un conjunto de diferentes exportadores ofrece una amplia visión general de todos los componentes del clúster. A continuación, visualizamos todo esto en paneles grandes en Grafana y usamos alertmanager para las alertas.
Otra herramienta útil para nosotros fue . Lo escribimos después de que varias veces nos encontráramos con una situación en la que un equipo superponía las rutas de ingreso de otro equipo, lo que generaba errores de 50 veces. Ahora, antes de implementarlo en producción, los desarrolladores verifican que nadie se verá afectado y para mi equipo esta es una buena herramienta para el diagnóstico inicial de problemas con Ingresses. Es curioso que al principio fue escrito para administradores y parecía bastante "torpe", pero después de que los equipos de desarrollo se enamoraron de la herramienta, cambió mucho y comenzó a no parecerse a "un administrador hizo una cara web para administradores". " Pronto abandonaremos esta herramienta y estas situaciones se validarán incluso antes de que se implemente el proceso.
Recursos del equipo en el Cubo
Antes de entrar en los ejemplos, vale la pena explicar cómo asignamos recursos para microservicios.
Para entender qué equipos y en qué cantidades utilizan sus ресурсы (procesador, memoria, SSD local), asignamos a cada comando su propio espacio de nombres en el “Cubo” y limitar sus capacidades máximas en cuanto a procesador, memoria y disco, habiendo discutido previamente las necesidades de los equipos. En consecuencia, un comando, en general, no bloqueará todo el clúster para su implementación, asignando miles de núcleos y terabytes de memoria. El acceso al espacio de nombres se otorga a través de AD (usamos RBAC). Los espacios de nombres y sus límites se agregan mediante una solicitud de extracción al repositorio GIT y luego todo se implementa automáticamente a través de la canalización de Ansible.
Un ejemplo de asignación de recursos a un equipo:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Solicitudes y límites
Cubicado" SOLICITUD es el número de recursos reservados garantizados para vaina (uno o más contenedores acoplables) en un clúster. El límite es un máximo no garantizado. A menudo se puede ver en los gráficos cómo algún equipo ha establecido demasiadas solicitudes para todas sus aplicaciones y no puede implementar la aplicación en el "Cubo", ya que todas las solicitudes bajo su espacio de nombres ya se han "gastado".
La forma correcta de salir de esta situación es observar el consumo real de recursos y compararlo con la cantidad solicitada (Solicitud).
En las capturas de pantalla anteriores, puede ver que las CPU "solicitadas" coinciden con la cantidad real de subprocesos y los límites pueden exceder la cantidad real de subprocesos de la CPU =)
Ahora veamos en detalle algún espacio de nombres (elegí el espacio de nombres kube-system, el espacio de nombres del sistema para los componentes del "Cubo") y veamos la proporción entre el tiempo de procesador y la memoria realmente utilizados y el solicitado:
Es obvio que se reserva mucha más memoria y CPU para los servicios del sistema de la que realmente se utiliza. En el caso del sistema kube, esto está justificado: sucedió que el controlador de ingreso nginx o los nodelocaldns en su punto máximo golpearon la CPU y consumieron mucha RAM, por lo que aquí tal reserva está justificada. Además, no podemos confiar en los gráficos de las últimas 3 horas: es deseable ver métricas históricas durante un largo período de tiempo.
Se desarrolló un sistema de “recomendaciones”. Por ejemplo, aquí puede ver qué recursos estarían mejor si aumentaran los “límites” (la barra superior permitida) para que no se produzca una “estrangulación”: el momento en que un recurso ya ha gastado CPU o memoria en el intervalo de tiempo asignado y está esperando hasta que se “descongela”:
Y aquí están las vainas que deberían frenar su apetito:
Про estrangulamiento + seguimiento de recursos, puedes escribir más de un artículo, así que haz preguntas en los comentarios. En pocas palabras, puedo decir que la tarea de automatizar este tipo de métricas es muy difícil y requiere mucho tiempo y equilibrio con funciones de “ventana” y “CTE” Prometheus / VictoriaMetrics (estos términos están entre comillas, ya que casi hay nada como esto en PromQL, y tienes que dividir las consultas aterradoras en varias pantallas de texto y optimizarlas).
Como resultado, los desarrolladores tienen herramientas para monitorear sus espacios de nombres en Cube, y pueden elegir por sí mismos dónde y a qué hora se pueden "cortar" los recursos de qué aplicaciones y qué servidores pueden recibir toda la CPU durante toda la noche.
Metodologías
En la empresa como es ahora. de moda, nos adherimos a DevOps- y SRE-facultativo Cuando una empresa tiene 1000 microservicios, unos 350 desarrolladores y 15 administradores para toda la infraestructura, hay que “estar a la moda”: detrás de todas estas “palabras falsas” hay una necesidad urgente de automatizar todo y a todos, y los administradores no deberían ser un cuello de botella. en procesos.
Como Ops, proporcionamos varias métricas y paneles para desarrolladores relacionados con las tasas de respuesta y los errores del servicio.
Utilizamos metodologías como: , и combinándolos entre sí. Intentamos minimizar la cantidad de paneles para que de un vistazo quede claro qué servicio se está degradando actualmente (por ejemplo, códigos de respuesta por segundo, tiempo de respuesta en el percentil 99), etc. Tan pronto como se vuelven necesarias algunas métricas nuevas para los paneles generales, las dibujamos y agregamos inmediatamente.
Hace un mes que no hago gráficos. Probablemente sea una buena señal: significa que la mayoría de los “deseos” ya se han cumplido. Sucedió que durante la semana dibujaba algún gráfico nuevo al menos una vez al día.
El resultado resultante es valioso porque ahora los desarrolladores rara vez acuden a los administradores con preguntas sobre "dónde mirar algún tipo de métrica".
Incrustar Malla de servicio está a la vuelta de la esquina y debería hacer la vida mucho más fácil para todos, los colegas de Tools ya están cerca de implementar el abstracto "Istio de una persona sana": el ciclo de vida de cada solicitud HTTP será visible en el monitoreo, y Siempre será posible entender “en qué etapa todo se rompió” durante la interacción entre servicios (y no solo). Suscríbase a las noticias del centro DomClick. =)
Soporte de infraestructura de Kubernetes
Históricamente utilizamos la versión parcheada. Kubespray – Función de Ansible para implementar, ampliar y actualizar Kubernetes. En algún momento, se eliminó el soporte para instalaciones que no eran kubeadm desde la rama principal y no se propuso el proceso de cambio a kubeadm. Como resultado, la empresa Southbridge creó su propia bifurcación (con soporte de kubeadm y una solución rápida para problemas críticos).
El proceso para actualizar todos los clústeres k8s tiene este aspecto:
- tomar Kubespray Desde Southbridge, consulta con nuestro hilo, Merjim.
- Estamos implementando la actualización para Estrés- “Cubo”.
- Implementamos la actualización un nodo a la vez (en Ansible esto es "serie: 1") en Dev- “Cubo”.
- Actualizamos Aguijón el sábado por la noche, un nodo a la vez.
Hay planes para reemplazarlo en el futuro. Kubespray para algo más rápido y vaya a kubeadm.
En total tenemos tres “Cubos”: Stress, Dev y Prod. Estamos planeando lanzar otro (modo de espera en caliente) Prod-“Cube” en el segundo centro de datos. Estrés и Dev vivir en “máquinas virtuales” (oVirt para Stress y VMWare cloud para Dev). Aguijón- "Cube" vive del "metal básico": estos son nodos idénticos con 32 subprocesos de CPU, 64-128 GB de memoria y 300 GB SSD RAID 10; hay 50 en total. Tres nodos "delgados" están dedicados a los "maestros" Aguijón- “Cuba”: 16 GB de memoria, 12 subprocesos de CPU.
Para las ventas, preferimos utilizar “metal desnudo” y evitar capas innecesarias como Pila abierta: no necesitamos "vecinos ruidosos" ni CPU robar tiempo. Y la complejidad de la administración aproximadamente se duplica en el caso de OpenStack interno.
Para CI/CD “Cubic” y otros componentes de infraestructura utilizamos un servidor GIT separado, Helm 3 (fue una transición bastante dolorosa desde Helm 2, pero estamos muy contentos con las opciones atómico), Jenkins, Ansible y Docker. Nos encantan las ramas de funciones y la implementación en diferentes entornos desde un repositorio.
Conclusión
Así es, en términos generales, cómo se ve el proceso DevOps en DomClick desde la perspectiva de un ingeniero de operaciones. El artículo resultó ser menos técnico de lo que esperaba: por lo tanto, siga las noticias de DomClick en Habré: habrá más artículos "hardcore" sobre Kubernetes y más.
Fuente: habr.com