Cómo crear un clúster de Kubernetes usando Kubeadm en Ubuntu 16.04

El autor seleccionó la Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

Introducción

Kubernetes es un sistema de orquestación de contenedores que administra contenedores a escala. Fue inicialmente desarrollado por Google en base a su experiencia en ejecución de contenedores en producción, es de código abierto y una comunidad mundial impulsa su desarrollo de manera activa.

Kubeadm automatiza la instalación y la configuración de componentes de Kubernetes como el servidor de API, Controller Manager y Kube DNS. Sin embargo, no crea usuarios ni maneja la instalación de dependencias al nivel del sistema operativo ni su configuración. Para estas tareas preliminares, se puede usar una herramienta de administración de configuración como Ansible o SaltStack. El uso de estas herramientas hace que la creación de clústeres adicionales o la recreación de los existentes sea mucho más simple y menos propensa a errores.

A través de esta guía, configurará un clúster de Kubernetes desde cero usando Ansible y Kubeadm, y luego implementará una aplicación de Nginx en contenedor.

Objetivos

Su clúster incluirá los siguientes recursos físicos:

• Un nodo maestro

  El nodo maestro (un nodo de Kubernetes hace referencia a un servidor) se encarga de administrar el estado del clúster. Ejecuta Etcd, que almacena datos de clústeres entre componentes que organizan cargas de trabajo en nodos de trabajo.

• Dos nodos de trabajo

  Los nodos de trabajo son los servidores en los que se ejecutarán sus cargas de trabajo (es decir, aplicaciones y servicios en contenedores). Un trabajador seguirá ejecutando su volumen de trabajo una vez que se le asigne, incluso si el maestro se desactiva cuando la programación se complete. La capacidad de un clúster puede aumentarse añadiendo trabajadores.

Tras completar esta guía, tendrá un clúster listo para ejecutar aplicaciones en contenedores siempre que los servidores del clúster cuenten con suficientes recursos de CPU y RAM para sus aplicaciones. Casi cualquier aplicación tradicional de Unix que incluya aplicaciones web, bases de datos, demonios y herramientas de línea de comandos pueden estar en contenedores y hechas para ejecutarse en el clúster. El propio clúster consumirá entre 300 y 500 MB de memoria, y un 10 % de CPU en cada nodo.

Una vez que se configure el clúster, implementará el servidor web de Nginx para que garantice que se ejecuten correctamente las cargas de trabajo.

Requisitos previos

• Un par de claves SSH en su máquina local con Linux, macOS o BSD. Si no usó claves SSH antes, puede aprender a configurarlas siguiendo esta explicación para configurar claves SSH en su máquina local.

• Tres servidores con Ubuntu 16.04 con al menos 2 GB de RAM y 2 vCPU cada uno. Debería poder usar SSH en cada servidor como usuario root con su par de claves SSH.

• Ansible instalado en su máquina local. Si usa Ubuntu 18.04 como SO, siga las indicaciones de la sección “Paso 1: Instalar Ansible”, en Cómo instalar y configurar Ansible en Ubuntu 18.04, para instalar Ansible. Para acceder a instrucciones de instalación en otras plataformas, como Mac OS X o CentOS, use la documentación de instalación oficial de Ansible.

• Conocimiento de los playbooks de Ansible. Para revisarlo, consulte Introducción a la administración de configuración: Escribir playbooks de Ansible.

• Conocimientos sobre cómo iniciar un contenedor desde una imagen de Docker. Vea e“Paso 5: Ejecutar un contenedor de Docker” en Cómo instalar y usar Docker en Ubuntu 16.04 si necesita un repaso.

Paso 1: Configurar el directorio de espacio de trabajo y el archivo de inventario de Ansible

En esta sección, creará un directorio en su máquina local que funcionará como su espacio de trabajo. También configurará Ansible a nivel local para que pueda comunicarse con sus servidores remotos y ejecutar comandos en ellos. Para hacer esto, creará un archivo hosts que contenga información de inventario, como las direcciones IP de sus servidores y los grupos a los que pertenece cada servidor.

De sus tres servidores, uno será el maestro con un IP que se mostrará como master_ip. Los otros dos servidores serán trabajadores y tendrán los IP worker_1_ip y worker_2_ip.

Cree un directorio llamado ~/kube-cluster en el directorio de inicio de su máquina local y use cd para posicionarse en él:

mkdir ~/kube-cluster
cd ~/kube-cluster

Este directorio será su espacio de trabajo para el resto del tutorial y contendrá todos sus playbooks de Ansible. También será el directorio dentro del que ejecutará todos los comandos locales.

Cree un archivo llamado ~/kube-cluster/hosts usando nano o su editor de texto favorito:

nano ~/kube-cluster/hosts

Añada el siguiente texto al archivo, que aportará información específica sobre la estructura lógica de su clúster:

[masters]
master ansible_host=master_ip ansible_user=root

[workers]
worker1 ansible_host=worker_1_ip ansible_user=root
worker2 ansible_host=worker_2_ip ansible_user=root

[all:vars]
ansible_python_interpreter=/usr/bin/python3

Posiblemente recuerde que los archivos de inventario de Ansible se utilizan para especificar datos del servidor, como direcciones IP, usuarios remotos y las agrupaciones de servidores que se abordarán como una sola unidad para ejecutar comandos. ~/kube-cluster/hosts será su archivo de inventario y usted agregó a este dos grupos de Ansible (maestros y trabajadores) para especificar la estructura lógica de su clúster.

En el grupo de maestros, existe una entrada de servidor llamada “master” que enumera el IP del nodo maestro (master_ip) y especifica que Ansible debería ejecutar comandos remotos como usuario root.

De modo similar, en el grupo de** trabajadores**, existen dos entradas para los servidores de trabajo worker_1_ip y worker_2_ip que también especifican el ansible_user como root.

La última línea del archivo indica a Ansible que utilice los intérpretes de Python 3 de servidores remotos para sus operaciones de administración.

Guarde y cierre el archivo después de agregar el texto.

Después de configurar el inventario del servidor con grupos, instalaremos dependencias a nivel del sistema operativo y crearemos ajustes de configuración.

Paso 2: Crear un usuario no root en todos los servidores remotos

En esta sección, creará un usuario no root con privilegios sudo en todos los servidores para poder acceder a SSH manualmente como usuario sin privilegios. Esto puede ser útil si, por ejemplo, desea ver la información del sistema con comandos como top/htop, ver una lista de contenedores en ejecución o cambiar archivos de configuración pertenecientes a root. Estas operaciones se realizan de forma rutinaria durante el mantenimiento de un clúster y el empleo de un usuario no root para esas tareas minimiza el riesgo de modificar o eliminar archivos importantes, o de realizar de forma no intencionada otras operaciones peligrosas.

Cree un archivo llamado ~/kube-cluster/initial.yml en el espacio de trabajo:

nano ~/kube-cluster/initial.yml

A continuación, añada el siguiente play al archivo para crear un usuario no root con privilegios sudo en todos los servidores. Un play en Ansible es una colección de pasos que se deben realizar y se orientan a servidores y grupos específicos. El siguiente play creará un usuario sudo no root:

- hosts: all
  become: yes
  tasks:
    - name: create the 'ubuntu' user
      user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash

    - name: allow 'ubuntu' to have passwordless sudo
      lineinfile:
        dest: /etc/sudoers
        line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'
        validate: 'visudo -cf %s'

    - name: set up authorized keys for the ubuntu user
      authorized_key: user=ubuntu key="{{item}}"
      with_file:
        - ~/.ssh/id_rsa.pub

A continuación, se ofrece un desglose de las funciones de este playbook:

• Crea el usuario no root ubuntu.

• Configura el archivo sudoers para permitir que el usuario ubuntu ejecute comandos sudo sin una solicitud de contraseña.

• Añade la clave pública de su máquina local (por lo general, ~/.ssh/id_rsa.pub) a la lista de claves autorizadas del usuario ubuntu remoto. Esto le permitirá usar SSH en cada servidor como usuario ubuntu.

Guarde y cierre el archivo después de agregar el texto.

A continuación, active el playbook ejecutando lo siguiente a nivel local:

ansible-playbook -i hosts ~/kube-cluster/initial.yml

El comando se aplicará por completo en un plazo de dos a cinco minutos. Al finalizar, verá resultados similares al siguiente:

Output
PLAY [all] ****

TASK [Gathering Facts] ****
ok: [master]
ok: [worker1]
ok: [worker2]

TASK [create the 'ubuntu' user] ****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [allow 'ubuntu' user to have passwordless sudo] ****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [set up authorized keys for the ubuntu user] ****
changed: [worker1] => (item=ssh-rsa AAAAB3...
changed: [worker2] => (item=ssh-rsa AAAAB3...
changed: [master] => (item=ssh-rsa AAAAB3...

PLAY RECAP ****
master                     : ok=5    changed=4    unreachable=0    failed=0   
worker1                    : ok=5    changed=4    unreachable=0    failed=0   
worker2                    : ok=5    changed=4    unreachable=0    failed=0   

Ahora que la configuración preliminar está completa, puede instalar dependencias específicas de Kubernetes.

Paso 3: Instalar las dependencias de Kubernetetes

En esta sección, instalará los paquetes a nivel del sistema operativo requeridos por Kubernetes con el administrador de paquetes de Ubuntu. Estos paquetes son los siguientes:

• Docker: tiempo de ejecución de contenedores. Es el componente que ejecuta sus contenedores. La compatibilidad con otros tiempos de ejecución como rkt se encuentra en etapa de desarrollo activo en Kubernetes.

• kubeadm: herramienta de CLI que instalará y configurará los distintos componentes de un clúster de manera estándar.

• kubelet: servicio o programa del sistema que se ejecuta en todos los nodos y gestiona operaciones a nivel de nodo.

• kubectl: herramienta de CLI que se utiliza para emitir comandos al clúster a través de su servidor de API.

Cree un archivo llamado ~/kube-cluster/kube-dependencies.yml en el espacio de trabajo:

nano ~/kube-cluster/kube-dependencies.yml

Añada los siguientes play al archivo para instalar estos paquetes en sus servidores:

- hosts: all
  become: yes
  tasks:
   - name: install Docker
     apt:
       name: docker.io
       state: present
       update_cache: true

   - name: install APT Transport HTTPS
     apt:
       name: apt-transport-https
       state: present

   - name: add Kubernetes apt-key
     apt_key:
       url: https://packages.cloud.google.com/apt/doc/apt-key.gpg
       state: present

   - name: add Kubernetes' APT repository
     apt_repository:
      repo: deb http://apt.kubernetes.io/ kubernetes-xenial main
      state: present
      filename: 'kubernetes'

   - name: install kubelet
     apt:
       name: kubelet=1.14.0-00
       state: present
       update_cache: true

   - name: install kubeadm
     apt:
       name: kubeadm=1.14.0-00
       state: present

- hosts: master
  become: yes
  tasks:
   - name: install kubectl
     apt:
       name: kubectl=1.14.0-00
       state: present
       force: yes

El primer play del playbook hace lo siguiente:

• Instala Docker, el tiempo de ejecución del contenedor.

• Instala apt-transport-https, que le permite añadir fuentes HTTPS externas a su lista de fuentes APT.

• Añade la clave apt del repositorio de APT de Kubernetes para la verificación de claves.

• Añade el repositorio de APT de Kubernetes a la lista de fuentes APT de sus servidores remotos.

• Instala kubelet y kubeadm.

El segundo play consta de una única tarea que instala kubectl en su nodo maestro.

Guarde y cierre el archivo cuando termine.

A continuación, active el playbook ejecutando lo siguiente a nivel local:

ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

Al finalizar, verá resultados similares al siguiente:

Output
PLAY [all] ****

TASK [Gathering Facts] ****
ok: [worker1]
ok: [worker2]
ok: [master]

TASK [install Docker] ****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [install APT Transport HTTPS] *****
ok: [master]
ok: [worker1]
changed: [worker2]

TASK [add Kubernetes apt-key] *****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [add Kubernetes' APT repository] *****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [install kubelet] *****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [install kubeadm] *****
changed: [master]
changed: [worker1]
changed: [worker2]

PLAY [master] *****

TASK [Gathering Facts] *****
ok: [master]

TASK [install kubectl] ******
ok: [master]

PLAY RECAP ****
master                     : ok=9    changed=5    unreachable=0    failed=0   
worker1                    : ok=7    changed=5    unreachable=0    failed=0  
worker2                    : ok=7    changed=5    unreachable=0    failed=0  

Tras la ejecución, Docker, kubeadm y kubelet se instalarán en todos los servidores remotos. kubectl no es un componente necesario y solo se necesita para ejecutar comandos de clúster. Si la instalación se realiza solo en el nodo maestro, tiene sentido en este contexto, ya que ejecutará comandos kubectl solo desde el maestro. Tenga en cuenta, sin embargo, que los comandos kubectl pueden ejecutarse desde cualquiera de los nodos de trabajo o desde cualquier máquina en donde se pueda instalar y configurar para apuntar a un clúster.

Con esto, quedarán instaladas todas las dependencias del sistema. Configuraremos el nodo maestro e iniciaremos el clúster.

Paso 4: Configurar el nodo maestro

A lo largo de esta sección, configurará el nodo maestro. Sin embargo, antes de crear playbooks, valdrá la pena abarcar algunos conceptos como Pods y complementos de red de Pods, ya que su clúster incluirá ambos.

Un pod es una unidad atómica que ejecuta uno o más contenedores. Estos contenedores comparten recursos como volúmenes de archivos e interfaces de red en común. Los pods son la unidad básica de programación de Kubernetes: se garantiza que todos los contenedores de un pod se ejecuten en el mismo nodo en el que esté programado el pod.

Cada pod tiene su propia dirección IP y un pod de un nodo debería poder acceder a un pod de otro usando el IP del pod. Los contenedores de un nodo único pueden comunicarse fácilmente a través de una interfaz local. Sin embargo, la comunicación entre los pods es más complicada y requiere un componente de red independiente que pueda dirigir de forma transparente el tráfico de un pod de un nodo a un pod de otro.

Los complementos de red de pods ofrecen esta funcionalidad. Para este clúster usará Flannel, una opción estable y apta.

Cree un playbook de Ansible llamado master.yml en su máquina local:

nano ~/kube-cluster/master.yml

Añada el siguiente play al archivo para iniciar el clúster e instalar Flannel:

- hosts: master
  become: yes
  tasks:
    - name: initialize the cluster
      shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
      args:
        chdir: $HOME
        creates: cluster_initialized.txt

    - name: create .kube directory
      become: yes
      become_user: ubuntu
      file:
        path: $HOME/.kube
        state: directory
        mode: 0755

    - name: copy admin.conf to user's kube config
      copy:
        src: /etc/kubernetes/admin.conf
        dest: /home/ubuntu/.kube/config
        remote_src: yes
        owner: ubuntu

    - name: install Pod network
      become: yes
      become_user: ubuntu
      shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt
      args:
        chdir: $HOME
        creates: pod_network_setup.txt

A continuación, se muestra un desglose de este play:

• La primera tarea inicializa el clúster ejecutando kubeadm init. Al pasar el argumento --pod-network-cidr=10.244.0.0/16 se especifica la subred privada desde la cual se asignarán los IP del pod. Flannel utiliza la subred anterior por defecto; le indicaremos a kubeadm que use la misma subred.

• Con la segunda tarea se crea un directorio .kube en /home/ubuntu. En este directorio se almacenarán datos de configuración, como los archivos de claves de administrador que se necesitan para establecer conexión con el clúster y la dirección API del clúster.

• Con la tercera tarea se copia el archivo /etc/kubernetes/admin.conf que se generó desde kubeadm init al directorio principal de su usuario no root. Esto le permitirá usar kubectl para acceder al clúster recién creado.

• Con la última tarea se ejecuta kubectl apply para instalar Flannel. kubectl apply -f descriptor.[yml|json]​​​​​​ es la sintaxis para indicar a ​​​kubectl​​​​​​ que cree los objetos descritos en ​​​​​​el archivo descriptor.[yml|json]​​​​​. El archivo kube-flannel.yml contiene las descripciones de los objetos necesarios para configurar Flannel en el clúster.

Guarde y cierre el archivo cuando termine.

Implemente el playbook a nivel local ejecutando lo siguiente:

ansible-playbook -i hosts ~/kube-cluster/master.yml

Al finalizar, verá un resultado similar al siguiente:

Output
PLAY [master] ****

TASK [Gathering Facts] ****
ok: [master]

TASK [initialize the cluster] ****
changed: [master]

TASK [create .kube directory] ****
changed: [master]

TASK [copy admin.conf to user's kube config] *****
changed: [master]

TASK [install Pod network] *****
changed: [master]

PLAY RECAP ****
master                     : ok=5    changed=4    unreachable=0    failed=0  

Para comprobar el estado del nodo maestro, aplique SSH en él con el siguiente comando:

ssh ubuntu@master_ip

Una vez que ingrese en el nodo maestro, ejecute lo siguiente:

kubectl get nodes

Ahora verá lo siguiente:

Output
NAME      STATUS    ROLES     AGE       VERSION
master    Ready     master    1d        v1.14.0

El resultado indica que el nodo master completó todas las tareas de inicialización y se encuentra en el estado Ready, a partir de lo cual puede comenzar a aceptar nodos de trabajo y ejecutar tareas enviadas al servidor de la API. Ahora, podrá añadir los trabajadores desde su máquina local.

Paso 5: Configurar los nodos del trabajador

La incorporación de trabajadores al clúster implica ejecutar un único comando en cada uno. Este comando incluye la información de clúster necesaria, como la dirección IP y el puerto del servidor de la API del maestro y un token seguro. Solo podrán incorporarse al clúster los nodos que puedan pasar el token seguro.

Regrese a su espacio de trabajo y cree un libro de reproducción llamado workers.yml:

nano ~/kube-cluster/workers.yml

Añada el siguiente texto al archivo para agregar los trabajadores al clúster:

- hosts: master
  become: yes
  gather_facts: false
  tasks:
    - name: get join command
      shell: kubeadm token create --print-join-command
      register: join_command_raw

    - name: set join command
      set_fact:
        join_command: "{{ join_command_raw.stdout_lines[0] }}"


- hosts: workers
  become: yes
  tasks:
    - name: join cluster
      shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
      args:
        chdir: $HOME
        creates: node_joined.txt

Esto es lo que hace el playbook:

• El primer play obtiene el comando de incorporación que debe ejecutarse en los nodos de trabajo. Este comando se mostrará en el siguiente formato: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>. Una vez que obtiene el comando real con el token y los valores de hash adecuados, la tarea lo fija como un hecho para que el siguiente play pueda acceder a esta información.

• El segundo play tiene una sola tarea que ejecuta el comando de incorporación en todos los nodos de trabajadores. Una vez que se complete esta tarea, los dos nodos de trabajo formarán parte del clúster.

Guarde y cierre el archivo cuando termine.

Implemente el playbook ejecutando lo siguiente a nivel local:

ansible-playbook -i hosts ~/kube-cluster/workers.yml

Al finalizar, verá resultados similares al siguiente:

Output
PLAY [master] ****

TASK [get join command] ****
changed: [master]

TASK [set join command] *****
ok: [master]

PLAY [workers] *****

TASK [Gathering Facts] *****
ok: [worker1]
ok: [worker2]

TASK [join cluster] *****
changed: [worker1]
changed: [worker2]

PLAY RECAP *****
master                     : ok=2    changed=1    unreachable=0    failed=0   
worker1                    : ok=2    changed=1    unreachable=0    failed=0  
worker2                    : ok=2    changed=1    unreachable=0    failed=0  

Una vez agregados los nodos de trabajo, su clúster estará completamente configurado y activo, con los trabajadores listos para ejecutar cargas de trabajo. Antes de programar aplicaciones, comprobaremos que el clúster funcione como se espera.

Paso 6: Verificar el clúster

Un clúster puede fallar durante la configuración debido a la indisponibilidad de un nodo o a que la conexión de red entre el maestro y el trabajador no funciona correctamente. Comprobaremos el clúster y nos aseguraremos de que los nodos funcionen correctamente.

Deberá comprobar el estado actual del clúster desde el nodo maestro para asegurarse de que los nodos estén listos. Si interrumpió la conexión con el nodo maestro, puede aplicar SSH en él de nuevo con el siguiente comando:

ssh ubuntu@master_ip

Luego, ejecute el siguiente comando para obtener el estado del clúster:

kubectl get nodes

Verá resultados similares al siguiente:

Output
NAME      STATUS    ROLES     AGE       VERSION
master    Ready     master    1d        v1.14.0
worker1   Ready     <none>    1d        v1.14.0
worker2   Ready     <none>    1d        v1.14.0

Si todos sus nodos tienen el valor Ready para STATUS, significa que son parte del clúster y están listos para ejecutar cargas de trabajo.

Sin embargo, si el valor de STATUS es NotReady para algunos de los nodos, es posible que aún no haya concluido la configuración de los nodos de trabajo. Espere entre 5 y 10 minutos antes de volver a ejecutar kubectl get node y verificar el nuevo resultado. Si el estado de algunos nodos todavía es NotReady, es posible que deba verificar y volver a ejecutar los comandos de los pasos anteriores.

Ahora que la verificación de su clúster se completó con éxito, programaremos una aplicación de Nginx de ejemplo en el clúster.

Paso 7: Ejecutar una aplicación en el clúster

Ahora podrá implementar cualquier aplicación en contenedor en su clúster. Para que sea sencillo, implementaremos Nginx usando implementaciones y servicios para ver la forma en que se puede implementar esta aplicación en el clúster. Puede usar también los comandos que se muestran a continuación para otras aplicaciones en contenedores siempre que cambie el nombre de imagen de Docker y cualquier indicador pertinente (por ejemplo, ports y volumes).

Dentro del nodo maestro, ejecute el siguiente comando para crear una implementación llamada nginx:

kubectl create deployment nginx --image=nginx

Una implementación es un tipo de objeto de Kubernetes que garantiza que siempre haya un número especificado de pods ejecutándose según una plantilla definida, incluso cuando el pod se bloquee durante la vida útil del clúster. Con la implementación anterior se creará un pod con un contenedor desde la imagen de Docker de Nginx del registro de Docker.

A continuación, ejecute el siguiente comando para crear un servicio llamado nginx que mostrará la aplicación públicamente. Lo hará a través de un NodePort, un esquema que permitirá el acceso al pod a través de un puerto arbitrario abierto en cada nodo del clúster:

kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort

Los servicios son otro tipo de objeto de Kubernetes que exponen los servicios internos del clúster a clientes internos y externos. También pueden usar solicitudes de equilibrio de carga para varios pods y son un componente integral de Kubernetes que interactúa de forma frecuente con otros.

Ejecute el siguiente comando:

kubectl get services

Con esto, se mostrará texto similar al siguiente:

Output
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP           PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>                443/TCP        1d
nginx        NodePort    10.109.228.209   <none>                80:nginx_port/TCP   40m

Desde la tercera línea del resultado anterior, puede recuperar el puerto en el que se ejecuta Nginx. Kubernetes asignará de forma aleatoria y automática un puerto superior al 30000, y garantizará que no esté ya vinculado a otro servicio.

Para probar que todo esté funcionando, visite http://worker_1_ip:nginx_port o http://worker_2_ip:nginx_port a través de un navegador en su máquina local. Visualizará la página de bienvenida conocida de Nginx.

Si desea eliminar la aplicación de Nginx, primero elimine el servicio nginx del nodo maestro:

kubectl delete service nginx

Ejecute lo siguiente para asegurarse de que el servicio se haya eliminado:

kubectl get services

Verá lo siguiente:

Output
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP           PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>                443/TCP        1d

Luego, elimine la implementación:

kubectl delete deployment nginx

Ejecute lo siguiente para confirmar que esto funcionó:

kubectl get deployments

Output
No resources found.

Conclusión

A través de esta guía, configuró correctamente un clúster de Kubernetes en Ubuntu 16.04 usando Kubeadm y Ansible para la automatización.

Si se pregunta qué hacer con el clúster ahora que está configurado, un buen paso sería lograr implementar con comodidad aplicaciones y servicios propios en el clúster. A continuación, se presenta una lista de enlaces con más información que puede orientarlo en el proceso:

• Implementar Docker en aplicaciones: contiene ejemplos en los que se detalla la forma de disponer aplicaciones en contenedores usando Docker.

• Descripción general de los pods: explicación detallada de su funcionaminento y su relación con otros objetos Kubernetes. Los pods se encuentran en todas partes en Kubernetes. Por ello, si los comprende su trabajo será más sencillo.

• Descripción general de las implementaciones: resumen sobre estas. Resulta útil comprender el funcionamiento de controladores como las implementaciones, ya que se utilizan con frecuencia en aplicaciones sin estado para escalar y reparar aplicaciones no saludables de forma automática.

• Descripción general de services: abarca services, otro objeto usado con frecuencia en los clústeres de Kubernetes. Comprender los tipos de servicios y las opciones que tienen es esencial para ejecutar aplicaciones con y sin estado.

Otros conceptos importantes que puede ver son los de Volume, Ingress y Secret, los cuales son útiles cuando se implementan aplicaciones de producción.

Kubernetes ofrece muchas funciones y características. La documentación oficial de Kubernetes es la mejor opción para aprender conceptos, encontrar guías específicas para tareas y buscar referencias de API para varios objetos.