Starten selbstverwalteter Bottlerocket-Knoten - Amazon EKS

Starten selbstverwalteter Bottlerocket-Knoten

Anmerkung

Verwaltete Knotengruppen bieten möglicherweise einige Vorteile für Ihren Anwendungsfall. Weitere Informationen finden Sie unter Verwaltete Knotengruppen.

Dieses Thema beschreibt Hinweise zum Starten von Auto-Scaling-Gruppen von Bottlerocket-Knoten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Bottlerocket ist ein Linux-basiertes Open-Source-Betriebssystem von AWS, mit dem Sie Container auf virtuellen Maschinen oder Bare-Metal-Hosts ausführen können. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. Weitere Informationen zu Bottlerocket finden Sie unter Using a GitHub AMI with Amazon EKS (Verwenden eines Bottlerocket-AMI mit Amazon EKS) auf GitHub und Custom AMI support (Benutzerdefinierter AMI-Support) in der eksctl-Dokumentation.

Weitere Informationen zu direkten Upgrades finden Sie unter Update-Operator für Bottlerocket auf GitHub.

Wichtig

Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen finden Sie unter Amazon EC2 – Preise.

Wichtig
  • Sie können auf Amazon-EC2-Instances mit x86- oder Arm-Prozessoren bereitstellen. Sie können jedoch nicht auf Instances bereitstellen, die über Inferentia-Chips verfügen.

  • Sie können nicht in folgenden Regionen eingesetzt werden: China (Peking) (cn-north-1) oder China (Ningxia) (cn-northwest-1).

  • Es gibt keineAWS CloudFormation-Vorlage zum Bereitstellen von Knoten mit.

  • Bottlerocket-Images werden nicht mit einem SSH-Server oder einer Shell geliefert. Sie können Out-of-Band-Zugriffsmethoden verwenden, um SSH die Aktivierung des Administrator-Containers zu ermöglichen und einige Bootstrapping-Konfigurationsschritte mit Benutzerdaten zu übergeben. Weitere Informationen finden Sie in diesen Abschnitten im bottlerocket README.md auf GitHub:

Bottlerocket-Knoten mit eksctl starten

Für diesen Vorgang ist eksctl Version 0.105.0 oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen:

eksctl version

Anweisungen zum Installieren oder Aktualisieren von eksctl finden Sie unter .

Anmerkung

Dieses Verfahren funktioniert nur für Cluster, die mit eksctl erstellt wurden.

  1. Erstellen Sie eine Datei mit dem Namen bottlerocket.yaml und dem folgenden Inhalt. Ersetzen Sie jede example-value durch Ihre eigenen Werte. Ersetzen Sie my-cluster mit dem Namen Ihres Clusters. Um die Bereitstellung auf Arm-Instances durchzuführen, ersetzen Sie m5.large durch einen Arm-Instance-Typ. Ersetzen Sie my-ec2-keypair-name mit dem Namen eines Amazon-EC2-SSH-Schlüsselpaars ein, das Sie für die Verbindung über SSH in Ihre Arbeitsknoten verwenden können, nachdem sie gestartet wurden. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS Management Console erstellen. Weitere Informationen finden Sie unter Amazon-EC2-Schlüsselpaare im Amazon-EC2-Benutzerhandbuch für Linux-Instances.

    Wenn Sie einen Arm Amazon-EC2-Instance-Typ angeben, überprüfen Sie die Überlegungen inAmazon-EKS-optimierte Arm-Amazon-Linux-AMIsbevor Sie eine Bereitstellung durchführen. Anweisungen zum Bereitstellen mit einem benutzerdefinierten AMI finden Sie unter Building Bottlerocket (Erstellen von Bottlerocket) auf GitHub und Custom AMI support (Benutzerdefinierter AMI-Support) in der eksctl-Dokumentation. Um eine verwaltete Knotengruppe bereitzustellen, stellen Sie ein benutzerdefiniertes AMI mithilfe einer Startvorlage bereit. Weitere Informationen finden Sie unter Support für Startvorlagen.

    Wichtig

    Um einen Knotengruppe in den Subnetzen AWS Outposts, AWS Wavelength oder AWS Local Zone bereitzustellen, übergeben Sie beim Erstellen des Clusters keine AWS Outposts-, AWS Wavelength- oder AWS-Local-Zone-Subnetze. Sie müssen die Subnetze im folgenden Beispiel angeben. Weitere Informationen finden Sie unter Verwenden von Config-Dateien und im Config-Datei-Schema in der eksctl-Dokumentation. Ersetzen Sie region-code durch die AWS-Region, in der sich Ihr Cluster befindet.

    --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code version: '1.22' iam: withOIDC: true nodeGroups: - name: ng-bottlerocket instanceType: m5.large desiredCapacity: 3 amiFamily: Bottlerocket ami: auto-ssm iam: attachPolicyARNs: - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy ssh: allow: true publicKeyName: my-ec2-keypair-name
  2. Stellen Sie den Treiber mit dem folgenden Befehl bereit.

    eksctl create nodegroup --config-file=bottlerocket.yaml

    Die Beispielausgabe lautet wie folgt.

    Mehrere Zeilen werden ausgegeben, während die Knoten erstellt werden. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile.

    [✔] created 1 nodegroup(s) in cluster "my-cluster"
  3. (Optional) Erstellen Sie ein persistentes Kubernetes-Volume auf einem Bottlerocket-Knoten, indem Sie das Amazon-EBS-CSI-Plugin verwenden. Der standardmäßige Amazon-EBS-Treiber basiert auf Dateisystem-Tools, die nicht in Bottlerocket enthalten sind. Weitere Informationen zur Erstellung einer Speicherklasse mit dem Treiber finden Sie unter Amazon-EBS-CSI-Treiber.

  4. (Optional) Standardmäßig setzt kube-proxy den Kernelparameter nf_conntrack_max auf einen Standardwert, der sich von dem unterscheiden kann, was Bottlerocket ursprünglich beim Booten festgelegt hat. Um die Standardeinstellung von Bottlerocket beizubehalten, bearbeiten Sie die kube-proxy-Konfiguration im folgenden Befehl.

    kubectl edit -n kube-system daemonset kube-proxy

    Fügen Sie --conntrack-max-per-core und --conntrack-min zu den kube-proxy-Argumenten im folgenden Beispiel hinzu. Eine Einstellung von0impliziert keine Änderung.

    containers: - command: - kube-proxy - --v=2 - --config=/var/lib/kube-proxy-config/config - --conntrack-max-per-core=0 - --conntrack-min=0
  5. (Optional) Stellen Sie eine Beispielanwendung bereit, um Ihre Bottlerocket-Knoten zu testen.

  6. Wir empfehlen, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind:

    • Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen.

    • Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon-EC2-Instance-Metadaten-Service (IMDS), zum Beispiel zum Abrufen der aktuellen AWS-Region.

    Weitere Informationen finden Sie unter Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist.