5 lecciones que aprendí sobre la ingeniería del caos para Kubernetes

Kubernetes es un marco complejo para trabajos complejos. Administrar múltiples contenedores puede ser complicado, y administrar cientos y miles de ellos es esencialmente imposible desde el punto de vista humano. Kubernetes hace realidad las aplicaciones en la nube de alta disponibilidad y escalabilidad y, por lo general, hace su trabajo de manera admirable. Sin embargo, la gente no tiende a notar los días y meses exitosos. Meses y años de funcionamiento sin problemas no son las cosas que resultan en llamadas telefónicas a las 2 am. En TI, lo que importa son los fallos. Y desafortunadamente, los errores no se ejecutan según lo programado.

El nuevo libro electrónico de Jessica Cherry, Ingeniería del caos para Kubernetes, presenta varios conceptos sobre cómo los ingenieros de sistemas pueden ayudar a probar la solidez de los sistemas que han diseñado. Sorprendentemente, gran parte es la bancarrota. Aquí están las primeras cinco lecciones que aprendí del libro de Cherry.

Índice

    El fracaso intencional es parte del éxito

    No importa que hayas hecho todo bien. Compró hardware diseñado para el trabajo, instaló una distribución estable, compró soporte, leyó los manuales refinados, documentó el proceso, la recuperación automática, la copia de seguridad, etc. Después de todo el trabajo de preparación, solo hay una cosa de la que puede estar seguro: algo saldrá mal con el tiempo.

    No es morboso pensar así porque es precisamente lo que sucede en los sistemas tecnológicos y mecánicos. Las cosas fallan.

    No puedes evitar que las cosas fallen, pero puedes Hacer fallan cuando te conviene. Desafortunadamente, forzar un error en su sistema no "agota" todos los errores asignados para el año. Las cosas seguirán fallando inesperadamente, pero al causar fallas en su programación, se asegura de tener los recursos y el conocimiento para solucionar problemas.

    La falla aleatoria es parte de la resiliencia

    No eres el único que necesita saber cómo manejar la bancarrota. Su infraestructura también debe ser capaz de soportar fallas. Si bien puede probar algunos de estos problemas con errores planificados, la aleatoriedad ayuda a garantizar la resiliencia. Después de todo, se producirán algunos errores cuando no esté presente para asegurarse de que todo lo demás sigue funcionando. Idealmente, desea desarrollar la tranquilidad de que algo podría romperse sin que se dé cuenta (pero eventualmente lo sabrá porque está monitoreando su clúster. Está monitoreando su clúster, ¿verdad?).

    La resiliencia tiene que suceder en muchos lugares

    Nunca olvidaré el primer servidor de archivos compartidos a gran escala (200 usuarios eran grandes para mí entonces). Tenía un grupo de almacenamiento LVM con mucho espacio para discos duros adicionales, respaldo de batería, un sólido backend SAMBA, una rutina de respaldo basada en AMANDA, una red alternativa y fácil acceso administrativo tanto de forma local como remota. El servidor no necesitaba una disponibilidad constante, por lo que tuve mucho tiempo para probarlo durante la semana, pero requería disponibilidad en momentos específicos durante el día laboral. Se usó bien y estuve justificadamente orgulloso de él durante varios meses.

    Y luego, una semana, mi servidor de archivos se quedó sin espacio en el disco duro. No hay problema: lo había construido para tener almacenamiento expandible, por lo que hubiera sido fácil caminar hasta el servidor, conectar una nueva unidad y continuar mi día. Excepto por una pequeña falla: los discos duros no se podían intercambiar en caliente en el hardware que había comprado. (¿Quién sabía que había servidores en rack sin bahías de unidades intercambiables en caliente?) Se tuvo que apagar todo el sistema para agregar almacenamiento y, por supuesto, sucedió un viernes por la tarde cuando el trabajo de todos había terminado.

    Lección aprendida: la resiliencia no es un punto fijo en el tiempo. No diseñas un sistema para que sea perfecto en un momento específico; lo diseñas para que pueda fallar en cualquier momento.

    Es difícil detectar las debilidades de su proyecto a menos que cause errores en momentos y lugares inesperados.

    El caos fortalece el orden

    Pensé que las pruebas rigurosas eran un lujo. Pensé que era algo que los grandes equipos podían permitirse hacer porque ciertamente tenían personal de control de calidad dedicado sentado en los laboratorios ajustando y desmontando copias al carbón de lo que está en producción.

    Sin embargo, como he tenido el privilegio de trabajar en equipos cada vez más grandes, descubrí que más personas significan que hay más potencial para que se realicen las pruebas. Nunca garantiza que las pruebas se realizarán realmente.

    La ingeniería del caos es una práctica que cualquiera puede adoptar. Hable con su departamento, forme un equipo, forme un plan. Configure el monitoreo, haga que la operación de su clúster sea transparente, invite a preguntas y desafíos. Obtenga un plan de ingeniería del caos formalizado porque el caos tensa el orden y, en última instancia, puede fortalecerlo.

    Kubernetes puede ser sorprendentemente divertido

    La gente a veces me pregunta qué hago con mi clúster Kubernetes de Raspberry Pi. Por supuesto, personalmente no ejecuto ningún servicio vital en mi pequeña nube híbrida abierta. Pero resulta que hay mucho para disfrutar con una superordenador en miniatura (bueno, eso es genial para mí de todos modos). Mirar los hermosos tableros de Grafana y jugar Doom con pods es divertido, pero también lo es la configuración, el desafío de probar el rendimiento de mi clúster después de que un nodo se elimine repentinamente de la red, tratando de ver cuántas veces una tarjeta SD puede sobrevivir a una eliminación incorrecta. (Hasta ahora, probablemente gracias a ext4), configure dos contenedores para que interactúen entre sí, trate con el espacio de nombres lógico y las estructuras de pod, y así sucesivamente.

    Al final del día, Kubernetes me dio mi nube y, francamente, me encanta tener ese tipo de poder al alcance de mi mano.

    La ingeniería del caos te da permiso para ser un poco salvaje. Te anima a ser metódicamente imprudente. Y al final, obtienes un sistema más resistente.

    Descarga el libro electrónico

    Por supuesto, no puedes simplemente intentar destruir tu ordenador sin rumbo fijo y llamarlo ingeniería del caos. Sin disciplina, documentación y mitigación, es solo un caos. Para asegurarse de dividir las cosas de manera responsable e inteligente, descargue Ingeniería del caos para Kubernetes. ¡Y luego deja escapar a los monos del caos!

    Artículos de interés

    Subir