Pero, ¿qué pasaría si los agentes de IA pudieran eliminar completamente estas herramientas intermedias (Terraform, Pulumi, OpenTofu, Crossplane)?

El Estado Actual: Capas Sobre Capas

Hoy en día, nuestro flujo típico se ve así:

Intención → Código IaC → Herramienta (Terraform) → API Provider → Infraestructura

Cada capa añade valor pero también complejidad:

• Terraform/Pulumi: Gestión de estado, planificación, sintaxis específica

• Proveedores: Traducción entre la herramienta y las APIs nativas

• Estado: Archivos .tfstate, backends remotos, locks de concurrencia

La Visión Disruptiva: Agentes IA Directos

Imagina un futuro donde un agente IA reciba instrucciones en lenguaje natural:

"Despliega una aplicación web escalable con base de datos, load balancer y certificados SSL automáticos en AWS"

Y ejecute directamente las llamadas API necesarias, sin código intermedio:

Intención → Agente IA → API Provider → Infraestructura

¿Es Técnicamente Viable?

La respuesta corta: Sí.

Los agentes IA modernos ya demuestran capacidad para:

• Interpretar intenciones complejas en lenguaje natural

• Entender documentación de APIs y sus interdependencias

• Ejecutar secuencias complejas de operaciones

• Manejar errores y reintentos de manera inteligente

Los Desafíos Técnicos (Y Sus Soluciones)

1. Gestión de Estado

Desafío: ¿Cómo saber qué infraestructura existe sin un archivo .tfstate?

Solución IA: El agente podría mantener su propio estado distribuido, consultando constantemente las APIs de los proveedores para sincronizar la realidad con su conocimiento interno.

2. Planificación y Diff

Desafío: ¿Cómo previsualizar cambios antes de ejecutarlos?

Solución IA: Un agente avanzado podría simular cambios, analizar dependencias en tiempo real y presentar un plan detallado, incluso mejor que el terraform plan actual.

3. Versionado y Auditoría

Desafío: ¿Cómo mantener trazabilidad de los cambios?

Solución IA: El agente podría generar automáticamente:

• Logs estructurados de cada operación

• Commits en repositorios Git con la configuración aplicada

• Reportes de compliance y seguridad

• Historiales de cambios navegables

4. Rollbacks y Recovery

Desafío: ¿Cómo revertir cambios problemáticos?

Solución IA: Con un conocimiento completo del estado actual y histórico, el agente podría implementar rollbacks más inteligentes, incluso prediciendo y previniendo problemas antes de que ocurran.

Las Ventajas Competitivas de los Agentes IA

Un agente IA no estaría limitado por las restricriciones de las herramientas actuales:

Análisis Inteligente

• Detectar configuraciones subóptimas

• Sugerir mejoras de costos automáticamente

• Identificar vulnerabilidades de seguridad en tiempo real

Adaptabilidad

• Aprender de patrones de la organización

• Adaptarse a nuevos servicios cloud sin actualizaciones de proveedores

• Optimizar recursos basado en métricas reales de uso

Interoperabilidad Natural

• Trabajar con múltiples clouds simultáneamente

• Migrar recursos entre proveedores de manera inteligente

• Integrar servicios on-premise y cloud sin configuración adicional

Los Obstáculos Para la Adopción

Confianza y Control

La industria necesitará ver que estos agentes son más confiables que los humanos escribiendo Terraform. Considerando la cantidad de bugs, configuraciones incorrectas y estados corruptos que vemos actualmente, esta vara no está tan alta.

Interoperabilidad Entre Agentes

¿Cómo migrar infraestructura entre diferentes agentes IA? ¿Cómo auditar sistemas desplegados por agentes de distintos vendors?

Regulación y Compliance

Sectores altamente regulados necesitarán marcos de certificación para agentes IA manejando infraestructura crítica.

El Punto de Inflexión

La transición no será inmediata, pero podríamos ver una evolución en fases:

Fase 1 (Actual): Agentes IA como generadores de código IaC Fase 2 (2-3 años): Agentes híbridos que mantienen workflows tradicionales pero automatizan la generación Fase 3 (5-7 años): Agentes completamente autónomos para casos de uso específicos Fase 4 (7-10 años): Reemplazo completo para la mayoría de casos de uso.

Reflexiones Finales

Esta evolución podría ser más disruptiva de lo que inicialmente pensamos. Si los agentes IA logran implementar sus propios sistemas confiables de gestión de estado y cambios, las herramientas intermedias como Terraform podrían convertirse en legado.

Para los profesionales de DevOps, esto no significa obsolescencia, sino evolución. Nuestro valor se desplazará hacia:

• Diseño de arquitecturas y políticas de alto nivel

• Supervisión y governance de agentes IA

• Integración entre sistemas complejos

• Resolución de problemas que requieren contexto humano

¿Qué opinas? ¿Estamos preparados para un futuro donde la infraestructura se gestione a través de conversaciones con IA en lugar de código?

¿Te ha gustado este análisis? Comparte tu perspectiva en los comentarios y conecta conmigo para más discusiones sobre el futuro de DevOps y la IA.

Durante más de una década, los contenedores han dominado el paisaje de las aplicaciones cloud native. Docker, Kubernetes, y todo el ecosistema de contenedores se han convertido en el estándar de facto para el despliegue de microservicios. Pero, ¿qué pasaría si te dijera que existe una tecnología que promete ser más segura, más rápida y más eficiente que los contenedores tradicionales?

Bienvenidos al mundo de los Unikernels. 🚀

¿Qué son los Unikernels? 🤔

Los unikernels son imágenes de máquinas virtuales especializadas que incluyen únicamente el código de la aplicación y las partes del sistema operativo necesarias para ejecutarla. A diferencia de los contenedores, que comparten el kernel del host, los unikernels son sistemas operativos (no como Linux o Windows - Solo Kernel y App), de propósito único compilados junto con la aplicación.

Contenedores vs Unikernels: La Batalla Tecnológica ⚔️

TL;DR: Los unikernels ofrecen mejor aislamiento, arranque más rápido y mayor seguridad, pero los contenedores tienen un ecosistema más maduro.

Arquitectura y Aislamiento 🏗️

Contenedores:

• Comparten el kernel del sistema operativo host

• Utilizan namespaces y cgroups para el aislamiento

• Múltiples contenedores ejecutándose sobre un solo kernel

• Superficie de ataque más amplia debido al kernel compartido

Unikernels:

• Cada unikernel es un sistema operativo completo y aislado (no es un SO tradicional como Linux o Windows, solo lleva el kernel y tu aplicativo - lo único necesario, sin mas procesos, librerías, módulos)

• Aislamiento a nivel de hipervisor (más fuerte que los contenedores)

• Superficie de ataque mínima - solo incluye lo necesario

• Inmutables por diseño

Rendimiento y Recursos 📊

Seguridad 🔒

Contenedores:

• Vulnerabilidades del kernel afectan a todos los contenedores

• Posibles escapes de contenedor

• Requieren hardening adicional del host

• Múltiples vectores de ataque

Unikernels:

• Aislamiento completo a nivel de hipervisor

• Superficie de ataque extremadamente reducida

• Sin shell o utilidades del sistema que puedan ser comprometidas

• Inmutabilidad inherente

Gestión y Orquestación 🎛️

Contenedores:

• Ecosistema maduro (Kubernetes, Docker Swarm)

• Herramientas de monitoreo y debugging bien establecidas

• Fácil depuración con acceso al contenedor

• Amplia adopción y documentación

Unikernels:

• Ecosistema emergente

• Herramientas de debugging limitadas

• Depuración más compleja (sin acceso directo)

• Curva de aprendizaje pronunciada

Casos de Uso Ideales para Unikernels 🎯

1. Funciones Serverless: Arranque instantáneo y uso mínimo de recursos

2. Microservicios de alta seguridad: Donde la superficie de ataque debe ser mínima

3. IoT y Edge Computing: Recursos limitados y requisitos de seguridad

4. Aplicaciones de alto rendimiento: Donde cada milisegundo cuenta

Ejemplo Práctico: Desplegando un Microservicio Java con Unikernels 💻

⚠️ Pre requisito: Este tutorial asume conocimientos básicos de Java, Maven y virtualización.

Vamos a crear un microservicio Java simple y desplegarlo usando GraalVM Native Image y Nanos como nuestro unikernel runtime.

Pre requisitos 📋

# Instalar GraalVM
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk install java 22.3-graal

# Instalar Nanos
curl https://nanos.org/install.sh -sSfL | sh

# Verificar instalación
ops version

💡 Tip: Para este tutorial se ha usado Nanos, puedes usar Unikraft, osv, QEMU u otro.

Paso 1: Crear el Microservicio Java ☕

// src/main/java/com/example/HelloUnikernel.java
package com.example;

import com.sun.net.httpserver.HttpServer;
import com.sun.net.httpserver.HttpHandler;
import com.sun.net.httpserver.HttpExchange;
import java.io.IOException;
import java.io.OutputStream;
import java.net.InetSocketAddress;
import java.time.LocalDateTime;
import java.util.concurrent.Executors;

public class HelloUnikernel {

    public static void main(String[] args) throws IOException {
        HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);

        server.createContext("/health", new HealthHandler());
        server.createContext("/hello", new HelloHandler());
        server.createContext("/metrics", new MetricsHandler());

        server.setExecutor(Executors.newCachedThreadPool());
        server.start();

        System.out.println("🚀 Unikernel microservice started on port 8080");
        System.out.println("📍 Endpoints:");
        System.out.println("  GET /health - Health check");
        System.out.println("  GET /hello - Hello world");
        System.out.println("  GET /metrics - Basic metrics");
    }

    static class HealthHandler implements HttpHandler {
        public void handle(HttpExchange exchange) throws IOException {
            String response = "{\"status\":\"UP\",\"timestamp\":\"" + 
                            LocalDateTime.now() + "\"}";
            exchange.getResponseHeaders().set("Content-Type", "application/json");
            exchange.sendResponseHeaders(200, response.getBytes().length);
            OutputStream os = exchange.getResponseBody();
            os.write(response.getBytes());
            os.close();
        }
    }

    static class HelloHandler implements HttpHandler {
        public void handle(HttpExchange exchange) throws IOException {
            String response = "{\"message\":\"Hello from Unikernel! 🎉\",\"technology\":\"Java + GraalVM + Nanos\"}";
            exchange.getResponseHeaders().set("Content-Type", "application/json");
            exchange.sendResponseHeaders(200, response.getBytes().length);
            OutputStream os = exchange.getResponseBody();
            os.write(response.getBytes());
            os.close();
        }
    }

    static class MetricsHandler implements HttpHandler {
        public void handle(HttpExchange exchange) throws IOException {
            Runtime runtime = Runtime.getRuntime();
            long memory = runtime.totalMemory() - runtime.freeMemory();
            String response = String.format(
                "{\"memory_used_bytes\":%d,\"memory_total_bytes\":%d,\"processors\":%d}",
                memory, runtime.totalMemory(), runtime.availableProcessors()
            );
            exchange.getResponseHeaders().set("Content-Type", "application/json");
            exchange.sendResponseHeaders(200, response.getBytes().length);
            OutputStream os = exchange.getResponseBody();
            os.write(response.getBytes());
            os.close();
        }
    }
}

🔍 Análisis del código: Hemos creado un microservicio simple con 3 endpoints que nos permitirán evaluar el rendimiento y funcionalidad del unikernel.

Paso 2: Configurar el Build 🔧

<!-- pom.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>hello-unikernel</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.graalvm.buildtools</groupId>
                <artifactId>native-maven-plugin</artifactId>
                <version>0.9.28</version>
                <extensions>true</extensions>
                <executions>
                    <execution>
                        <id>build-native</id>
                        <goals>
                            <goal>compile-no-fork</goal>
                        </goals>
                        <phase>package</phase>
                    </execution>
                </executions>
                <configuration>
                    <imageName>hello-unikernel</imageName>
                    <mainClass>com.example.HelloUnikernel</mainClass>
                    <buildArgs>
                        <buildArg>--no-fallback</buildArg>
                        <buildArg>--enable-http</buildArg>
                        <buildArg>--enable-https</buildArg>
                    </buildArgs>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Paso 3: Construir el Ejecutable Nativo ⚡

# Compilar la aplicación
mvn clean package -Pnative

# Verificar el ejecutable
ls -la target/hello-unikernel
file target/hello-unikernel

⏱️ Tiempo estimado: La compilación nativa puede tomar 2-5 minutos dependiendo de tu hardware.

Paso 4: Crear la Configuración del Unikernel ⚙️

{
  "Files": ["target/hello-unikernel"],
  "Dirs": ["target"],
  "Args": ["target/hello-unikernel"],
  "Boot": "target/hello-unikernel",
  "Env": {
    "USER": "root"
  },
  "MapDirs": {
    "target": "./target"
  },
  "Ports": ["8080"]
}

Paso 5: Construir y Ejecutar el Unikernel 🚀

# Construir la imagen del unikernel
ops build -c config.json

# Ejecutar el unikernel
ops run -c config.json -p 8080

# En otra terminal, probar los endpoints
curl http://localhost:8080/health
curl http://localhost:8080/hello
curl http://localhost:8080/metrics

🎉 ¡Felicidades! Si todo funciona correctamente, acabas de ejecutar tu primer microservicio en un unikernel.

Paso 6: Análisis de Rendimiento 📈

# Medir tiempo de arranque
time ops run -c config.json -p 8080 &

# Medir uso de memoria
ops run -c config.json -p 8080 &
ps aux | grep hello-unikernel

# Comparar con contenedor Docker equivalente
docker build -t hello-container .
time docker run -p 8081:8080 hello-container &

📊 Benchmark: Documenta estos resultados para comparar con contenedores tradicionales.

Resultados Esperados 📊

Al ejecutar este ejemplo, deberías observar:

🚨 Importante: Estos resultados pueden variar según tu hardware y configuración específica.

Herramientas del Ecosistema Unikernel 🛠️

Runtimes y Frameworks

• Nanos: Runtime de unikernel para Linux

• OSv: Sistema operativo diseñado para cloud

• MirageOS: Unikernels funcionales en OCaml

• IncludeOS: Framework C++ para unikernels

• Rumprun: Ejecuta aplicaciones POSIX sin modificaciones

• Unikraft: Dentro de los proyectos de la CNCF

Orquestación

• UniK: Compilador y orquestrador de unikernels

• Kubernetes con CRI-O: Soporte experimental para unikernels

• Firecracker: MicroVMs que pueden ejecutar unikernels

Limitaciones y Consideraciones ⚠️

💭 Reflexión: Como cualquier tecnología emergente, los unikernels no son una bala de plata.

Desafíos Actuales 🚧

1. Ecosistema inmaduro: Pocas herramientas comparado con contenedores

2. Debugging complejo: Sin acceso directo al sistema en ejecución

3. Curva de aprendizaje: Requiere cambio de mentalidad y nuevas habilidades

4. Limitaciones de lenguaje: No todos los lenguajes tienen soporte maduro

Cuándo NO usar Unikernels ❌

• Aplicaciones que requieren debugging frecuente

• Sistemas que necesitan acceso a muchas librerías del sistema

• Entornos que requieren alta flexibilidad operacional

• Equipos sin experiencia en virtualización de bajo nivel

El Futuro: ¿Coexistencia o Reemplazo? 🔮

Los unikernels no necesariamente reemplazarán completamente a los contenedores, pero están encontrando su nicho en:

1. Serverless Computing: Donde el arranque rápido es crucial

2. Edge Computing: Recursos limitados y requisitos de seguridad

3. Microservicios críticos: Donde la seguridad es prioritaria

4. IoT: Dispositivos con recursos extremadamente limitados

Conclusión 🎯

Los unikernels representan una evolución natural en la búsqueda de mayor eficiencia, seguridad y rendimiento en aplicaciones cloud native. Aunque aún están en una fase relativamente temprana de adopción, ofrecen ventajas significativas en casos de uso específicos.

Como profesionales Cloud Native, debemos estar preparados para esta nueva ola tecnológica. Los unikernels no son solo una curiosidad académica, sino una herramienta práctica que puede resolver problemas reales de seguridad y rendimiento que enfrentamos con los contenedores tradicionales.

🤔 La pregunta clave: No es si los unikernels tendrán un lugar en nuestro stack tecnológico, sino cuándo y cómo los adoptaremos de manera efectiva.

¿Estás listo para dar el salto a los unikernels? 🚀

¿Qué opinas? 💬

¿Has experimentado con unikernels en tu organización? ¿Crees que reemplazarán a los contenedores o coexistirán?

Comparte tu experiencia en los comentarios y ayuda a construir esta conversación. Si este artículo te fue útil, no olvides darle ❤️ y compartirlo con tu equipo.

Sígueme para más contenido Cloud Native 📱

• 🐦 Twitter: @stazdx

• 💼 LinkedIn: Staz

• 📚 GitHub: Staz

Referencias y Recursos Adicionales 📖

• Nanos Documentation

• GraalVM Native Image

• UniK Project

• MirageOS

• IncludeOS

• Unikraft

Helm is a package manager for Kubernetes that helps us to deploy custom applications and generate parameterized templates. This is very useful when it comes to deploying microservices on Kubernetes.

Helm was accepted into CNCF on January 18, 2016 and is at the Graduate project maturity level.

The package format used by Helm is called a chart. Helm has a command-line tool that makes it easy to create charts for us to customize and then deploy. Also has a registry where the community and companies share their charts. If you are looking for one, it probably already exists, you can check it out here.

You can review the documentation for more information on charts and best practices in its implementation.

Demo

This demo applies to any programming language and application/microservice you need to deploy on Kubernetes. Remember that it is a template and it is customizable.

Install and run an Ubuntu instance

I will use multipass to generate an ubuntu instance and microk8s to deploy kubernetes. Both are very good tools developed by Canonical.

Install multipass.

For this demo, create a very light ubuntu instance with 2GB of RAM and 5 GB of Disk space:

$ multipass launch --name demo --mem 2G --disk 5G

Install and setup microk8s

After that, install microk8s inside the ubuntu instance:

$ multipass shell demo
$ sudo su
$ snap install microk8s --classic --channel=1.18/stable
$ iptables -P FORWARD ACCEPT

The iptables command is necessary to permit traffic between the VM and host.

Create an alias for kubectl command:

$ alias k="microk8s kubectl"
$ k cluster-info

We already have our lightweight Kubernetes cluster using microk8s.

Install and setup Helm

$ snap install helm --classic
$ helm
$ microk8s config > ~/.kube/config

It is important to copy the microk8s configuration to the ~/.kube/config directory for Helm to work.

Create a Helm Chart

Then, we can create a Helm chart for our microservice.

$ helm create microservice-template
$ snap install tree
$ tree microservice-template

This is the file structure of a chart. In the following, we will explain the most important ones:

The most important files of a chart

Chart.yaml is required, and in this gist repository you have all the allowed fields. You can call their variables like this {{ .Chart.my_variable }}

values.yaml is the file containing all customizable input parameters for your chart. You can call their variables like this {{ .Values.my_variable }}

templates/_helpers.tpl is the file where you can transform your input values and even define global variables for your chart. These cannot be entered as input parameters.

Then there are the kubernetes manifests *.yaml which are the ones that will be created in your kubernetes cluster. These receive the input variables and the ones you have defined in Chart.yaml, values.yaml and _helpers.tpl files. Here is an example of what you can call them.

Using conditionals and calling variables

For example in the templates/hpa.yaml, this is a Horizontal Pods Autoscaler manifest that uses variables from the values.yaml file, _helpers.tpl and even uses if conditional to create certain properties:

The conditional says that if the value of the .Values.autoscaling.enabled variable is true the whole manifest will be created, but if it is false, it will not create it.

In this case, in values.yaml, the .Values.autoscaling.enabled parameter is false, then it will not create it.

Also, in the templates/hpa.yaml file uses microservice-template.fullname and microservice-template.labels, these refers to the variable that was defined in the _helpers.tpl file.

Also uses .Chart.name, .Chart.AppVersion that are found within Chart.yaml file.

.Release.Name refers to the name you assign when you install the chart, for example: helm install demo . -> . demo is the .Release.Name variable and .Release.Service is Helm.

** Validate a Helm chart**

helm lint

Create Kubernetes manifests using Helm

helm template .

Output:

WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config
---
# Source: microservice-template/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: RELEASE-NAME-microservice-template
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
---
# Source: microservice-template/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: RELEASE-NAME-microservice-template
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: RELEASE-NAME
---
# Source: microservice-template/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: RELEASE-NAME-microservice-template
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: microservice-template
      app.kubernetes.io/instance: RELEASE-NAME
  template:
    metadata:
      labels:
        app.kubernetes.io/name: microservice-template
        app.kubernetes.io/instance: RELEASE-NAME
    spec:
      serviceAccountName: RELEASE-NAME-microservice-template
      securityContext:
        {}
      containers:
        - name: microservice-template
          securityContext:
            {}
          image: "nginx:1.16.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}
---
# Source: microservice-template/templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "RELEASE-NAME-microservice-template-test-connection"
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['RELEASE-NAME-microservice-template:80']
  restartPolicy: Never

Debug and dry-run a Helm Chart

This command simulates a Helm Chart install and generates k8s manifests:

helm upgrade --install demo . --debug --dry-run

Output:

WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config
history.go:56: [debug] getting history for release demo
upgrade.go:139: [debug] preparing upgrade for demo
upgrade.go:147: [debug] performing update for demo
upgrade.go:310: [debug] dry run for demo
Release "demo" has been upgraded. Happy Helming!
NAME: demo
LAST DEPLOYED: Sun Jun 26 02:15:07 2022
NAMESPACE: default
STATUS: pending-upgrade
REVISION: 2
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
affinity: {}
autoscaling:
  enabled: false
  maxReplicas: 100
  minReplicas: 1
  targetCPUUtilizationPercentage: 80
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: nginx
  tag: ""
imagePullSecrets: []
ingress:
  annotations: {}
  className: ""
  enabled: false
  hosts:
  - host: chart-example.local
    paths:
    - path: /
      pathType: ImplementationSpecific
  tls: []
nameOverride: ""
nodeSelector: {}
podAnnotations: {}
podSecurityContext: {}
replicaCount: 1
resources: {}
securityContext: {}
service:
  port: 80
  type: ClusterIP
serviceAccount:
  annotations: {}
  create: true
  name: ""
tolerations: []

HOOKS:
---
# Source: microservice-template/templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "demo-microservice-template-test-connection"
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: demo
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['demo-microservice-template:80']
  restartPolicy: Never
MANIFEST:
---
# Source: microservice-template/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-microservice-template
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: demo
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
---
# Source: microservice-template/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: demo-microservice-template
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: demo
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: demo
---
# Source: microservice-template/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-microservice-template
  labels:
    helm.sh/chart: microservice-template-0.1.0
    app.kubernetes.io/name: microservice-template
    app.kubernetes.io/instance: demo
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: microservice-template
      app.kubernetes.io/instance: demo
  template:
    metadata:
      labels:
        app.kubernetes.io/name: microservice-template
        app.kubernetes.io/instance: demo
    spec:
      serviceAccountName: demo-microservice-template
      securityContext:
        {}
      containers:
        - name: microservice-template
          securityContext:
            {}
          image: "nginx:1.16.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=microservice-template,app.kubernetes.io/instance=demo" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

Install a Helm chart

$ helm install demo .

$ helm ls

$ k get all

I recommend using helm upgrade --install, because if the chart already exists, it will only apply the changes. If you use helm install and the chart already exists, returns an error.

Uninstall a Helm chart

$ helm del demo

Github example

Here, a simple example of a springboot chart:

Conclusion

You can use Helm if you have a lot of microservices and you want a template to easily deploy them in a parameterized way. Helm is not only for microservices, actually you can use it for everything.

I hope you find it useful and can apply it.

Later on we will see how powerful your deployments can be using GitOps, Kustomize and Helm.

If you are an advanced user and want to test it directly, just check the README.md -> Github

Resources:

• Spring boot project files

• Observability tools manifests

• Github repository

I always follow closely new open source tools and especially if it is about observability tools, I consider that the world of observability is very broad, complex and every time new interesting tools come out. Now, I present you some tools that have caught my attention. Before starting a brief introduction about the tools.

1. OpenTelemetry: It helps us to collect metrics, logs and traces using an agent; then it can send them to other tools. It has a lot of instrumentation power and integration with several programming languages. It is in incubation within the CNCF.

2. Prometheus: One of the largest and best known tools in the world of metric collection, it is graduated at the CNCF.

3. Exemplars: Tool that correlates the trace_id with metrics on the backend side. It is interesting because through resource metrics you can get traces and get to the log. It works hand in hand with Prometheus.

4. Promtail: Tool that sends the logs to Loki, just as Prometheus collects logs and works as an agent in each node of the cluster.

5. Loki: Tool that receives logs, centralizes them, distributes them, ingests, allows applying rules and has its own syntax to perform queries (LogQL). It has very good integration with Kubernetes.

6. Tempo: Tool that receives OpenTelemetry traces to be able to visualize them with an embedded interface (Jaeger). It has an intuitive visualization and integrates with Loki and exemplars.

7. Grafana: Interface that allows to integrate multiple datasources, dashboards, alerts and many other visualization tools.

Setting up a Backend Application

For this demo we will use Java - Spring Boot, since it is very common to see microservices projects with this framework.

The first thing we need is to create a Java Spring boot project, we will use https://start.spring.io/ . It helps you to quickly generate a Java project using Spring Boot, it also allows you to add the dependencies you will use and other configurations to the project.

Make sure to configure it as shown in the screenshot. In this case I will use Gradle as build automation tool, Spring Boot in version 2.7, JAR as package build format and JDK11.

When you finish the configuration click on Generate; you can download, unzip and import it into your favorite IDE (I will use Visual Studio Code, you can download it here).

We will set up our build.gradle in the root of the project, make sure you have all the dependencies:

plugins {
    id 'org.springframework.boot' version '2.7.0'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

repositories {
  maven {
    url = uri('https://repo.spring.io/libs-snapshot')
  }
    mavenCentral()
}

dependencyManagement {
  imports {
    mavenBom 'io.micrometer:micrometer-bom:1.9.0-SNAPSHOT'
  }
}

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-actuator'
  implementation 'io.micrometer:micrometer-registry-prometheus:1.9.0'
  implementation 'org.springframework.boot:spring-boot-starter-web'
  implementation 'io.opentelemetry:opentelemetry-api:1.12.0'
}

tasks.named('test') {
    useJUnitPlatform()
}

group = 'com.staz'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

Then we will create a Controller Class Controller.java with 2 endpoints: /fail and success. The file must be located in the path ${project}/src/main/java/com/staz/observability/ in my case.

package com.staz.observability;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class Controller {

    @PostMapping("/fail")
    public String fail() {
        return "Fail!";
    }

    @GetMapping("/success")
    public String success() {

        return "Success!";
    }

}

In order to correlate the Java metrics sent through prometheus with the trace_id generated by OpenTelemetry (using Exemplar), we will need to add a Configuration Class that will apply for the whole project PrometheusExemplarConfiguration.java in the same path as the previous ${project}/src/main/java/com/staz/observability/:

package com.staz.observability;

import io.micrometer.core.instrument.Clock;
import io.micrometer.prometheus.PrometheusConfig;
import io.micrometer.prometheus.PrometheusMeterRegistry;
import io.opentelemetry.api.trace.Span;
import io.prometheus.client.CollectorRegistry;
import io.prometheus.client.exemplars.DefaultExemplarSampler;
import io.prometheus.client.exemplars.tracer.otel_agent.
       OpenTelemetryAgentSpanContextSupplier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class PrometheusExemplarConfiguration {
    @Bean
    public PrometheusMeterRegistry prometheusMeterRegistryWithExemplar
    (PrometheusConfig prometheusConfig, CollectorRegistry collectorRegistry, 
    Clock clock) {
        return new PrometheusMeterRegistry(prometheusConfig, collectorRegistry, 
        clock, new DefaultExemplarSampler(new OpenTelemetryAgentSpanContextSupplier() {

                    @Override
                    public String getTraceId() {
                        if (!Span.current().getSpanContext().isSampled()) {
                            return null;
                        }
                        return super.getTraceId();
                    }
                })
        );
    }
}

Now, set the properties file application.yml -> ${project}/src/main/resources/ :

# Enable Actuator endpoints including Prometheus
management:
  endpoints:
    web:
      exposure:
        include: health, info, prometheus
  metrics:
    # Exemplar metrics
    distribution:
      percentiles-histogram:
        http.server.requests: true
      minimum-expected-value:
        http.server.requests: 5ms
      maximum-expected-value:
        http.server.requests: 1000ms

# Add trace_id in log. OpenTelemetry set this value using logger-mdc.
# https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/logger-mdc-instrumentation.md
logging:
  pattern:
    level: '%prefix(%mdc{trace_id:-0}) %5p'

In order to run it in our local environment we will need the OpenTelemetry Agent, for this demo I am using version 1.12.1. You can download it here.

Done, now in the terminal, from the root path of our project run:

$ gradle build -x test

Then to start Spring Boot with the Opentelemetry Agent, our project pointing to application.yml, run:

$ java -javaagent:opentelemetry-javaagent.jar -Dspring.config.location=src/main/resources/application.yml -jar build/libs/observability-0.0.1-SNAPSHOT.jar

Our application has been deployed on the default port for Spring Boot which is 8080. We will test our 2 endpoints htttp://localhost:8080/fail and htttp://localhost:8080/success.

For the first one the result should be a 405 Method Not Allowed error and for the second one it should show the message Success! with status code 200, this is how the result should look like:

Testing /fail endpoint:

Testing /success endpoint:

After having tested our endpoints we are going to see our Prometheus metrics, we will go to our actuator endpoint: http://localhost:8080/actuator/prometheus and look for the metrics we are interested in http_server_requests_seconds_count, http_server_requests_seconds_sum and http_server_requests_seconds_bucket.

To make sure Exemplar is correlating lod trace_id we will run a curl with the OpenMetrics header:

$ curl -H 'Accept: application/openmetrics-text; version=1.0.0; charset=utf-8' http://localhost:8080/actuator/prometheus | grep trace_id

We have our Spring Boot application ready, now we need to install the observability tools. Before that, we are going to install it on Kubernetes k3s locally, using Multipass we will create an ubuntu node and Helm to deploy our tools inside our single-node cluster.

Containerizing our Spring Boot project

Before creating our local cluster, let's create the Dockerfile for our Spring Boot Application, in the root of our project. If you don't have Docker installed, you can download it here.

# Download OpenTelemetryAgent
FROM curlimages/curl:7.81.0 AS OTEL_AGENT
ARG OTEL_AGENT_VERSION="1.12.1"
RUN curl --silent --fail -L "https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/download/v${OTEL_AGENT_VERSION}/opentelemetry-javaagent.jar" \
    -o "/tmp/opentelemetry-javaagent.jar"

# Build .JAR file
FROM gradle:7.1.1-jdk11-hotspot AS BUILD_IMAGE
COPY --chown=gradle:gradle . /home/gradle/src
WORKDIR /home/gradle/src
RUN gradle build -x test --no-daemon 

# Final image copying OTEL Agent and .JAR File
FROM gradle:7.1.1-jdk11-hotspot
ENV TIME_ZONE America/Lima
ENV TZ=$TIME_ZONE
ENV JAVA_OPTS "-Dspring.config.location=src/main/resources/application.yml"
COPY --from=OTEL_AGENT /tmp/opentelemetry-javaagent.jar /otel-javaagent.jar
COPY --from=BUILD_IMAGE home/gradle/src/build/libs/*.jar app.jar
ENTRYPOINT exec java -javaagent:/otel-javaagent.jar -jar app.jar

To test it we must build it and run it for it, run:

$ docker build --no-cache -t otel-springboot-prometheus .
$ docker run -it -p 8080:8080 otel-springboot-prometheus

After running them, you should be able to see the Spring Boot logs with the container started. Then in the browser you could go to http://localhost:8080/success and you should have the same result as before.

• Creating our local single-node cluster

To install an Ubuntu instance we will use Multipass. After installing it, we will create an Ubuntu instance passing as parameters node name, ram and disk that we will assign (minimum 4G of Ram and 10Gb Disk).

Go to the terminal and run:

$ multipass launch --name demo --mem 4G --disk 20G

We will log in our already created instance:

$ multipass shell demo

Verify that we are inside the instance and we will scale to root:

$ sudo su

Install k3s:

$ curl -sfL https://get.k3s.io | sh -

Add KUBECONFIG environment variable:

$ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

Verify that we have kubernetes installed:

$ kubectl cluster-info

Install Helm:

$ snap install helm --classic

Copy k3 KUBECONFIG in the ~/.kube/config directory:

$ kubectl config view --raw > ~/.kube/config

Verify that we have Helm installed:

$ helm

Deploying our Observability Stack

Now we are ready to deploy our Helm charts that install Prometheus, Promtail, Loki, Tempo and Grafana. We will also finally deploy our Spring Boot application.

All the following steps are done inside the demo node that we created before:

$ multipass shell demo
$ sudo su

Clone the repository to have the manifests at hand:

$ git clone https://github.com/stazdx/otel-springboot-grafana-tools.git
$ cd otel-springboot-grafana-tools/kubernetes

We will add the charts we will need for the tools and update the Helm repository:

$ helm repo add grafana https://grafana.github.io/helm-charts
$ helm repo update

Then we will create our namespace for the observability tools:

$ kubectl create ns observability

Installing Promtail

To install Promtail, run:

$ cd promtail
$ helm upgrade --install promtail grafana/promtail -n observability -f promtail.yaml

It is important thatPromtail points to Loki service called loki-loki-distributed-gateway.

Installing Loki

Deploy Loki inside the cluster by running:

$ helm upgrade --install loki grafana/loki-distributed -n observability

Here we are interested in the loki-loki-distributed-gateway service created by Loki, Promtail will need it to send the logs and Grafana will also need it to create it as datasource.

Installing Tempo

We locate ourselves in the directory where the manifests are located:

$ cd ../tempo

To install Tempo as a prerequisite we need to install minio you can find the repository here. It is a tool that helps us to simulate an AWS Object Storage s3 service.

For this, run:

$ kubectl apply -f minio.yaml

Minio is deployed in the default namespace, since it is a more generic tool for Object Storage, not directly for observability.

Now, to deploy Tempo, run:

$ helm upgrade --install tempo grafana/tempo-distributed -n observability -f tempo.yaml

Here we are interested in the tempo-tempo-distributed-query-frontend service that uses port 3100, since Grafana will need it to create it as a datasource.

Installing Prometheus and Grafana

To install Prometheus and Grafana we use this Git repository Github.

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update

After adding the helm repo to use, let's run it:

$ cd ../prometheus-grafana
$ helm dependency update
helm upgrade --install kube-prometheus-stack -n observability .

With this we automate the generation of datasources (Prometheus, Loki, Tempo) and dashboards of Grafana, also we will allow anonymous access to Grafana, since it is a demo. For production environment it is necessary to add authentication.

Checking our deployments

$ helm ls -n observability

$ kubectl get po -n observability

$ kubectl get svc -n observability

We can see that our observability tools were successfully deployed on our single-node Kubernetes cluster.

Deploying our Spring Boot Application on Kubernetes

To deploy it we are going to enter the directory where the manifest is located:

$ cd ../springboot-app

It is important to identify these configurations for it to work:

Our Service configuration must have these annotations so that it can send metrics to prometheus.

  annotations:
    # Annotations for Prometheus - scrape config 
    prometheus.io/path: '/actuator/prometheus'
    prometheus.io/port: 'actuator'
    prometheus.io/scrape: 'true'

Another very important one is to add the environment variables for Deployment, for communication with OpenTelemetry:

          env:
            - name: SERVER_PORT
              value: '8080'
            - name: MANAGEMENT_SERVER_PORT
              value: '8081'
            # Setting OTEL_EXPORTER_METRICS: none - Default: OTLP
            - name: OTEL_METRICS_EXPORTER
              value: none
            - name: OTEL_TRACES_EXPORTER
              value: otlp,logging
            # Setting Tempo Distributor Service using GRPC Port -> 4317
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: http://tempo-tempo-distributed-distributor.observability.svc.cluster.local:4317
            - name: OTEL_SERVICE_NAME
              value: springboot-app
            - name: KUBE_POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: OTEL_RESOURCE_ATTRIBUTES
              value: app=springboot-app

And finally we have the ConfigMap that contains our Grafana Dashboard for Spring Boot, this will allow us to see how Exemplar correlates with Tempo through metrics such as Request Latency.

Having explained this, we can now run our manifest:

kubectl apply -f springboot-app.yaml

Verify the created resources of our application by running:

$ kubectl get deploy,svc,cm -l app=springboot-app

We can see that everything deployed correctly, we can also see the external-ip of our Spring Boot Application 192.168.64.5 using port 8080 for our /fail and /success endpoints. The management port uses 8081 for the /actuator endpoints, the one we are interested in is /actuator/prometheus.

Testing endpoints

With the above information we just need to go to the browser and enter our endpoints:

Testing /fail -> http://{external-ip}:8080/fail, in my case:

Effectively it returns a Method Not Allowed 405 Error.

Testing /success -> http://{external-ip}:8080/success, in my case:

Effectively it returns success.

Testing /actuator/prometheus -> http://{external-ip}:8081/actuator/prometheus, in my case:

We can see that it returns the metrics correctly.

Testing Grafana

Now we have everything configured, ready to perform our troubleshooting process. In order to open grafana, we need to obtain the port, run:

kubectl get svc -n observability

Identify the port, in my case: 32656

Go to the browser -> http://{external-ip}:32656 :

We will validate that our automated datasources are imported:

We can see Prometheus, Loki, Tempo configured and we can test the connections:

Prometheus:

We can see Prometheus andTempo correlated bytrace_id, using Exemplars.

Loki:

We can see Loki and Tempo correlated by trace_id in the log.

Tempo:

We can see that here we correlate Tempo with Loki and map the app tag that we configured in the microservice.

• Let's put it to the test

We will see the log of our Spring Boot application, go to Explore:

Select Loki as datasource:

With Loki, we can make filters to the Kubernetes resources. We will use the app label of our Spring Boot application. If we have many pods with this label, the logs are centralized.

And we see how from the logs we can get to the trace:

Now let's see our Grafana dashboard:

We will see that the last one is Spring Boot Demo, this is the one that we create as ConfigMap at the moment of deploying our Spring Boot application.

This histogram shows Requests Latency, we can see the behavior of our Spring Boot application, we will see some stars, these are generated by Exemplar:

By hovering over it with the mouse, we can see how it is correlated to a trace_id which will then redirect us to Tempo when clicked:

We can see the trace that it generates and we can also see the log, since it is also correlated with Loki, when clicking we will have:

The screen is split and we can see the log it generates.

Finally we have implemented observability correlated between metrics, logs and traces. This can help us in the process of microservices troubleshooting, identify bottlenecks, see the behavior of our application metrics and be able to get to specific traces and logs.

If you made it this far, thank you very much for joining me in this demo. I'm happy to share with you all what I can learn!

Happy coding!

Surfing the internet, 99.9% of the results say that you can only do it with Parallels or VMware Fusion, the truth is that I am not a fan of these tools.

However I wanted to try with one of my favorite tools Multipass, which until then I used it with VirtualBox. Unfortunately VirtualBox does not work on M1-Based Mac.

But I was surprised to discover that Canonical had already been working on a version for M1-Based Mac without Virtualbox as of Multipass version 1.18.

I tried it and in two steps I had an instance of ubuntu running on my m1 based mac.

Below I quote the two steps needed:

1. Install Multipass for macOS at this link.

2. Open the terminal and run:

$ multipass launch --name node1

Fifty seconds later ...

We can check the instance type with the following command:

$ multipass exec node1 -- lsb_release -a

We can also enter to our Ubuntu instance:

Do not forget to stop your instance when you are not using it, you can even delete it completely if necessary. With the following commands:

$ multipass stop node1
$ multipass delete node1
$ multipass purge

If you wish, you can adjust the resources assigned to your instance, to generate several of them. You can view the available properties when running a new instance with the following command:

$ multipass launch -h

I hope you find it helpful, thank you very much for reaching the end of the post :).

Happy hacking!

We will need to create virtual machines on our PC/Laptop, for this I will use a Canonical product: Multipass. I have been using it for a long time and it is the best choice to create Ubuntu VMs in my opinion.

For cluster initialization, we will use kubeadm, as recommended in the official Kubernetes documentation.

Here I quote some reasons why it is better to use this stack against other options such as minikube, microk8s, k3s, RKE, EKS, AKS, GKE, and others:

1. The main reason: No need to install Docker, you will use containerd as the container runtime, crictl as cli for CRI compliant container runtime and if you need to build a Dockerfile, you will use podman.

2. There is no need to install extra dependencies on the Ubuntu VMs, what you need are clean nodes that only have what you need to work with.

3. You need that your cluster to be clean as well, you do not need to install extra Kubernetes resources such as CRDs, statefulsets, daemons, services, deployments, among others.

4. Multipass and Ubuntu were developed by Canonical, these have their support.

5. You need to have full control of your cluster, especially your control plane node. That’s why Kubernetes managed services are useless (EKS, AKS, GKE, and others).

6. You need Ubuntu nodes for simulating CKA/CKAD/CKS exams.

Requirements:

Make sure you have at least 4 GB of RAM,4 free CPU cores, and 20 Gb for VMs.

I recommend using these resources to avoid performance and disk space problems:

Control Plane (master node):

• 2 Gb RAM
• 2 CPU Core
• 10 Gb Disk

Worker (worker node):

• 2 Gb RAM
• 2 CPU Core
• 10 Gb Disk

Kubernetes Cluster Configuration

Without more to say here I attach a Git repository with the readme file where you can see the step by step for the Kubernetes cluster configuration:

https://github.com/stazdx/k8s-local-environment

Note: What is applied in this post is based on my experience, it isn’t the only way to be able to do it.

Happy coding!

Without further ado, I will give some considerations and tips so you can get the certifications in your first attempt. I have separated them into 3: Time, Speed and Space.

Time

Each exam lasts 2 hours, approximately 15 to 22 questions (depending on the exam). The exam is made so that you will not be able to finish it, so you must manage your time well.

Tips:

• Give priority to the questions that have higher scores.

You will see that there are questions that have a weight of 12%, 10%, 8%. These you have to do them yes or yes (it is the ideal). A common mistake is to do them in order, you may not have enough time and leave questions with high scores.

• Use the notepad provided by the exam.

Based on the first tip, something that has worked for me is to use the notepad to write down the pending questions (not solved yet, because they have lower scores) and the percentage that each one represents. As you solve them, you update the notepad. This will help you to have an approximation of the score you are accumulating.

• Avoid reviewing your solution if the process is long.

One thing I don't like about the exam is that the updates or changes you make to the Control Plane of your clusters take a long time and/or often get "stuck".

You will always want to verify your solution, but many times this just takes more time. I recommend that you trust yourself, practice will give you that confidence.

Velocity

You will have to be quick to try to finish all the questions, this can only be achieved with constant practice.

Tips:

• Learn the shortcuts of the vim editor and put it into practice.

I think this is the most important thing, since most of the time you will be editing files or creating new ones. Take advantage of the shortcuts and practice a lot.

• kubectl master

Learn the kubectl imperative commands and generate your manifests quickly by adding dry-run=client and -oyaml. This will help you generate a manifest quickly.

• Learn the structure of manifests

If you want to be faster, you will have to know very well the structure of your manifests. For example: where to place an annotation, security context, mount a volume, add labels, etc. This can only be done with practice (it takes a lot of time to search in the documentation to find out where in the manifest to add).

• Try to use the documentation as little as possible.

In the exam you only have access to a browser tab, for CKA and CKAD only to the kubernetes documentation. Practice how to quickly search for what you need and use the right panel to go to the specifics, for example:

Still, my recommendation would be to take the exam if you are sufficiently prepared, without using the documentation. In the case of CKS it is more critical, you can use only one tab too, but they are several pages of documentation (kubernetes, apparmor, falco, trivy, sysdig). It is uncomfortable to have to use only one browser tab to switch from one documentation to another.

Space

It is important that you practice as if you were actually taking the exam.

Tips:

• Simulate a cluster with Ubuntu servers (I will create another post for this soon, so you can do it on Windows, Linux and Mac).

• Be very careful at exam time, to be in the right context, as you will be working with several clusters and each question may use a different cluster.

• See well what each question asks you, many times we don't finish the whole question. Sometimes you are asked to save outputs or logs in a certain path and you can skip them.

• Make a backup of the files you will edit, because if you mess up one of them, you can lose a lot of time trying to fix it. If you mess up a cluster, you will not be able to solve several questions, so be careful!

• Use a prefix in your manifests, this will help you identify which question it belonged to, you can review them if you wish or finish something you left unfinished. For example: 1_pod.yaml, 2_networkpolicy.yaml.

• Forget Docker! In the exam you will use crictl to see the containers inside the servers, especially in the CKA, CKS.

For the CKS, your Linux level must be very good. Since in many questions you will be troubleshooting at kernel, syscalls, processes, networking, etc. level.

Finally, some extra recommendations:

• Go to the bathroom before giving the exam, ideally not to lose your concentration for a second.

• You can have a glass/bottle of water at your desk, but I do not recommend it. Give the exam with a fresh mind.

• I will soon add more posts so you can generate a local practice environment and also the fixes on each topic of the certifications.

Many successes :) !