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

AL2023 introduit un nouveau processus nodeadm d’initialisation de nœud qui utilise un schéma de configuration YAML. Si vous utilisez des groupes de nœuds autogérés ou un modèle de lancement qui spécifie un ID AMI personnalisé, vous devez désormais fournir explicitement des métadonnées de cluster supplémentaires. Vous devez fournir ces métadonnées lors de la création d'un nouveau groupe de nœuds. Voici un exemple de paramètres minimaux requis pour nodeadm, où apiServerEndpointcertificateAuthority, et le service cidr sont désormais requis :

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

Avec AL2, les métadonnées issues de ces paramètres étaient détectées via l’appel d’API DescribeCluster d’Amazon EKS. Avec AL2023, ce comportement a changé, car l’appel d’API supplémentaire risque d’entraîner une limitation lors des augmentations verticales du nombre de nœuds. 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 en savoir plus sur certificateAuthority et le service cidr, consultez DescribeCluster dans la Référence API Amazon EKS.

Pour AL2023, nodeadm modifie également le format pour appliquer les paramètres au service kubelet sur chaque nœud utilisant NodeConfigSpec. Dans AL2, cela se faisait au moyen du paramètre --kubelet-extra-args. 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 1.16.2 ou ultérieure de Amazon VPC CNI est requise pour AL2023.

AL2023 impose par défaut l’utilisation d’IMDSv2. IMDSv2 présente plusieurs avantages qui améliorent 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 façon de passer de IMDSv1 àIMDSv2, consultez Transition vers l'utilisation du service de métadonnées d'instance version 2 et Profitez de tous les avantages de l'IMDSv2 et désactivez IMDSv1 sur l'ensemble de votre infrastructure. AWS 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 utilise la nouvelle génération de hiérarchie unifiée des groupes de contrôle (cgroupv2). cgroupv2 est utilisé par défaut pour mettre en œuvre l’exécution de conteneur, et par systemd. Bien qu’AL2023 inclue encore le code permettant d’exécuter le système en cgroupv1, cette configuration n’est plus recommandée ni prise en charge. Cette configuration sera complètement supprimée dans une prochaine version majeure d’Amazon Linux.

La version 0.176.0 ou ultérieure d’eksctl est requise pour eksctl pour que AL2023 soit pris en charge.

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. Assurez-vous d’abord que vos applications et vos données utilisateur fonctionnent correctement avec AL2023 avant de mettre à niveau cette stratégie.

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 spécifie pas l'ID AMI, vous devez effectuer la 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 AL2023 comme type d'AMI. Le nouveau groupe de nœuds doit ensuite être configuré avec soin pour garantir que toutes les données personnalisées du groupe de nœuds AL2 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.