Lo que Kubernetes me enseñó sobre el desarrollo

Como desarrollador full-stack, especialmente desarrollador front-end, las tecnologías DevOps y cómo piensan los desarrolladores de DevOps siempre ha sido un misterio para mí. Cuando la empresa para la que trabajo lanzó una nueva aplicación de interfaz de línea de comandos (CLI) llamada Gatekeeper, entré en el mundo de DevOps y Kubernetes y lo que aprendí fue muy valioso. Ahora entiendo mucho mejor Kubernetes y la canalización de DevOps y puedo explicar mejor cómo nuestra aplicación CLI es compatible con ambos.

Aquí está mi historia.

Índice

    Sobre mí

    Mi nombre es Noaa Barki. He sido desarrollador full-stack durante más de cinco años y trabajo en una empresa fantástica llamada Datree, donde ayudamos a los desarrolladores e ingenieros de DevOps a evitar que las configuraciones incorrectas de Kubernetes (K8) lleguen a producción.

    Entendiendo el problema

    Imagina esto: has tenido una semana larga, pero ahora es viernes y estás soñando en paz, listo para un fin de semana largo. Sin embargo, tu fin de semana llega antes de lo esperado, porque a las 03:46 te despiertas con el timbre de tu teléfono después de 15 llamadas perdidas del trabajo. Aparentemente, olvidó agregar un límite de memoria en una de las distribuciones, lo que provocó una pérdida de memoria en uno de los contenedores, lo que provocó que todos los nodos de Kubernetes se quedaran sin memoria.

    ¿Cómo pudo pasar eso? Su equipo de DevOps se ha esforzado mucho en educar a los desarrolladores sobre los K8 y la importancia del límite de memoria.

    Para evitar incidentes como este, debe definir los requisitos para una solución ideal y buscar plataformas y bibliotecas que ayuden a evitar que las configuraciones incorrectas afecten su clúster. Los requisitos reales pueden variar según su infraestructura, pero este es un buen ejemplo:

    • Aplicar restricciones políticas al desarrollo: Una forma de hacer cumplir las restricciones antes de que apliquen recursos al clúster
    • Habilitar la gestión de restricciones: Gestión flexible de restricciones en un lugar dedicado en toda la organización, lo que permite a los administradores tener control total sobre todos sus sistemas
    • Educar sobre las mejores prácticas: Libere al equipo de DevOps de la necesidad constante de revisar, aislar y preparar para el futuro todos los peligros posibles en todos los casos de uso actuales y futuros que forman parte de la autodistribución.

    Trabajar como desarrollador significa resolver problemas de la vida real, pero a veces el contexto marca la diferencia. Debe comprender cómo ocurre un problema en primer lugar antes de poder trabajar para solucionarlo de manera efectiva.

    • ¿Por qué las organizaciones adoptan K8?
    • ¿Cuál es el papel del ingeniero DevOps?
    • Y sobre todo, ¿para quién estoy desarrollando mi aplicación?

    ¿Quiénes son los ingenieros de DevOps?

    Inicialmente, sabía muy poco sobre el carácter de los ingenieros de DevOps y casi nada sobre su tecnología, especialmente Kubernetes. He leído, investigado y entrevistado a mis amigos de DevOps sobre sus trabajos y responsabilidades. Hice preguntas como:

    • ¿Cuáles son tus metas diarias?
    • ¿Quiénes son sus clientes?
    • ¿Cómo son tus días?

    Me tomó un tiempo, pero después de unos meses finalmente encontré la respuesta o, para ser honesto, el coraje para experimentar el trabajo de DevOps.

    Sorprendentemente, lo que más me ayudó fue reconocer que pensamos en términos diferentes. Los ingenieros de DevOps necesitan hacer sus mentes más pequeñas. Comienzan con el componente de aplicación más pequeño, luego escalan y se basan en él, como una cebolla.

    Los desarrolladores, por otro lado, pueden comenzar desde el mismo componente de la aplicación, pero están acostumbrados a pensar en la dirección opuesta: desde el nivel superior hasta los bits y bytes del software. Los desarrolladores eliminan las capas, desde el servidor hasta el servicio, la función, la variable, su asignación de memoria, hasta el componente más pequeño. Todos trabajan en el lado opuesto de la tubería, pero ambos trabajamos en la misma tubería.

    Esto me hizo preguntarme, ¿qué pasaría si la solución estuviera en algún lugar del proceso, algo que ambas partes puedan integrar?

    La pregunta de si la solución debería ser parte de la tubería me llevó a pensar en qué más DevOps y los desarrolladores podrían tener en común. Pensé en mis flujos de trabajo como desarrollador y los comparé con los flujos de trabajo de los desarrolladores de DevOps hasta que, de repente, me di cuenta:

    Todos tenemos políticas.

    Porque no siempre se puede confiar en la adquisición

    Todos los desarrolladores e ingenieros tienen estándares y mejores prácticas que tratamos de mantener para tener más confianza en nuestro trabajo. Como desarrollador, utilizo principios de código limpio y SOLID, pruebas unitarias y pruebas de integración y trato de aprender todas las mejores prácticas de cada tecnología que uso.

    Una mañana le pregunté a mi director ejecutivo: "Como ingeniero de DevOps, ¿cuáles son sus políticas? ¿Qué usa para crear y administrar sus políticas?" Me miró a los ojos y dijo una palabra: "OPA".

    ¿Qué es la oferta pública de adquisición?

    OPA, que significa Open Policy Agent, es como un súper motor. Puede escribir todas sus políticas en él, luego ejecutarlo con cada entrada para verificar si viola alguna política y, de ser así, cómo. La idea principal detrás de la adquisición es la capacidad de desvincular la lógica de la formulación de políticas del uso de la aplicación de políticas.

    Supongamos que estamos trabajando en una arquitectura multiservicio. Es posible que sea necesario tomar decisiones de política, por ejemplo, cuando el microservicio recibe una solicitud de API (como una autorización). Esa lógica se basa en reglas proporcionadas en su organización, por lo que, en este caso, puede descargar y unificar toda su lógica de toma de decisiones en un servicio dedicado: OPA.

    Cómo usar la OPA

    1. Integrar con OPA: Si sus servicios están escritos en Go, puede integrar OPA como un paquete dentro de su proyecto. De lo contrario, puede implementar OPA como un demonio a nivel de host.
    2. Escriba y archive sus pólizas: Para definir sus políticas en la oferta pública de adquisición, debe escribirlas Rego y enviarlos a la oferta pública de adquisición. De esta forma, cada vez que utilice OPA para la aplicación de políticas, OPA consulta la entrada con respecto a estas políticas.
    3. Solicitar evaluación de póliza: Cuando la aplicación necesite tomar una decisión de política, enviará una solicitud de consulta API utilizando JSON, que contiene todos los datos solicitados a través de HTTP.

    Cuando la oferta pública de adquisición no es suficiente

    Como puede ver, OPA aborda la necesidad de administración y aplicación de políticas dentro de una organización porque es una excelente herramienta basada en utilidades y proporciona una excelente solución de infraestructura. Sin embargo, la oferta pública de adquisición también requiere mucho trabajo pesado y configuración, generalmente demasiado para una empresa en medio de un crecimiento intensivo.

    Cuando se trata de políticas en K8, OPA no está diseñado para equipos pequeños, porque los ingenieros de DevOps aún pueden dedicar demasiado tiempo a resolver emergencias. El uso de OPA no siempre es la mejor manera de hacer cumplir las políticas de K8, pero examinarlo me dio una idea de qué políticas hay en el mundo de DevOps.

    Usando ConfTest: ¡ya casi llegamos!

    ConfTest le permite escribir pruebas para cualquier archivo estructurado y está especialmente diseñado para usarse con CI o pruebas locales. Puede pensar en ello como una biblioteca de prueba de unidad de archivo estructurado. ConfTest se basa en OPA.

    El objetivo principal de ConfTest es su propio test mando:

    $ conftest test deployment.yaml

    Esto acepta la ruta a los archivos que desea probar, luego evalúa todas las políticas en esos archivos. De forma predeterminada, todas las políticas (pruebas unitarias) deben colocarse en un directorio llamado política, pero se puede anular. Como se basa en ofertas públicas de adquisición, las pólizas también deben redactarse en Rego.

    Además, ConfTest ofrece la capacidad de insertar y extraer políticas de cualquier registro de Open Container Initiative (OCI) (como Dockerhub, Quay.io y otros).

    El problema con ConfTest

    A primera vista, ConfTest parece la solución perfecta. No es necesario implementar un servicio como OPA, sin embargo, la capacidad de extraer y enviar desde registros OCI significa que puede unificar sus políticas en espacios dedicados y, por lo tanto, obtener más control. El verdadero poder de ConfTest es cuando se usa en el proceso de CI, lo que hace que el mantenimiento de K8 sea más claro para los desarrolladores que están acostumbrados a probar su propio código y a integrarse continuamente con él.

    Desafortunadamente, ConfTest no ofrece suficiente poder de administración de políticas. Unificar las políticas en una ubicación dedicada no es suficiente. ¿Qué sucede si desea ejecutar un conjunto de políticas en un servicio y otro en un servicio diferente? Todavía necesitaría una forma de aprovechar las pruebas en el proceso de integración continua y, al mismo tiempo, agrupar políticas.

    El estudio ConfTest me hizo darme cuenta de que el problema real no es solo hacer cumplir lo que enviará al clúster en este momento, sino también lo que puede o podría enviar mañana. Es como pruebas unitarias; existe para mantenerlo seguro de que cualquier cambio de código actual o futuro no dañará su producción existente. Necesita una solución que aplique políticas para el futuro y el pasado.

    DevOps, Kubernetes y yo

    Ahora que descarté otros métodos para hacer cumplir las políticas, es hora de ir a la siguiente aventura y comenzar a estudiar Kubernetes.

    Si eres un desarrollador que quiere embarcarse en una aventura de K8 conmigo, tengo tres consejos que me gustaría compartir contigo.

    K8 para desarrolladores: consejos y pautas

    • Más información sobre CI/CD: Si desea comenzar a aprender sobre K8, es esencial saber qué sucede exactamente en la canalización de CI / CD, las diferencias entre CI y CD, y por qué, por último pero no menos importante, su empresa lo está utilizando. Empecé con el componente más pequeño que creía entender, uno de nuestros microservicios, y dibujé un gráfico con todos los recursos y entornos conectados a él. He anotado todo lo que sucede desde el momento en que envío el código hasta que aparece mágicamente en mi entorno de producción.

    • Descubre tu plataforma: El uso de Kubernetes requiere mucho trabajo de configuración que puede no estar relacionado con Kubernetes en sí. Debe comprender cómo funciona su plataforma, qué recursos usa y necesita, y cómo están conectados desde una perspectiva de red.

    • Comprender la distribución: La implementación es probablemente la expresión más común que he escuchado en DevOps, pero ¿qué es realmente? ¿Es un recurso de Kubernetes? ¿Un proceso? ¿Un artefacto? En Kubernetes, distribución significa el "estado de mi aplicación".

    Sin embargo, lo que más me interesó fue la aplicación CLI de la que hablé anteriormente, Gatekeeper. Aprender sobre OPA Gatekeeper me enseñó la necesidad de ganar visibilidad y pasar por el ciclo de todas las políticas, ver qué no cumple y luego tomar medidas para arreglar las cosas. Además de mi artículo sobre Gatekeeper, también recomiendo leer Documentos del guardián.

    mi mantra personal

    La sensación de logro que proviene de brindar una solución utilizando la tecnología con creatividad e ingenio es la razón por la que soy desarrollador. Nuestro trabajo como desarrolladores no se trata de escribir código, sino de problemas de la vida real. No vale la pena corregir todos los errores, no vale la pena codificar todas las características y no vale la pena refactorizar todo el código desordenado. El código debe tener un propósito: de lo contrario, no debería escribirse en absoluto.

    Artículos de interés

    Subir