Saltar al contenido principal

CronJob para Reiniciar MariaDB

⚠️ CronJob Desactivada
Este CronJob está suspendido temporalemente debido a que ya se aumentaron los recursos de la plataforma por lo que no es necesario mantener esta CronJob funcionando. 7PM Venezuela - 10/09/2025

Introducción

Esta documentación describe la configuración de un CronJob en Kubernetes que reinicia el pod mariadb-0 en el namespace mediawiki-production cada 2 días. El objetivo principal de este CronJob es liberar recursos y evitar problemas de rendimiento en el servidor.

Este CronJob soluciona el problema que a partir de cierta cantidad de días pod de mariadb-0 empiece a consumir una gran cantidad de recursos de la memoria RAM, lo cuál ocaciona muchas caídas para el Cluster.

⚠️ Advertencia:
Si en el futuro los recursos de la infraestructura mejoran significativamente, se recomienda eliminar este CronJob, ya que podría no ser necesario y mantenerlo podría generar una sobrecarga administrativa innecesaria además de causar problemas.

CronJob: Reiniciar MariaDB

Descripción

El CronJob está configurado para eliminar el pod mariadb-0, lo que provoca que Kubernetes lo reinicie automáticamente. Esto ayuda a gestionar el consumo de recursos y a prevenir que el servidor se quede sin memoria.

Configuración del CronJob

El CronJob se creó con la siguiente configuración:

apiVersion: batch/v1
kind: CronJob
metadata:
name: reiniciar-mariadb
namespace: mediawiki-production
spec:
schedule: "0 0 */2 * *" # Ejecuta el job cada 2 días a la medianoche
concurrencyPolicy: Forbid
suspend: false
jobTemplate:
metadata:
name: reiniciar-mariadb
namespace: mediawiki-production
spec:
parallelism: 1
completions: 1
backoffLimit: 1
template:
metadata:
labels:
app: reiniciar-mariadb
spec:
containers:
- name: reiniciar-mariadb
image: bitnami/kubectl:latest
command:
- /bin/sh
- -c
- |
kubectl delete pod mariadb-0 -n mediawiki-production
resources:
limits:
cpu: 100m
memory: 100Mi
restartPolicy: Never
terminationGracePeriodSeconds: 30

Roles y RoleBindings

Descripción

Para permitir que el CronJob elimine el pod mariadb-0, se creó un Role y un RoleBinding en el namespace mediawiki-production.

Role: mariadb-pod-delete-role

Este Role permite la acción de eliminar pods en el namespace mediawiki-production.

Configuración del Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: mediawiki-production
name: mariadb-pod-delete-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["delete"]

RoleBinding: mariadb-pod-delete-rolebinding

Este RoleBinding vincula el Role anterior a la cuenta de servicio default, permitiendo que el CronJob tenga los permisos necesarios para eliminar el pod.

Configuración del RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mariadb-pod-delete-rolebinding
namespace: mediawiki-production
subjects:
- kind: ServiceAccount
name: default
namespace: mediawiki-production
roleRef:
kind: Role
name: mariadb-pod-delete-role
apiGroup: rbac.authorization.k8s.io

Ejecución Manual desde OpenLens

Para ejecutar manualmente un CronJob desde OpenLens, sigue estos pasos:

  1. Abre OpenLens y conéctate al cluster correspondiente
  2. En el menú lateral izquierdo, navega hasta la sección "CronJobs"
  3. Localiza el CronJob que deseas ejecutar en la lista
  4. Haz clic en los tres puntos en el CronJob con el nombre "reiniciar-mariadb" que aparece en lista.
  5. En el menú desplegable, selecciona "▶️ Trigger"
  6. El CronJob comenzará a ejecutarse inmediatamente

Una vez iniciada la ejecución, puedes monitorear el estado del Job generado en la pestaña "Jobs" o revisar los logs del Pod creado en la sección "Pods".

Conclusión

Con esta configuración, el CronJob se ejecuta cada 2 días, eliminando el pod mariadb-0 y permitiendo que Kubernetes lo reinicie. Esto ayuda a gestionar el consumo de recursos y a mantener el rendimiento del servidor. Los Roles y RoleBindings creados aseguran que el CronJob tenga los permisos necesarios para realizar esta acción.

Nota: Monitoree regularmente el rendimiento del servidor y evalúe si este CronJob sigue siendo necesario. Si los recursos de la infraestructura mejoran, lo mejor será eliminarlo para evitar problemas a largo plazo.