Kubernetes -
1.14 será lanzado esta noche. De acuerdo con la tradición que se ha desarrollado para nuestro blog, estamos hablando de cambios clave en la nueva versión de este maravilloso producto de Código Abierto.
La información utilizada para preparar este material se toma de
la tabla de seguimiento de mejoras de Kubernetes ,
CHANGELOG-1.14 y cuestiones relacionadas, solicitudes de extracción, Propuestas de mejora de Kubernetes (KEP).
ACTUALIZACIÓN (26 de marzo): el
anuncio oficial de lanzamiento también apareció en el blog de K8.
Comencemos con la importante introducción del ciclo de vida del clúster SIG: los clústeres
dinámicos de conmutación por error de Kubernetes (y más precisamente, las implementaciones de alta disponibilidad autohospedadas) ahora se
pueden crear utilizando los comandos
kubeadm (
init y
join ) habituales (en el contexto de clusters de un solo nodo). En resumen, para esto:
- los certificados utilizados por el clúster se transfieren a secretos;
- para la posibilidad de usar el clúster etcd dentro del clúster K8s (es decir, deshacerse de la dependencia externa que ha existido hasta ahora), se usa el operador etcd ;
- Se documentan las configuraciones recomendadas para un equilibrador de carga externo que proporciona una configuración tolerante a fallas (en el futuro, se planifica la posibilidad de falla de esta dependencia, pero no en esta etapa).
Arquitectura de clúster de Kubernetes HA construida con kubeadmLos detalles de la implementación se pueden encontrar en la
propuesta de diseño . Esta característica era muy esperada: la versión alfa se esperaba en K8s 1.9, pero solo apareció ahora.
API
El comando de
apply y la
administración de objetos en general
declarativa se mueven de
kubectl a un servidor. Los propios desarrolladores explican brevemente su decisión al decir que
kubectl apply es una parte fundamental del trabajo con configuraciones en Kubernetes, sin embargo, está "lleno de errores y es difícil de solucionar", y por lo tanto esta funcionalidad necesita restaurarse a la normalidad y transferirse al plano de control. Ejemplos simples e ilustrativos de los problemas de hoy:
Los detalles de la implementación se encuentran en
KEP . La disponibilidad actual es la versión alfa (la promoción a beta está prevista para la próxima versión de Kubernetes).
En la versión alfa, la
capacidad de usar el esquema OpenAPI v3 para
crear y publicar la documentación de OpenAPI en CustomResources (CR) utilizada para validar los recursos K8 definidos por el usuario (del lado del servidor) (CustomResourceDefinition, CRD) está disponible. La publicación de OpenAPI para CRD permite a los clientes (por ejemplo,
kubectl ) realizar la validación de su lado (como parte de
kubectl create y
kubectl apply ) y emitir documentación de acuerdo con el esquema (
kubectl explain ). Los detalles están en el
KEP .
Los registros preexistentes
ahora se abren con el indicador
O_APPEND (en lugar de
O_TRUNC ) para evitar la pérdida de registros en algunas situaciones y para la conveniencia de registros truncados con utilidades de rotación externas.
También en el contexto de la API de Kubernetes, se puede observar que en el
PodSandbox y
PodSandboxStatus campo
PodSandboxStatus para tener en cuenta la información sobre
RuntimeClass en el pod (lea más sobre esto en el texto sobre
el lanzamiento de Kubernetes 1.12 , donde esta clase apareció como una versión alfa), y en Admission Webhooks
implementó la capacidad de determinar qué versiones de
AdmissionReview admiten. Finalmente, en las reglas de Admisión de Webhooks, ahora
puede limitar el alcance de su aplicación al espacio de nombres y al alcance del clúster.
Instalaciones de almacenamiento
PersistentLocalVolumes que tienen estado beta desde el lanzamiento de
K8s 1.10 se
declaran estables (GA): esta puerta de características ya no se desactivará y se eliminará en Kubernetes 1.17.
Se ha desarrollado la capacidad de utilizar las variables de entorno de la denominada
API descendente (por ejemplo, el nombre del pod) para los nombres de directorio montados como
subPath , en forma de un nuevo campo
subPathExpr , con el que ahora se determina el nombre de directorio deseado. Inicialmente, la función apareció en Kubernetes 1.11, pero para 1.14 permaneció en el estado de versión alfa.
Al igual que con la versión anterior de Kubernetes, se introducen muchos cambios significativos para el CSI (Interfaz de almacenamiento de contenedores) que evoluciona rápidamente:
CSI
El soporte para cambiar el tamaño del soporte para volúmenes CSI ha estado disponible (como parte de la versión alfa). Para usarlo, deberá habilitar la puerta de características llamada
ExpandCSIVolumes , así como la presencia de soporte para esta operación en un controlador CSI específico.
Otra característica para CSI en la versión alfa es la
capacidad de referirse directamente (es decir, sin usar PV / PVC) a volúmenes CSI como parte de la especificación de pod. Esto
elimina la restricción de usar CSI como almacenes de datos exclusivamente remotos , abriéndoles la puerta al mundo de
los volúmenes efímeros locales . Para usar (
ejemplo de la documentación ), debe habilitar la puerta de la característica
CSIInlineVolume .
Ha habido progreso en los "componentes internos" de Kubernetes relacionados con CSI, que no son tan notorios para los usuarios finales (administradores del sistema) ... Por el momento, los desarrolladores están obligados a admitir dos versiones de cada complemento de almacenamiento: uno "a la antigua usanza", dentro de la base de código de K8 (en -tree), y el segundo - como parte del nuevo CSI
(lea más sobre esto, por ejemplo, aquí ) . Esto causa inconvenientes comprensibles que deben abordarse a medida que el CSI como tal se estabiliza. Simplemente desaprobar la API en desuso de los complementos en árbol no es posible debido a la
política de Kubernetes correspondiente .
Todo esto llevó al hecho de que la versión alfa alcanzó el
proceso de migración del código interno de los complementos implementados como in-trees a los complementos CSI, debido a que las preocupaciones de los desarrolladores se reducirán a admitir una versión de sus complementos, y se preservará la compatibilidad con las API antiguas y se podrán declarar obsoleto como de costumbre. Se espera que en la próxima versión de Kubernetes (1.15), se migren todos los complementos del proveedor de la nube, la implementación recibirá el estado beta y se activará en las instalaciones predeterminadas de K8s. Vea la
propuesta de diseño para más detalles. Esta migración también resultó en el
rechazo de restricciones para volúmenes definidos por proveedores específicos de la nube (AWS, Azure, GCE, Cinder).
Además, el soporte para dispositivos de bloque CSI (
CSIBlockVolume ) se ha
convertido a beta.
Nodos / Kubelet
Introdujo una versión alfa del
nuevo punto final en Kubelet, diseñado para
devolver métricas para los recursos principales . En términos generales, si Kubelet solía obtener estadísticas sobre el uso de contenedores de cAdvisor, ahora estos datos provienen del tiempo de ejecución del contenedor a través de la CRI (Interfaz de tiempo de ejecución del contenedor), pero se preserva la compatibilidad con versiones anteriores de Docker. Anteriormente, las estadísticas recopiladas en Kubelet se proporcionaban a través de la API REST, pero ahora utiliza el punto final ubicado en
/metrics/resource/v1alpha1 . La estrategia a largo plazo de los desarrolladores
es minimizar el conjunto de métricas proporcionadas por Kubelet.
Por cierto, estas métricas ahora se denominan no "métricas centrales", sino "métricas de recursos", y se describen como "recursos de primera clase, como CPU y memoria".Un matiz muy interesante: a pesar de la clara ventaja en el rendimiento del punto final de gRPC en comparación con los diferentes casos de uso del formato Prometheus
(el resultado de uno de los puntos de referencia'ov ver a continuación) , los autores prefirieron el formato de texto Prometheus debido al liderazgo claro de este sistema de monitoreo en la comunidad.
“GRPC no es compatible con las principales tuberías de monitoreo. Endpoint solo será útil para entregar métricas a Metrics Server o monitorear componentes que se integran directamente con él. Cuando se usa el almacenamiento en caché en Metrics Server, el rendimiento del formato de texto Prometheus es lo suficientemente bueno para que podamos preferir Prometheus en lugar de gRPC, dado el uso generalizado de Prometheus en la comunidad. Cuando el formato OpenMetrics se vuelve más estable, podemos acercarnos al rendimiento de gRPC con un formato basado en proto ”.
Una de las pruebas de rendimiento comparativas que utilizan los formatos gRPC y Prometheus en el nuevo punto final de Kubelet para métricas. Se pueden encontrar más gráficos y otros detalles en KEP .Entre otros cambios:
- Kubelet ahora acepta el parámetro
pid=<number> en las --system-reserved y --kube-reserved , asegurando que el PID especificado se reservará para todo el sistema o los demonios del sistema Kubernetes, respectivamente. La función se activa cuando la puerta de la función está habilitada, llamada SupportNodePidsLimit . - Kubelet ahora (una vez) intenta detener los contenedores en un estado desconocido antes de reiniciar y eliminar operaciones.
- Al usar
PodPresets , la misma información ahora se agrega al contenedor init como un contenedor normal. - Kubelet comenzó a usar
usageNanoCores uso del proveedor de estadísticas CRI, y se agregaron estadísticas de red para nodos y contenedores en Windows. - La información sobre el sistema operativo y la arquitectura ahora se registra en las
kubernetes.io/arch kubernetes.io/os y kubernetes.io/arch de los objetos Node (transferidos de beta a GA). - La capacidad de especificar un grupo de usuarios de sistema específico para contenedores en el pod (
RunAsGroup , apareció en K8s 1.11 ) ha progresado a la versión beta (habilitada de manera predeterminada). - du y find utilizados en cAdvisor son reemplazados por implementaciones Go.
CLI
El indicador -k se ha
agregado a cli-runtime y kubectl para la integración con
kustomize (por cierto, ahora se está desarrollando en un repositorio separado), es decir. para procesar archivos YAML adicionales de directorios especiales de personalización (para obtener detalles sobre su uso, consulte
KEP ):
Un ejemplo de un uso simple del archivo de personalización ( también es posible un uso más complicado de kustomize dentro de las superposiciones )Además
- El logotipo de kubectl y su documentación se han actualizado ; consulte kubectl.docs.kubernetes.io .
- Se ha
kubectl create cronjob un nuevo kubectl create cronjob , cuyo nombre habla por sí mismo. - En los
kubectl logs ahora puede combinar los indicadores -f (- --follow para los registros de transmisión) y -l ( --selector para la consulta de etiquetas). - kubectl enseñó a copiar archivos seleccionados con un comodín.
- El indicador
kubectl wait se agregó al comando de kubectl wait para seleccionar todos los recursos en el espacio de nombres del tipo de recurso especificado. - Mecanismo de complemento estable declarado para kubectl .
Otros
El estado estable (GA) recibió las siguientes características:
- Soporte para nodos de Windows (incluido Windows Server 2019), lo que implica la posibilidad de planificar contenedores de Windows Server en Kubernetes (ver también KEP );
ReadinessGate utilizado en la especificación del pod para determinar condiciones adicionales que se consideran en la preparación del pod;- Soporte para páginas grandes (puerta de funciones llamada
HugePages ); - CustomPodDNS ;
- PriorityClass API, Pod Priority & Preemption .
Otros cambios introducidos en Kubernetes 1.14:
- La política predeterminada de RBAC ya no proporciona acceso a la API de
discovery y access-review a usuarios no autenticados. - El soporte oficial para CoreDNS se proporciona solo para Linux, por lo que cuando se usa kubeadm para su implementación (CoreDNS) en un clúster, los nodos deberían funcionar solo en Linux (los nodos de selección se usan para esta limitación).
- La configuración predeterminada de CoreDNS ahora usa el complemento de reenvío en lugar del proxy. Además, se ha agregado readinessProbe a CoreDNS, lo que evita el equilibrio de carga en los pods correspondientes (no listos para el servicio).
- En kubeadm, en las
upload-certs init o upload-certs , fue posible cargar los certificados requeridos para conectar el nuevo plano de control al secreto de --experimental-upload-certs se usa la bandera --experimental-upload-certs ). - Para las instalaciones de Windows, ha aparecido una versión alfa de soporte para gMSA (Cuenta de servicio administrado de grupo): cuentas especiales en Active Directory, que pueden ser utilizadas por los contenedores.
- Para GCE , el cifrado mTLS se activó entre etcd y kube-apiserver.
- Actualizaciones en el software usado / dependiente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, soporte para Docker 18.09 en kubeadm, y la versión mínima admitida de la API de Docker fue 1.26.
PS
Lea también en nuestro blog: