Platzieren Sie Kubernetes-Pods auf Amazon mithilfe EKS von Knotenaffinität, Taints und Toleranzen

PDF

Erstellt von Hitesh Parikh () und Raghu Bhamidimarri () AWS AWS

Übersicht

Dieses Muster veranschaulicht die Verwendung von Kubernetes-Knotenaffinität, Node-Taints und Pod-Toleranzen, um Anwendungs-Pods bewusst auf bestimmten Worker-Knoten in einem Amazon Elastic Kubernetes Service (AmazonEKS) -Cluster in der Amazon Web Services () -Cloud zu planen. AWS

Ein Taint ist eine Knoteneigenschaft, die es Knoten ermöglicht, eine Reihe von Pods abzulehnen. Eine Toleranz ist eine Pod-Eigenschaft, die es dem Kubernetes-Scheduler ermöglicht, Pods auf Knoten mit passenden Taints einzuplanen.

Toleranzen allein können einen Scheduler jedoch nicht daran hindern, einen Pod auf einem Worker-Knoten zu platzieren, der keine Makel aufweist. Beispielsweise kann ein rechenintensiver Pod mit einer Toleranz unbeabsichtigt auf einem Allzweckknoten eingeplant werden, der keinen Einfluss hat. In diesem Szenario weist die Eigenschaft „Knotenaffinität“ eines Pods den Scheduler an, den Pod auf einem Knoten zu platzieren, der die in der Knotenaffinität angegebenen Knotenauswahlkriterien erfüllt.

Taints, Tolerations und Node-Affinität zusammen weisen den Scheduler an, Pods konsistent auf den Knoten mit übereinstimmenden Taints und den Knotenbezeichnungen einzuplanen, die den im Pod angegebenen Auswahlkriterien für die Knotenaffinität entsprechen.

Dieses Muster enthält ein Beispiel für eine Manifestdatei für die Kubernetes-Bereitstellung und die Schritte zum Erstellen eines Clusters, zum Bereitstellen einer EKS Anwendung und zum Überprüfen der Pod-Platzierung.

Voraussetzungen und Einschränkungen

Voraussetzungen

• Ein AWS Konto mit Anmeldeinformationen, die so konfiguriert sind, dass Ressourcen in Ihrem Konto erstellt werden AWS

• AWSBefehlszeilenschnittstelle (AWSCLI)

• eksctl

• kubectl

• Docker wurde installiert (für das verwendete Betriebssystem) und die Engine wurde gestartet (Informationen zu den Docker-Lizenzanforderungen finden Sie auf der Docker-Website)

• Java-Version 11 oder höher

• Ein Java-Microservice, der in Ihrer bevorzugten integrierten Entwicklungsumgebung (IDE) ausgeführt wird, z. B. IntelliJ IDEA Community Edition oder Eclipse (falls Sie keinen Java-Microservice haben, finden Sie unter Deploy a sample java microservice on Amazon EKS pattern and Microservices with Spring Hilfe bei der Erstellung des Microservices)

Einschränkungen

• Dieses Muster enthält keinen Java-Code und es wird davon ausgegangen, dass Sie bereits mit Java vertraut sind. Informationen zum Erstellen eines grundlegenden Java-Microservices finden Sie unter Bereitstellen eines Java-Microservices auf Amazon als Beispiel. EKS

• Mit den Schritten in diesem Artikel werden AWS Ressourcen erstellt, für die Kosten anfallen können. Stellen Sie sicher, dass Sie die AWS Ressourcen bereinigen, nachdem Sie die Schritte zur Implementierung und Validierung des Musters abgeschlossen haben.

Architektur

Zieltechnologie-Stack

• Amazon EKS

• Java

• Docker

• Amazon Elastic Container Registry (AmazonECR)

Zielarchitektur

Das Lösungsarchitekturdiagramm zeigt Amazon EKS mit zwei Pods (Deployment 1 und Deployment 2) und zwei Knotengruppen (ng1 und ng2) mit jeweils zwei Knoten. Die Pods und Knoten haben die folgenden Eigenschaften.

	Bereitstellung: 1 Pod	Bereitstellung 2 Pod	Knotengruppe 1 (ng1)	Knotengruppe 2 (ng2)
Toleranz	Schlüssel: classified_workload, Wert: true, Effekt: NoSchedule Schlüssel: machine_learning_workload, Wert: true, Effekt: NoSchedule	None
Knotenaffinität	Schlüssel: alpha.eksctl.io/nodegroup-name = ng1;	None	nodeGroups.name = ng1
Makel			Schlüssel: classified_workload, Wert: true, Effekt: NoSchedule Schlüssel: machine_learning_workload, Wert: true, Effekt: NoSchedule	None

1. Für den Deployment 1-Pod sind Toleranzen und eine Knotenaffinität definiert. Dadurch wird der Kubernetes-Scheduler angewiesen, die Bereitstellungs-Pods auf den Knoten der Knotengruppe 1 (ng1) zu platzieren.

2. Die Knotengruppe 2 (ng2) hat kein Knotenlabel, das dem Knotenauswahlausdruck für die Knotenaffinität für Deployment 1 entspricht, sodass die Pods nicht auf ng2-Knoten geplant werden.

3. Für den Deployment 2-Pod sind keine Toleranzen oder Knotenaffinität im Bereitstellungsmanifest definiert. Der Scheduler lehnt die Planung von Deployment 2-Pods auf Knotengruppe 1 aufgrund der Schwachstellen auf den Knoten ab.

4. Die Deployment 2-Pods werden stattdessen auf Knotengruppe 2 platziert, da die Knoten keine Makel aufweisen.

Dieses Muster zeigt, dass Sie mithilfe von Taints und Toleranzen in Kombination mit der Knotenaffinität die Platzierung von Pods auf bestimmten Gruppen von Worker-Knoten kontrollieren können.

Tools

AWS-Services

• AWSCommand Line Interface (AWSCLI) ist ein Open-Source-Tool, mit dem Sie mithilfe von Befehlen in Ihrer AWS Befehlszeilen-Shell mit Diensten interagieren können.

• Amazon Elastic Container Registry (AmazonECR) ist ein verwalteter Container-Image-Registry-Service, der sicher, skalierbar und zuverlässig ist.

• Mit Amazon Elastic Kubernetes Service (AmazonEKS) können Sie Kubernetes ausführen, AWS ohne dass Sie Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten müssen.

• eksctl entspricht kubectl und hilft beim Erstellen. AWS EKS

Andere Tools

• Docker ist eine Reihe von Platform-as-a-Service (PaaS) -Produkten, die Virtualisierung auf Betriebssystemebene nutzen, um Software in Containern bereitzustellen.

• kubectl ist eine Befehlszeilenschnittstelle, mit der Sie Befehle für Kubernetes-Cluster ausführen können.

Epen

Erstellen Sie den Cluster EKS

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie die Datei cluster.yaml.	Erstellen Sie eine Datei cluster.yaml mit dem folgenden Code. apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-taint-demo region: us-west-1 # Unmanaged nodegroups with and without taints. nodeGroups: - name: ng1 instanceType: m5.xlarge minSize: 2 maxSize: 3 taints: - key: classified_workload value: "true" effect: NoSchedule - key: machine_learning_workload value: "true" effect: NoSchedule - name: ng2 instanceType: m5.xlarge minSize: 2 maxSize: 3	App-Besitzer AWS DevOps, Cloud-Administrator, DevOps Ingenieur
Erstellen Sie den Cluster mithilfe von eksctl.	Führen Sie die cluster.yaml Datei aus, um den Cluster zu erstellen. EKS Das Erstellen des Clusters kann einige Minuten dauern. eksctl create cluster -f cluster.yaml	AWS DevOps, AWS Systemadministrator, App-Entwickler

Erstellen Sie den Cluster EKS

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie die Datei cluster.yaml.	Erstellen Sie eine Datei cluster.yaml mit dem folgenden Code. apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-taint-demo region: us-west-1 # Unmanaged nodegroups with and without taints. nodeGroups: - name: ng1 instanceType: m5.xlarge minSize: 2 maxSize: 3 taints: - key: classified_workload value: "true" effect: NoSchedule - key: machine_learning_workload value: "true" effect: NoSchedule - name: ng2 instanceType: m5.xlarge minSize: 2 maxSize: 3	App-Besitzer AWS DevOps, Cloud-Administrator, DevOps Ingenieur
Erstellen Sie den Cluster mithilfe von eksctl.	Führen Sie die cluster.yaml Datei aus, um den Cluster zu erstellen. EKS Das Erstellen des Clusters kann einige Minuten dauern. eksctl create cluster -f cluster.yaml	AWS DevOps, AWS Systemadministrator, App-Entwickler

Erstellen Sie ein Bild und laden Sie es auf Amazon hoch ECR

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie ein ECR privates Amazon-Repository.	Informationen zum Erstellen eines ECR Amazon-Repositorys finden Sie unter Privates Repository erstellen. Beachten Sie das URI des Repos.	AWS DevOps, DevOps Ingenieur, App-Entwickler
Erstellen Sie das Dockerfile.	Wenn Sie über ein vorhandenes Docker-Container-Image verfügen, das Sie zum Testen des Musters verwenden möchten, können Sie diesen Schritt überspringen. Verwenden Sie das folgende Snippet als Referenz, um ein Dockerfile zu erstellen. Wenn Sie auf Fehler stoßen, lesen Sie im Abschnitt Fehlerbehebung nach. FROM adoptopenjdk/openjdk11:jdk-11.0.14.1_1-alpine RUN apk add maven WORKDIR /code # Prepare by downloading dependencies ADD pom.xml /code/pom.xml RUN ["mvn", "dependency:resolve"] RUN ["mvn", "verify"] # Adding source, compile and package into a fat jar ADD src /code/src RUN ["mvn", "package"] EXPOSE 4567 CMD ["java", "-jar", "target/eksExample-jar-with-dependencies.jar"]	AWS DevOps, DevOps Ingenieur
Erstellen Sie die Datei pom.xml und die Quelldateien und erstellen Sie das Docker-Image und übertragen Sie es.	Informationen zum Erstellen der pom.xml Datei und der Java-Quelldatei finden Sie unter Bereitstellen eines EKS Beispielmusters für einen Java-Microservice auf Amazon. Verwenden Sie die Anweisungen in diesem Muster, um das Docker-Image zu erstellen und zu pushen.	AWS DevOps, DevOps Ingenieur, App-Entwickler

Erstellen Sie ein Bild und laden Sie es auf Amazon hoch ECR

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie ein ECR privates Amazon-Repository.	Informationen zum Erstellen eines ECR Amazon-Repositorys finden Sie unter Privates Repository erstellen. Beachten Sie das URI des Repos.	AWS DevOps, DevOps Ingenieur, App-Entwickler
Erstellen Sie das Dockerfile.	Wenn Sie über ein vorhandenes Docker-Container-Image verfügen, das Sie zum Testen des Musters verwenden möchten, können Sie diesen Schritt überspringen. Verwenden Sie das folgende Snippet als Referenz, um ein Dockerfile zu erstellen. Wenn Sie auf Fehler stoßen, lesen Sie im Abschnitt Fehlerbehebung nach. FROM adoptopenjdk/openjdk11:jdk-11.0.14.1_1-alpine RUN apk add maven WORKDIR /code # Prepare by downloading dependencies ADD pom.xml /code/pom.xml RUN ["mvn", "dependency:resolve"] RUN ["mvn", "verify"] # Adding source, compile and package into a fat jar ADD src /code/src RUN ["mvn", "package"] EXPOSE 4567 CMD ["java", "-jar", "target/eksExample-jar-with-dependencies.jar"]	AWS DevOps, DevOps Ingenieur
Erstellen Sie die Datei pom.xml und die Quelldateien und erstellen Sie das Docker-Image und übertragen Sie es.	Informationen zum Erstellen der pom.xml Datei und der Java-Quelldatei finden Sie unter Bereitstellen eines EKS Beispielmusters für einen Java-Microservice auf Amazon. Verwenden Sie die Anweisungen in diesem Muster, um das Docker-Image zu erstellen und zu pushen.	AWS DevOps, DevOps Ingenieur, App-Entwickler

Auf Amazon bereitstellen EKS

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie die Datei deployment.yaml.	Verwenden Sie den Code im deployment.yaml Abschnitt Zusätzliche Informationen, um die Datei zu erstellen. Im Code ist der Schlüssel für die Knotenaffinität ein beliebiges Label, das Sie beim Erstellen von Knotengruppen erstellen. Dieses Muster verwendet das von eksctl erstellte Standardlabel. Informationen zum Anpassen von Labels finden Sie unter Zuweisen von Pods zu Nodes in der Kubernetes-Dokumentation. Der Wert für den Knotenaffinitätsschlüssel ist der Name der Knotengruppe, die von erstellt wurde. cluster.yaml Führen Sie den folgenden Befehl aus, um den Schlüssel und den Wert für den Taint abzurufen. kubectl get nodes -o json | jq '.items[].spec.taints' Das Bild ist das URI des ECR Amazon-Repositorys, das Sie in einem früheren Schritt erstellt haben.	AWS DevOps, DevOps Ingenieur, App-Entwickler
Stellen Sie die Datei bereit.	Führen Sie für die Bereitstellung auf Amazon EKS den folgenden Befehl aus. kubectl apply -f deployment.yaml	App-Entwickler, DevOps Ingenieur, AWS DevOps
Überprüfen Sie die Bereitstellung.	Führen Sie den folgenden Befehl aus, um zu überprüfenREADY, ob es sich um die Pods handelt. kubectl get pods -o wide Wenn der bereit POD ist, sollte die Ausgabe etwa wie folgt aussehen, mit dem Status STATUS Running. NAME        READY    STATUS    RESTARTS   AGE   IP  NODE  NOMINATED NODE   READINESS GATES <pod_name>   1/1     Running   0          12d   192.168.18.50   ip-192-168-20-110.us-west-1.compute.internal   <none>           <none> Notieren Sie sich den Namen des Pods und den Namen des Knotens. Sie können den nächsten Schritt überspringen. (Optional) Führen Sie den folgenden Befehl aus, um weitere Informationen zum Pod zu erhalten und die Toleranzen auf dem Pod zu überprüfen. kubectl describe pod <pod_name> Ein Beispiel für die Ausgabe finden Sie im Abschnitt Zusätzliche Informationen. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Pod-Platzierung auf dem Knoten korrekt ist. kubectl describe node <node name> | grep -A 1 "Taints" Vergewissern Sie sich, dass der Makel auf dem Knoten der Toleranz entspricht und dass die Bezeichnung auf dem Knoten der unter definierten Knotenaffinität entspricht. deployment.yaml Der Pod mit den Toleranzen und der Knotenaffinität sollte auf einem Knoten mit den entsprechenden Merkmalen und den Knotenaffinitätsbezeichnungen platziert werden. Der vorherige Befehl gibt Ihnen die Taints auf dem Knoten. Im Folgenden finden Sie eine Beispielausgabe. kubectl describe node ip-192-168-29-181.us-west-1.compute.internal | grep -A 1 "Taints" Taints:             classifled_workload=true:NoSchedule                     machine_learning_workload=true:NoSchedule Führen Sie zusätzlich den folgenden Befehl aus, um zu überprüfen, ob der Knoten, auf dem sich der Pod befindet, eine Bezeichnung hat, die der Bezeichnung des Knotens mit der Knotenaffinität entspricht. kubectl get node <node name> --show-labels Um zu überprüfen, ob die Anwendung das tut, wofür sie vorgesehen ist, überprüfen Sie die Pod-Protokolle, indem Sie den folgenden Befehl ausführen. kubectl logs -f <name-of-the-pod>	App-Entwickler, DevOps Ingenieur, AWS DevOps
Erstellen Sie eine zweite .yaml-Datei für die Bereitstellung ohne Toleranz und Knotenaffinität.	Dieser zusätzliche Schritt besteht darin, zu überprüfen, ob der resultierende Pod nicht auf einem Knoten mit Taints geplant ist, wenn keine Knotenaffinität oder Toleranzen in der Bereitstellungsmanifestdatei angegeben sind. (Er sollte auf einem Knoten geplant werden, der keine Taints aufweist). Verwenden Sie den folgenden Code, um eine neue Bereitstellungsdatei mit dem Namen deploy_no_taint.yaml zu erstellen. apiVersion: apps/v1 kind: Deployment metadata: name: microservice-deployment-non-tainted spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: java-microservice-no-taint template: metadata: labels: app.kubernetes.io/name: java-microservice-no-taint spec: containers: - name: java-microservice-container-2 image: <account_number>.dkr.ecr<region>.amazonaws.com/<repository_name>:latest ports: - containerPort: 4567	App-Entwickler AWS DevOps, DevOps Ingenieur
Stellen Sie die zweite Bereitstellungsdatei (.yaml) bereit und validieren Sie die Pod-Platzierung	Führen Sie den folgenden Befehl aus. kubectl apply -f deploy_no_taint.yaml Führen Sie nach erfolgreicher Bereitstellung dieselben Befehle aus, die Sie zuvor ausgeführt haben, um die Pod-Platzierung in einer Knotengruppe ohne Makel zu überprüfen. kubectl describe node <node_name> | grep "Taints" Die Ausgabe sollte wie folgt aussehen. Taints: <none> Damit ist der Test abgeschlossen.	App-Entwickler AWS DevOps, DevOps Ingenieur

Auf Amazon bereitstellen EKS

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie die Datei deployment.yaml.	Verwenden Sie den Code im deployment.yaml Abschnitt Zusätzliche Informationen, um die Datei zu erstellen. Im Code ist der Schlüssel für die Knotenaffinität ein beliebiges Label, das Sie beim Erstellen von Knotengruppen erstellen. Dieses Muster verwendet das von eksctl erstellte Standardlabel. Informationen zum Anpassen von Labels finden Sie unter Zuweisen von Pods zu Nodes in der Kubernetes-Dokumentation. Der Wert für den Knotenaffinitätsschlüssel ist der Name der Knotengruppe, die von erstellt wurde. cluster.yaml Führen Sie den folgenden Befehl aus, um den Schlüssel und den Wert für den Taint abzurufen. kubectl get nodes -o json | jq '.items[].spec.taints' Das Bild ist das URI des ECR Amazon-Repositorys, das Sie in einem früheren Schritt erstellt haben.	AWS DevOps, DevOps Ingenieur, App-Entwickler
Stellen Sie die Datei bereit.	Führen Sie für die Bereitstellung auf Amazon EKS den folgenden Befehl aus. kubectl apply -f deployment.yaml	App-Entwickler, DevOps Ingenieur, AWS DevOps
Überprüfen Sie die Bereitstellung.	Führen Sie den folgenden Befehl aus, um zu überprüfenREADY, ob es sich um die Pods handelt. kubectl get pods -o wide Wenn der bereit POD ist, sollte die Ausgabe etwa wie folgt aussehen, mit dem Status STATUS Running. NAME        READY    STATUS    RESTARTS   AGE   IP  NODE  NOMINATED NODE   READINESS GATES <pod_name>   1/1     Running   0          12d   192.168.18.50   ip-192-168-20-110.us-west-1.compute.internal   <none>           <none> Notieren Sie sich den Namen des Pods und den Namen des Knotens. Sie können den nächsten Schritt überspringen. (Optional) Führen Sie den folgenden Befehl aus, um weitere Informationen zum Pod zu erhalten und die Toleranzen auf dem Pod zu überprüfen. kubectl describe pod <pod_name> Ein Beispiel für die Ausgabe finden Sie im Abschnitt Zusätzliche Informationen. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Pod-Platzierung auf dem Knoten korrekt ist. kubectl describe node <node name> | grep -A 1 "Taints" Vergewissern Sie sich, dass der Makel auf dem Knoten der Toleranz entspricht und dass die Bezeichnung auf dem Knoten der unter definierten Knotenaffinität entspricht. deployment.yaml Der Pod mit den Toleranzen und der Knotenaffinität sollte auf einem Knoten mit den entsprechenden Merkmalen und den Knotenaffinitätsbezeichnungen platziert werden. Der vorherige Befehl gibt Ihnen die Taints auf dem Knoten. Im Folgenden finden Sie eine Beispielausgabe. kubectl describe node ip-192-168-29-181.us-west-1.compute.internal | grep -A 1 "Taints" Taints:             classifled_workload=true:NoSchedule                     machine_learning_workload=true:NoSchedule Führen Sie zusätzlich den folgenden Befehl aus, um zu überprüfen, ob der Knoten, auf dem sich der Pod befindet, eine Bezeichnung hat, die der Bezeichnung des Knotens mit der Knotenaffinität entspricht. kubectl get node <node name> --show-labels Um zu überprüfen, ob die Anwendung das tut, wofür sie vorgesehen ist, überprüfen Sie die Pod-Protokolle, indem Sie den folgenden Befehl ausführen. kubectl logs -f <name-of-the-pod>	App-Entwickler, DevOps Ingenieur, AWS DevOps
Erstellen Sie eine zweite .yaml-Datei für die Bereitstellung ohne Toleranz und Knotenaffinität.	Dieser zusätzliche Schritt besteht darin, zu überprüfen, ob der resultierende Pod nicht auf einem Knoten mit Taints geplant ist, wenn keine Knotenaffinität oder Toleranzen in der Bereitstellungsmanifestdatei angegeben sind. (Er sollte auf einem Knoten geplant werden, der keine Taints aufweist). Verwenden Sie den folgenden Code, um eine neue Bereitstellungsdatei mit dem Namen deploy_no_taint.yaml zu erstellen. apiVersion: apps/v1 kind: Deployment metadata: name: microservice-deployment-non-tainted spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: java-microservice-no-taint template: metadata: labels: app.kubernetes.io/name: java-microservice-no-taint spec: containers: - name: java-microservice-container-2 image: <account_number>.dkr.ecr<region>.amazonaws.com/<repository_name>:latest ports: - containerPort: 4567	App-Entwickler AWS DevOps, DevOps Ingenieur
Stellen Sie die zweite Bereitstellungsdatei (.yaml) bereit und validieren Sie die Pod-Platzierung	Führen Sie den folgenden Befehl aus. kubectl apply -f deploy_no_taint.yaml Führen Sie nach erfolgreicher Bereitstellung dieselben Befehle aus, die Sie zuvor ausgeführt haben, um die Pod-Platzierung in einer Knotengruppe ohne Makel zu überprüfen. kubectl describe node <node_name> | grep "Taints" Die Ausgabe sollte wie folgt aussehen. Taints: <none> Damit ist der Test abgeschlossen.	App-Entwickler AWS DevOps, DevOps Ingenieur

Bereinigen von -Ressourcen

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Bereinigen Sie die Ressourcen.	Verwenden Sie den folgenden Befehl, um zu vermeiden, dass AWS Gebühren für Ressourcen anfallen, die ungenutzt bleiben. eksctl delete cluster --name <Name of the cluster> --region <region-code>	AWS DevOps, App-Entwickler

Bereinigen von -Ressourcen

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Bereinigen Sie die Ressourcen.	Verwenden Sie den folgenden Befehl, um zu vermeiden, dass AWS Gebühren für Ressourcen anfallen, die ungenutzt bleiben. eksctl delete cluster --name <Name of the cluster> --region <region-code>	AWS DevOps, App-Entwickler

Fehlerbehebung

Problem	Lösung
Einige dieser Befehle werden möglicherweise nicht ausgeführt, wenn Ihr System die Arm64-Architektur verwendet (insbesondere, wenn Sie dies auf einem M1-Mac ausführen). In der folgenden Zeile ist möglicherweise ein Fehler aufgetreten. FROM adoptopenjdk/openjdk11:jdk-11.0.14.1_1-alpine	Wenn Sie beim Ausführen des Dockerfiles Fehler haben, ersetzen Sie die FROM Zeile durch die folgende Zeile. FROM bellsoft/liberica-openjdk-alpine-musl:17

Zugehörige Ressourcen

• Stellen Sie einen Beispiel-Java-Microservice auf Amazon bereit EKS

• Erstellen Sie ein ECR privates Amazon-Repository

• Zuweisen von Pods zu Knoten (Kubernetes-Dokumentation)

• Schwächen und Toleranzen (Kubernetes-Dokumentation)

• Amazon EKS

• Amazon ECR

• AWS CLI

• Docker

• IntelliJ CE IDEA

• Eclipse

Zusätzliche Informationen

bereitstellung.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: microservice-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: java-microservice
  template:
    metadata:
      labels:
        app.kubernetes.io/name: java-microservice
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: alpha.eksctl.io/nodegroup-name
                    operator: In
                    values:
                      - <node-group-name-from-cluster.yaml>
      tolerations: #only this pod has toleration and is viable to go to ng with taint
        - key: "<Taint key>" #classified_workload in our case
          operator: Equal
          value: "<Taint value>" #true 
          effect: "NoSchedule" 
        - key: "<Taint key>" #machine_learning_workload in our case
          operator: Equal
          value: "<Taint value>" #true
          effect: "NoSchedule"
      containers:
        - name: java-microservice-container
          image: <account_number>.dkr.ecr<region>.amazonaws.com/<repository_name>:latest
          ports:
            - containerPort: 4567

Beschreiben Sie die Pod-Beispielausgabe

Name:         microservice-deployment-in-tainted-nodes-5684cc495b-vpcfx
Namespace:    default
Priority:     0
Node:         ip-192-168-29-181.us-west-1.compute.internal/192.168.29.181
Start Time:   Wed, 14 Sep 2022 11:06:47 -0400
Labels:       app.kubernetes.io/name=java-microservice-taint
              pod-template-hash=5684cc495b
Annotations:  kubernetes.io/psp: eks.privileged
Status:       Running
IP:           192.168.13.44
IPs:
  IP:           192.168.13.44
Controlled By:  ReplicaSet/microservice-deployment-in-tainted-nodes-5684cc495b
Containers:
  java-microservice-container-1:
    Container ID:   docker://5c158df8cc160de8f57f62f3ee16b12725a87510a809d90a1fb9e5d873c320a4
    Image:          934188034500.dkr.ecr.us-east-1.amazonaws.com/java-eks-apg
    Image ID:       docker-pullable://934188034500.dkr.ecr.us-east-1.amazonaws.com/java-eks-apg@sha256:d223924aca8315aab20d54eddf3443929eba511b6433017474d01b63a4114835
    Port:           4567/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Wed, 14 Sep 2022 11:07:02 -0400
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ddvvw (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-ddvvw:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 classifled_workload=true:NoSchedule
                             machine_learning_workload=true:NoSchedule
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>