Esta noche próxima versión de Kubernetes - . Siguiendo la tradición que se ha desarrollado en nuestro blog, estamos hablando de los cambios clave en la nueva versión de este maravilloso producto de Código Abierto.
La información utilizada para preparar este material está extraída de , y problemas relacionados, solicitudes de extracción y propuestas de mejora de Kubernetes (KEP).
Comencemos con una introducción importante del ciclo de vida del clúster SIG: clústeres dinámicos de conmutación por error Kubernetes (o para ser más precisos, implementaciones de HA autohospedadas) ahora está usando comandos familiares (en el contexto de clústeres de un solo nodo) kubeadm (init и join). En resumen, para esto:
- los certificados utilizados por el clúster se transfieren a secretos;
- para la posibilidad de utilizar el clúster etcd dentro del clúster K8s (es decir, deshacerse de la dependencia externa previamente existente) ;
- Documenta la configuración recomendada para un equilibrador de carga externo que proporciona una configuración tolerante a fallos (en el futuro está previsto eliminar esta dependencia, pero no en esta etapa).
Arquitectura de un cluster Kubernetes HA creado con kubeadm
Los detalles de la implementación se pueden encontrar en . Esta característica era realmente esperada desde hace mucho tiempo: la versión alfa se esperaba en K8s 1.9, pero apareció recién ahora.
API
Equipo apply y todos gestión declarativa de objetos de kubectl en un servidor. Los propios desarrolladores explican brevemente su decisión diciendo que kubectl apply - una parte fundamental del trabajo con configuraciones en Kubernetes, sin embargo, "está llena de errores y es difícil de solucionar", por lo que esta funcionalidad debe volver a la normalidad y transferirse al plano de control. Ejemplos simples y claros de problemas que existen hoy en día:
Los detalles sobre la implementación están en . La preparación actual es alfa (la promoción a beta está prevista para la próxima versión de Kubernetes).
Disponible en versión alfa. utilizando el esquema OpenAPI v3 para crear y publicar documentación OpenAPI para CustomResources (CR) utilizado para validar (del lado del servidor) los recursos definidos por el usuario de K8 (CustomResourceDefinition, CRD). La publicación de OpenAPI para CRD permite a los clientes (p. ej. kubectl) realizar la validación de su lado (dentro de kubectl create и kubectl apply) y emitir documentación de acuerdo con el esquema (kubectl explain). Detalles - en .
Registros preexistentes con bandera O_APPEND (y no O_TRUNC) para evitar la pérdida de registros en algunas situaciones y para la conveniencia de truncar registros con utilidades externas para la rotación.
También en el contexto de la API de Kubernetes, se puede observar que en PodSandbox и PodSandboxStatus campo runtime_handler para registrar información sobre RuntimeClass en el pod (lea más sobre esto en el texto sobre , donde esta clase apareció como versión alfa), y en Admission Webhooks capacidad de determinar qué versiones AdmissionReview ellos apoyan. Finalmente, las reglas de Admisión Webhooks ahora están el alcance de su uso por parte de espacios de nombres y marcos de clústeres.
Instalaciones de almacenamiento
, que tenía estado beta desde su lanzamiento , estable (GA): esta puerta de funciones ya no está deshabilitada y se eliminará en Kubernetes 1.17.
usando variables de entorno llamadas (por ejemplo, el nombre del pod) para los nombres de los directorios montados como , fue desarrollado - en forma de un nuevo campo subPathExpr, que ahora se utiliza para determinar el nombre del directorio deseado. La función apareció inicialmente en Kubernetes 1.11, pero en 1.14 permaneció en estado de versión alfa.
Al igual que con la versión anterior de Kubernetes, se introducen muchos cambios significativos para la CSI (Container Storage Interface) en desarrollo activo:
CSI
Estuvo disponible (como parte de la versión alfa) cambio de tamaño para volúmenes CSI. Para usarlo, deberá habilitar la puerta de función llamada ExpandCSIVolumes, así como la presencia de soporte para esta operación en un controlador CSI específico.
Otra característica de CSI en la versión alfa: hacer referencia directamente (es decir, sin utilizar PV/PVC) a los volúmenes CSI dentro de la especificación del pod. Este elimina la restricción sobre el uso de CSI como almacenamiento de datos exclusivamente remoto, abriéndoles las puertas al mundo . Para usar () debe estar habilitado CSIInlineVolume puerta característica.
También ha habido avances en las "partes internas" de Kubernetes relacionadas con CSI, que no son tan visibles para los usuarios finales (administradores de sistemas) ... Actualmente, los desarrolladores se ven obligados a admitir dos versiones de cada complemento de almacenamiento: una - "en el vieja manera”, dentro del código base de K8s (en -tree), y el segundo, como parte del nuevo CSI (lea más sobre esto, por ejemplo, en ). Esto causa inconvenientes comprensibles que deben abordarse a medida que CSI se estabiliza. No es posible simplemente desaprobar la API de complementos internos (en el árbol) debido a .
Todo esto llevó al hecho de que la versión alfa alcanzó código de complemento interno, implementado como in-tree, en complementos CSI, gracias a lo cual las preocupaciones de los desarrolladores se reducirán a admitir una versión de sus complementos, y la compatibilidad con las API antiguas se mantendrá y pueden declararse obsoletas en el escenario habitual. Se espera que para la próxima versión de Kubernetes (1.15) se migren todos los complementos del proveedor de la nube, la implementación reciba el estado beta y se active en las instalaciones K8 de forma predeterminada. Para más detalles, consulte . Esta migración también resultó en de los límites de volumen definidos por proveedores de nube específicos (AWS, Azure, GCE, Cinder).
Además, soporte para dispositivos de bloque con CSI (CSIBlockVolume) a la versión beta.
Nodos/Kubelet
Versión alfa presentada en Kubelet, diseñado para métricas de retorno sobre recursos clave. En términos generales, si antes Kubelet recibía estadísticas sobre el uso de contenedores de cAdvisor, ahora estos datos provienen del entorno de ejecución del contenedor a través de CRI (Container Runtime Interface), pero también se conserva la compatibilidad para trabajar con versiones anteriores de Docker. Anteriormente, las estadísticas recopiladas en Kubelet se enviaban a través de la API REST, pero ahora un punto final ubicado en /metrics/resource/v1alpha1. Estrategia a largo plazo de los desarrolladores. es minimizar el conjunto de métricas proporcionadas por Kubelet. Por cierto, estas métricas en sí 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 rendimiento del endpoint gRPC en comparación con varios casos de uso del formato Prometheus (vea el resultado de uno de los puntos de referencia a continuación), los autores prefirieron el formato de texto de Prometheus debido al claro liderazgo de este sistema de seguimiento en la comunidad.
“gRPC no es compatible con los principales canales de monitoreo. Endpoint solo será útil para entregar métricas a Metrics Server o monitorear componentes que se integren directamente con él. Rendimiento del formato de texto de Prometheus cuando se utiliza el almacenamiento en caché en Metrics Server suficientemente bueno Es preferible que prefiramos Prometheus a gRPC dada la adopción generalizada de Prometheus en la comunidad. Una vez que el formato OpenMetrics se vuelva más estable, podremos abordar el rendimiento de gRPC con un formato basado en prototipos”.
Una de las pruebas comparativas de rendimiento del uso de formatos gRPC y Prometheus en el nuevo punto final de Kubelet para métricas. Más gráficos y otros detalles se pueden encontrar en .
Entre otros cambios:
- Kubelet ahora (una vez) contenedores en un estado desconocido antes de las operaciones de reinicio y eliminación.
- Cuando se utiliza el ahora al contenedor de inicio La misma información que para un contenedor normal.
- kubelet
usageNanoCoresdel proveedor de estadísticas CRI y para nodos y contenedores en Windows estadísticas de la red. - La información del sistema operativo y la arquitectura ahora se registra en etiquetas.
kubernetes.io/osиkubernetes.io/archObjetos de nodo (transferidos de beta a GA). - Capacidad de especificar un grupo de usuarios del sistema específico para contenedores en un pod (
RunAsGroup, apareció en ) antes de la versión beta (habilitada de forma predeterminada). - du y encontrar utilizado en cAdvisor, Implementación en marcha.
CLI
En cli-runtime y kubectl -k bandera para integración con (por cierto, su desarrollo ahora se lleva a cabo en un repositorio separado), es decir para procesar archivos YAML adicionales desde directorios de personalización especiales (para obtener detalles sobre su uso, consulte ):
Ejemplo de uso de archivos simple (Es posible una aplicación más compleja de kustomize dentro )
Además:
- nuevo equipo
kubectl create cronjob, cuyo nombre habla por sí solo. - В
kubectl logsahora puedes banderas-f(--followpara registros de transmisión) y-l(--selectorpara consulta de etiquetas). - kubectl copiar archivos seleccionados por comodín.
- al equipo
kubectl waitbandera--allpara seleccionar todos los recursos en el espacio de nombres del tipo de recurso especificado.
Otros
Las siguientes capacidades han recibido el estado estable (GA):
- , utilizado en la especificación del pod para definir condiciones adicionales que se tienen en cuenta en la preparación del pod;
- Soporte para páginas grandes (puerta de funciones llamada );
- ;
- API de clase prioritaria .
Otros cambios introducidos en Kubernetes 1.14:
- La política RBAC predeterminada ya no permite el acceso a la API
discoveryиaccess-reviewusuarios sin autenticación (no autenticado). - Soporte oficial de CoreDNS Solo Linux, por lo que cuando se usa kubeadm para implementarlo (CoreDNS) en un clúster, los nodos solo deben ejecutarse en Linux (se usan nodeSelectors para esta limitación).
- La configuración predeterminada de CoreDNS ahora es en lugar de proxy. Además, en CoreDNS readinessProbe, que evita el equilibrio de carga en pods apropiados (no listos para el servicio).
- En kubeadm, en fases
initoupload-certs, cargue los certificados necesarios para conectar el nuevo plano de control al secreto kubeadm-certs (use la bandera--experimental-upload-certs). - Ha aparecido una versión alfa para instalaciones de Windows gMSA (Cuenta de servicio administrada por grupo): cuentas especiales en Active Directory que también pueden ser utilizadas por contenedores.
- Para la CME Cifrado mTLS entre etcd y kube-apiserver.
- Actualizaciones en software usado/dependiente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, compatibilidad con Docker 18.09 en kubeadm y la versión mínima de API de Docker admitida ahora es 1.26.
PS
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com