Vorbereitung des „ Red Hat OpenShift on IBM Cloud “-Clusters

Für den Cluster „ Red Hat OpenShift “ auf IBM Cloud ist der NMState Operator erforderlich. NMState sorgt für eine dauerhafte Netzwerkkonfiguration für Brücken und physische Netzwerke. In diesem Schritt wird der Operator installiert.

Beachten Sie bitte Folgendes:

• Die Installation dauert 5 bis 10 Minuten, nachdem Sie das Manifest angewendet haben.
• Erstellen Sie pro Schnittstelle nur eine Brücke.
• Versuchen Sie nicht, die Brücke auf eth0 zu verändern.

Kopieren Sie den folgenden Code-Block in eine Datei und führen Sie ihn mit dem Befehl „ oc apply -f step0a.yml “ aus, um den NMState Operator zu installieren.

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
spec:
  finalizers:
  - kubernetes
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
  - openshift-nmstate
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubernetes-nmstate-operator
  namespace: openshift-nmstate
spec:
  channel: stable
  installPlanApproval: Automatic
  name: kubernetes-nmstate-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Warten Sie, bis der Administrator die benutzerdefinierte Ressourcendefinition (CRD) „ NMState “ registriert hat, bevor Sie die benutzerdefinierte Ressource „ NMState “ erstellen. Wenn Sie die Ressource „ NMState “ anwenden, bevor die CRD eingerichtet ist, wird eine Fehlermeldung wie „ no matches for kind "NMState" in version "nmstate.io/v1" “ angezeigt.

Führen Sie die folgenden Befehle aus, um so lange abzufragen, bis das CRD angezeigt wird, und warten Sie anschließend, bis es den Status „ Established “ erreicht hat.

until oc get crd nmstates.nmstate.io >/dev/null 2>&1; do echo "Waiting for NMState CRD..."; sleep 10; done
oc wait --for=condition=established crd/nmstates.nmstate.io --timeout=300s

Stellen Sie sicher, dass alle NMState-CRDs installiert sind.

oc get crd | grep nmstate

Beispielausgabe:

nmstates.nmstate.io                                               ...
nodenetworkconfigurationenactments.nmstate.io                     ...
nodenetworkconfigurationpolicies.nmstate.io                       ...
nodenetworkstates.nmstate.io                                      ...

Sobald die CRDs fertig sind, kopieren Sie den folgenden Code-Block in eine Datei und wenden Sie ihn mit „ oc apply -f step0b.yml “ an, um die benutzerdefinierte Ressource „ NMState “ zu erstellen.

---
apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
spec:
  probeConfiguration:
    dns:
      host: root-servers.net

Anwendung der Brückenkonfiguration

Wenden Sie die grundlegende Bridge-Konfiguration an, um die zweite PCI-VNI-Netzwerkkarte (Peripheral Component Interconnect-Virtual Network Interface) zu verwenden (eth1).

Kopieren Sie den folgenden Code-Block in eine Datei und führen Sie ihn mit dem Befehl „ oc apply -f step1.yml “ aus.

---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: "br-eth1"
spec:
  desiredState:
    interfaces:
    - name: "br-eth1"
      description: A dedicated OVS bridge with a NIC as a port
      type: ovs-bridge
      state: up
      bridge:
        allow-extra-patch-ports: true
        options:
          stp: false
        port:
        - name: "eth1"

Warten Sie, bis diese Konfiguration auf allen Knoten übernommen wurde, bevor Sie mit dem nächsten Schritt fortfahren.

% oc get NodeNetworkConfigurationPolicy br-eth1
NAME      STATUS      REASON
br-eth1   Available   SuccessfullyConfigured

Anwendung der Bridge-Mapping-Konfiguration

Wenden Sie die grundlegende Konfiguration für das Bridge-Mapping an.

Kopieren Sie den folgenden Code-Block in eine Datei und führen Sie ihn mit dem Befehl „ oc apply -f step2.yml “ aus.

---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: "vpc-vlans"
spec:
  desiredState:
    ovn:
      bridge-mappings:
      - localnet: "vpc-vlans" # <- use your desired network name
        bridge: "br-eth1"
        state: present

Erstellen eines benutzerdefinierten sekundären Präfixes und von Subnetzen für Ihre VPC

Lokale Netzwerke können für jedes Netzwerk sekundäre VPC-Subnetze verwenden. In diesem Beispiel werden drei neue Subnetze aus einem neuen VPC-Präfix verwendet. Sie können ein beliebiges Präfix oder Netzwerk angeben oder die VPC-Standardwerte verwenden.

ic is vpc-addrc my-vpc-zone-1-vms my-vpc us-south-1 198.18.0.0/18 --default true
ic is vpc-addrc my-vpc-zone-2-vms my-vpc us-south-2 198.18.64.0/18
ic is vpc-addrc my-vpc-zone-3-vms my-vpc us-south-3 198.18.128.0/18

ic is subnetc zone1-vm-prod my-vpc us-south-1 --ipv4-cidr-block 198.18.0.0/24
ic is subnetc zone1-vm-db my-vpc us-south-1 --ipv4-cidr-block 198.18.1.0/24
ic is subnetc zone1-vm-app my-vpc us-south-1 --ipv4-cidr-block 198.18.2.0/24

ic is subnets | awk ' $8 ~ /yourVPC-NAME_GOES-HERE/'

0716-16da748a-5159-480c-b809-5f9e4750028b   zone1-vm-app    available   198.18.2.0/24   249/256   stone-likeness-bagging-headcount   pgw-0ec02020-2f74-11f1-b0c5-bfe21078e55b   potato-farm   us-south-1   Default
0716-74a2d06b-de5c-40c2-8311-38dbff74ce62   zone1-vm-db     available   198.18.1.0/24   249/256   stone-likeness-bagging-headcount   -                                          potato-farm   us-south-1   Default
0716-efd14367-eed3-429d-b390-ea17f0e8cfb1   zone1-vm-prod   available   198.18.0.0/24   249/256   stone-likeness-bagging-headcount   pgw-0ec02020-2f74-11f1-b0c5-bfe21078e55b   potato-farm   us-south-1   Default

ic is subnet-public-gateway-attach zone1-vm-prod --pgw r134-053cb8b1-d966-4b02-9f20-5fcbeda76048

Installation des FRR OVN Router Pods

Wenden Sie den Patch „ Red Hat OpenShift “ auf den Cluster „ IBM Cloud “ an, um die Option „Free Range Routing“ (FRR) im Open Virtual Networking (OVN)-Pod freizuschalten. Wenden Sie den folgenden Patch an, um FRR als zusätzlichen Routing-Anbieter zu aktivieren und Routing-Ankündigungen in der OVN- Kubernetes-Konfiguration zu leiten.

oc patch Network.operator.openshift.io cluster --type=merge -p='{"spec":{"additionalRoutingCapabilities":{"providers":["FRR"]},"defaultNetwork":{"ovnKubernetesConfig":{"routeAdvertisements":"Enabled"}}}}'

Aktivieren der Vernetzung zwischen Namespaces

Wenden Sie die Basisnetzwerkkonfiguration an, die die Vernetzung zwischen Namespaces für benutzerdefinierte Cluster-Netzwerke (CUDNs) ermöglicht, die über das Border Gateway Protocol (BGP) bekannt gegeben werden. Diese Konfiguration lockert das standardmäßige Isolationsverhalten für benutzerdefinierte Netzwerke (UDN). Speichern Sie das folgende Manifest in einer Datei und wenden Sie es mit dem Befehl „ oc apply -f step0.yml “ an.

# Permit intra-CUDN-namespace traffic
---
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: openshift-network-operator
  name: ovn-kubernetes-config-overrides
data:
  advertised-udn-isolation-mode: "loose"

Auswahlfunktion für Routenankündigungen aktivieren

Fügen Sie Routenankündigungen hinzu, um OVN so zu konfigurieren, dass Pod-Netzwerke über BGP mit dem OVN-FRR-Pod angekündigt werden. Speichern Sie das folgende Manifest in einer Datei und wenden Sie es mit dem Befehl „ oc apply -f step1.yml “ an.

Netzwerke müssen die Bezeichnung „ advertise: true “ tragen.

# Add the RouteAdvertisements
---
kind: RouteAdvertisements
apiVersion: k8s.ovn.org/v1
metadata:
  name: default
spec:
  nodeSelector: {}
  frrConfigurationSelector: {}
  networkSelectors:
    - networkSelectionType: ClusterUserDefinedNetworks
      clusterUserDefinedNetworkSelector:
        networkSelector:
          matchLabels:
            advertise: "true"
  advertisements:
    - "PodNetwork"
---