Introducción a k8s

1. Características de k8s

• Ligero: consume menos recursos
• Fuente abierta
• Escala elástica
• Equilibrio de carga: IPVS

Dos, diseño de arquitectura

El número de réplicas de clúster de alta disponibilidad es preferiblemente un número impar> = 3

2.1 Arquitectura Borg (predecesora de k8s)

2.2 arquitectura k8s

• etcd: se posiciona oficialmente como un servicio de almacenamiento de valor clave distribuido confiable , que puede almacenar algunos datos clave para todo el clúster distribuido y ayudar al funcionamiento normal del clúster distribuido. etcd es una base de datos de pares clave-valor que almacena toda la información importante (persistencia) del clúster k8s . Se recomienda utilizar la versión Etcd v3 en el clúster k8s, la versión v2 ha quedado obsoleta en k8s v1.11
• servidor api: una entrada unificada para todos los servicios de acceso
• ControllerManager: mantenga el número esperado de copias
• Programador: Responsable de introducir tareas, seleccionando los nodos apropiados para asignar tareas.
• kubelet: interactúa directamente con el motor del contenedor para realizar la gestión del ciclo de vida del contenedor
• kube-proxy: responsable de escribir reglas en IPTABLES, IPVS para lograr el acceso al mapeo de servicios
• coredns: puede crear un nombre de dominio y una resolución de correspondencia de IP para el SVC en el clúster
• panel de control: proporciona un sistema de acceso a la estructura B / S para el clúster k8s
• controlador de entrada: el funcionario solo puede implementar un proxy de cuatro capas, y la entrada puede implementar un proxy de siete capas
• federación: proporciona una función de gestión unificada que puede cruzar centros de clústeres con varios k8
• prometheus: proporciona la capacidad de supervisión del clúster k8s
• ELK: proporciona una plataforma unificada de análisis e intervención para los registros del clúster k8s

2.3 Clasificación de servicios

• Servicio con estado: DBMS
• Servicio sin estado: LVS APACHE

2.4 Controlador

2.4.1 ReplicationController & ReplicaSet & Deployment

ReplicationController se utiliza para garantizar que el número de réplicas de la aplicación de contenedor siempre permanezca en el número de réplicas definido por el usuario. Es decir, si un contenedor sale de manera anormal, se creará automáticamente un nuevo Pod para reemplazarlo; y si el contenedor sale de manera anormal, se reciclará automáticamente. En la nueva versión de Kubernetes, se recomienda usar ReplicaSet para reemplazar ReplicationController.

No hay una diferencia esencial entre ReplicaSet y ReplicationController, excepto que el nombre es diferente y ReplicaSet admite selectores colectivos.

Aunque ReplicaSet se puede usar de forma independiente, generalmente se recomienda usar Deployment para administrar ReplicaSet automáticamente. De esta manera, no hay necesidad de preocuparse por la incompatibilidad con otros mecanismos (por ejemplo, ReplicaSet no es compatible con la actualización continua, pero la implementación es compatible)

2.4.2 HPA （Ajuste de escala automático horizontal de pod）

El ajuste de escala automático horizontal del pod solo se aplica a la implementación y al ReplicaSet. En la versión v1, solo admite la expansión y la contracción según el uso de CPU del pod. En la versión vlalpha, admite la expansión y la contracción según la memoria y las métricas definidas por el usuario.

2.4.3 StatefulSet

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

• Almacenamiento persistente estable, es decir, se puede acceder a los mismos datos persistentes después de reprogramar el Pod. Basado en PVC
• Un símbolo de red estable, es decir, su nombre de pod y el nombre de host permanecen sin cambios después de reprogramar el pod. Implementación basada en Headless Service (es decir, servicio sin IP de clúster)
• Implementación ordenada, expansión ordenada, es decir, pods están en orden. Cuando se implementan o expanden, deben llevarse a cabo en secuencia según el orden definido (es decir, de 0 a N-1. Antes de que se ejecute el siguiente pod, todos los pods debe estar en ejecución y listo), según los contenedores de inicio
• Reducir ordenadamente, eliminar ordenadamente (es decir, de N-1 a 0)

2.4.4 DaemonSet

DaemonSet garantiza que todos (o algunos) nodos ejecuten una copia del Pod. Cuando un nodo se une al clúster, también le agregará un pod. Cuando se elimina un nodo del clúster, estos pods también se reciclarán. Eliminar DaemonSet eliminará todos los pods que creó

Algunos usos típicos de DaemonSet:

• Ejecute el demonio de almacenamiento en clúster, por ejemplo, ejecute glustered y ceph en cada nodo.
• Ejecute el demonio de recopilación de registros en cada nodo, como fluentd, logstash
• Ejecute el demonio de supervisión en cada nodo, como Prometheus NodeExporter

3. Modo de comunicación de red K8S

El modelo de red de Kubernetes asume que todos los pods están en un espacio de red plano que se puede conectar directamente. Este es un modelo de red listo para usar en GCE (Google Compute Engine) y Kubernetes asume que esta red ya existe. Al crear un clúster de Kubernetes en una nube privada, no puede asumir que esta red ya existe. Necesitamos implementar esta suposición de red por nosotros mismos, primero abrir el acceso mutuo entre contenedores Docker en diferentes nodos y luego ejecutar Kubernetes

Modo de comunicación:

• Entre varios contenedores en el mismo Pod: lo
• Comunicación entre pods: red superpuesta
• Comunicación entre Pod y Servicio: reglas Iptables de cada nodo

Solución de red: Kubernetes + Flannel

Flannel es un servicio de planificación de redes diseñado por el equipo de CoreOS para Kubernetes. En pocas palabras, su función es permitir que los contenedores Docker creados por diferentes hosts de nodo en el clúster tengan una dirección IP virtual única en todo el clúster. Y también puede establecer una red superpuesta (Overlay Network) entre estas direcciones IP, a través de esta red superpuesta, el paquete de datos se entrega intacto al contenedor de destino

La relación entre ETCD y Flannel:

• Gestión de almacenamiento Flannel puede asignar recursos de segmentos de direcciones IP
• Monitoree la dirección real de cada Pod en ETCD y establezca y mantenga una tabla de enrutamiento de nodo Pod en la memoria

Método de comunicación en red en diferentes situaciones.

• Comunicación interna del mismo pod: el mismo pod comparte el mismo espacio de nombres de red y la misma pila de protocolos de Linux
• Pod1 accede a Pod2:
  (1) Pod1 y Pod2 no están en el mismo host, y la dirección de Pod está en el mismo segmento de red que docker0, pero el segmento de red de docker0 y la tarjeta de red del host son dos segmentos de red IP completamente diferentes, y son diferentes de Node. La comunicación entre ellos solo se puede realizar a través de la tarjeta de red física del equipo host. Asocie la IP del Pod con la IP del Nodo donde se encuentra el Pod. A través de esta asociación, el Pod puede acceder entre sí
  (2) Pod1 y Pod2 están en el mismo host, y el puente docker0 reenvía la solicitud directamente a Pod2 sin pasar por franela
• Acceso de pod a la red de servicio: actualmente basado en consideraciones de rendimiento, todos son mantenidos y reenviados por iptables
• Acceso del pod a la red externa: el pod envía una solicitud a la red externa, busca la tabla de enrutamiento y reenvía el paquete de datos a la tarjeta de red del host. Una vez que la tarjeta de red del host completa el enrutamiento, iptables ejecuta Masquerade, cambia la IP de origen a la IP de la tarjeta de red del host, y luego el servidor externo envía una solicitud
• Pod de acceso desde Internet: Servicio