k8s INITIAL

Creación de recursos con descriptores yaml (folder pods)

• pod.yaml
  • Creación simple de un pod (u otro recurso) con kubectl apply -f pod.yaml
  • Borramos con kubectl delete -f pod.yaml
• pod2.yaml
  • Descriptor con dos pods en el mismo yml.
• containers.yaml
  • Creación de un pod con dos contenedores. Demo de qué ocurre cuando colisionamos puertos. Instalación de comando en Alpine.
    • OJO a: no podremos acceder desde un container al otro, pero sí comparten la red (no podrán compartir el mismo puerto).
    • Los containers se ven como localhost
  • Probamos en Docker imagen de python (que tiene server http de ejecución simple)
    • Lo hacemos con docker run --net host -ti python:3.6-alpine sh. Esto ejecuta lo siguiente:
      • Utiliza la imagen indicada (la baja si no está en registry local)
      • La ejecuta en red del host
      • Abre terminal interactivo (ti)...
      • ... con la ejecución del comando sh (shell)
  • Ejecutamos en shell del container python ejecutándose python -m http.server 8081
  • Comprobamos correcta ejecución en localhost:8081
  • Añadimos al yml los command para que cree un file con echo diferente
  • Si ponemos el mismo puerto en ambos containers, da error. kubectl describe doscont no arroja explicación del error
  • kubectl logs doscont -c cont1 no da error.
  • kubectl logs doscont -c cont2 >> Address in use (si pusimos el mismo puerto)
  • Entramos en container con kubectl exec -ti doscont -c cont1 -- sh
    • El SO Alpine no trae curl. Lo instalamos con apk add -U curl para hacer las pruebas
  • Si, para rehacer los containers (corrigiendo puerto), ejecutamos de nuevo kubectl apply da error: un pod no puede actualizarse a sí mismo (hacen falta objetos de más alto nivel.)
  • Una vez la definición es correcta, desde dentro de cada container hay acceso a localhost:8082 y 8083 con curl localhost:[puerto]. Comparten host, cada container se ve a sí mismo y al otro.
  • Desde fuera, podemos hacer port-forward a los puertos del pod y ver la salida de cada container del pod.
• labels.yaml. Metadata para distinguir pods.
  • Distinguimos con kubectl get pods -l app=backend, p.ej.
  • Se añade el parámetro -l con la label y el valor
  • Siempre deberemos añadir por lo menos el de app para distinguir qué tiene cada pod.

ReplicaSets (folder replicaSet)

• replicaset.yaml
  • Crea 5 pods de 2 containers cada uno (con réplicas). OJO a:
    • Utilización de apiVersion y labels
    • Se crea con kubectl apply -f [nombreFile].yaml
    • Listamos con kubectl get replicaset o kubectl get rs
  • Si eliminamos a mano un pod con kubectl delete pod [nombrnieCompletoPod] --> ReplicaSet lo vuelve a crear
  • Corregimos las propiedades de replicaset.yaml y fijamos a 2 el numero de replicas.
    • Al ejecutar de nuevo kubectl apply -f replicaset.yaml, el replicaSet elimina los redundantes para dejar en funcionamiento los deseados (2).

Deployments (folder deployment)

• dep.yaml
  • Creación de Deployment. kubectl apply -f dep.yaml
  • Deployment visible con kubectl get deployment
    • Labels visibles con kubectl get deployment --show-labels
• dep2.yaml
  • Actualización de Deployment sobre dep.yaml
• IMPORTANTE:
  • Podemos ejecutar la actualización con kubectl apply -f dep2.yaml
  • Vemos ejecución de cambios en tiempo real con kubectl rollout status deployment [nombreDeploy]
  • La actualización se efectúa en base a los parámetros fijados (o default, si no) MaxUnavailable y MaxSearch
• dep3.yaml
  • Nuevo cambio para ver histórico de cambios en Deployments. Podemos verificar con kubectl rollout history deployment [nombreDeploy]
  • Volvemos a colocar versión de imagen de dep.yaml.
  • Ejecutamos con kubectl apply -f dep3.yaml
• dep4.yaml
  • Inclusión de parámetro revisionHistoryLimit a 1 para modificación del máximo de registros de histórico (por default es 10).
  • Eliminamos Deployment con kubectl apply -f dep4.yaml

Change Cause (dep5.yaml)

• Elemento que aparece al mostrar el history en Deployments con kubectl rollout history deployment [deploymentName]
• Contiene metadata para añadir CHANGE-CAUSE (kubernetes.io/change-cause)

Rollback de un despliegue (dep6.yaml)

• File incorrecto (que apunta a una imagen que no existe) para forzar un rollback.
• Ejecutamos kubectl apply -f dep6.yaml (forzado error)
• kubectl get pods muestra el error
• kubectl rollout history deployment deployment-test nos indica el historial (para hacer el rollback)

Services (folder service)

• Ver file svc.yaml
• Podemos añadir en el file distintos tipos de resources que se crearán de manera secuencial
• Mapeo de puertos y secuencia de entrada (file svc.yaml):
  • IP del service: Kubernetes garantizará la IP del service (que no cambia)
  • El port del service --> spec > ports > port
  • Ports de los pods adonde redirige el Service --> spec > ports > targetPort
• File svc2.yaml: Inclusión de tipo de cluster en el Service. Delete service anterior y aplicación del nuevo:
  • kubectl delete -f svc.yaml
  • kubectl apply -f svc2.yaml
• File nodeport.yaml: Utilización de nodeport en lugar de ClusterIP.
  • OJO que cambian los nombres del deployment y del service
  • Hacemos apply del NodePort con svc.yaml también desplegado.
  • get pods muestra los 6 pods (filtramos con kubectl get pods -l app=front o app=backend)
  • kubectl get svc arroja ambos servicios (my-service y my-service1, además de kubernetes)
    • Bajo PORT(S) vemos el port que expone NodePort (p.ej. 8080:31078/TCP)

Tratamiento de error: no se visualiza IP del service desde fuera

• OJO con las imagenes con base Alpine 3.3, tienen un bug declarado. Véase https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

• Descomponemos nodeport.yaml => nodeport_deployment.yaml y nodeport_service.yaml.