lanzamiento de la plataforma de orquestación de contenedores , que permite gestionar como un todo un clúster de contenedores aislados y proporciona mecanismos para implementar, mantener y escalar aplicaciones ejecutadas en contenedores. El proyecto fue originalmente creado por Google, pero luego se trasladó a una plataforma independiente administrada por la Linux Foundation. La plataforma se posiciona como una solución universal desarrollada por la comunidad, no vinculada a sistemas específicos y capaz de trabajar con cualquier aplicación en cualquier entorno en la nube. El código de Kubernetes está escrito en Go y bajo la licencia Apache 2.0.
se proporcionan funciones para implementar y gestionar la infraestructura, tales como el mantenimiento de una base de datos DNS, balanceo de carga,
distribución de contenedores entre nodos del clúster (migración de contenedores según los cambios en la carga y las necesidades de los servicios), verificación de estado a nivel de aplicaciones, gestión de cuentas, actualización y escalado dinámico del clúster en funcionamiento, sin detenerlo. Es posible implementar grupos de contenedores realizando operaciones de actualización y reversión de cambios simultáneamente para todo el grupo, así como una división lógica del clúster en partes con separación de recursos. También se admite la migración dinámica de aplicaciones, para las cuales los datos pueden almacenarse tanto en almacenamiento local como en sistemas de almacenamiento en red.
La versión 1.18 de Kubernetes incluye 38 cambios y mejoras, de las cuales 15 han sido promovidas a estado estable y 11 a estado beta. 12 cambios nuevos se han propuesto en estado alfa. Para la preparación de la nueva versión, se han dedicado esfuerzos equitativos tanto a mejorar diversas funcionalidades y estabilizar características experimentales como a añadir nuevos desarrollos. Principales cambios:
- Kubectl
- versión alfa del comando «kubectl debug», que simplifica la depuración en pods mediante la ejecución de contenedores efímeros con herramientas de depuración.
- comando «kubectl diff», que permite ver qué cambiará en el clúster si se aplica un manifiesto.
- todos los generadores del comando «kubectl run», excepto el generador para iniciar un único pod.
- el flag «—dry-run», dependiendo de su valor (client, server y none) ejecuta de manera provisional el comando en el lado del cliente o del servidor.
- Código kubectl en un repositorio independiente. Esto ha permitido desacoplar kubectl de las dependencias internas de kubernetes y ha facilitado la importación de código en proyectos externos.
- Ingress
- cambio del grupo API para Ingress a networking.v1beta1.
- nuevos campos:
- pathType, que permite especificar cómo se comparará la ruta en la solicitud
- IngressClassName — reemplazo de la anotación kubernetes.io/ingress.class, que ha sido declarada obsoleta. En este campo se especifica el nombre del objeto especial IngressClass
- el objeto IngressClass, donde se especifica el nombre del controlador de ingreso, sus parámetros adicionales y la indicación de su uso como predeterminado
- Servicio
- el campo AppProtocol, en el que se puede indicar qué protocolo utiliza la aplicación
- a estado beta y se ha incluido por defecto EndpointSlicesAPI, que es un reemplazo más funcional de los Endpoints convencionales.
- Red
- IPv6 ha pasado a estado beta.
- Discos persistentes. Se ha declarado estable la siguiente funcionalidad:
- Configuración de la aplicación
- En los objetos ConfigMap y Secret nuevo campo «immutable». Establecer el valor del campo en true impide la modificación del objeto.
- Programador
- posibilidad de crear perfiles adicionales para kube-scheduler. Si anteriormente se requería ejecutar planificadores adicionales por separado para implementar algoritmos de distribución no estándar de pods, ahora se ha introducido la posibilidad de crear conjuntos adicionales de configuraciones para el planificador estándar y especificar su nombre en el mismo campo del pod «.spec.schedulerName». Estado — alfa.
- ha sido declarado estable
- Escalado
- la posibilidad de indicar en el manifiesto HPA el grado de agresividad al modificar la cantidad de pods en ejecución, es decir, al aumentar la carga, iniciar de inmediato N veces más instancias.
- ha comenzado a utilizar
- ha alcanzado estado beta. La función incluye distribución NUMA, lo que permite evitar la degradación del rendimiento en sistemas de múltiples sockets.
- Estado beta la función PodOverhead, que permite especificar en RuntimeClass una cantidad adicional de recursos necesaria para ejecutar un pod.
- Soporte para HugePages, se agregó la aislación a nivel de contenedor en estado alfa y se admite múltiples tamaños de hugepages.
- endpoint para métricas /metrics/resource/v1alpha1, en su lugar se utiliza /metrics/resource
- API
- se ha eliminado la posibilidad de usar los grupos de API obsoletos apps/v1beta1 y extensions/v1beta1.
- se elevó al estado beta2. Esta mejora transfiere la manipulación de objetos de kubectl al servidor API. Los autores de la mejora afirman que permitirá corregir numerosos errores existentes que no se pueden solucionar en la situación actual. También agregaron un campo ‘.metadata.managedFields’, donde proponen almacenar el historial de cambios del objeto, indicando quién, cuándo y qué exactamente se modificó.
- API de CertificateSigningRequest estable.
- Soporte para la plataforma Windows.
- Continúa ampliándose el soporte para nodos Windows. Se han agregado versiones alfa:
- Se ha trasladado al estado estable el soporte para
- Continúa ampliándose el soporte para nodos Windows. Se han agregado versiones alfa:
Fuente: opennet.ru
