Forem: Coles C

Kubernetes resources

Coles C — Wed, 25 Mar 2026 20:58:43 +0000

En Kubernetes, hay configuraciones que parecen pequeñas, pero tienen un impacto enorme en operación. Una de las más importantes es resources.

Muchos equipos la rellenan al final, copiando valores de otro deployment o usando números “razonables” sin validar nada. El problema es que Kubernetes sí se toma esos valores muy en serio. A partir de ahí decide dónde ubicar un pod, cuánto puede consumir y cómo se comporta el nodo cuando hay presión de recursos.

Por eso, cuando resources está mal definido, los síntomas aparecen rápido: pods en Pending, reinicios por OOMKilled, CPU throttling, degradación bajo carga o incluso Evicted en procesos con alto uso de almacenamiento temporal.

Qué estás definiendo realmente

Cuando declaras algo como esto:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

no estás simplemente completando un bloque del manifiesto. Le estás diciendo a Kubernetes dos cosas clave:

requests: lo mínimo que el contenedor necesita para que el scheduler lo coloque en un nodo.
limits: el máximo que ese contenedor puede llegar a consumir.

La diferencia importa mucho. Los requests afectan la planificación. Los limits afectan el comportamiento en tiempo de ejecución.

Si defines mal uno de los dos, el clúster empieza a tomar decisiones basadas en una realidad que no existe.

El error clásico: definir recursos a ojo

Este es uno de los errores más comunes en entornos reales. Se asignan valores porque “seguro con esto alcanza”, porque otro servicio usa algo parecido o porque interesa que el pod entre rápido en el nodo.

Ahí empiezan los problemas.

Si el request es demasiado alto, el pod puede quedarse en Pending porque ningún nodo tiene capacidad suficiente. Si es demasiado bajo, Kubernetes coloca más carga de la que el nodo realmente puede soportar. Si el limit es demasiado agresivo, el contenedor se vuelve inestable cuando aumenta el consumo. Y si no hay limits, una aplicación puede crecer sin control y afectar al resto de workloads.

Lo más peligroso es que muchas veces esto no explota al desplegar. Explota después, en producción, cuando llega tráfico, concurrencia o una ejecución inesperada.

Un ejemplo muy común en producción

Supongamos una API desplegada con esta configuración:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: orders-api
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      containers:
        - name: orders-api
          image: registry.example.com/orders-api:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "200m"
              memory: "256Mi"

En el papel, parece una configuración eficiente. Pero en la práctica, la aplicación arranca consumiendo entre 300 y 400 MiB y, en picos, supera 500 MiB.

¿Qué ocurre entonces?

Kubernetes planifica el pod pensando que necesita solo 128Mi de memoria. El nodo acepta más pods de los que realmente puede soportar. Cuando la aplicación entra en carga y supera el limit de 256Mi, el proceso termina en OOMKilled. El pod reinicia, sube la latencia, fallan peticiones y el equipo empieza a investigar la aplicación cuando, en realidad, el primer problema estaba en el manifiesto.

Una configuración más alineada con el comportamiento real podría ser esta:

resources:
  requests:
    cpu: "300m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "768Mi"

Aquí el scheduler trabaja con una reserva más realista, el nodo no se sobrecarga tan fácilmente y la aplicación tiene margen para absorber picos sin colapsar.

El recurso que muchos olvidan: ephemeral-storage

En entornos DevOps hay otro punto que suele pasarse por alto: ephemeral-storage.

Esto aparece mucho en pipelines de Jenkins sobre Kubernetes, builds con Kaniko, procesos batch, cargas temporales o contenedores que generan archivos intermedios. Aunque CPU y memoria estén bien definidas, un uso elevado de disco efímero puede hacer que el pod termine en Evicted.

Ejemplo:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
    ephemeral-storage: "1Gi"
  limits:
    cpu: "1000m"
    memory: "1Gi"
    ephemeral-storage: "2Gi"

Si tu workload descarga artefactos, genera cachés o escribe mucho en /tmp, ignorar este recurso puede convertirse en un problema operativo serio.

Cómo definir resources de forma correcta

La respuesta no está en adivinar mejor. Está en medir.

La forma sana de trabajar esto es observar el consumo real de la aplicación, entender su comportamiento base y sus picos, y ajustar a partir de datos. Los requests deberían acercarse al uso normal. Los limits deberían dejar margen, pero sin caer en valores exagerados que falseen la capacidad del clúster.

Bien definidos, los resources mejoran el scheduling, hacen más predecible el autoscaling, reducen reinicios innecesarios y ayudan a usar mejor la infraestructura. Mal definidos, convierten el clúster en una fuente constante de síntomas difíciles de interpretar.

Conclusión

resources no es un bloque decorativo del YAML. Es una de las decisiones más importantes que tomas sobre cómo va a vivir tu aplicación dentro de Kubernetes.

Cuando está bien configurado, aporta estabilidad, previsibilidad y control. Cuando está mal, aparecen errores que parecen de aplicación, pero en realidad son de operación.

En Kubernetes, muchas veces el problema no es que falten recursos. El problema es no haber descrito bien cuántos necesitaba de verdad tu workload.

10 problemas Linux comunes para un DevOps

Coles C — Tue, 05 Aug 2025 22:08:25 +0000

Trabajar con Linux es el pan de cada día para un DevOps Engineer. Sin un dominio mínimo de su funcionamiento, es fácil cometer errores que pueden dejarte sin acceso al servidor, romper configuraciones críticas o afectar la disponibilidad de una aplicación en producción. Conocer estos problemas comunes y cómo resolverlos te ayudará a ganar confianza y a manejar sistemas Linux de forma más segura y eficiente. Aquí te comparto los 10 más habituales y sus soluciones.

1. Confusión de directorios (`/var/log`, `/etc`, `/usr/bin`)

/var/log → almacena logs del sistema y aplicaciones.
/etc → contiene configuraciones (ej. nginx.conf, ssh/sshd_config).
/usr/bin → binarios ejecutables del sistema (comandos).

👉 Error común: borrar o mover archivos críticos por no diferenciar su función.

2. Cambiar el puerto SSH y quedarse fuera

El acceso remoto por defecto es puerto 22.
Si lo cambias en /etc/ssh/sshd_config sin configurar bien firewall (iptables, ufw, security group en AWS), te bloqueas.

👉 Solución: tener siempre otra sesión abierta o acceso de emergencia (ej. consola en AWS).

3. Intentar matar un proceso zombi

Un zombie es un proceso terminado pero que aún aparece en ps porque su padre no lo ha recogido.
No se puede matar con kill.

👉 Solución: matar o reiniciar el proceso padre, o esperar a que libere al zombi.

4. Instalar paquetes con `apt` sin revisar dependencias

Comando: sudo apt install paquete.
Puede eliminar paquetes dependientes al hacer upgrades.

👉 Siempre usar:

apt show paquete (ver detalles).
apt-get -s install paquete (simulación antes de instalar).

5. Borrar logs sobredimensionados

Logs en /var/log/ pueden crecer mucho (syslog, auth.log, nginx/access.log).
Si los borras directo con rm, las apps pueden fallar porque el file descriptor sigue apuntando.

👉 Mejor: truncate -s 0 archivo.log o usar logrotate.

6. Crear scripts con `sudo` y no poder editarlos

Ejemplo: sudo nano script.sh → queda como root.
Después tu usuario no puede modificarlo.

👉 Usar:

sudo chown usuario:usuario script.sh (cambiar dueño).
O sudoedit para editar sin cambiar permisos.

7. Confundir proceso, servicio y demonio

Proceso → programa en ejecución (ps, top).
Servicio → proceso gestionado por systemd o init.d.
Daemon → proceso en background (ej. sshd).

👉 Error común: intentar reiniciar un proceso directo en vez del servicio (systemctl restart nginx).

8. Romper `iptables` y bloquear acceso

iptables gestiona firewall en Linux.
Una regla mal escrita puede cortar acceso SSH a todos.

👉 Siempre:

Probar reglas con iptables -L.
Guardar backup: iptables-save > backup.rules.
Usar at o cron para restaurar reglas en caso de error.

9. Montar un volumen encima de otro

mount /dev/xvdf /mnt/data sobre un directorio con datos → se ocultan.
Los datos siguen ahí, pero inaccesibles hasta desmontar (umount).

👉 Ver antes con: lsblk, df -h.

10. Cron ejecuta como root, tú como user

Tareas en /etc/crontab o crontab -e pueden ejecutarse con distintos usuarios.
Resultado: variables de entorno distintas, rutas distintas. 👉 Siempre especificar rutas absolutas en cron y comprobar con whoami dentro del script.

En resumen: dominar estos puntos de Linux te da una base sólida como DevOps/Cloud Engineer, porque gran parte de los workloads en la nube corren sobre Linux (Amazon Linux, Ubuntu, Debian).

Docker componentes esenciales

Coles C — Tue, 20 May 2025 11:12:04 +0000

Docker ha revolucionado el mundo del desarrollo y la implementación de software, haciendo que empaquetar, distribuir y ejecutar aplicaciones sea más fácil que nunca. Pero, ¿alguna vez te has preguntado qué piezas forman este ecosistema? Hoy vamos a repasar los componentes principales de Docker, para ayudarte a comprender cómo encajan entre sí.

🧱 1. Imágenes (Images)

Una imagen es una plantilla de solo lectura utilizada para crear contenedores. Incluye el código de la aplicación, bibliotecas, dependencias y todo lo necesario para ejecutarla.

📦 2. Contenedor (Container)

Un contenedor es una instancia en ejecución de una imagen. Se trata de un paquete independiente y liviano que ejecuta la aplicación de manera consistente sin importar el entorno.

🔧 3. Dockerfile

Este archivo es una especie de receta que define paso a paso cómo construir una imagen. Es el punto de partida para automatizar la creación de entornos de desarrollo o producción.

📁 4. Volúmenes (Volumes)

Los volúmenes permiten persistir datos fuera del ciclo de vida de un contenedor. Esto es ideal cuando necesitas que tus datos sobrevivan reinicios o se compartan entre múltiples contenedores.

🐳 5. Docker Daemon

El Docker Daemon es un servicio que corre en segundo plano y se encarga de gestionar objetos de Docker (contenedores, imágenes, redes, etc.). Es el motor detrás de todo.

⚙️ 6. Docker Engine

El Docker Engine es la combinación del daemon, una API REST y la interfaz de línea de comandos (CLI). Es el componente central que permite construir, ejecutar y administrar contenedores.

🚀 Conclusión

Comprender estos componentes te ayudará a dominar Docker desde sus fundamentos. Cada uno cumple una función específica, y juntos hacen posible la magia del desarrollo basado en contenedores.

¿Te gustaría que hablemos más a fondo sobre alguno de estos componentes? ¡Déjamelo saber en los comentarios!

GitOps, Automatiza tu despliegue usando Flux y Kubernetes 🚀

Coles C — Mon, 19 May 2025 10:09:46 +0000

En este artículo veremos cómo implementar una estrategia GitOps usando Flux, un operador para Kubernetes que mantiene tu clúster sincronizado con un repositorio Git. Esta es una guía práctica que puedes seguir para automatizar tus despliegues de manera segura y reproducible.

¿Qué es GitOps?

GitOps es una metodología que utiliza Git como única fuente de verdad para las configuraciones e infraestructura. Cada cambio se realiza mediante pull requests y se refleja automáticamente en el entorno.

Beneficios clave:

Historial de cambios claro y auditable.
Reversión sencilla usando git revert.
Automatización del ciclo de vida de aplicaciones.

¿Qué es Flux?

Flux es una herramienta CNCF que actúa como un controlador que se ejecuta dentro de tu clúster de Kubernetes y aplica automáticamente los cambios definidos en tus repositorios Git.

Requisitos previos

Un clúster de Kubernetes (puedes usar kind para pruebas locales o cualquier proveedor cloud).
kubectl configurado.
flux CLI instalado (instrucciones).
Un repositorio Git (GitHub, GitLab, etc.).

🧪 Ejemplo simple: Despliegue de una app con Flux

Paso 1: Instalar Flux

flux bootstrap github \
  --owner=tu-usuario \
  --repository=tu-repo \
  --branch=main \
  --path=clusters/mi-cluster \
  --personal

Paso 2: Estructura del repositorio

.
├── clusters/
│   └── mi-cluster/
│       ├── kustomization.yaml
│       └── apps/
│           └── nginx/
│               ├── deployment.yaml
│               └── kustomization.yaml

Ejemplo de kustomization.yaml en apps/nginx/:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml

clusters/mi-cluster/kustomization.yaml:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 1m
  path: ./clusters/mi-cluster/apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system

Paso 3: Despliegue automático

git add .
git commit -m "Agregar despliegue de nginx"
git push

🌱 Ejemplo avanzado: Múltiples entornos (dev y prod)

Una estrategia común en GitOps es separar los entornos por carpetas, usando Kustomize para sobreescribir valores.

Estructura del repositorio

.
├── apps/
│   └── nginx/
│       ├── base/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       ├── dev/
│       │   ├── kustomization.yaml
│       │   └── patch.yaml
│       └── prod/
│           ├── kustomization.yaml
│           └── patch.yaml
├── clusters/
│   ├── dev/
│   │   └── kustomization.yaml
│   └── prod/
│       └── kustomization.yaml

`apps/nginx/base/kustomization.yaml`

resources:
  - deployment.yaml

`apps/nginx/dev/kustomization.yaml`

resources:
  - ../base
patchesStrategicMerge:
  - patch.yaml

Y patch.yaml podría modificar el número de réplicas:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1

`apps/nginx/prod/patch.yaml`

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3

`clusters/dev/kustomization.yaml`

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nginx-dev
  namespace: flux-system
spec:
  interval: 1m
  path: ./apps/nginx/dev
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  targetNamespace: dev

Y análogamente para prod.

Verificación y monitoreo

flux get kustomizations
kubectl get pods -n dev
kubectl get pods -n prod

Conclusión

Flux y GitOps te permiten automatizar múltiples entornos de forma limpia y reproducible. Separar dev y prod con Kustomize mantiene tus bases reutilizables y tus entornos consistentes.

¿Te gustaría ver un ejemplo con Helm Charts o integración con ArgoCD? ¡Déjalo en los comentarios! 🙌

Dockerizar una aplicación de Node.js 🚀

Coles C — Tue, 21 Jan 2025 13:24:54 +0000

Dockerizar tu aplicación de Node.js es una excelente manera de asegurar que se ejecute de manera consistente en cualquier entorno. En este artículo, te mostraré cómo crear un Dockerfile, construir una imagen y ejecutar un contenedor para tu proyecto Node.js.

Paso 1: Configurar el proyecto de Node.js

Comencemos creando una aplicación básica de Node.js.

Archivo: server.js

const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('¡Hola, mundo desde Docker!');
});

app.listen(port, () => {
  console.log(`Servidor escuchando en http://localhost:${port}`);
});

Asegúrate de tener un archivo package.json con las dependencias necesarias:

npm init -y
npm install express

Paso 2: Crear un Dockerfile

El Dockerfile es un archivo que define cómo construir la imagen de tu contenedor.

Archivo: Dockerfile

# Utilizar una imagen base de Node.js
FROM node:16-alpine

# Crear un directorio de trabajo
WORKDIR /app

# Copiar los archivos de la aplicación al contenedor
COPY package*.json ./
COPY server.js ./

# Instalar dependencias
RUN npm install

# Exponer el puerto de la aplicación
EXPOSE 3000

# Comando para ejecutar la aplicación
CMD ["node", "server.js"]

Paso 3: Crear el archivo `.dockerignore`

Para evitar copiar archivos innecesarios al contenedor, crea un archivo .dockerignore:

Archivo: .dockerignore

node_modules
npm-debug.log

Paso 4: Construir la imagen Docker

Usa el siguiente comando para construir la imagen:

docker build -t nodejs-app .

Paso 5: Ejecutar el contenedor

Inicia un contenedor con la imagen que acabas de crear:

docker run -p 3000:3000 nodejs-app

Abre tu navegador y accede a http://localhost:3000. ¡Deberías ver el mensaje "¡Hola, mundo desde Docker!"! 🎉

Paso 6: Opcional - Publicar la imagen en Docker Hub

Si deseas compartir tu imagen, primero inicia sesión en Docker Hub:

docker login

Luego etiqueta tu imagen y publícala:

docker tag nodejs-app tu-usuario/nodejs-app
docker push tu-usuario/nodejs-app

Conclusión

Dockerizar una aplicación de Node.js es fácil y útil para garantizar la portabilidad de tu código. Este es solo el comienzo: puedes agregar herramientas como docker-compose o crear configuraciones más avanzadas.

Espero que este tutorial te haya sido útil. Si tienes dudas, ¡deja un comentario! 😊

Vagrant comandos básicos

Coles C — Sun, 03 Nov 2024 18:34:31 +0000

0. Instalación

Instalar proveedor de virtualización

Vagrant requiere un proveedor de virtualización, como VirtualBox, VMware o QEMU. Descarga e instala el proveedor de tu elección.
Descargar e instalar Vagrant

Visita la página oficial de Vagrant y descarga el instalador adecuado para tu sistema operativo. Luego, sigue las instrucciones de instalación.
Verificar la instalación

Una vez que hayas instalado Vagrant, abre una terminal y ejecuta el siguiente comando para asegurarte de que esté correctamente instalado:

   vagrant --version

1. Inicializar Vagrant en un directorio

vagrant init

Crea un archivo Vagrantfile en el directorio actual, donde puedes especificar la configuración de la máquina virtual.

2. Crear y levantar la máquina virtual

vagrant up

Descarga la caja especificada en el Vagrantfile y levanta la máquina virtual.

3. Acceder a la máquina virtual

vagrant ssh

Inicia sesión en la máquina virtual a través de SSH.

4. Suspender la máquina virtual

vagrant suspend

Pausa la máquina virtual, guardando su estado en la RAM.

5. Detener la máquina virtual

vagrant halt

Apaga la máquina virtual de forma segura.

6. Reiniciar la máquina virtual

vagrant reload

Reinicia la máquina virtual y recarga su configuración.

7. Destruir la máquina virtual

vagrant destroy

Elimina la máquina virtual. No afecta al Vagrantfile ni a las configuraciones guardadas.

8. Actualizar la caja de Vagrant

vagrant box update

Actualiza la caja a la última versión disponible.

9. Listar cajas disponibles

vagrant box list

Muestra todas las cajas que están descargadas en tu entorno local.

10. Agregar una caja manualmente

vagrant box add <nombre_caja> <url_caja>

Permite agregar una caja descargada o desde una URL.

11. Eliminar una caja

vagrant box remove <nombre_caja>

Elimina una caja específica de Vagrant de tu sistema local.

12. Mostrar el estado de la máquina virtual

vagrant status

Indica si la máquina está en ejecución, detenida o no ha sido creada.

13. Mostrar el ID de la máquina virtual

vagrant global-status

Muestra el estado de todas las máquinas de Vagrant y sus IDs.

14. Sincronizar carpetas compartidas

vagrant rsync

Sincroniza los archivos entre el sistema host y la máquina virtual en caso de usar rsync para carpetas compartidas.

15. Verificar versión de Vagrant

vagrant --version

Muestra la versión actual de Vagrant instalada.

Estos comandos cubren las operaciones más comunes y te permitirán gestionar entornos virtuales de desarrollo con Vagrant de manera efectiva.

Git comandos útiles

Coles C — Tue, 20 Aug 2024 14:11:29 +0000

Iniciar un repositorio

git init

Clonar un repositorio

git clone <url_repositorio>

Ver el estado del repositorio

git status

Agregar un archivo al área de preparación (stage)

git add <archivo>

Agregar todos los cambios al área de preparación

git add .

Confirmar cambios con un mensaje

git commit -m "mensaje"

Listar ramas

git branch

Crear una nueva rama

git branch <rama>

Cambiar a una rama específica

git checkout <rama>

Fusionar una rama con la rama actual

git merge <rama>

Ver los remotos configurados

git remote -v

Obtener cambios de una rama remota

git pull origin <rama>

Enviar cambios a una rama remota

git push origin <rama>

Ver el historial de confirmaciones

git log

Ver el historial de confirmaciones en una sola línea

git log --oneline

Revertir una confirmación específica

git revert <commit>

Restablecer a una confirmación específica

git reset <commit>

Listar las etiquetas

git tag

Crear una etiqueta anotada

git tag -a v1.0 -m "etiqueta"

Configurar el nombre de usuario global

git config --global user.name "nombre"

Configurar el correo electrónico global

git config --global user.email "correo"

Linux networking tools

Coles C — Sun, 16 Jun 2024 12:12:59 +0000

𝗦𝗼𝘂𝗿𝗰𝗲: https://wizardzines.com/networking-tools-poster/

share in the section comments your favorite tool :)

Linux networking tools

Coles C — Sun, 16 Jun 2024 12:12:59 +0000

𝗦𝗼𝘂𝗿𝗰𝗲: https://lnkd.in/grHR7Kdv

share in the section comments your favorite tool :)

Administración Kubernetes

Coles C — Tue, 30 Jan 2024 17:08:05 +0000

Hoy quiero compartir con ustedes una guía muy útil para quienes trabajamos con Kubernetes. En esta entrada encontrarás los comandos más esenciales de kubectl para gestionar clústeres, pods, despliegues, servicios, configuraciones y más.

🛠️ Primeros pasos con kubectl

Para administrar y obtener información sobre un clúster de Kubernetes, puedes usar la herramienta de línea de comandos kubectl, que es el cliente oficial de Kubernetes.

1️⃣ Instalar kubectl

Asegúrate de tener kubectl instalado en tu máquina. Puedes encontrar instrucciones de instalación en la documentación oficial de Kubernetes:

🔗 Instalar kubectl

2️⃣ Configurar kubectl

Después de instalarlo, necesitas configurar kubectl para conectarte al clúster. Esto normalmente implica:

Proporcionar la dirección del servidor API del clúster.
Establecer las credenciales de autenticación necesarias.

Puedes hacerlo utilizando el comando:

kubectl config

🚀 Comandos Esenciales

A continuación, comandos por categoría para que puedas navegar Kubernetes con soltura:

📦 Comandos de clúster

kubectl cluster-info # Muestra información del clúster
kubectl get nodes -o wide # Lista todos los nodos y muestra sus IPs

🐳 Comandos de pods

kubectl get pods # Lista todos los pods
kubectl get pods -o wide # Información detallada de pods
kubectl get pods -l <label>=<valor> # Filtra pods por etiqueta
kubectl get pod <nombre> # Muestra un pod específico
kubectl describe pod <pod> # Detalles del pod
kubectl logs <pod> # Muestra logs de un pod
kubectl exec -it <pod> -- <cmd> # Ejecuta un comando en un pod
kubectl delete pod <pod> # Elimina un pod
kubectl explain pod <recurso> # Muestra descripción del recurso Pod

🚢 Comandos de despliegue

Estos comandos te permiten gestionar despliegues (Deployments), que son controladores que administran el ciclo de vida de tus pods y aseguran que el estado deseado se mantenga activo en el clúster.

kubectl create deployment <nombre> --image=<imagen> # Crea un nuevo despliegue
kubectl get deployments # Lista todos los despliegues
kubectl describe deployment <nombre> # Detalles de un despliegue específico
kubectl scale deployment <nombre> --replicas=<número> # Escala un despliegue a más (o menos) réplicas
kubectl rollout restart deployment/<nombre> # Reinicia el despliegue
kubectl rollout status deployment/<nombre>  # Muestra el estado del rollout
kubectl create deployment <nombre> --image=<imagen> -o yaml # Genera el YAML del despliegue sin aplicarlo
kubectl create deployment <nombre> --image=<imagen> -o yaml --dry-run=client # Genera el YAML del Deployment sin aplicarlo.
kubectl create deployment <nombre> --image=<imagen> -o yaml --dry-run=client > nombre.yaml # Genera y guarda el YAML del Deployment en un archivo.

🌐 Comandos de servicios

Los servicios permiten exponer aplicaciones ejecutándose en tus pods, ya sea para el acceso interno o externo.

kubectl get services # Lista todos los servicios
kubectl describe service <nombre> # Detalles de un servicio específico
kubectl expose pod <nombre> # Crea un servicio que expone un pod
kubectl delete service <nombre> # Elimina un servicio
kubectl port-forward <pod> <puerto-local>:<puerto-remoto> # Redirige tráfico del host al pod

🧩 ConfigMaps y Secrets

ConfigMaps y Secrets te permiten manejar configuración y datos sensibles (como contraseñas o tokens) por separado del código de tus aplicaciones.

kubectl create configmap <nombre> --from-literal=<clave>=<valor> # Crea un ConfigMap desde un valor literal
kubectl create secret generic <nombre> --from-literal=<clave>=<valor> # Crea un Secret genérico
kubectl get configmaps # Lista todos los ConfigMaps
kubectl get secrets # Lista todos los Secrets
kubectl describe configmap <nombre> # Detalla un ConfigMap específico

🗂️ Namespaces

Los namespaces permiten dividir recursos dentro de un mismo clúster en espacios lógicos aislados.

kubectl get namespaces # Lista todos los namespaces
kubectl create namespace <nombre> # Crea un nuevo namespace
kubectl delete namespace <nombre> # Elimina un namespace
kubectl config set-context --current --namespace=<nombre> # Cambia el contexto actual al namespace indicado

🛠️ Recursos

Manejo general de recursos definidos en archivos YAML o JSON.

kubectl apply -f <archivo> # Aplica un archivo de configuración
kubectl edit <tipo> <nombre> # Edita un recurso directamente desde el editor
kubectl delete -f <archivo> # Elimina un recurso definido en archivo
kubectl get <tipo> # Lista recursos por tipo
kubectl describe <tipo> <nombre> # Muestra detalles de un recurso específico

📊 Estadísticas y eventos

Estos comandos te ayudan a monitorear el uso de recursos y eventos recientes en el clúster.

kubectl top nodes # Muestra el uso de CPU/Memoria por nodo
kubectl top pods # Muestra el uso de CPU/Memoria por pod
kubectl events # Lista eventos recientes (versión antigua)
kubectl get events # Lista eventos recientes (formato moderno)

🔐 Permisos

Consulta sobre roles definidos en el clúster, útiles para manejar RBAC (control de acceso basado en roles).

kubectl get roles # Lista todos los roles definidos en el clúster

¿Tienes algún comando favorito que no aparece aquí? ¡Déjalo en los comentarios! 👇

¿Te gustaría ver más contenido como este? ¡Sígueme para más tips de DevOps y Kubernetes en español! 🚀🐳

Docker comandos basicos

Coles C — Wed, 22 Nov 2023 22:44:03 +0000

Docker es una plataforma de contenerización que facilita la creación, implementación y ejecución de aplicaciones en entornos aislados llamados contenedores. Aquí tienes algunos comandos básicos de Docker que te pueden resultar útiles:

docker version: Muestra la versión de Docker que está instalada en tu sistema.

$ docker version

docker info: Proporciona información detallada sobre la configuración de Docker, como el número de contenedores y de imágenes.

$ docker info

docker pull: Descarga una imagen de Docker desde Docker Hub o cualquier otro registro de imágenes.

$ docker pull nginx

docker images: Lista las imágenes de Docker que están almacenadas localmente en tu sistema.

$ docker images

docker run: Crea y ejecuta un contenedor a partir de una imagen.

$ docker run -d -p 80:80 --name mi-aplicacion nginx

-d: Ejecuta el contenedor en segundo plano.
-p 80:80: Mapea el puerto 80 del host al puerto 80 del contenedor.
--name mi-aplicacion: Asigna el nombre "mi-aplicacion" al contenedor.
nginx: La imagen a partir de la cual se creará el contenedor.

docker stop: Detiene un contenedor en ejecución.

$ docker stop mi-aplicacion

docker ps: Muestra los contenedores en ejecución.

$ docker ps

para mostrar todos los contenedores, tanto los que están en ejecución como los detenidos.

$ docker ps -a

docker start: Inicia un contenedor detenido.

$ docker start mi-aplicacion

docker restart: Detiene y vuelve a iniciar un contenedor.

$ docker restart mi-aplicacion

docker rm: Elimina un contenedor.

$ docker rm mi-aplicacion

docker rmi: Elimina una imagen.

$ docker rmi nginx

docker exec: Ejecuta un comando dentro de un contenedor en ejecución.

$ docker exec -it mi-aplicacion /bin/bash

docker logs: Muestra los registros (logs) de un contenedor en ejecución.

$ docker logs [nombre-pod]
...
$ docker logs -f [nombre-pod]

Estos son solo algunos comandos básicos de Docker. Hay muchos más comandos y opciones disponibles para satisfacer diversas necesidades. Puedes obtener más información sobre cada comando utilizando el comando docker --help o consultando la documentación oficial de Docker en https://docs.docker.com/.

Git comandos básicos

Coles C — Wed, 15 Nov 2023 18:14:14 +0000

Aunque hay cientos de comandos diferentes de Git, hay unos pocos que se utilizan con más frecuencia, entre ellos:

git config: Este comando se utiliza para establecer la configuración específica de usuario o de repositorio. Puedes configurar tu nombre de usuario, dirección de correo electrónico, colores de interfaz, entre otras opciones.

$ git config --global user.name "Tu Nombre"
$ git config --global user.email "tu@email.com"

git clone: Este comando se utiliza para clonar un repositorio existente en un nuevo directorio. Descarga una copia de un repositorio remoto, incluidos todos los historiales y ramas.

$ git clone <URL_del_repositorio>

git init: Este comando se utiliza para iniciar un nuevo repositorio Git. Crea un nuevo directorio y configura los archivos de control de versiones de Git.

$ git init

git status: Muestra el estado actual del repositorio. Te dice qué archivos han cambiado, están pendientes de ser confirmados o no están siendo rastreados por Git.

$ git status

git push: Este comando se utiliza para enviar los cambios locales al repositorio remoto.

$ git push <nombre_remoto> <rama_local>

git add: Agrega cambios al área de preparación (staging area). Permite seleccionar qué cambios se incluirán en la próxima confirmación.

$ git add <nombre_archivo>

git commit: Registra los cambios confirmados en el repositorio. Crea un punto de control con un mensaje que describe los cambios realizados.

$ git commit -m "Mensaje descriptivo"

git branch: Muestra, crea o borra ramas. También se puede usar para cambiar entre ramas.

$ git branch                    # Muestra las ramas
$ git branch <nombre_rama>      # Crea una nueva rama
$ git branch -d <nombre_rama>   # Borra una rama

Estos son comandos básicos y muy utilizados en Git. Cada uno de ellos tiene opciones adicionales que puedes explorar en la documentación oficial de Git o mediante la ayuda integrada (git help <comando>).

Forem: Coles C

Kubernetes resources

Qué estás definiendo realmente

El error clásico: definir recursos a ojo

Un ejemplo muy común en producción

El recurso que muchos olvidan: ephemeral-storage

Cómo definir resources de forma correcta

Conclusión

10 problemas Linux comunes para un DevOps

1. Confusión de directorios (/var/log, /etc, /usr/bin)

2. Cambiar el puerto SSH y quedarse fuera

3. Intentar matar un proceso zombi

4. Instalar paquetes con apt sin revisar dependencias

5. Borrar logs sobredimensionados

6. Crear scripts con sudo y no poder editarlos

7. Confundir proceso, servicio y demonio

8. Romper iptables y bloquear acceso

9. Montar un volumen encima de otro

10. Cron ejecuta como root, tú como user

Docker componentes esenciales

🧱 1. Imágenes (Images)

📦 2. Contenedor (Container)

🔧 3. Dockerfile

📁 4. Volúmenes (Volumes)

🐳 5. Docker Daemon

⚙️ 6. Docker Engine

🚀 Conclusión

GitOps, Automatiza tu despliegue usando Flux y Kubernetes 🚀

¿Qué es GitOps?

¿Qué es Flux?

Requisitos previos

🧪 Ejemplo simple: Despliegue de una app con Flux

Paso 1: Instalar Flux

Paso 2: Estructura del repositorio

Paso 3: Despliegue automático

🌱 Ejemplo avanzado: Múltiples entornos (dev y prod)

Estructura del repositorio

apps/nginx/base/kustomization.yaml

apps/nginx/dev/kustomization.yaml

apps/nginx/prod/patch.yaml

clusters/dev/kustomization.yaml

Verificación y monitoreo

Conclusión

Dockerizar una aplicación de Node.js 🚀

Paso 1: Configurar el proyecto de Node.js

Paso 2: Crear un Dockerfile

Paso 3: Crear el archivo .dockerignore

Paso 4: Construir la imagen Docker

Paso 5: Ejecutar el contenedor

Paso 6: Opcional - Publicar la imagen en Docker Hub

Conclusión

Vagrant comandos básicos

0. Instalación

1. Inicializar Vagrant en un directorio

2. Crear y levantar la máquina virtual

3. Acceder a la máquina virtual

4. Suspender la máquina virtual

5. Detener la máquina virtual

6. Reiniciar la máquina virtual

7. Destruir la máquina virtual

8. Actualizar la caja de Vagrant

9. Listar cajas disponibles

10. Agregar una caja manualmente

11. Eliminar una caja

12. Mostrar el estado de la máquina virtual

13. Mostrar el ID de la máquina virtual

14. Sincronizar carpetas compartidas

15. Verificar versión de Vagrant

Git comandos útiles

Iniciar un repositorio

Clonar un repositorio

Ver el estado del repositorio

Agregar un archivo al área de preparación (stage)

Agregar todos los cambios al área de preparación

Confirmar cambios con un mensaje

Listar ramas

Crear una nueva rama

Cambiar a una rama específica

Fusionar una rama con la rama actual

Ver los remotos configurados

1. Confusión de directorios (`/var/log`, `/etc`, `/usr/bin`)

4. Instalar paquetes con `apt` sin revisar dependencias

6. Crear scripts con `sudo` y no poder editarlos

8. Romper `iptables` y bloquear acceso

`apps/nginx/base/kustomization.yaml`

`apps/nginx/dev/kustomization.yaml`

`apps/nginx/prod/patch.yaml`

`clusters/dev/kustomization.yaml`

Paso 3: Crear el archivo `.dockerignore`