kubernetes, denominado k8s (k12345678s). 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.

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.

1.El 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.

Sitio web oficial: Kubernetes

GitHub: GitHub - kubernetes/kubernetes: programación y gestión de contenedores de nivel de producción

2. ¿Por qué utilizar k8?

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.) 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 es 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, una vez implementado el servicio, se conectará al equilibrador de carga para compartir. la presión del servicio existente.
Surge un problema: desde el seguimiento de las alarmas hasta el despliegue de servicios, se requiere intervención humana. Entonces, ¿existe alguna manera de implementar, actualizar, desinstalar, ampliar y reducir servicios automáticamente?
Y esto es lo que va a hacer K8S: un programa de gestión automatizada de operaciones y mantenimiento en contenedores (Docker).

Funciones principales de 3.k8s

Orqueste contenedores entre hosts.
Aproveche al máximo los recursos de hardware para maximizar las necesidades de las aplicaciones empresariales.
Controle y automatice la implementación y las actualizaciones de aplicaciones.
Monte y agregue almacenamiento para aplicaciones con estado.
Escale 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.
Realice 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.
Proporciona descubrimiento de servicios y equilibrio de carga para múltiples contenedores, eliminando la necesidad de que los usuarios consideren los problemas de IP de los contenedores.

2. Arquitectura y componentes del clúster k8s

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 maestro generalmente se llama nodo maestro y el nodo esclavo se llama nodo nodo trabajador, y 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 Nodo Trabajador. Cuando un Nodo deja de funcionar, el Maestro transferirá automáticamente la carga de trabajo en él a otros nodos.

1.Componente maestro

1.1 Kube apiservidor

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. API Server es responsable de recibir todas las solicitudes de K8S (desde la interfaz de usuario o la herramienta de línea de comandos CLI) y luego notifica a otros componentes para que funcionen de acuerdo con la solicitud específica del usuario. Se puede decir que el servidor API es el cerebro de la arquitectura del clúster K8S.

1.2Kube-controlador-administrador

El controlador de gestión de operaciones es un proceso 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.

Tipos de controladores:

Controlador de Nodo: Responsable de detectar y responder a fallas de nodo.
Controlador de replicación: responsable de garantizar que la cantidad 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 tokens y cuentas de servicio: cree cuentas predeterminadas y tokens de acceso a API para nuevos espacios de nombres.
Controlador de cuota de recursos (controlador de cuota de recursos): asegúrese de que el objeto de recurso especificado no ocupe en exceso los recursos físicos del sistema en ningún momento.
Controlador de espacio de nombres: gestiona el ciclo de vida del espacio de nombres.
Controlador de servicio (Controlador de servicio): pertenece a un controlador de interfaz entre el clúster K8S y la plataforma de nube externa.

1.3Programador de Kube

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

Puede entenderse como el programador de todos los nodos de K8S. Cuando el usuario quiera implementar el servicio, el Programador seleccionará el Nodo más adecuado para implementar el Pod de acuerdo con el algoritmo de programación.

Estrategia de predicado (predicado)
estrategia preferida (prioridades)

El servidor API recibe una solicitud para crear un lote de Pods, el servidor API permitirá que el administrador del controlador cree Pods de acuerdo con la plantilla preestablecida, el administrador del controlador irá al programador para seleccionar el nodo Nodo más adecuado para los pods recién creados a través del servidor API. 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. La cantidad de recursos que quedan en el nodo del nodo se almacena en etcd informando al servidor API, y el servidor API llamará a un método para encontrar los recursos restantes de todos los nodos del nodo en etcd y luego comparará 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 clasificarán de acuerdo con la estrategia de optimización para los nodos de Nodo que hayan pasado la preselección en la etapa de optimizació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.

2. Componentes del nodo

2.1 El cubo

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 deseado del Pod en su propio nodo desde el nodo Maestro (como qué contenedor ejecutar, la cantidad de copias a ejecutar, cómo configurar la red o el almacenamiento, etc.) e interactúe directamente con el motor del contenedor para implementar la gestión del ciclo de vida del contenedor.Si el estado del Pod en su propio nodo es el mismo que Si el estado esperado es inconsistente, llame a la interfaz de la plataforma del contenedor correspondiente (es decir, la interfaz acoplable) para lograr este estado.

Administre la limpieza de imágenes y contenedores para garantizar que las imágenes en los nodos no ocupen espacio en el 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 manejar las tareas enviadas por el Maestro al nodo y administrar Pods y contenedores en 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.2Kube-Proxy

El agente 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 un equilibrador de carga dentro del clúster K8S. Es un servidor proxy distribuido que ejecuta un componente proxy Kube en cada nodo de K8S.

2.3 acoplador o cohete

El motor de contenedor ejecuta el contenedor y es responsable de la creación y gestión del contenedor local.
Cuando Kubernetes programa el pod en el nodo, el kubelet en el nodo le indicará 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.

3. Configurar el centro de almacenamiento

3.1etcd

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.

3. Flujo de trabajo de k8 creando pods

El usuario envía una solicitud para crear un Pod al apiserver en el nodo maestro a través del cliente.
El apiserver primero escribirá la información de la solicitud en etcd para su almacenamiento y luego buscará el controlador-administrador para crear recursos Pod de acuerdo con la plantilla de configuración de recursos preestablecida.
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.
El planificador selecciona el nodo más adecuado para la programación mediante la estrategia de preselección y la estrategia de optimización del algoritmo de programación.
Luego use apiserver para encontrar el kubelet en el nodo correspondiente para crear y administrar Pods.
El kubelet interactuará con el motor del contenedor para gestionar el ciclo de vida del Pod/contenedor.
Los usuarios también pueden escribir reglas de red en kube-proxy a través de un servidor, crear recursos de servicio y realizar el descubrimiento de servicios y el equilibrio de carga de Pods.

4. El concepto central de k8

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 (SideCar). En un entorno de producción, un Pod generalmente se compone de uno o varios contenedores con fuertes asociaciones y complementariedades.

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ápsulas

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.).

Hay muchos controladores Pod proporcionados en K8S, y los más utilizados son los siguientes:

Despliegue: despliegue de aplicaciones sin estado. La función de Deployment es administrar y controlar Pod y ReplicaSet, y controlarlos para que se ejecuten en el estado esperado por el usuario.
Conjunto de réplicas: asegúrese de que haya la cantidad esperada 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.
Daemonset: asegúrese de que todos los nodos ejecuten el mismo tipo de Pod y asegúrese de que uno de esos Pod se esté ejecutando en cada nodo. Generalmente se usa para implementar tareas en segundo plano a nivel del sistema.
Statefulset: implementación de aplicaciones con estado
Trabajo: Una 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

La relación entre implementación y conjunto de réplicas:

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, el usuario operará 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.

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, y también 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.

La diferencia entre Etiqueta y 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 estar en el medio. Contiene guiones (-), guiones bajos (_), puntos (.) y letras o números. No hay límite de longitud de caracteres para los valores de los comentarios.

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 recursos con 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 el clúster K8S, aunque a cada Pod se le asignará una dirección IP separada, dado que los Pods tienen un ciclo de vida (se pueden crear 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 un grupo de interfaces de acceso externo y equilibradores de tráfico 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 back-end. Todas las solicitudes de red acceden directamente a la IP virtual del Servicio, y el Servicio la reenviará automáticamente a la parte trasera.
Además de proporcionar un método de acceso externo estable, el Servicio también puede funcionar como un equilibrio de carga (Load Balance), distribuyendo automáticamente el tráfico de solicitudes a todos los servicios de back-end, y el Servicio puede escalar horizontalmente de forma transparente a los clientes (escala).
La clave para realizar la función de servicio es kube-proxy. kube-proxy se ejecuta en cada nodo y monitorea los cambios de los objetos de servicio en el servidor API. Puede implementar la red a través de los siguientes tres modos de programación de tráfico: espacio de usuario (abandonado), iptables (al borde de obsoleto), 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.
La ventaja es muy obvia: por un lado, los usuarios externos no necesitan percibir los cambios de IP causados por fallas inesperadas del servicio en Pods y K8S al reiniciar los Pods, y los usuarios externos no necesitan percibir las IP causadas por los reemplazos de Pod causados por actualizaciones y servicios. cambia Variedad.

6.Ingreso

El servicio es el principal responsable de la topología de la red dentro del clúster K8S, entonces, ¿cómo puede el exterior del clúster acceder 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 funciona bajo el modelo de referencia de red OSI en un 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 y la forma de expresión es ip+puerto. Ingress puede programar el tráfico comercial de diferentes dominios comerciales y diferentes rutas de acceso a URL.
Por ejemplo: solicitudes de cliente http://www.kgc.com:puerto ---> Ingress ---> Servicio ---> Pod

7.Nombre

Dado que K8S utiliza "recursos" 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 los "recursos" en diferentes espacios de nombres pueden ser los mismos y los "nombres" de los mismos "recursos" en el mismo espacio de nombres no pueden ser los mismos.
El uso razonable del espacio de nombres de K8S puede permitir a los administradores de clústeres clasificar, administrar y explorar mejor los servicios entregados a K8S.
Los espacios de nombres predeterminados en K8S incluyen: default, kube-system, kube-public, etc.
Para consultar "recursos" específicos en K8S, debe traer el espacio de nombres correspondiente.

Información de configuración de recursos 9.k8s:

Aplicación: la versión de la interfaz API utilizada por cada objeto de recurso en k8s
Tipo: el tipo de objeto de recurso
Maledala: metadatos de objetos de recursos, como nombre, nombre de recurso, espacio de nombres. etiquetas etiqueta, anillas comentario
Especificación: lista de configuración de recursos (atributos de configuración) del objeto de recurso, como número de copias, nombre del espejo, volumen de datos, selector de etiquetas, etc.
Estado: información del estado de ejecución actual del objeto de recurso

Arquitectura y flujo de trabajo de Kubernetes

1. Introducción a Kubernetes