El autor seleccionó la Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.
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.
Nota: Para este tutorial se utiliza la versión 1.14 de Kubernetes, la versión oficial admitida en el momento de la publicación de este artículo. Para obtener información actualizada sobre la versión más reciente, consulte las notas de la versión actual en la documentación oficial de Kubernetes.
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 adiciones 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 contenedores.
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 contenedorizadas 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 Nginx para que garantice que se ejecuten correctamente las cargas de trabajo.
Un par de claves SSH en su máquina local Linux/macOS/BSD. Si no ha usado claves SSH antes, puede aprender a configurarlas siguiendo esta explicación para configurar claves SSH en su máquina local.
Tres servidores con Ubuntu 18.04 y 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 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 macOS o CentOS, siga la documentación de instalación oficial de Ansible.
Conocimiento de los libros de reproducción de Ansible. Para revisarlo, consulte Introducción a la administración de configuración 101: Escribir playbooks de Ansible.
Conocimientos sobre cómo iniciar un contenedor desde una imagen de Docker. Vea el “Paso 5: Ejecutar un contenedor de Docker” en Cómo instalar y usar Docker en Ubuntu 18.04 si necesita un repaso.
En esta sección, creará un directorio en su máquina local que funcionará como su espacio de trabajo. Configurará Ansible localmente para que pueda comunicarse con comandos y ejecutarlos en sus servidores remotos. Una vez realizado esto, creará un archivo de 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 IPS worker_1_ip
y worker_2_ip.
Cree un directorio llamado ~/kube-cluster
en el directorio de inicio de su máquina local y cd
en él:
- mkdir ~/kube-cluster
- cd ~/kube-cluster
Este directorio será su espacio de trabajo para el resto del tutorial y contendrá todos sus libros de reproducción 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 especificará información 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
Es posible que 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.
Tras haber configurado el inventario del servidor con grupos, instalaremos dependencias a nivel del sistema operativo y crearemos ajustes de configuración.
En esta sección, creará un usuario no root con privilegios sudo en todos los servidores para poder acceder a SSH manualmente como usuario no privilegiado. 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
Este es un desglose de lo que hace este libro de reproducción:
Crea el usuario no root ubuntu
.
Configura el archivo sudoers
para permitir que el usuario de ubuntu
ejecute comandos sudo
sin un mensaje 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 tras haber añadido el texto.
A continuación, ejecute el libro de reproducción ejecutando lo siguiente a nivel local:
- ansible-playbook -i hosts ~/kube-cluster/initial.yml
El comando se completará en dos o cinco minutos. Al finalizar, verá resultados similares al siguiente:
OutputPLAY [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.
A través de esta sección, instalará los paquetes a nivel del sistema operativo requeridos por Kubernetes con el administrador de paquetes de Ubuntu. Estos paquetes son l:
Docker: un 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 forma estándar.
kubelet
: servicio o programa del sistema que se ejecuta en todos los nodos y gestiona operaciones a nivel de nodo.
kubectl
: una 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 a 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.
Nota: Aunque en la documentación de Kubernetes se le recomienda usar la última versión estable de Kubernetes para su entorno, en este tutorial se utiliza una versión específica. Esto garantizará que pueda seguir los pasos correctamente, ya que Kubernetes cambia de forma rápida y es posible que la última versión no funcione con este tutorial.
Guarde y cierre el archivo cuando haya terminado.
A continuación, ejecute el playbook ejecutando lo siguiente a nivel local:
- ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml
Al finalizar, verá resultados similares al siguiente:
OutputPLAY [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.
En esta sección, configurará el nodo maestro. Sin embargo, antes de crear cualquier playbook, 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 ejecutan 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 puede 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 libro de reproducción 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 inicia el clúster ejecutando kubeadm init
. Pasar el argumento --pod-network-cidr=10.244.0.0/16
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.
La segunda tarea 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.
La tercera tarea 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.
La última tarea 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 haya terminado.
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 dentro del nodo maestro, ejecute lo siguiente:
- kubectl get nodes
Ahora verá lo siguiente:
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
El resultado indica que el nodo master
ha completado 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 puede añadir los trabajadores desde su máquina local.
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 denominado workers.yml
:
- nano ~/kube-cluster/workers.yml
Añada el siguiente texto al archivo para añadir 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 hash adecuados, la tarea lo establece 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 trabajo. Una vez que se complete esta tarea, los dos nodos de trabajo formarán parte del clúster.
Guarde y cierre el archivo cuando haya terminado.
Implemente el playbook ejecutando lo siguiente a nivel local:
- ansible-playbook -i hosts ~/kube-cluster/workers.yml
Al finalizar, verá resultados similares al siguiente:
OutputPLAY [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
Con la adición de los nodos de trabajo, ahora su clúster estará completamente configurado y activo, con los trabajadores listos para ejecutar el volumen de trabajo. Antes de programar aplicaciones, comprobaremos que el clúster funcione como se espera.
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
El resultado debe ser similar a lo siguiente:
OutputNAME 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 el valor de STATUS
es Ready
para todos sus nodos, 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, podría significar que los nodos de trabajo aún no han terminado su configuración. Espere de 5 a 10 minutos antes de volver a ejecutar kubectl get nodes
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 su clúster se ha verificado correctamente, programaremos una aplicación de Nginx de ejemplo en el clúster.
Ahora puede 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. La implementación anterior 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. Esto 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 los clientes, tanto internos como 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:
OutputNAME 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 Nginx se ejecuta. 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:
OutputNAME 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 haya funcionado:
- kubectl get deployments
OutputNo resources found.
A través de esta guía, configuró correctamente un clúster de Kubernetes en Ubuntu 18.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 Pod: describe en detalle el funcionaminento de los Pods 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: ofrece un panorama de las implementaciones. 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 forma de aprender sobre conceptos, encontrar guías específicas para tareas y buscar referencias de API para varios objetos.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!