Kubernetes: Definición de log-driver y log-opt al especificar pod en RC y Pod

/ cc @ kubernetes / rh-cluster-infra

Hmm, creo que probablemente querremos poder establecer este grupo como predeterminado, y luego tal vez permitir que se anulen las definiciones de pod específicas.

cc @sosiouxme @smarterclayton @liggitt @jwhonce @jcantrill @bparees @jwforres

¿Puede describir cómo aprovecharía esto por contenedor (caso de uso)? Tradicionalmente, no exponemos opciones específicas de Docker directamente en contenedores a menos que se puedan abstraer de forma limpia en los tiempos de ejecución. Saber cómo le gustaría usar esto ayudará a justificarlo.

Tenga en cuenta que los registros de la ventana acoplable solo admiten los controladores json-file y journald, aunque imagino que esa lista podría expandirse.

Quizás lo que los usuarios realmente deseen es una selección de puntos finales de escritura de registro definidos, no la exposición a los detalles del controlador de registro.

@ncdc @smarterclayton Estoy de acuerdo con los dos, después de reconsiderar nuestro caso de uso interno, resulta que

1. Nuestra principal necesidad es proteger nuestros nodos. Enviamos los registros a un servidor de registros, pero si falla, los registros se recuperan en los registros internos de la ventana acoplable. En tal caso, para evitar la saturación de nodos, necesitamos un comportamiento de todo el clúster para el registro de Docker.
2. Exponer opciones específicas de la ventana acoplable en las definiciones de pod / Rc no es una buena idea como lo sugirió
3. Otra opción es realizar cambios en los archivos de configuración de kubelet y el código para manejar dicho comportamiento de registro.

Los cambios en las plantillas de sal para convertirlo en un valor predeterminado no deben ser
terriblemente difícil. Es realmente la configuración correcta del demonio (y
lidiar con cualquier cambio en la agregación de registros a través de fluentd en virtud de
seleccionando una fuente diferente)

El martes 13 de octubre de 2015 a las 10:55 a.m., Epo Jemba [email protected]
escribió:

@ncdc https://github.com/ncdc @smarterclayton
https://github.com/smarterclayton Estoy de acuerdo con ustedes dos, después
reconsiderando nuestro caso de uso interno, resulta que

1. Nuestra principal necesidad es proteger nuestros nodos. Enviamos los registros a un registro.
   servidor, pero si falla, los registros se recuperan en los registros internos de la ventana acoplable. De tal
   caso, para evitar la saturación de nodos, necesitamos un comportamiento de todo el clúster para
   registro de Docker
2. Exponer opciones específicas de la ventana acoplable en las definiciones de pod / Rc no es una
   buena idea como @smarterclayton https://github.com/smarterclayton
   lo sugirió. También estamos de acuerdo con una abstracción que permite la definición de alta
   comportamiento de registro de nivel si es posible
3. Otra opción es realizar cambios en los archivos de configuración de kubelet y
   código para manejar tal comportamiento de registro

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -147740136
.

:Pulgares hacia arriba:

Tenga en cuenta que ahora hay 9 controladores de registro . ¿Cuál es el consenso para conseguir este?

+1

En caso de que alguien no lo sepa, puede definir el controlador de registro predeterminado por nodo con una marca para el demonio de Docker ( --log-driver ). En mi entorno, configuro el controlador en journald esta manera. Para ser honesto, me cuesta pensar en un caso de uso para anular esto por contenedor.

La mayoría de los clústeres no querrán que sus registros estén "fuera de banda", entonces, ¿cuál es la habilitación de funciones que esto proporcionaría?

Además, desde la perspectiva de las operaciones, parece una pérdida de control. Actualmente establecemos los valores predeterminados y configuramos una pila de registro para agregar.

+1 en esto.
No poder controlar cómo se maneja el registro de la ventana acoplable implica que la única opción sensata de registro es usar las herramientas enviadas con k8s, lo cual es una limitación increíble.

@timothysc aquí nuestro caso de uso. Tenemos una infraestructura dinámica compleja (~ 100 máquinas) con muchos servicios existentes que se ejecutan en ellas, con nuestro propio logstash para recopilar registros. Bueno, ahora estamos tratando de trasladar nuestros servicios, uno por uno, a k8s y, para mí, no parece haber una forma limpia de integrar el registro entre nuestra infraestructura existente y los contenedores agrupados en k8s.

K8S es extremadamente obstinado sobre cómo recopilar registros. Esto podría ser excelente para quien esté comenzando desde cero en una infraestructura simple. Para todos los que trabajan en infraestructuras complejas a los que no les importaría profundizar e implementar un mecanismo de registro personalizado, simplemente no hay forma de hacerlo en este momento, lo cual es bastante frustrante.

Con suerte, tiene sentido.

Entonces, en su escenario, los registros son realmente "por aplicación", pero debe
asegurarse de que el host subyacente admita esos registros? Esa es la preocupación que estamos
discutiendo aquí, o lo hacemos a nivel de clúster o a nivel de nodo, pero si lo hacemos
nivel de pod, entonces el programador tendría que ser consciente de qué controladores de registro
están presentes donde. En la medida de lo posible, tratamos de evitarlo.

El lunes 23 de mayo de 2016 a las 10:50 a. M., Jacopo Nardiello < [email protected]

escribió:

+1 en esto.
No poder controlar cómo se maneja el registro de la ventana acoplable implica que el
La única opción de registro sensata es utilizar las herramientas enviadas con k8s, que es una
limitación increíble.

@timothysc https://github.com/timothysc aquí nuestro caso de uso. Tenemos una
infraestructura dinámica compleja (~ 100 máquinas) con una gran cantidad de
servicios que se ejecutan en ellos, con nuestro propio logstash para recopilar registros. Bueno ... nosotros
ahora estamos tratando de trasladar nuestros servicios, uno por uno, a k8s y a mí allí
no parece haber una forma limpia de integrar el registro entre nuestros
infraestructura y contenedores agrupados en k8s.

K8S es extremadamente obstinado sobre cómo recopilar registros. Esto puede ser genial
para quien empieza de cero en una infraestructura sencilla. Para
todos los demás que trabajan en infraestructuras complejas a las que no les importaría
profundizar e implementar un mecanismo de registro personalizado, simplemente no hay
manera de hacerlo en este momento, lo cual es bastante frustrante.

Con suerte, tiene sentido.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221002545

@smarterclayton Entiendo sus inquietudes y están bien ubicadas. No estoy seguro de si todo el clúster tiene que ser consciente de la existencia del registro a nivel de pod, lo que creo que deberíamos hacer es dar la opción de registrar pod stdout / stderr en algún lugar (¿un archivo basado en su nombre de pod actual?) para que cualquiera que esté dispuesto a implementar su solución personalizada, tenga un lugar persistente donde obtener el contenido. Esto abre un capítulo ENORME, ya que la rotación de registros no es trivial.

Estos son solo mis dos centavos, pero no podemos pretender que los escenarios complejos del mundo real simplemente renuncien a su infraestructura de registro existente.

¿Está especificando opciones de registro personalizadas por aplicación? Cuantos diferentes
conjuntos de opciones de registro que tendría por clúster? Si hay pequeños conjuntos de
config, una opción sería admitir una anotación en pods que sea
correlacionado con la configuración de nivel de nodo que ofrece una serie de "registros estándar
opciones ". Es decir, en el momento de inicio de kubelet, defina un" modo de registro X "(que define
opciones de registro y controlador personalizados), y el pod especificaría "
pod.alpha.kubernetes.io/log.mode=X ".

Otra opción más sería que expongamos una forma de permitir que los implementadores tengan la
oportunidad de mutar la definición del contenedor inmediatamente antes de comenzar
El contenedor. Eso es más difícil hoy porque tendríamos que serializar el
docker def a un formato intermedio, ejecútelo y luego ejecútelo
de nuevo, pero potencialmente más fácil en el futuro.

Finalmente, podríamos exponer pares clave-valor en la interfaz del contenedor que
se pasan directamente al motor del contenedor, no ofrecen garantías de API para
ellos y asegurarse de que PodSecurityPolicy pueda regular esas opciones. Eso podría
ser la escotilla de escape para las personas que llaman, pero no podríamos proporcionar ninguna
garantizar que seguirán funcionando en todas las versiones.

El jueves 26 de mayo de 2016 a las 5:34 a.m., Jacopo Nardiello [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton Entiendo sobre
sus inquietudes y están bien ubicadas. No estoy seguro de si todo el grupo
tiene que ser consciente de la existencia de registros a nivel de pod, lo que creo que
debería hacer es dar la opción de registrar pod stdout / stderr en algún lugar (un archivo
basado en su nombre de pod actual?) para que cualquiera que esté dispuesto a implementar su
solución personalizada, tendría un lugar persistente donde obtener el contenido.
Esto abre un capítulo ENORME, ya que la rotación de registros no es trivial.

Estos son solo mis dos centavos, pero no podemos fingir que el complejo del mundo real
Los escenarios simplemente abandonan su infraestructura de registro existente.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221823732

@smarterclayton has visto https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

No, gracias. Moviendo la discusión allí.

El jueves 26 de mayo de 2016 a las 11:23 a. M., Andy Goldstein [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton has visto # 24677
(comentario)
https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221903781

Hola,
Creo que esta es una característica importante que debe tenerse en cuenta para los kubernetes.
Habilitar el uso del controlador de registro de Docker puede resolver algunos problemas no triviales.

Yo diría que el registro en el disco es un anti-patrón. Los registros son inherentemente "estado" y, preferiblemente, no se deben guardar en el disco. Enviar los registros directamente desde un contenedor a un repositorio resuelve muchos problemas.

Configurar el controlador de registro significaría que el comando kubectl logs ya no puede mostrar nada.
Si bien esa función es "agradable de tener", la función no será necesaria cuando los registros estén disponibles en una fuente diferente.

Docker ya tiene controladores de registro para google cloud (gcplogs) y Amazon (awslogs). Si bien es posible configurarlos en el demonio de Docker, eso tiene muchos inconvenientes. Al poder configurar las dos opciones de la ventana acoplable:

--log-driver = Controlador de registro para el contenedor
--log-opt = [] Opciones de controlador de registro

Sería posible enviar etiquetas (para gcplogs) o awslogs-group (para awslogs)
específico de una vaina. Eso facilitaría encontrar los registros en el otro extremo.

He estado leyendo sobre cómo las personas manejan los registros en kubernetes. Muchos parecen instalar algunos raspadores elaborados que envían los registros a los sistemas centrales. Ser capaz de configurar el controlador de registro lo hará innecesario, liberando tiempo para trabajar en cosas más interesantes :)

También puedo agregar que algunas personas, incluyéndome a mí, quieren realizar la rotación de registros de la ventana acoplable a través de la opción '--log-opt max-size' en el controlador de registro JSON (que es nativo de la ventana acoplable) en lugar de configurar logrotate en el host. Por lo tanto, incluso exponer solo la opción '--log-opt' sería muy apreciado

He modificado el k8s, al crear la configuración del contenedor LogConfig.

+1
Usar el controlador de registro de la ventana acoplable para la recopilación de registros centralizada parece mucho más simple que crear enlaces simbólicos para los archivos de registro, montarlos en un contenedor especial con fluidez, seguirlos y administrar la rotación de registros.

Caso de uso para la configuración por contenedor: quiero iniciar sesión en otro lugar o de manera diferente para los contenedores que implemento y no me importa (o quiero cambiar) el controlador de registro para los contenedores estándar necesarios para ejecutar Kubernetes.

Ahí tienes. Por favor, haz que esto suceda.

Otra idea es que todos los contenedores reenvían registros al mismo punto final, pero al menos puede establecer diferentes valores de campos para diferentes contenedores de Docker en su servidor de registros.

Esto funcionaría para el controlador de la ventana acoplable gelf, si pudiéramos asegurarnos de que los contenedores de la ventana acoplable creados por Kubernetes tengan etiquetas personalizadas. Significado: algunos de los campos de un pod se pueden reenviar como etiquetas de contenedor de la ventana acoplable. (Quizás esto ya sea posible pero no sé cómo lograrlo).

Ejemplo sin Kubernetes, solo con el demonio docker y el controlador gelf. Tenga el demonio de la ventana acoplable configurado con: --log-driver=gelf --log-opt labels=env,label2 y cree un contenedor de la ventana acoplable:

docker run -dti --label env=testing --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

y otro contenedor docker:

docker run -dti --label env=production --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

De esta manera, en Graylog, puede diferenciar entre contenedores env=production y env=testing .

Actualmente utilizo tales opciones de demonio de docker:

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

@xmik , qué para confirmar es una característica existente o su propuesta con respecto

Actualmente utilizo tales opciones de demonio de docker:

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

Esas opciones del demonio de la ventana acoplable que uso actualmente ya funcionan. Kubernetes ya establece algunas etiquetas para cada contenedor de la ventana acoplable. Por ejemplo, al ejecutar docker inspect en el contenedor kube-apiserver:

 "Labels": {
   "io.kubernetes.container.hash": "4959a3f5",
   "io.kubernetes.container.name": "kube-apiserver",
   "io.kubernetes.container.ports": "[{\"name\":\"https\",\"hostPort\":6443,\"containerPort\":6443,\"protocol\":\"TCP\"},{\"name\":\"local\",\"hostPort\":8080,\"containerPort\":8080,\"protocol\":\"TCP\"}]",
   "io.kubernetes.container.restartCount": "1",
   "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
   "io.kubernetes.pod.name": "kube-apiserver-k8s-production-master-1",
   "io.kubernetes.pod.namespace": "kube-system",
   "io.kubernetes.pod.terminationGracePeriod": "30",
   "io.kubernetes.pod.uid": "a47396d9dae12c81350569f56aea562e"
}

Por lo tanto, esas opciones del demonio de la ventana acoplable funcionan.

Sin embargo, creo que ahora no es posible hacer que Kubernetes establezca etiquetas personalizadas en un contenedor de la ventana acoplable basándose en las especificaciones del Pod. Entonces, por ejemplo, --log-driver=gelf --log-opt labels=env,label2 no funciona.

¿Hay alguna novedad en este frente? ¡Tener la capacidad de especificar las etiquetas y luego aprovechar --log-opt labels<> sería bastante bueno!

@portante @jcantrill Solo para capturarlo aquí porque lo discutimos, aquí está el caso de uso para el que pensamos que esto podría ser útil:

Cuando los módulos de registro de registros comienzan a encontrar y registrar errores, la infra que recopila esos errores los capturará y los enviará al mecanismo de registro, que a su vez arroja y registra más errores.

Este bucle de retroalimentación se puede evitar mediante el uso de mecanismos de filtrado, pero eso es un poco frágil. Usar un controlador de registro diferente para grabar en un archivo y tener opciones de rotación parece ser una buena solución.

Mis 2 centavos.

Las soluciones actuales para iniciar sesión dentro de k8s son (AFAIK):

• contenedor sidecar enviando registros a alguna parte
• controlador de replicación enviando todos los registros a alguna parte
• el propio contenedor envía registros a alguna parte

El contenedor Sidecar me parece un poco exagerado. La estrategia del controlador de replicación parece buena, pero mezcla registros de contenedores de todas las implementaciones, y algunos usuarios ahora pueden querer eso, y en su lugar pueden querer registrar cada aplicación en algo diferente. Para estos casos, la última opción funciona mejor en mi humilde opinión, pero crea una gran cantidad de código replicado en todos los contenedores (por ejemplo: instalar y configurar el demonio de logentries).

Todo esto sería mucho más fácil si tuviéramos acceso a las banderas log-driver , por lo que cada implementación definiría cómo debe registrarse, utilizando las funciones nativas de Docker.

Puedo intentar implementar eso, pero probablemente necesite algo de ayuda, ya que no estoy familiarizado con la base de código de Kubernetes.

una vez que la tenencia múltiple se convierta en algo más importante, será más difícil de resolver correctamente.

Cada espacio de nombres puede ser un inquilino diferente, por lo que los registros de cada uno no deben agregarse necesariamente, sino que deben enviarse a ubicaciones específicas del inquilino.

Puedo pensar en algunas formas de hacer esto:

1. hacer un nuevo tipo de volumen, container-logs. Esto permite que un daemonset lanzado por un espacio de nombres particular acceda solo a los registros de sus propios contenedores. A continuación, pueden enviar los registros con el remitente de registros que prefieran al demonio de almacenamiento que prefieran.
2. Modifique uno de los remitentes de registros (o más), como fluentd-bit para leer el espacio de nombres en el que se encuentra el pod, y redirija los registros de cada pod a otro remitente de registros que se ejecute en ese espacio de nombres como servicio. Como fluentd. De nuevo, esto permite que el espacio de nombres configure su propio cargador de registros para enviarlo a cualquier backend de registros que deseen admitir.

@ caarlos0 @ kfox1111 Estoy de acuerdo con tus puntos. Este es un tema complejo, ya que requiere coordinación de instrumentación, almacenamiento, nodo y tal vez incluso más equipos. Sugiero tener una propuesta para la arquitectura de registro general presentada primero y luego discutir el cambio a esta vista coherente. Espero que esta propuesta aparezca en aproximadamente un mes, poniendo orden y resolviendo todos los problemas mencionados.

@crassirostris No estoy seguro de entender: si solo permitimos log-driver et al, no tenemos que ocuparnos del almacenamiento ni nada de eso, ¿verdad?

¿La ventana acoplable envía su STDOUT a cualquier controlador de registro que esté configurado en un contenedor, verdad? En cierto modo, pasamos la responsabilidad al contenedor ... me parece una solución bastante simple, pero, como dije, no conozco el código base, así que tal vez estoy simplemente equivocado ...

El problema es que el controlador de registro en la ventana acoplable no agrega ninguno de los metadatos de k8s que hacen que consumir los registros más adelante sea realmente útil. : /

@ kfox1111 hmm, tiene sentido ...

pero, ¿qué pasa si el usuario solo quiere los registros de la "aplicación", no los registros de kubernetes, no los registros de la ventana acoplable, solo la aplicación que se ejecuta dentro de los registros del contenedor?

En ese caso, me parece que log-driver funcionaría ...

@ caarlos0 Puede tener algunas implicaciones, por ejemplo, kubelet hace algunas suposiciones sobre el formato de registro en los registros de kubectl del servidor.

Pero aparte de todo, log-driver per se es específico de Docker y es posible que no funcione para otros tiempos de ejecución, esa es la razón principal para no incluirlo en la API.

@crassirostris eso tiene sentido ...

Dado que esta función no se agregará (como se describe en el problema), ¿tal vez este problema debería cerrarse (o editarse o lo que sea)?

@ caarlos0 Sin embargo, definitivamente queremos que la configuración del registro sea más flexible y transparente. ¡Sus comentarios serán apreciados sobre la propuesta!

El registro estándar de los contenedores se maneja actualmente fuera de banda dentro de Kubernetes. Actualmente confiamos en soluciones que no son de Kubernetes para manejar el registro, o en contenedores privilegiados que liberan a Kubernetes para obtener acceso al registro fuera de banda. El registro en tiempo de ejecución del contenedor es diferente según el tiempo de ejecución (docker, rkt, Windows), por lo que elegir cualquiera, como Docker --log-driver es crear equipaje futuro.

Sugiero que necesitemos el kubelet para devolver los flujos de registro dentro de la banda. Defina o elija un formato de registro JSON o XML mínimo, que recopile líneas de salida estándar de cada contenedor, agregue un clúster mínimo + espacio de nombres + pod + metadatos de contenedor, de modo que la fuente del registro se identifique dentro del espacio de Kubernetes y dirija la transmisión a un servicio de Kubernetes + Puerto. Los usuarios son libres de proporcionar cualquier servicio de consumo de registros que deseen. Tal vez Kubernetes proporcione un servicio de referencia / predeterminado que implemente el soporte de 'registros de kubectl'.

Sin un servicio de consumo de registro especificado, los registros se descartarán y no llegarán al disco en absoluto . Transmitir los registros en otro lugar, o escribir en almacenamiento persistente y rotar, todo eso es responsabilidad / decisión del Servicio.

El contenedor de tiempo de ejecución del contenedor de kubelet hace lo mínimo para extraer el stdout de cada tiempo de ejecución del contenedor y volverlo a poner en banda para que los servicios autohospedados de k8s lo consuman y procesen.

La especificación del contenedor en la implementación o el pod especificaría opcionalmente el servicio y el puerto de destino para el registro de salida estándar. Agregar metadatos de k8s para clúster + espacio de nombres + pod + contenedor sería opcional (por lo que la elección de sin procesar / sin tocar o con metadatos). Los usuarios tendrían la libertad de agregar todos los registros en un solo lugar, o agregarlos por inquilino, espacio de nombres o aplicación.

Lo más cercano a esto ahora es ejecutar un servicio que use 'kubectl logs -f' para transmitir registros de contenedor para cada contenedor a través del servidor API. Eso no suena muy eficiente o escalable. Esta propuesta permitiría una transmisión directa más eficiente desde el contenedor en tiempo de ejecución directamente al servicio o pod, con optimizaciones como preferir la implementación de registros o los pods de Daemonset en el mismo nodo y el contenedor que genera los registros.

Propongo que Kubernetes debería hacer lo mínimo para llevar de manera eficiente los registros de tiempo de ejecución del contenedor en banda, para cualquier solución de registro autohospedada, homogénea o heterogénea que creemos dentro del espacio de Kubernetes.

¿Qué piensa la gente?

@whereisaaron Realmente me gustaría no tener esta discusión ahora, cuando no tenemos todos los detalles sobre el ecosistema de tala en un solo lugar.

Por ejemplo, veo problemas en la red y en la máquina que interrumpen el flujo de registro, pero nuevamente, no quiero discutirlo todavía. ¿Qué tal si discutimos esto más tarde, cuando la propuesta esté lista? ¿Te parece razonable?

Ciertamente @crassirostris. Háganos saber aquí cuando la propuesta esté lista para pagar.

/ sig escalabilidad

Aunque tanto --log-driver como --log-opt son opciones para el demonio Docker y no características de k8s, sería bueno especificarlas en la especificación del pod k8s para:

1. controlador de registro por pod y no un solo controlador de registro a nivel de nodo
2. diferentes tipos de controladores de registro específicos de la aplicación (fluentd, syslog, journald, splunk) en el mismo nodo
3. establecer --log-opt para configurar la rotación de registros para un pod
4. por pod --log-opt configuraciones y ni un solo nivel de nodo --log-opt

AFAIK, nada de lo anterior se puede configurar a nivel de pod en la especificación de pod k8s hoy.

@vhosakot ninguno de los anteriores se puede establecer en ningún nivel en Kubernetes, porque esos no son conceptos de Kubernetes

@crassirostris exactamente! :)

Si k8s hace todo lo que hace Docker a nivel de pod / contenedor, ¿no será fácil para los usuarios? ¿Por qué hacer que los usuarios usen Docker para algunas cosas a nivel de pod / contenedor?

Y un amante de k8s que no sea un fanático de Docker puede hacer la misma pregunta.

@vhosakot Point es que hay una serie de otros tiempos de ejecución de contenedores que se pueden usar con K8, pero --log-opt solo existe en Docker. Crear tal opción en el nivel K8s estaría filtrando intencionalmente la abstracción. No creo que este sea el camino que queremos seguir. Si existe una opción, debería ser compatible con todos los tiempos de ejecución del contenedor, idealmente ser parte de CRI

No estoy diciendo que no habrá tal opción, estoy diciendo que no será una ruta directa a Docker.

@crassirostris Es cierto, parece que todo se reduce a si k8s debería hacer lo que CRI hace / permite a nivel de pod / contenedor, no específico de Docker.

Sí, absolutamente correcto

Aunque llegué tarde a esta discusión y tengo interés en ver implementada esta función, diría que existe una compensación entre tener un diseño bonito y tener una forma sencilla de configurar una solución de registro sana y uniforme. para el clúster. Sí, tener esta función implementada expondría la ventana acoplable interna, lo cual es un gran no, no, pero al mismo tiempo podría apostar una buena cantidad de dinero a que la mayoría de los usuarios de K8S usan la ventana acoplable como tecnología de contenedor subyacente y la ventana acoplable viene con una lista muy completa. de controladores de registro.

@ gabriel-tincu Actualmente no estoy convencido de que el FR original valga la pena

Docker viene con una lista muy completa de controladores de registro

Puede configurar el registro en el nivel de Docker durante el paso de implementación de K8 y usar cualquiera de estos controladores de registro, sin filtrar esta información a K8. Lo único que no puede hacer hoy es configurar esas opciones por contenedor / por pod (en realidad, puede tener una configuración con nodos dedicados y usar el selector de nodos), pero no estoy seguro de que sea una gran limitación.

@crassirostris Estoy de acuerdo en que puede configurar eso __antes__ de configurar el entorno, pero si hay una manera de actualizar activamente el controlador de registro de la ventana acoplable después de que el entorno ya está configurado, entonces se me escapa en este momento

@ gabriel-tincu @vhosakot la interfaz directa que solía existir entre k8s y Docker en los 'viejos tiempos' de> = 1.5 está obsoleta y creo que el código se eliminó por completo ahora. Todo entre el kubelet y los tiempos de ejecución como Docker (u otros como rkt, cri-o, runc, lxd) pasa por CRI. Ahora hay muchos tiempos de ejecución de contenedores y es probable que el propio Docker quede obsoleto y se elimine pronto a favor de cri-containerd + containerd .

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

@crassirostris ¿ algún movimiento sobre una propuesta, que podría tener la posibilidad de tala de contenedores dentro de la banda?

El registro del contenedor CRI se basa en archivos (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md) y la ruta del registro se define explícitamente:

/var/log/pods/PodUID/ContainerName/RestartCount.log

En la mayoría de los controladores de registro de la ventana acoplable https://docs.docker.com/config/containers/logging/configure/#supported -logging-drivers, creo que para el entorno de clúster, los más importantes son los controladores que ingieren el registro del contenedor en el clúster sistema de gestión de registros, como splunk , awslogs , gcplogs etc.

En el caso de CRI, no se debe utilizar ningún "controlador de registro de la ventana acoplable". Las personas pueden ejecutar un daemonset para ingerir registros de contenedores desde el directorio de registros de contenedores de CRI donde quieran. Pueden usar fluentd o incluso escribir un daemonset por sí mismos.

Si se necesitan más metadatos, podemos pensar en soltar un archivo de metadatos, extender la ruta del archivo o dejar que el daemonset obtenga metadatos de apiserver. Hay una discusión en curso sobre esto https://github.com/kubernetes/kubernetes/issues/58638

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida podrido
/ remove-lifecycle stale

/ eliminar-ciclo de vida podrido

alguna actualización sobre esto? Entonces, ¿cómo alguien que ejecuta k8s con contenedores Docker resolvió el registro en algún backend como AWS CloudWatch?

@ bryan831 es popular recopilar los archivos de registro del contenedor k8s usando fluentd o similar y agregarlos en su elección de back-end, CloudWatch, StackDriver, Elastisearch, etc.

Hay gráficos de Helm listos para fluentd + CloudWatch , fluentd + Elastisearch , -bit-> fluentd-> su elección , Datadog y probablemente otras combinaciones si

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Sería bueno poder personalizar las opciones de Docker --log-opt. En mi caso, me gustaría usar una etiqueta como '--log-opt tag = "{{. ImageName}} / {{. Name}} / {{. ID}}"' para emitir ImageName a los registros para saber de qué versión del contenedor provienen los registros. (Referencia: https://docs.docker.com/config/containers/logging/log_tags/)

/ remove-lifecycle stale

@ pmahalwar-intertrust puede pasar el mismo --log-opt al demonio de la ventana acoplable, lo que afectará a todos sus contenedores ...

@ pmahalwar-intertrust los registros recopilados de containerd por kubernetes ya incluyen metadatos extensos, incluye cualquier etiqueta que hayas aplicado al contenedor. Si lo recopila con fluentd obtendrá todos los metadatos, por ejemplo, como en la entrada de registro a continuación.

{
    "log": " - [] - - [25/Oct/2018:06:29:48 +0000] \"GET /nginx_status/format/json HTTP/1.1\" 200 9250 \"-\" \"Go-http-client/1.1\" 118 0.000 [internal] - - - - 5eb73997a372badcb4e3d993ceb44cd9\n",
    "stream": "stdout",
    "docker": {
        "container_id": "3657e1d9a86e629d0dccefec0c3c7624eaf0c4a11f60f53c5045ec0839c37f06"
    },
    "kubernetes": {
        "container_name": "nginx-ingress-controller",
        "namespace_name": "ingress",
        "pod_name": "nginx-ingress-dev-controller-69c644f7f5-vs8vw",
        "pod_id": "53514ad6-d0f4-11e8-a04c-02c433fc5820",
        "labels": {
            "app": "nginx-ingress",
            "component": "controller",
            "pod-template-hash": "2572009391",
            "release": "nginx-ingress-dev"
        },
        "host": "ip-172-29-21-204.us-east-2.compute.internal",
        "master_url": "https://10.3.0.1:443/api",
        "namespace_id": "e262510b-180a-11e8-b763-0a0386e3402c"
    },
    "kubehost": "ip-172-29-21-204.us-east-2.compute.internal"
}

¿Todavía no hay ningún plan para admitir estas funciones?
--log-driver = Controlador de registro para el contenedor
--log-opt = [] Opciones de controlador de registro

Hola @lifubang No puedo hablar de los planes de nadie, pero el demonio que soportaba esas características, dockerd ya no es parte de Kubernetes (vea la discusión anterior que cubre eso).

Aún puede instalarlo opcionalmente si lo desea, por lo que es posible que pueda hacerlo para usar los antiguos controladores de registro dockerd . Esa opción se analiza aquí:
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

Pero usar un servicio de registro dedicado como fluentd es el enfoque sugerido. Puede implementarlo globalmente para su clúster o por pod como un sidecar. El inicio de sesión en Kubernetes se analiza aquí:
https://kubernetes.io/docs/concepts/cluster-administration/logging/

Recomiendo encarecidamente fluentd como lo describe @whereisaaron

En lo que respecta a esta solicitud de función en la que se está trabajando ... la hoja de ruta arquitectónica de kubernetes tiene un registro en la sección "Ecosistema" de cosas que no son realmente "parte" de kubernetes, por lo que dudo que tal característica alguna vez sea compatible de forma nativa.
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md#summarytldr

Recomiendo encarecidamente no usar fluentd, ya que tiene varios errores que pueden hacer que su vida sea h * ll al ejecutar k8s

in_tail evita que Docker elimine el contenedor https://github.com/fluent/fluentd/issues/1680.

in_tail elimina la posición del archivo sin seguimiento durante la fase de inicio. Significa que el contenido de pos_file está creciendo hasta que se reinicia y puede consumir una tonelada de escaneo de la CPU a través de él cuando sigue muchos archivos con la configuración de ruta dinámica.
https://github.com/fluent/fluentd/issues/1126.

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Gracias por tu experiencia @roffe. fluent / fluentd # 1680 era un problema en k8s 1.5 y no usamos 'in_tail' en ese entonces por esa razón. Dado que k8s se movió al registro containerd , ¿no parece ser todavía una cosa? No hemos visto ningún impacto detectable de fluent / fluentd # 1126.

Recomendó contra fluentd . ¿Qué recomendarías en su lugar? ¿Qué usa personalmente en lugar de fluentd para la agregación de registros con metadatos k8s?

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida podrido

Los problemas podridos se cierran después de 30 días de inactividad.
Vuelva a abrir el problema con /reopen .
Marque el problema como nuevo con /remove-lifecycle rotten .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/cerrar

@ fejta-bot: Cerrando este problema.

Esto no debería haberse cerrado, ¿verdad?
La solicitud de función todavía tiene sentido para mí, ya que estoy buscando configurar las opciones de registro por pod (sin configurarlo en el demonio o usar logrotate) ...

Estoy bastante seguro de que admitir opciones de configuración específicas de Docker desde dentro de k8s no es una buena idea. Como se mencionó anteriormente, un daemonset fluentd o sidecar fluenbit son opciones actuales. Prefiero el sidecar porque es mucho más seguro.

@whereisaaron , ¿encontró una solución de registro para K8s @ containerd?

¿--log-driver, --log-opt aún no son compatibles?
Estoy tratando de encontrar una manera de reenviar registros de un solo módulo a Splunk. ¿algunas ideas?

@ sariel1212 para una sola cápsula, recomiendo incluir un contenedor de vagón lateral en su cápsula que sea solo el agente de reenvío de splunk. Puede compartir un volumen de directorio vacío entre todos los contenedores del pod y hacer que los contenedores de la aplicación escriban sus registros en el directorio vacío compartido. Luego haga que el contenedor del reenviador splunk lea de ese volumen y reenvíelos.

Si desea cobrar a Splunk para todo su clúster @ sariel1212 , hay un gráfico oficial de Splunk helm para implementar fluentd con el complemento de Splunk HEC fluentd para recopilar registros de nodos, registros de contenedores y registros del plano de control, además de objetos de Kubernetes y métricas de clústeres de Kubernetes. Para un Pod, la sugerencia de @coffeepac de un sidecar con un directorio vacío compartido es un buen enfoque.

Es bastante terrible que todavía no haya forma de que el propietario de un clúster use los controladores de registro de Docker después de todo este tiempo.

Pude configurarlo muy rápidamente con Docker-Compose (simulando mi clúster K8s) para canalizar todos los stdout / err a mi servicio de registro agregado.

¿Tratando de hacer esto en Kubenetes? ¡A partir de este hilo, parece que tendré que aumentar el código para cada microservicio! No es bueno.

Hola @ashleydavis , dockerd quedó obsoleto en Kubernetes, por lo que no tiene sentido introducir soporte para algo que ya no forma parte de Kubernetes. Aunque aún puede instalarlo además de Kubernetes. Aquí está el trasfondo:
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

No necesita aumentar los contenedores a menos que lo desee, Kubernetes transmite de forma nativa los registros stdout / stderr para cada contenedor de forma automática. Solo necesita implementar un contenedor en cada nodo (un DaemonSet ) para recopilar y enviar esos flujos de registro a su elección de servicio de agregación. Es muy fácil.

https://docs.fluentd.org/container-deployment/kubernetes

Hay muchas imágenes de contenedor backend listas para usar fluentd + y configuraciones de muestra para backends de agregación posterior aquí:

https://github.com/fluent/fluentd-kubernetes-daemonset

Si está utilizando DataDog, tienen su propio agente para instalar en su lugar o además de fluentd :

https://docs.datadoghq.com/integrations/kubernetes/

En general, docker tendía a kitchen sink , con registro y complementos de registro, y herramientas de enjambre y tiempo de ejecución, herramientas de compilación, redes y montaje del sistema de archivos, etc., todo en un proceso de demonio. Por lo general, Kubernetes prefiere contenedores / procesos poco acoplados que realicen una tarea cada uno y se comuniquen a través de API. Así que es un estilo un poco diferente al que acostumbrarse.

Gracias por la respuesta detallada. Definitivamente voy a investigar esto.

Con dockerd obsoleto, ¿eso significa que no puedo implementar imágenes de Docker en Kubernetes en el futuro?

@ashleydavis , ciertamente puede seguir usando imágenes 'Docker' (incluso sin dockerd presente), y puede seguir implementando dockerd en sus nodos de Kubernetes para sus propios fines (como en docker-in-docker construye) si lo desea. Las partes principales de la ventana acoplable se han extraído y estandarizado como 'contenedores OCI' y el tiempo de ejecución containerd .

https://www.opencontainers.org/
https://containerd.io/

Tanto Docker como Kubernetes ahora se basan en estos estándares compartidos.

https://blog.docker.com/2017/08/what-is-containerd-runtime/
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

Gracias, estoy aprendiendo mucho.

Acabo de crear un microservicio que llamé Loggy. La intención era que el controlador de registro de Docker enviara registros y luego los reenvíe (a través de webhook) a Slack.

Puede ver el código aquí: https://github.com/artlife-solutions/loggy/blob/master/src/index.ts

Es bastante simple, recibe un registro y reenvíalo a través de HTTP POST a Slack.

¿Cuál es la forma más rápida de adaptar esto para poder recopilar y agregar registros de mis pods?

@ashleydavis , podría crear una imagen de contenedor con ese

1. Impleméntelo en clúster como Implementación con un Servicio al que todos los contenedores de su clúster podrían enviar (utilizando el nombre DNS del clúster del Servicio ).

2. Impleméntelo como un contenedor adicional 'sidecar' en su implementación . Los contenedores en el mismo Pod comparten acceso privado al mismo localhost para que el contenedor de la aplicación pueda enviar a su contenedor de microservicio sidecar en localhost:12201 . Alternativamente, los contenedores en el mismo pod pueden compartir un volumen para archivos de registro compartidos o canalizaciones con nombre.

Esto se está saliendo del tema aquí y no todos querrán esto, así que tal vez investigue algunos ejemplos en Github y visite algunos canales de Slack para obtener consejos.

https://github.com/ramitsurana/awesome-kubernetes
https://slack.k8s.io/
https://kubernetes.io/

Suena bien. Gracias. Solo esperaba no tener que cambiar los servicios existentes. Solo me gustaría capturar su stdout / error. ¿Alguna manera de hacer eso?

La promesa de los controladores de registro de Docker fue la simplicidad. ¿Existe alguna forma sencilla de hacer esto?

Claro, @ashleydavis , implemente su clúster, implemente fluentd y, ¡listo! 😺. Cada aplicación que implemente tendrá su stdout / stderr enviado a su agregador favorito. 👍

Después de invertir algo de tiempo en K8 y de iniciar sesión, configuré una buena pila de ELK sin una configuración explícita de GELF . Eche un vistazo a https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html

Mi configuración es Filebeat que canaliza los registros a Logstash que filtra, extrae y canaliza sus cosas a Elasticsearch. Con Kibana puedo ver los registros y agregar datos.

También me encantaría admitir el registro en el archivo syslog nativo del sistema operativo, por ejemplo: en Ubuntu puedo escribir registros en /var/log/syslog , que se administra mediante logrotate listo para usar.

Con swarm / compose, puedo hacer esto:

version: '3.3'
services:
  mysql:
    image: mysql:5.7
    logging:
      driver: syslog
      options:
        tag: mysql

El uso de un volumen emtpyDir está bien, sin embargo, los pods de larga ejecución corren el riesgo de llenar el volumen a menos que agregue un proceso adicional que rote / trunque los archivos de registro. No estoy de acuerdo con esta complejidad adicional cuando el sistema operativo ya está manejando la rotación de / var / log / syslog.

Estoy de acuerdo en que usar sidecars para algunas implementaciones es una gran idea (ya lo hago para algunas de mis implementaciones), sin embargo, el entorno de todos es diferente.

Usar un volumen emtpyDir está bien

Tenga cuidado con ellos: los administra Kubernetes y usted no controla su vida útil. Si un pod es desalojado y reprogramado a otro nodo, los registros se perderán. Si actualiza un pod y su uid cambia, no usará el volumen anterior, sino que creará uno nuevo y eliminará el anterior.

@jsirianni no todos los sistemas ejecutan syslog, lo que significa que debería haber alguna anotación por nodo sobre las instalaciones disponibles para garantizar que se satisfagan las necesidades de un pod determinado. docker compose hace esa suposición porque se ejecuta solo localmente.

@coffeepac El hecho de que los nodos no tengan syslog no significa que el operador no deba tener la opción. Si tengo la intención de usar syslog, me aseguraría de que mis nodos de trabajo tengan syslog.

Creo que este problema debería reabrirse ya que todavía hay suficientes casos de uso para esta función.
/reabrir

@ saiyam1814 : Reabrió este problema.

Personalmente, sigo pensando que Kubernetes debería admitir los controladores de registro de Docker o alguna otra forma sencilla incorporada de configurar el registro.

Muchas veces me han dicho que configurar el registro es fácil en Kubernetes, pero ahora que he pasado por el proceso de configurar mi propio sistema de agregación de registros, puedo decir que realmente no es simple.

Escribí una publicación de blog sobre la forma más sencilla de poner a mano su propio sistema de agregación de registros para Kubernetes: http://www.the-data-wrangler.com/kubernetes-log-aggregation/

Con suerte, la publicación de mi blog ayudará a otros a descubrir su propia estrategia.

No debería ser tan difícil, pero aquí es donde estamos.

Seguro que necesitamos una forma de consumir registros de Docker directamente desde stdout y stderr, en lugar de usar archivos de registro. Existen algunos problemas de seguridad para usar la ruta de Docker para registrar archivos, porque puede acceder a otros registros en el sistema host.

¿Podemos implementar el controlador de registro de Docker? 👍

La configuración de los controladores de registro de la ventana acoplable en un nivel de contenedor en un pod (donde el pod está bajo el control del cliente) permitiría redirigir los registros con el controlador gelf directamente a un servicio / pod de graylog (que también está bajo el control del cliente) ) en lugar de tener que recopilarlos de archivos en el host con otro servicio inmediato (que es más sobrecarga de administración y una ruptura peor del nivel de abstracción que usar el controlador de registro gelf ) o por los pods del cliente que acceden al directorio de registros del contenedor en el anfitrión.

Por lo tanto, me encantaría ver esta función implementada en kubernetes.

Sería útil asegurarnos de hacer algo como https://github.com/cri-o/cri-o/pull/1605 , donde desconectamos la interpretación del flujo de registro de los controladores de registro para que el comportamiento del contenedor no pueda afectar cómo los conductores funcionan.

Los problemas podridos se cierran después de 30 días de inactividad.
Vuelva a abrir el problema con /reopen .
Marque el problema como nuevo con /remove-lifecycle rotten .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/cerrar

@ fejta-bot: Cerrando este problema.

La función aún debe implementarse
/reabrir

@ M0rdecay : No puede volver a abrir un problema / RP a menos que sea el autor o un colaborador.

@ M0rdecay : No puede volver a abrir un problema / RP a menos que sea el autor o un colaborador.

Está bien, lo entendí

Incluso aws ecs tiene esta funcionalidad en la que se puede configurar el controlador de registro de la ventana acoplable.
En nuestro entorno, hemos creado un índice independiente con un token único para cada servicio de contenedor.

"logConfiguration": {
"logDriver": "splunk",
"opciones": {
"splunk-format": "raw",
"splunk-insecureskipverify": "verdadero",
"splunk-token": "xxxxx-xxxxxxx-xxxxx-xxxxxxx-xxxxxx",
"splunk-url": " https://xxxxx.splunk-heavyforwarderxxx.com ",
"etiqueta": "{{.Name}} / {{. ID}}",
"splunk-verify-connection": "falso",
"modo": "sin bloqueo"
}
}

Pero no encontré nada como esto en k8s. Debería estar en la propia definición de la vaina.

Las opciones aún deben implementarse
/reabrir

@ejemba : Reabrió este número.

/ sig nodo
/ remove-sig instrumentación

/ remove-sig escalabilidad

@logicalhan : Esas etiquetas no están establecidas en el tema: sig/

¿Algún progreso con eso?
Estaba buscando específicamente la capacidad de configurar contenedores de pods para iniciar sesión en el logstash externo, especificando el controlador de registro gelf de docker. Establecerlo de forma predeterminada para todos los contenedores en /etc/docker/daemon.json parece ser una sobrecarga.

Los problemas podridos se cierran después de 30 días de inactividad.
Vuelva a abrir el problema con /reopen .
Marque el problema como nuevo con /remove-lifecycle rotten .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/cerrar

@ fejta-bot: Cerrando este problema.

/reabrir

@andreswebs : no puede volver a abrir un problema / RP a menos que sea el autor o un colaborador.

/reabrir

@ejemba : Reabrió este número.

@ejemba : Este problema está actualmente pendiente de clasificación.

Si un SIG o un subproyecto determina que este es un tema relevante, lo aceptarán aplicando la etiqueta triage/accepted y brindarán más orientación.

Los miembros de la organización pueden agregar la etiqueta triage/accepted escribiendo /triage accepted en un comentario.

Realmente me gustaría que se implementara esta característica. Actualmente estoy migrando cargas de trabajo de los clústeres de Rancher 1.x a los clústeres de Rancher 2.x que ejecutan k8s. Tenemos una implementación que establece los parámetros log-driver y log-opt en la configuración de docker-compose.

No quiero tener que configurar un host específico para usar el controlador gelf globalmente y etiquetar el pod con una etiqueta y el host con una etiqueta.

Parece que deberíamos cambiar CRI-O para especificar que ambos flujos de registro de contenedor (stdout / stderr) se recopilan en forma sin procesar, y cuando leemos el archivo sin procesar para más adelante, podemos aplicar diferentes interpretaciones del flujo de bytes de registro.

Consulte https://github.com/cri-o/cri-o/pull/1605.

Los problemas podridos se cierran después de 30 días de inactividad.
Vuelva a abrir el problema con /reopen .
Marque el problema como nuevo con /remove-lifecycle rotten .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/cerrar

@ fejta-bot: Cerrando este problema.