Una vez tenemos ya preparado nuestros nodos, ya podemos continuar con la instalación de nuestro cluster. En este caso vamos a por la parte del Bootstrap de nuestro nodo master.
En este post utilizaremos kubeadm para realizar las siguientes tareas:
- Checking pre-instalación
- Crear el Certificate Authority utilizado para el cifrado de comunicaciones interno de nuestros cluster
- Crear los ficheros kubeconfig
- Generar los manifest files de los static pod
- yaml
- Kube-apiserver.yaml
- kube-controller-manager.yaml
- kube-scheduler.yaml
- Levantar el control plane
- Taints de master
- Para que solo se agenden pods de administración en el nodo master
- Generar el tooken de Bootstrap
- Arrancar los pods estáticos:
- DNS
- Kube-proxy
No te asustes, porque todo eso lo hace kubeadm por nosotros 😊
NOTA: Para más información, ver kubeadm init
Red
Uno de los puntos importantes a tener claros a la hora de desplegar nuestro cluster va a ser decidir sobre qué red vamos a querer que sean desplegados nuestros PODS. Mi recomendación es que utilices una red diferente para esto a la que estas utilizando actualmente para montar tu nodo (en nuestro caso recuerda que nuestros nodos van sobre 192.168.100.x/24).
Para este ejemplo, vamos a configurar el CIDR para que trabaje contra la red 172.16.0.0/12
Init
Llegó el momento de levantar nuestro cluster 😊
Prestemos especial atención a mensajes como estos:
Y también en este, que nos indica por ejemplo que no podremos desplegar pods en master por defecto:
Y por último, uno de los mensajes más importantes, el que nos va a indicar cómo añadir nodos a nuestro nuevo cluster
NOTA: Salva el output relativo a kubeadm join, porque lo vas a necesitar más adelante
Configurar Nuestra Red
Como he introducido anteriormente, existen numerosos network policy disponibles en el ecosistema kubernetes. Al final casi va a gustos y cómo de cómodo te sientas utilizándolos. En mi caso personalmente he trabajado tanto con WeaveNet como con calico, pero me decanto más por Calico y por eso lo vamos a utilizar en este post 😊
NOTA: Para más información ver Instalar un network policy
Descargar calico
Calico es un despliegue yaml, por lo que desplegarlo será tan sencillo como descargarlo como yaml, editar lo que queramos dentro del fichero y desplegarlo con kubectl -f apply
Descarga de cálico:
Configurar Nuestro Network Policy
Ahora vamos a configurar Calico, que por defecto viene configurado contra la red 192.168.0.0/16, para que utilice la red que hemos comentado anteriormente (y sobre la que ya hemos iniciado nuestro cluster).
Para ello buscaremos dentro del fichero calico.yaml descargado anteriormente por el gat “CALICO_IPV4POOL_CIDR” y le asignaremos el valor de red donde queramos que se vayan presentando nuestros pods al levantarse, que quedará así:
Una vez hecho esto, procederemos a desplegar nuestro network policy:
Autenticación
Una vez tenemos el Bootstrap de master, es buen momento ya para obtener nuestro fichero kubeconfig con el que seguir funcionando
Verificar el Cluster
Una vez tenemos ya el fichero ~.kube/config en el directorio del usuario de trabajo, podremos utilizar kubectl con normalidad, pudiendo ahora ya ver el estado de nuestro cluster, que te recuerdo que ahora mismo está formado únicamente por nuestro nodo master, sobre el que además no podremos desplegar pods que no sean de sistema:
De esta forma, deberías ver lo siguiente:
Y por supuesto, podremos ver que su estado es el correcto:
En este post hemos desplegado nuestro controlplane (master). En un siguiente post vamos a ver cómo añadirle nodos finalmente a nuestro cluster, para terminar de formarlo.
Curso Administración de Kubernetes: De 0 a 100
¿Quieres profundizar en tus conocimientos en Kubernetes? Después de esta formación, comprenderás los diversos componentes que lo conforman y sus interdependencias, gestionar cargas de trabajo en Kubernetes, configurar tu propio cluster Kubernetes con buenas prácticas... ¡y mucho más!
Voy a Echar un vistazoEnrique Catalá
Soy Technical Leader en Verne TECH, MVP de Microsoft y Microsoft Certified Trainer (MCT). Estoy focalizado en motores relacionales de SQL Server y me encanta resolver problemas de rendimiento y escalabilidad en sistemas OLTP. He liderado más de 100 proyectos, no sólo en España, sino también en otros países como USA, Holanda, México, etc. siendo el principal arquitecto de soluciones como HealthCheck, QueryAnalytics y DatabaseObfuscator.