Aktualisieren Sie das selbstverwaltete Kubernetes-Add-on kube-proxy - Amazon EKS
VoraussetzungenÜberlegungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Aktualisieren Sie das selbstverwaltete Kubernetes-Add-on kube-proxy

Wichtig

Wir empfehlen, den EKS Amazon-Typ des Add-ons zu Ihrem Cluster hinzuzufügen, anstatt den selbstverwalteten Typ des Add-ons zu verwenden. Falls Sie mit dem Unterschied zwischen den Typen nicht vertraut sind, finden Sie weitere Informationen unterEKSAmazon-Add-Ons. Weitere Informationen zum Hinzufügen eines EKS Amazon-Add-ons zu Ihrem Cluster finden Sie unterEin EKS Amazon-Add-on erstellen. Wenn Sie das EKS Amazon-Add-on nicht verwenden können, empfehlen wir Ihnen, ein Problem mit der Begründung einzureichen, warum Sie das nicht können, an das GitHub Container-Roadmap-Repository.

Voraussetzungen

Überlegungen

  • Kube-proxyhat auf einem EKS Amazon-Cluster dieselbe Kompatibilitäts- und Schrägstellungsrichtlinie wie Kubernetes. Erfahren Sie, wie Sie die Kompatibilität der EKS Amazon-Add-On-Version mit einem Cluster überprüfen können.

    1. Vergewissern Sie sich, dass Sie das selbstverwaltete Add-On auf Ihrem Cluster installiert haben. Ersetzen my-cluster mit dem Namen Ihres Clusters.

      aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text

      Wenn Sie eine Fehlermeldung erhalten, wird das Add-On als selbstverwaltetes Add-On auf Ihrem Cluster installiert. Die verbleibenden Schritte in diesem Thema beziehen sich auf die Aktualisierung des selbstverwalteten Typs des Add-Ons. Wenn eine Versionsnummer zurückgegeben wird, haben Sie den EKS Amazon-Typ des Add-ons auf Ihrem Cluster installiert. Um es zu aktualisieren, verwenden Sie das unter Aktualisieren eines EKS Amazon-Add-ons beschriebene Verfahren, anstatt das Verfahren in diesem Thema zu verwenden. Wenn Sie mit den Unterschieden zwischen den Add-On-Typen nicht vertraut sind, finden Sie weitere Informationen unterEKSAmazon-Add-Ons.

    2. Sehen Sie, welche Version des Container-Images derzeit auf Ihrem Cluster installiert ist.

      kubectl describe daemonset kube-proxy -n kube-system | grep Image

      Eine Beispielausgabe sieht wie folgt aus.

      Image:    602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.29.1-eksbuild.2

      In der Beispielausgabe v1.29.1-eksbuild.2 ist die auf dem Cluster installierte Version.

    3. Aktualisieren Sie das kube-proxy Add-on, indem Sie es ersetzen 602401143452 and region-code mit den Werten aus Ihrer Ausgabe im vorherigen Schritt. Ersetzen v1.30.6-eksbuild.3 mit der kube-proxy Version, die in der Tabelle Letzte verfügbare selbstverwaltete Kube-Proxy-Container-Image-Version für jede EKS Amazon-Cluster-Version aufgeführt ist.

      Wichtig

      Die Manifeste für jeden Image-Typ sind unterschiedlich und zwischen den Standard - und Minimal-Image-Typen nicht kompatibel. Sie müssen denselben Bildtyp wie das vorherige Bild verwenden, damit der Einstiegspunkt und die Argumente übereinstimmen.

      kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.30.6-eksbuild.3

      Eine Beispielausgabe sieht wie folgt aus.

      daemonset.apps/kube-proxy image updated

    4. Vergewissern Sie sich, dass die neue Version jetzt auf Ihrem Cluster installiert ist.

      kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3

      Eine Beispielausgabe sieht wie folgt aus.

      v1.30.0-eksbuild.3

    5. Wenn Sie Arm and-Knoten im selben Cluster verwenden x86 und Ihr Cluster vor dem 17. August 2020 bereitgestellt wurde. Bearbeiten Sie dann Ihr kube-proxy-Manifest, um einen Knotenselektor für mehrere Hardwarearchitekturen mit dem folgenden Befehl einzuschließen. Dies ist ein einmaliger Vorgang. Nachdem Sie den Selektor zu Ihrem Manifest hinzugefügt haben, müssen Sie ihn nicht jedes Mal hinzufügen, wenn Sie das Add-on aktualisieren. Wenn Ihr Cluster am oder nach dem 17. August 2020 bereitgestellt wurde, ist kube-proxy bereits Multi-Architektur-fähig.

      kubectl edit -n kube-system daemonset/kube-proxy

      Fügen Sie der Datei im Editor den folgenden Knotenselektor hinzu und speichern Sie die Datei. Ein Beispiel dafür, wo Sie diesen Text in den Editor einfügen können, finden Sie in der CNIManifestdatei unter GitHub. Das ermöglicht Kubernetes um das richtige Hardware-Image basierend auf der Hardwarearchitektur des Knotens abzurufen.

      - key: "kubernetes.io/arch"
  operator: In
  values:
  - amd64
  - arm64

    6. Wenn Ihr Cluster ursprünglich mit erstellt wurde Kubernetes Version 1.14 oder höher, dann können Sie diesen Schritt überspringen, da er kube-proxy bereits enthalten istAffinity Rule. Wenn Sie ursprünglich einen EKS Amazon-Cluster erstellt haben mit Kubernetes Version 1.13 oder früher und beabsichtigen, Fargate-Knoten in Ihrem Cluster zu verwenden. Bearbeiten Sie dann Ihr kube-proxy Manifest so, dass es eine NodeAffinity Regel enthält, die verhindert kube-proxy Pods aus der Terminplanung auf Fargate-Knoten. Dies ist eine einmalige Bearbeitung. Sobald Sie das Affinity Rule zu Ihrem Manifest hinzugefügt haben, müssen Sie es nicht jedes Mal hinzufügen, wenn Sie das Add-on aktualisieren. Bearbeiten Sie Ihre kube-proxy DaemonSet.

      kubectl edit -n kube-system daemonset/kube-proxy

      Fügen Sie Folgendes Affinity Rule zum DaemonSet`spec` Abschnitt der Datei im Editor und speichern Sie dann die Datei. Ein Beispiel dafür, wo dieser Text in den Editor aufgenommen werden kann, finden Sie in der CNIManifestdatei unter GitHub.

      - key: eks.amazonaws.com/compute-type
  operator: NotIn
  values:
  - fargate