Comment ajouter une authentification de base HTTP à une entrée Kubernetes NGINX - CloudSavvy IT
Agence web » Actualités du digital » Quoi de neuf dans Kubernetes v1.23 ? – CloudSavvy IT

Quoi de neuf dans Kubernetes v1.23 ? – CloudSavvy IT

Kubernetes v1.23 est la dernière version majeure de 2021. La dernière mise à jour de la principale plate-forme d’orchestration de conteneurs promeut 11 fonctionnalités sur le canal stable, les marquant comme adaptées à un usage général. Voici ce que vous devez savoir avant de procéder à la mise à niveau.

Mise en réseau IPv4/IPv6 à double pile

La mise en réseau IPv4/IPv6 à double pile est généralement disponible dans la v1.23. La fonctionnalité permet d’attribuer à un Pod ou à un Service des adresses IPv4 et IPv6. Vous avez besoin d’interfaces réseau à double pile sur vos nœuds et d’un plug-in de mise en réseau CNI pour que cela fonctionne.

le .spec.ipFamilyPolicy Le champ définit si un pod ou un service reçoit une interface simple ou double pile. Réglez-le sur PreferDualStack ou RequireDualStack pour activer la prise en charge de la double pile. La valeur par défaut est SingleStack.

spec:
    ipFamilyPolicy: RequireDualStack

Les modes à double pile alloueront des adresses IP de cluster de services à partir des espaces d’adressage IPv4 et IPv6. Vous pouvez définir l’ordre de préférence de la pile avec le .spec.ipFamilies domaine. Cela permet également de spécifier IPv4 ou IPv6 comme famille pour le SingleStack mode.

Volumes éphémères

Les volumes éphémères sont une autre graduation au statut GA. Un volume éphémère est lié à un pod et est supprimé lorsque le pod se termine. Il fonctionne avec tous les pilotes de stockage existants qui prennent en charge le provisionnement dynamique.

Les volumes éphémères sont créés en imbriquant un volumeClaimTemplate sous un nouveau ephemeral terrain dans le volumes section d’une spécification de pod. le volumeClaimTemplate devrait ressembler à un PersistentVolumeClaim normal.

spec:
  volumes:
    - name: ephemeral-volume
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              type: example-volume-type
          spec:
            accessModes: ["ReadWriteOnce"]
            storageClassName: example-storage-class
            resources:
              requests:
                storage: 1Gi

Bien qu’un volume « éphémère » puisse sembler étrange au départ, il existe plusieurs cas d’utilisation pour cette fonctionnalité. Les volumes sont souvent utilisés pour fournir au processus d’un pod des valeurs de configuration de première exécution qui ne sont accessibles qu’une seule fois. Dans ce scénario, un pod éphémère est idéal car il sera supprimé lorsque le pod s’arrêtera, au lieu d’être rattaché aux futurs pods qui n’utiliseront jamais les données. Un autre cas possible concerne les processus qui mettent en cache de grandes quantités de données mais n’ont pas besoin qu’elles soient persistantes entre les terminaisons individuelles des pods.

Pod horizontal Autoscaler v2

Après cinq ans, la v2 de l’API Horizontal Pod Autoscaler est devenue stable. L’autoscaling permet à Kubernetes d’ajuster automatiquement le nombre de réplicas de vos déploiements, ReplicaSets et StatefulSets pour répondre aux changements de métriques en temps réel.

Cette promotion n’affecte actuellement pas la mise en œuvre de l’autoscaler d’origine. L’API v1 reste utilisable et n’est pas obsolète. Le nouveau autoscaling/v2 L’API prend le relais de la autoscaling/v2beta2 des versions précédentes de Kubernetes.

L’utilisation de l’API v2 est avantageuse car vous pouvez définir des décisions d’autoscaling basées sur des métriques personnalisées. Le contrôleur de l’autoscaler effectuera des requêtes API arbitraires pour informer les modifications de réplica, au lieu de vous limiter aux conditions de CPU et de mémoire du nœud.

Ignorer les changements de propriété du volume au démarrage du pod

En utilisant le fsGroup champ sur un volume pour définir sa propriété provoque actuellement l’exécution récursive de Kubernetes chown() et chmod() sur le contenu du volume chaque fois qu’il est monté sur un pod. Cela peut être un problème de performances important lorsque vous travaillez avec de gros volumes composés principalement de petits fichiers. Le Pod ne démarrera pas tant que les autorisations n’auront pas été modifiées.

Kubernetes prend en charge un fsGroupChangePolicy champ qui vous permet de remplacer ce comportement. Il est maintenant généralement disponible via un Pod securityContextdomaine. Définir la politique de modification sur OnRootMismatch appellera seulement chown() si la racine du volume a des autorisations incorrectes. Cela accélère le démarrage du pod lorsque les autorisations sont déjà compatibles avec le fsGroup déclaration.

securityContext:
  fsGroupChangePolicy: OnRootMismatch

Autres faits saillants

Il y a quelques ajouts notables aux API alpha et bêta. La version bêta comprend désormais :

  • Journalisation structurée – Plus de composants prennent en charge le format de journalisation de texte structuré qui produit une sortie JSON. Les journaux structurés sont plus facilement analysables par des outils externes, ce qui simplifie les processus d’ingestion et de requête des journaux.
  • API PodSecurityPodSecurity remplace l’ancien PodSecurityPolicy contrôleur d’admission qui vous permet d’appliquer des règles de sécurité au niveau de l’espace de noms. PodSecurity fournit un mécanisme pour stipuler que les pods ne peuvent pas exister dans un espace de noms s’ils manquent de certaines protections de contexte de sécurité.
  • Prise en charge de la migration CSI – Cette fonctionnalité offre un moyen transparent de passer d’un pilote de stockage dans l’arborescence qui fait partie de l’API Kubernetes, tel que kubernetes.io/aws-ebs, à un pilote CSI du fournisseur. Les utilisateurs ne devraient remarquer aucune modification de leur stockage une fois la migration terminée. Cette fonctionnalité est désormais en version bêta pour AWS EBS, Azure Disk et GCE PD. Il est étiqueté alpha pour Ceph RBD et Portworx.

Dans le canal alpha, certaines fonctionnalités supplémentaires font leurs débuts :

  • Validation des champs côté serveur – La validation de champ côté serveur envoie des avertissements du serveur lorsqu’un client essaie de créer des ressources qui incluent des champs inconnus ou dupliqués. Kubernetes a historiquement abandonné ces champs, provoquant potentiellement un comportement déroutant. Activer le ServerSideFeatureValidation feature gate fournit un moyen de résoudre ce problème.
  • Validation du langage d’expression pour les CRD – Un nouveau langage d’expression en ligne facilite la validation des définitions de ressources personnalisées (CRD). Cela permet de remédier à la nature abstraite des CRD où les ressources définies par l’utilisateur ne peuvent actuellement pas être garanties pour respecter les exigences des contrôleurs existants et des applications clientes.
  • Prise en charge d’OpenAPI v3 – OpenAPI v3 a été ajouté derrière une porte de fonctionnalité (OpenAPIV3). Lorsqu’elle est activée, vous pouvez demander la spécification OpenAPI v3.0 pour n’importe quel type d’objet Kubernetes, offrant ainsi un moyen de découvrir et de parcourir les ressources par programmation via des normes d’API ouvertes.

Conclusion

Kubernetes v1.23 stabilise plusieurs fonctionnalités importantes, notamment la mise en réseau à double pile, le nouvel autoscaler horizontal personnalisable et les volumes éphémères pour travailler avec des données non critiques. Il y a aussi des dizaines d’autres changements, en plus de deux dépréciations : le FlexVolume interface de pilote de stockage antérieure à CSI et plusieurs indicateurs de journalisation qui seront supprimés à l’avenir.

Au total, 11 fonctionnalités existantes ont été promues au statut GA. 17 autres capacités sont désormais marquées comme bêta, tandis que 19 autres sont de toutes nouvelles capacités atterrissant en alpha. La stratégie de publication de Kubernetes se concentre sur la fonctionnalité d’expédition dès le début, permet à la communauté de guider son développement et d’aider à rationaliser les implémentations d’API. Bien que les fonctionnalités alpha ou bêta soient généralement stables, cela n’est pas garanti. Les API peuvent changer de manière significative ou être entièrement supprimées au cours du processus de développement.

Vous pouvez lire les notes de version complètes de la v1.23 sur GitHub. Les téléchargements sont disponibles sur la page des versions. Vous pouvez mettre à niveau un cluster existant qui a été créé à l’aide de Kubeadm en suivant les instructions de la documentation. Le processus sera différent pour les utilisateurs d’offres cloud gérées et de distributions Kubernetes tierces.

★★★★★