Resumen de Kubernetes
De la introducción al dominio ~
Si empiezas, no te rindas
El conocimiento es riqueza
La vida es corta
Estás listo ?
Uno, introducción a Kubernetes
Haga clic en el título a continuación, saltará automáticamente a ~
1. Descripción del componente
(1.1) Fuente de la abreviatura de K8s
(1.2) Características
(1.3) Arquitectura
(1.4) Diagrama de arquitectura etcd
(1.5) nodo
2. Concepto de pod
(2.1) Pod autónomo
(2.2) Pod gestionado por el controlador
(2.3) Servicio Descubrimiento
3. Método de comunicación de red
(3.1) Fuente abreviada de K8s
(3.2) Características
(3.3) Arquitectura
Dos, instalación e implementación de Kubernetes
Haga clic en el título a continuación, saltará automáticamente a ~
1. Preparación del entorno del clúster
(1) información de enrutamiento suave de koolshare
(2) información del nodo K8s
(3) información del nodo del almacén del puerto
2. Implementación de Koolshare
(1)
(2)
(3)
3. Implementación del nodo K8s
(1)
(2)
(3)
4. Desplegar el almacén del puerto
(1)
(2)
(3)
Uno, introducción a Kubernetes
1. Descripción del componente
(1.1) Fuente de abreviaturas de K8s
Kubernetes se conoce como K8, porque hay 8 letras entre "K" y "s";
(1.2) Características
Kubernetes Google 10 años de infraestructura en contenedores borg GO language Borg
caracteristicas:
Ligero: consume pocos recursos, equilibrio de carga de escalado elástico de
código abierto : IPVS
(1.3) Arquitectura
K8s (arquitectura C / S) utiliza el protocolo http;
Programador:
programador, responsable de introducir tareas, seleccionar los nodos apropiados para asignar tareas, escribir en el servidor api, servidor api en etcd y distribuir solicitudes a los nodos;
CrontrollerManager:
controlador, mantiene el número esperado de copias;
servidor api:
entrada unificada para todos los servicios;
kubectl:
herramienta de gestión de línea de comandos;
etcd: una
base de datos de pares clave-valor, que almacena toda la información importante (persistencia) del clúster de K8S. El funcionario lo posiciona como un servicio de almacenamiento de clave-valor distribuido confiable K / V, que puede almacenar algunos datos clave para todo el clúster distribuido para ayudar El funcionamiento normal del clúster distribuido;
# Se recomienda usar las versiones etcd v3 y v2 en el clúster de kubernetes; kubernetes v1.11 incluye la versión anterior que viene con etcd y no es compatible con la versión v3; la versión v2 escribirá los datos en la memoria; la versión v3 escribirá los datos en el volumen local para su persistencia Operación, el apagado no causará daños a los datos, restauración desde el disco local;
COREDNS:
puede crear una resolución de correspondencia IP de nombre de dominio para el SVC en el clúster;
TABLERO:
Proporciona un sistema de acceso a la estructura B / S para el clúster K8S;
CONTROLADOR DE INGRESS: Los
funcionarios solo pueden implementar un proxy de cuatro capas, e INGRESS puede implementar un proxy de siete capas;
FEDERACIÓN:
Proporciona una función de gestión unificada que puede cruzar centros de clúster con varios K8S;
PROMETHEUS:
Proporciona la capacidad de monitoreo del clúster K8S;
ELK:
proporciona una plataforma unificada de análisis e intervención para los registros del clúster K8S;
(1.4) diagrama de arquitectura etcd
#Utilizando el protocolo http, C / S;
balsa:
preservación de información de lectura y escritura: se escribirá en el almacenamiento del disco local para configuraciones persistentes;
WAL:
registro de escritura anticipada, copia de seguridad temporal o copia de seguridad completa del registro;
（1,5） nodo
kubelet:
hablará con crl (contenedor, entorno operativo, interfaz de interfaz);
interactuará directamente con el motor del contenedor para realizar la gestión del ciclo de vida del contenedor
proxy kube:
el acceso y el equilibrio de carga entre el puerto y el puerto deben utilizar el proxy kube. El objeto de operación predeterminado es el firewall, que implementa el mapeo de puertos. La nueva versión también es compatible con IPVS;
2. Concepto de vaina
(2.1) Cápsula autónoma
En el caso tradicional, cada contenedor existe de forma independiente, y cada contenedor tiene una dirección IP, volumen montado, etc., y está aislado por un espacio de nombres;
defina un pod, mientras se ejecute el Pod, el contenedor se iniciará ( Llamado pausa);
un Pod encapsulará muchos contenedores, compartirá la red de pausa, los volúmenes de almacenamiento (html, etc.), es decir, no hay una dirección IP independiente, solo la dirección IP del Pod o la dirección IP de pausa, usando localhost: puerto, el contenedor Pueden acceder entre sí; los
puertos no pueden entrar en conflicto, de lo contrario, se reiniciará indefinidamente;
(2.2) Pod gestionado por el controlador
ReplicationController (denominado RC): se
utiliza para garantizar que la cantidad de réplicas de la aplicación de contenedor se mantenga siempre en la cantidad de réplicas definida por el usuario, es decir, si un contenedor sale de forma anormal, se creará automáticamente un nuevo Pod para reemplazarlo, y si el contenedor anormalmente adicional también se recicla automáticamente ;
Se recomienda usar ReplicaSet en lugar de ReplicationControlle en la nueva versión de kubernetes
ReplicaSet (RS para abreviar) está diseñado para servicios sin estado:
no es esencialmente diferente de ReplicationController, excepto que el nombre es diferente;
y ReplicaSet admite selectores colectivos (etiquetaremos al crear Pod, como app-apache, etc.) Un montón de etiquetas, cuando queremos borrar el contenedor o hacer las facilidades correspondientes, que podemos hacer cuando app = apache ...)
La implementación está diseñada para servicios sin estado:
aunque ReplicaSet se puede usar de forma independiente, generalmente se recomienda usar Deployment para administrar ReplicaSet automáticamente, de modo que no haya que preocuparse por la incompatibilidad con otros mecanismos (por ejemplo, ReplicaSet no es compatible con la actualización continua, pero Soporte de implementación); La
implementación proporciona un método declarativo para Pod y ReplicaSet. Se utiliza para reemplazar el ReplicationContoller anterior para facilitar las aplicaciones de administración. Los escenarios de aplicación típicos incluyen:
Definir Depolyment para crear
actualizaciones progresivas de Pod y ReplicaSet y aplicaciones de reversión
Expansión y reducción
Pausar y reanudar la implementación
HPA (Horizontl Pod AutoScale):
solo se aplica a Deployment y ReplicaSet. En la versión V1, solo admite la expansión según el uso de CPU del Pod. En la versión v1alpha, admite la expansión y la contracción según la memoria y las métricas definidas por el usuario;
como se muestra en la siguiente figura, definición HPA, cuando la CPU es menor que 80, el MÁXIMO definido es 10 y el máximo es 10, pero cuando la CPU llega a 80, la expansión no continúa; si la CPU ya es mayor que 80, entonces el Pod se elimina hasta que el Mín mínimo es 2. O cuando la CPU es menor a 80, el Pod no se quita
StatefullSet es para resolver el problema de los servicios con estado. 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, según PVC;
identificación de red estable, es decir, reprogramación del Pod Posteriormente, su Nombre de Pod y HostNmae permanecen sin cambios y se implementan en base al Servicio Headless (es decir, Servicio sin IP de Clúster);
implementación ordenada, expansión ordenada, es decir, Pods se ordenan, y deben implementarse o expandirse según el orden definido. Continuar (es decir, de 0 a N-1, todos los pods anteriores deben estar en los estados En ejecución y Listo antes de que se ejecute el siguiente pod) según los contenedores de inicio;
reducción ordenada y eliminación ordenada (es decir, N-1 a 0);
DaemonSet:
asegúrese de que todos (o algunos) nodos ejecuten una copia de un Pod. Cuando un Nodo se une al clúster, se les agregará un Pod. Cuando se elimine un Nodo del clúster, estos Pods también se retirarán y el DaemonSet se eliminará. Se eliminarán todos los
pods creados por él; algunos usos típicos de DaemonSet:
ejecutar el demonio de almacenamiento en clúster, por ejemplo, ejecutar glusterd
en cada nodo , ceph ejecuta el demonio de recopilación de registros
en cada nodo , como fluentd, logstash en cada nodo Ejecute el demonio de supervisión, como prometheus Node Exporter
Trabajo:
Responsable de las tareas de procesamiento por lotes, es decir, una tarea que se ejecuta solo una vez, lo que garantiza que uno o más Pods de la tarea de procesamiento por lotes se completen con éxito.
Trabajo cron : el trabajo cron administra el tiempo estimado del trabajo, es decir: se
ejecuta solo una vez
en un momento dado y se ejecuta periódicamente en un momento dado
(2.3) Descubrimiento de servicios
El cliente desea acceder a un grupo de Pods. El servicio recopila los Pods a través de etiquetas. El servicio tiene una IP y un puerto. Luego, clinet accede al Pod correspondiente de forma indirecta al acceder al puerto IP + del servicio, que es un RR de acceso sondeado, el primer acceso El primer Pod y así sucesivamente:
Ponga la siguiente estructura en K8 para ejecutar:
Mysql se ejecuta en un Pod y se puede colocar en el controlador StatefullSet, pero la agrupación en clústeres no es tan conveniente para
Php-fpm para crear un controlador de implementación. La implementación especificará la cantidad de copias, como 3, y agregará el servicio al frente, de modo que Squid sea No es necesario escribir la dirección IP, use localhost en lugar de
Squid para encapsularlo en Pod, controlarlo a través del controlador, crear un servicio y vincularlo a través de etiquetas relacionadas, y el modo de exposición Nodeport
LVS realiza la programación de carga a través de sus propias funciones
Estado de funcionamiento del K8s:
