Mise à niveau d’Amazon Linux 2 vers Amazon Linux 2023

AL2023 introduit un nouveau processus d'initialisation des nœuds nodeadm qui utilise un schéma de configuration YAML. Si vous utilisez des groupes de nœuds autogérés ou une AMI avec un modèle de lancement, vous devez désormais fournir explicitement des métadonnées de cluster supplémentaires lors de la création d’un nouveau groupe de nœuds. Un exemple des paramètres minimum requis est présenté ci-dessous, où apiServerEndpoint, certificateAuthority et le service cidr sont désormais obligatoires :

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16

Dans AL2, les métadonnées de ces paramètres ont été découvertes à partir de l'appel d'DescribeClusterAPI Amazon EKS. Avec AL2 023, ce comportement a changé car l'appel d'API supplémentaire risque d'être limité lors de la mise à l'échelle de nœuds à grande échelle. Cette modification ne vous affecte pas si vous utilisez des groupes de nœuds gérés sans modèle de lancement, ou si vous utilisez Karpenter. Pour plus d’informations sur certificateAuthority et le service cidr, consultez DescribeCluster dans la Référence de l’API Amazon EKS.

Pour AL2 023, modifie nodeadm également le format pour appliquer des paramètres à kubelet chaque nœud utilisant NodeConfigSpec. En AL2, cela a été fait avec le --kubelet-extra-args paramètre. Ceci est couramment utilisé pour ajouter des étiquettes et des rejets aux nœuds. L’exemple ci-dessous illustre l’application de maxPods et --node-labels sur le nœud.

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: test-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
  kubelet:
    config:
      maxPods: 110
    flags:
      - --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test

La version CNI d'Amazon VPC 1.16.2 ou supérieure est requise pour 023. AL2

AL2023 nécessite IMDSv2 par défaut. IMDSv2présente plusieurs avantages qui contribuent à améliorer la posture de sécurité. Il utilise une méthode d’authentification orientée session qui nécessite la création d’un jeton secret dans une simple requête HTTP PUT pour démarrer la session. La durée de validité du jeton de session peut avoir une valeur quelconque entre 1 seconde et 6 heures. Pour plus d'informations sur la manière de passer de IMDSv1 àIMDSv2, consultez Transition vers l'utilisation du service de métadonnées d'instance version 2 et Profitez pleinement des avantages de votre AWS infrastructure IMDSv2 et désactivez-la IMDSv1 dans l'ensemble de celle-ci. Si vous souhaitez continuer à utiliser IMDSv1, vous pouvez le faire en surchargant manuellement les paramètres via les propriétés de lancement de l’instance.

AL2023 propose la nouvelle génération de hiérarchie unifiée des groupes de contrôle (cgroupv2). cgroupv2est utilisé pour implémenter un environnement d'exécution de conteneur, et parsystemd. Bien que AL2 023 contienne toujours du code permettant au système de fonctionner en utilisantcgroupv1, cette configuration n'est ni recommandée ni prise en charge. Cette configuration sera complètement supprimée dans une prochaine version majeure d’Amazon Linux.

eksctlune version 0.176.0 ou supérieure est requise pour eksctl prendre en charge la version AL2 023.

Si vous utilisez une AMI personnalisée avec un groupe de nœuds gérés, vous pouvez effectuer une mise à niveau sur place en remplaçant l’ID de l’AMI dans le modèle de lancement. Vous devez d'abord vous assurer que vos applications et toutes les données utilisateur sont transférées vers AL2 023 avant d'exécuter cette stratégie de mise à niveau.

Si vous utilisez des groupes de nœuds gérés avec le modèle de lancement standard ou avec un modèle de lancement personnalisé qui ne précise pas l'ID de l'AMI, vous devez effectuer une mise à niveau à l'aide d'une blue/green stratégie. Une blue/green mise à niveau est généralement plus complexe et implique la création d'un tout nouveau groupe de nœuds dans lequel vous devez spécifier AL2 023 comme type d'AMI. Le nouveau groupe de nœuds devra ensuite être configuré avec soin pour garantir que toutes les données personnalisées du groupe de AL2 nœuds sont compatibles avec le nouveau système d'exploitation. Une fois le nouveau groupe de nœuds testé et validé avec vos applications, vous pouvez migrer les pods de l’ancien groupe vers le nouveau. Après la migration, vous pouvez supprimer l’ancien groupe de nœuds.