Saltar al contenido

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift

white and gray spiral stairs

Pon algo de cerebro cuando una ruta no funciona como se espera, o tus consumidores no pueden acceder al servicio


Foto de Sylvain Gllm en Unsplash

Todos sabemos que Openshift es una distribución de Kubernetes excepcional y una de las más utilizadas, principalmente cuando se habla de implementaciones en la nube privada. Basado en la sólida reputación de Red Hat Enterprise Linux, Openshift pudo crear un producto sólido que se está convirtiendo casi en un estándar para la mayoría de las empresas.

Proporciona muchas extensiones del estilo de Kubernetes Vanilla, incluyendo algunos de los estándares de la industria de código abierto como Prometheus, Thanos y Grafana para el monitoreo de métricas o la pila ELK para la agregación de registros, pero también incluye sus extensiones como las Rutas de Openshift.

Las Rutas de Openshift fueron la solución inicial antes de que el concepto de Ingress fuera una realidad dentro del estándar. Ahora, también se implementa siguiendo ese patrón para mantener la compatibilidad. Está respaldado por HAProxy, uno de los proxies inversos más conocidos disponibles en la comunidad de código abierto.

Una de las partes complicadas por defecto es saber cómo depurar cuando una de tus rutas no funciona como se espera. La forma en que creas rutas es tan fácil que cualquiera puede hacerlo en unos pocos clics, y si todo funciona como se espera, eso es genial.

Pero si no es así, los problemas comienzan porque, por defecto, no obtienes ningún registro sobre lo que está sucediendo. Pero eso es lo que vamos a resolver aquí.

Primero, hablaremos un poco más sobre cómo se configura esto. Actualmente (versión 4.8 de Openshift), esto se implementa, como dije, usando HAProxy por defecto, así que si estás usando otra tecnología como ingresses como Istio o Nginx, este artículo no es para ti (pero no olvides dejar un comentario si un artículo similar sería de tu interés para que también pueda llevarlo al backlog 🙂 )

Desde la perspectiva de la implementación, esto se implementa usando el Marco de Operadores, por lo que el ingreso se despliega como un Operador, y está disponible en el espacio de nombres openshift-ingress-operator.

pods del operador de ingreso en el ecosistema de Openshift

Entonces, como esto es un operador, se han instalado varias Definiciones de Recursos Personalizados (CRD) para trabajar con esto, una de las más interesantes de este artículo. Este CRD es Controladores de Ingreso.

Instancias de Ingreso en el Ecosistema de Openshift

Por defecto, solo verás una instancia llamada default. Esta es la que incluye la configuración del ingreso que se está desplegando, por lo que necesitamos agregar aquí una configuración adicional para tener también los registros.

Archivo YAML del controlador de ingreso

El fragmento que necesitamos es el que se muestra a continuación bajo el parámetro spec que comienza la definición de la especificación del IngressController en sí:

   logging:
    access:
      destination:
        type: Container
      httpLogFormat: >-
        log_source="haproxy-default" log_type="http" c_ip="%ci" c_port="%cp"
        req_date="%tr" fe_name_transport="%ft" be_name="%b" server_name="%s"
        res_time="%TR" tot_wait_q="%Tw" Tc="%Tc" Tr="%Tr" Ta="%Ta"
        status_code="%ST" bytes_read="%B" bytes_uploaded="%U"
        captrd_req_cookie="%CC" captrd_res_cookie="%CS" term_state="%tsc"
        actconn="%ac" feconn="%fc" beconn="%bc" srv_conn="%sc" retries="%rc"
        srv_queue="%sq" backend_queue="%bq" captrd_req_headers="%hr"
        captrd_res_headers="%hs" http_request="%r"

Esto hará que se despliegue otro contenedor en los pods del enrutador en el espacio de nombres openshift-ingress siguiendo el patrón sidecar llamado logs.

Pods del enrutador en la instalación de Openshift

Este contenedor imprimirá los registros de las solicitudes que llegan al componente de ingreso, por lo que la próxima vez que tu consumidor no pueda llamar a tu servicio, podrás ver las solicitudes entrantes con todos sus metadatos y saber al menos qué está haciendo mal:

Registros de acceso de la Ruta de Openshift

Como puedes ver, ¡simple y fácil! Si ya no lo necesitas, puedes eliminar la configuración nuevamente y guardarla, y la nueva versión se implementará y volverá a la normalidad.

Related articles:

Uso de Ingress de Kubernetes en OpenShift: Cómo se Generan las Rutas y Cuándo Usar Cada Una Using Kubernetes Ingress on OpenShift: How Routes Are Generated and When to Use Each Integración de Istio con aplicaciones BWCE Sondas de Kubernetes para una aplicación de TIBCO BusinessWorks Container Edition
Etiquetas:

How To Enable Access Logs on Openshift Default Routes

white and gray spiral stairs

Put some brain when a route is not working as expected, or your consumers are not able to reach the service


Photo by Sylvain Gllm on Unsplash

We all know that Openshift is an outstanding Kubernetes Distribution and one of the most used mainly when talking about private-cloud deployments. Based on the solid reputation of Red Hat Enterprise Linux, Openshift was able to create a solid product that is becoming almost a standard for most enterprises.

It provides a lot of extensions from the Vanilla Kubernetes style, including some of the open-source industry standards such as Prometheus, Thanos, and Grafana for Metrics Monitoring or ELK stack for Logging Aggregation but also including its extensions such as the Openshift Routes.

Openshift Routes was the initial solution before the Ingress concept was a reality inside the standard. Now, it also implements following that pattern to keep it compatible. It is backed by HAProxy, one of the most known reverse-proxy available in the open-source community.

One of the tricky parts by default is knowing how to debug when one of your routes is not working as expected. The way you create routes is so easy that anyone can make it in a few clicks, and if everything works as expected, that’s awesome.

But if it doesn’t, the problems start because, by default, you don’t get any logging about what’s happening. But that’s what we are going to solve here.

First, we will talk a little more about how this is configured. Currently (Openshift 4.8 version), this is implemented, as I said, using HAProxy by default so if you are using other technology as ingresses such as Istio or Nginx, this article is not for you (but don’t forget to leave a comment if a similar kind of article would be of your interest so I can also bring it to the back-log 🙂 )

From the implementation perspective, this is implemented using the Operator Framework, so the ingress is deployed as an Operator, and it is available in the openshift-ingress-operator namespace.

ingress-operator pods on Openshift ecosystem

So, as this is an operator, several Custom Resources Definition (CRD) have been installed to work with this, one of the most interesting of this article. This CRD is Ingress Controllers.

Ingress instances on Openshift Ecosystem

By default, you will only see one instance named default. This is the one that includes the configuration of the ingress that is being deployed, so we need to add here an additional configuration to have also the logs.

Ingress controller YAML file

The snippet that we need to that is the one shown below under the spec parameter that starts the definition of the specification of the IngressController itself: 

   logging:
    access:
      destination:
        type: Container
      httpLogFormat: >-
        log_source="haproxy-default" log_type="http" c_ip="%ci" c_port="%cp"
        req_date="%tr" fe_name_transport="%ft" be_name="%b" server_name="%s"
        res_time="%TR" tot_wait_q="%Tw" Tc="%Tc" Tr="%Tr" Ta="%Ta"
        status_code="%ST" bytes_read="%B" bytes_uploaded="%U"
        captrd_req_cookie="%CC" captrd_res_cookie="%CS" term_state="%tsc"
        actconn="%ac" feconn="%fc" beconn="%bc" srv_conn="%sc" retries="%rc"
        srv_queue="%sq" backend_queue="%bq" captrd_req_headers="%hr"
        captrd_res_headers="%hs" http_request="%r"

This will make another container deployed on the router pods in the openshift-ingressnamespace following the sidecar pattern named logs.

Router pods on Openshift Installation

This container will print the logs from the requests reaching the ingress component, so next time your consumer is not able to call your service, you will be able to see the incoming requests with all their metadata and know at least what is doing wrong:

Openshift Route Access Logs

As you can see, simple and easy!! If you don’t need it anymore, you can again remove the configuration and save it, and the new version will be rolled out and go back to normal.

Related articles:

Uso de Ingress de Kubernetes en OpenShift: Cómo se Generan las Rutas y Cuándo Usar Cada Una Using Kubernetes Ingress on OpenShift: How Routes Are Generated and When to Use Each Integración de Istio con aplicaciones BWCE Sondas de Kubernetes para una aplicación de TIBCO BusinessWorks Container Edition
Etiquetas:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *