Introducción teórica a Kubernetes (k8s)

Un sistema de código abierto para implementar, escalar y administrar automáticamente "aplicaciones en contenedores".
Se puede entender que K8S es un clúster responsable de la operación y el mantenimiento automatizados de múltiples programas en contenedores (como Docker), y es una herramienta de marco de orquestación de contenedores con un ecosistema extremadamente rico.

2. Origen de los K8

K8S se basa en el sistema Borg de Google (sistema Borg, una herramienta de orquestación de contenedores a gran escala utilizada internamente por Google) como prototipo, que luego se reescribió en el lenguaje GO utilizando las ideas de Borg y se donó a la Fundación CNCF para código abierto.

La Cloud Native Foundation (CNCF) se estableció en diciembre de 2015 y está afiliada a la Linux Foundation. El primer proyecto incubado por CNCF fue Kubernetes. Con el uso generalizado de contenedores, Kubernetes se ha convertido en el estándar de facto para las herramientas de orquestación de contenedores.

Significado: La palabra proviene del griego timonel y piloto.

Sitio web oficial: https://kubernetes.io

GitHub: https://github.com/kubernetes/kubernetes

3. ¿Por qué utilizar K8S?

Imagine el método tradicional de implementación de back-end: coloque el paquete del programa (incluidos los archivos binarios ejecutables, los archivos de configuración, etc.) en el servidor, luego ejecute el script de inicio para ejecutar el programa y, al mismo tiempo, inicie el script del demonio para ejecutarlo regularmente. Verifique el estado de ejecución del programa y reinícielo si es necesario. Abra el programa.

Imagínese, ¿qué pasa si la cantidad de solicitudes de servicio aumenta y el servicio implementado no puede responder? El enfoque tradicional suele ser que si el volumen de solicitudes, la memoria y la CPU exceden el umbral y se emite una alarma, el personal de operación y mantenimiento agregará inmediatamente algunos servidores más y, después de implementar el servicio, se conectará al equilibrio de carga para compartir. la presión de los servicios existentes.
Surge un problema: desde el seguimiento de las alarmas hasta el despliegue de servicios, se requiere intervención humana. Entonces, ¿existe alguna forma de implementar, actualizar, desinstalar, ampliar y reducir servicios automáticamente?
Y esto es lo que tiene que hacer K8S: automatizar la gestión de operación y mantenimiento de programas en contenedores (Docker) .

K8S es el sistema de gestión de clústeres de contenedores de código abierto de Google. Basado en tecnologías de contenedores como Docker, proporciona una serie de funciones completas como implementación y operación, programación de recursos, descubrimiento de servicios y escalado dinámico para aplicaciones en contenedores, mejorando la eficiencia de las aplicaciones a gran escala. Gestión de clusters de contenedores.Conveniencia.

4. Funciones de Kubernetes

●Organizar contenedores entre hosts.
●Aprovechar al máximo los recursos de hardware para maximizar las necesidades de las aplicaciones empresariales.
●Despliegue y actualización de aplicaciones de control y automatización.
●Monte y agregue almacenamiento para aplicaciones con estado.
● Ampliar o reducir las aplicaciones en contenedores y sus recursos en línea.
●La gestión declarativa de contenedores garantiza que las aplicaciones implementadas funcionen de acuerdo con la forma en que las implementamos.
●Logre la verificación del estado de la aplicación y la autorreparación mediante diseño automático, reinicio automático, replicación automática y escalado automático.
●Proporcionar descubrimiento de servicios y equilibrio de carga para múltiples contenedores, de modo que los usuarios no tengan que considerar problemas de IP de contenedores.

2: Arquitectura y componentes del clúster de Kubernetes

1. Arquitectura y componentes del clúster de Kubernetes

K8S pertenece al modelo de dispositivo maestro-esclavo (arquitectura maestro-esclavo) , es decir, el nodo maestro es responsable de la programación, administración, operación y mantenimiento del clúster, y el nodo esclavo es el nodo de carga de trabajo informática en el clúster. .
En K8S, el nodo principal generalmente se llama nodo maestro y el nodo esclavo se llama nodo trabajador. El maestro asignará a cada nodo una carga de trabajo.

El componente maestro puede ejecutarse en cualquier computadora del clúster, pero se recomienda que el nodo maestro ocupe un servidor separado. Debido a que el Maestro es el cerebro de todo el clúster, si el nodo donde se encuentra el Maestro deja de funcionar o deja de estar disponible, todos los comandos de control dejarán de ser válidos. Además del Maestro, otras máquinas en el clúster K8S se denominan Nodos de Trabajador. Cuando un Nodo deja de funcionar, el Maestro transferirá automáticamente la carga de trabajo que contiene a otros nodos.

2. Componente principal-componente maestro

(1) Era un servidor

Se utiliza para exponer la API de Kubernetes. Cualquier solicitud de recurso u operación de llamada se realiza a través de la interfaz proporcionada por kube-apiserver. HTTP Restful API se utiliza para proporcionar servicios de interfaz. Todas las operaciones de adición, eliminación, modificación, consulta y monitoreo de recursos de objetos se entregan al servidor API para su procesamiento y luego se envían al almacenamiento de Etcd.

Se puede entender que API Server es el servicio de entrada de solicitudes de K8S. El servidor API es responsable de recibir todas las solicitudes de K8S (desde la interfaz UI o la herramienta de línea de comandos CLI) y luego notificar a otros componentes para que funcionen de acuerdo con las solicitudes específicas del usuario. Se puede decir que el servidor API es el cerebro de la arquitectura del clúster K8S.

(2) Administrador-controlador-kube

El controlador de gestión de operaciones es un subproceso en segundo plano que maneja tareas regulares en el clúster K8S y es el centro de control automatizado para todos los objetos de recursos en el clúster K8S.
En un clúster K8S, un recurso corresponde a un controlador y el administrador del controlador es responsable de administrar estos controladores.

Consiste en una serie de controladores que monitorean el estado de todo el clúster a través del servidor API y garantizan que el clúster esté en el estado de funcionamiento esperado. Por ejemplo, cuando un nodo falla inesperadamente, el administrador del controlador descubrirá y ejecutará rápidamente una solución automatizada. Proceso de reparación para garantizar que el grupo esté siempre en buen estado de funcionamiento.Condiciones de trabajo esperadas.

Estos controladores incluyen principalmente
el Controlador de Nodo : Responsable de detectar y responder a fallas de los nodos.
•Controlador de replicación : Responsable de garantizar que el número de copias de Pod asociadas con un RC (controlador de replicación de objeto de recurso) en el clúster siempre mantenga el valor preestablecido. Puede entenderse como garantizar que haya y solo haya N instancias de Pod en el clúster, donde N es el número de copias de Pod definidas en RC.
• Controlador de puntos finales : completa los objetos de los puntos finales (es decir, conecta servicios y pods) y es responsable de monitorear los cambios en los servicios y las copias de pods correspondientes. Se puede entender que un punto final es un punto de acceso expuesto por un servicio. Si necesita acceder a un servicio, debe conocer su punto final.
• Controladores de cuentas de servicio y tokens : cree cuentas predeterminadas y tokens de acceso API para nuevos espacios de nombres.
•ResourceQuota Controller (controlador de cuota de recursos) : garantiza que el objeto de recurso especificado no sobreocupará los recursos físicos del sistema en ningún momento.
•Namespace Controller (controlador de espacio de nombres) : gestiona el ciclo de vida del espacio de nombres.
• Controlador de servicio : un controlador de interfaz entre el clúster K8S y la plataforma de nube externa.

(3) Programador de Kube

Es el proceso responsable de la programación de recursos y selecciona un nodo Nodo apropiado para el Pod recién creado de acuerdo con el algoritmo de programación.

Puede entenderse como el programador de todos los nodos del nodo K8S. Cuando un usuario desea implementar un servicio, el Programador seleccionará el Nodo más apropiado para implementar el Pod según el algoritmo de programación.
•Predicado
•Prioridades

El Servidor API recibe la solicitud para crear un lote de Pods. El Servidor API le pedirá al Administrador-Controlador que cree Pods de acuerdo con la plantilla preestablecida. El Administrador-Controlador irá al Programador a través del Servidor API para seleccionar el Nodo más adecuado. nodo para el Pod recién creado. Por ejemplo, ejecutar este Pod requiere recursos 2C4G, y el Programador filtrará los nodos que no cumplan con la política a través de la política de preselección. Los recursos restantes en el nodo Nodo se informan al servidor API y se almacenan en etcd. El servidor API llamará a un método para encontrar los recursos restantes de todos los nodos Nodo en etcd y luego los comparará con los recursos requeridos por el Pod. Si un nodo nodo tiene recursos insuficientes O si no cumple con las condiciones de la estrategia de preselección, no podrá pasar la preselección. Los nodos seleccionados en la etapa de preselección se calificarán y clasificarán de acuerdo con la estrategia de optimización en la etapa de preselección, y se seleccionará el nodo con la puntuación más alta. Por ejemplo, un nodo con más recursos y una carga menor puede tener una clasificación más alta.

3. Configurar el centro de almacenamiento

(1)etc.

Servicio de almacenamiento K8S. etcd es un sistema de almacenamiento distribuido de valores clave que almacena configuraciones clave y configuraciones de usuario de K8S. Solo el servidor API en K8S tiene permisos de lectura y escritura, y otros componentes deben leer y escribir datos a través de la interfaz del servidor API.

4. Componente del nodo

(1) Kubelet

El monitor del nodo Nodo y el comunicador con el nodo Maestro. Kubelet es el "delineador" del nodo maestro instalado en el nodo Nodo. Informará periódicamente al servidor API el estado de los servicios que se ejecutan en su nodo Nodo y aceptará instrucciones del nodo maestro para tomar medidas de ajuste.

Obtenga el estado esperado del Pod en su propio nodo desde el nodo maestro (como qué contenedor ejecutar, la cantidad de réplicas en ejecución, cómo configurar la red o el almacenamiento, etc.) e interactúe directamente con el motor del contenedor para implementarlo. la gestión del ciclo de vida del contenedor.Si el estado del Pod en su propio nodo es diferente de Si el estado esperado es inconsistente, llame a la interfaz de la plataforma del contenedor correspondiente (es decir, la interfaz acoplable) para alcanzar este estado.

Administre la limpieza de imágenes y contenedores para garantizar que las imágenes en los nodos no ocupen todo el espacio en disco y que los contenedores salidos no ocupen demasiados recursos.

Resumen:
en un clúster de Kubernetes, se inicia un proceso de servicio de Kubelet en cada nodo (también conocido como nodo trabajador). Este proceso se utiliza para procesar las tareas asignadas por el Maestro a este nodo y administrar Pods y contenedores en los Pods. Cada proceso de kubelet registrará la propia información del nodo en el servidor API, informará periódicamente el uso de los recursos del nodo al maestro y monitoreará los recursos del contenedor y del nodo a través de cAdvisor.

(2) Para proxy

El proxy de red Pod se implementa en cada nodo Nodo, que es el portador de los recursos del Servicio Kubernetes y es responsable de mantener las reglas de la red y el equilibrio de carga de cuatro capas. Responsable de escribir reglas para iptables e ipvs para implementar el acceso al mapeo de servicios.

Kube-Proxy en sí no proporciona directamente una red para Pods. La red del Pod la proporciona Kubelet. Kube-Proxy en realidad mantiene una red de clúster de Pod virtual.
Kube-apiserver actualiza el servicio Kubernetes y mantiene los puntos finales monitoreando Kube-Proxy.

Kube-proxy implementa el equilibrio de carga de microservicios en el clúster K8S. Kube-proxy es el equilibrador de carga dentro del clúster K8S. Es un servidor proxy distribuido que ejecuta un componente proxy Kube en cada nodo de K8S.

(3) acoplador o cohete

El motor de contenedores ejecuta el contenedor y es responsable de la creación y gestión del contenedor local.
Cuando Kubernetes programa un pod en un nodo, el kubelet en el nodo le indica a Docker que inicie un contenedor específico. Luego, kubelet recopilará continuamente información del contenedor a través de la ventana acoplable y luego la enviará al nodo maestro. Docker extraerá la imagen del contenedor e iniciará o detendrá el contenedor como de costumbre. La única diferencia es que esto lo controla un sistema automatizado en lugar de que lo realice manualmente un administrador en cada nodo.

5. Conceptos básicos de Kubernetes

Kubernetes contiene muchos tipos de objetos de recursos: pod, etiqueta, servicio, controlador de replicación , etc.

Todos los objetos de recursos se pueden agregar, eliminar, modificar, verificar, etc. a través de la herramienta kubectl proporcionada por Kubernetes y almacenar en etcd para un almacenamiento persistente.

Kubernets es en realidad un sistema de control de recursos altamente automatizado que realiza funciones avanzadas como el control automático y la corrección automática de errores mediante el seguimiento y la comparación de la diferencia entre el estado esperado de los recursos guardados en el almacenamiento etcd y el estado real de los recursos en el entorno actual.

(1) vaina

Pod es la unidad básica más pequeña/simple creada o implementada por Kubernetes. Un Pod representa un proceso que se ejecuta en el clúster.
Las vainas pueden entenderse como vainas de guisantes, y cada contenedor de una misma vaina es un guisante.

Un Pod consta de uno o más contenedores. Los contenedores del Pod comparten red, recursos informáticos y de almacenamiento y se ejecutan en el mismo host Docker.
Se pueden ejecutar varios contenedores en un Pod, también llamado modo SideCar. En un entorno de producción, un solo contenedor o varios contenedores con una fuerte correlación y complementariedad forman un Pod.

Los contenedores en el mismo Pod pueden acceder entre sí a través de localhost y pueden montar todos los volúmenes de datos en el Pod; sin embargo, los contenedores entre diferentes Pods no pueden acceder a través de localhost ni pueden montar los volúmenes de datos de otros Pods.

(2) Controlador de cápsula

El controlador de pod es una plantilla para el inicio de Pod, que se utiliza para garantizar que los Pods iniciados en K8S siempre se ejecuten de acuerdo con las expectativas del usuario (número de copias, ciclo de vida, verificación del estado de salud, etc.).

K8S proporciona numerosos controladores Pod , los siguientes se utilizan comúnmente:
•Implementación : implementación de aplicaciones sin estado. La función de Implementación es administrar y controlar Pods y ReplicaSets, y controlarlos para que se ejecuten en el estado esperado por el usuario.

•Replicaset : Garantiza el número esperado de réplicas de Pod. La función de ReplicaSet es administrar y controlar los Pods y controlarlos para que funcionen bien. Sin embargo, ReplicaSet está controlado por Deployment.

Se puede entender que Deployment es el contratista general, quien es el principal responsable de supervisar el trabajo de los Pods de trabajadores a continuación y garantizar que la cantidad de Pods requeridos por el usuario esté funcionando en todo momento. Si descubre que un Pod de trabajo está fuera de servicio, obtenga rápidamente un Pod nuevo para reemplazarlo. ReplicaSet es el subcontratista del contratista general.
Desde la perspectiva de los usuarios de K8S, los usuarios operarán directamente el servicio de implementación de implementación y, cuando se implemente la implementación, K8S generará automáticamente el ReplicaSet y Pod requeridos. Los usuarios solo deben preocuparse por la implementación y no por el ReplicaSet.
El objeto de recurso Replication Controller es el predecesor de ReplicaSet y se recomienda oficialmente utilizar Deployment para reemplazar el Replication Controller para implementar servicios.

•Daemonset : asegúrese de que todos los nodos ejecuten el mismo tipo de Pod y asegúrese de que haya un Pod ejecutándose en cada nodo, que generalmente se usa para implementar tareas en segundo plano a nivel del sistema.

•Statefulset : implementación de aplicaciones con estado

•Trabajo : tarea única. Según la configuración del usuario, el Pod administrado por el Trabajo se cerrará automáticamente después de que la tarea se complete con éxito.

•Cronjob : tareas periódicas programadas

(3)Etiqueta

Las etiquetas son un método de gestión único de K8S, que facilita la clasificación y gestión de objetos de recursos.
Las etiquetas se pueden adjuntar a varios objetos de recursos, como Nodo, Pod, Servicio, RC, etc., y se utilizan para asociar objetos, realizar consultas y filtrar.
Una etiqueta es un par clave-valor, donde el usuario especifica la clave y el valor.
Un objeto de recurso puede definir cualquier número de etiquetas, y la misma etiqueta también se puede agregar a cualquier número de objetos de recurso, o se puede agregar o eliminar dinámicamente después de crear el objeto.
Las funciones de gestión de agrupación de recursos multidimensionales se pueden lograr agrupando una o más etiquetas diferentes con objetos de recursos específicos.

Similar a Etiqueta, también existe Anotación .
La diferencia es que un valor de etiqueta válido debe tener 63 caracteres o menos y debe estar vacío o comenzar y terminar con caracteres alfanuméricos ([a-z0-9A-Z]) y puede incluir guiones (-), guiones bajos (_) , punto (.) y letras o números. Los valores de los comentarios no tienen límite de longitud de caracteres.

(4) Selector de etiquetas (selector de etiquetas)

Definir una etiqueta para un objeto de recurso equivale a darle una etiqueta; luego puede consultar y filtrar objetos de recurso que tengan ciertas etiquetas a través del selector de etiquetas (selector de etiquetas).
Actualmente existen dos tipos de selectores de etiquetas: basados en relaciones de equivalencia (igual a, no igual a) y basados en relaciones de conjunto (pertenece a, no pertenece a, existe).

(5) Servicio

En un clúster K8S, aunque a cada Pod se le asignará una dirección IP separada, debido a que los Pods tienen un ciclo de vida (pueden crearse y no se reiniciarán después de ser destruidos), pueden cambiar en cualquier momento debido a cambios comerciales. Como resultado, esta dirección IP también desaparecerá cuando se destruya el Pod.

El servicio es el concepto central utilizado para resolver este problema.
Servicio en K8S no significa "servicio" como solemos decir, sino más bien una capa de puerta de enlace, que puede considerarse como la interfaz de acceso externo y el equilibrador de tráfico de un grupo de Pods que brindan el mismo servicio.
En qué Pods actúa el Servicio se definen mediante selectores de etiquetas.
En un clúster K8S, el Servicio puede considerarse como la interfaz de acceso externo de un grupo de Pods que brindan el mismo servicio. El servicio al que el cliente necesita acceder es el objeto Servicio. Cada Servicio tiene una IP virtual fija (esta IP también se llama IP de clúster), que está vinculada automática y dinámicamente al Pod de backend. Todas las solicitudes de red acceden directamente a la IP virtual del Servicio, y el Servicio se reenviará automáticamente al backend. .
Además de proporcionar un método de acceso externo estable, el Servicio también puede funcionar como un equilibrador de carga, distribuyendo automáticamente el tráfico de solicitudes a todos los servicios back-end. El Servicio puede escalar horizontalmente de forma transparente a los clientes).
La clave para realizar la función de servicio es kube-proxy. kube-proxy se ejecuta en cada nodo y monitorea los cambios en los objetos de servicio en el servidor API. La red se puede implementar a través de los siguientes tres modos de programación de tráfico: espacio de usuario (obsoleto), iptables (a punto de ser abandonado) e ipvs (recomendado). , mejor rendimiento) reenvío.

El servicio es el núcleo de los servicios K8S: protege los detalles del servicio y expone las interfaces del servicio al exterior de manera unificada, logrando verdaderamente "microservicios". Por ejemplo, uno de nuestro servicio A ha implementado 3 copias, es decir, 3 Pods; los usuarios solo deben prestar atención a la entrada de un Servicio y no deben preocuparse por qué Pod deben solicitarse.
Las ventajas son muy obvias: por un lado, los usuarios externos no necesitan estar al tanto de los cambios de IP causados por fallas inesperadas de los servicios en los Pods o del reinicio de los Pods K8S. Los usuarios externos tampoco necesitan estar al tanto de los cambios de IP causados por el Pod. Reemplazos debido a actualizaciones o cambios de servicio.Variedad.

(6) Ingreso

El servicio es el principal responsable de la topología de la red dentro del clúster K8S, entonces, ¿cómo accede el exterior del clúster al interior del clúster? Se necesita ingreso en este momento. El ingreso es la capa de acceso de todo el clúster K8S y es responsable de la comunicación dentro y fuera del clúster.
Ingress es una aplicación de capa 7 que trabaja bajo el modelo de referencia de red OSI en el cluster K8S, es una interfaz expuesta externamente, el método de acceso típico es http/https.
El servicio solo puede realizar la programación del tráfico en la cuarta capa, en forma de ip+puerto. Ingress puede programar el tráfico comercial en diferentes dominios comerciales y diferentes rutas de acceso a URL.
Por ejemplo: el cliente solicita http://www.qhw.com:puerto ---> Ingress ---> Servicio ---> Pod

(7)Nombre

Dado que K8S utiliza "recursos" internamente para definir cada concepto lógico (función), cada "recurso" debe tener su propio "nombre".
Los "recursos" incluyen la versión de API (apiversión), categoría (tipo), metadatos (metadatos), lista de definiciones (especificaciones), estado (estado) y otra información de configuración.
El "nombre" generalmente se define en la información de "metadatos" del "recurso". Debe ser único dentro del mismo espacio de nombres.

(8) Espacio de nombres

A medida que aumentan los proyectos, aumenta el personal y se expande la escala del clúster, se necesita un método que pueda aislar lógicamente varios "recursos" dentro de K8S: este es el espacio de nombres.
Namespace nació para dividir un clúster K8S en varios grupos de clústeres virtuales cuyos recursos no se pueden compartir.
Los nombres de "recursos" en diferentes espacios de nombres pueden ser los mismos, pero los "nombres" del mismo tipo de "recursos" en el mismo espacio de nombres no pueden ser los mismos.
El uso adecuado del espacio de nombres de K8S puede permitir a los administradores de clústeres clasificar, gestionar y explorar mejor los servicios prestados a K8S.
Los espacios de nombres que existen por defecto en K8S incluyen: default, kube-system, kube-public, etc.
Para consultar un "recurso" específico en K8S, debe traer el espacio de nombres correspondiente.

6. flujo de trabajo k8s

1. El usuario envía una solicitud a kube apiserver mediante autenticación para crear una solicitud de pod.

2. apiserver escribirá información relevante en etcd.

3. El apiserver encontrará el controlador-administrador de kube para crear los recursos de pod correspondientes.

4. El controlador-administrador leerá los datos en etcd a través de un servidor para encontrar la información del pod correspondiente.

5. El apiserver encuentra el programador para programar el pod. Con respecto a dónde transferir el pod, el apiserver lee los datos en etcd para obtener la información relevante del nodo y encuentra el nodo más adecuado para ejecutar el pod. Finalmente, el programador programa el estrategia de preselección y la estrategia preferida a través de un algoritmo.Calcule en qué nodo se debe programar la ejecución del pod.

6. El programador encuentra el componente kubelet en el nodo correspondiente a través de un servidor, crea y mantiene pods a través de este componente y los contenedores relacionados se crean a través de Docker.

7. Luego, estos pods se asocian para formar un clúster a través del proxy kube. El proxy kube utiliza recursos de servicio para exponerlos usando una dirección IP unificada. Los usuarios externos pueden usar esta dirección IP para acceder a los servicios que se ejecutan en el pod.

8. Kubelet monitoreará cuántos recursos se están ejecutando en este nodo, así como el estado y la información relacionados con el pod, y los enviará a un servidor, que escribirá la información en etcd y la guardará. El mantenimiento de los pods lo realiza el controlador-administrador. Cuando el número de pods no cumple con el número preestablecido, creará el número preestablecido correspondiente para garantizar el número total de pods.

Tres: instalación de K8

1. Métodos comunes de instalación e implementación de K8S

(1) Minikubo

Minikube es una herramienta que puede ejecutar rápidamente un micro K8S de un solo nodo localmente y solo se utiliza para aprender y obtener una vista previa de algunas funciones de K8S.
Dirección de implementación: https://kubernetes.io/docs/setup/minikube

(2) Administrador del cubo

Kubeadm también es una herramienta que proporciona kubeadm init y kubeadm join para una implementación rápida de clústeres K8S, lo cual es relativamente simple.
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

2. Instalación e implementación binaria

La primera opción para producción es descargar el paquete binario de la versión de distribución oficial, implementar manualmente cada componente y el certificado TLS autofirmado para formar un clúster K8S, recomendado para principiantes.
https://github.com/kubernetes/kubernetes/releases

Kubeadm reduce el umbral de implementación, pero bloquea muchos detalles, lo que dificulta la resolución de problemas. Si desea hacerlo más fácil y controlable, se recomienda utilizar paquetes binarios para implementar clústeres de Kubernetes. Aunque la implementación manual es más problemática, puede aprender muchos principios de funcionamiento durante el proceso, lo que también es beneficioso para el mantenimiento posterior.

3. La diferencia entre la implementación binaria de k8s y la alta disponibilidad

●La implementación binaria
es difícil de implementar, fácil de administrar, tiene un buen rendimiento de expansión del clúster y es más
estable. Cuando la escala del clúster alcanza una cierta escala (cientos de nodos, decenas de miles de Pods), la estabilidad binaria es mayor que la de Implementación de kubeadm
. Cuando ocurre una falla, la máquina host lo hará y el proceso también comenzará

La implementación de Kubeadm es
simple de implementar pero difícil de administrar.
Permite que los componentes y servicios sean administrados por contenedores. El tiempo de recuperación de fallas es más lento que el binario. Cuando
ocurre una falla, inicia el host, luego inicia el proceso y finalmente inicia el contenedor, para que el clúster pueda ser restaurado. Más lento que el binario

Resumir

ansible herramienta de orquestación de múltiples máquinas a nivel de aplicación
docker motor de contenedor tiempo de ejecución de contenedor
dockerfile build image
docker compose herramienta de orquestación de clúster de contenedores de una sola máquina

docker swarm La herramienta de orquestación de múltiples máquinas de contenedores Docker es una herramienta para realizar la gestión y programación de clústeres de contenedores de Docker.
kubernetes La herramienta de orquestación de múltiples máquinas de contenedores de Google ocupa más del 80% de la participación de mercado y se ha convertido en el estándar de facto para las herramientas de orquestación de contenedores
mesos + marathon mesos: marco de administración de recursos distribuidos, que puede programar y administrar de manera uniforme los recursos de hardware de múltiples hosts en el clúster
marathon: marco de orquestación de contenedores de Mesos, utilizado para programar y ejecutar servicios de contenedores

¿Qué componentes tiene el K8S?
K8S tienedos tipos de nodos : maestro y nodo de trabajo.
El nodo maestro tiene un programador de administrador-controlador de servidor y etcd se utiliza como base de datos del clúster k8s.
El nodo de nodo tiene un motor de contenedor kubelet kube-proxy/tiempo de ejecución de contenedor (docker, contenedord ).

¿Qué hace el componente?
apiserver : es la entrada de acceso unificado para todas las solicitudes de servicio.
Controller-manager : el administrador del controlador es responsable de administrar objetos de recursos como conjuntos de réplicas de Pod, espacios de nombres, puntos finales, nodos y controladores implementados; monitorear el estado de todo el clúster K8S. a través de un servidor y asegúrese de que el clúster esté en el estado de funcionamiento esperado.
Programador : Programador de recursos, responsable de programar los recursos del Pod, seleccionar el nodo más adecuado para el Pod implementado mediante un algoritmo de programación (estrategia de preselección, estrategia preferida), etc.: K8S La base de datos del clúster
es una base de datos distribuida con una estructura de almacenamiento de valores clave, responsable de almacenar toda la información importante del clúster K8S. Solo apiserver tiene permisos de lectura y escritura.

kubelet : recibe solicitudes del maestro, crea y administra Pods y contenedores, interactúa con el motor del contenedor para administrar el ciclo de vida del contenedor; recopila información de recursos del nodo y el estado de ejecución del Pod e informa al apiserver kube-proxy del maestro:
como servicio El portador de recursos, implementa el proxy de red de Pod, mantiene las reglas de red y el trabajo de equilibrio de carga de cuatro capas
Motor de contenedor/tiempo de ejecución del contenedor: ejecuta el contenedor

¿Cuál es el flujo de trabajo para crear Pods en K8S?
1) El usuario envía una solicitud para crear un Pod al apiserver en el nodo maestro a través del cliente,
2) El apiserver primero escribirá la información de la solicitud en etcd y la guardará, y luego buscará el controlador-administrador para crear el recurso Pod. de acuerdo con la plantilla de configuración de recursos preestablecida.
3) Luego, el controlador-administrador irá al programador a través del apiserver para seleccionar el nodo más adecuado para el Pod recién creado.
4) El programador selecciona el nodo más adecuado para la programación a través del pre- estrategia de selección y estrategia de optimización del algoritmo de programación.
5) Luego encontrará el nodo correspondiente a través del apiserver. El kubelet en el nodo crea y administra Pods
6) El kubelet interactuará con el motor del contenedor para administrar el ciclo de vida del Pod/contenedor
7) Los usuarios también pueden escribir reglas de red en kube-proxy a través de un servidor, crear recursos de servicio e implementar control de Pod Descubrimiento de servicios y equilibrio de carga

Pod de objetos de recursos de K8S
: es la unidad más pequeña que K8S puede crear y administrar. Un Pod puede contener uno o más contenedores de aplicaciones, y los contenedores de un Pod comparten recursos como la red y el almacenamiento.
Controlador de cápsulas:

implementación : implementa aplicaciones sin estado. También responsable de la gestión.

replicaset (mantener la cantidad de copias de Pod como se esperaba) y Pod (un proceso de aplicación en contenedores)
statefulset : implementar aplicaciones con estado
daemonset : implementar el mismo Pod en todos los nodos
trabajo de nodos: implementar Pods de tareas a corto plazo al mismo tiempo, Pod
Cronjob : Los pods para tareas a corto plazo se implementan periódicamente y el Pod saldrá automáticamente después de ejecutar la tarea.