Metadatos de Kubernetes: Potencia tus aplicaciones con contenido de tus pods

black laptop computer turned on on table

Descubre cómo extraer toda la información disponible para inyectarla en tus pods

Empodera tus pods con contenido de tu metadata de Kubernetes

Foto de James Harrison en Unsplash

La metadata de Kubernetes es cómo accederás a parte de la información de tus pods en tu aplicación en tiempo de ejecución. Cuando te mueves de un tipo de desarrollo tradicional a uno nativo de la nube, usualmente necesitas acceder a alguna información disponible de manera predeterminada en un entorno convencional.

Esto sucede especialmente cuando hablamos de una plataforma que en el pasado se desplegaba en cualquier plataforma que estaba poblada con información como el nombre de la aplicación, versión, dominio, etc. Pero esto es complicado en un enfoque nativo de la nube. O tal vez no, pero al menos por algún tiempo, te has estado preguntando cómo puedes acceder a parte de la información que conoces sobre tu carga de trabajo nativa de la nube, para que la aplicación en ejecución dentro del pod también la conozca.

Porque cuando defines un nativo de la nube, describes mucha información muy relevante. Por ejemplo, pensemos en eso. Cuando inicias tu pod, conoces el nombre de tu pod porque es tu nombre de host:

Pero cuando defines tu carga de trabajo, tienes un nombre de despliegue; ¿cómo puedes obtenerlo desde tu pod? ¿Cómo obtienes en qué espacio de nombres se ha desplegado tu pod? ¿O qué hay de toda la metadata que definimos como etiquetas y anotaciones?

Lo bueno es que hay una manera de obtener cada dato que hemos comentado, así que no te preocupes; obtendrás toda esta información disponible para usar si la necesitas.

La forma estándar de acceder a cualquier información es a través de variables de entorno. Esta es la forma tradicional en que proporcionamos datos iniciales a nuestro pod. Ya hemos visto que sabemos que podemos usar ConfigMaps para poblar variables de entorno, pero esta no es la única manera de proporcionar datos a nuestros pods. Hay mucho más, así que échale un vistazo.

Descubriendo la opción fieldRef

Cuando discutimos el uso de ConfigMap como variables de entorno, teníamos dos maneras de poblar esa información. Proporcionando todo el contenido de ConfigMap, en cuyo caso usamos la opción envFrom, también podemos usar valueFrom y proporcionar el nombre del configMap y la misma clave de la que nos gustaría obtener el valueFrom.

Así que, siguiendo el enfoque de esta sección, tenemos un comando aún más útil llamado fieldRef. fieldRef es el nombre del comando para una referencia a un campo, y podemos usarlo dentro de la directiva valueFrom. En resumen, podemos proporcionar una referencia de campo como un valor para una clave de variable de entorno.

Así que echemos un vistazo a los datos que podemos obtener de este objeto:

  • metadata.name: Esto obtiene el nombre del pod como un valor para un valor de entorno
  • metadata.namespace: Proporciona el espacio de nombres en el que el pod está ejecutándose como el valor
  • metadata.labels[LABELNAME]: Extrae el valor de la etiqueta como el valor para la clave de entorno
  • metadata.annotations[ANNOTATIONNAME]: Extrae el valor de la anotación como valor para la clave de entorno

Aquí puedes ver un fragmento que define diferentes variables de entorno usando esta metadata como el valor para que puedas usarlo dentro del pod simplemente recopilándolo como variables de entorno estándar:

        env:
        - name: APP_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['app']
        - name: DOMAIN_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['domain']
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name 

Yendo aún más allá

Pero esto no es todo lo que la opción fieldRef puede proporcionar, hay mucho más, y si te gustaría echar un vistazo, puedes hacerlo aquí:

Cómo solucionar problemas de conexiones de red en tus cargas de trabajo de Kubernetes

blue UTP cord

Descubre Mizu: Visor de Tráfico para Kubernetes para facilitar este desafío y mejorar tu trabajo diario.


Foto de Jordan Harrison en Unsplash

Una de las cosas más comunes que tenemos que hacer al probar y depurar nuestras cargas de trabajo nativas de la nube en Kubernetes es verificar la comunicación de red.

Podría ser para verificar el tráfico entrante que estás recibiendo para que podamos inspeccionar las solicitudes que estamos recibiendo y ver a qué estamos respondiendo y casos de uso similares. Estoy seguro de que esto suena familiar para la mayoría de ustedes.

Normalmente resuelvo eso usando tcpdump en el contenedor, similar a lo que haría en un entorno tradicional, pero esto no siempre es fácil. Dependiendo del entorno y la configuración, no puedes hacerlo porque necesitas incluir un nuevo paquete en la imagen de tu contenedor, hacer un nuevo despliegue para que esté disponible, etc.

Entonces, para resolver eso y otros problemas similares, descubrí una herramienta llamada Mizu, que me hubiera gustado encontrar hace unos meses porque me ayudaría mucho. Mizu es precisamente eso. En sus propias palabras:

Mizu es un visor de tráfico API simple pero poderoso para Kubernetes, que te permite ver toda la comunicación API entre microservicios a través de múltiples protocolos para ayudarte a depurar y solucionar regresiones.

Para instalar, es bastante sencillo. Necesitas obtener el binario y proporcionar el permiso correcto en tu computadora. Tienes un binario diferente para cada arquitectura, y en mi caso (Mac basado en Intel), estos son los comandos que ejecuté:

curl -Lo mizu github.com/up9inc/mizu/releases/latest/download/mizu_darwin_amd64 && chmod 755 mizu && mv mizu /usr/local/bin

Y eso es todo, luego tienes un binario en tu laptop que se conecta a tu clúster de Kubernetes usando la API de Kubernetes, por lo que necesitas tener configurado el contexto adecuado.

En mi caso, he desplegado un servidor nginx simple usando el comando:

 kubectl run simple-app --image=nginx --port 80

Y una vez que el componente ha sido desplegado, como se muestra en la captura de pantalla de Lens a continuación:

Ejecuté el comando para lanzar mizu desde mi laptop:

mizu tap

Y después de unos segundos, tengo frente a mí una página web abierta monitoreando todo el tráfico que ocurre en este pod:

He expuesto el puerto de nginx usando el comando kubectl expose:

 kubectl expose pod/simple-app

Y después de eso, desplegué un pod temporal usando la imagen curl para comenzar a enviar algunas solicitudes con el comando que se muestra a continuación:

 kubectl run -it --rm --image=curlimages/curl curly -- sh

ahora he comenzado a enviar algunas solicitudes a mi pod nginx usando curl:

 curl -vvv http://simple-app:80 

Y después de algunas llamadas, pude ver mucha información frente a mí. En primer lugar, puedo ver las solicitudes que estaba enviando con todos los detalles de las mismas:

Pero aún más importante, puedo ver un diagrama de mapa de servicios que muestra las dependencias y las llamadas gráficamente que ocurren en el pod con el tiempo de respuesta y también el uso del protocolo:

Esto ciertamente no reemplazará una solución completa de observabilidad sobre una malla de servicios. Aún así, será una herramienta muy útil para agregar a tu cadena de herramientas cuando necesites depurar una comunicación específica entre componentes o escenarios similares. Como se comentó, es como un tcpdump de alto nivel para la comunicación de pods.

Pod de Múltiples Contenedores: Cómo, Cuándo y Por Qué

city with high rise buildings during night time

Hablemos sobre la opción más peligrosa desde la perspectiva del diseño de Pods, ¡para que estés listo para usarla!


Foto de Timelab Pro en Unsplash

Una de las conversaciones habituales es sobre la composición y definición de componentes dentro de un Pod. Esto es normal para las personas que se trasladan de un despliegue tradicional a un entorno nativo de la nube, y la pregunta principal es: ¿Cuántos contenedores puedo tener dentro de un pod? 

Estoy seguro de que la mayoría de ustedes han escuchado o han hecho esa pregunta en algún momento de su viaje nativo de la nube, o incluso tienen esta duda internamente en este momento, y no hay duda en la respuesta: Un solo contenedor.

¡Espera, espera! ¡No dejes el post todavía! Sabemos que eso no es técnicamente cierto, pero es más fácil de entender inicialmente; solo puedes tener un pod haciendo una cosa.

Entonces, si ese es el caso, ¿por qué existen los pods de múltiples contenedores? Y lo más importante, si esta es la primera vez que escuchas ese concepto, ¿qué es un pod de múltiples contenedores?

Comencemos con la definición: Un pod de múltiples contenedores tiene más de un contenedor en su composición. Y cuando hablamos de múltiples contenedores, no estamos hablando de tener algunos initContainers para gestionar las dependencias. Aún así, estamos hablando de tener más de un contenedor ejecutándose simultáneamente y al mismo nivel, como puedes ver en la imagen a continuación:

Definición de Pod de Múltiples Contenedores

¿Kubernetes admite este modelo? Sí, por supuesto. Puedes definir dentro de tu sección de contenedores tantos contenedores como necesites. Entonces, desde un punto de vista técnico, no hay límite para tener tantos contenedores como necesites en el mismo pod. Pero la pregunta principal que deberías hacerte es:

¿Es esto lo que quieres hacer?

Un pod es la unidad más pequeña en Kubernetes como recordatorio. Despliegas y retiras pods, detienes y arrancas pods, reinicias pods, escalas pods. Así que cualquier cosa que esté dentro del mismo pod está altamente acoplada. Es como un paquete, y también comparten recursos. Así que es aún más crítico.

Imagina esta situación, me gustaría comprar un cuaderno, así que voy a la tienda y pido el cuaderno, pero no tienen un solo cuaderno. Aún así, tienen un paquete increíble: un cuaderno, un bolígrafo y una grapadora por solo $2 más que el precio de un solo cuaderno.

Así que piensas que este es un excelente precio porque estás obteniendo un bolígrafo y una grapadora por una pequeña parte de su precio si quisieras comprarlo por separado. Así que piensas que es una buena idea. Pero luego, recuerdas que también necesitas otros cuadernos para otros propósitos. Al final, necesitas diez cuadernos más, pero cuando necesitas comprarlos, también necesitas reconocer los diez bolígrafos y las diez grapadoras que ya no necesitas. OK, son más baratos, pero al final, estás pagando un precio razonable por algo que no necesitas. Así que, no es eficiente. Y lo mismo se aplica a la definición de la estructura del Pod.

Al final, ¿te mueves de despliegues monolíticos tradicionales a diferentes contenedores dentro de un pod para tener los mismos desafíos y problemas? ¿Cuál es el punto de hacer eso?

Ninguno.

Si no hay razón para tener dos contenedores estrechamente juntos, ¿por qué está permitido esto en la especificación de K8S? Porque esto es útil para algunos casos de uso y escenarios específicos. Hablemos de algunos de ellos.

  • Contenedores de Ayuda: Este es el más común y es que tienes diferentes contenedores dentro del pod. Aún así, uno es el principal, el que proporciona una capacidad de negocio o una característica, y el otro solo está ayudando de alguna manera.
  • Implementación del Patrón Sidecar: Otro enfoque común para tener esta composición es implementar el patrón sidecar. Así es como funciona al desplegar otro contenedor para realizar una capacidad específica. Lo has visto, por ejemplo, para Service Meshes, Arquitectura de Agregación de Logs, u otros componentes que siguen ese patrón.
  • Exportadores de Monitoreo: Otra cosa usual de ver es usar uno de estos contenedores para actuar como un exportador de las métricas de monitoreo del componente principal. Esto se ve usualmente en arquitecturas como Prometheus, donde cada pieza tiene su exportador para ser extraído del Servidor Prometheus

También hay hechos interesantes de compartir contenedores dentro de un pod porque, como se comentó, también comparten recursos como:

  • Volúmenes: Puedes, por ejemplo, definir una carpeta compartida para todos los diferentes contenedores dentro de un pod, para que un contenedor pueda leer información del otro para realizar su tarea de manera rápida y eficiente.
  • Comunicación Inter-procesos: Puedes comunicarte entre contenedores usando IPC para comunicarte de manera más eficiente.
  • Red: Los diferentes contenedores dentro de un pod también pueden acceder a puertos de otros contenedores simplemente alcanzando localhost.

Espero que este artículo te haya ayudado a entender por qué existe esta capacidad de tener muchos contenedores dentro del mismo pod, pero al mismo tiempo saber qué tipo de escenarios están usando este enfoque y tener algún razonamiento sobre si un nuevo caso de uso debería usar este enfoque o no.

ServiceMonitor y PodMonitor de Prometheus: ¡No te pierdas los nuevos conceptos!

black flat screen tv turned on near black and gray audio component

Descubre las diferencias entre dos de los CRDs más utilizados del Operador Prometheus y cómo usar cada uno de ellos.

Conceptos de Prometheus: ServiceMonitor y PodMonitor

Foto de Ibrahim Boran en Unsplash

ServiceMonitor y PodMonitor son términos que comenzarás a ver más a menudo cuando se hable de usar Prometheus. Hemos cubierto mucho sobre Prometheus en artículos anteriores. Es una de las principales referencias cuando hablamos de monitoreo en un entorno nativo de la nube y está especialmente enfocado en el ecosistema de Kubernetes.

Prometheus tiene un nuevo modelo de implementación bajo el Marco del Operador de Kubernetes en tiempos recientes. Eso ha generado varios cambios en términos de recursos y cómo configuramos varios aspectos del monitoreo de nuestras cargas de trabajo. Algunos de estos conceptos ahora se gestionan como Definición de Recurso Personalizado (CRD) que se incluyen para simplificar la configuración del sistema y estar más alineados con las capacidades de la propia plataforma de Kubernetes. Esto es genial pero, al mismo tiempo, cambia cómo necesitamos usar esta excelente herramienta de monitoreo para cargas de trabajo nativas de la nube.

Hoy, cubriremos dos de estos nuevos CRDs, uno de los más relevantes: ServiceMonitor y PodMonitor. Estos son los nuevos objetos que especifican los recursos que estarán bajo el alcance de monitoreo para la plataforma, y cada uno de ellos cubre un tipo diferente de objeto, como puedes imaginar: Servicios y Pods.

Cada uno de ellos tiene su archivo de definición con sus campos y metadatos particulares, y para destacarlos, presentaré un ejemplo para cada uno de ellos a continuación:

Service Monitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    serviceMonitorSelector: prometheus
  name: prometheus
  namespace: prometheus
spec:
  endpoints:
  - interval: 30s
    targetPort: 9090
    path: /metrics
  namespaceSelector:
    matchNames:
    - prometheus
  selector:
    matchLabels:
      operated-prometheus: "true"

Pod Monitor

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: front-end
  labels:
    name: front-end
spec:
  namespaceSelector:
    matchNames:
      - sock-shop
  selector:
    matchLabels:
      name: front-end
  podMetricsEndpoints:
  - targetPort: 8079

Como puedes ver, las definiciones de los componentes son muy similares y muy intuitivas, enfocándose en el selector para detectar qué pods o servicios debemos monitorear y algunos datos sobre el objetivo específico del monitoreo, para que Prometheus sepa cómo extraerlos.

Si deseas echar un vistazo más en detalle a cualquier opción que puedas configurar en este CRD, te recomendaría que eches un vistazo a esta URL que incluye una documentación detallada campo por campo de los CRDs más comunes:

Estos componentes pertenecerán a la definición de tus cargas de trabajo, lo que significa que la creación y el mantenimiento de estos objetos serán responsabilidad de los desarrolladores de la aplicación.

Eso es genial por varias razones:

  • Incluirá el aspecto de Monitoreo del propio componente, por lo que nunca olvidarás agregar la configuración de un componente específico. Eso significa que se puede incluir en los archivos YAML duplicados o en el Helm Chart o en recursos de Kustomize como otro recurso necesario.
  • Descentralizará la configuración de monitoreo haciéndola más ágil, y progresará a medida que lo hagan los componentes de software.
  • Reducirá el impacto en otros componentes monitoreados ya que no hay necesidad de actuar en ningún archivo o recurso estándar, por lo que cualquier carga de trabajo diferente continuará funcionando como se espera.

Ambos objetos son muy similares en sus propósitos ya que ambos extraen todos los endpoints que coinciden con el selector que agregamos. Entonces, ¿en qué casos debería usar uno u otro?

La respuesta será sencilla. Por defecto, optarás por un ServiceMonitor porque proporcionará las métricas del propio servicio y de cada uno de los endpoints que tiene el servicio, por lo que cada uno de los pods que están implementando el servicio será descubierto y extraído como parte de esta acción.

Entonces, ¿en qué casos debería usar PodMonitor? Donde la carga de trabajo que estás tratando de monitorear no actúa detrás de un servicio, por lo que al no haber un servicio definido, no puedes usar ServiceMonitor. ¿Quieres algunos ejemplos de eso? ¡Traigamos algunos!

  • Servicios que interactúan usando otros protocolos que no son basados en HTTP, como Kafka, SQS/SNS, JMS, o similares.
  • Componentes como CronJobs, DaemonSets, o que no exponen ningún modelo de conexión entrante.

Así que espero que este artículo te ayude a entender la principal diferencia entre esos objetos y profundizar un poco más en cómo funcionan los nuevos recursos del Marco del Operador Prometheus. Continuaremos cubriendo otros aspectos en próximos artículos.

Cómo mejorar la productividad en el desarrollo de cargas de trabajo de Kubernetes

timelapse photo of highway during golden hour

La telepresencia es la forma de reducir el tiempo entre tus líneas de código y una carga de trabajo nativa de la nube en ejecución.

foto de lapso de tiempo de la autopista durante la hora dorada
Foto de Joey Kyber en Unsplash

Todos sabemos cómo las cargas de trabajo nativas de la nube y Kubernetes han cambiado la forma en que hacemos las cosas. Hay muchos beneficios que vienen con el efecto de la contenedorización y las plataformas de orquestación como Kubernetes, y hemos discutido mucho sobre ello: escalabilidad, autocuración, autodescubrimiento, resiliencia, y así sucesivamente.

Pero se han planteado algunos desafíos, la mayoría de ellos en el aspecto operativo en el que tenemos muchos proyectos enfocados en abordar, pero generalmente olvidamos lo que el embajador ha definido como el “ciclo de desarrollo interno”.

El “ciclo de desarrollo interno” es el flujo de trabajo productivo que cada desarrollador sigue al trabajar en una nueva aplicación, servicio o componente. Este flujo iterativo es donde codificamos, probamos lo que hemos codificado y arreglamos lo que no funciona o mejoramos lo que ya tenemos.

Este flujo ha existido desde el principio de los tiempos; no importa si estabas codificando en C usando la biblioteca STD o COBOL a principios de 1980 o haciendo nodejs con los últimos marcos y bibliotecas a tu disposición.

Hemos visto movimientos hacia hacer este ciclo interno más efectivo, especialmente en el desarrollo front-end. Tenemos muchas opciones para ver el último cambio que hemos hecho en el código, solo guardando el archivo. Pero por primera vez, cuando el movimiento hacia una plataforma basada en contenedores, este flujo hace que los desarrolladores sean menos productivos.

La razón principal es que el número de tareas que un desarrollador necesita hacer ha aumentado. Imagina este conjunto de pasos que necesitamos realizar:

  • Construir la aplicación
  • Construir la imagen del contenedor
  • Desplegar la imagen del contenedor en Kubernetes

Estas acciones no son tan rápidas como probar tus cambios localmente, haciendo que los desarrolladores sean menos productivos que antes, que es lo que el proyecto “telepresencia” está tratando de resolver.

La telepresencia es un proyecto incubador de la CNCF que ha centrado mucha atención recientemente porque se ha incluido OOTB en las últimas versiones del componente Docker Desktop. Basado en sus propias palabras, esta es la definición del proyecto de telepresencia:

La telepresencia es una herramienta de código abierto que permite a los desarrolladores codificar y probar microservicios localmente contra un clúster de Kubernetes remoto. La telepresencia facilita flujos de trabajo de desarrollo más eficientes aliviando la necesidad de preocuparse por otras dependencias de servicio.

Ok, entonces, ¿cómo podemos empezar? Vamos a sumergirnos juntos. Lo primero que necesitamos hacer es instalar la telepresencia en nuestro clúster de Kubernetes:

Nota: También hay una forma de instalar telepresencia usando Helm en tu clúster siguiendo estos pasos:

helm repo add datawire  https://app.getambassador.io
helm repo update
kubectl create namespace ambassador
helm install traffic-manager --namespace ambassador datawire/telepresence

Ahora crearé un contenedor simple que alojará una aplicación Golang que expone un servicio REST simple y lo haré más accesible; seguiré el tutorial que está disponible a continuación; tú también puedes hacerlo.

Una vez que tengamos nuestra aplicación golang lista, vamos a generar el contenedor a partir de ella, usando el siguiente Dockerfile:

FROM golang:latest

RUN apt-get update
RUN apt-get upgrade -y

ENV GOBIN /go/bin

WORKDIR /app

COPY *.go ./
RUN go env -w GO111MODULE=off
RUN go get .
RUN go build -o /go-rest
EXPOSE 8080
CMD [ "/go-rest" ]

Luego, una vez que tengamos la aplicación, la subiremos al servidor de Kubernetes y la ejecutaremos como un despliegue, como puedes ver en la imagen a continuación:

kubectl create deployment rest-service --image=quay.io/alexandrev/go-test  --port=8080
kubectl expose deploy/rest-service

Una vez que tengamos eso, es el momento de comenzar a ejecutar la telepresencia, y comenzaremos a conectarnos al clúster usando el siguiente comando telepresence connect, y mostrará una salida como esta:

Luego vamos a listar los puntos finales disponibles para interceptar con el comando telepresence list y veremos nuestro servicio-rest que hemos expuesto antes:

Ahora, ejecutaremos el interceptor específico, pero antes de eso, vamos a hacer el truco para que podamos conectarlo a nuestro Visual Studio Code. Generaremos un archivo launch.json en Visual Studio Code con el siguiente contenido:

{
    // Usa IntelliSense para aprender sobre posibles atributos.
    // Pasa el ratón para ver descripciones de atributos existentes.
    // Para más información, visita: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Lanzar con archivo env",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "program": "1",
            "envFile": "NULL/go-debug.env"
           }
    ]
}

La parte interesante aquí es el argumento envFile que apunta a un archivo inexistente go-debug.env en la misma carpeta, por lo que necesitamos asegurarnos de que generamos ese archivo cuando hacemos la intercepción. Así que usaremos el siguiente comando:

telepresence intercept rest-service --port 8080:8080 --env-file /Users/avazquez/Data/Projects/GitHub/rest-golang/go-debug.env

Y ahora, podemos comenzar nuestra sesión de depuración en Visual Studio Code y tal vez agregar un punto de interrupción y algunas líneas, como puedes ver en la imagen a continuación:

Entonces, ahora, si golpeamos el pod en Kubernetes, veremos cómo se alcanza el punto de interrupción como si estuviéramos en una sesión de depuración local.

Eso significa que podemos inspeccionar variables y todo, cambiar el código o hacer lo que necesitemos para acelerar nuestro desarrollo!

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

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.

Las 3 mejores opciones para implementar Loki escalable en Kubernetes

Modelos de Despliegue para una Arquitectura Escalable de Agregación de Logs usando Loki

Desplegar Solución Escalable de Loki

Desplegar un Loki escalable no es una tarea sencilla. Ya hemos hablado sobre Loki en publicaciones anteriores en el sitio, y se está volviendo cada vez más popular, y su uso se vuelve mucho más regular cada día. Es por eso que creo que tiene sentido incluir otra publicación sobre la Arquitectura de Loki.

Loki tiene varias ventajas que lo promueven como una opción predeterminada para desplegar una Pila de Agregación de Logs. Una de ellas es su escalabilidad porque puedes ver a través de diferentes modelos de despliegue cuántos componentes te gustaría desplegar y sus responsabilidades. Así que el objetivo del tema es mostrarte cómo desplegar una solución escalable de Loki y esto se basa en dos conceptos: componentes disponibles y cómo los agrupas.

Así que comenzaremos con los diferentes componentes:

  • ingester: responsable de escribir datos de logs en backends de almacenamiento a largo plazo (DynamoDB, S3, Cassandra, etc.) en la ruta de escritura y devolver datos de logs para consultas en memoria en la ruta de lectura.
  • distributor: responsable de manejar flujos entrantes por parte de los clientes. Es el primer paso en la ruta de escritura para los datos de logs.
  • query-frontend: servicio opcional que proporciona los puntos finales de la API del querier y puede usarse para acelerar la ruta de lectura.
  • querier: servicio que maneja consultas usando el lenguaje de consulta LogQL, obteniendo logs de los ingesters y del almacenamiento a largo plazo.
  • ruler: responsable de evaluar continuamente un conjunto de consultas configurables y realizar una acción basada en el resultado.

Luego puedes unirlos en diferentes grupos, y dependiendo del tamaño de estos grupos, tienes una topología de despliegue diferente, como se muestra a continuación:

Modo de Despliegue Monolítico de Loki
  • Monolito: Como puedes imaginar, todos los componentes se ejecutan juntos en una sola instancia. Esta es la opción más simple y se recomienda como un punto de partida de 100 GB / día. Incluso puedes escalar este despliegue, pero escalará todos los componentes simultáneamente, y debería tener un estado de objeto compartido.
Modo de Despliegue Escalable Simple de Loki
  • Modelo de Despliegue Escalable Simple: Este es el segundo nivel, y puede escalar hasta varios TB de logs por día. Consiste en dividir los componentes en dos perfiles diferentes: lectura y escritura.
Modo de Despliegue de Microservicios de Loki
  • Microservicios: Eso significa que cada componente será gestionado de manera independiente, dándote todo el poder en tus manos para escalar cada uno de estos componentes por separado.

Definir el modelo de despliegue de cada instancia es muy fácil, y se basa en un solo parámetro llamado target. Así que dependiendo del valor del target seguirá uno de los modelos de despliegue anteriores:

  • all (por defecto): Se desplegará en modo monolítico.
  • write: Será la ruta de escritura en el modelo de despliegue escalable simple
  • read: Será el grupo de lectura en el modelo de despliegue escalable simple
  • ingester, distributor, query-frontend, query-scheduler, querier, index-gateway, ruler, compactor: Valores individuales para desplegar un solo componente para el modelo de despliegue de microservicios.

El argumento target ayudará para un tipo de despliegue on-premises. Aún así, si estás usando Helm para la instalación, Loki ya proporciona diferentes charts de helm para los otros modelos de despliegue:

Pero todos esos charts de helm se basan en el mismo principio comentado anteriormente sobre definir el rol de cada instancia usando el argumento target, como puedes ver en la imagen a continuación:

MinIO: Almacenamiento de Objetos Multinube

Todo el poder del almacenamiento de objetos en tu entorno de Kubernetes

MinIO: Almacenamiento de Objetos Multi Nube
MinIO: Almacenamiento de Objetos Multi Nube (Foto por Timelab Pro en Unsplash)

En este post, me gustaría presentarles MinIO, una verdadera solución de almacenamiento de objetos en la nube con todas las características que puedas imaginar e incluso algunas más. Probablemente estés al tanto del almacenamiento de objetos del servicio AWS S3 que surgió hace algunos años y de la mayoría de las alternativas en los principales proveedores de nube pública como Google o Azure.

¿Pero qué pasa con las nubes privadas? ¿Existe algo disponible que pueda proporcionar todos los beneficios del almacenamiento de objetos, pero sin necesidad de depender de un solo proveedor de nube? Y aún más importante que eso, en el presente y futuro, donde todas las empresas van a ser multi nube, ¿tenemos a nuestra disposición una herramienta que proporcione todas estas características pero que no nos obligue a tener un bloqueo de proveedor? Incluso algunos software, como Loki, te animan a usar una solución de almacenamiento de objetos.

¡La respuesta es sí! Y de eso se trata MinIO, y solo quiero usar sus propias palabras:

“MinIO ofrece almacenamiento de objetos de alto rendimiento, compatible con S3. Nativo de Kubernetes, MinIO es la única suite de almacenamiento de objetos disponible en cada nube pública, distribución de Kubernetes, la nube privada y el edge. MinIO es definido por software y es 100% de código abierto bajo GNU AGPL v3.”

Así que, como dije, todo lo que puedas imaginar e incluso más. Centrémonos en algunos puntos:

  • Nativo de Kubernetes: Puedes desplegarlo en cualquier distribución de Kubernetes de tu elección, ya sea pública o privada (o incluso en el edge).
  • 100% de código abierto bajo GNU AGPL v3, por lo que no hay bloqueo de proveedor.
  • Almacenamiento de objetos compatible con S3, lo que incluso simplifica la transición para clientes con un fuerte vínculo con el servicio AWS.
  • El alto rendimiento es la característica esencial.

Suena genial. ¡Probémoslo en nuestro entorno! Así que voy a instalar MinIO en mi entorno de rancher-desktop, y para hacerlo, voy a usar el operador que tienen disponible aquí:

Para poder instalar, la opción recomendada es usar krew, el gestor de plugins del que ya hablamos en otro artículo. Lo primero que necesitamos hacer es ejecutar el siguiente comando.

 kubectl minio init

Este comando desplegará el operador en el clúster como puedes ver en la imagen a continuación:

Una vez hecho y todos los componentes estén en funcionamiento, podemos lanzar las interfaces gráficas que nos ayudarán a crear el inquilino de almacenamiento. Para hacerlo, necesitamos ejecutar el siguiente comando:

 kubectl minio proxy -n minio-operator

Esto expondrá la interfaz interna que nos ayudará durante ese proceso. Se nos proporcionará un token JWT para poder iniciar sesión en la plataforma como puedes ver en la imagen a continuación:

Ahora necesitamos hacer clic en el botón que dice “Crear Inquilino” que nos proporcionará un menú de asistente para crear nuestro inquilino de almacenamiento de objetos MinIO:

En ese asistente podemos seleccionar varias propiedades dependiendo de nuestras necesidades, como esto es para mi escritorio rancher, intentaré mantener la configuración al mínimo como puedes ver aquí:

Sería útil si tuvieras el espacio de nombres creado de antemano para ser recuperado aquí. Además, debes tener en cuenta que solo puede haber un inquilino por espacio de nombres, por lo que necesitarás espacios de nombres adicionales para crear otros inquilinos.

Tan pronto como presiones crear, se te proporcionará una clave API y un secreto que necesitas almacenar (o descargar) para poder usar más tarde, y después de eso, el inquilino comenzará su despliegue. Después de unos minutos, tendrás todos tus componentes en funcionamiento, como puedes ver en la imagen a continuación:

Si vamos a nuestro console-svc, encontrarás la siguiente interfaz gráfica disponible:

Después de que las credenciales se descarguen en el paso anterior, ingresaremos a la consola de nuestro almacenamiento de objetos en la nube y podremos comenzar a crear nuestros buckets como puedes ver en la imagen a continuación:

En la pantalla de creación de un bucket, puedes ver varias opciones, como Versionado, Cuota y Bloqueo de Objetos, que dan una visión de las características y capacidades que tiene esta solución.

Y podemos comenzar a subir y descargar objetos a este nuevo bucket creado:

Espero que puedas ver esto como una opción para tus despliegues, especialmente cuando necesitas una opción de solución de almacenamiento de objetos para despliegues privados o simplemente como una alternativa a AWS S3.

Principales 6 comandos de Kubectl y consejos de Kubectl

Los 6 mejores comandos de Kubectl y consejos de Kubectl
Los 6 mejores comandos de Kubectl y consejos de Kubectl

El comando kubectl puede ser el comando más utilizado que puedes escribir al trabajar con el ecosistema de Kubernetes. Como sabes, kubectl es la puerta de entrada a todo el mundo de Kubernetes, ya que prácticamente todas nuestras interacciones pasan por esa parte, a menos que estés utilizando un enfoque de CLI.

Entonces, basándonos en los principios de productividad, si puedes mejorar solo un 1% en la tarea que realizas más, la mejora global será masiva. Así que, veamos cómo podemos hacer eso aquí.

kubectl es un comando con muchas opciones diferentes que podrían ayudar a aumentar tu productividad mucho. Pero al mismo tiempo, como tiene tantas opciones, es bastante complejo conocerlas todas o estar al tanto de que hay una forma más rápida de hacer el trabajo, y por eso me gustaría agregar algunas opciones aquí para intentar ayudarte con este conjunto de consejos de kubectl.

Consejos de Comandos de Kubectl

Comencemos con los primeros comandos de kubectl que ayudan mucho a mejorar tu productividad:

kubectl explain <resource-object>

Este comando mostrará la referencia de la API para cualquier Objeto de Kubernetes, por lo que te ayudará a conocer la ortografía exacta de la opción que siempre escribes mal.

kubectl get <resource-object> —watch-output

La opción —watch-output añadida a cualquier comando de kubectl funcionará de la misma manera que el comando watch en sí, por lo que actualizará el mismo comando cada 2.0 segundos para ver la versión en tiempo real de ese comando y evitar que necesites escribirlo de nuevo o depender de un comando externo como watch

kubectl get events --sort-by=".lastTimestamp"

Este comando te ayudará cuando quieras ver los eventos en tu contexto actual, pero la principal diferencia es que ordenará la salida por la marca de tiempo de más reciente a más antiguo, por lo que evitarás tener que desplazarte para encontrar los últimos eventos.

kubectl logs --previous

Siempre hablamos de una de las necesidades de una Arquitectura de Agregación de Logs porque los logs son desechables, pero ¿qué pasa si quieres obtener los logs en un contenedor eliminado? Puedes usar la bandera --previous para acceder a los logs de un contenedor que se ha terminado recientemente. Esto no eliminará la necesidad de una técnica de agregación de logs, pero ayudará a solucionar problemas cuando Kubernetes comience a eliminar cosas y necesites saber qué sucedió.

kubectl create <object> <options> -o=yaml --dry-run=client

kubectl create nos permite crear un objeto de nuestra preferencia proporcionando los argumentos requeridos de manera imperativa, pero si añadimos la opción -o=yaml --dry-run=client, no obtendremos nuestro objeto creado. En su lugar, tendremos un archivo YAML que define ese objeto. Así que podemos modificarlo fácilmente a nuestras necesidades sin tener que hacerlo desde cero buscando en Google un ejemplo para comenzar.

kubectl top pods --all-namespaces --sort-by='memory'

Este comando alterará el orden estándar de top pods para mostrar los pods y los recursos que están consumiendo, y al mismo tiempo, ordenará esa salida por el uso de memoria. Así que, en entornos con muchos pods, proporcionará justo en la parte superior aquellos en los que deberías centrarte primero para optimizar los recursos de todo tu clúster.

Alias de Kubectl

Un paso más allá es simplificar esos comandos añadiendo un alias a esto. Como puedes ver, la mayoría de estos comandos son bastante largos ya que tienen muchas opciones, por lo que escribir cada una de estas opciones tomará un tiempo.

Entonces, si quieres ir un paso más allá en esta optimización, siempre puedes añadir un alias a ese comando para simplificarlo mucho. Y si quieres aprender más sobre esos alias, recomiendo encarecidamente el repositorio de GitHub de Ahmet Alp Balkan:

Operadores de Kubernetes: 5 cosas que realmente necesitas saber

Operadores de Kubernetes: 5 Cosas Que Realmente Necesitas Saber
Operadores de Kubernetes: 5 Cosas Que Realmente Necesitas Saber (Foto por Dan Lohmar en Unsplash)

El Operador de Kubernetes ha sido la nueva norma para desplegar grandes cargas de trabajo en Kubernetes, pero como algunos de estos principios no se alinean inmediatamente con los conceptos principales de Kubernetes, generalmente genera un poco de confusión y dudas cuando necesitas usarlos o incluso crearlos.

¿Qué Son los Operadores de Kubernetes?

Los operadores son la forma de extender las capacidades de Kubernetes para gestionar grandes cargas de trabajo donde se relacionan diferentes opciones. En componentes con una arquitectura distribuida, como un sistema de monitoreo, un sistema de agregación de registros, o incluso un service mesh, puedes encontrar eso. Basado en las palabras de la documentación oficial de Kubernetes, los operadores se definen de la siguiente manera:

Los operadores son extensiones de software para Kubernetes que utilizan recursos personalizados para gestionar aplicaciones y sus componentes. Los operadores siguen los principios de Kubernetes, notablemente el bucle de control.

Su uso principal es para servicios estándar y no tanto para aplicaciones simples o cargas de trabajo de usuario, pero podría usarse en casos incluso para ese escenario.

¿Cómo Funciona el Operador de Kubernetes?

El concepto central detrás del Operador de Kubernetes es el concepto de extensión. Se basa en la definición y gestión de objetos personalizados de Kubernetes llamados Definición de Recursos Personalizados (CRDs) que permiten una descripción al estilo Kubernetes de nuevos conceptos que podrías necesitar para tus cargas de trabajo.

Algunos ejemplos de estos CRDs son el ServiceMonitor o PodMonitor que explicamos en publicaciones anteriores, por ejemplo, pero hay muchos más para agregar. Entonces, eso significa que ahora tienes un nuevo archivo YAML para definir tus objetos, y puedes usar las primitivas principales de Kubernetes para crearlos, editarlos o eliminarlos según sea necesario.

Entonces, para que estos componentes realicen cualquier trabajo, necesitas codificar algunos controladores específicos que traduzcan los cambios realizados en esos archivos YAML para alcanzar primitivas al estado del clúster.

Patrón de Operador de Kubernetes (https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md#foundation)
Patrón de Operador de Kubernetes (https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md#foundation)

¿Cómo Gestionar los Operadores de Kubernetes?

El operador de Kubernetes se puede instalar como cualquier otra carga de trabajo de Kubernetes, por lo que dependiendo del caso puede distribuirse como un archivo YAML o un Helm Chart. Incluso puedes encontrar un repositorio compartido de operadores en OperatorsHub.

OperatorHub: Repositorio Central para Operadores de Kubernetes
OperatorHub: Repositorio Central para Operadores de Kubernetes

Operador de Kubernetes vs. Helm Charts

Como ya se discutió, no son el mismo tipo de objeto que los Helm Charts porque los Helm Charts solo funcionan a nivel de despliegue haciendo el empaquetado y gestionando esos lanzamientos, pero los operadores van un paso más allá porque gestionan y controlan el ciclo de vida a nivel de tiempo de ejecución. Y como se comentó, Helm y los Operadores son compatibles; este es, por ejemplo, cómo funciona el Operador de Prometheus que tiene un Helm Chart para desplegarse, como puedes encontrar aquí.

Cómo Construir un Operador de Kubernetes

Si tu objetivo después de leer esto es crear un Operador de Kubernetes, necesitas saber que ya existen algunos marcos que harán tu vida más fácil en esa tarea.

Herramientas como Kopf, kubebuilder, metacontroller, o incluso el CNCF Operator Framework te proporcionarán las herramientas y las tareas cotidianas para comenzar a enfocarte en lo que tu operador necesita hacer, y ellos manejarán las principales tareas diarias por ti.

 Más Recursos Para Aprender sobre el Operador de Kubernetes

Si deseas aprender más sobre los Operadores de Kubernetes o el patrón de Operador, en ese caso, te recomiendo encarecidamente que mires el Libro Blanco del Operador de CNCF que puedes encontrar aquí.

Esto cubrirá todos los temas discutidos anteriormente con más detalle técnico e introducirá otros temas vitales, como la gestión del ciclo de vida de la seguridad o incluso las mejores prácticas.

Otros recursos interesantes son el recurso bibliográfico del propio Libro Blanco que voy a agregar aquí por si deseas ir directamente a la fuente:

  • Dobies, J., & Wood, J. (2020). Kubernetes Operators. O’Reilly.
  • Ibryam, B. (2019). Kubernetes Patterns. O’Reilly.
  • Operator Framework. (n.d.). Operator Capabilities. Operator Framework. Retrieved 11 2020, 24, from https://operatorframework.io/operator-capabilities/
  • Philips, B. (2016, 03 16). Introducing Operators: Putting Operational Knowledge into Software. CoreOS Blog. Retrieved 11 24, 2020, from https://coreos.com/blog/introducing-operators.html
  • Hausenblas, M & Schimanski, S. (2019). Programming Kubernetes. O’Reilly.