Despliegue de un clúster Kubernetes

ro:Implementarea unui cluster Kubernetes ru:Развертывание кластера Kubernetes pl:Wdrażanie klastra Kubernetes ja:Kubernetesクラスタのデプロイ zh:部署一个Kubernetes集群 de:Bereitstellen eines Kubernetes-Clusters nl:Een Kubernetes cluster implementeren pt:Implantação de um aglomerado Kubernetes fr:Deployer un cluster Kubernetes
Este artículo ha sido traducido por un software de traducción automática. Usted puede ver el origen artículo aquí.

en:Deploying a Kubernetes cluster it:Configurare un cluster Kubernetes fr:Deployer un cluster Kubernetes

¿Qué es Kubernetes?

Kubernetes es una plataforma de código abierto para gestionar cargas de trabajo y servicios en contenedores. Soporta la escritura de la configuración declarativa pero también la automatización. Kubernetes es un ecosistema grande y de rápido crecimiento.

Este procedimiento le permitirá desplegar rápida y fácilmente un cluster de tres nodos Kubernetes (k8s) Este procedimiento le permitirá desplegar rápida y fácilmente un cluster de tres nodos a partir de tres instancias de CentOS 7 desplegadas dentro de la misma red en una zona de avanzada.

Una de estas tres instancias será nuestro nodo maestro y las otras dos serán nuestros nodos trabajadores. Resumiendo de forma sencilla, el nodo maestro es el nodo desde el que gestionamos el cluster de Kubernetes (orquestador de contenedores) desde su API y los nodos trabajadores son los nodos en los que se ejecutarán los pods o contenedores (Docker en nuestro caso).

Asumiremos que tus 3 instancias de CentOS 7 ya están desplegadas y que tienes acceso ssh a ellas para ejecutar los comandos que siguen.

Esta es la configuración que tenemos en nuestro ejemplo y que se utilizará como ejemplo a lo largo de este procedimiento:

Nodo maestro: "k8s-master" / 10.1.1.16
Primer nodo trabajador: "k8s-worker01" / 10.1.1.169
Segundo nodo trabajador: "k8s-worker02" / 10.1.1.87

Tutorial de preparación del sistema e instalación de Kubernetes

Las siguientes acciones deben realizarse en todas las instancias (maestro y trabajadores) como root (o con los derechos sudo necesarios).

Comience por rellenar el archivo /etc/hosts en cada una de sus instancias para que puedan resolver su respectivo nombre de host (normalmente ya es el caso en una red de zona avanzada donde el enrutador virtual es un resolvedor de DNS).

En nuestro ejemplo esto da el siguiente archivo /etc/hosts en nuestras tres instancias (adáptalo con el nombre y la ip de tus instancias):

cat /etc/hosts
127.0.0.1   localhost
::1         localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02

Habilite el módulo bridge y las reglas iptables para él con los siguientes tres comandos:

modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf

Añade el repositorio YUM Docker :

cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF

Añade el repositorio YUM Kubernetes :

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

Instalar Docker :

yum install -y docker-ce

A continuación, instale los paquetes de Kubernetes necesarios:

yum install -y kubeadm kubelet kubectl

Editar el archivo de configuración del kubelet systemd (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) para añadir la siguiente línea en la sección "[Service]":

Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"

tal que :

cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

Recargue la configuración, habilite y luego inicie los servicios Docker y Kubelet a través de los siguientes tres comandos:

systemctl daemon-reload systemctl enable docker kubelet systemctl start docker kubelet </syntaxhighlight>

Desactivar el swap del sistema (kubelet no soporta la memoria swap, obtendrá un error durante las comprobaciones previas al vuelo al inicializar su clúster a través de kubeadms si no lo desactiva):

swapoff -a

Por favor, recuerde también comentar/eliminar la línea de intercambio en el archivo /etc/fstab de cada una de sus instancias como :

#/dev/mapper/vg01-swap  swap            swap    defaults                0       0

Inicialización del clúster Kubernetes

Las siguientes acciones sólo deben realizarse en la instancia maestra del nodo

Inicie la inicialización de su clúster Kubernetes a través del siguiente comando, teniendo cuidado de modificar el valor del parámetro "--apiserver-advertise-address=" por la dirección ip de su instancia maestra.

kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16

Nota: No modifique la ip de red "10.244.0.0/16" indicada en el parámetro "--pod-network-cidr=" porque este parámetro nos permite indicar que vamos a utilizar el plugin CNI Flannel para gestionar la parte de red de nuestros pods.

Este es el aspecto que debería tener el retorno de este comando cuando el clúster se inicializa con éxito:

[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c

Realizamos las operaciones solicitadas para finalizar la inicialización de nuestro cluster:

Creamos un directorio y un archivo de configuración en el directorio de nuestro usuario (root en nuestro caso):

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Desplegamos nuestra red pod Flannel para nuestro cluster:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created

nota: mantendremos el último comando proporcionado por el retorno del comando de inicialización lateral ("kubeadm join...") para ejecutarlo en nuestras instancias de trabajadores más tarde para unirlas a nuestro cluster.

Ahora podemos hacer las primeras comprobaciones de nuestro cluster desde nuestra instancia maestra:

Escriba el comando "kubectl get nodes" para comprobar los nodos actualmente presentes en su clúster:

[root@k8s-master ~]# kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
k8s-master.cs437cloud.internal   Ready    master   41m   v1.12.2

Nota: actualmente sólo está su nodo maestro, lo cual es normal ya que aún no hemos añadido los otros nodos al clúster.

Escriba el comando "kubectl get pods --all-namespaces" para comprobar los pods/contenedores actualmente presentes en su clúster:

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
kube-system   coredns-576cbf47c7-fwxj9                                 1/1     Running   0          41m
kube-system   coredns-576cbf47c7-t86s9                                 1/1     Running   0          41m
kube-system   etcd-k8s-master.cs437cloud.internal                      1/1     Running   0          41m
kube-system   kube-apiserver-k8s-master.cs437cloud.internal            1/1     Running   0          41m
kube-system   kube-controller-manager-k8s-master.cs437cloud.internal   1/1     Running   0          41m
kube-system   kube-flannel-ds-amd64-wcm7v                              1/1     Running   0          84s
kube-system   kube-proxy-h94bs                                         1/1     Running   0          41m
kube-system   kube-scheduler-k8s-master.cs437cloud.internal            1/1     Running   0          40m

Nota: Sólo hay pods correspondientes a los componentes de Kubernetes necesarios para nuestro nodo maestro (kube-apiserver, etcd, kube-scheduler, etc).

Podemos comprobar el estado de estos componentes con el siguiente comando:

[root@k8s-master ~]# kubectl get cs
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}

Añadir nodos trabajadores al clúster

Acciones a realizar sólo en las instancias/nodos trabajadores

En cada una de sus instancias de trabajadores (no lo haga en su instancia maestra), ejecute el comando "kubeadm join ..." proporcionado al final de la inicialización del clúster anterior:

[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
        [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
        [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

Comprobación del estado del clúster

Acciones a realizar desde la instancia/nodo maestro

Compruebe que sus nodos de trabajo se han añadido a su clúster volviendo a ejecutar el comando "kubectl get nodes":

[root@k8s-master ~]# kubectl get nodes
NAME                               STATUS   ROLES    AGE    VERSION
k8s-master.cs437cloud.internal     Ready    master   46m    v1.12.2
k8s-worker01.cs437cloud.internal   Ready    <none>   103s   v1.12.2
k8s-worker02.cs437cloud.internal   Ready    <none>   48s    v1.12.2

Nota: Podemos ver nuestros dos nodos trabajadores (k8s-worker01 y k8s-worker02), por lo que se han añadido a nuestro clúster.

Ahora vamos a ejecutar de nuevo el comando "kubectl get pods --all-namespaces":

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
kube-system   coredns-576cbf47c7-fwxj9                                 1/1     Running   0          46m
kube-system   coredns-576cbf47c7-t86s9                                 1/1     Running   0          46m
kube-system   etcd-k8s-master.cs437cloud.internal                      1/1     Running   0          46m
kube-system   kube-apiserver-k8s-master.cs437cloud.internal            1/1     Running   0          46m
kube-system   kube-controller-manager-k8s-master.cs437cloud.internal   1/1     Running   0          46m
kube-system   kube-flannel-ds-amd64-724nl                              1/1     Running   0          2m6s
kube-system   kube-flannel-ds-amd64-wcm7v                              1/1     Running   0          6m31s
kube-system   kube-flannel-ds-amd64-z7mwg                              1/1     Running   3          70s
kube-system   kube-proxy-8r7wg                                         1/1     Running   0          2m6s
kube-system   kube-proxy-h94bs                                         1/1     Running   0          46m
kube-system   kube-proxy-m2f5r                                         1/1     Running   0          70s
kube-system   kube-scheduler-k8s-master.cs437cloud.internal            1/1     Running   0          46m

Nota: Puedes ver que hay tantos pods/contenedores "kube-flannel" y "kube-proxy" como nodos tenemos en nuestro cluster.

Despliegue de un primer módulo

Desplegaremos nuestro primer vaina en nuestro clúster Kubernetes.

Para simplificar, elegimos desplegar un pod (sin réplicas) llamado "nginx" y utilizando la imagen "nginx":

[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created

Si lo comprobamos, éste aparece bien a la vuelta del comando que lista los pods de nuestro cluster:

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
default       nginx-55bd7c9fd-5bghl                                    1/1     Running   0          104s
kube-system   coredns-576cbf47c7-fwxj9                                 1/1     Running   0          57m
kube-system   coredns-576cbf47c7-t86s9                                 1/1     Running   0          57m
kube-system   etcd-k8s-master.cs437cloud.internal                      1/1     Running   0          57m
kube-system   kube-apiserver-k8s-master.cs437cloud.internal            1/1     Running   0          57m
kube-system   kube-controller-manager-k8s-master.cs437cloud.internal   1/1     Running   0          57m
kube-system   kube-flannel-ds-amd64-724nl                              1/1     Running   0          13m
kube-system   kube-flannel-ds-amd64-wcm7v                              1/1     Running   0          17m
kube-system   kube-flannel-ds-amd64-z7mwg                              1/1     Running   3          12m
kube-system   kube-proxy-8r7wg                                         1/1     Running   0          13m
kube-system   kube-proxy-h94bs                                         1/1     Running   0          57m
kube-system   kube-proxy-m2f5r                                         1/1     Running   0          12m
kube-system   kube-scheduler-k8s-master.cs437cloud.internal            1/1     Running   0          57m

Aparece al principio de la lista en un espacio de nombres diferente de "kube-system", ya que no es un componente específico para el funcionamiento de Kubernetes.

También es posible evitar que se muestren los pods específicos del espacio de nombres de kube-system ejecutando este mismo comando sin el parámetro "--all-namespace":

[root@k8s-master ~]# kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
nginx-55bd7c9fd-vs4fq     1/1     Running   0          3d2h

Para mostrar las etiquetas :

[root@k8s-master ~]# kubectl get pods --show-labels
NAME                      READY   STATUS    RESTARTS   AGE    LABELS
nginx-55bd7c9fd-ckltn     1/1     Running   0          8m2s   app=nginx,pod-template-hash=55bd7c9fd

También podemos comprobar nuestros despliegues con el siguiente comando:

[root@k8s-master ~]# kubectl get deployments
NAME    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx   1         1         1            1           93m

Así que tenemos un pod de nginx desplegado e iniciado pero todavía no es accesible desde el exterior. Para hacerlo accesible externamente, necesitamos exponer el puerto de nuestro pod creando el servicio (de tipo NodePort) mediante el siguiente comando:

[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created

Así se crea nuestro servicio:

[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        147m
nginx        NodePort    10.108.251.178   <none>        80:30566/TCP   20s

Nota: Escucha en el puerto 80/tcp y estará disponible/expuesto desde el exterior en el puerto 30566/tcp

Podemos obtener la ip de nuestro pod y el nombre del nodo en el que se está ejecutando actualmente a través del siguiente comando:

[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME                    READY   STATUS    RESTARTS   AGE    IP           NODE                               NOMINATED NODE
nginx-55bd7c9fd-vs4fq   1/1     Running   0          174m   10.244.2.2   k8s-worker02.cs437cloud.internal   <none>

Aquí nuestro pod nginx tiene la ip 10.244.2.2 y se ejecuta en nuestro nodo k8s-worker02.

También puedes simplemente ejecutar un comando o abrir un shell en nuestro pod nginx a través del siguiente comando (muy similar al comando docker):

[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#

Todo lo que tiene que hacer es crear su regla de equilibrio de carga en su red Ikoula One Cloud para acceder / hacer público su servidor web (nginx pod):

- Conéctese al Nube Ikoula Uno

- ir a "Red" en el menú vertical de la izquierda

- haga clic en la red en la que ha desplegado sus instancias de Kubernetes, luego en "Ver direcciones IP" y en su ip de origen NAT y vaya a la pestaña "Configuración

- haga clic en "Load Balancing" y cree su regla especificando un nombre, el puerto público "80" en nuestro caso, el puerto privado "30566" en nuestro caso (ver arriba), eligiendo un algoritmo LB (por ejemplo, round-robin) como :

- marque todas sus instancias de trabajo:

Compruebe sus instancias de trabajo de kubernetes

Pruebe el acceso a su servidor web / nginx pod desde su navegador (a través de la ip pública de su red en la que creó la regla LB):

Acceso a su servidor web

El hecho de que se pueda acceder a su pod nginx desde cualquiera de sus nodos es posible gracias al componente "kube-proxy" que se encarga de dirigir las conexiones al nodo o nodos en los que se está ejecutando (en caso de réplicas).

Así que acabas de desplegar un clúster Kubernetes básico de 3 nodos con un maestro y dos trabajadores.

Ir más allá

Puedes ir más allá desplegando el tablero de Kubernetes o creando volúmenes persistentes para tus pods, aumentando el número de tus nodos trabajadores, o incluso asignando de forma redundante el rol de maestro para una alta disponibilidad o dedicando nodos a ciertos componentes como Etcd por ejemplo.

Aquí hay algunos enlaces útiles:

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/