ProHoster > Blog > noticias de internet > Lanzamiento de Kubernetes 1.18, un sistema para gestionar un cluster de contenedores aislados

Lanzamiento de Kubernetes 1.18, un sistema para gestionar un cluster de contenedores aislados

publicado lanzamiento de la plataforma de orquestación de contenedores Kubernetes 1.18, que le permite administrar un clúster de contenedores aislados en su conjunto y proporciona mecanismos para implementar, mantener y escalar aplicaciones que se ejecutan en contenedores. El proyecto fue creado originalmente por Google, pero luego transferido a un sitio independiente supervisado por la Fundación Linux. La plataforma se posiciona como una solución universal desarrollada por la comunidad, no vinculada a sistemas individuales y capaz de trabajar con cualquier aplicación en cualquier entorno de nube. El código de Kubernetes está escrito en Go y distribuido por licenciado bajo Apache 2.0.

Proporciona funciones para implementar y administrar infraestructura, como mantenimiento de bases de datos DNS, equilibrio de carga,
distribución de contenedores entre los nodos del clúster (migración de contenedores dependiendo de los cambios en la carga y las necesidades de servicio), comprobaciones de estado a nivel de aplicación, gestión de cuentas, actualización y escalado dinámico de un clúster en ejecución, sin detenerlo. Es posible implementar grupos de contenedores con operaciones de actualización y deshacer para todo el grupo a la vez, así como la división lógica del clúster en partes con división de recursos. Hay soporte para la migración dinámica de aplicaciones, para el almacenamiento de datos se pueden utilizar tanto sistemas de almacenamiento local como de red.

La versión Kubernetes 1.18 incluye 38 cambios y mejoras, de los cuales 15 se han movido al estado estable y 11 al estado beta. Se proponen 12 nuevos cambios en el estado alfa. Al preparar la nueva versión, se hicieron esfuerzos iguales tanto para perfeccionar diversas funciones como para estabilizar las capacidades experimentales, así como para agregar nuevos desarrollos. Principales cambios:

  • Kubectl
    • Añadido por Una versión alfa del comando "kubectl debug", que le permite simplificar la depuración en pods lanzando contenedores efímeros con herramientas de depuración.
    • Declarado estable el comando "kubectl diff", que le permite ver qué cambiará en el clúster si aplica el manifiesto.
    • Remoto todos los generadores del comando "kubectl run", excepto el generador para ejecutar un solo pod.
    • Cambiado flag “--dry-run”, dependiendo de su valor (cliente, servidor y ninguno), la ejecución de prueba del comando se realiza en el lado del cliente o del servidor.
    • código kubectl resaltado a un repositorio separado. Esto permitió desacoplar kubectl de las dependencias internas de Kubernetes y facilitó la importación de código a proyectos de terceros.
  • Ingreso
    • Comenzó cambiando el grupo de API para Ingress a networking.v1beta1.
    • Adicional nuevos campos:
      • pathType, que le permite especificar cómo se comparará la ruta en la solicitud
      • IngressClassName es un reemplazo de la anotación kubernetes.io/ingress.class, que se declara obsoleta. Este campo especifica el nombre del objeto especial InressClass
    • Добавлен un objeto IngressClass, que indica el nombre del controlador de ingreso, sus parámetros adicionales y el signo de su uso por defecto
  • Service
    • Adicional el campo AppProtocol, en el que puede especificar qué protocolo utiliza la aplicación
    • Traducido en estado beta y habilitado de forma predeterminada EndpointSlicesAPI, que es un reemplazo más funcional para los Endpoints normales.
  • Red
    • Apoyar IPv6 ha pasado al estado beta.
  • Discos permanentes. La siguiente funcionalidad ha sido declarada estable:
  • Configuración de la aplicación
    • A ConfigMap y objetos secretos adicional nuevo campo "inmutable". Establecer el valor del campo en verdadero evita la modificación del objeto.
  • Planificador
    • Añadido por capacidad de crear perfiles adicionales para kube-scheduler. Si antes era necesario ejecutar programadores independientes adicionales para implementar algoritmos de distribución de pods no estándar, ahora es posible crear conjuntos de configuraciones adicionales para el programador estándar y especificar su nombre en el mismo campo del pod ".spec.schedulerName". Estado: alfa.
    • Desalojo basado en corrupción declarado estable
  • Escalado
    • Añadido por la capacidad de especificar en el manifiesto HPA el grado de agresividad al cambiar el número de pods en ejecución, es decir, cuando aumenta la carga, lanzar N veces más instancias a la vez.
  • kubelet
    • Gerente de topología recibió el estado beta. La característica permite la asignación de NUMA, lo que evita la degradación del rendimiento en sistemas de múltiples sockets.
    • Estado beta recibido Función PodOverhead, que le permite especificar en RuntimeClass la cantidad adicional de recursos necesarios para ejecutar el pod.
    • Expandido soporte para HugePages, en estado alfa se agregó aislamiento a nivel de contenedor y soporte para múltiples tamaños de páginas enormes.
    • Eliminado punto final para métricas /metrics/resource/v1alpha1, en su lugar se utiliza /metrics/resource
  • API
    • Por fin Se eliminó la capacidad de utilizar el grupo API obsoleto apps/v1beta1 y extensions/v1beta1.
    • Aplicar del lado del servidor actualizado al estado beta2. Esta mejora traslada la manipulación de objetos de kubectl al servidor API. Los autores de la mejora afirman que esto solucionará muchos errores existentes que no se pueden corregir en la situación actual. También agregaron una sección “.metadata.managedFields”, en la que proponen almacenar el historial de cambios de objetos, indicando quién, cuándo y qué cambió exactamente.
    • Anunciado API CertificateSigningRequest estable.
  • Soporte de plataforma Windows.

Fuente: opennet.ru

Añadir un comentario