Upgrade von Amazon Linux 2 zu Amazon Linux 2023

AL2023 führt einen neuen Knoteninitialisierungsprozess einnodeadm, 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

AL2In wurden die Metadaten dieser Parameter aus dem Amazon DescribeCluster EKS-API-Aufruf ermittelt. Mit hat sich dieses Verhalten geändert AL2023, da durch den zusätzlichen API-Aufruf die Gefahr einer Drosselung bei der Skalierung großer Knoten besteht. 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.

Denn ändert nodeadm auch das Format AL2023, in dem Parameter kubelet für jeden verwendeten Knoten angewendet werden. NodeConfigSpec In AL2, das wurde mit dem --kubelet-extra-args Parameter gemacht. 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

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

AL2023 erfordert IMDSv2 standardmäßig. IMDSv2hat 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 Umstellung auf Instance Metadata Service Version 2 und Nutzen Sie alle Vorteile IMDSv2 und deaktivieren Sie Ihre IMDSv1 gesamte 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 einheitlicher Kontrollgruppenhierarchien (cgroupv2). cgroupv2wird verwendet, um eine Container-Laufzeit zu implementieren, und vonsystemd. Es enthält zwar AL2023 immer noch Code, mit dem das System zum Laufen gebracht werden kanncgroupv1, ist aber keine empfohlene oder unterstützte Konfiguration. Diese Konfiguration wird in einer zukünftigen Hauptversion von Amazon Linux vollständig entfernt.

eksctlFür eksctl die Unterstützung ist eine Version 0.176.0 oder höher erforderlich AL2023.

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. Sie sollten sicherstellen, dass Ihre Anwendungen und alle Benutzerdaten an AL2023 First übertragen werden, bevor Sie diese Upgrade-Strategie durchführen.

Wenn Sie verwaltete Knotengruppen entweder mit der Standardstartvorlage oder mit einer benutzerdefinierten Startvorlage verwenden, die die AMI-ID nicht angibt, müssen Sie das Upgrade mithilfe einer blue/green Strategie durchführen. Ein blue/green Upgrade ist in der Regel komplexer und beinhaltet die Erstellung einer völlig neuen Knotengruppe, die 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.