🥇Kubernetes 1.16: visión xeral das principais novidades

Hoxe, mércores, terá lugar próxima versión de Kubernetes - 1.16. Segundo a tradición que se desenvolveu para o noso blog, este é o décimo aniversario que falamos dos cambios máis significativos da nova versión.

A información empregada para preparar este material tómase de Táboas de seguimento de melloras de Kubernetes, CAMBIOS-1.16 e problemas relacionados, solicitudes de extracción e propostas de mellora de Kubernetes (KEP). Entón, imos!...

Nodos

No lado dos nodos do clúster K8s (Kubelet) preséntase un gran número de innovacións notables (en estado de versión alfa).

En primeiro lugar, o chamado «recipientes efémeros» (Contenedores efémeros), deseñado para simplificar os procesos de depuración en pods. O novo mecanismo permítelle lanzar contedores especiais que comezan no espazo de nomes dos pods existentes e viven por pouco tempo. O seu propósito é interactuar con outras vainas e contedores para resolver calquera problema e depurar. Implementouse un novo comando para esta función kubectl debug, similar en esencia a kubectl exec: só en lugar de executar un proceso nun contenedor (como en exec) lanza un contedor nunha vaina. Por exemplo, este comando conectará un novo contedor a un pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Pódense atopar detalles sobre envases efémeros (e exemplos do seu uso) en KEP correspondente. A implementación actual (en K8s 1.16) é unha versión alfa, e entre os criterios para a súa transferencia a unha versión beta está "probar a API Ephemeral Containers durante polo menos 2 versións de [Kubernetes]".

NB: Na súa esencia e mesmo no seu nome, a función aseméllase a un complemento xa existente kubectl-debugsobre o que nós xa escribiu. Espérase que coa chegada dos contedores efémeros cese o desenvolvemento dun complemento externo separado.

Outra innovación - PodOverhead - Deseñado para proporcionar mecanismo para calcular os gastos xerais dos pods, que pode variar moito dependendo do tempo de execución empregado. Como exemplo, os autores este KEP dar lugar a Kata Containers, que requiren executar o núcleo convidado, o axente kata, o sistema de inicio, etc. Cando os gastos xerais se fan tan grandes, non se poden ignorar, o que significa que debe haber unha forma de telos en conta para futuras cotas, planificación, etc. Para implementala en PodSpec campo engadido Overhead *ResourceList (compara cos datos en RuntimeClass, se se usa).

Outra innovación notable é xestor de topoloxía de nodos (Xestor de topoloxía de nodos), deseñado para unificar o enfoque para axustar a asignación de recursos de hardware para varios compoñentes en Kubernetes. Esta iniciativa vén impulsada pola crecente necesidade de diversos sistemas modernos (do ámbito das telecomunicacións, a aprendizaxe automática, os servizos financeiros, etc.) para a computación paralela de alto rendemento e minimizar os atrasos na execución das operacións, para o que empregan CPU avanzadas e capacidades de aceleración de hardware. Este tipo de optimizacións en Kubernetes conseguíronse ata agora grazas a compoñentes dispares (xestor de CPU, xestor de dispositivos, CNI), e agora engadirase unha única interface interna que unifica o enfoque e simplifica a conexión de novos similares -a chamada topoloxía-. consciente - compoñentes do lado de Kubelet. Detalles - en KEP correspondente.

Diagrama de compoñentes do xestor de topoloxía

Próxima función - revisando os contedores mentres están funcionando (sonda de arranque). Como sabedes, para os contedores que tardan moito tempo en lanzarse, é difícil obter un estado actualizado: ou son "matados" antes de comezar a funcionar, ou acaban nun punto morto durante moito tempo. Nova comprobación (activada a través da porta de funcións chamada StartupProbeEnabled) cancela -ou, mellor dito, apraza- o efecto de calquera outra comprobación ata o momento en que o pod remate de funcionar. Por este motivo, a función chamábase orixinalmente pod-startup liveness-probe holdoff. Para os pods que tardan moito en iniciarse, podes consultar o estado en intervalos de tempo relativamente curtos.

Ademais, unha mellora para RuntimeClass está dispoñible inmediatamente no estado beta, engadindo soporte para "clústeres heteroxéneos". C Programación RuntimeClass Agora non é para nada necesario que cada nodo teña soporte para cada RuntimeClass: para os pods podes seleccionar unha RuntimeClass sen pensar na topoloxía do clúster. Anteriormente, para logralo -para que os pods acabasen en nós con soporte para todo o que necesitan- era necesario asignarlle as regras adecuadas a NodeSelector e as tolerancias. EN CAP Fala de exemplos de uso e, por suposto, de detalles de implementación.

Rede

Dúas características de rede importantes que apareceron por primeira vez (en versión alfa) en Kubernetes 1.16 son:

Apoiar pila de rede dual - IPv4/IPv6 - e a súa correspondente "comprensión" a nivel de pods, nodos e servizos. Inclúe interoperabilidade de IPv4 a IPv4 e IPv6 a IPv6 entre pods, desde pods ata servizos externos, implementacións de referencia (dentro dos complementos Bridge CNI, PTP CNI e Host-Local IPAM), así como compatibilidade inversa cos clústeres de Kubernetes en execución. Só IPv4 ou IPv6. Os detalles de implementación están en CAP.
Un exemplo de visualización de enderezos IP de dous tipos (IPv4 e IPv6) na lista de pods:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nova API para Endpoint - API EndpointSlice. Resolve os problemas de rendemento/escalabilidade da API de Endpoint existente que afectan a varios compoñentes do plano de control (apiserver, etcd, endpoints-controller, kube-proxy). A nova API engadirase ao grupo Discovery API e poderá servir decenas de miles de puntos finais de backend en cada servizo nun clúster formado por miles de nós. Para iso, cada Servizo está asignado a N obxectos EndpointSlice, cada un dos cales por defecto non ten máis de 100 puntos finais (o valor é configurable). A API EndpointSlice tamén ofrecerá oportunidades para o seu desenvolvemento futuro: soporte para varios enderezos IP para cada pod, novos estados para os puntos finais (non só Ready и NotReady), subconxunto dinámico para puntos finais.

O presentado na última versión chegou á versión beta finalizadornomeada service.kubernetes.io/load-balancer-cleanup e adxunto a cada servizo con tipo LoadBalancer. No momento de eliminar tal servizo, impide a eliminación real do recurso ata que se complete a "limpeza" de todos os recursos do equilibrador relevantes.

Maquinaria API

O verdadeiro "fito de estabilización" está na área do servidor API de Kubernetes e na interacción con el. Isto ocorreu en gran parte grazas a trasladando a un estado estable aqueles que non necesitan unha introdución especial Definicións de recursos personalizados (CRD), que teñen estado beta desde os tempos afastados de Kubernetes 1.7 (e este é xuño de 2017!). A mesma estabilización chegou ás características relacionadas:

"subrecursos" con /status и /scale para CustomResources;
transformación versións para CRD, baseadas en webhook externo;
presentada recentemente (en K8s 1.15) valores predeterminados (por defecto) e eliminación automática de campos (poda) para CustomResources;
oportunidade usando o esquema OpenAPI v3 para crear e publicar documentación de OpenAPI utilizada para validar os recursos CRD no lado do servidor.

Outro mecanismo que os administradores de Kubernetes son familiares desde hai tempo: webhook de admisión - tamén permaneceu en estado beta durante moito tempo (desde K8s 1.9) e agora está declarado estable.

Outras dúas funcións chegaron a versión beta: aplicarase no lado do servidor и ver marcadores.

E a única innovación significativa na versión alfa foi falla de SelfLink — un URI especial que representa o obxecto especificado e forma parte del ObjectMeta и ListMeta (é dicir, parte de calquera obxecto en Kubernetes). Por que o abandonan? Motivación dun xeito sinxelo soa como a ausencia de razóns reais (abrumadoras) para que este campo siga existindo. Motivos máis formais son optimizar o rendemento (eliminando un campo innecesario) e simplificar o traballo do genérico-apiserver, que se ve obrigado a xestionar tal campo dun xeito especial (este é o único campo que se establece xusto antes do obxecto). está serializado). Auténtica obsolescencia (dentro beta) SelfLink sucederá coa versión 1.20 de Kubernetes e a versión final - 1.21.

Almacenamento de datos

O traballo principal na zona de almacenamento, como en anteriores lanzamentos, obsérvase na zona Soporte CSI. Os principais cambios aquí foron:

por primeira vez (en versión alfa) apareceu Compatibilidade con complementos CSI para nodos de traballo de Windows: a forma actual de traballar co almacenamento tamén substituirá os complementos da árbore no núcleo de Kubernetes e os complementos FlexVolume de Microsoft baseados en Powershell;

Esquema para implementar complementos CSI en Kubernetes para Windows
oportunidade redimensionar os volumes CSI, introducido de volta en K8s 1.12, pasou a ser unha versión beta;
Unha "promoción" similar (de alfa a beta) conseguiuse coa capacidade de usar CSI para crear volumes efémeros locais (Soporte de volume en liña CSI).

Introducido na versión anterior de Kubernetes función de clonación de volume (usando PVC existente como DataSource para crear novo PVC) tamén recibiu o estado beta.

Programador

Dous cambios notables na programación (ambos en alfa):

EvenPodsSpreading - oportunidade use pods en lugar de unidades de aplicación lóxicas para unha "distribución xusta" das cargas (como Deployment e ReplicaSet) e axustando esta distribución (como un requisito duro ou como unha condición suave, é dicir, como prioridade). A función ampliará as capacidades de distribución existentes dos pods planificados, limitadas actualmente polas opcións PodAffinity и PodAntiAffinity, dándolles aos administradores un control máis fino neste asunto, o que supón unha mellor alta dispoñibilidade e un consumo de recursos optimizado. Detalles - en CAP.
Usar Política de BestFit в Función de prioridade RequestedToCapacityRatio durante a planificación do pod, o que permitirá para aplicar embalaxe da papeleira ("empaquetado en contedores") tanto para recursos básicos (procesador, memoria) como para os estendidos (como GPU). Para máis detalles, consulte CAP.

Programación de módulos: antes de usar a política de mellor axuste (directamente a través do planificador predeterminado) e co seu uso (a través do extensor do planificador)

Ademais, presentado a posibilidade de crear os seus propios complementos de planificador fóra da árbore de desenvolvemento principal de Kubernetes (fóra da árbore).

Outros cambios

Tamén podes notar na versión 1.16 de Kubernetes iniciativa para traendo métricas dispoñibles en orde completa, ou máis precisamente, de acordo con normativa oficial a instrumentación K8s. Confían en gran parte no correspondente Documentación Prometheus. As inconsistencias xurdiron por varios motivos (por exemplo, algunhas métricas simplemente creáronse antes de que aparecesen as instrucións actuais), e os desenvolvedores decidiron que era hora de levar todo a un único estándar, "en liña co resto do ecosistema de Prometheus". A implementación actual desta iniciativa está en estado alfa, que se irá promovendo progresivamente en versións posteriores de Kubernetes a beta (1.17) e estable (1.18).

Ademais, pódense sinalar os seguintes cambios:

Desenvolvemento de soporte de Windows с aparencia Utilidades Kubeadm para este sistema operativo (versión alfa), oportunidade RunAsUserName para contenedores de Windows (versión alfa), mellora Compatibilidade coa conta de servizo xestionada en grupo (gMSA) ata a versión beta, apoiar montar/conectar para volumes de vSphere.
Reciclado mecanismo de compresión de datos nas respostas da API. Anteriormente, utilizábase para estes fins un filtro HTTP, que impoñía unha serie de restricións que impedían activalo por defecto. "Compresión transparente de solicitudes" agora funciona: envío de clientes Accept-Encoding: gzip na cabeceira, reciben unha resposta comprimida con GZIP se o seu tamaño supera os 128 KB. Os clientes de Go admiten automaticamente a compresión (enviando a cabeceira necesaria), polo que notarán inmediatamente unha redución do tráfico. (Poden ser necesarias pequenas modificacións noutros idiomas.)
Fíxose posible escalando HPA de/a cero pods en función de métricas externas. Se escala en función de obxectos/métricas externas, cando as cargas de traballo estean inactivas, pode escalar automaticamente a 0 réplicas para aforrar recursos. Esta función debería ser especialmente útil para os casos nos que os traballadores solicitan recursos de GPU e o número de diferentes tipos de traballadores inactivos supera o número de GPU dispoñibles.
Novo cliente - k8s.io/client-go/metadata.Client — para o acceso “xeneralizado” a obxectos. Está deseñado para recuperar facilmente metadatos (é dicir, subsección metadata) dos recursos do clúster e realizar con eles operacións de recollida de lixo e cotas.
Construír Kubernetes agora podes sen provedores de nube legados (versión "alfa").
Para a utilidade kubeadm engadido capacidade experimental (versión alfa) para aplicar parches personalizados durante as operacións init, join и upgrade. Obtén máis información sobre como usar a bandeira --experimental-kustomize, ver en CAP.
Novo punto final para apiserver - readyz, - permítelle exportar información sobre a súa preparación. O servidor da API tamén ten agora unha marca --maximum-startup-sequence-duration, o que lle permite regular os seus reinicios.
Dous características para Azure declarado estable: apoio zonas de dispoñibilidade (Zonas de Dispoñibilidade) e grupo de recursos cruzados (RG). Ademais, Azure engadiu:
- soporte de autenticación AAD e ADFS;
- anotación service.beta.kubernetes.io/azure-pip-name para especificar a IP pública do equilibrador de carga;
- oportunidade axustes LoadBalancerName и LoadBalancerResourceGroup.
AWS agora ten apoiar para EBS en Windows e optimizado Chamadas á API EC2 DescribeInstances.
Kubeadm agora é independente migra Configuración de CoreDNS ao actualizar a versión de CoreDNS.
Binarios etcd na imaxe de Docker correspondente feito mundo executable, o que lle permite executar esta imaxe sen necesidade de dereitos de root. Ademais, imaxe de migración etcd cesou Compatibilidade coa versión etcd2.
В Cluster Autoscaler 1.16.0 pasou a usar distroless como imaxe base, mellorou o rendemento, engadiu novos provedores de nube (DigitalOcean, Magnum, Packet).
Actualizacións no software usado/dependente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Lea tamén no noso blog:

Fonte: www.habr.com

Kubernetes 1.16: visión xeral das principais novidades