Esta noite próxima versión de Kubernetes - . Segundo a tradición que se desenvolveu para o noso blog, estamos a falar dos principais cambios na nova versión deste marabilloso produto de código aberto.
A información empregada para preparar este material tómase de , e problemas relacionados, solicitudes de extracción, propostas de mellora de Kubernetes (KEP).
Comecemos cunha introdución importante do ciclo de vida do clúster SIG: clústeres de conmutación por error dinámicos Kubernetes (ou, para ser máis precisos, implementacións de alta disponibilidad autoaloxadas) xa está utilizando comandos coñecidos (no contexto de clústeres dun só nodo). kubeadm (init и join). En resumo, para iso:
- os certificados utilizados polo clúster transfírense a segredos;
- para a posibilidade de usar o clúster etcd dentro do clúster K8s (é dicir, desfacerse da dependencia externa previamente existente) ;
- Documenta a configuración recomendada para un equilibrador de carga externo que proporciona unha configuración tolerante a fallos (no futuro está previsto eliminar esta dependencia, pero non neste momento).
Arquitectura dun clúster HA de Kubernetes creado con kubeadm
Os detalles da implementación pódense consultar en . Esta característica era moi esperada: a versión alfa era esperada en K8s 1.9, pero só apareceu agora.
API
Equipo apply e en xeral xestión de obxectos declarativos de kubectl en apiserver. Os propios desenvolvedores explican brevemente a súa decisión dicindo iso kubectl apply - unha parte fundamental do traballo con configuracións en Kubernetes, non obstante, "está cheo de erros e é difícil de corrixir" e, polo tanto, esta funcionalidade ten que ser normalizada e transferida ao plano de control. Exemplos sinxelos e claros de problemas que existen na actualidade:
Os detalles sobre a implementación están en . A preparación actual é alfa (a promoción a beta está prevista para a próxima versión de Kubernetes).
Dispoñible en versión alfa usando o esquema OpenAPI v3 para creando e publicando documentación OpenAPI para CustomResources (CR) usado para validar (no servidor) recursos definidos polo usuario de K8 (CustomResourceDefinition, CRD). A publicación de OpenAPI para CRD permite que os clientes (p. kubectl) realizar a validación do seu lado (dentro kubectl create и kubectl apply) e expedir documentación segundo o esquema (kubectl explain). Detalles - en .
Rexistros preexistentes con bandeira O_APPEND (pero non O_TRUNC) para evitar a perda de rexistros nalgunhas situacións e para a conveniencia de truncar os rexistros con utilidades externas para a rotación.
Tamén no contexto da API de Kubernetes, pódese sinalar que en PodSandbox и PodSandboxStatus campo runtime_handler para gravar información sobre RuntimeClass no pod (le máis sobre iso no texto sobre , onde esta clase apareceu como unha versión alfa), e en Admission Webhooks capacidade de determinar que versións AdmissionReview eles apoian. Finalmente, agora están as regras de Admisión Webhooks a extensión do seu uso por espazos de nomes e marcos de clúster.
Almacenamento
, que tiña estado beta desde o lanzamento , estable (GA): esta porta de funcións xa non está desactivada e eliminarase en Kubernetes 1.17.
usando variables de ambiente chamadas (por exemplo, o nome do pod) para os nomes dos directorios montados como , foi desenvolvido - en forma dun novo campo subPathExpr, que agora se usa para determinar o nome do directorio desexado. A función apareceu inicialmente en Kubernetes 1.11, pero para a versión 1.14 permaneceu en estado de versión alfa.
Do mesmo xeito que coa versión anterior de Kubernetes, introdúcense moitos cambios significativos para o CSI (Container Storage Interface) en desenvolvemento activo:
CSI
Quedou dispoñible (como parte da versión alfa) redimensionar para volumes CSI. Para usalo, terás que activar a porta de funcións chamada ExpandCSIVolumes, así como a presenza de soporte para esta operación nun controlador CSI específico.
Outra característica para CSI na versión alfa: referirse directamente (é dicir, sen usar PV/PVC) aos volumes CSI dentro da especificación do pod. Isto elimina a restrición ao uso de CSI como almacenamento de datos exclusivamente remoto, abríndolles as portas ao mundo . Para uso () debe estar activado CSIInlineVolume porta de características.
Tamén houbo avances nos "internos" de Kubernetes relacionados co CSI, que non son tan visibles para os usuarios finais (administradores do sistema)... Actualmente, os desenvolvedores están obrigados a admitir dúas versións de cada complemento de almacenamento: unha - "no vello", dentro da base de código K8s (en -árbore), e o segundo - como parte do novo CSI (le máis sobre iso, por exemplo, en ). Isto provoca inconvenientes comprensibles que deben ser abordados a medida que o propio CSI se estabiliza. Non é posible simplemente desaprobar a API dos complementos internos (en árbore) debido a .
Todo isto levou ao feito de que chegou a versión alfa código de complemento interno, implementado como in-tree, nos complementos CSI, grazas ao cal as preocupacións dos desenvolvedores reduciranse a soportar unha versión dos seus complementos, e manterase a compatibilidade coas API antigas e poderán ser declaradas obsoletas no escenario habitual. Espérase que na próxima versión de Kubernetes (1.15) todos os complementos do provedor de nube sexan migrados, a implementación recibirá o estado beta e activarase nas instalacións de K8s por defecto. Para máis detalles, consulte . Esta migración tamén deu lugar a partir de límites de volume definidos por provedores de nube específicos (AWS, Azure, GCE, Cinder).
Ademais, soporte para dispositivos de bloque con CSI (CSIBlockVolume) á versión beta.
Nodos/Kubelet
Versión alfa presentada en Kubelet, deseñado para devolver métricas sobre recursos clave. En xeral, se anteriormente Kubelet recibía estatísticas sobre o uso de contedores de cAdvisor, agora estes datos proceden do entorno de execución do contedor a través de CRI (Interface de execución de contedores), pero tamén se conserva a compatibilidade para traballar con versións antigas de Docker. Anteriormente, as estatísticas recollidas en Kubelet enviábanse a través da API REST, pero agora un punto final situado en /metrics/resource/v1alpha1. Estratexia a longo prazo dos desenvolvedores é minimizar o conxunto de métricas proporcionadas por Kubelet. Por certo, estas métricas en si non "métricas básicas", senón "métricas de recursos", e descríbense como "recursos de primeira clase, como CPU e memoria".
Un matiz moi interesante: a pesar da clara vantaxe de rendemento do punto final gRPC en comparación con varios casos de uso do formato Prometheus (ver o resultado dun dos benchmarks a continuación), os autores preferiron o formato de texto de Prometheus debido ao claro liderado deste sistema de seguimento na comunidade.
"gRPC non é compatible coas principais conducións de vixilancia. Endpoint só será útil para entregar métricas a Metrics Server ou supervisar compoñentes que se integran directamente con el. Rendemento do formato de texto de Prometheus ao usar a caché en Metrics Server suficientemente bo para que preferimos Prometheus ao gRPC dada a ampla adopción de Prometheus na comunidade. Unha vez que o formato OpenMetrics sexa máis estable, poderemos abordar o rendemento de gRPC cun formato baseado en proto.
Unha das probas comparativas de rendemento do uso dos formatos gRPC e Prometheus no novo punto final de Kubelet para as métricas. Podes atopar máis gráficos e outros detalles en .
Entre outros cambios:
- Kubelet agora (unha vez) contedores nun estado descoñecido antes de reiniciar e eliminar as operacións.
- Ao usar agora ao contedor de inicio a mesma información que para un recipiente normal.
- kubelet
usageNanoCoresdo provedor de estatísticas CRI, e para nós e contedores en Windows estatísticas da rede. - A información do sistema operativo e da arquitectura agora está rexistrada en etiquetas
kubernetes.io/osиkubernetes.io/archObxectos nodos (transferidos de beta a GA). - Capacidade de especificar un grupo específico de usuarios do sistema para contedores nun pod (
RunAsGroup, apareceu en ) antes de beta (activado por defecto). - du e find usado en cAdvisor, implementación en Go.
CLI
En cli-runtime e kubectl -k bandeira para a integración con (por certo, o seu desenvolvemento realízase agora nun repositorio separado), é dicir. para procesar ficheiros YAML adicionais desde directorios especiais de personalización (para obter detalles sobre o seu uso, consulte ):
Exemplo de uso sinxelo de ficheiros (É posible unha aplicación máis complexa de kustomize dentro )
Ademais:
- novo equipo
kubectl create cronjob, cuxo nome fala por si só. - В
kubectl logsagora podes bandeiras-f(--followpara rexistros de streaming) e-l(--selectorpara consulta de etiquetas). - kubectl copiar ficheiros seleccionados por comodín.
- Ao equipo
kubectl waitbandeira--allpara seleccionar todos os recursos no espazo de nomes do tipo de recurso especificado.
Outros
As seguintes capacidades recibiron o estado estable (GA):
- , usado na especificación do pod para definir condicións adicionais que se teñen en conta na preparación do pod;
- Soporte para páxinas grandes (porta de funcións chamada );
- ;
- API de PriorityClass .
Outros cambios introducidos en Kubernetes 1.14:
- A política RBAC predeterminada xa non permite o acceso á API
discoveryиaccess-reviewusuarios sen autenticación (sen autenticar). - Soporte oficial de CoreDNS Só Linux, polo que cando se usa kubeadm para implementalo (CoreDNS) nun clúster, os nós só deben executarse en Linux (usanse nodeSelectors para esta limitación).
- A configuración predeterminada de CoreDNS é agora en lugar de proxy. Ademais, en CoreDNS ReadinessProbe, que impide o equilibrio de carga nos pods axeitados (non listos para o servizo).
- En kubeadm, en fases
initouupload-certs, cargue os certificados necesarios para conectar o novo plano de control ao segredo kubeadm-certs (use a bandeira--experimental-upload-certs). - Apareceu unha versión alfa para instalacións de Windows gMSA (Group Managed Service Account) - contas especiais en Active Directory que tamén poden ser usadas por contedores.
- Para G.C.E. Cifrado mTLS entre etcd e kube-apiserver.
- Actualizacións no software usado/dependente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, compatibilidade con Docker 18.09 en kubeadm e a versión mínima admitida da API de Docker agora é 1.26.
PS
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com