Container Compute Service:Notes de version de Kubernetes 1.30

Le hook PreStop introduit un mode veille qui suspend un conteneur pendant une durée spécifiée avant son arrêt. Cette pause laisse le temps aux opérations en attente ou aux requêtes réseau de se terminer. Pour plus d'informations, consultez KEP-3960 : Introduction de l'action Sleep pour le hook PreStop.

SidecarContainers passe en phase Beta et est activé par défaut. Cette fonctionnalité permet de définir restartPolicy d'un conteneur d'initialisation sur Always, le transformant ainsi en conteneur sidecar. Celui-ci peut démarrer, s'arrêter ou redémarrer indépendamment, sans affecter le conteneur d'application principal ni les autres conteneurs d'initialisation. Pour plus d'informations, consultez Sidecar Containers.

Le nouveau type de ressource ServiceCIDR permet la configuration dynamique de la plage ClusterIP des Services. Cette fonctionnalité est en phase Alpha et désactivée par défaut. Pour en savoir plus sur l'extension dynamique du nombre d'adresses IP disponibles pour les Services, consultez KEP-1880 : Multiple Service CIDRs.

Les PVC (Persistent Volume Claims) et les conteneurs utilisaient initialement la même structure ResourceRequirements pour définir les requests et les limits de ressources. Cela entraînait une modification de l'API PVC chaque fois que la structure resources du conteneur changeait, par exemple lors de l'ajout du champ claims. Par conséquent, les PVC utilisent désormais une structure distincte, VolumeResourceRequirements, qui contient uniquement les champs requests et limits, et exclut le champ claims. Pour plus d'informations, consultez Volume resource requirements.

La fonctionnalité PodReadyToStartContainers est en phase Beta et activée par défaut. Elle indique que le bac à sable (sandbox) d'un pod est créé et que son réseau est configuré. Le runtime de conteneur est alors prêt, ce qui aide le kubelet à déterminer l'état du pod. Pour plus d'informations, consultez Pod conditions.

PodAffinity et PodAntiAffinity prennent désormais en charge matchLabelKeys et mismatchLabelKeys afin de résoudre un problème où le planificateur ne distinguait pas les anciens pods des nouveaux lors d'une mise à jour progressive d'un Deployment. Cette confusion pouvait conduire à des résultats de planification non conformes aux attentes d'affinité et d'anti-affinité. Lorsque vous configurez matchLabelKeys pour PodAffinity, le Deployment ajoute un libellé pod-template-hash au ReplicaSet. Chaque pod du Deployment reçoit ainsi une chaîne de hachage correspondante, indiquant au planificateur d'évaluer uniquement les pods ayant la même valeur pod-template-hash, ce qui facilite la distinction des pods appartenant au même lot de mise à jour. Pour plus d'informations, consultez KEP-3633.

Outre les ressources de l'API Kubernetes de base, la vérification de type pour ValidatingAdmissionPolicy prend désormais en charge les CRD et les extensions d'API. Cela contribue à garantir la fiabilité des politiques et l'exactitude de la configuration du cluster. Pour plus d'informations, consultez type-checking.

Le nouveau feature gate UserNamespacesPodSecurityStandards intègre les namespaces utilisateur aux Pod Security Standards. Une fois activé, il permet aux conteneurs de s'exécuter en tant qu'utilisateur non root ou avec un ID utilisateur spécifique dans le contexte de sécurité du pod. Ce feature gate est en phase Alpha et désactivé par défaut ; il pourrait rester désactivé dans les versions futures. Pour plus d'informations, consultez KEP-127 : Update PSS based on feature gate.

Pour les objets nœud, le nouveau feature gate DisableNodeKubeProxyVersion rend obsolète le champ status.nodeInfo.kubeProxyVersion. Autrement dit, la définition du champ kubeProxyVersion pour les nœuds est désactivée dans Kubernetes. Le kubelet ne pouvant pas toujours identifier avec précision la version de kube-proxy, ce champ n'est pas toujours exact. Ce feature gate est actuellement en phase Alpha et désactivé (false) par défaut.

Le feature gate JobBackoffLimitPerIndex passe en phase Beta et est activé par défaut. Il permet de spécifier le nombre maximal de tentatives pour chaque index d'un job indexé. Pour plus d'informations sur les jobs indexés, consultez Use Indexed Job for Parallel Processing with Static Work Assignment.

Le feature gate ImageMaximumGCAge permet au kubelet de configurer l'âge maximal d'une image inutilisée avant sa suppression par le ramasse-miettes. Si une image reste inutilisée au-delà de cette durée, le mécanisme de ramasse-miettes peut la nettoyer. La valeur par défaut est "0s", ce qui signifie qu'aucune limite de temps n'est définie. Introduit en phase Alpha dans la version 1.29, ce feature gate est passé en phase Beta dans la version 1.30.

Kubelet ajoute la nouvelle métrique de surveillance image_pull_duration_seconds pour suivre la durée de téléchargement des images. Pour plus d'informations, consultez List of Alpha Kubernetes Metrics.

Le feature gate LegacyServiceAccountTokenCleanUp passe en phase GA et est activé par défaut. Si un Secret généré automatiquement et associé à un ServiceAccount n'a pas été utilisé pendant une période donnée (un an par défaut) et n'est monté par aucun pod, le kube-controller-manager ajoute le libellé kubernetes.io/legacy-token-invalid-since au Secret avec la date actuelle comme valeur, marquant ainsi le Secret comme invalide. Si un Secret reste inutilisé pendant une période donnée (un an par défaut) après avoir été marqué comme invalide, le kube-controller-manager le nettoie automatiquement. Pour les Secrets marqués comme invalides mais pas encore supprimés automatiquement, retirez le libellé kubernetes.io/legacy-token-invalid-since afin de les rendre à nouveau valides. Pour plus d'informations, consultez Auto-generated legacy ServiceAccount token clean up et Legacy ServiceAccount token cleaner.

Dans la version 1.30, si l'indicateur --nodeport-addresses de kube-proxy n'est pas défini (comportement par défaut), les mises à jour d'un Service NodePort affectent uniquement l'adresse IP principale du nœud, et non toutes ses adresses IP. Pour plus d'informations, consultez #122724.

Afin d'éviter les conflits de configuration et les problèmes de sécurité, l'URL de l'émetteur OIDC ne doit pas être identique à l'URL de l'émetteur ServiceAccount de l'API server. Pour plus d'informations, consultez #123561.

Le feature gate LoadBalancerIPMode ajoute le champ .status.loadBalancer.ingress.ipMode aux Services de type LoadBalancer. Ce champ spécifie le comportement de transfert de l'IP de l'équilibreur de charge. Vous ne pouvez spécifier ce champ que si le champ .status.loadBalancer.ingress.ip est également spécifié. Le feature gate LoadBalancerIPMode est désormais en phase Beta. Pour plus d'informations, consultez Specifying IPMode of load balancer status et Load Balancer IP Mode for Services.

Le Horizontal Pod Autoscaling (HPA) basé sur les métriques ContainerResource est passé en phase Stable dans la version 1.30. Cette fonctionnalité permet au HPA de mettre à l'échelle en fonction de l'utilisation des ressources de conteneurs individuels au sein d'un pod, plutôt que de se baser uniquement sur l'utilisation globale des ressources du pod. Il devient ainsi plus simple de configurer des seuils de mise à l'échelle pour les conteneurs les plus critiques d'un pod. Pour plus d'informations, consultez Container resource metrics.

Le feature gate AdmissionWebhookMatchConditions a atteint le stade de disponibilité générale (GA). Il est activé par défaut et ne peut plus être désactivé. Ce feature gate permet de faire correspondre les webhooks d'admission en fonction de conditions spécifiques, offrant ainsi un contrôle plus granulaire sur leurs conditions de déclenchement. Pour plus d'informations, consultez Dynamic Admission Control.

Un feature gate JobSuccessPolicy a été ajouté. Il permet de déclarer qu'un Job est terminé avec succès en se basant sur un ensemble de pods réussis. Dans la politique de succès, vous pouvez spécifier que le Job est terminé en fonction de certains index (par exemple, les index des pods x, y et z) ou d'un nombre de pods réussis issus d'un ensemble d'index (par exemple, trois pods). Ce feature gate est en phase Alpha. Pour plus d'informations, consultez Job success/completion policy.

Le feature gate RelaxedEnvironmentVariableValidation a été ajouté pour autoriser l'utilisation de la plupart des caractères ASCII imprimables dans les variables d'environnement (tous les caractères de 32 à 126, à l'exception de =). Ce feature gate est en phase Alpha et désactivé par défaut. Pour plus d'informations, consultez #123385.

Le feature gate CustomResourceFieldSelectors a été ajouté. Il permet de configurer des selectableFields pour les CRD. Vous pouvez ainsi utiliser des Field Selectors pour filtrer les requêtes List, Watch et DeleteCollection, facilitant ainsi la localisation ou la gestion des ressources CRD répondant à des critères spécifiques. Ce feature gate est en phase Alpha et désactivé par défaut. Pour plus d'informations, consultez Custom Resource Field Selectors.

Le feature gate CRDValidationRatcheting introduit une mise à jour importante. Lorsqu'une nouvelle validation est ajoutée à un CRD, les ressources existantes peuvent devenir invalides. Toutefois, l'API Server ne bloque pas les mises à jour de ces ressources tant que les parties échouant à la validation ne sont pas modifiées. Ce changement évite toute perturbation pour les ressources et les utilisateurs existants. Il facilite la validation lors de la migration des CRD vers l'utilisation de schémas OpenAPI v3 et permet de mettre à jour les règles de validation en toute sécurité. Ce feature gate est en phase Beta et activé par défaut. Pour plus d'informations, consultez CRD Validation ratcheting.

La Downward API utilise le champ status.hostIPs pour prendre en charge la double pile (IPv4 et IPv6). La première adresse IP de la liste status.hostIPs est toujours identique à status.hostIP. Pour plus d'informations, consultez Downward API.

Le feature gate NodeLogQuery permet d'interroger les journaux des services de nœud via l'endpoint /logs. Ce feature gate passe en phase Beta et est désactivé par défaut. Pour plus d'informations, consultez Log Query.

CronJob ne prend plus en charge la définition de CRON_TZ ou TZ dans .spec.schedule. Utilisez plutôt le champ .spec.timeZone, disponible depuis la version 1.25. Pour plus d'informations, consultez CronJob limitations.

L'API controversée networking/v1alpha1 ClusterCIDR a été supprimée. Elle était en phase Alpha. Pour plus d'informations, consultez ClusterCIDR v1alpha1.

Le paramètre --prune-whitelist a été retiré de la commande kubectl apply. Utilisez --prune-allowlist à la place. Pour plus d'informations, consultez --prune.

Le plug-in d'admission SecurityContextDeny, rendu obsolète dans la version 1.27, a été supprimé du code dans la version 1.30. Utilisez le plug-in d'admission PodSecurity à la place. Ce dernier est devenu Stable dans la version 1.25 et est activé par défaut. Pour plus d'informations, consultez PodSecurity.