Notas del curso Docker a fondo e Introducción a Kubernetes: aplicaciones basadas en contenedores del Clúster TIC de Galicia.

• Horas: 60
• Fecha Inicio: 13/02/2024
• Fecha Fin: 09/04/2024

En este curso aprenderás a dominar Docker desde cero hasta el nivel avanzado, y tendrás las nociones necesarias para empezar a trabajar con Kubernetes.

En la primera parte del curso, aprenderás los conceptos básicos de Docker, como qué es y cómo funciona, además de conocer los usos que tiene y lo que es un contenedor y una imagen. Aprenderás a gestionar imágenes y contenedores, cómo crear imágenes y subirlas a un repositorio.

En la segunda parte, abordaremos escenarios multicontenedor con herramientas como docker-compose, además de aprender a trabajar con networking en Docker y cómo usar contextos.

La tercera parte se centra en escenarios avanzados para, por ejemplo, usar Docker para compilar y crear imágenes sin tener que instalar el framework (como .NET o Node) o cómo depurar utilizando contenedores. También sabrás cómo sacar partido a la tecnología de contenedores en entornos Windows y no solo Linux.

En la última parte del curso abordaremos Kubernetes, el orquestador de contenedores más utilizado del mundo. Aprenderás los conceptos básicos de Kubernetes, cómo funciona, cómo crear y configurar pods, cómo desplegar aplicaciones sin estado y cómo exponer tu aplicación al exterior.

Con este curso, tendrás las habilidades necesarias para crear y desplegar aplicaciones en contenedores con Docker y Kubernetes, y estarás preparado para aplicar tus conocimientos en proyectos reales tanto para desarrollo como para despliegue de sistemas.

• Parte 1. Conceptos básicos de Docker
  • Módulo 1: Introducción a Docker.
  • Módulo 2: Gestión de imágenes y contenedores
  • Módulo 3: Creación de imágenes
• Parte 2. Escenarios multi-contenedor
  • Módulo 4: Docker Compose
  • Módulo 5: Uso de Docker Compose en escenarios multicontenedor
  • Módulo 6: Un ejemplo práctico real
  • Módulo 7: Las redes en Docker
  • Módulo 8: Contextos en Docker
• Parte 3. Escenarios “avanzados” con Docker
  • Módulo 9: Usar Docker para compilar
  • Módulo 10: Contenedores Windows
  • Módulo 11: Depurar contenedores
  • Módulo 12: Visual Studio Code "Dev Containers"
• Parte 4. Kubernetes (k8s)
  • Módulo 13: Introducción a Kubernetes
  • Módulo 14: Pods y servicios
  • Módulo 15: Despliegues declarativos en Kubernetes
  • Módulo 16: Desplegar aplicaciones SIN estado en Kubernetes
  • Módulo 17: Configurar contenedores
  • Módulo 18: Exponer la aplicación al exterior

¿Qué diferencia hay entre las instrucciones ARG y ENV del Dockerfile?

• ENV admite valores por defecto, mientras que ARG no
• Ninguna. Son dos comandos equivalentes
• ARG crea una variable de entorno del contenedor y ENV crea una variable en tiempo de construcción
• ENV crea una variable de entorno del contenedor y ARG crea una variable en tiempo de construcción (correcto)

¿Qué diferencias hay entre bind mounts y volúmenes?

• Los bind mounts se ven como un directorio en el contenedor. Los volúmenes como una unidad externa
• Los volúmenes pueden persistir en almacenamientos externos. Los bind mounts solo en el host (correcto)
• Los bind mounts son de lectura y escritura. Los volúmenes de solo lectura
• Los volúmenes son manejados por Docker, los bind mounts solo mapean una carpeta del host al contenedor (correcto)
• La CLI docker volumes permite ver y eliminar volúmenes y bind mounts
• La CLI docker volumes permite ver y eliminar volúmenes, pero no bind mounts (correcto)

Dadas las siguientes instrucciones del Dockerfile:

CMD node server.js

y

CMD ["node", "server.js"]

Marca todas las opciones correctas.

• La primera es incorrecta. Solo la segunda es válida
• La segunda es incorrecta. Solo la primera es válida
• Ambas son correctas (correcto)
• La primera establece “node server.js” como comando inicial del contenedor
• La segunda establece “node server.js” como comando inicial del contenedor (correcto)
• La primera establece “/bin/sh - c 'node server.js'” como comando inicial del contenedor (correcto)
• La segunda establece “/bin/sh - c 'node server.js'” como comando inicial del contenedor

La imagen “my-image” recibe peticiones por su puerto 5000. Creas un contenedor usando: docker run -p 5000:5000 my-image ¿Cómo envías peticiones al contenedor?

• Usando http://my-image:5000
• Usando http://localhost:5000 (correcto)
• No puedes acceder al puerto 5000 del contenedor desde tu máquina
• Usando http://localhost
• Usando http://my-image

Tienes un contenedor de MySql. Te das cuenta de que cada vez que lo pones en marcha (con docker run), los datos de la base de datos se han perdido. ¿Qué soluciones hay? (Marca todas las correctas)

• Asegurarse de no parar nunca el contenedor
• Usar un bind mount, de forma que los datos de la bbdd se guarden en el host (correcto)
• Usar un volumen (correcto)
• Tener dos contenedores MySql configurados en clúster, de forma que siempre haya al menos uno de ellos levantado

¿Qué relación hay entre contenedores y microservicios?

• Los contenedores no son apropiados para arquitecturas de Microservicios
• Si usas microservicios debes usar contenedores
• Si usas contenedores ya estás usando microservicios, aunque es posible microservicios sin contenedores
• Los contenedores pueden ayudar en arquitecturas de Microservicios (correcto)

¿Qué relación hay entre imagen y contenedor?

• Una imagen es un contenedor pausado. La imagen puede copiarse a otro ordenador y continuar la ejecución
• Una imagen describe los datos de un contenedor y su configuración. A partir de una imagen se crean contenedores (correcto)
• A partir de un contenedor se crean imágenes para conservar distintos estados de su ejecución y volver a ellos más tarde
• Un contenedor contiene (de ahí su nombre) varias imágenes, permitiendo cambiar de una a otra

Marca todas las respuestas correctas referentes a los bind mounts:

• Los usamos cuando queremos compartir ficheros entre el contenedor y el host (correcto)
• Un bind mount puede persistirse en almacenamientos externos (discos virtuales, etc)
• El contenedor no puede escribir datos en un bind mount ya que esos son de solo lectura
• Un bind mount mapea un directorio del host en un directorio del contenedor (correcto)

Desde un terminal ejecutas tres veces el comando “docker run -d hello-world”. ¿Qué es lo que ocurre?

• No puedes ejecutarlo tres veces, el primer “docker run” bloquea el terminal hasta que el contenedor termine
• La segunda vez te da un error de que el contenedor “hello-world” ya existe
• Terminas con tres contenedores distintos ejecutando tres veces la imagen “hello-world” (correcto)
• Terminas con un solo contenedor ejecutando “hello-world”, ya que la 2a y 3a vez que usas el comando este se ignora por ya existir el contenedor

¿Qué hace la sentencia FROM del Dockerfile?

• Indica la imagen base de la imagen que se está definiendo (correcto)
• Indica la URL de donde descargar el sistema de ficheros de la imagen
• Indica la ubicación en disco de la imagen base
• Indica qué ficheros forman parte del sistema de ficheros de la imagen

¿Qué pasa si usas el comando?: docker compose up -f compose-file1.yml -f compose-file2.yml

• Compose combina ambos ficheros en un único fichero y levanta la aplicación definida por ese “fichero combinado” (correcto)
• Compose levanta primero la aplicación del primer fichero y luego la aplicación del segundo
• Da un error ya que solo se admite un fichero compose
• Compose levanta primero la aplicación del primer fichero y cuando se termina (todos los contenedores finalizan) levanta la aplicación del segundo

¿Es buena idea que la configuración forme parte de la imagen?

• No. Lo ideal es que la configuración la proporcione el entorno (correcto)
• Sí: debes usar instrucciones ENV para establecer dicha configuración
• Sí: debes usar instrucciones COPY para copiar los ficheros de configuración en la imagen
• Sí, porque de esa manera la imagen funciona con independencia del entorno.

Para configurar compose usamos:

• Ficheros en formato XML
• Ficheros en formato JSON
• Ficheros en formato YAML (correcto)
• Ficheros en un formato propio de compose

Tienes el siguiente fichero compose:

version: '3.4'
services:
  helloworld:
    image: dockercampusmvp/go-hello-world
    ports:
     - "80:80"
  db:
    image: mysql
    profiles:
     - db

Si lo ejecutas con docker compose --profile db up, ¿Cuántos contenedores se crean?

• Se ejecuta un contenedor ejecutando la imagen dockercampusmvp/go-hello-world
• Se ejecuta un contenedor ejecutando la imagen mysql
• Se crea un contenedor ejecutando la imagen dockercampusmvp/go-hello-world y otro ejecutando la imagen mysql (correcto)
• Da error, ya que el fichero es incorrecto

Tienes un contenedor que:

• Escucha por su puerto 80
• Su IP propia es 10.72.10.3
• El puerto 80 del host está mapeado al 8000 del host

Abres un navegador y verificas que http://localhost:8000 funciona correctamente. No obstante hay otro contenedor ejecutándose que se intenta conectar con este. Cuando intenta usar http://localhost:8000 da error. Ambos contenedores se han lanzado usando docker compose up.

¿Qué URL se podría usar para que el segundo contenedor se pueda comunicar con el primero?

• http://10.72.10.3:8000
• http://10.72.10.3:80 (correcto)
• http://localhost:80
• http://localhost:8000 es correcto, pero debe abrirse el firewall de la red de Docker
• http://localhost:8000 es correcto, pero ambos contenedores deben estar en la misma red docker

Un desarrollador te pasa un fichero en Kotlin. No tienes SDK ni runtime de Kotlin en tu máquina, pero necesitas ejecutar el proyecto. ¿Qué harías?

• Crear una máquina virtual con el SDK de Kotlin y ejecutar el proyecto allí.
• Instalarte el SDK de Kotlin
• Crear un Dockerfile multi-stage build para generar una imagen de Docker y ejecutarla (correcto)
• Ir con un compañero que tenga Kotlin instalado

Un desarrollador está haciendo pruebas con Docker y ha ejecutado el comando docker build -t myimage .. El Dockerfile es muy sencillo, simplemente contenía una sentencia FROM, pero la construcción de la imagen ha tardado mucho tiempo. El desarrollador ya tenía la imagen base descargada. ¿Qué otra posible causa puede haber?

• Ha ejecutado la sentencia desde un directorio con un contexto de build muy grande. (correcto)
• Falta de memoria RAM
• Falta de espacio en disco, que provoca el uso de swap
• Versión antigua de docker, que no usa BuildKit

Tienes un servidor de docker, pero quieres controlarlo desde tus ordenadores. ¿Cómo puedes hacerlo, de la forma más sencilla?

• Pones el servidor en un lugar accesible y cuando sea necesario te desplazas allí y usas docker
• Instalas algún sistema de control remoto (como p. ej. TeamViewer) y accedes al servidor desde tu ordenador
• Usas un contexto de docker, apuntando al daemon de Docker del ordenador remoto (correcto)
• Abres una conexión SSH, entras en el ordenador remoto y usas docker

¿Es admisible que un contenedor use stdout para lanzar trazas?

• Es irrelevante: toda salida a stdout es ignorada y se pierde
• Sí, ya que eso permite el uso de docker logs para analizar las trazas (correcto)
• No. Los contenedores no tienen acceso a stdout (genera un error)
• Sí, ya que eso permite el uso de docker cp para analizar las trazas

¿Cuál es la mejor manera de pasarle un fichero de configuración a un contenedor? Sin este fichero el contenedor da error nada más arrancar

• Abriendo sesión interactiva con el contenedor, crear a mano el fichero de configuración y luego usar docker commit para crear una nueva imagen
• Copiando el fichero con el comando “docker cp”
• Usando un “bind mount” (correcto)
• Añadiendo una sentencia COPY en el Dockerfile para copiar el fichero de configuración y recrear la imagen

Tienes un StatefulSet con 3 pods. El StatefulSet define una plantilla de PVC. Luego se desescala el StatefulSeta dos pods. ¿Qué ocurre con el PVC del tercer pod, con la configuración por defecto del StatefulSet?

• Se elimina automáticamente
• Se mantiene (correcto)
• El desescalado da error, ya que hay que eliminar manualmente el PVC antes

Un desarrollador necesita conectarse a la BBDD de desarrollo, pero no conoce la cadena de conexión. Actualmente hay un pod que usa dicha cadena de conexión. El YAML del pod es como sigue:

apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
  - name: app
    image: acme-org/client:v1
    env:
    - name: DB_CONSTR
      valueFrom:
      - secretKeyRef:
        name: db-data
        key: constr

¿Qué le indicas al desarrollador para que pueda ver la cadena de conexión?

• Que pregunte al departamento de seguridad
• Que ejecute el comando kubectl get secret db-data -o yaml y luego decodifique el valor de la clave constr que estará en BASE64. (correcto)
• Que ejecute el comando kubectl get cm db-data -o yaml y mire el valor de la clave constr
• Que mire los logs del pod
• Que mire los logs del nodo
• Que abra una sesión interactiva con el pod y ejecute el comando env
• grep DB_CONSTR

¿Todos los pods de un StatefulSet tienen que tener la misma plantilla?

• Para nada, para crear pods idénticos se usa el Deployment
• Sí, porque un StatefulSet crea siempre pods idénticos (correcto)
• Sólo si no usan volúmenes persistentes
• El StatefulSet no crea pods, crea estados.

¿Es posible configurar un StatefulSet para que elimine un PVC cuando el StatefulSet es desescalado?

• Sí, con la opción whenScaled a Delete (correcto)
• No, porque los PVCs son eliminados automáticamente cuando se elimina un pod
• No, solo puedes configurar que se borren los PVCs al eliminar el StatefulSet entero
• No, los PVCs siempre deben ser eliminados manualmente

¿Puedes exponer MySQL a través de NodePort?

• No, debes usar Ingress
• No, debes usar un servicio ExternalName
• No, debes usar un servicio LoadBalancer
• No, debes usar un servicio ClusterIP
• Sí (correcto)

Listado de todos los comandos que salen en el curso:

• docker --version: verifica la versión de Docker instalada.
• docker context
• docker context ls: listar contextos actuales.
• docker context use <NOMBRE_CONTEXTO>: cambia de contexto.
• docker context create shared-vm --docker host=tcp://shared-vm:2735: crea un contexto que apunta a TCP://shared-vm:2375 (donde debe haber un daemon de Docker escuchando por el puerto 2735).
• docker context import <nombre-contexto>: exporta un contexto.
• docker context import <nombre-contexto> <nombre-fichero>: importa un contexto.
• docker pull <NOMBRE_IMAGEN>: descarga una imagen
• docker images: lista las imágenes descargadas
  • docker images -q: solo muestra las IDs de las imágenes
  • docker images -f: filtra las imágenes según criterio
  • docker images -a: muestra las imágenes intermedias.
  • docker images --no-trunc: muestra el ID entero de las imágenes.
• docker rmi <IMAGEN>: borra una imagen (hay que indicar la ID para que la borre realmente).
  • docker rmi $(docker images -q): borra todas las imágenes que tengamos.
  • docker rmi -f <IMAGEN>: borra la imagen aunque tenga contenedores en marcha que la usen.
  • docker rmi $(docker images -f "dangling=true" -q): elimina las imágenes que no están en uso por otras imágenes.
• docker run <NOMBRE_IMAGEN>: crea un contenedor a partir de una imagen
  • docker run –name <NOMBRE_CONTENEDOR> <NOMBRE_IMAGEN>: establecer un nombre al contenedor.
  • docker run -d <NOMBRE_IMAGEN>: libera el terminal tras la creación (segundo plano).
  • docker run -d -p 8080:80 <IMAGEN>: redirige el puerto 8080 del host al 80 del contenedor creado.
  • docker run -it <IMAGEN> /bin/bash: inicia una sesión interactiva (ejecutando bash).
  • docker run -v /etc/tmp:/test-volume test-volume: crea un bind mount que asocia /etc/tmp del host con /test-volume del contenedor.
  • docker run -v /test-volume test-volume: crea un volumen anónimo (Docker lo hace automáticamente).
  • docker run -e "variable=valor" <nombre_imagen>: pasa variable de entorno a un contenedor.
  • docker run --network test-network <IMAGEN>: crea un contenedor que use la red test-network.
• docker ps: lista los contenedores en ejecución.
  • docker ps -a: lista los contenedores en ejecución y parados.
  • docker ps -q: lista solo las IDs de los contenedores en ejecución.
  • docker rm $(docker ps -q -a): borra todos los contenedores.
  • docker rm $(docker ps -q -a -f): borra todos los contenedores (incluso los que están en marcha).
  • docker ps -s: lista los contenedores y su tamaño, tanto virtual (total capas) como el de la capa de escritura (última capa).
• docker stop <CONTENEDOR>: detiene un contenedor
• docker kill <CONTENEDOR>: mata el proceso del contenedor.
• docker start <CONTENEDOR>: reinicia un contenedor que estaba parado.
• docker inspect <ID_CONTENEDOR> -f "{{ .NetworkSettings.IPAddress }}": muestra la IP del contenedor
• docker build . -t <NOMBRE>: crea una imagen llamada NOMBRE a partir de un Dockerfile del mismo directorio.
• docker save <MI_IMAGEN> -o <MI_IMAGEN.tar>: exporta una imagen a un fichero .tar.
• docker history <IMAGEN>: información de las capas que componen una imagen.
• docker exec <CONTENEDOR> <COMANDO>: ejecuta un proceso nuevo en un contenedor en marcha.
• docker inspect --format "{{json .Mounts}}" <id-contenedor>: ver los volúmenes de un contenedor.
• docker volume create <NOMBRE_VOLUMEN>: crea un volumen
• docker volume ls: lista los volúmenes
• docker inspect <NOMBRE_VOLUMEN>: obtiene los datos del volumen.
• docker volume prune: borra los volúmenes que no usan ningún contenedor.
• docker tag <IMAGEN> <IMAGEN:ETIQUETA>: etiqueta una imagen con ETIQUETA.
  • docker build . -t test-volume:v2: etiqueta una imagen a la hora de construirla.
  • docker rmi test-volume:v2: borra una etiqueta.
• docker push <USUARIO/IMAGEN>: sube la imagen a un repositorio.
• docker login <REPOSITORIO>: autenticarse contra un repositorio.
• docker buildx build --platform linux/arm/v7 -t demo:arm .: construye una imagen para cierta plataforma.
• docker system df: espacio usado en disco.
• docker system prune: elimina contenedores parados, imágenes sin dependencias y redes no utilizadas.
• docker compose --version: verifica la versión instalada de Docker Compose.
  • docker compose up: descarga la imagen (si no existe en local) y pone en marcha un contenedor a partir de ella
  • docker compose up -d: levanta los servicios en segundo plano (no se enlaza con ellos).
  • docker compose up <SERVICIO>: levanta solo el servicio SERVICIO.
  • docker compose -f docker-compose.development.yml up: especifica el fichero Docker Compose a utilizar.
  • docker compose -f docker-compose.yml -f docker-compose.prod.yml up.
  • docker compose -f docker-compose.yml -f docker-compose.prod.yml config: ver el fichero combinado resultante.
  • docker compose –profile front up: levanta los servicios con el perfil up y los que no tienen ningún perfil asociado.
  • docker compose build: construye imágenes con Docker Compose.
  • docker compose up --scale <SERVICIO=5>: escalar un servicio con 5 instancias.
• docker attach <CONTENEDOR>: permite enlazarnos a un contenedor.
• docker network ls: lista las redes de Docker que hay en la máquina.
• docker network create --driver bridge <nombre-red>: crea una red tipo bridge.
• docker network create --driver host <nombre-red>: crea una red tipo host (solo puede existir una).
• docker network rm <ID_RED>: elimina una red.
• docker network prune: elimina todas las redes que no estén en uso.
• docker logs <CONTENEDOR>: ver los logs de un contenedor (la salida por pantalla, stdin, o errores, stdout).
• docker cp <CONTENEDOR>:logs/log.txt .: copia del contenedor al host.
• docker cp foo.txt <CONTENEDOR>:/app/foo.txt: copia del host al contenedor
• docker commit <CONTENEDOR> <NUEVA_IMAGE>: crea una imagen a partir de un contenedor.

Listado de ficheros:

• /var/run/docker.sock: named pipe que utilizan cliente y servidor de Docker para comunicarse.
• Dockerfile: instrucciones para la creación de imágenes.
• docker-compose.yml: nombre habitual del fichero de configuración de Docker Compose.
• docker-compose.override.yml
• kubectl get secrets: muestra los secretos que hay en el clúster.
• kubectl create secret generic my_secret --from-literal password=PassW0rD: crea un secreto.
• kubectl logs <NOMBRE_POD>: muestra los logs de un pod (lo que su contenedor o contenedores muestren por stdout o stderr).
  • kubectl logs -l <etiqueta=valor>: muestra los logs de los pods que tengan la etiqueta indicada.

Dockerfile:

• FROM <IMAGEN>: indica la imagen base.
• ENV <variable>=<valor>: define variables de entorno del contenedor.
• ARG <ETIQUETA>: crea una variable en tiempo de construcción (no existirá en el contenedor).
• WORKDIR <DIRECTORIO>: se sitúa en DIRECTORIO en el contenedor (como hacer cd DIRECTORIO)
• COPY <ORIGEN_LOCAL> <DESTINO_CONTENEDOR>: copia ficheros de un directorio local a un directorio del contenedor.
• ADD <ORIGEN> <DESTINO_CONTENEDOR>: igual que COPY, pero admite como origen una URL o fichero comprimido.
• RUN <COMANDO>: comandos a ejecutar en el contenedor (durante la fase de construcción de la imagen).
• CMD <COMANDO>: comando a ejecutar al iniciar el contenedor.
  • CMD [<COMANDO1>, <COMANDO2>]: ejecuta en forma exec (COMANDO1 COMANDO2)
  • CMD <COMANDO1> <COMANDO2>: ejecuta en forma shell (/bin/sh -c 'COMANDO1 COMANDO2')
• ENTRYPOINT <COMANDO>: igual que CMD, pero recomendado si no queremos permitir que se modifique el proceso inicial de la imagen.
• EXPOSE <PUERTO>: indica el puerto que quiere exponer / abrir el contenedor. Es informativo.
• VOLUME <DIRECTORIO>: indica que DIRECTORIO será un volumen

Dockerfile multi-stage:

FROM golang:1.9-stretch
WORKDIR /go/src/hello_world
COPY hello_world.go .
RUN go build

FROM ubuntu:latest
WORKDIR /root/
COPY --from=0 /go/src/hello_world .
ENTRYPOINT ["/root/hello_world"]

Docker Compose:

version: '3'

services:
  sample-api:
    image: dockercampusmvp/nodejs-sample
    ports:
      - "9000:3000"
    environment:
      - PORT=80
    volumes:
      - /home/data:/var/lib/data
      - data-volume:/var/lib/data
      - data-volume2:/tmp
    profiles: ["backend"]

volumes:
  data-volume:
  
volumes:
  data-volume2:
     external: true

Multicontenedor:

version: '3'

services:
  client:
    image: dockercampusmvp/nodejs-sample
  server:
    image: dockercampusmvp/nodejs-sample

Construir imágenes con Docker Compose:

version: '3'

services:
  sample-api:
    image: dockercampusmvp/nodejs-sample:dev
    build:
      context: ./nodejs-sample
      dockerfile: Dockerfile

Kubernetes:

• minikube start: Minikube ejecuta Kubernetes como un contenedor de Docker.
• minikube stop: detine el contenedor de Minikube.
• minikube ip:muestra la IP de Minikube.
• minikube tunnel: crea un emulador de balanceador de carga (para probar los LoadBalancer).
• minikube addons enable ingress: instalar un controlador ingress en Minikube.
• minikube service -n ingress-nginx ingress-controller: muestra las URL de acceso al controlador de ingress ingress-controller del espacio de nombres ingress-nginx.
• kubectl version: información sobre la versión del cliente y servidor de Kubernetes instalados.
• kubectl get nodes: lista los nodoso de nuestro clúster.
• kubectl get pods: lista los pods.
  • kubectl get pods -o wide: lista los pods y muestra su IP y otros campos más.
• kubectl config get-contexts: lista los contextos de configuración que tengamos
• kubectl config current-context: muestra el contexto actual.
• kubectl config use-context <nombre-contexto>: cambia el contexto actual.
• kubectl --kubeconfig=<RUTA_FICHERO_CONFIG> <comando-de-kubcetl>: especifica el fichero de configuración de Kubernetes a usar.
• kubectl run my-first-deployment --image=dockercampusmvp/go-hello-world: crea y despliega un pod con 1 contenedor.
  • kubectl run bb --image busybox --rm --restart=Never -it -- /bin/sh: crea un pod llamado bb a partir de la imagen busybox, lo enlaza a nuestra terminal y ejecuta un shell. Se eliminará el pod cuando termine de ejecutarse. El pod no intentará reiniciar el contenedor.
• kubectl delete pod <nombre-del-pod>: elimina un pod.
• kubectl create deployment <NOMBRE_DEPLOYMENT> –image=<IMAGEN>: crea un deployment indicando que debe ejecutarse un contenedor a partir de cierta imagen. Se puede abreviar deployment con deploy.
• kubectl describe: detalle sobre los eventos de cierto objeto.
• kubectl expose pod <NOMBRE_POD> --name <NOMBRE_SERVICIO> --port <puerto>: crea un servicio pra exponer cierto pod por un determinado puerto.
• kubectl get services: muestra los servicios. También se puede acortar services con svc.
• kubectl get pods --show-labels: mostrar las etiquetas de los pods.
• kubectl get pod <nombre_pod> -o json: muestra la descripción del pod en formato JSON.
• kubectl get nodes: mostrar los nodos del clúster de kubernetes.
• kubectl taint node <nombre-node> <clave>=<valor>:<efecto>: “contamina” un nodo para que no se ejecute pods en él.
• kubectl get svc hello-svc -o yaml: obtiene la definición del servicio hello-svc en YAML.
• kubectl get pod hello -o yaml: obtiene la definición del objeto hello en YAML.
• kubectl create ns <nombre-namespace>: crea un espacio de nombres.
  • kubectl run nginx –image nginx -n mi-espacio-nombres: creamos el pod nginx en el espacio de nombres mi-espacio-nombres con un contenedor basado en la imagen nginx.
• kubectl delete ns <espacio-de-nombres>: elimina un espacio de nombres y todo recurso contenido en él.
• kubectl apply -f <NOMBRE_FICHERO>: aplica un fichero para la creación de algún objeto en Kubernetes.
• kubectl delete -f <fichero>: elimina los recursos definidos en el fichero (secciones kind y metadata.name).
• kubectl run hello --image dockercampusmvp/go-hello-world --dry-run=client -o yaml > pod.yaml: genera el YAML necesario para poder crear un pod de forma declarativa.
• kubectl explain <recurso>: muestra la especificación YAML de cualquier recurso.
  • kubectl explain pod.spec: muestra los campos que tiene spec en la especificación YAML de un pod.
• kubectl port-forward <nombre-pod> <puerto-local>:<puerto-pod>: establece un túnel entre nuestra máquina y el pod para poder acceder a él.
• kubectl delete rs <nombre-replicaset> .: elimina un ReplicaSet y los pods que gestiona.
• kubectl scale rs/<nombre-replicaset> --replicas=4: escala un ReplicaSet a 4 pods.
• kubectl scale deploy/<nombre-deployment> --replicas=<numero-replicas>: escala un deployment.
• kubectl rollout status: muestra el estado de un rolling update.
• kubectl rollout history: mostrar las versiones de deployment.
• kubectl rollout undo deploy/<NOMBRE_DEPLOY> --to-revision=1: vamos a la versión 1 de cierto deployment.
• kubectl annotate deploy/hello kubernetes.io/change-cause=“volvemos atrás porque eso no va”: indicamos una nota sobre la razón que provoca el rollling update.
• kubectl create cm staging --from-literal api_url=https://api_service --from-literal environment_name=staging: crea un Config Map
• kubectl create cm config_files --from-file web.config --from-file config.ini=config.staging.ini: crea un Config Map con fichero.
• kubectl get ing: ver recursos Ingress.
• kubectl describe ing <nombre-recurso-ingress>: información sobre un recurso Ingress.
• kubectl get svc -n ingress-nginx: ver el servicio que se expone al exterior del espacio de nombres ingress-nginx.
• kubectl get deploy: muestra los deployments.

Creación de un pod de forma declarativa:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: hello-declarative
  name: hello-declarative
spec:
  containers:
  - image: dockercampusmvp/go-hello-world
    name: hello

Creación de pod de forma declarativa indicando variables de entorno:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - image: imagenAUsar
    name: ctr
    env:
    - name: FooVar
      value: FooValue
    - name: BarVar
      value: BarValue

Creando un servicio de forma declarativa:

apiVersion: v1
kind: Service
metadata:
  name: hello-svc-declarative
spec:
  ports:
  - port: 8080
    targetPort: 80
    name: http
    protocol: TCP
  - port: 9000
    targetPort: 3000
    name: metrics
  selector:
    run: hello-declarative

ReplicaSet:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: dockercampusmvp/go-hello-world

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  strategy:
    type: rollingUpdate
    rollingUpdate:
      maxSurge: 1               # El valor por defecto es 25%
      maxUnavailable: 20%       # El valor por defecto es 25%
  replicas: 5
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: dockercampusmvp/go-hello-world

ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: staging
data:
  api_url: https://api_service
  environment_name: staging

Config Map que contiene un fichero:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config_staging
data:
  config.json: |
    {
        "environment": "staging",
        "api": {
            "server": "https://myapi"
        }
    }

Definición de volúmenes de pod:

spec:
  volumes:
  - name: shared
    emptyDir: {}

Montaje de un Config Map en un contenedor de un pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demovol
spec:
  selector:
    matchLabels:
      app: demovol
  template:
    metadata:
      labels:
        app: demovol
    spec:
      # Definimos el volumen
      volumes:
      - name: cfg
        configMap:
          name: config_staging  # Nombre del configmap
      containers:
      - name: demo
        image: dockercampusmvp/go-hello-world
        # Montamos el volumen
        volumeMounts:
        - name: cfg     # Nombre del volumen
          mountPath: /app/config

Secretos:

apiVersion: v1
data:
  password: VmVyeUNvbXBsZXhQYXNzdzByZA==
kind: Secret
metadata:
  name: mysecret

Comando inicial de un contenedor:

apiVersion: v1
kind: Pod
metadata:
  name: command
spec:
  containers:
  - name: main
    image: alpine
    command:
    - /bin/ls
  restartPolicy: Never

Servicio NodePort:

apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - name: http
    port: 8080
    targetPort: http
  type: NodePort

Servicio LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - name: http
    port: 8080
    targetPort: http
  type: LoadBalancer

Recurso Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app: demo-ingress
  name: demo-ingress
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /api
        pathType: ImplementationSpecific
        backend:
          service:
            name: apisvc
            port:
              number: 80
      - path: /hello
        pathType: ImplementationSpecific
        backend:
          service:
            name: hellosvc
            port:
              number: 80

Recurso Ingress con hosts virtuales:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-ingress
spec:
  rules:
  - host: dev.campusmvp.es
    http:
      paths:
      - pathType: Prefix
        path: "/api"
        backend:
          service:
            name: hellosvc
            port:
              name: http