Ediciones ENI Editorial | líder en informática
Gestionar componentes internos de Kubernetes
Objetivos del capítulo y requisitos previos
Los capítulos anteriores han cubierto los diferentes tipos de objetos que se pueden usar en Kubernetes, desde el despliegue hasta el volumen persistente.
Este capítulo se dedicará al estudio de los elementos del sistema de un clúster de Kubernetes, incluido el espacio de nombres kube-system.
Espacio de nombres kube-system
1. Pods presentes en el espacio de nombres kube-system
La clasificación de los elementos en Kubernetes se realiza mediante espacios de nombres (namespaces). En el caso de los elementos de sistema del clúster, estos se alojan en el espacio de nombres kube-system.
Recupere la lista de pods del espacio de nombres kube-system:
kubectl -n kube-system get pods A continuación, se muestra el contenido del espacio de nombres de un clúster Minikube:
NAME READY STATUS RESTARTS AGE
coredns-64897985d-d8mnm 1/1 Running 0 6d6h
etcd-minikube 1/1 Running 0 6d6h
kindnet-mktfs 1/1 Running 0 6d6h ...Configuración de los servidores maestros
1. Principio de lanzamiento de los pods de sistema
La pieza etcd almacena toda la información del clúster. De hecho, Kubernetes no puede gestionar directamente su lanzamiento.
En el caso de los servicios de sistema, los pods correspondientes se lanzarán mediante un archivo de manifest. Estos archivos están presentes en las máquinas del clúster, en el directorio /etc/kubernetes/manifests.
2. Contenido del directorio /etc/kubernetes/manifests
Para ver el contenido de este directorio, ejecute en Minikube el siguiente comando:
$ minikube ssh Una vez conectado, recupere el contenido del directorio /etc/kubernetes/manifests con el comando ls:
$ cd /etc/kubernetes/manifests
$ ls -l A continuación, se muestra un extracto del comando que muestra el contenido del directorio:
total 16
-rw------- 1 root root 2309 Dec 22 20:32 etcd.yaml
-rw------- 1 root root 4071 Dec 22 20:32 kube-apiserver.yaml
-rw------- 1 root root 3390 Dec 22 20:32 kube-controller-manager.yaml
-rw------- 1 root root 1436 Dec 22 20:32 kube-scheduler.yaml 3. Contenido de los archivos
Estos archivos se corresponden con la definición de cinco pods.
Compruebe el contenido del archivo etcd.yaml:
$ sudo cat etcd.yaml A continuación, se muestra un extracto del archivo:
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod:...Monitoring de los contenedores del clúster con Glances
1. Origen de la necesidad
Se ha abordado el funcionamiento interno de un clúster y, en particular, las diferentes piezas implementadas (Deployment, StatefulSet, ReplicaSet, Pod) y el mecanismo que permite actualizarlas.
No se ha cubierto un último tipo de objeto: los DaemonSets (acceso directo ds). Permite controlar despliegues en los nodos del clúster como, por ejemplo, la adición de un agente de monitorización.
2. Consulta de los DaemonSets
En el caso de Minikube, solo existe un único objeto de este tipo: kube-proxy (en el espacio de nombres kube-system).
Para consultarlo, ejecute el siguiente comando:
$ kubectl get daemonset -n kube-system El comando debería mostrar el siguiente resultado:
NAME DESIRED CURRENT READY ... NODE SELECTOR AGE
kube-proxy 1 1 1 <none> 43d 3. Presentación de Glances
Por naturaleza, un clúster de Kubernetes (especialmente el de desarrollo), es muy activo. Como resultado, los motores de contenedores subyacentes tendrán una gran actividad.
La herramienta Glances (desarrollada por Nicolas Hennion) responde a una necesidad simple: inspeccionar lo que sucede en una máquina. Funciona de dos maneras diferentes:
-
en línea de comandos,
-
a través de una interfaz web.
En el caso de la interfaz web, el comando glances se lanzará con la opción -w.
Para más detalles, visite el siguiente sitio web: https://github.com/nicolargo/glances
4. Definición de DaemonSet
a. Estructura de la declaración
De la misma manera que sucede con un despliegue, el DaemonSet tendrá la forma de una declaración en formato YAML con los siguientes campos:
-
Los campos apiVersion (apps/v1) y kind (DaemonSet).
-
El registro namespace con los siguientes campos:
-
name: nombre del recurso (glaces).
-
namespace: espacio de nombres donde desplegar el pod (kube-system).
-
El registro spec --> template con los siguientes campos:
-
La estructura metadata, con las etiquetas que hay que posicionar.
-
La estructura...