Esta noche se lanza otra versión de Kubernetes — . Según la tradición de nuestro blog, hablamos sobre los cambios clave en la nueva versión de este maravilloso producto de código abierto.
La información utilizada para la preparación de este material se tomó de , y los issues, pull requests, Propuestas de Mejora de Kubernetes (KEP) correspondientes.
Comencemos con una importante introducción de SIG cluster-lifecycle: clústeres dinámicos y tolerantes a fallos Kubernetes (o, para ser más precisos, despliegues HA autoalojados) ahora utilizando los comandos familiares (en el contexto de clústeres de un solo nodo) kubeadm (init y join). En resumen, para esto:
- los certificados utilizados por el clúster se transfieren a secretos;
- para permitir el uso de etcd dentro del clúster de K8s (es decir, eliminar la dependencia externa que existía anteriormente) se ha implementado ;
- se documentan las configuraciones recomendadas para el balanceador de carga externo que proporciona una configuración tolerante a fallos (en el futuro se planea la posibilidad de renunciar a esta dependencia también, pero no en esta etapa).
Arquitectura del clúster HA de Kubernetes creado con kubeadm
Los detalles de la implementación se pueden encontrar en . Esta función ha sido realmente esperada: la versión alfa se esperaba desde K8s 1.9, pero solo ha llegado ahora.
API
Comando aplicar y en general gestión declarativa de objetos de kubectl en apiserver. Los propios desarrolladores explican brevemente su decisión señalando que kubectl apply — una parte fundamental del trabajo con configuraciones en Kubernetes, sin embargo, «está llena de errores y es difícil de corregir», por lo que esta funcionalidad necesita ser puesta en condiciones normales y trasladada al control plane. Ejemplos simples y claros de los problemas existentes hoy son:
Los detalles de la implementación — en . La preparación actual — versión alfa (se planea avanzar a beta en el próximo lanzamiento de Kubernetes).
En la versión alfa se ha hecho disponible el uso del esquema OpenAPI v3 para crear y publicar documentación OpenAPI para CustomResources (CR), utilizados para la validación (del lado del servidor) de los recursos de K8s definidos por el usuario (CustomResourceDefinition, CRD). La publicación de OpenAPI para CRD permite a los clientes (por ejemplo, kubectl) realizar la validación del lado del cliente (dentro de kubectl create y kubectl apply) y producir documentación del esquema (kubectl explain). Más detalles — en .
Los registros existentes anteriormente con la bandera O_APPEND (y no O_TRUNC) para evitar la pérdida de registros en ciertas situaciones y para facilitar la truncación de registros a través de herramientas externas para la rotación.
También en el contexto de la API de Kubernetes, se puede señalar que en PodSandbox y PodSandboxStatus el campo runtime_handler para tener en cuenta la información sobre RuntimeClass en el pod (para más detalles, consulte el texto sobre , donde esta clase se introdujo como versión alfa), y en Admission Webhooks la capacidad de definir qué versiones AdmissionReview son compatibles. Finalmente, en las reglas de Admission Webhooks ahora el alcance de su aplicación por namespaces y límites del clúster.
Almacenamientos
, que tenían estatus de versión beta desde el lanzamiento , estables (GA): este feature gate ya no se desactiva y se eliminará en Kubernetes 1.17.
el uso de variables de entorno llamadas (por ejemplo, el nombre del pod) para los nombres de directorios montados como , ha evolucionado — en forma de un nuevo campo subPathExpr, mediante el cual ahora se determina el nombre de directorio necesario. Esta función apareció inicialmente en Kubernetes 1.11, pero también permaneció en estado alfa para 1.14.
Al igual que en la versión anterior de Kubernetes, se presentan muchos cambios significativos para el en desarrollo CSI (Container Storage Interface):
CSI
Se ha hecho disponible (en versión alfa) cambio de tamaño para volúmenes CSI.Para utilizarlo, será necesario activar el feature gate llamado ExpandCSIVolumes, así como contar con el soporte para esta operación en el controlador CSI específico.
Otra característica de CSI en versión alfa — referirse directamente (es decir, sin usar PV/PVC) a volúmenes CSI dentro de la especificación de los pods. Esto elimina la restricción de utilizar CSI exclusivamente como almacenamiento de datos remoto, abriendo puertas a Para su uso () es necesario activar el feature gate CSIInlineVolume. Ha habido avances también en las 'entrañas' de Kubernetes relacionados con CSI, que no son tan evidentes para los usuarios finales (administradores del sistema)... En este momento, los desarrolladores se ven obligados a mantener dos versiones de cada plugin de almacenamiento: una 'a la antigua', dentro de la base de código de K8s (in-tree), y la segunda — dentro del nuevo CSI
(para más detalles, consulte, por ejemplo, en (lea más sobre él, por ejemplo, en ). Esto provoca incomodidades comprensibles que deben ser solucionadas a medida que se estabiliza CSI como tal. Simplemente declarar obsoletos (deprecated) a los APIs internos (in-tree) de los plugins no es posible debido a .
Todo esto ha llevado a que las versiones alfa hayan alcanzado del código interno de los plugins, implementados como in-tree, a plugins CSI, lo que permitirá a los desarrolladores preocuparse por mantener una sola versión de sus plugins, asegurando la compatibilidad con los APIs antiguos y permitiendo que sean declarados obsoletos de la manera habitual. Se espera que para la próxima versión de Kubernetes (1.15) se complete la migración de todos los plugins de proveedores de la nube, que la implementación alcance el estado beta y se active en las instalaciones de K8s por defecto. Para más detalles, consulte . Como consecuencia de esta migración también surgió de las restricciones para volúmenes definidos por proveedores de nube específicos (AWS, Azure, GCE, Cinder).
Además, se ha añadido soporte para dispositivos de bloque con CSI (CSIBlockVolume) a versión beta.
Nodos / Kubelet
Se ha presentado la versión alfa en Kubelet, destinado a proporcionar métricas sobre recursos clave. En términos generales, si antes Kubelet obtenía estadísticas de uso de contenedores de cAdvisor, ahora estos datos provienen del entorno de ejecución del contenedor a través de CRI (Container Runtime Interface), aunque se ha mantenido la compatibilidad para trabajar con versiones antiguas de Docker. Antes, las estadísticas recolectadas en Kubelet se entregaban a través de REST API, y ahora se utiliza un endpoint ubicado en /metrics/resource/v1alpha1. La estrategia a largo plazo de los desarrolladores minimizar el conjunto de métricas proporcionadas por Kubelet. Por cierto, estas métricas no «core metrics», sino «resource metrics», y se describen como «first-class resources, como CPU y memoria».
Un matiz interesante: a pesar de la clara ventaja de rendimiento del endpoint gRPC en comparación con varios casos de uso del formato Prometheus (el resultado de uno de los benchmark se ve a continuación), los autores prefirieron el formato de texto de Prometheus debido al claro liderazgo de este sistema de monitoreo en la comunidad.
«gRPC no es compatible con los principales pipelines de monitoreo. El endpoint solo será útil para entregar métricas al Metrics Server o a componentes de monitoreo que se integren directamente con él. Al utilizar el almacenamiento en caché en el Metrics Server, el rendimiento del formato de texto de Prometheus es suficientemente bueno para nosotros como para preferir Prometheus en lugar de gRPC, dado que Prometheus es ampliamente utilizado en la comunidad. Cuando el formato OpenMetrics sea más estable, podremos acercarnos al rendimiento de gRPC con un formato basado en proto».
Una de las pruebas comparativas de rendimiento entre los formatos gRPC y Prometheus en el nuevo endpoint de Kubelet para métricas. Más gráficos y otros detalles se pueden encontrar en .
Entre otros cambios:
- Kubelet ahora (una vez) los contenedores en estado desconocido (unknown) antes de las operaciones de reinicio y eliminación.
- Al usar ahora se agrega la misma información al contenedor init Kubelet
- ha comenzado a utilizar
del proveedor de estadísticas CRI, y para nodos y contenedores en Windowsestadísticas de red. La información sobre el sistema operativo y la arquitectura ahora se registra en las etiquetas - kubernetes.io/os
kubernetes.io/archyde los objetos Node (migrado de beta a GA).La capacidad de especificar un grupo de usuario del sistema específico para contenedores en un pod ( - RunAsGroup
, fue introducida enK8s 1.11 ) du y find, utilizados en cAdvisor, - fueron reemplazados CLI
en cli-runtime y kubectl
el flag -k para integración con (por cierto, su desarrollo ahora se lleva a cabo en un repositorio separado), es decir, para procesar archivos YAML adicionales de directorios especiales de kustomization (detalles sobre su uso se pueden encontrar en Ejemplo de uso simple del archivo ):
kustomization overlays )
nueva comando
- kubectl create cronjob
, cuyo nombre lo dice todo.kubectl logs - En
combinaahora es posible flags-f(para la transmisión de logs) y--selector-l(para la consulta por etiquetas).se aprendió - kubectl El comando
- kubectl wait
--allbanderapara seleccionar todos los recursos en el espacio de nombres del tipo de recursos especificado.Las siguientes características recibieron estado estable (GA):
Otros
ReadinessGate
- , utilizado en la especificación del pod para definir condiciones adicionales que se tienen en cuenta en la disponibilidad del pod;
- Soporte para páginas grandes (feature gate llamada );
- ;
- API de PriorityClass, .
Otros cambios introducidos en Kubernetes 1.14:
- La política RBAC por defecto ya no permite el acceso al API
discoveryyaccess-reviewa usuarios sin autenticación (unauthenticated). - El soporte oficial de CoreDNS solo para Linux, por lo que al usar kubeadm para su (CoreDNS) implementación en el clúster, los nodos deben funcionar solo en Linux (para esta limitación se utilizan nodeSelectors).
- La configuración por defecto de CoreDNS ahora en lugar de proxy. Además, en CoreDNS readinessProbe, que evita el balanceo de carga en los pod's correspondientes (no listos para atender).
- En kubeadm, en las fases
initoupload-certs, cargar los certificados necesarios para conectar un nuevo control-plane al secreto kubeadm-certs (se usa el flag--experimental-upload-certs). - Para instalaciones de Windows, hay una versión alfa gMSA (Cuenta de Servicio Administrado por Grupo) — cuentas especiales en Active Directory que pueden ser utilizadas también por contenedores.
- Para GCE la encriptación mTLS entre etcd y kube-apiserver.
- Actualizaciones en el software utilizado/dependiente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, soporte de Docker 18.09 en kubeadm, y la versión mínima soportada de la API de Docker es 1.26.
P.D.
También puedes leer en nuestro blog:
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
