Instalación de Kubernetes: mini guía dedicada a la instalación local de Kubernetes
Instalar y lanzar Kubernetes localmente es la mejor manera de ver y comprender todos los componentes de Kubernetes.
Instalar y lanzar Kubernetes localmente es la mejor manera de ver y comprender todos los componentes de Kubernetes y la forma en que se integran.
Kubernetes funciona en casi todas partes, con diferentes versiones de Linux y gracias a diferentes servicios en la nube (link articolo «Servizi Cloud Kubernetes»). La compatibilidad de esta herramienta con diferentes sistemas operativos utilizados en todo el mundo representa uno de los principales puntos fuertes de este instrumento.
Si echas un vistazo a la web oficial de Kubernetes encontrarás una página con los documentos que resumen el estado de las diversas combinaciones de distribución del sistema, así como una serie de guías introductorias que pueden ayudarte a realizar una correcta instalación local de Kubernetes.
Dicho esto, Kubernetes se puede distribuir de forma autónoma, la única necesidad es tener Linux con Docker instalado en su propia máquina o en una máquina virtual.
Antes de entrar en detalle, vamos a repasar la arquitectura de Kubernetes porque será útil durante la lectura:
- El maestro es el «plan de control» de Kubernetes y tiene una serie de componentes en cuanto a clústeres, incluyendo un servidor de API que es utilizado por las herramientas para interactuar con el propio clúster (por ejemplo kubectl).
- Cada nodo tiene un servicio kubelet que recibe órdenes del maestro y un runtime en el contenedor (incluido pero no limitado por un Docker) con el que interactúa para gestionar las peticiones del contenedor. Veámoslo en acción y describamos más a fondo los componentes mientras los configuramos.
Instalación local de Kubernetes
Como se ha descrito anteriormente en la guía introductoria, solo hay tres pasos para obtener un clúster autónomo que esté activo y funcionando. Veámoslos juntos.
Paso uno: ejecutar el etcd
docker run -d \
–net=host \
gcr.io/google_containers/etcd:2.0.9 \
/usr/local/bin/etcd \
–addr=127.0.0.1:4001 \
–bind-addr=0.0.0.0:4001 \
–data-dir=/var/etcd/data
Kubernets almacena de forma fiable el estado principal y la configuración a través de etcd. Los diferentes componentes maestros «vigilan» estos datos y actúan en consecuencia, por ejemplo, lanzando un nuevo contenedor para mantener un número deseado de copias.
Segundo paso: ejecutar el maestro
docker run -d \
–net=host \
-v /var/run/docker.sock:/var/run/docker.sock \
jetstack/hyperkube:v0.20.1 \
/hyperkube kubelet \
–api_servers=http://localhost:8080 \
–v=2 \
–address=0.0.0.0 \
–enable_server \
–hostname_override=127.0.0.1 \
–config=/etc/kubernetes/manifests
Este paso ejecuta un contenedor kubelet, que en este despliegue local ejecuta a su vez los componentes en clúster que forman el «plano de control» principal de Kubernetes.
- API del servidor: proporciona la API RESTful de Kubernetes para gestionar la configuración del clúster, con el apoyo del almacén de datos etcd.
- Programador: coloca los pods en los nodos basándose en reglas (por ejemplo, etiquetas). En esta etapa, el programador es simple, pero, como la mayoría de los componentes de Kubernetes, es configurable.
- Controller Manager: gestiona todas las funciones a nivel de clúster, incluyendo la creación/actualización de puntos finales, la detección, gestión y monitorización de nodos y la gestión de pods.
Tercer paso: ejecutar el proxy de servicio
docker run -d \
–net=host \
–privileged \
jetstack/hyperkube:v0.20.1 \
/hyperkube proxy \
–master=http://127.0.0.1:8080 \
–v=2
El proxy ( kube-proxy ) se ejecuta en cada nodo y proporciona un proxy de red simple y capacidades de equilibrio de carga. Este proxy permite exponer los servicios con una dirección de red y un nombre estables.
En este punto deberíamos tener un cluster Kubernetes ejecutable localmente. Para asegurarnos de que todo está bien, podemos utilizar Docker ps para comprobar las instancias de contenedor en ejecución; debería tener el aspecto que se ve en la siguiente imagen (se han omitido varias columnas por razones de brevedad):
IMAGEN | COMANDO |
jetstack/hyperkube:v0.20.1 | /hyperkube proxy |
jetstack/hyperkube:v0.20.1 | /hyperkube scheduler |
jetstack/hyperkube:v0.20.1 | /hyperkube apiserver |
jetstack/hyperkube:v0.20.1 | /hyperkube controller |
gcr.io/google_containers/pause:0.8.0 | /pause |
jetstack/hyperkube:v0.20.1 | /hyperkube kubelet |
gcr.io/google_containers/etcd:2.0.9 | /usr/local/bin/etcd |
alt tag = Instalación de Kubernetes
Para interactuar con el clúster necesitamos utilizar la herramienta CLI kubectl. Se puede descargar pre-construida directamente desde Google (nota 0.20.1 es la última versión en el momento de escribir).
wget https://storage.googleapis.com/kubernetes-release/release/v0.20.1/bin/linux/amd64/kubectl
chmod u+x kubetctl
sudo mv kubectl /usr/local/bin/
La forma más rápida de iniciar un contenedor en el clúster es utilizar el comando kubectl run. Así, por ejemplo, para iniciar un contenedor Nginx, puedes utilizar el comando y hacer referencia al nombre de la imagen del contenedor.
kubectl run web –image=nginx
Aunque esto es conveniente y adecuado para la experimentación, los recursos como los pods se crean generalmente utilizando artefactos de configuración que pueden tener ventajas por el hecho de que pueden ser versionados con GIT, facilitando así, por ejemplo, los rollbacks.
Si se usa YAML (o JSON), se declara un pod y su estado deseado; a continuación, el trabajo de Kubernetes es garantizar que este pod siempre exista de acuerdo con esta especificación hasta que se elimine.
Hay aquí un ejemplo sencillo de configuración de un pod para ese pod nginx (archivo nginx-pod.yml).
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: web
spec:
containers:
– name: nginx
image: nginx
Esto ejecuta la misma imagen de contenedor (nginx) que la anterior, pero en este caso la configuración de recursos específica, algunos metadatos adicionales, por ejemplo, una etiqueta (par clave/valor) que asigna a este pod una etiqueta del tipo «app» de «web».
kubectl create -f nginx-pod.yml
Kubernetes, en segundo plano, instruirá a un nodo para que extraiga la imagen del contenedor iniciando el mismo contenedor a su vez.
En este punto volverá a utilizar kubectl unos instantes después y debería poder ver el pod de nginx en funcionamiento.
$ kubectl get pods
POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED
web1 172.17.0.1 nginx nginx 127.0.0.1/127.0.0.1 app=web Running About a minute web1
Como se ha solicitado, un contenedor Nginx se está ejecutando en un pod (web1-qtlc1 en este caso) y también se le ha asignado una dirección IP. En Kubernetes, a cada pod se le asigna una dirección IP de una red interna y esto significa que los pods pueden comunicarse entre sí, sin embargo, en este caso hemos desplegado Kubernetes con Docker usando la red del host (-net=host) y estas direcciones IP serán accesibles localmente.
Comments