Aplicador de Kube es un servicio que permite la implementación continua de objetos de Kubernetes mediante la aplicación de archivos de configuración declarativos desde un repositorio de Git a un clúster de Kubernetes.
kube-applier se ejecuta como un pod en el clúster y monitorea Git repositorio para garantizar que los objetos del clúster estén actualizados con los archivos de especificación relevantes (JSON o YAML) en el repositorio.
En el intervalo especificado, kube-applier realiza una «ejecución completa», emitiendo el comando kubectl apply para todos los archivos JSON y YAML en el repositorio.
Cuando se realiza una nueva confirmación en el repositorio, kube-applier realiza una «ejecución rápida» que solo emite el comando de aplicación para los archivos que han cambiado desde la última ejecución.
La ejecución rápida y la ejecución completa se procesan por separado y simultáneamente.
kube-applier proporciona una página de estado y proporciona métricas de seguimiento.
- Ir (1.7+)
- Ventana acoplable (17.05+)
- Clúster de Kubernetes
- kube-applier generalmente es compatible con cualquier versión del servidor Kubernetes, suponiendo que tenga un cliente kubectl compatible instalado en su Dockerfile.
- La versión de kubectl especificada en Dockerfile debe ser la misma versión secundaria que el servidor API del clúster, o una versión detrás del servidor (por ejemplo, el cliente 1.3 y el servidor 1.4 están bien, pero el cliente 1.4 y el servidor 1.3 no lo están).
- Hay varios problemas conocidos
kubectl applyEsto puede afectar su uso de kube-applier. Algunos ejemplos:- Las versiones anteriores a la 1.6.0 tienen muchos problemas conocidos relacionados con el uso
kubectl applyAplique el objeto ThirdPartyResource. - Las versiones 1.5 y 1.6 anteriores a la 1.5.8 y la 1.6.3 no eran compatibles debido a problemas con el espacio de nombres, solucionados aquí.
- Las versiones anteriores a la 1.6.0 tienen muchos problemas conocidos relacionados con el uso
Descargue el código fuente y cree la imagen del contenedor.
$ ve a github.com/box/kube-applier
$ cd $GOPATH/src/github.com/box/kube-applier
$ hacer contenedor
Debe insertar la imagen en el registro para hacer referencia a ella en la especificación del contenedor de Kubernetes.
Especificaciones del contenedor
Recomendamos ejecutar kube-applier como una implementación (ver demostración/ por ejemplo, archivo YAML). Solo admitimos la ejecución de una réplica a la vez en este momento, por lo que si el nodo que sirve la réplica falla antes de reprogramar a otro nodo, la aplicación puede experimentar brechas.
importante: Los pods que contienen contenedores kube-applier deben generarse en un espacio de nombres que tenga acceso de escritura a todos los espacios de nombres en el servidor API (por ejemplo, kube-system).
requerido
REPO_PATH– (cadena) Ruta absoluta al directorio que contiene el archivo de configuración a aplicar. Debe ser un repositorio de Git o una ruta dentro de él. Todos los archivos .json y .yaml en este directorio (y sus subdirectorios) se aplicarán a menos que estén en la lista negra o excluidos de la lista blanca.LISTEN_PORT– (int) Puerto del contenedor. Este debe ser el mismo puerto que se especifica en la especificación del contenedor.
Electivo
SERVER– (String) La dirección del servidor API de Kubernetes. De forma predeterminada, kube-proxy gestiona la detección de servidores API. Si kube-proxy no está configurado, esta variable de entorno debe usarse para especificar la dirección del servidor API (que luego se escribe en el archivo kubeconfig del backend). La autenticación en el servidor API se maneja mediante tokens de cuenta de servicio. Para obtener más información, consulte Acceso a clústeres.BLACKLIST_PATH– (String) Ruta a un archivo de «lista negra» que especifica los archivos que no deben aplicarse.Esta ruta debe ser absoluta (por ejemplo,/k8s/conf/kube_applier_blacklist), no relativo aREPO_PATH(aunque es posible que desee verificar el archivo de la lista negra en el repositorio). El archivo de la lista negra en sí debe ser un archivo de texto claro con una ruta de archivo por línea.Cada uno de estos caminos debe ser relativo aREPO_PATH(por ejemplo, siREPO_PATHestablecer como/git/repo, el archivo que se incluirá en la lista negra es/git/repo/apps/app1.json, La línea en el archivo de la lista negra debe serapps/app1.json).WHITELIST_PATH– (String) Ruta a un archivo de «lista blanca» que se usa para que la aplicación considere un subconjunto específico de archivos del repositorio. Solo los documentos incluidos en la lista blanca se considerarán para la solicitud. Una lista en blanco (o una variable de entorno sin establecer) significa que todos los archivos del repositorio se pueden aplicar. Si el archivo está tanto en la lista blanca como en la lista negra, el archivo no se aplica. El formato de las variables de entorno y el archivo en sí debe ser el mismo que el de la lista negra anterior.
notas Los archivos de lista negra y lista blanca admiten comentarios de línea. Si el primer carácter que no es un espacio en blanco en la línea es #, la línea se ignorará.
POLL_INTERVAL_SECONDS– (int) Número de segundos de espera entre cada comprobación de nuevas confirmaciones en el repositorio (predeterminado 5). Establézcalo en 0 para deshabilitar el período de espera.FULL_RUN_INTERVAL_SECONDS– (int) Segundos entre ejecuciones completas automáticas (predeterminado 300 o 5 minutos). Establézcalo en 0 para deshabilitar el período de espera.DIFF_URL_FORMAT– (cadena) Si se especifica, permite que la página de estado muestre un enlace al código fuente de la referencia de diferencias para una confirmación específica.DIFF_URL_FORMATDebe ser la URL de un repositorio remoto alojado que admita la vinculación para confirmar hashes.Reemplace la parte del hash de confirmación con «%s» para que kube-applier la complete (por ejemplo,https://github.com/kubernetes/kubernetes/commit/%s).LOG_LEVEL– (int) establecer-vtodas las banderaskubectlse ejecuta el comando. Utilice esta opción para configurar un registro más detallado.Si no se especifica, entonces-vbandera no establecidakubectlComandos que por defecto tienen el nivel de detalle de registro estándar.
Hay dos formas de montar un repositorio Git en el contenedor kube-applier.
- Contenedor sidecar Git-sync
Git-sync mantiene actualizados los directorios locales con los repositorios remotos. El directorio local reside en el volumen vacíoDir compartido, que está montado en los contenedores git-sync y kube-applier.
Consulte el repositorio de git-sync para la configuración y el uso.
Monte el repositorio de Git desde el directorio del host. Esto puede ser útil cuando desea que kube-applier aplique cambios a los objetos sin verificar el archivo de especificaciones modificado en el repositorio remoto.
«rollo»: [
{
“hostPath”: {
“path”:
},
“name”: “repo-volume”
}
…
]
¿Qué sucede si el contenido del repositorio local de Git cambia mientras se ejecuta kube-applier?
Si hay cambios en el archivo $REPO_PATH Durante una ejecución de kube-applier, estos cambios pueden reflejarse o no en esa ejecución, dependiendo de cuándo se realizaron los cambios.
en vista de $REPO_PATH Un directorio es o reside en un repositorio de Git, y lo más probable es que la mayoría de los cambios estén asociados con confirmaciones de Git. Por lo tanto, los cambios en medio de una ejecución pueden actualizar el hash de confirmación HEAD, lo que desencadenará otra ejecución tan pronto como finalice la ejecución actual (independientemente de si los cambios son válidos en la ejecución actual). Sin embargo, los cambios no relacionados con la nueva confirmación de Git no activarán la ejecución.
Si elimino un archivo de configuración, ¿kube-applier eliminará el objeto de Kubernetes asociado?
No.Si el archivo es de $REPO_PATH directorio, kube-applier ya no aplicará archivos, pero kube-applier no Elimina el objeto de clúster descrito por el archivo.Estos objetos deben limpiarse manualmente usando kubectl delete.
En casos excepcionales, es posible que desee activar una ejecución de kube-applier sin verificar una confirmación o esperar la próxima ejecución programada (por ejemplo, algunos de sus archivos no se pueden aplicar debido a algunas condiciones de fondo en el clúster y ha corregido la última vez que se ejecutó). Esto se puede hacer a través del botón «Forzar ejecución» en la página de estado, que inicia la ejecución inmediatamente si no hay ninguna ejecución actualmente en curso, o pone en cola la ejecución para que comience después de que se complete la ejecución actual. Solo uno puede estar ejecutándose en la cola en un momento dado.
kube-applier aloja una página de estado en un servidor web, que se sirve en la URL del punto final del servicio. La página de estado muestra información sobre ejecuciones recientes de aplicaciones, que incluyen:
- tipo de ejecución
- hora de inicio y fin
- alfombrilla de ratón
- compromiso más reciente
- archivos incluidos en la lista blanca
- archivos en la lista negra
- Error
- La aplicación del documento es exitosa
La plantilla HTML para la página de estado se encuentra en templates/status.html, y static/ mantener activos adicionales.
kube-applier usa Prometheus para las métricas. Las métricas se alojan en el servidor web en /metrics (la interfaz de usuario de estado es la página de índice). Además de las métricas predeterminadas de Prometheus, se incluyen las siguientes métricas personalizadas:
- ejecutar_latencia_segundos – Un resumen que rastrea la duración de cada ejecución de la aplicación, etiquetado con el tipo de ejecución y un valor booleano para indicar si la ejecución fue exitosa (es decir, no hubo intentos fallidos de la aplicación).
- file_apply_count – Un contador para cada archivo que ha intentado la aplicación durante la vigencia del contenedor, incrementado con cada intento de aplicación y marcado por la ruta del archivo y el resultado del intento.
La API HTTP de Prometheus (consulte también la biblioteca Go) se puede utilizar para consultar el servidor de métricas.
