IBM Cloud Docs
Klassisch: Basislastausgleich mit einer NLB 1.0 einrichten

Klassisch: Basislastausgleich mit einer NLB 1.0 einrichten

Netzlastausgleichsfunktionen (Network Load Balancer, NLBs) der Version 1.0 können nur in klassischen Clustern erstellt werden, nicht aber in VPC-Clustern. Wie der Lastausgleich in VPC-Clustern erfolgt, erfahren Sie unter Apps mit Lastausgleichsfunktionen für VPC zugänglich machen.

Machen Sie einen Port zugänglich und verwenden Sie eine portierbare IP-Adresse für die Layer 4-Netzlastausgleichsfunktion (NLB), um eine containerisierte App zugänglich zu machen. Weitere Informationen zu NLBs der Version 1.0 finden Sie unter Komponenten und Architektur einer NLB der Version 1.0.

NLB der Version 1.0 in einem Mehrzonencluster konfigurieren

Vorbereitende Schritte:

  • Um öffentliche Netzlastausgleichsfunktionen in mehreren Zonen zu erstellen, muss mindestens ein öffentliches VLAN portierbare Teilnetze aufweisen, die in jeder Zone verfügbar sind. Um private NLBs in mehreren Zonen zu erstellen, muss mindestens ein privates VLAN portierbare Teilnetze aufweisen, die in jeder Zone verfügbar sind. Sie können Teilnetze hinzufügen, indem Sie die Schritte im Abschnitt Teilnetze für Cluster konfigurieren ausführen.
  • Aktivieren Sie eine VRF-Funktion (Virtual Router Function) für Ihr IBM Cloud-Infrastrukturkonto. Informationen zum Aktivieren von VRF finden Sie im Abschnitt VRF aktivieren. Mit dem Befehl ibmcloud account show können Sie überprüfen, ob VRF bereits aktiviert ist. Wenn Sie VRF nicht aktivieren können oder möchten, aktivieren Sie VLAN-Spanning. Wenn VRF- oder VLAN Spanning aktiviert ist, kann die NLB der Version 1.0 Pakete an verschiedene Teilnetze im Konto weiterleiten.
  • Vergewissern Sie sich, dass Sie über die Writer oder Manager IBM Cloud IAM-Service-Zugriffsrolle für den Namensraum " default.
  • Wenn Sie den Datenaustausch im Netz auf Edge-Workerknoten beschränken, stellen Sie sicher, dass in jeder Zone mindestens zwei Edge-Workerknoten aktiviert sind, sodass die NLBs gleichmäßig bereitgestellt werden.
  • Wenn Clusterknoten erneut geladen werden oder wenn eine Cluster-Master-Aktualisierung ein neues keepalived-Image enthält, wird die virtuelle IP-Adresse der Lastausgleichsfunktion in die Netzschnittstelle eines neuen Knotens verschoben. In diesem Fall müssen alle langlebigen Verbindungen zu Ihrer Lastausgleichsfunktion wiederhergestellt werden. Ziehen Sie in Erwägung, eine Wiederholungslogik in Ihre Anwendung einzubauen, damit die Versuche, die Verbindung wiederherzustellen, schnell durchgeführt werden.

Gehen Sie wie folgt vor, um eine NLB der Version 1.0 in einem Mehrzonencluster einzurichten:

  1. Stellen Sie die App im Cluster bereit. Stellen Sie sicher, dass Sie im Metadatenabschnitt der Konfigurationsdatei für die Bereitstellung eine Bezeichnung hinzufügen. Mit dieser angepassten Bezeichnung werden alle Pods gekennzeichnet, in denen Ihre App ausgeführt wird und die in den Lastausgleich einbezogen werden sollen.

  2. Erstellen Sie einen Lastausgleichsservice für die App, die Sie über das öffentliche Internet oder ein privates Netz zugänglich machen wollen.

    1. Erstellen Sie eine Servicekonfigurationsdatei namens myloadbalancer.yaml (Beispiel).

    2. Definieren Sie einen Lastausgleichsservice für die App, die Sie zugänglich machen möchten. Sie können eine Zone, ein VLAN und eine IP-Adresse angeben.

      apiVersion: v1
      kind: Service
      metadata:
        name: myloadbalancer
        annotations:
          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
          service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
          service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
      spec:
        type: LoadBalancer
        selector:
          <selector_key>: <selector_value>
        ports:
         - protocol: TCP
           port: 8080
           targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
        loadBalancerIP: <IP_address>
      
      service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type
      Annotation zur Angabe einer private- oder public-Lastausgleichsfunktion. Wenn Sie diese Annotation nicht angeben und Ihre Workerknoten mit öffentlichen VLANs verbunden sind, wird ein öffentlicher LoadBalancer-Service erstellt. Wenn Ihre Workerknoten nur mit privaten VLANs verbunden sind, wird ein privater LoadBalancer-Service erstellt.
      service.kubernetes.io/ibm-load-balancer-cloud-provider-zone
      Annotation zum Angeben der Zone, in der der Lastausgleichsservice bereitgestellt wird. Führen Sie zum Anzeigen von Zonen den Befehl ibmcloud oc zone ls aus.
      service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan
      Annotation zum Angeben eines VLAN, in dem der Lastausgleichsservice bereitgestellt wird. Führen Sie zum Anzeigen von VLANs den Befehl ibmcloud oc vlan ls --zone <zone> aus.
      selector
      Der Bezeichnungsschlüssel (<selector_key>) und der Wert (<selector_value>), die Sie im Abschnitt spec.template.metadata.labels Ihrer YAML-Datei für die App-Bereitstellung verwendet haben.
      port
      Der Port, den der Service überwacht.
      loadBalancerIP
      Optional: Um eine private Lastausgleichsfunktion zu erstellen oder um eine bestimmte portierbare IP-Adresse für eine öffentliche Lastausgleichsfunktion zu verwenden, geben Sie die IP-Adresse an, die Sie verwenden wollen. Die IP-Adresse muss sich in dem VLAN und der Zone befinden, die Sie in den Annotationen angeben. Wenn Sie keine IP-Adresse angeben, geschieht Folgendes:
      Wenn sich Ihr Cluster in einem öffentlichen VLAN befindet, dann wird eine portierbare öffentliche IP-Adresse verwendet. Die meisten Cluster befinden sich in einem öffentlichen VLAN.
      Wenn sich Ihr Cluster nur in einem privaten VLAN befindet, wird eine portierbare private IP-Adresse verwendet.

      Beispielkonfigurationsdatei zum Erstellen eines privaten NLB-Service der Version 1.0, der eine angegebene IP-Adresse im privaten VLAN 2234945 in dal12 verwendet:

      apiVersion: v1
      kind: Service
      metadata:
        name: myloadbalancer
        annotations:
          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
          service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
          service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
      spec:
        type: LoadBalancer
        selector:
          app: nginx
        ports:
         - protocol: TCP
           port: 8080
           targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
        loadBalancerIP: 172.21.xxx.xxx
      
    3. Optional: Machen Sie Ihren NLB-Service nur für einen begrenzten Bereich von IP-Adressen verfügbar, indem Sie die IP-Adressen im Feld spec.loadBalancerSourceRanges angeben. loadBalancerSourceRanges wird von kube-proxy über Iptables-Regeln auf Workerknoten in Ihrem Cluster implementiert. Weitere Informationen finden Sie in der Kubernetes.

    4. Erstellen Sie den Service in Ihrem Cluster.

      oc apply -f myloadbalancer.yaml
      
  3. Stellen Sie sicher, dass der NLB-Service erfolgreich erstellt wurde. Es kann ein paar Minuten dauern, bis der Service erstellt wurde und die App verfügbar ist.

    oc describe service myloadbalancer
    

    In der Ausgabe ist die IP-Adresse für LoadBalancer Ingress die portierbare IP-Adresse, die Ihrem NLB-Service zugewiesen wurde:

    NAME:                   myloadbalancer
    Namespace:              default
    Labels:                 <none>
    Selector:               app=liberty
    Type:                   LoadBalancer
    Zone:                   dal10
    IP:                     172.21.xxx.xxx
    LoadBalancer Ingress:   169.xx.xxx.xxx
    Port:                   <unset> 8080/TCP
    NodePort:               <unset> 32040/TCP
    Endpoints:              172.30.xxx.xxx:8080
    Session Affinity:       None
    Events:
        FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
        ---------    --------    -----    ----            -------------    ----     ------                      -------
        10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
        10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer
    
  4. Wenn Sie eine öffentliche NLB erstellt haben, dann greifen Sie über das Internet auf Ihre App zu.

    1. Öffnen Sie Ihren bevorzugten Web-Browser.

    2. Geben Sie die portierbare öffentliche IP-Adresse der NLB und des Ports ein.

      http://169.xx.xxx.xxx:8080
      
  5. Wiederholen Sie die Schritte 2 bis 4, um eine NLB der Version 1.0 in jeder Zone hinzuzufügen.

  6. Wenn Sie die Beibehaltung der Quellen-IP für eine NLB der Version NLB 1.0 wählen, stellen Sie sicher, dass App-Pods auf den Edge-Workerknoten geplant werden, indem Sie Edge-Knoten-Affinität zu App-Pods hinzufügen. App-Pods müssen auf Edge-Knoten geplant werden, um eingehende Anforderungen empfangen zu können.

  7. Optional: Ein Lastausgleichsservice macht Ihre App auch über die NodePort-Instanzen des Service verfügbar. Auf Knotenports (NodePorts) kann über jede öffentliche und private IP-Adresse für jeden Knoten innerhalb des Clusters zugegriffen werden. Informationen zum Blockieren des Datenverkehrs an Knotenports während der Verwendung eines NLB-Service finden Sie im Abschnitt Eingehenden Datenverkehr an Netzlastausgleichsfunktion (NLB) oder NodePort-Services steuern.

Als Nächstes können Sie eine NLB-Unterdomäne registrieren.

NLB 1.0 in einem Mehrzonencluster konfigurieren

Vorbereitende Schritte:

  • Es muss eine portierbare öffentliche oder private IP-Adresse verfügbar sein, die dem NLB-Service (NLB, Netzlastausgleichsfunktion) zugewiesen werden kann. Weitere Informationen finden Sie unter Teilnetze für Cluster konfigurieren.
  • Vergewissern Sie sich, dass Sie über die Writer oder Manager IBM Cloud IAM-Service-Zugriffsrolle für den Namensraum " default.
  • Wenn Clusterknoten erneut geladen werden oder wenn eine Cluster-Master-Aktualisierung ein neues keepalived-Image enthält, wird die virtuelle IP-Adresse der Lastausgleichsfunktion in die Netzschnittstelle eines neuen Knotens verschoben. In diesem Fall müssen alle langlebigen Verbindungen zu Ihrer Lastausgleichsfunktion wiederhergestellt werden. Ziehen Sie in Erwägung, eine Wiederholungslogik in Ihre Anwendung einzubauen, damit die Versuche, die Verbindung wiederherzustellen, schnell durchgeführt werden.

Gehen Sie wie folgt vor, um einen NLB-Service der Version 1.0 in einem Einzelzonencluster zu erstellen:

  1. Stellen Sie die App im Cluster bereit. Stellen Sie sicher, dass Sie zur Bereitstellung im Metadatenabschnitt der Konfigurationsdatei eine Bezeichnung hinzufügen. Diese Bezeichnung ist zur Identifizierung aller Pods erforderlich, in denen Ihre App ausgeführt wird, damit sie in den Lastausgleich aufgenommen werden können.

  2. Erstellen Sie einen Lastausgleichsservice für die App, die Sie über das öffentliche Internet oder ein privates Netz zugänglich machen wollen.

    1. Erstellen Sie eine Servicekonfigurationsdatei namens myloadbalancer.yaml (Beispiel).

    2. Definieren Sie einen Lastausgleichsservice für die App, die Sie zugänglich machen möchten.

      apiVersion: v1
      kind: Service
      metadata:
        name: myloadbalancer
        annotations:
          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
          service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
      spec:
        type: LoadBalancer
        selector:
          <selector_key>: <selector_value>
        ports:
         - protocol: TCP
           port: 8080
           targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
        loadBalancerIP: <IP_address>
      
      service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type:
      Annotation zur Angabe einer private- oder public-Lastausgleichsfunktion. service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan:: Annotation zum Angeben eines VLAN, in dem der Lastausgleichsservice bereitgestellt wird. Führen Sie zum Anzeigen von VLANs den Befehl ibmcloud oc vlan ls --zone <zone> aus. selector: Der Label-Schlüssel (<selector_key>) und der Wert (<selector_value>), den Sie im Abschnitt ' spec.template.metadata.labels Ihrer App Deployment YAML verwendet haben.
      port
      Der Port, den der Service überwacht.
      loadBalancerIP
      Optional: Um eine private Lastausgleichsfunktion zu erstellen oder um eine bestimmte portierbare IP-Adresse für eine öffentliche Lastausgleichsfunktion zu verwenden, geben Sie die IP-Adresse an, die Sie verwenden wollen. Die IP-Adresse muss sich in dem VLAN befinden, das Sie in den Annotationen angeben. Wenn Sie keine IP-Adresse angeben, geschieht Folgendes:
      Wenn sich Ihr Cluster in einem öffentlichen VLAN befindet, dann wird eine portierbare öffentliche IP-Adresse verwendet. Die meisten Cluster befinden sich in einem öffentlichen VLAN.
      Wenn sich Ihr Cluster nur in einem privaten VLAN befindet, wird eine portierbare private IP-Adresse verwendet.

      Beispielkonfigurationsdatei zum Erstellen eines privaten NLB-Service der Version 1.0, der eine angegebene IP-Adresse im privaten VLAN 2234945 verwendet:

      apiVersion: v1
      kind: Service
      metadata:
        name: myloadbalancer
        annotations:
          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
          service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
      spec:
        type: LoadBalancer
        selector:
          app: nginx
        ports:
         - protocol: TCP
           port: 8080
           targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
        loadBalancerIP: 172.21.xxx.xxx
      
    3. Optional: Machen Sie Ihren NLB-Service nur für einen begrenzten Bereich von IP-Adressen verfügbar, indem Sie die IP-Adressen im Feld spec.loadBalancerSourceRanges angeben. loadBalancerSourceRanges wird von kube-proxy über Iptables-Regeln auf Workerknoten in Ihrem Cluster implementiert. Weitere Informationen finden Sie in der Kubernetes.

    4. Erstellen Sie den Service in Ihrem Cluster.

      oc apply -f myloadbalancer.yaml
      
  3. Stellen Sie sicher, dass der NLB-Service erfolgreich erstellt wurde. Es kann ein paar Minuten dauern, bis der Service erstellt wurde und die App verfügbar ist.

    oc describe service myloadbalancer
    

    CLI-Beispielausgabe:

    NAME:                   myloadbalancer
    Namespace:              default
    Labels:                 <none>
    Selector:               app=liberty
    Type:                   LoadBalancer
    Location:               dal10
    IP:                     172.21.xxx.xxx
    LoadBalancer Ingress:   169.xx.xxx.xxx
    Port:                   <unset> 8080/TCP
    NodePort:               <unset> 32040/TCP
    Endpoints:              172.30.xxx.xxx:8080
    Session Affinity:       None
    Events:
        FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
        ---------    --------    -----    ----            -------------    ----     ------                      -------
        10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
        10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer
    

    Die IP-Adresse für LoadBalancer Ingress ist die portierbare IP-Adresse, die dem NLB-Service zugewiesen wurde.

  4. Wenn Sie eine öffentliche NLB erstellt haben, dann greifen Sie über das Internet auf Ihre App zu.

    1. Öffnen Sie Ihren bevorzugten Web-Browser.

    2. Geben Sie die portierbare öffentliche IP-Adresse der NLB und des Ports ein.

      http://169.xx.xxx.xxx:8080
      
  5. Wenn Sie die Beibehaltung der Quellen-IP für eine NLB der Version NLB 1.0 wählen, stellen Sie sicher, dass App-Pods auf den Edge-Workerknoten geplant werden, indem Sie Edge-Knoten-Affinität zu App-Pods hinzufügen. App-Pods müssen auf Edge-Knoten geplant werden, um eingehende Anforderungen empfangen zu können.

  6. Optional: Ein Lastausgleichsservice macht Ihre App auch über die NodePort-Instanzen des Service verfügbar. Auf Knotenports (NodePorts) kann über jede öffentliche und private IP-Adresse für jeden Knoten innerhalb des Clusters zugegriffen werden. Informationen zum Blockieren des Datenverkehrs an Knotenports während der Verwendung eines NLB-Service finden Sie im Abschnitt Eingehenden Datenverkehr an Netzlastausgleichsfunktion (NLB) oder NodePort-Services steuern.

Als Nächstes können Sie eine NLB-Unterdomäne registrieren.

Beibehaltung von Quellen-IP-Adressen aktivieren

Dieses Feature ist nur für Netzlastausgleichsfunktionen (NLBs) der Version 1.0 verfügbar. Die Quellen-IP-Adresse von Clientanforderungen wird in den NLBs der Version 2.0 standardmäßig beibehalten.

Wenn eine Clientanforderung an Ihre App an Ihren Cluster gesendet wird, empfängt ein Pod des Lastausgleichsservice die Anforderung. Wenn kein App-Pod auf demselben Workerknoten wie der Pod des Lastausgleichsservice vorhanden ist, leitet die NLB die Anforderung an einen anderen Workerknoten weiter. Die Quellen-IP-Adresse des Pakets wird in die öffentliche IP-Adresse des Workerknotens geändert, auf dem der Pod des Lastausgleichsservice ausgeführt wird.

Um die ursprüngliche Quell-IP-Adresse der Client-Anfrage beizubehalten, können Sie " quell-IP aktivieren für Load Balancer-Dienste verwenden. Die TCP-Verbindung wird bis zu den App-Pods fortgesetzt, sodass die App die tatsächliche IP-Adresse des Initiators sehen kann. Das Beibehalten der IP des Clients ist nützlich, z. B. wenn App-Server Sicherheits- und Zugriffssteuerungsrichtlinien genügen müssen.

Nachdem Sie die Quellen-IP aktiviert haben, müssen Lastausgleichsfunktions-Pods Anforderungen an App-Pods weiterleiten, die auf demselben Workerknoten bereitgestellt sind. In der Regel werden auch Lastausgleichsfunktions-Pods auf den Workerknoten bereitgestellt, auf denen sich die App-Pods befinden. Es kann jedoch vorkommen, dass die Lastausgleichsfunktions-Pods und die App-Pods nicht auf demselben Workerknoten geplant sind:

  • Sie verfügen Edge-Knoten, auf die ein Taint angewendet wurde und auf denen deshalb nur Lastausgleichsfunktions-Pods bereitgestellt werden können. App-Pods dürfen auf diesen Knoten nicht bereitgestellt werden.
  • Ihr Cluster ist mit mehreren öffentlichen oder privaten VLANs verbunden und Ihre App-Pods werden unter Umständen auf Workerknoten bereitgestellt, die nur mit einem VLAN verbunden sind. Lastausgleichsfunktions-Pods lassen sich möglicherweise nicht auf solchen Workerknoten bereitstellen, weil die NLB-IP-Adresse mit einem anderen VLAN als die Workerknoten verbunden ist.

Um zu erzwingen, dass Ihre App auf bestimmten Workerknoten bereitgestellt wird, auf denen auch Lastausgleichsfunktions-Pods bereitgestellt werden können, müssen Sie Affinitätsregeln und Tolerierungen zu Ihrer App-Bereitstellung hinzufügen.

Affinitätsregeln und Tolerierungen für Edge-Knoten hinzufügen

Wenn Sie Workerknoten als Edge-Knoten kennzeichnen und zudem die Edge-Knoten mit Taints versehen, werden Pods des Lastausgleichsservice nur auf diesen Edge-Knoten bereitgestellt und App-Pods können nicht auf Edge-Knoten bereitgestellt werden. Wenn die Quellen-IP für den NLB-Service aktiviert ist, können die Pods der Lastausgleichsfunktion auf den Edge-Knoten keine eingehenden Anforderungen an Ihre App-Pods auf anderen Workerknoten weiterleiten.

Um zu erzwingen, dass Ihre App-Pods auf Edge-Nodes bereitgestellt werden, fügen Sie der App-Bereitstellung eine Edge-Node-Affinitätsregel und -toleranz hinzu.

Beispiel für die YAML-Bereitstellungsdatei mit Edge-Knoten-Affinität und -Tolerierung:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: dedicated
                operator: In
                values:
                - edge
      tolerations:
        - key: dedicated
          value: edge
...

In beiden Abschnitten affinity und tolerations ist der Wert dedicated für key und der Wert edge für value angegeben.

Affinitätsregeln für mehrere öffentliche oder private VLANs hinzufügen

Wenn Ihr Cluster mit mehreren öffentlichen oder privaten VLANs verbunden ist, werden Ihre App-Pods unter Umständen auf Workerknoten bereitgestellt, die nur mit einem VLAN verbunden sind. Wenn die NLB-IP-Adresse mit einem anderen VLAN als diese Workerknoten verbunden ist, werden die Lastausgleichsfunktions-Pods nicht auf diesen Workerknoten bereitgestellt.

Wenn die Quellen-IP aktiviert ist, planen Sie App-Pods auf Workerknoten, die dasselbe VLAN wie die NLB-IP-Adresse aufweisen, indem Sie eine Affinitätsregel zur App-Bereitstellung hinzufügen.

Vorbereitende Schritte: Greifen Sie auf Ihren Red Hat OpenShift-Cluster zu.

  1. Rufen Sie die IP-Adresse des NLB-Service ab. Suchen Sie im Feld LoadBalancer Ingress nach der IP-Adresse.

    oc describe service <loadbalancer_service_name>
    
  2. Rufen Sie die VLAN-ID ab, mit der Ihr NLB-Service verbunden ist.

    1. Listen Sie portierbare öffentliche VLANs für Ihren Cluster auf.

      ibmcloud oc cluster get --cluster <cluster_name_or_ID> --show-resources
      

      Beispielausgabe

      ...
      
      Subnet VLANs
      VLAN ID   Subnet CIDR       Public   User-managed
      2234947   10.xxx.xx.xxx/29  false    false
      2234945   169.36.5.xxx/29   true     false
      
    2. Suchen Sie in der Ausgabe unter Subnet VLANs nach der Teilnetz-CIDR, die mit der NLB-IP-Adresse übereinstimmt, die Sie zuvor abgerufen haben, und notieren Sie sich die VLAN-ID.

      Wenn die IP-Adresse des NLB-Service beispielsweise 169.36.5.xxx lautet, ist das passende Teilnetz in der Beispielausgabe aus dem vorherigen Schritt 169.36.5.xxx/29. Die VLAN-ID, mit der das Teilnetz verbunden ist, lautet 2234945.

  3. Hinzufügen einer Affinitätsregel in die App-Bereitstellung für die VLAN-ID ein, die Sie im vorherigen Schritt notiert haben.

    Wenn Sie beispielsweise über mehrere VLANs verfügen, aber Ihre App-Pods nur auf Workerknoten im öffentlichen VLAN 2234945 bereitstellen möchten.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: with-node-affinity
    spec:
      selector:
        matchLabels:
          <label_name>: <label_value>
      template:
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: publicVLAN
                    operator: In
                    values:
                    - "2234945"
    ...
    

    In der YAML-Beispieldatei enthält der Abschnitt affinity den Wert publicVLAN für key und den Wert "2234945" für value.

  4. Wenden Sie die aktualisierte Bereitstellungskonfigurationsdatei an.

    oc apply -f with-node-affinity.yaml
    
  5. Überprüfen Sie, dass die App-Pods auf Workerknoten bereitgestellt werden, die mit dem designierten VLAN verbunden sind.

    1. Listen Sie die Pods in Ihrem Cluster auf. Ersetzen Sie <selector> durch die Bezeichnung, die Sie für die App verwendet haben.

      oc get pods -o wide app=<selector>
      

      Beispielausgabe

      NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
      cf-py-d7b7d94db-vp8pq  1/1       Running             0          10d       172.30.xxx.xxx   10.176.48.78
      
    2. Geben Sie in der Ausgabe einen Pod für Ihre App an. Notieren Sie sich die Knoten-ID (NODE) des Workerknotens, auf dem sich der Pod befindet.

      In der Beispielausgabe aus dem vorherigen Schritt befindet sich der App-Pod cf-py-d7b7d94db-vp8pq auf dem Workerknoten 10.176.48.78.

    3. Listen Sie die Details für den Workerknoten auf.

      oc describe node <worker_node_ID>
      

      Beispielausgabe

      NAME:                   10.xxx.xx.xxx
      Role:
      Labels:                 arch=amd64
      beta.kubernetes.io/arch=amd64
      beta.kubernetes.io/os=linux
      failure-domain.beta.kubernetes.io/region=us-south
      failure-domain.beta.kubernetes.io/zone=dal10
      ibm-cloud.kubernetes.io/encrypted-docker-data=true
      kubernetes.io/hostname=10.xxx.xx.xxx
      privateVLAN=2234945
      publicVLAN=2234967
      ...
      
    4. Überprüfen Sie im Abschnitt Labels der Ausgabe, dass es sich bei dem öffentlichen oder privaten VLAN um das VLAN handelt, das Sie in den vorherigen Schritten angegeben haben.