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.