Como ecosistema Cuando se crea un recurso CronJob<\/strong>, lo que hace realmente Kubernetes<\/strong><\/a> es registrar una programaci\u00f3n en el tiempo. Cada 10 segundos el Controlador de CronJobs comprueba si hay programaciones que coincidan y de las que deba ocuparse<\/a>. Cuando llega el momento se\u00f1alado se crea un recurso Job, que deber\u00e1 hacerse cargo de la tarea para esa ejecuci\u00f3n espec\u00edfica. Finalmente cada Job crea un recurso Pod, que ser\u00e1 el ejecutor final.<\/p>\n Como probablemente se haya podido apreciar ya, esta aproximaci\u00f3n difiere significativamente del enfoque que tiene un Sistema Operativo. Lo que se observa aqu\u00ed es un desacoplamiento entre el sistema de programaci\u00f3n en el tiempo (Cron) y la gesti\u00f3n de las ejecuciones (Jobs). Esto permite al cl\u00faster (y por tanto al usuario) gestionar tareas ef\u00edmeras sin perder el control sobre ellas.<\/p>\n Cabe adem\u00e1s mencionar que los Jobs pueden crear uno o m\u00e1s Pods (permitiendo concurrencia\/paralelismo) a la vez que se aseguran que las tareas se completan satisfactoriamente. Sin embargo, este \u00faltimo comportamiento podr\u00eda crear complejidades adicionales ya que los contenedores ya incorporan su propia funcionalidad de gesti\u00f3n de fallos y reinicios.<\/strong> Este tema ser\u00e1 abordado en la siguiente secci\u00f3n.<\/p>\n Debe tenerse en cuenta que para configurar un CronJob<\/strong>, cada recurso subyacente debe configurarse tambi\u00e9n. Esto significa que la configuraci\u00f3n de un CronJob<\/strong> agrega sus propios par\u00e1metros<\/a> adem\u00e1s de las propiedades del Job<\/a> y de las especificaciones del Pod\/contenedor. Teniendo en cuenta que la mayor\u00eda de las operativas comunes se pueden entender y conseguir leyendo la documentaci\u00f3n, el prop\u00f3sito de esta secci\u00f3n es mostrar c\u00f3mo obtener ciertas funcionalidades avanzadas mediante la configuraci\u00f3n.<\/p>\n Cuando un contenedor detiene su ejecuci\u00f3n (ya sea por un fallo o despu\u00e9s de una ejecuci\u00f3n satisfactoria) existen una serie de acciones que se pueden tomar justo despu\u00e9s, las cuales son definidas (como de costumbre) por las directivas del propio recurso. Las acciones t\u00edpicas son reiniciar el contenedor (siempre o s\u00f3lo cuando ha sucedido alg\u00fan error) o bien no hacer nada. Pero, adem\u00e1s, los Jobs a\u00f1aden una capa de complejidad adicional que se encarga de que la tarea se termine adecuadamente. Esto quiere decir que la pol\u00edtica de reinicios se garantiza desde dos capas diferentes, que a su vez deben gestionarse desde dos partes diferentes.<\/p>\n Desde el lado de los contenedores, la directiva se llama restartPolicy<\/a>. En el lado de los Jobs, la pol\u00edtica se gestiona mediante la directiva backoffLimit<\/a>, la cual\u00a0 especifica el n\u00famero<\/strong> de fallos permitidos antes dejar de reiniciar la tarea. Teniendo ambas en cuenta, obtener la configuraci\u00f3n para un CronJob<\/strong> que pueda fallar sin reinicios se aproxima a lo siguiente.<\/p>\n Cuando se habla de un CronJob<\/strong> en espec\u00edfico, podr\u00edan coexistir varias ejecuciones. Dependiendo del tipo de operativa que caracterice a la tarea, la concurrencia podr\u00eda ser una forma de proceder para acelerar el procesamiento. Existen tres v\u00edas disponibles para gestionar c\u00f3mo se ejecutan los Jobs, las cuales son controladas mediante la directiva concurrencyPolicy<\/a>.<\/p>\n Mientras que la primera permite la concurrencia, las dos \u00faltimas apuestan por ejecuciones secuenciales. Una vez m\u00e1s, para seguir el estilo de los crones de la vieja escuela, la opci\u00f3n que m\u00e1s se aproxima es Allow<\/strong>. Por otra parte, las ejecuciones concurrentes pueden desembocar en efectos no deseados si no se tratan adecuadamente, y es algo que se debe tener en cuenta y tratarse con cautela.<\/p>\n Como ya se ha visto anteriormente, las nuevas ejecuciones de tareas pueden llegar a interferir con las anteriores, dependiendo de c\u00f3mo se establezcan las directivas de concurrencia. Existe una propiedad en la especificaci\u00f3n de los contenedores (terminationGracePeriodSeconds<\/a>) que se puede emplear para sobrellevar las consecuencias de interrumpir ejecuciones. Mediante su uso se puede definir un tiempo m\u00ednimo de ejecuci\u00f3n, de modo que aunque una nueva tarea fuerce la terminaci\u00f3n de una previa, se garantiza una terminaci\u00f3n gr\u00e1cil.<\/p>\n Una vez la configuraci\u00f3n pone de manifiesto lo que se pretende que haga el CronJob, los comandos b\u00e1sicos pueden ser utilizados para recuperar su estado<\/a> (informaci\u00f3n acerca de la programaci\u00f3n, el estado de ejecuci\u00f3n, logs, …). Al igual que en la secci\u00f3n anterior, las siguientes operativas cubren c\u00f3mo obtener algunas funcionalidades menos comunes.<\/p>\n La especificaci\u00f3n de los CronJobs<\/strong> contiene una propiedad llamada suspend<\/a> que permite deshabilitarlos. Ya sea de manera temporal o permanente, los CronJobs<\/strong> se pueden definir sin que ello implique que vayan a ser ejecutados (a pesar de lo que indiquen sus programaciones en el tiempo).<\/p>\n Echa un vistazo a la siguiente secci\u00f3n para descubrir m\u00e1s detalles sobre los efectos colaterales que esto podr\u00eda causar.<\/strong><\/p>\n Es ampliamente reconocido que las pruebas (comunmente llamados tests, del Ingl\u00e9s) son \u00fatiles para detectar efectos no deseados. Los CronJobs<\/strong> se pueden ejecutar manualmente incluso cuando est\u00e1n desactivados, por lo que mantenerlos en ese estado y poder ejecutarlos bajo circunstancias que sirvan para probarlos puede ayudar a validar que todo est\u00e1 correctamente configurado.<\/p>\n Despu\u00e9s de todo, no existir\u00eda la variedad si todo funcionase igual. Cada situaci\u00f3n tiene sus propias particularidades y caracter\u00edsticas especiales, por lo que cuando se trata de los CronJobs<\/strong> la cosa no es diferente. A lo largo de las siguientes l\u00edneas se presentar\u00e1n y tratar\u00e1n algunos casos poco frecuentes, de modo que las soluciones aportadas puedan ser reutilizadas (o, al menos, tenidas en consideraci\u00f3n).<\/p>\n En secciones anteriores se trat\u00f3 el tema del tiempo de ejecuci\u00f3n, de modo que se garantizase un tiempo m\u00ednimo antes de forzar la terminaci\u00f3n. Pero, \u00a1eh! \u00bfQu\u00e9 sucede con las ejecuciones que se alarguen en el tiempo m\u00e1s all\u00e1 de lo previsto? La motivaci\u00f3n (desde un punto de vista agn\u00f3stico) de los contenedores (y tambi\u00e9n la de Kubernetes<\/strong><\/a>) es la de ejecutar las tareas hasta el infinito y m\u00e1s all\u00e1. Los contenedores pueden fluir o pueden crashear<\/em> (fallar), pero no se deben terminar como una pr\u00e1ctica habitual. Siguiendo este principio, no existe ninguna forma de gestionar la expiraci\u00f3n del tiempo previsto desde la especificaci\u00f3n de los CronJobs\/Jobs\/Contenedores. \u00bfEntonces, es imposible implantar un tiempo m\u00e1ximo de ejecuci\u00f3n? \u2014 \u00a1No, no lo es! En este punto es donde el abanico de herramientas de Linux aparece al rescate. Existe un comando llamado timeout<\/a> que puede ser usado para ejecutar otro comando durante una cantidad espec\u00edfica de tiempo.<\/p>\n Aunque la utilidad anterior puede limitar el tiempo, el c\u00f3digo de salida de la ejecuci\u00f3n cuando lo hace, no es un c\u00f3digo exitoso; por lo que el contenedor entrar\u00e1 en un estado de fallo (que puede escalar en un reinicio si as\u00ed est\u00e1 especificado). Por otra parte, el estado del comando que se quiere ejecutar se puede preservar, pero entonces no se puede saber si fue terminado o no. Entonces, \u00bfc\u00f3mo tratar ambas situaciones? En el siguiente extracto de c\u00f3digo se puede hallar una propuesta que consigue terminar siempre de manera satisfactorio, a la vez que se devuelve retroalimentaci\u00f3n acerca de lo ocurrido en realidad.<\/p>\n Se produce un efecto colateral cuando se desactiva un CronJob<\/strong>, que consiste en que despu\u00e9s de haberse perdido 100 programaciones en el tiempo, el CronJob<\/strong> no se volver\u00e1 a ejecutar. Esta informaci\u00f3n ya se se\u00f1ala en la documentaci\u00f3n, pero se menciona de pasada y se trata como algo poco relevante. La soluci\u00f3n en este caso es volver a crear el recurso.<\/p>\n Se puede encontrar otro efecto no esperado cuando se trata con CronJobs<\/strong>, que consiste en que al reactivar uno de ellos (y a pesar del hecho de que el momento en el que se haga no coincida con el que tiene programado) se ejecuta inmediatamente. Esto sucede porque la ejecuci\u00f3n no es simplemente un evento aislado, sino una ventana de tiempo con una fecha l\u00edmite. Esto implica que cada ejecuci\u00f3n que se pierde (por la pol\u00edtica de concurrencia, o por estar el CronJob<\/strong> deshabilitado) incrementa un contador (hasta cierta cantidad, lo que probablemente est\u00e1 relacionado con el caso poco frecuente anterior). Entonces, llegado el momento, cuando el CronJob<\/strong> se vuelve a activar y se permite de nuevo su ejecuci\u00f3n, el controlador tiene en cuenta que existen programaciones pendientes. Si la ventana de tiempo no se ha cerrado a\u00fan, el CronJob<\/strong> comienza a ejecutarse.<\/p>\n Este comportamiento puede gestionarse estableciendo la directiva startingDeadlineSeconds<\/a> en un valor peque\u00f1o, de modo que la ventana de ejecuci\u00f3n no coincida con el momento de la reactivaci\u00f3n.<\/p>\n Cabe tener en cuenta que la anterior directiva startingDeadlineSeconds<\/em> se puede establecer en cualquier valor, pero no todos ellos van a causar el efecto deseado<\/strong>. Como ya se ha mencionado anteriormente el controlador de CronJobs se ejecuta cada 10 segundos, por lo que todo valor por debajo de diez segundos har\u00e1 que los CronJobs nunca se ejecuten<\/strong>. Se ha enviado una incidencia<\/a> al proyecto de website de Kubernetes<\/strong><\/a>, avis\u00e1ndoles de este caso. Seguramente en siguientes versiones se podr\u00e1 encontrar que ya se ha documentado, aunque no sea as\u00ed por el momento.<\/p>\n As\u00ed que no se debe olvidar establecer startingDeadlineSeconds<\/em> en un valor mayor que 10.<\/strong><\/p>\n Como habr\u00e1s podido comprobar, la diferencia entre los crones de Sistema Operativo y los de Kubernetes<\/strong><\/a> es mayor de la esperable desde un primer momento. Existen diferentes escenarios en un cl\u00faster y numerosas situaciones gestionar, y por eso se tratan. En algunos casos estaremos buscando un comportamiento similar al que podemos obtener en un Sistema Operativo, y en otros casos no, pero probablemente todos ellos pueden ser abordados. Por otra parte, que algo se incline mucho al multi-prop\u00f3sito tambi\u00e9n puede derivar (como los CronJobs<\/strong>) en una experiencia de configuraci\u00f3n con una mayor dificultad.<\/p>\n Afortunadamente siempre puedes contar con el equipo de Geko<\/a> (un equipo de ingenieros altamente cualificados), quienes profundizar\u00e1n en el tema hasta conseguir hacerlo sencillo para ti. \u00a1No olvides volver por el blog de Geko<\/a> para comprobar qu\u00e9 hay nuevo por aqu\u00ed! El equipo de Geko<\/a> siempre estar\u00e1 m\u00e1s que contento de verte por aqu\u00ed, y por supuesto \u00a1Ponte en contacto con nosotros para m\u00e1s informaci\u00f3n!<\/a><\/p>\n https:\/\/kubernetes.io\/docs\/tasks\/job\/automated-tasks-with-cron-jobs\/<\/a> Introducci\u00f3n Hoy en d\u00eda, y cada vez m\u00e1s, es com\u00fan que las empresas migren algunas partes de su infraestructura (o incluso la compa\u00f1\u00eda entera) al cloud. Hay dos principales enfoques: Permanecer lo mas cerca posible de la antigua arquitectura usando VMs, o apostar por flexibilidad\/escalabilidad\/disponibilidad y buscar una nueva perspectiva mediante el uso de un […]<\/p>\n","protected":false},"author":38,"featured_media":5402,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[18],"tags":[37],"yoast_head":"\ncompleto<\/del> grande, Kubernetes<\/strong><\/a> provee por su cuenta algunas de las funcionalidades anteriormente mencionadas, de modo que los requerimientos del d\u00eda a d\u00eda puedan ser atendidos y gestionados. Sin embargo, aparecen nuevas operativas y posibilidades cuando se habla de cl\u00fasteres y contenedores. A lo largo de las siguientes l\u00edneas se describir\u00e1 c\u00f3mo Kubernetes<\/strong><\/a> ha solucionado la funcionalidad Cron, as\u00ed como la mayor\u00eda de sus nuevas caracter\u00edsticas y detalles ocultos.<\/p>\n1. C\u00f3mo funcionan los CronJobs en Kubernetes realmente<\/h2>\n
![\"cronjob-job-pod\"](\"https:\/\/geko2.factoryfy.com\/wp-content\/uploads\/diagram1.png\")
<\/p>\n2. C\u00f3mo configurar los detalles avanzados<\/h2>\n
Gestionar los errores<\/h3>\n
apiVersion: batch\/v1beta1\r\nkind: CronJob\r\n...\r\nspec:\r\n ...\r\n jobTemplate:\r\n spec:\r\n backoffLimit: 0<\/strong>\r\n template:\r\n spec:\r\n containers:\r\n ...\r\n restartPolicy: Never<\/strong><\/pre>\n<\/div>\n
Ejecuciones Solapadas vs. Secuenciales<\/h3>\n
\n
Tiempo m\u00ednimo de ejecuci\u00f3n<\/h3>\n
3. Operar con los CronJobs como un Maestro<\/h2>\n
Habilitar\/Deshabilitar los CronJobs<\/h3>\n
# Deshabilitar un CronJob\r\nNOMBRE_CRONJOB=mi-cronjob-1\r\nkubectl patch cronjobs $NOMBRE_CRONJOB -p '{\"spec\" : {\"suspend\" : true }}'\r\n\r\n# Deshabilitar TODOS los CronJobs\r\nkubectl get cronjobs | grep False | cut -d' ' -f 1 | xargs kubectl patch cronjobs -p '{\"spec\" : {\"suspend\" : true }}'<\/pre>\n<\/div>\nEjecutar CronJobs manualmente<\/h3>\n
NOMBRE_CRONJOB=mi-cronjob-1\r\nkubectl create job --from=cronjobs\/$NOMBRE_CRONJOB $NOMBRE_CRONJOB-ejec-manual-01<\/pre>\n<\/div>\n
4. Sacando a la luz los casos poco frecuentes<\/h2>\n
Tiempo m\u00e1ximo de ejecuci\u00f3n<\/h3>\n
containers:\r\n - name: \"mi-container-limitado-a-10s\"\r\n ...\r\n command: [\"bash\", \"-c\"]\r\n args:\r\n - \/usr\/bin\/timeout 10 bash -c 'bash -c \"com arg1\" && echo OK || echo KO-COM' || echo KO-TMP<\/pre>\n<\/div>\n
CronJobs que no se ejecutan despu\u00e9s de haber sido desactivados y activados de nuevo<\/h3>\n
CronJobs que se ejecutan fuera de su programaci\u00f3n despu\u00e9s de haber sido reactivados<\/h3>\n
CronJobs que no se ejecutan<\/h3>\n
Conclusi\u00f3n<\/h2>\n
Lectura adicional<\/h2>\n
\nhttps:\/\/kubernetes.io\/docs\/concepts\/workloads\/controllers\/cron-jobs\/<\/a>
\nhttps:\/\/kubernetes.io\/docs\/concepts\/workloads\/controllers\/job\/<\/a>
\nhttps:\/\/www.magalix.com\/blog\/kubernetes-patterns-the-cron-job-pattern<\/a>
\nhttps:\/\/medium.com\/@bambash\/kubernetes-docker-and-cron-8e92e3b5640f<\/a>
\nhttps:\/\/medium.com\/cloud-native-the-gathering\/how-to-write-and-use-kubernetes-cronjobs-3fbb891f88b8<\/a>
\nhttps:\/\/medium.com\/@hengfeng\/what-does-kubernetes-cronjobs-startingdeadlineseconds-exactly-mean-cc2117f9795f<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"