Análisis de la tecnología de virtualización, la segunda ronda de comprensión de Kubernetes por primera vez

Autor: JD Logística Yang Jianmin

1. Origen de la arquitectura de microservicios

Arquitectura monolítica: se puede entender como una aplicación en la que el módulo de lógica de negocios principal (el módulo de código que escribimos, excluyendo el middleware independiente) se ejecuta en un proceso, generalmente ejecutándose en un contenedor Tomcat y ubicado en un proceso. Las ventajas de la arquitectura monolítica son un umbral técnico bajo, una menor carga de trabajo de programación, un desarrollo simple y rápido, una depuración conveniente, una construcción sencilla del entorno, una fácil implementación y actualización, un bajo costo general de desarrollo y mantenimiento y resultados rápidos. Sus desventajas también son obvias:

(1) El sistema de aplicación monolítico está relativamente inflado e inflado, con un alto grado de acoplamiento, lo que dificulta llevar a cabo el desarrollo y la operación y el mantenimiento sostenibles.

(2) Es difícil que una sola aplicación soporte las crecientes solicitudes y demandas de los usuarios.

 

Diagrama de arquitectura de aplicación única basado en Spring Framework

La idea central de la arquitectura distribuida es dividir un sistema de un solo proceso en un grupo de procesos que cooperan entre sí en función y se pueden implementar de forma independiente en varios servidores. De esta manera, el sistema se puede implementar de la siguiente manera de dos maneras según las necesidades comerciales reales La expansión de algunos componentes independientes mejora el rendimiento.

• Expansión horizontal: expansión aumentando el número de servidores

• Expansión vertical: asigne mejores máquinas y proporcione más recursos a ciertos negocios especiales en el sistema, aumentando así la carga del sistema y el rendimiento de estos negocios

La arquitectura distribuida es dividir una enorme aplicación monolítica en múltiples procesos que se ejecutan de forma independiente. Estos procesos pueden realizar llamadas remotas de alguna manera. Por lo tanto, el primer problema técnico central que debe resolver la arquitectura distribuida es el proceso de comunicación remota entre procesos independientes. La primera respuesta a esta pregunta es la tecnología RPC (llamada a procedimiento remoto).El diagrama estructural de una plataforma típica de arquitectura de microservicios es el siguiente:

 

Los marcos de arquitectura de microservicios más conocidos incluyen Dubbo y Spring Cloud. Después de eso, las arquitecturas de microservicios más exitosas están básicamente vinculadas a la tecnología de contenedores. La más exitosa e influyente es la plataforma Kubernetes, y Docker también es similar. La compañía lanzó Docker Swarm. (a finales de 2017, Docker Swarm también admitía Kubernetes).

 

Las ventajas de la arquitectura de microservicios no se ampliarán debido al espacio limitado del artículo, pero cualquier tecnología tiene dos lados, y la arquitectura de microservicios tiene cierta complejidad.Por ejemplo, los desarrolladores deben dominar alguna tecnología RPC y deben escribir código para manejar RPC. velocidad Problemas complicados como la lentitud o la falla de la llamada. Para resolver el problema de la complejidad de la programación que plantean los microservicios, ha surgido una nueva idea de diseño de arquitectura, que es Service Mesh.La definición de Service Mesh es: una infraestructura compleja para manejar la comunicación (llamadas) entre los servicios y las instalaciones de servicios. En esencia, Service Mesh es una red de servicios compuesta por un grupo de agentes de red. Estos agentes se implementarán junto con los programas de usuario para actuar como agentes de servicio. Este agente se denomina más adelante "Sidecar" en la arquitectura de productos Istio de Google. De hecho, es utilizar la idea del modo proxy para resolver el problema de la intrusión de código y la codificación repetida. La siguiente figura muestra el diagrama de arquitectura más simple de Service Mesh. Servie Mesh tampoco es el protagonista esta vez, los amigos interesados ​​​​pueden aprender por sí mismos.

 

2. Conociendo k8s por primera vez

El texto oficial es: K8s es una abreviatura derivada de la sustitución de las 8 letras “ubernete” por 8.

El nombre completo de k8s es kubernetes.El nombre proviene del griego y significa "timonel" o "navegador".Es la arquitectura de microservicios de la primera generación de tecnología de contenedores (la segunda generación es Servie Mesh).

Kubernetes se originó originalmente en el Borg interno de Google, que proporciona un sistema de administración e implementación de clústeres de contenedores orientado a aplicaciones. El objetivo de Kubernetes es eliminar la carga de orquestar la infraestructura física/virtual de computación, red y almacenamiento, y permitir que los operadores y desarrolladores de aplicaciones se concentren por completo en las primitivas centradas en contenedores para las operaciones de autoservicio. Kubernetes también proporciona una base estable y compatible (plataforma) para crear flujos de trabajo personalizados y tareas de automatización más avanzadas.

Kubernetes tiene capacidades integrales de administración de clústeres, que incluyen mecanismos de acceso y protección de seguridad de varios niveles, capacidades de soporte de aplicaciones de múltiples inquilinos, mecanismos transparentes de registro y descubrimiento de servicios, balanceadores de carga integrados, capacidades de recuperación automática y descubrimiento de fallas, y actualizaciones continuas de servicios. Y expansión en línea, mecanismo de programación automática de recursos escalables, capacidades de gestión de cuotas de recursos de granularidad múltiple.

Kubernetes también proporciona herramientas de gestión integrales, que cubren todos los aspectos del desarrollo, las pruebas de implementación, la supervisión de la operación y el mantenimiento, etc.

2.1 arquitectura y componentes k8s

 

 

Kubernetes consta principalmente de los siguientes componentes principales:

1. etcd guarda el estado de todo el clúster;
2. aserver proporciona el único acceso a las operaciones de recursos y proporciona autenticación, autorización, control de acceso, registro de API y mecanismos de descubrimiento;
3. El administrador del controlador es responsable de mantener el estado del clúster, como la detección de fallas, la expansión automática, la actualización continua, etc.;
4. El planificador es responsable de la programación de los recursos y programa los Pods para las máquinas correspondientes de acuerdo con la estrategia de programación predeterminada;
5. Kubelet se encarga de mantener el ciclo de vida del contenedor, y también se encarga de la gestión de Volumen (CVI) y red (CNI);
6. El tiempo de ejecución del contenedor es responsable de la gestión de imágenes y la operación real de Pod y contenedor (CRI);
7. kube-proxy es responsable de proporcionar detección de servicios y balanceo de carga dentro del clúster para el Servicio;

concepto de diseño 2.2 k8s

Principios de diseño de API

El objeto API es la unidad de operación de administración en el clúster k8s. Cada vez que el sistema de clúster k8s admite una nueva función e introduce una nueva tecnología, el objeto API correspondiente debe introducirse nuevamente para admitir la gestión y operación de la función. Por ejemplo, el objeto API correspondiente al conjunto de réplicas Conjunto de réplicas es RS.

k8s adopta operaciones declarativas, yaml definido por el usuario, y la API de k8s es responsable de crear. Cada objeto tiene tres categorías de atributos: metadatos, especificación de especificación y estado de estado. Los metadatos se usan para identificar los objetos de la API, y cada objeto tiene al menos 3 metadatos: espacio de nombres, nombre y uid; además, hay varias etiquetas que se usan para identificar y hacer coincidir diferentes objetos, como los usuarios. Puede usar la etiqueta env para identificar y distinguir diferentes entornos de implementación de servicios, y usar env=dev, env=testing y env=production para identificar diferentes servicios para desarrollo, prueba y producción. La especificación describe el estado ideal (estado deseado) que el usuario espera que logre el sistema distribuido en el clúster k8s. Por ejemplo, el usuario puede establecer la cantidad esperada de réplicas de pod en 3 a través del controlador de replicación; el estado describe el estado actual real estado del sistema (Estado), por ejemplo, el número real actual de copias de Pod en el sistema es 2; entonces la lógica del programa actual del controlador de replicación es iniciar automáticamente un nuevo Pod, esforzándose por alcanzar el número de copias a 3 .

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

• apiVersion: la versión de la API de Kubernetes que creó el objeto

• tipo: ¿qué tipo de objeto crear?

• metadatos: datos que identifican de forma única el objeto, incluidos el nombre (cadena), el UID y el espacio de nombres (opcional)

Cree una implementación con el archivo .yaml anterior mediante el comando kubectl create en kubectl. Pase ese archivo .yaml como parámetro. Por ejemplo:

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

Objetos k8s comunes: pod, controlador de replicación (RC), conjunto de réplicas (conjunto de réplicas, RS), implementación, servicio, trabajo, volumen, volumen persistente y reclamo de volumen persistente (volumen persistente, PV, reclamo de volumen persistente, PVC), nodo ( Nodo), ConfigMap, Endpoint , etc.

 

Principios de diseño del mecanismo de control

• Cada módulo puede degradar correctamente los servicios cuando sea necesario. La lógica de control solo debe depender del estado actual. Esto es para garantizar la estabilidad y confiabilidad de los sistemas distribuidos. Para los sistemas distribuidos que a menudo tienen errores locales, si la lógica de control solo depende del estado actual, es muy fácil restaurar un sistema temporalmente defectuoso a un estado normal, porque solo necesita poner el Una vez que el sistema se restablece a un estado estable, puede estar seguro de que toda la lógica de control del sistema comenzará a funcionar de manera normal.

• Asume cualquier posibilidad de error, y hazlo con tolerancia. Los errores locales y temporales son un evento de alta probabilidad en un sistema distribuido. Los errores pueden provenir de fallas del sistema físico, y las fallas del sistema externo también pueden provenir de errores de código en el propio sistema. En realidad, es difícil garantizar la estabilidad del sistema confiando en códigos autoimplementados sin errores. Por lo tanto, es necesario diseñar fallas. procesamiento tolerante para cualquier posible error.

• Trate de evitar máquinas de estado complejas y la lógica de control no debe depender de estados internos que no se pueden monitorear. Debido a que cada subsistema de un sistema distribuido no se puede sincronizar estrictamente dentro del programa, si la lógica de control de los dos subsistemas se afecta entre sí, entonces los subsistemas deben poder acceder entre sí al estado que afecta la lógica de control, de lo contrario, solo equivale a la existencia de una lógica de control incierta en el sistema.

• Suponga que cualquier operación puede ser rechazada por cualquier objeto de operación, o incluso mal analizada. Debido a la complejidad del sistema distribuido y la relativa independencia de cada subsistema, los diferentes subsistemas a menudo provienen de diferentes equipos de desarrollo, por lo que no puede esperar que otro subsistema maneje cualquier operación de manera correcta. ocurre un error, los errores de nivel de operación no afectarán la estabilidad del sistema.

• Cada módulo se puede restaurar automáticamente después de un error. Dado que es imposible garantizar que cada módulo del sistema esté siempre conectado en un sistema distribuido, cada módulo debe tener la capacidad de autorreparación y asegurarse de que no se bloquee porque no se puede conectar a otros módulos.

• Cada módulo puede degradar los servicios con gracia cuando sea necesario. El llamado Graceful Downgrade Service es un requisito para la robustez del sistema, es decir, se requiere distinguir claramente entre funciones básicas y funciones avanzadas al diseñar e implementar módulos, de modo que las funciones básicas no dependan de funciones avanzadas. funciones, y al mismo tiempo asegurarse de que no habrá problemas debido a las funciones avanzadas.Una falla hace que todo el módulo se bloquee. El sistema implementado de acuerdo con este concepto también es más fácil de agregar rápidamente nuevas funciones avanzadas, pensando que no hay necesidad de preocuparse por la introducción de funciones avanzadas que afectan las funciones básicas originales.

 

3. Gestión de recursos

La forma en que la plataforma de contenedores en la nube administra con precisión los recursos disponibles para los inquilinos juega un papel vital en la disponibilidad, la capacidad de mantenimiento y la facilidad de uso de la plataforma, y ​​es la piedra angular para que la plataforma de contenedores en la nube brinde a los usuarios una gestión rica de microservicios. En el campo de la computación en la nube, los recursos se pueden dividir en tres categorías: recursos informáticos, recursos de red y recursos de almacenamiento, que también pueden denominarse nubes informáticas, nubes de red y nubes de almacenamiento, respectivamente.

3.1 Gestión de recursos informáticos

espacio de nombres

En el clúster k8s, la entidad que proporciona recursos informáticos se denomina Nodo. ​​El nodo puede ser un servidor de máquina física o un servidor de máquina virtual. Cada nodo proporciona recursos como CPU, memoria, disco y red. Cada Nodo (nodo) tiene algunos servicios necesarios para ejecutar el pod y es administrado por el componente Maestro. Los servicios en el nodo Nodo incluyen Docker, kubelet y kube-proxy.

Al introducir Namespace, k8s divide aún más el clúster en múltiples grupos virtuales para la administración. La "partición" realizada por Namespace es lógica y no está vinculada a los recursos reales. Se utiliza en escenarios de múltiples inquilinos para realizar la partición de recursos y el uso de la maximización de recursos.

 

La mayoría de los recursos de Kubernetes (como pods, servicios, controladores de replicación u otros) están en algún espacio de nombres, pero los recursos del espacio de nombres en sí no están en el espacio de nombres. Y los recursos de bajo nivel (como Node y persistenteVolumes) no están en ningún espacio de nombres. Los eventos son una excepción: pueden o no tener un espacio de nombres, según el objeto Eventos.

Por debajo

Pod es la unidad básica más pequeña/simple creada o implementada por Kubernetes, y un Pod representa un proceso que se ejecuta en el clúster.

Un pod encapsula un contenedor de aplicaciones (o varios contenedores), recursos de almacenamiento, una IP de red independiente y opciones de políticas para administrar y controlar cómo se ejecuta el contenedor. Un pod representa una unidad de implementación: una instancia de una sola aplicación en Kubernetes, que puede consistir en un solo contenedor o recursos compartidos por varios contenedores.

Cada Pod es una instancia única de la aplicación en ejecución. Si necesita escalar la aplicación horizontalmente (por ejemplo, para ejecutar varias instancias), debe usar varios Pods, un Pod por instancia. En Kubernetes, esto a menudo se denomina replicación. Los pods de replicación generalmente son creados y administrados por el controlador. El controlador puede crear y administrar múltiples pods, proporcionando administración de réplicas, actualizaciones continuas y capacidades de recuperación automática a nivel de clúster. Por ejemplo, si falla un nodo, el controlador puede programar automáticamente los pods en el nodo para otros nodos en buen estado.

 

Envase

Docker en sí es relativamente pesado. La OCI (Iniciativa de contenedor abierto ) nació en 2015. Define estándares de imagen, estándares de tiempo de ejecución y estándares de distribución. Dado que k8s en sí no tiene la capacidad de crear contenedores, llama interfaces y comandos API de tiempo de ejecución de contenedor a través del componente kubelet Para crear contenedores, la relación entre Kubernetes y los tiempos de ejecución de contenedores es histórica y compleja. Pero a medida que Kubernetes abandona Docker, los tiempos de ejecución principales actuales son principalmente contenedores y CRI-O. 

 

El modo "un contenedor por pod" es el uso más común de Kubernetes, y un pod también puede tener varios contenedores.

Tres niveles de gestión de recursos informáticos

En k8s se puede gestionar la configuración y limitación de recursos desde los tres niveles de Namespace, Pod y Container. Por ejemplo:

• El nivel del contenedor se puede configurar a través de Solicitud de recursos y Límites de recursos

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
spec:
  containers:
  - name: memory-demo-3-ctr
    image: vish/stress
    resources:
      limits:
        memory: "1000Gi"
      requests:
        memory: "1000Gi"
    args:
    - -mem-total
    - 150Mi
    - -mem-alloc-size
    - 10Mi
    - -mem-alloc-sleep
    - 1s

• El nivel del Pod se puede configurar creando un objeto LimitRange, de modo que los contenedores contenidos en el Pod se puedan configurar de manera uniforme

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "4"
      memory: 2Gi
    min:
      cpu: 200m
      memory: 6Mi
    maxLimitRequestRatio:
      cpu: 3
      memory: 2
    type: Pod
  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi
    maxLimitRequestRatio:
      cpu: 5
      memory: 4
    type: Container

• El nivel de espacio de nombres puede proporcionar un límite de uso de recursos general a través de la configuración del objeto de recurso ReSourceQuota. Este límite puede ser el límite superior de la cantidad total de recursos informáticos utilizados por todos los Pods, o el límite superior de la cantidad total de objetos de un cierto tipo para todos los pods (incluida la cantidad de objetos como Pod, RC, Service, Secret, ConfigMap y PVC que se pueden crear)

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
  request.cpu: "4"
  request.memory: 8GB
  limit.memory:16GB
  pods: "2"

3.2 Gestión de recursos de red

El modelo ip de k8s

node Ip  : la ip del nodo nodo, que es la ip física.

pod Ip : La ip del pod, es decir, la ip del contenedor docker, es una ip virtual.

cluster Ip : la ip del servicio, que es una ip virtual. Proporcione una IP virtual dentro del clúster para el acceso al Pod. El principio de realización es a través de las reglas de firewall de Linux, que pertenece a la tecnología NAT. Al acceder a ClusterIP, la solicitud se reenviará a la instancia de back-end. Si hay varias instancias de back-end, el equilibrio de carga se logrará por cierto. El valor predeterminado es el método de entrenamiento por turnos.

Solución de red de contenedores entre hosts

En el sistema k8s, un principio básico del diseño del modelo de red k8s: cada pos tiene una dirección IP independiente y se supone que todos los pods están en un espacio de red plano que se puede conectar directamente, independientemente de si se están ejecutando en el mismo Nodo (host), se puede acceder directamente a través de la IP de la otra parte. Pero k8s en sí mismo no proporciona una solución de red de contenedores entre hosts. Los entornos de nube pública (como AWS, Azure y GCE) suelen proporcionar soluciones de red de contenedores, pero en los entornos de nube privada, las plataformas de nube de contenedores aún deben proporcionar varias soluciones de red de contenedores para diferentes inquilinos.

Actualmente, establecer una red superpuesta para contenedores es la solución de red de contenedores entre hosts más convencional. Una red superpuesta se refiere a encapsular paquetes IP originales a través de algún protocolo de red adicional para formar una red lógica sin cambiar la configuración de red original. En la plataforma k8s, se recomienda desplegar la red de contenedores a través del complemento CNI.

CNI (Container Network Interface) es un proyecto de la Fundación CNCF. Consiste en un conjunto de especificaciones y bibliotecas para configurar la interfaz de red del contenedor. Define la especificación de la interfaz entre el entorno operativo del contenedor y el complemento de red, y solo se preocupa por el contenedor La configuración de la red en el momento de la creación y la destrucción del contenedor son la liberación de los recursos de la red, y un contenedor puede vincular múltiples complementos de red CNI para unirse a la red, como se muestra en la figura a continuación.

 

En la actualidad, los métodos de implementación de complementos CNI que comparan procesos incluyen Flannel, Calico, macvlan, Open vSwitch y enrutamiento directo.

Ingreso

En el clúster k8s, la aplicación proporciona servicios en forma de Servicio de forma predeterminada, y kube-proxy implementa la función de equilibrador de carga de Servicio a contenedor, como se muestra en la siguiente figura para definir un servicio mysql:

kind: Service
apiVersion: v1
metadata:
  name: mysql-master
spec:
  selector:
    app: mysql-master
  ports:
      port: 3306
      targetPort: 3306

En este momento, no se puede acceder al Servicio fuera del clúster. Para los servicios que requieren clientes fuera del clúster k8s para brindar servicios, los servicios se pueden exponer a través de Ingress y, si el clúster (red) tiene un nombre de dominio real, el Servicio también se puede conectar directamente al nombre de dominio.

k8s combina la definición de un objeto de recurso de ingreso con un controlador de ingreso específico para implementar un balanceador de carga de capa 7. Cuando el controlador de entrada reenvía las solicitudes de los clientes al servicio de backend, omite la función de equilibrador de carga de capa 4 proporcionada por kube-proxy y las reenvía directamente a los pods de backend (puntos finales) del servicio para mejorar la eficiencia de reenvío de la red.

 

La figura anterior muestra un ejemplo típico de Ingress de enrutamiento de capa HTTP, donde:

• El acceso a http://mywebsite.com/api se enrutará al Servicio denominado "api" en el backend;

• El acceso a http://mywebsite.com/web se enrutará al Servicio con el nombre de backend "web";

• El acceso a http://mywebsite.com/doc se enrutará al Servicio con el nombre de backend "doc".

La siguiente es una definición de política de entrada típica: el controlador de entrada reenvía la solicitud de acceso a la dirección de destino http://mywebsite.com/demo a la aplicación web (webapp:8080/demo) servida dentro del clúster

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
   name: mywebsite-ingress
spec:
   rules:
   -host：mywebsite.com
    http:
       paths:
      - path: /demo
          backend:
           serviceName: webapp
           servicePort: 8080

Los controladores de entrada comúnmente utilizados incluyen: Nginx, HAProxy, Traefik, apisix, etc.

3.3 Recursos de almacenamiento

Tipos de volumen admitidos por k8s

Directorio temporal (emptyDir)

Con el uso de emptyDir, cuando se asigna un Pod a un Nodo, se creará un EmptyDir, y mientras el Pod en el Nodo siga funcionando, el Volumen siempre existirá. Cuando el Pod (por cualquier motivo) se elimine del Nodo, el directorio vacío también se eliminará al mismo tiempo y los datos almacenados también se eliminarán de forma permanente. Nota: La eliminación de un contenedor no afecta a emptyDir.

clase de configuración

• ConfigMap: monte la información del archivo de configuración almacenada en el objeto de recurso ConfigMap en un directorio determinado del contenedor

• Secreto: monte la clave de contraseña y otra información almacenada en el objeto de recurso Secreto en un archivo en el contenedor

• DownwardApI: inyecta los datos de la API descendente en el contenedor en forma de variables de entorno o archivos

• gitRepo: monte una base de código Git en un directorio en el contenedor

clase de almacenamiento local

• hostPath: monte el directorio o archivo del host en el contenedor para su uso

• local: introducido desde la versión v1.9, el almacenamiento local se proporciona al contenedor en forma de PV, y puede administrar el espacio de almacenamiento

clase de almacenamiento compartido

• PV (Volumen persistente): defina el almacenamiento compartido como un "volumen de almacenamiento persistente" que pueden compartir varios contenedores

• PVC (reclamo de volumen persistente): la "aplicación" de un usuario para los recursos de almacenamiento. El objeto de la aplicación de PVC es PV. Una vez que la aplicación es exitosa, la aplicación puede usar el volumen de almacenamiento compartido como un directorio local. La siguiente figura es una definición ymal de objeto PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
  annotations:
        "volume.alpha.kubernetes.io/node-affinity": '{
            "requiredDuringSchedulingIgnoredDuringExecution": {
                "nodeSelectorTerms": [
                    { "matchExpressions": [
                        { "key": "kubernetes.io/hostname",
                          "operator": "In",
                          "values": ["example-node"]
                        }
                    ]}
                 ]}
              }'
spec:
    capacity:
      storage: 100Gi
    accessModes:
    - ReadWriteOnce
    persistentVolumeReclaimPolicy: Delete
    storageClassName: local-storage
    local:
      path: /mnt/disks/ssd1

PV y PVC

 

El ciclo de vida de la relación entre PV y PVC se muestra en la figura anterior. El modo de suministro de almacenamiento compartido k8s incluye el modo estático (estático) y el modo dinámico (dinámico). El resultado del suministro de recursos es la creación de un buen PV. La creación manual de PV por parte del personal de operación y mantenimiento es estática, y la clave para el modo dinámico es StorageClass, que se utiliza para crear plantillas de PV.

Para crear una StorageClass, debe definir los atributos de PV, como el tipo de almacenamiento, el tamaño, etc.; además, debe usar un complemento de almacenamiento para crear dicho PV. El efecto final es que el usuario envía un PVC, que especifica el tipo de almacenamiento. Si coincide con la clase de almacenamiento que definimos, se creará y enlazará automáticamente un PV.

La siguiente figura crea un objeto StorageClass a través de ymal

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs    // 存储分配器
parameters:
  type: gp2
reclaimPolicy: Retain   // 回收策略
mountOptions:
  - debug

La relación operativa entre StorageClass y PV y PVC se muestra en la siguiente figura:

 

CSI

La relación entre CSI (Interfaz de almacenamiento de contenedores) y k8s es algo similar a la de CNI. CSI tiene como objetivo sugerir un conjunto de interfaces de acceso de almacenamiento estándar entre contenedores y almacenamiento compartido. Antes de su nacimiento, experimentó el método "en árbol" y el modo FlexVolume.

La especificación CSI desacopla por completo el código del proveedor de almacenamiento del código k8s, y el propio proveedor de almacenamiento mantiene el código del complemento de almacenamiento.

 

Algunos contenedores sidecar proporcionados directamente por K8S official interactúan directamente con kube-apiserver, y estos sidecars se pueden implementar directamente. Estos contenedores sidecar (principalmente los tres componentes principales de la figura anterior) escuchan sus CRD correspondientes, activan las operaciones correspondientes y llaman directamente a las interfaces del controlador CSI (como CreateVolume(), NodePublishVolme(), etc.) a través del UDS interfaz para implementar el volumen.

 

Para desarrollar Drivers CSI generalmente se implementan los siguientes servicios:

• Servicio de identidad CSI

Permite a las personas que llaman (componentes de Kubernetes y contenedores sidecar de CSI) identificar el controlador y las funciones opcionales que admite.

• Servicio de nodo CSI

Se requieren NodePublishVolume, NodeUnpublishVolume y NodeGetCapabilities.

El método requerido permite a la persona que llama hacer que el volumen esté disponible en la ruta especificada y descubrir qué funciones opcionales admite el controlador.

• Servicio de controlador CSI

Implementar las interfaces CreateVolume y DeleteVolume

3.4 Esquema de gestión de recursos de múltiples clústeres: federación de clústeres (Federación)

Federation es un subproyecto de Kubernetes. Su objetivo de diseño es administrar múltiples clústeres de Kubernetes de manera unificada e implementar aplicaciones de usuario en centros de datos en diferentes regiones. Federation presenta un plano de control ubicado en el clúster de Kubernetes, protege los subclústeres k8s de back-end y proporciona a los clientes un portal de administración unificado, como se muestra en la siguiente figura:

 

El plano de control de federación "encapsula" la función de maestro de varios clústeres k8s y proporciona un maestro unificado, que incluye el servidor API de federación y el administrador del controlador de federación. Los usuarios pueden operar federación como si estuvieran operando un solo clúster y unificar el DNS y ConfigMap de todos k8s clusters. , y guarde los datos en una base de datos etcd centralizada.

escribir a los lectores

Para los principiantes de k8s, la primera impresión de k8s debería ser que hay muchos conceptos y sustantivos. La guía autorizada de kubernetes: combate en la nube de contenedores de nivel empresarial comienza desde la perspectiva de la práctica empresarial, describe la evolución de la tecnología y proporciona una comparación de diferentes implementaciones de tecnología en muchos escenarios. En combinación con la comunidad china k8s, este libro se puede utilizar como herramienta de aprendizaje para los libros introductorios de k8s. Este artículo es en realidad una nota de lectura de este libro. El artículo se expande desde las tres direcciones de recursos informáticos, recursos de red y recursos de almacenamiento, e introduce algunos conceptos y objetos comunes en k8s. Debido a problemas de espacio, muchos conceptos importantes no se introducen en detalle en el artículo, los lectores pueden realizar un estudio complementario de acuerdo con su propia situación. Los componentes principales y los principios de funcionamiento de k8s se lanzarán en el futuro.

{{o.nombre}}

{{m.nombre}}