Kubernetes 1.19: un aperçu des principales innovations

Aujourd'hui, 25 août, une nouvelle version de Kubernetes aura lieu (elle a été retardée de près de 2 mois au total) - 1.19. Suivant la tradition de notre blog, nous parlons des changements les plus significatifs de la nouvelle version.







Les informations utilisées pour préparer ce matériel sont tirées du tableau de suivi des améliorations de Kubernetes , CHANGELOG-1.19 , de l'aperçu de Sysdig , ainsi que des problèmes connexes, des demandes d'extraction, des propositions d'amélioration de Kubernetes (KEP).



Commençons par quelques innovations majeures à caractère assez général ...



Avec la sortie de Kubernetes 1.19, la "fenêtre de support" pour les versions de Kubernetes est passée de 9 mois (soit les 3 dernières versions) à 1 an (soit 4 versions). Pourquoi?



Il s'est avéré qu'en raison de la vitesse élevée du développement du projet (fréquentes versions majeures), les administrateurs de cluster Kubernetes n'ont pas le temps de mettre à jour leurs installations. Les auteurs du KEP correspondant se réfèrent à une enquête menée par le groupe de travail au début de l'année dernière et ont montré qu'environ un tiers des utilisateurs de Kubernetes traitaient des versions obsolètes de K8s en cours de production:





(Au moment de l'enquête, la version actuelle de Kubernetes était 1.13, c'est-à-dire tous les utilisateurs de K8s 1.9 et 1.10 fonctionnaient avec des versions qui n'étaient plus prises en charge à l'époque.)



Ainsi, il est supposé qu'une prolongation de 3 mois de la période de support pour les versions de Kubernetes - la publication de correctifs qui corrigent les problèmes trouvés dans le code - garantira que plus de 80% des utilisateurs travailleront sur les versions prises en charge de K8 (au lieu des 50-60% supposés pour le moment. ).



Autre grand développement: un standard pour les logs structurés a été développé ... Le système de journalisation actuel dans le plan de contrôle ne garantit pas une structure unique pour les messages et les références d'objet dans Kubernetes, ce qui complique le traitement de ces journaux. Pour résoudre ce problème, une nouvelle structure pour les messages dans les journaux est introduite, pour laquelle la bibliothèque klog a été étendue avec de nouvelles méthodes qui fournissent une interface structurée pour générer des journaux, ainsi que des méthodes auxiliaires pour identifier les objets K8 dans les journaux.



Simultanément à la migration vers klog v2, la transition vers un nouveau format de sortie des logs en JSON est effectuée, ce qui simplifiera l'exécution des requêtes vers les logs et leur traitement. Pour cela, un drapeau apparaît --logging-format, qui utilise par défaut l'ancien format de texte.



Étant donné que le référentiel Kubernetes est énorme et que les auteursLes KEP de journalisation structurée sont réalistes et concentreront leurs efforts pour donner vie à de nouvelles idées sur les messages les plus courants.



Une illustration de la journalisation à l'aide des nouvelles méthodes de klog:

klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kubedns"

klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"

klog.ErrorS(err, "Failed to update pod status")

E1025 00:15:15.525108       1 controller_utils.go:114] "Failed to update pod status" err="timeout"

Utilisation du format JSON:

pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready")

{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}

Une autre innovation importante (et très pertinente) est le mécanisme d'information sur les API obsolètes , implémentées immédiatement en version bêta (c'est-à-dire actives dans les installations par défaut). Comme expliqué par les auteurs, dans de nombreux Kubernetes capacité constamment pas à jour, en restant dans les différents Etats et avec le temps différent de perspectives mi. Il est presque impossible de les suivre, en lisant attentivement toutes les notes de publication et en nettoyant manuellement les configurations / paramètres.



Pour résoudre ce problème, maintenant lors de l'utilisation de l'API obsolète, un en-tête est ajouté à ses réponses Warning, qui est reconnu côté client (client-go) avec possibilité de réponses différentes: ignorer, dédupliquer, consigner. Dans l'utilitaire kubectl, ils ont appris à envoyer ces messages à stderr, à mettre en évidence le message dans la console avec une couleur et à ajouter un indicateur --warnings-as-errorsavec un nom explicite .



En plus de cela, des métriques spéciales ont été ajoutées pour signaler l'utilisation d'API obsolètes et d'annotations d'audit.



Enfin, les développeurs ont assisté à l' avancement des fonctionnalités de Kubernetes à partir de la version bêta . Comme l'expérience du projet l'a montré, certaines nouvelles fonctionnalités et modifications de l'API étaient "bloquées" dans l'état de la bêta, car elles étaient déjà automatiquement (par défaut) activées et ne nécessitaient aucune action supplémentaire de la part des utilisateurs.



Pour éviter que cela ne se produise, il est suggéré envoyer automatiquement à la liste d'obsolescence les fonctionnalités qui sont en version bêta depuis 6 mois (deux versions) et ne remplissent aucune de ces conditions:

1. répondent aux critères de l'AG et sont promus au statut stable;
2. ont une nouvelle version bêta qui rend obsolète la version bêta précédente.

Et maintenant, pour d'autres changements dans Kubernetes 1.19, classés par leurs SIG respectifs.

coffres

Les nouveaux objets CSIStorageCapacity sont destinés à améliorer le processus de planification pour les pods qui utilisent des volumes CSI: ils ne seront pas placés sur des nœuds qui n'ont plus d'espace de stockage. Pour cela, les informations sur l'espace disque disponible seront stockées dans le serveur API et disponibles pour les pilotes CSI et le planificateur. L'état actuel de l'implémentation est la version alpha; voir KEP pour plus de détails .



Une autre innovation de la version alpha est la possibilité de définir des volumes éphémères directement dans les spécifications des pods, volumes génériques en ligne éphémères ( KEP). Les volumes éphémères sont créés pour des pods spécifiques au moment de leur apparition et sont supprimés à leur sortie. Ils auraient pu être définis plus tôt (y compris directement dans la spécification, c'est-à-dire par la méthode en ligne), mais l'approche existante, ayant prouvé la cohérence de la fonctionnalité elle-même, ne couvrait pas tous les cas d'utilisation.



Le nouveau mécanisme offre une API simple pour définir des volumes éphémères pour tout pilote avec prise en charge du provisionnement dynamique (auparavant, cela nécessitait une modification du pilote). Il vous permet de travailler avec tous les volumes éphémères (à la fois CSI et dans l'arborescence, par exemple EmptyDir), et prend également en charge une autre nouvelle fonctionnalité (décrite ci-dessus) - le suivi de l'espace de stockage disponible.



Un exemple d'objet Kubernetes de haut niveau utilisant un nouveau volume éphémère (générique en ligne):

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: scratch
          mountPath: /scratch
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: scratch
        ephemeral:
          metadata:
            labels:
              type: fluentd-elasticsearch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi

Ici, le contrôleur DaemonSet crée des pods avec des noms de vue fluentd-elasticsearch-b96sd, après quoi un PersistentVolumeClaim sera ajouté pour un tel pod fluentd-elasticsearch-b96sd-scratch.



Et la dernière fonctionnalité de stockage entièrement nouvelle, introduite en version alpha, est un nouveau champ csidriver.spec.SupportsFSGrouppour les pilotes CSI qui indique la prise en charge des autorisations basées sur FSGroup ( KEP ). Motivation: un changement de propriété d'un volume CSI est effectué avant son montage dans un conteneur, mais tous les types de stockage ne prennent pas en charge une telle opération (par exemple, NFS), c'est pourquoi elle peut désormais entraîner des erreurs.



Jusqu'à la version bêta (c'est-à-dire, les inclusions par défaut) ont "augmenté":

• CSI- Azure vSphere ( , Kubernetes);
• Secrets ConfigMaps.

/ Kubelet

Seccomp a été déclaré stable (GA) . En particulier, ces travaux ont conduit à la transition vers des champs pour seccomp dans l'API au lieu d'annotations déclarées obsolètes (les nouveaux Kubelets ignorent les annotations), et ont affecté PodSecurityPolicy .



Un nouveau champ a été ajouté au PodSpec fqdnInHostnamepour vous permettre de définir le FQDN (nom de domaine complet) pour l'hôte du pod . L'objectif est d'améliorer la prise en charge des applications héritées dans Kubernetes. Voici comment les auteurs expliquent leurs intentions:

« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».

La valeur par défaut sera falsede conserver l'ancien comportement (pour Kubernetes). Statut de la fonctionnalité - version alpha, qui devrait être déclarée stable dans la prochaine version (1.20).



Il a été décidé d' abandonner les métriques d'accélérateur collectées par Kubelet . Il est proposé de collecter ces métriques par des agents de surveillance externes via l'API PodResources. Cette API elle-même a été créée précisément dans le but de supprimer toutes les métriques spécifiques aux appareils du référentiel principal Kubernetes, permettant aux fournisseurs de les implémenter sans apporter de modifications au cœur de Kubernetes. L'API PodResources est en version bêta (Feature Gate en est responsable KubeletPodResources) et sera bientôt stable. Pour la version actuelle, le processus d'abandon est en statut alpha, les détails sont dans KEP .



Désormais, Kubelet peut être construit sans Docker : par ce "sans" les auteurs signifient l'absence de tout code spécifique à Docker et la dépendance au package Golang docker/docker. Le but ultime de cette initiative est d'arriver à un Kubelet complètement "sans docker" (c'est-à-dire sans dépendance Docker). Vous pouvez en savoir plus sur la motivation, comme toujours, chez KEP . Cette opportunité a immédiatement reçu le statut GA.



Le Node Topology Manager, qui a atteint sa version bêta dans la dernière version de K8, a désormais la possibilité de niveler les ressources au niveau du pod.

Planificateur

De retour dans Kubernetes 1.18, nous avons écrit sur une configuration globale pour une distribution uniforme de pod (Even Pod Spreading) , mais il a ensuite été décidé de reporter cette fonctionnalité en fonction des résultats des tests de performances. Elle est maintenant dans Kubernetes (en statut alpha).



L'essence de l'innovation est l'ajout de contraintes globales ( DefaultConstraints), qui permettent de réguler les règles de distribution des pods à un niveau supérieur - au niveau du cluster, et pas seulement en PodSpec(à travers topologySpreadConstraints), comme c'était le cas jusqu'à présent. La configuration par défaut sera similaire au plugin actuel DefaultPodTopologySpread:

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

Les détails sont dans KEP .



Autre particularité liée à Even Pod Spreading: la répartition d'un groupe de pods par domaines de défaillance (régions, zones, nœuds, etc.), - transférée de l'alpha à la beta (activée par défaut).



Trois autres fonctionnalités du planificateur ont atteint une "augmentation" similaire:

• Profils de planification (ordonnancement des profils) , présentés en 1.18;
• option pour activer / désactiver la préemption de pod dans PriorityClasses;
• fichier de configuration kube-scheduler ComponentConfig .

Réseaux

La ressource Ingress est finalement déclarée stable et a une version v1dans l'API. À cet égard, de nombreuses mises à jour ont été présentées dans la documentation pertinente. Une attention particulière doit être portée aux changements perceptibles par l'utilisateur à partir de ce PR : par exemple, il existe des renoms tels que spec.backend→ spec.defaultBackend, serviceName→ service.name, servicePort→ service.port.number...



Le champ AppProtocol pour les services et les points de terminaison, ainsi que l' API EndpointSlice (kube-proxy sous Linux démarre utiliser EndpointSlices par défaut, mais est resté en alpha pour Windows) et le support SCTP .

kubeadm

Deux nouvelles fonctionnalités (en version alpha) sont introduites pour l'utilitaire kubeadm.



La première consiste à utiliser des correctifs pour modifier les manifestes générés par kubeadm. Il était déjà possible de les modifier en utilisant Kustomize (en alpha), mais les développeurs de kubeadm ont décidé que l'utilisation de correctifs réguliers était la méthode préférée (puisque Kustomize devient une dépendance inutile, ce qui n'est pas le bienvenu).



Il est maintenant possible d'appliquer des patchs bruts (via un drapeau --experimental-patches) pour les commandes kubeadm init, joinet upgrade, ainsi que leurs phases. L'implémentation basée sur Kustomize (indicateur --experimental-kustomize) sera obsolète et supprimée.



La deuxième fonctionnalité est une nouvelle approche pour travailler avec les configurations de composantsavec lequel kubeadm fonctionne. L'utilitaire génère, valide, définit les valeurs par défaut, stocke les configurations (sous la forme de ConfigMaps) pour des composants de cluster Kubernetes tels que Kubelet et kube-proxy. Au fil du temps, il est devenu clair que cela posait un certain nombre de difficultés: comment distinguer les configurations générées par kubeadm ou soumises par l'utilisateur (et si non, que faire de la migration de configuration)? Quels champs avec des valeurs par défaut ont été générés automatiquement, et lesquels ont été intentionnellement définis? ..



Pour résoudre ces problèmes, un grand ensemble de modifications est présenté , notamment: le refus de définir les valeurs par défaut (cela doit être fait par les composants eux-mêmes), la délégation de validation de la configuration par eux-mêmes composants, signature de chaque ConfigMap généré, etc.



Et une autre fonctionnalité moins importante pour kubeadm est une porte de fonctionnalités appelée PublicKeysECDSA, qui inclut la possibilité de créer un cluster [via kubeadm init] avec des certificats ECDSA. La mise à jour des certificats existants (via kubeadm alpha certs renew) est également fournie, mais il n'existe aucun mécanisme permettant de basculer facilement entre RSA et ECDSA.

Autres changements

• Le statut GA a reçu 3 fonctionnalités dans le domaine de l'authentification: l' API CertificateSigningRequest , la restriction de l'accès des nœuds à certaines API (via un plugin d'admission NodeRestriction), le bootstrap et le renouvellement automatique du certificat client Kubelet.
• La nouvelle API d'événements a également été déclarée stable avec une approche modifiée de la déduplication (pour éviter de surcharger le cluster avec des événements).
• (kube-apiserver, kube-scheduler, etcd ) debian distroless. : , ( — KEP).
• Kubelet Docker runtime target-, TargetContainerName EphemeralContainer ( ).
• « » .status.conditions, API .
• kube-proxy IPv6DualStack Windows ( feature gate).
• La porte de fonctionnalité avec un nom explicite CSIMigrationvSphere(migration du plug-in intégré - dans l'arborescence - pour vSphere vers le pilote CSI) est passée à la version bêta.
• Pour kubectl run un drapeau ajouté--privileged .
• Un nouveau point d'extension a été ajouté au planificateur - , - qui démarre après la phase .PostFilterFilter
• -Containerd Cri support sur Windows a atteint beta.

Changements de dépendance:

• version de CoreDNS incluse dans kubeadm - 1.7.0;
• cri-tools 1.18.0;
• CNI (Container Networking Interface) 0.8.6;
• etcd 3.4.9;
• la version de Go utilisée est 1.15.0-rc.1.

PS

Lisez aussi sur notre blog:

• « Kubernetes 1.18: revue des principales innovations »;
• «Kubernetes 1.17: »;
• «Kubernetes 1.16: »;
• «Kubernetes 1.15: ».