Instalación del ejecutor de CI Gitlab de Kubernetes (k8s)
Trabajos->Etapa->Pipeline
En realidad, un pipeline es equivalente a una tarea de construcción y puede incluir muchos procesos, como instalar dependencias, ejecutar pruebas, compilar e implementar servidores de pruebas. , implementar servidores de producción, etc. Cualquier envío o fusión de una solicitud de fusión desencadenará la construcción del canal, como se muestra en la siguiente figura:
Las etapas representan una etapa de construcción, que es el proceso mencionado anteriormente. Puede definir varias etapas en una tubería, que tendrá las siguientes características:
La relación entre etapas y tuberías es la siguiente:
Trabajos representa trabajos de construcción, lo que significa que en una etapa trabajo completado. Puede definir varios trabajos en etapas, y estos trabajos tendrán las siguientes características:
La relación entre trabajos y etapas es la siguiente:
Si entendemos los conceptos básicos anteriores, Puede que encuentres una pregunta, ¿dónde está nuestra tarea de construcción? En el pasado, Jenkins podía usarse para ejecutar tareas de compilación en nodos maestros y esclavos, y era Gitlab Runner el que realizaba nuestras tareas de compilación de Gitlab CI.
Sabemos que en la mayoría de los casos, las tareas de compilación consumen muchos recursos del sistema. Si la tarea de compilación la ejecuta directamente Gitlab, obviamente el rendimiento de Gitlab se reducirá considerablemente. La función más importante de GitLab CI es gestionar el estado de construcción de cada proyecto. Por lo tanto, sería mucho mejor dejar las tareas que desperdician recursos, como ejecutar tareas de construcción, a corredores independientes de Gitlab. Más importante aún, Gitlab Runner se puede instalar en diferentes máquinas, incluso en la nuestra, sin afectar en absoluto a Gitlab.
Instalar Gitlab Runner es muy sencillo. Podemos instalar completamente la documentación oficial:/runner/install/. Por ejemplo, podemos usar directamente binario, Docker, etc. De manera similar, todavía instalamos Gitlab Runner en el clúster de Kubernetes para que nuestro clúster pueda administrar de manera uniforme los servicios relacionados con Gitlab.
1. Verificar el clúster de Kubernetes
Ejecute el siguiente comando para verificar el clúster de Kubernetes:
El comando cluster-info muestra el estado del clúster del enlace actual. y la lista de servicios de clúster disponibles.
2. Obtenga el token de registro de Gitlab CI
Gitlab se ha instalado correctamente en la sección anterior. Abra la página hwzxgit.sinoing.net en el navegador, luego inicie sesión en la página de administración/admin y luego haga clic en Runner en la barra de navegación. Puedes ver que esta página tiene dos parámetros generales, uno es la URL y el otro es el Token de Registro. Los siguientes pasos requieren estos dos valores de parámetros.
Figura 1,
Del mismo modo, todos los objetos de recursos relacionados con Runner se instalan bajo el espacio de nombres kube-ops. Primero, la variable de entorno (Runner-cm. Yaml) se pasa a través del recurso ConfigMap:
Cabe señalar que el valor correspondiente a CI_SERVER_URL debe apuntar a la URL de la instancia de Gitlab (puede ser un dirección de red externa o un clúster de Kubernetes La dirección DNS del servicio interno (ya que Runner también se ejecuta en un clúster de Kubernetes), más /ci (/ci). Además, se agregaron algunos límites de recursos para las operaciones de construcción de contenedores y se pueden cambiar según sea necesario.
Además de la configuración anterior relacionada con algunas variables de entorno, también necesita un pequeño script para registrarse, ejecutar y cerrar sesión en Gitlab CI Runner. La cancelación del registro de la rueda solo se activa cuando Kubernetes finaliza el Pod normalmente (señal TERM). Si el Pod se cierra a la fuerza (señal SIGKILL), el corredor no cerrará sesión. Debes limpiar manualmente este corredor asesinado. El archivo de lista de configuración es el siguiente: (runner-scripts-cm.yaml)
Puedes ver que se requiere un GITLAB_CI_TOKEN y luego copiar el token del corredor Gitlab CI en la imagen siguiente para crear un secreto de Kubernetes. objeto. Marcado de codificación Base64:
Luego puedes usar Statefulset para escribir un objeto controlador para el Runner en ejecución real. Primero, al comienzo de la ejecución, intente cerrar la sesión de todos los corredores con el mismo nombre. Esto es especialmente útil cuando se pierde un nodo (es decir, evento NodeLost). Luego intenta volver a registrarte y comienza a correr.
Cuando el Pod se detiene normalmente, el Runner ejecutará el comando de cancelación de registro para intentar cancelarse, por lo que Gitlab ya no podrá usar este Runner. Esto se hace a través de ganchos en el ciclo de vida del Pod de Kubernetes.
Además, al usar envFrom para especificar Secrets y ConfigMaps como variables de entorno, el archivo de lista de recursos correspondiente es el siguiente: (runner-statefulset.yaml).
Puedes ver que utilizamos una cuenta de servicio llamada gitlab-ci para crear un nuevo archivo de lista de recursos rbac: (runner-rbac.yaml).
4. Cree un objeto de recurso Runner
Después de preparar el archivo de lista de recursos, cree directamente el objeto de recurso anterior:
Una vez completada la creación, puede véalo por estado del Pod para determinar si el corredor se está ejecutando correctamente:
Puede ver que dos instancias del Runner se han ejecutado exitosamente (dependiendo del número de copias en la lista StatefulSet) y luego cambie a la página Runner en la página de administración de Gitlab:
En este punto, se completa la instalación de Gitlab CI Runner en Kubernetes. Por supuesto, algunas configuraciones del Runner se pueden cambiar según sea necesario, como agregar etiquetas.