×
Tutorial de Kubernetes – Parte 3: Dashboard y Rollouts

Tutorial de Kubernetes – Parte 3: Dashboard y Rollouts


En nuestro último tutorial de Kubernetes nos habíamos encargado de realizar el setup de nuestros nodos y dejar todo funcional y listo para comenzar a realizar pruebas. En el tutorial de hoy, vamos a explorar Kubernetes y sus funcionalidades más a fondo, ingresar a su administración a través del navegador, crear y replicar pods, así como también realizar rollouts de éstos.

Anteriormente, en nuestro tutorial habíamos creado tres nodos, uno master y dos nodos esclavos y nos habíamos fijado con el comando kubectl get nodes que todos ellos se encontraran en estado «Ready» es decir listo para ser utilizado.

Obteniendo algo similar a lo siguiente:

~$ kubectl get nodes
NAME               STATUS    ROLES     AGE       VERSION
kubernetesmaster   Ready     master    28m       v1.11.3
kubernetesnode     Ready         21m       v1.11.3

Como vemos, en este caso contamos con un nodo master y otro hijo, con los cuales estaremos trabajando el día de hoy, es decir que el tercer nodo que habíamos creado no lo estaremos necesitando por ahora.

[wp-svg-icons icon=»cogs» wrap=»i»] Administrando Kubernetes desde el Dashboard

Primero que nada vamos a desplegar el Dashboard de Kubernetes, donde veremos de una forma más intuitiva y fácil nuestra infraestructura. Además también de poder ver claramente los pods que tenemos, nodos, los estados de estos, varias estadísticas y demás.

Pero para ello, necesitaremos antes que nada crear un par de pods con un ReplicationController, así los podremos ver luego desde la administración.

Para poder crear nuestros pods con Nginx, vamos a tener que en primera instancia crear un archivo de configuración que luego cargaremos. Dentro de este archivo ingresamos la siguiente configuración. Tengamos en cuenta además, que el archivo se puede llamar como desees, pero deberá finalizar con «.yaml».

Ejemplo: nginx_rc.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

 

Seguramente te estés preguntando ¿qué es un ReplicationController? ¿y qué exactamente significa el archivo que tenemos más arriba? Bien, veamos más detalladamente qué le hemos indicado en nuestro .yaml a Kubernetes.

¿Qué es un ReplicationController?

Un ReplicationController se asegura de que una cantidad específica de pods están corriendo siempre y se encuentren disponibles. Como vemos en nuestro .yaml, nosotros en la variable «replicas» le hemos indicado que deseábamos contar con 3.

Debemos tener en cuenta que se encargará siempre de contar con los pods que le hemos indicado en nuestro .yaml, por lo que si hay menos creará los faltantes y si hay más, se encargará de eliminarlos. Por otro lado, en caso de que ocurra un fallo, él mismo intentará recuperarlos o eliminarlos y crear nuevos, de ser necesario.

Otra cosa a tener en cuenta, es que aún cuando nuestra aplicación solamente necesite un pod, es recomendable utilizar un ReplicationController, ya que en caso de alguna falla, él se encargará de eliminar y crear uno nuevo a modo de que siempre lo tengamos disponible.

Creando un ReplicationController

Ahora sí podemos proceder a crearlos, para ello corremos el siguiente comando:

kubectl create -f nginx_rc.yaml

Deberíamos obtener por respuesta algo similar a lo siguiente:

replicationcontroller/nginx created

Podemos obtener el status con el siguiente comando:

Name:         nginx
Namespace:    default
Selector:     app=nginx
Labels:       app=nginx
Annotations:  
Replicas:     2 current / 2 desired
Pods Status:  2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  
    Mounts:       
  Volumes:        
Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  43m   replication-controller  Created pod: nginx-dpp8h
  Normal  SuccessfulCreate  43m   replication-controller  Created pod: nginx-5gf4b

Como vemos, nos indica que deseamos tener dos réplicas y actualmente tenemos dos. Además también podemos ver el estado de nuestros pods, etiquetas, puertos, etc.

Podemos ver el estado de nuestro ReplicationController (abreviado rc en los comandos de kubectl) con el siguiente comando:

kubectl get rc

Y deberíamos obtener algo como lo siguiente:

~$ kubectl get rc
NAME      DESIRED   CURRENT   READY     AGE
nginx     2         2         0         6s

Como podemos ver, tenemos nuestro ReplicationController con dos pods. Aquí se nos indica el nombre del replication controller, la cantidad de pods deseados, la cantidad que tenemos actualmente, el número que se encuentra listo y también el tiempo que llevan corriendo.

Si deseamos ver el estado de los pods, podemos correr el siguiente comando:

kubectl get pods

Y deberíamos obtener una salida como la siguiente:

sabrina@kubernetesmaster:~$ kubectl get pods
NAME          READY     STATUS    RESTARTS   AGE
nginx-5gf4b   1/1       Running   0          10m
nginx-dpp8h   1/1       Running   0          10m

Vemos aquí que ambos pods se encuentran listos y corriendo correctamente desde hace 10 minutos.

Desplegando el Dashboard

Ahora sí, vamos a desplegar el dashboard para poder ver esto mismo, pero en una interfaz gráfica y más bonito. Para ello utilizaremos el archivo .yaml de la página oficial de Kubernetes.

Por lo cual ejecutamos en nuestra terminal el siguiente comando:

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

Luego de ello, podemos ver si se ha desplegado correctamente el pod, listando todos y realizando un filtro por el nombre.

Es decir, ejecutando lo siguiente:

kubectl get pods --all-namespaces | grep dashboard

Allí deberíamos de obtener una salida similar a esta:

sabrina@kubernetesmaster:~$ kubectl get pods --all-namespaces | grep dashboard
kube-system   kubernetes-dashboard-767dc7d4d-2sh7t       1/1       Running   0          3h

En donde podemos ver que el pod se encuentra corriendo correctamente.

Una vez que tenemos desplegado el dashboard, vamos a crear un rol, para poder acceder a este. Hay que tener en cuenta que el despliegue se hace sin seguridad, es decir que no se nos va a solicitar contraseña o password, ya que es meramente de ejemplo y por supuesto esto no es recomendado para producción.

Para poder crear el rol creamos un archivo por ejemplo llamado dashboard.yaml:

nano -w dashboard.yaml

Y le colocamos las siguientes líneas dentro:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard
  labels:
    k8s-app: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system

Ahora lo aplicamos con el comando:

kubectl apply -f dashboard.yaml

Y por último para acceder al Dashboard ejecutamos:

kubectl proxy --address 0.0.0.0 --accept-hosts='^*$'

Y para poder acceder vía web, debemos ir a la siguiente dirección:

http://server_ip:puerto/api/v1/namespaces/kube-system/services/https:kubernetes-
dashboard:/proxy/#!/cluster

Al acceder se nos consultará la forma por la cual deseamos ingresar. Dado que nosotros no vamos a utilizar ningún tipo de autenticación ya que simplemente estamos realizando pruebas, vamos a presionar simplemente «skip«.

Luego de ello sí podemos acceder al dashboard y veremos algo como lo siguiente

Como vemos, en la interfaz gráfica podemos realizar varias acciones. Podemos ver los pods activos, los nodos, los namespaces, etc.

[wp-svg-icons icon=»contract» wrap=»i»] Realizando Rollouts en Kubernetes

Anteriormente hemos visto cómo podemos crear pods en Kubernetes, por lo que una de las funcionalidad más interesante que podemos encontrar es la de realizar un rollout cuando tenemos un inconveniente.

En el ejemplo que veremos y dado que anteriormente ya contábamos con dos pods con Nginx, vamos a pasar el servicio a una versión diferente para luego realizar el rollout y regresar a la que ya teníamos. Para ello, vamos a utilizar un Deployment.

Ejecutando un Rollout

Por lo que debemos crear un archivo con la siguiente configuración:

nano -w nginx-deployment.yaml

Y dentro colocamos:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Como vemos, le indicamos a Kubernetes que necesitamos tres pods con Nginx en la versión 1.7.9

Ahora agregamos los cambios:

kubectl create -f  nginx-deployment.yaml

Veamos si el deployment se ha creado correctamente:

kubectl get deployments

Y deberíamos obtener un output como el siguiente:

~$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            0           6s

¿Qué nos indica el comando?

  • NAME: nos indica el nombre del deployment
  • DESIRED: indica el número de réplicas deseadas para la aplicación, la cual hemos indicado al crear el deployment. Sería el estado que deseamos.
  • CURRENT: indica cuántas réplicas tenemos corriendo actualmente.
  • UP-TO-DATE: indica cuántas réplicas han sido actualizadas para que tengamos el estado deseado.
  • AVAILABLE: indica cuántas réplicas hay disponible para los usuarios.
  • AGE: indica hace cuanto las réplicas se encuentran corriendo.

Ahora, pensemos que deseamos que los pods corran la versión 1.9.1 de Nginx.

Entonces vamos a correr el siguiente comando:

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

Otra opción que tenemos es editar nuestro deployment con el siguiente comando:

kubectl edit deployment/nginx-deployment

Para poder ver si los cambios se están ejecutando corremos:

kubectl rollout status deployment/nginx-deployment

Y si vemos que todo va correcto, podemos volver obtener los pods, a ver cual es su estado.

¿Cómo podemos verificar si realmente la versión de Nginx fue actualizada?

Para poder verificar si realmente la versión de Nginx cambia en nuestros pods y se está actualizando correctamente, bastará simplemente con acceder a ellos y verificarlo nosotros mismo si así lo deseamos. A continuación veremos cómo realizarlo.

Primero obtengamos el Nombre con el siguiente comando:

kubectl get pods -o wide

Obtenemos una salida como la siguiente, en la cual podremos ver el nombre, es decir el identificador que necesitamos para poder acceder a ellos.

sabrina@kubernetesmaster:~$ kubectl get pods -o wide
NAME                                READY     STATUS    RESTARTS   AGE       IP              NODE             NOMINATED NODE
nginx-5gf4b                         1/1       Running   1          22h       192.168.88.6    kubernetesnode   
nginx-deployment-67594d6bf6-8bbg2   1/1       Running   0          1m        192.168.88.13   kubernetesnode   

Ahora procedemos a ingresar a uno de ellos. En este caso hemos elegido el pod con nombre «nginx-deployment-67594d6bf6-8bbg2». En tu caso será diferente, pero bastará con cambiar el nombre por el de tu pod en el comando.

kubectl exec -it nginx-deployment-67594d6bf6-8bbg2 -- /bin/bash

Veamos que version obtenemos y luego ejecutamos el update anterior y verificamos nuevamente:

root@nginx-deployment-67594d6bf6-8bbg2:/# nginx -v
nginx version: nginx/1.7.9
root@nginx-deployment-67594d6bf6-8bbg2:/# exit

No nos olvidemos de obtener los pods para volver a sacar el nombre, ya que al realizar un edit, el pod es eliminado y creado nuevamente, por lo cual el nombre cambiará.

~$ kubectl exec -it nginx-deployment-6fdbb596db-8zzv7 -- /bin/bash
root@nginx-deployment-6fdbb596db-8zzv7:/# nginx -v
nginx version: nginx/1.9.1
root@nginx-deployment-6fdbb596db-8zzv7:/# exit
exit

Como vemos, en un caso la versión de Nginx nos da la 1.7.9 y en el siguiente la 1.9.1, por lo cual el rollout está funcionando correctamente.

Sin dudas es algo muy interesante en Kubernetes el tener la posibilidad de realizar rollouts, pues como vemos, bastará con editar un archivo y él mismo se encargará de realizar los cambios en todos los pods, siempre teniendo en cuenta que tiene que haber pods disponibles para los usuario y a su vez encargándose de que todo funcione correctamente.

Conclusión

Podemos ver que Kubernetes es realmente una tecnología que nos trae consigo muchas herramientas útiles. Después de todo, sin lugar a dudas el hecho de poder tener siempre un número de réplicas sin tener que preocuparnos de que alguna de ellas deje de funcionar o bien de poder actualizar una configuración y que los cambios se repliquen es algo muy bueno y que nos ahorra bastante trabajo.

Además por supuesto, Kubernetes nos trae junto con esto muchas posibilidades más, siempre dependiendo de lo que desees, bastará con leer la documentación oficial y seguro encuentras cómo realizarlo, ya que en ese sentido es muy flexible.

Sigue la última parte de este mini curso: Tutorial de Kubernetes – Parte 4: Configuración de API.

 

 

¿Te gustó el artículo? Compártelo:

Escrito por Sabrina De Los Santos

Sabrina es una talentosa SysAdmin, encargada del Soporte Técnico via Chat y a través del sistema de Tickets. Además de saber sobre servidores Linux y cPanel, también es una apasionada por la programación de lenguajes C, C++, Bash, PHP - MySQL. Cursó su carrera de Analista Programador en Universidad ORT, y además la de Tecnólogo Informático en UDELAR. Aparte de esto tiene certificaciones en inglés por la Universidad de Cambridge. Conoce más sobre ella desde su Sitio web y LinkedIn.

    Recibe en tu correo electrónico toda la información sobre hosting, desarrollo web y dominios

    Términos y Condiciones de Servicio

    Infranetworking Internacional - Copyright 2002-2024
    Todos los derechos reservados.