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 😊

sudo kubeadm init –pod-network-cidr=172.16.0.0/12
Este comando es el que finalmente va a realizar el Bootstrap de nuestro cluster (master). Lo lanzaremos y esperaremos unos segundos. Si todo lo anteriormente mencionado en el post de prerrequisitos lo hemos hecho bien, nos debería mostrar este mensaje al final del proceso:
kubernetes control

Prestemos especial atención a mensajes como estos:

Kubernetes: Bootstrap de Cluster con Kubeadm

Y también en este, que nos indica por ejemplo que no podremos desplegar pods en master por defecto:

kubernetes mark

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

kubernetes addon

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:

wget https://docs.projectcalico.org/manifests/calico.yaml

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í:

kubernetes ip value

Una vez hecho esto, procederemos a desplegar nuestro network policy:

#Deploy yaml file for your pod network.
kubectl apply -f calico.yaml
 

Autenticación

Una vez tenemos el Bootstrap de master, es buen momento ya para obtener nuestro fichero kubeconfig con el que seguir funcionando

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
En este momento, ya podremos utilizar el comando kubectl desde el propio nodo master (copiando el fichero a nuestro HOST, también)

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:

kubectl get pods –all-namespaces
 
kubernetes namespace

Y por supuesto, podremos ver que su estado es el correcto:

sudo systemctl status kubelet.service
 
kubernetes master

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 vistazo
0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Power Apps Portals limitar acceso
Leer más

Powerapps Portals: Limitar el acceso a usuarios conocidos

¿Conoces los beneficios que te ofrece #PowerApps Portals? En esta segunda parte, Pablo Gómez Cruañes comparte cómo crear sitios web externos, paso a paso, limitando el acceso a usuarios conocidos y permitiéndoles disponer de los datos con una experiencia de usuario única. ¡A configurar!
Arquitectura Power BI Premium
Leer más

Arquitecturas Power BI Premium

Repasamos las posibles arquitecturas que puede tomar un proyecto de BI, partiendo de un escenario de Power BI Premium y en el que principalmente el dato viene de orígenes ya estructurados, analizando las principales ventajas e inconvenientes de cada uno, para poder elegir siempre el mejor camino.