Upgrade von Amazon Linux 2 zu Amazon Linux 2023

AL2023 führt einen neuen nodeadm-Prozess zur Knoteninitialisierung ein, der ein YAML-Konfigurationsschema verwendet. Wenn Sie selbstverwaltete Knotengruppen oder eine AMI mit einer Startvorlage verwenden, müssen Sie nun beim Erstellen einer neuen Knotengruppe explizit zusätzliche Cluster-Metadaten angeben. Ein Beispiel für die mindestens erforderlichen Parameter ist wie folgt, wobei jetzt apiServerEndpoint, certificateAuthority und Service-cidr erforderlich sind:

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

In AL2 wurden die Metadaten dieser Parameter über den DescribeCluster-API-Aufruf von Amazon EKS ermittelt. Mit AL2023 hat sich dieses Verhalten geändert, da der zusätzliche API-Aufruf bei Knoten-Hochskalierungen zu Drosselungen führen kann. Diese Änderung betrifft Sie nicht, wenn Sie verwaltete Knotengruppen ohne Startvorlage verwenden oder wenn Sie Karpenter verwenden. Weitere Informationen zu certificateAuthority und Service cidr finden Sie unter DescribeCluster in der API-Referenz von Amazon EKS.

Für AL2023 ändert nodeadm auch das Format, um Parameter für jeden Knoten unter Verwendung von NodeConfigSpec auf das kubelet anzuwenden. In AL2 wurde dies mit dem --kubelet-extra-args-Parameter erreicht. Dies wird häufig verwendet, um Knoten mit Beschriftungen und Taints zu versehen. Ein Beispiel unten zeigt die Anwendung von maxPods und --node-labels auf den Knoten.

---
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

Für AL2023 ist die Amazon-VPC-CNI-Version 1.16.2 oder höher erforderlich.

AL2023 erfordert standardmäßig IMDSv2. IMDSv2 bietet mehrere Vorteile, die zur Verbesserung der Sicherheitslage beitragen. Das Programm verwendet eine sitzungsorientierte Authentifizierungsmethode, welche die Erstellung eines geheimen Tokens in einer einfachen HTTP-PUT-Anfrage zum Starten der Sitzung erfordert. Die Gültigkeitsdauer eines Sitzungs-Tokens kann zwischen 1 Sekunde und 6 Stunden variieren. Weitere Informationen zum Übergang von IMDSv1 zu IMDSv2 finden Sie unter Übergang zur Verwendung von Instance Metadata Service Version 2 und Nutzung aller Vorteile von IMDSv2 und Deaktivierung von IMDSv1 in Ihrer gesamten AWS-Infrastruktur. Wenn Sie IMDSv1 verwenden möchten, können Sie dies dennoch tun, indem Sie die Einstellungen mithilfe der Starteigenschaften der Instance-Metadatenoption manuell überschreiben.

AL2023 bietet die nächste Generation der einheitlichen Kontrollgruppen-Hierarchie (cgroupv2). cgroupv2 wird zur Implementierung einer Container-Laufzeit verwendet, und von systemd. Obwohl AL2023 weiterhin Code enthält, der das System mit cgroupv1 ausführen kann, ist dies keine empfohlene oder unterstützte Konfiguration. Diese Konfiguration wird in einer zukünftigen Hauptversion von Amazon Linux vollständig entfernt.

eksctl-Version 0.176.0 oder höher ist erforderlich, damit eksctl AL2023 unterstützt.

Wenn Sie ein benutzerdefiniertes AMI mit einer verwalteten Knotengruppe verwenden, können Sie ein direktes Upgrade durchführen, indem Sie die AMI-ID in der Startvorlage austauschen. Stellen Sie sicher, dass Ihre Anwendungen und alle Benutzerdaten zunächst auf AL2023 übertragen werden, bevor Sie diese Upgrade-Strategie durchführen.

Wenn Sie verwaltete Knotengruppen mit der Standard-Startvorlage oder mit einer benutzerdefinierten Startvorlage verwenden, die keine AMI-ID angibt, müssen Sie das Upgrade mithilfe einer Blau/Grün-Strategie durchführen. Ein Blau/Grün-Upgrade ist in der Regel komplexer und erfordert die Erstellung einer vollständig neuen Knotengruppe, in der Sie AL2023 als AMI-Typ angeben würden. Die neue Knotengruppe muss anschließend sorgfältig konfiguriert werden, um sicherzustellen, dass alle benutzerdefinierten Daten aus der AL2-Knotengruppe mit dem neuen Betriebssystem kompatibel sind. Sobald die neue Knotengruppe mit Ihren Anwendungen getestet und validiert wurde, können Pods von der alten Knotengruppe auf die neue Knotengruppe migriert werden. Nach Abschluss der Migration können Sie die alte Knotengruppe löschen.