Principios de los componentes principales y descubrimiento de servicios de Kubernetes

Principio de los componentes básicos

1. RC[controlador]

Controlador de replicación

​ Se utiliza para garantizar que la cantidad de réplicas de la aplicación del contenedor se mantenga siempre en la cantidad de réplicas definida por el usuario, es decir, si un contenedor sale de manera anormal, se creará automáticamente un nuevo Pod para reemplazarlo, y si no hay anormalmente muchos contenedores, se reciclará automáticamente.

En la nueva versión de Kubernetes, se recomienda usar ReplicaSet para reemplazar ReplicationController

2. RS [controlador]

conjunto de réplicas

​ No hay una diferencia esencial entre ReplicaSet y ReplicationController, pero el nombre es diferente y ReplicaSet admite una colección de selectores.

​

​ Aunque ReplicaSet se puede usar de forma independiente, generalmente se recomienda usar Deployment para administrar automáticamente ReplicaSet, de modo que no haya necesidad de preocuparse por la incompatibilidad con otros mecanismos (por ejemplo, ReplicaSet no admite la actualización continua pero Deployment sí lo hace)

3, Despliegue

La implementación proporciona un método de definición declarativa para Pod y ReplicaSet, que se usa para reemplazar el ReplicationController anterior para administrar las aplicaciones de manera conveniente.

Escenarios de aplicación típicos:

(1), defina Implementación para crear Pod y ReplicaSet

(2), actualización continua y aplicación de reversión

(3), expansión y capacidad de cable

(4), suspender y continuar el despliegue

La implementación no solo se puede actualizar de forma continua, sino que también se puede revertir.Si encuentra que el servicio no está disponible después de actualizar a V2, puede revertir a V1.

4, HPA

HPA (HorizontalPodAutoScale)

El ajuste de escala automático de pod horizontal solo se aplica a Deployment y ReplicaSet. En la versión V1, solo admite la expansión en función de la utilización de la CPU del pod. En la versión vlalpha, admite la expansión y la contracción en función de la memoria y las métricas definidas por el usuario.

5, conjunto completo de estado

StatefullSet es para resolver el problema de los servicios con estado (correspondientes a Deployments y ReplicaSets están diseñados para servicios sin estado), y sus escenarios de aplicación incluyen:

(1) Almacenamiento persistente estable, es decir, los mismos datos persistentes a los que aún se puede acceder después de reprogramar el Pod, según PVC

(2) Una marca de red estable, y su PodName y HostName permanecen sin cambios después de que se reprograme el Pod, según el Servicio Headless (es decir, el Servicio sin IP de clúster).

(3) Despliegue ordenado y expansión ordenada, es decir, los Pods son ordenados, y al momento de desplegar o expandir, se deben realizar en secuencia de acuerdo al orden definido (es decir, de 0 a N-1, todos los Pods anteriores deben ser Ambos están en los estados En ejecución y Listo), según los contenedores de inicio.

(4) Reducción ordenada, eliminación ordenada (es decir, de N-1 a 0)

6, conjunto de demonios

​ DaemonSet garantiza que todos (o algunos [nodos están contaminados (se puede imaginar como una etiqueta), si el pod no define la tolerancia a esta contaminación, entonces el programador no asignará el pod a este nodo])

Una réplica de un pod se ejecuta en un nodo. Cuando un nodo se une al clúster, también se le agrega un pod. Estos pods también se reciclan cuando se elimina un nodo del clúster. Eliminar un DaemonSet eliminará todos los Pods que creó, utilizando algunos usos típicos de DaemonSet:

(1) Ejecute el daemon de almacenamiento del clúster, por ejemplo, ejecute glustred y ceph en cada nodo

(2) Ejecute el daemon de recopilación de registros en cada nodo, por ejemplo: fluentd, logstash.

(3) Ejecute el Daemon de monitoreo en cada Nodo, por ejemplo: Prometheus Node Exporter

El trabajo es responsable de las tareas por lotes, es decir, las tareas que se ejecutan una sola vez, y garantiza que uno o más Pods de la tarea por lotes finalicen con éxito.

La gestión de Cron Job se basa en el trabajo de tiempo, a saber:

• ejecutar solo una vez en un momento dado
• ejecutarse periódicamente en un momento determinado

7、Volumen

Volúmenes de datos, que comparten datos utilizados por contenedores en un Pod.

8, Etiqueta

标签用于区分对象（比如Pod、Service），键/值对存在；每个对象可以有多个标签，通过标签关联对象。 

Cualquier objeto API en Kubernetes se identifica mediante una etiqueta. La esencia de una etiqueta es una serie de pares clave-valor clave/valor, donde el usuario especifica la clave y el valor.

Las etiquetas se pueden adjuntar a varios objetos de recursos, como nodo, pod, servicio, RC, etc. Un objeto de recurso puede definir cualquier cantidad de etiquetas, y la misma etiqueta también se puede agregar a cualquier cantidad de objetos de recursos.

La etiqueta es la base para el funcionamiento del controlador y el servicio de replicación, y los dos usan la etiqueta para asociar pods que se ejecutan en Node.

Podemos realizar la función de gestión de grupos de recursos multidimensionales vinculando una o más etiquetas diferentes al objeto de recurso especificado, para facilitar la asignación de recursos, la programación, la configuración y otras tareas de gestión flexibles y convenientes.
Algunas etiquetas de uso común son las siguientes:

Etiquetas de versión: "release": "stable", "release": "canary"...

Etiquetas de entorno: "entorno": "dev", "entorno": "qa", "entorno": "producción"

Etiquetas de esquema: "tier": "frontend", "tier": "backend", "tier": "middleware"

Etiqueta de partición: "partición": "clienteA", "partición": "clienteB"

Etiqueta de control de calidad: "seguimiento": "diario", "seguimiento": "semanal"

Label es equivalente a la etiqueta con la que estamos familiarizados. Definir una etiqueta para un objeto de recurso es equivalente a agregarle una etiqueta, y luego puede consultar y filtrar objetos de recurso con ciertas etiquetas a través del selector de etiquetas (selector de etiquetas). Kubernetes utiliza este Este método implementa un mecanismo de consulta de objetos simple y general similar a SQL.

Los escenarios de uso importantes del Selector de etiquetas en Kubernetes son los siguientes:
-> El proceso kube-Controller define el Selector de etiquetas en el objeto de recurso RC para filtrar la cantidad de copias de Pod que se monitorearán, a fin de realizar el proceso de control completamente automático que el número de copias siempre cumple con la configuración esperada;
-> El proceso kube-proxy selecciona el Pod correspondiente a través del Selector de etiquetas del Servicio y establece automáticamente la tabla de enrutamiento de reenvío de solicitudes de cada isla de Servicio correspondiente al Pod, realizando así el inteligente balanceo de carga del Servicio -> Al definir una Etiqueta específica para
algunos Nodos y usar la estrategia de programación de etiquetas de Nodeselector en el archivo de definición de Pod, el proceso kuber-scheduler puede realizar la función de "programación dirigida" de Pod;

descubrimiento de servicios

1, servicio

1.1, ¿Qué es el Servicio?

El servicio es un concepto abstracto. Asigna el puerto especificado a través de un formulario de IP virtual (VIP) y reenvía la solicitud enviada por el cliente proxy a uno de los conjuntos de pods de back-end (es decir, el punto final)

El servicio define la colección lógica del Pod y la estrategia para acceder a la colección, y es una abstracción de los servicios reales. El servicio proporciona un portal de acceso al servicio unificado, un proxy de servicio y un mecanismo de detección, y asocia varios pods con la misma etiqueta. Los usuarios no necesitan saber cómo se ejecutan los pods en segundo plano.
El problema de acceder al Servicio desde sistemas externos:
-> Primero, debe comprender las tres direcciones IP de Kubernetes -
Nodo IP: la dirección IP del nodo Nodo- Pod IP: la dirección IP del Pod- Cluster IP: el Dirección IP del Servicio
　
　

-> Primero, la IP del nodo es la dirección IP de la tarjeta de red física del nodo en el clúster de Kubernetes, y todos los servidores que pertenecen a esta red pueden comunicarse directamente a través de esta red. Esto también muestra que cuando un nodo fuera del clúster de Kubernetes accede a un nodo o servicio TCP/IP en el clúster de Kubernetes, debe comunicarse a través de la IP del nodo.

-> En segundo lugar, Pod IP es la dirección IP de cada Pod, que Docker Engine asigna de acuerdo con el segmento de dirección IP del puente docker0, generalmente una red virtual de capa 2.

Finalmente, la IP del clúster es una IP virtual, pero se parece más a una red de IP falsificada. Las razones son las siguientes:
-> La IP del clúster solo funciona en el objeto del servicio de Kubernetes, y Kubernetes administra y asigna direcciones P
-> Clúster No se puede hacer ping a la IP, no tiene un "objeto de red física" para responder
-> La IP del clúster solo se puede combinar con el Puerto de servicio para formar un puerto de comunicación específico, y una sola IP del clúster no tiene la base para la comunicación, y ellos pertenecen a un espacio cerrado como el clúster de Kubernetes.
-> En el clúster de Kubernetes, la comunicación entre la red IP del nodo, la red IP del módulo y la red IP del clúster adopta una regla de enrutamiento especial diseñada por el propio Kubernetes.

1.2, principio de servicio

2, tablas IP

El modo Iptables es el modo de proxy predeterminado de los Servicios. En el modo de proxy de iptables, kube-proxy no realiza una distribución de equilibrio de carga entre los VIP y los pods de back-end como un proxy inverso. Este trabajo es implementado por iptables trabajando en la cuarta capa. iptables y netfilter están estrechamente integrados y cooperan estrechamente, y ambos realizan el reenvío de paquetes en kernelspace.

En este modo, kube-proxy tiene principalmente los siguientes pasos para realizar el reenvío de paquetes:

• A través de la API del clúster del clúster de Kubernetes, obtenga el comando para crear, eliminar Servicios o Endpoint Pod.
• kube-proxy establece las reglas de iptables en el nodo. Cuando se reenvía una solicitud al ClusterIP de los Servicios, se capturará de inmediato y se redirigirá a un Pod de backend correspondiente a los Servicios.
• kube-proxy establecerá reglas de iptables para cada Pod correspondiente a los Servicios en el nodo, y el algoritmo predeterminado para seleccionar Pod es una estrategia aleatoria.

En el modo iptables, kube-proxy confía la estrategia de reenvío de tráfico y balanceo de carga a iptables/netfiter.Todas estas operaciones de reenvío se implementan en el espacio del núcleo, que es mucho más rápido que el espacio del usuario.

En iptables, kube-proxy solo desempeña la función de sincronizar la información de datos más reciente con la API de observación. La información de la regla de enrutamiento y el reenvío se colocan en iptables y netfiter en kernelspace. Sin embargo, este modo no es tan bueno como el modo de espacio de usuario. En el modo de espacio de usuario, kube-proxy realiza el equilibrio de carga. Si no se desea el pod de backend seleccionado, kube-proxy puede volver a intentarlo. En el modo iptables, es un Si el pod de backend a ser reenviado no responde y K8S no lo ha eliminado, es posible que se agote el tiempo de espera de la solicitud reenviada a este Pod. Debe usarse junto con la sonda K8S.

2.1, método de equilibrio de carga

Hay dos modos de equilibrio de carga tcp usando iptables en Linux: aleatorio y turno rotativo

The statistic module support two different modes:

random:(随机)
the rule is skipped based on a probability
nth:（轮询）
the rule is skipped based on a round robin algorithm

2.2 Método aleatorio

El siguiente es un ejemplo para ilustrar la implementación específica de los dos métodos LB de iptables:

Hay 3 servidores proporcionados en el sistema. A continuación, configuramos iptables para que el tráfico equilibre el acceso a estos 3 servidores.

# 随机：(Random balancing)
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode random --probability 0.33  -j DNAT --to-destination 10.0.0.2:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode random --probability 0.5 -j DNAT --to-destination 10.0.0.3:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017  -j DNAT --to-destination 10.0.0.4:1234

descripción de las reglas:

En la primera regla, especificar --probability 0.33 significa que la regla acertará con una probabilidad del 33%.

La segunda regla también acierta con una probabilidad del 33% porque en la regla se especifica --probability 0.5. Entonces la probabilidad de acertar es: 50% * (1 - 33%) = 0,33

En la tercera regla, no se especifica el parámetro --probability, lo que significa que cuando el partido alcanza la tercera regla, se debe acertar, y la probabilidad de alcanzar la tercera regla en este momento es: 1 - 0.33 -0.33 ≈ 0.33 .

De lo anterior se puede ver que la probabilidad de acertar las tres reglas es la misma. Además, si queremos modificar la tasa de acierto de las tres reglas, podemos ajustarla a través del parámetro --probability.

Suponiendo que hay n servidores, puede establecer n reglas para distribuir el tráfico por igual a n servidores, donde el valor del parámetro --probability se puede calcular mediante la siguiente fórmula:

其中 i 代表规则的序号（第一条规则的序号为1）

n 代表规则/server的总数

p 代表第 i 条规则中 --probability 的参数值

 p=1/(n−i+1)

Nota: Debido a que en iptables, las reglas se emparejan en orden, de arriba a abajo, por lo que al diseñar las reglas de iptables, las reglas deben ordenarse estrictamente. Por lo tanto, el orden de las tres reglas anteriores no se puede cambiar, de lo contrario, no se puede realizar la ecualización de LB.

2.3 Método de votación

Hay dos parámetros en el algoritmo de sondeo:

 n： 指每 n 个包

 p：指第 p 个包

En la regla, n y p representan: a partir del p-ésimo paquete, ejecutar la regla cada n paquetes.

Esto puede ser un bocado, solo mira las castañas:

Aún en el ejemplo anterior, hay 3 servidores y 3 servidores sondean y procesan paquetes de tráfico, la configuración de la regla es la siguiente:

#every：每n个包匹配一次规则
#packet：从第p个包开始
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination 10.0.0.2:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -m statistic --mode nth --every 2 --packet 0  -j DNAT --to-destination 10.0.0.3:1234
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.1 --dport 27017 -j DNAT --to-destination 10.0.0.4:1234

3, IPVS

3.1 ¿Qué es IPVS?

IPVS (IP Virtual Server) implementa el equilibrio de carga de la capa de transporte, comúnmente conocido como conmutación de LAN de capa 4, y es parte del kernel de Linux.

IPVS se ejecuta en el host y actúa como un equilibrador de carga frente al clúster de servidores real. IPVS puede dirigir solicitudes de servicios basados ​​en TCP y UDP a servidores reales y hacer que los servicios del servidor real aparezcan como servicios virtuales en una única dirección IP.

3.2, IPVS frente a IPTABLES

El modo IPVS se introdujo en Kubernetes v1.8 y entró en versión beta en v1.9. El modo IPTABLES se agregó en v1.1 y ha sido el modo de operación predeterminado desde v1.2. Tanto IPVS como IPTABLES se basan en netfilter. Las diferencias entre el modo IPVS y el modo IPTABLES son las siguientes:

• IPVS proporciona mejor escalabilidad y rendimiento para clústeres grandes.
• IPVS admite algoritmos de equilibrio de carga más complejos que iptables (menor carga, menos conexiones, localidad, ponderación, etc.).
• IPVS admite la verificación del estado del servidor y el reintento de conexión, etc.

Todos sabemos que iptables está diseñado para servicios de firewall en Linux, y para aquellos con menos reglas, no hay mucho impacto en el rendimiento. Pero para un clúster K8S, habrá miles de Servicios y, por supuesto, se reenviarán a Pods, cada uno de los cuales es una regla de iptables. Para el clúster, habrá una gran cantidad de reglas de iptables en cada nodo, lo cual es simplemente pesadilla.

De manera similar, IPVS puede resolver tales requisitos de reenvío de red a gran escala, pero IPVS usa tablas hash para almacenar reglas de reenvío de red, lo que es más ventajoso que iptables en este sentido, y funciona principalmente en el espacio del núcleo, lo que reduce la sobrecarga.

3.3, pasos de carga de IPVS

Hay varios pasos para configurar el reenvío de red para kube-proxy e IPVS:

• Mediante la visualización de la API del clúster del clúster de kubernetes, obtener nuevos, eliminar servicios o comandos de Endpoint Pod, se crea un nuevo servicio, kube-proxy devuelve la llamada a la interfaz de red y crea reglas de IPVS.
• Al mismo tiempo, kube-proxy sincronizará periódicamente las reglas de reenvío de los servicios y los pods de back-end para garantizar que se pueda actualizar y reparar el reenvío no válido.
• Cuando se reenvía una solicitud al clúster de back-end, el balanceador de carga de IPVS la reenvía directamente al pod de back-end.

3.4, algoritmo de carga IPVS

Hay varios algoritmos de equilibrio de carga compatibles con IPVS:

• rr: sondeo
• lc: número mínimo de conexiones
• dh: hash de dirección de destino
• sh: hash de dirección de origen
• sed: retraso mínimo esperado
• nq: sin cola de espera

point Pod, se crea un nuevo servicio, kube-proxy devuelve la llamada a la interfaz de red y crea reglas de IPVS.

• Al mismo tiempo, kube-proxy sincronizará periódicamente las reglas de reenvío de los servicios y los pods de back-end para garantizar que se pueda actualizar y reparar el reenvío no válido.
• Cuando se reenvía una solicitud al clúster de back-end, el balanceador de carga de IPVS la reenvía directamente al pod de back-end.