Procedure

1. Select Ecosystem → Software Catalog.
2. In the search field below All Items, enter nmstate and click Enter to search for the Kubernetes NMState Operator.
3. Click on the Kubernetes NMState Operator search result.
4. Click on Install to open the Install Operator window.
5. Click Install to install the Operator.
6. After the Operator finishes installing, click View Operator.
7. Under Provided APIs, click Create Instance to open the dialog box for creating an instance of kubernetes-nmstate.

8. In the Name field of the dialog box, ensure the name of the instance is nmstate.

   Note

   The name restriction is a known issue. The instance is a singleton for the entire cluster.

9. Accept the default settings and click Create to create the instance.

Procedure

1. Create the nmstate Operator namespace:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-nmstate
   spec:
     finalizers:
     - kubernetes
   EOF

   Copy code to clipboard

2. Create the OperatorGroup:

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: openshift-nmstate
     namespace: openshift-nmstate
   spec:
     targetNamespaces:
     - openshift-nmstate
   EOF

   Copy code to clipboard

3. Subscribe to the nmstate Operator:

   $ cat << EOF| oc apply -f -
   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
   EOF

   Copy code to clipboard

4. Confirm the ClusterServiceVersion (CSV) status for the nmstate Operator deployment equals Succeeded:

   $ oc get clusterserviceversion -n openshift-nmstate \
    -o custom-columns=Name:.metadata.name,Phase:.status.phase

   Copy code to clipboard

5. Create an instance of the nmstate Operator:

   $ cat << EOF | oc apply -f -
   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   EOF

   Copy code to clipboard

6. If your cluster has problems with the DNS health check probe because of DNS connectivity issues, you can add the following DNS host name configuration to the NMState CRD to build in health checks that can resolve these issues:

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: redhat.com
   # ...

   Copy code to clipboard

   1. Apply the DNS host name configuration to your cluster network by running the following command. Ensure that you replace <filename> with the name of your CRD file.

      $ oc apply -f <filename>.yaml

      Copy code to clipboard

   2. Monitor the nmstate CRD until the resource reaches the Available condition by running the following command. Ensure that you set a value for the --timeout option so that if the Available condition is not met within this set maximum waiting time, the command times out and generates an error message.

      $ oc wait --for=condition=Available nmstate/nmstate --timeout=600s

      Copy code to clipboard

Verification

1. Verify that all pods for the NMState Operator have the Running status by entering the following command:

   $ oc get pod -n openshift-nmstate

   Copy code to clipboard

Procedure

1. If you want to view the metrics from the Developer perspective in the OpenShift Container Platform web console, complete the following tasks:

   1. Click Observe.
   2. To view the metrics of a specific project, select the project in the Project: list. For example, openshift-nmstate.
   3. Click the Metrics tab.

   4. To visualize the metrics on the plot, select a query from the Select query list or create a custom PromQL query based on the selected query by selecting Show PromQL.

      Note

      You can only run one query at a time with the developer role.

2. If you want to view the metrics in the OpenShift Container Platform web console as an administrator, complete the following tasks:

   1. Click Observe → Metrics.
   2. Enter kubernetes_nmstate_features_applied in the Expression field.
   3. Click Add query and then Run queries.

3. To explore the visualized metrics, do any of the following tasks:

   1. To zoom into the plot and change the time range, do any of the following tasks:

      • To visually select the time range, click and drag on the plot horizontally.
      • To select the time range, use the menu which is in the upper left of the console.
   2. To reset the time range, select Reset zoom.
   3. To display the output for all the queries at a specific point in time, hold the mouse cursor on the plot at that point. The query output displays in a pop-up box.

Procedure

1. To deploy the AWS Load Balancer Operator on-demand from the software catalog, create a Subscription object by running the following command:

   $ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

   Copy code to clipboard

2. Check if the status of an install plan is Complete by running the following command:

   $ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'

   Copy code to clipboard

3. View the status of the aws-load-balancer-operator-controller-manager deployment by running the following command:

   $ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

   Copy code to clipboard

   Example output

   NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-operator-controller-manager  1/1       1            1           23h

   Copy code to clipboard

Procedure

1. Create the aws-load-balancer-operator project by running the following command:

   $ oc new-project aws-load-balancer-operator

   Copy code to clipboard

2. Create the OperatorGroup object by running the following command:

   $ cat <<EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     targetNamespaces: []
   EOF

   Copy code to clipboard

3. Create the Subscription object by running the following command:

   $ cat <<EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     channel: stable-v1
     name: aws-load-balancer-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     config:
       env:
       - name: ROLEARN
         value: "<albo_role_arn>"
   EOF

   Copy code to clipboard

   where:

   <albo_role_arn>

   Specifies the ARN role to be used in the CredentialsRequest to provision the AWS credentials for the AWS Load Balancer Operator. An example for <albo_role_arn> is arn:aws:iam::<aws_account_number>:role/albo-operator.

   Note

   The AWS Load Balancer Operator waits until the secret is created before moving to the Available status.

Procedure

1. Navigate to Ecosystem → Software Catalog in the OpenShift Container Platform web console.
2. Select the AWS Load Balancer Operator. You can use the Filter by keyword text box or the filter list to search for the AWS Load Balancer Operator from the list of Operators.
3. Select the aws-load-balancer-operator namespace.

4. On the Install Operator page, select the following options:

   1. For the Update the channel option, select stable-v1.
   2. For the Installation mode option, select All namespaces on the cluster (default).
   3. For the Installed Namespace option, select aws-load-balancer-operator. If the aws-load-balancer-operator namespace does not exist, it gets created during the Operator installation.
   4. Select Update approval as Automatic or Manual. By default, the Update approval is set to Automatic. If you select automatic updates, the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without any intervention. If you select manual updates, the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the Operator update to the newer version.
5. Click Install.

Procedure

1. Create a Namespace object:

   1. Create a YAML file that defines the Namespace object:

      Example namespace.yaml file

      apiVersion: v1
      kind: Namespace
      metadata:
        name: aws-load-balancer-operator
      # ...

      Copy code to clipboard

   2. Create the Namespace object by running the following command:

      $ oc apply -f namespace.yaml

      Copy code to clipboard

2. Create an OperatorGroup object:

   1. Create a YAML file that defines the OperatorGroup object:

      Example operatorgroup.yaml file

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: aws-lb-operatorgroup
        namespace: aws-load-balancer-operator
      spec:
        upgradeStrategy: Default

      Copy code to clipboard

   2. Create the OperatorGroup object by running the following command:

      $ oc apply -f operatorgroup.yaml

      Copy code to clipboard

3. Create a Subscription object:

   1. Create a YAML file that defines the Subscription object:

      Example subscription.yaml file

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: aws-load-balancer-operator
        namespace: aws-load-balancer-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: aws-load-balancer-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

      Copy code to clipboard

   2. Create the Subscription object by running the following command:

      $ oc apply -f subscription.yaml

      Copy code to clipboard

Verification

1. Get the name of the install plan from the subscription:

   $ oc -n aws-load-balancer-operator \
     get subscription aws-load-balancer-operator \
     --template='{{.status.installplan.name}}{{"\n"}}'

   Copy code to clipboard

2. Check the status of the install plan:

   $ oc -n aws-load-balancer-operator \
     get ip <install_plan_name> \
     --template='{{.status.phase}}{{"\n"}}'

   Copy code to clipboard

   The output must be Complete.

Procedure

1. Create a YAML file that defines the AWSLoadBalancerController object:

   Example sample-aws-lb.yaml file

   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     subnetTagging: Auto
     additionalResourceTags:
     - key: example.org/security-scope
       value: staging
     ingressClass: alb
     config:
       replicas: 2
     enabledAddons:
       - AWSWAFv2

   Copy code to clipboard

   where:

   kind

   Specifies the AWSLoadBalancerController object.

   metadata.name

   Specifies the AWS Load Balancer Controller name. The Operator adds this instance name as a suffix to all related resources.

   spec.subnetTagging

   Specifies the subnet tagging method for the AWS Load Balancer Controller. The following values are valid:

   • Auto: The AWS Load Balancer Operator determines the subnets that belong to the cluster and tags them appropriately. The Operator cannot determine the role correctly if the internal subnet tags are not present on internal subnet.
   • Manual: You manually tag the subnets that belong to the cluster with the appropriate role tags. Use this option if you installed your cluster on user-provided infrastructure.

   spec.additionalResourceTags

   Specifies the tags used by the AWS Load Balancer Controller when it provisions AWS resources.

   ingressClass

   Specifies the ingress class name. The default value is alb.

   config.replicas

   Specifies the number of replicas of the AWS Load Balancer Controller.

   enabledAddons

   Specifies annotations as an add-on for the AWS Load Balancer Controller.

   AWSWAFv2

   Specifies that enablement of the alb.ingress.kubernetes.io/wafv2-acl-arn annotation.

2. Create the AWSLoadBalancerController object by running the following command:

   $ oc create -f sample-aws-lb.yaml

   Copy code to clipboard

3. Create a YAML file that defines the Deployment resource:

   Example sample-aws-lb.yaml file

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: <echoserver>
     namespace: echoserver
   spec:
     selector:
       matchLabels:
         app: echoserver
     replicas: 3
     template:
       metadata:
         labels:
           app: echoserver
       spec:
         containers:
           - image: openshift/origin-node
             command:
              - "/bin/socat"
             args:
               - TCP4-LISTEN:8080,reuseaddr,fork
               - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
             imagePullPolicy: Always
             name: echoserver
             ports:
               - containerPort: 8080

   Copy code to clipboard

   where:

   kind

   Specifies the deployment resource.

   metadata.name

   Specifies the deployment name.

   spec.replicas

   Specifies the number of replicas of the deployment.

4. Create a YAML file that defines the Service resource:

   Example service-albo.yaml file

   apiVersion: v1
   kind: Service
   metadata:
     name: <echoserver>
     namespace: echoserver
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: NodePort
     selector:
       app: echoserver

   Copy code to clipboard

   where:

   apiVersion

   Specifies the service resource.

   metadata.name

   Specifies the service name.

5. Create a YAML file that defines the Ingress resource:

   Example ingress-albo.yaml file

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: <name>
     namespace: echoserver
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: alb
     rules:
       - http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: <echoserver>
                   port:
                     number: 80

   Copy code to clipboard

   where:

   metadata.name

   Specifies a name for the Ingress resource.

   service.name

   Specifies the service name.

Procedure

1. Create the config map to contain the certificate authority (CA) bundle in the aws-load-balancer-operator namespace by running the following command:

   $ oc -n aws-load-balancer-operator create configmap trusted-ca

   Copy code to clipboard

2. To inject the trusted CA bundle into the config map, add the config.openshift.io/inject-trusted-cabundle=true label to the config map by running the following command:

   $ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true

   Copy code to clipboard

3. Update the AWS Load Balancer Operator subscription to access the config map in the AWS Load Balancer Operator deployment by running the following command:

   $ oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'

   Copy code to clipboard

4. After the AWS Load Balancer Operator is deployed, verify that the CA bundle is added to the aws-load-balancer-operator-controller-manager deployment by running the following command:

   $ oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"

   Copy code to clipboard

   Example output

   -rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
   trusted-ca

   Copy code to clipboard

5. Optional: Restart deployment of the AWS Load Balancer Operator every time the config map changes by running the following command:

   $ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager

   Copy code to clipboard

Procedure

1. Create a YAML file that defines the AWSLoadBalancerController resource:

   Example add-tls-termination-albc.yaml file

   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     subnetTagging: Auto
     ingressClass: tls-termination
   # ...

   Copy code to clipboard

   where:

   spec.ingressClass

   Specifies the ingress class name. If the ingress class is not present in your cluster the AWS Load Balancer Controller creates one. The AWS Load Balancer Controller reconciles the additional ingress class values if spec.controller is set to ingress.k8s.aws/alb.

2. Create a YAML file that defines the Ingress resource:

   Example add-tls-termination-ingress.yaml file

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: <example>
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx
   spec:
     ingressClassName: tls-termination
     rules:
     - host: example.com
       http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: <example_service>
                   port:
                     number: 80
   # ...

   Copy code to clipboard

   where:

   metadata.name

   Specifies the ingress name.

   annotations.alb.ingress.kubernetes.io/scheme

   Specifies the controller that provisions the load balancer for ingress. The provisioning happens in a public subnet to access the load balancer over the internet.

   annotations.alb.ingress.kubernetes.io/certificate-arn

   Specifies the Amazon Resource Name (ARN) of the certificate that you attach to the load balancer.

   spec.ingressClassName

   Specifies the ingress class name.

   rules.host

   Specifies the domain for traffic routing.

   backend.service

   Specifies the service for traffic routing.

Procedure

1. Create an IngressClassParams resource YAML file, for example, sample-single-lb-params.yaml, as follows:

   apiVersion: elbv2.k8s.aws/v1beta1
   kind: IngressClassParams
   metadata:
     name: single-lb-params
   spec:
     group:
       name: single-lb

   Copy code to clipboard

   where:

   apiVersion

   Specifies the API group and version of the IngressClassParams resource.

   metadata.name

   Specifies the IngressClassParams resource name.

   spec.group.name

   Specifies the IngressGroup resource name. All of the Ingress resources of this class belong to this IngressGroup.

2. Create the IngressClassParams resource by running the following command:

   $ oc create -f sample-single-lb-params.yaml

   Copy code to clipboard

3. Create the IngressClass resource YAML file, for example, sample-single-lb-class.yaml, as follows:

   apiVersion: networking.k8s.io/v1
   kind: IngressClass
   metadata:
     name: single-lb
   spec:
     controller: ingress.k8s.aws/alb
     parameters:
       apiGroup: elbv2.k8s.aws
       kind: IngressClassParams
       name: single-lb-params

   Copy code to clipboard

   where:

   apiVersion

   Specifies the API group and version of the IngressClass resource.

   metadata.name

   Specifies the ingress class name.

   spec.controller

   Specifies the controller name. The ingress.k8s.aws/alb value denotes that all ingress resources of this class should be managed by the AWS Load Balancer Controller.

   parameters.apiGroup

   Specifies the API group of the IngressClassParams resource.

   parameters.kind

   Specifies the resource type of the IngressClassParams resource.

   parameters.name

   Specifies the IngressClassParams resource name.

4. Create the IngressClass resource by running the following command:

   $ oc create -f sample-single-lb-class.yaml

   Copy code to clipboard

5. Create the AWSLoadBalancerController resource YAML file, for example, sample-single-lb.yaml, as follows:

   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     subnetTagging: Auto
     ingressClass: single-lb

   Copy code to clipboard

   where:

   spec.ingressClass

   Specifies the name of the IngressClass resource.

6. Create the AWSLoadBalancerController resource by running the following command:

   $ oc create -f sample-single-lb.yaml

   Copy code to clipboard

7. Create the Ingress resource YAML file, for example, sample-multiple-ingress.yaml, as follows:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-1
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/group.order: "1"
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: single-lb
     rules:
     - host: example.com
       http:
           paths:
           - path: /blog
             pathType: Prefix
             backend:
               service:
                 name: example-1
                 port:
                   number: 80
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-2
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/group.order: "2"
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: single-lb
     rules:
     - host: example.com
       http:
           paths:
           - path: /store
             pathType: Prefix
             backend:
               service:
                 name: example-2
                 port:
                   number: 80
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-3
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/group.order: "3"
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: single-lb
     rules:
     - host: example.com
       http:
           paths:
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: example-3
                 port:
                   number: 80

   Copy code to clipboard

   where:

   metadata.name

   Specifies the ingress name.

   alb.ingress.kubernetes.io/scheme

   Specifies the load balancer to provision in the public subnet to access the internet.

   alb.ingress.kubernetes.io/group.order

   Specifies the order in which the rules from the multiple ingress resources are matched when the request is received at the load balancer.

   alb.ingress.kubernetes.io/target-type

   Specifies that the load balancer will target OpenShift Container Platform nodes to reach the service.

   spec.ingressClassName

   Specifies the ingress class that belongs to this ingress.

   rules.host

   Specifies a domain name used for request routing.

   http.paths.path

   Specifies the path that must route to the service.

   backend.service.name

   Specifies the service name that serves the endpoint configured in the Ingress resource.

   port.number

   Specifies the port on the service that serves the endpoint.

8. Create the Ingress resource by running the following command:

   $ oc create -f sample-multiple-ingress.yaml

   Copy code to clipboard

Procedure

1. To create the bpfman namespace, enter the following command:

   $ cat << EOF| oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       pod-security.kubernetes.io/enforce: privileged
       pod-security.kubernetes.io/enforce-version: v1.24
     name: bpfman
   EOF

   Copy code to clipboard

2. To create an OperatorGroup CR, enter the following command:

   $ cat << EOF| oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: bpfman-operators
     namespace: bpfman
   EOF

   Copy code to clipboard

3. Subscribe to the eBPF Manager Operator.

   1. To create a Subscription CR for the eBPF Manager Operator, enter the following command:

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bpfman-operator
        namespace: bpfman
      spec:
        name: bpfman-operator
        channel: alpha
        source: community-operators
        sourceNamespace: openshift-marketplace
      EOF

      Copy code to clipboard

4. To verify that the Operator is installed, enter the following command:

   $ oc get ip -n bpfman

   Copy code to clipboard

   Example output

   NAME            CSV                                 APPROVAL    APPROVED
   install-ppjxl   security-profiles-operator.v0.8.5   Automatic   true

   Copy code to clipboard

5. To verify the version of the Operator, enter the following command:

   $ oc get csv -n bpfman

   Copy code to clipboard

   Example output

   NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
   bpfman-operator.v0.5.0              eBPF Manager Operator              0.5.0     bpfman-operator.v0.4.2              Succeeded

   Copy code to clipboard

Procedure

1. Install the eBPF Manager Operator:

   1. In the OpenShift Container Platform web console, click Ecosystem → Software Catalog.
   2. Select eBPF Manager Operator from the list of available Operators, and if prompted to Show community Operator, click Continue.
   3. Click Install.
   4. On the Install Operator page, under Installed Namespace, select Operator recommended Namespace.
   5. Click Install.

2. Verify that the eBPF Manager Operator is installed successfully:

   1. Navigate to the Ecosystem → Installed Operators page.

   2. Ensure that eBPF Manager Operator is listed in the openshift-ingress-node-firewall project with a Status of InstallSucceeded.

      Note

      During installation an Operator might display a Failed status. If the installation later succeeds with an InstallSucceeded message, you can ignore the Failed message.

      If the Operator does not have a Status of InstallSucceeded, troubleshoot using the following steps:

      • Inspect the Operator Subscriptions and Install Plans tabs for any failures or errors under Status.
      • Navigate to the Workloads → Pods page and check the logs for pods in the bpfman project.

Procedure

1. To download the manifest, enter the following command:

   $ curl -L https://github.com/bpfman/bpfman/releases/download/v0.5.1/go-xdp-counter-install-selinux.yaml -o go-xdp-counter-install-selinux.yaml

   Copy code to clipboard

2. To deploy the sample eBPF application, enter the following command:

   $ oc create -f go-xdp-counter-install-selinux.yaml

   Copy code to clipboard

   Example output

   namespace/go-xdp-counter created
   serviceaccount/bpfman-app-go-xdp-counter created
   clusterrolebinding.rbac.authorization.k8s.io/xdp-binding created
   daemonset.apps/go-xdp-counter-ds created
   xdpprogram.bpfman.io/go-xdp-counter-example created
   selinuxprofile.security-profiles-operator.x-k8s.io/bpfman-secure created

   Copy code to clipboard

3. To confirm that the eBPF sample application deployed successfully, enter the following command:

   $ oc get all -o wide -n go-xdp-counter

   Copy code to clipboard

   Example output

   NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                 NOMINATED NODE   READINESS GATES
   pod/go-xdp-counter-ds-4m9cw   1/1     Running   0          44s   10.129.0.92    ci-ln-dcbq7d2-72292-ztrkp-master-1   <none>           <none>
   pod/go-xdp-counter-ds-7hzww   1/1     Running   0          44s   10.130.0.86    ci-ln-dcbq7d2-72292-ztrkp-master-2   <none>           <none>
   pod/go-xdp-counter-ds-qm9zx   1/1     Running   0          44s   10.128.0.101   ci-ln-dcbq7d2-72292-ztrkp-master-0   <none>           <none>
   
   NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS       IMAGES                                           SELECTOR
   daemonset.apps/go-xdp-counter-ds   3         3         3       3            3           <none>          44s   go-xdp-counter   quay.io/bpfman-userspace/go-xdp-counter:v0.5.0   name=go-xdp-counter

   Copy code to clipboard

4. To confirm that the example XDP program is running, enter the following command:

   $ oc get xdpprogram go-xdp-counter-example

   Copy code to clipboard

   Example output

   NAME                     BPFFUNCTIONNAME   NODESELECTOR   STATUS
   go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess

   Copy code to clipboard

5. To confirm that the XDP program is collecting data, enter the following command:

   $ oc logs <pod_name> -n go-xdp-counter

   Copy code to clipboard

   Replace <pod_name> with the name of an XDP program pod, such as go-xdp-counter-ds-4m9cw.

   Example output

   2024/08/13 15:20:06 15016 packets received
   2024/08/13 15:20:06 93581579 bytes received
   ...

   Copy code to clipboard

Procedure

1. Check the name of an install plan, such as install-zcvlr, by running the following command:

   $ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

   Copy code to clipboard

2. Check if the status of an install plan is Complete by running the following command:

   $ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'

   Copy code to clipboard

3. View the status of the external-dns-operator deployment by running the following command:

   $ oc get -n external-dns-operator deployment/external-dns-operator

   Copy code to clipboard

   Example output

   NAME                    READY     UP-TO-DATE   AVAILABLE   AGE
   external-dns-operator   1/1       1            1           23h

   Copy code to clipboard

Procedure

1. Click Ecosystem → Software Catalog in the OpenShift Container Platform web console.
2. Click External DNS Operator. You can use the Filter by keyword text box or the filter list to search for External DNS Operator from the list of Operators.
3. Select the external-dns-operator namespace.
4. On the External DNS Operator page, click Install.

5. On the Install Operator page, ensure that you selected the following options:

   1. Update the channel as stable-v1.
   2. Installation mode as A specific name on the cluster.
   3. Installed namespace as external-dns-operator. If namespace external-dns-operator does not exist, the Operator gets created during the Operator installation.
   4. Select Approval Strategy as Automatic or Manual. The Approval Strategy defaults to Automatic.

   5. Click Install.

      If you select Automatic updates, the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without any intervention.

      If you select Manual updates, the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the Operator updated to the new version.

Procedure

1. Create a Namespace object:

   1. Create a YAML file that defines the Namespace object:

      Example namespace.yaml file

      apiVersion: v1
      kind: Namespace
      metadata:
        name: external-dns-operator
      # ...

      Copy code to clipboard

   2. Create the Namespace object by running the following command:

      $ oc apply -f namespace.yaml

      Copy code to clipboard

2. Create an OperatorGroup object:

   1. Create a YAML file that defines the OperatorGroup object:

      Example operatorgroup.yaml file

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        upgradeStrategy: Default
        targetNamespaces:
        - external-dns-operator
      # ...

      Copy code to clipboard

   2. Create the OperatorGroup object by running the following command:

      $ oc apply -f operatorgroup.yaml

      Copy code to clipboard

3. Create a Subscription object:

   1. Create a YAML file that defines the Subscription object:

      Example subscription.yaml file

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: external-dns-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      # ...

      Copy code to clipboard

   2. Create the Subscription object by running the following command:

      $ oc apply -f subscription.yaml

      Copy code to clipboard

Verification

1. Get the name of the install plan from the subscription by running the following command:

   $ oc -n external-dns-operator \
     get subscription external-dns-operator \
     --template='{{.status.installplan.name}}{{"\n"}}'

   Copy code to clipboard

2. Verify that the status of the install plan is Complete by running the following command:

   $ oc -n external-dns-operator \
     get ip <install_plan_name> \
     --template='{{.status.phase}}{{"\n"}}'

   Copy code to clipboard

3. Verify that the status of the external-dns-operator pod is Running by running the following command:

   $ oc -n external-dns-operator get pod

   Copy code to clipboard

   Example output

   NAME                                     READY   STATUS    RESTARTS   AGE
   external-dns-operator-5584585fd7-5lwqm   2/2     Running   0          11m

   Copy code to clipboard

4. Verify that the catalog source of the subscription is redhat-operators by running the following command:

   $ oc -n external-dns-operator get subscription

   Copy code to clipboard

5. Check the external-dns-operator version by running the following command:

   $ oc -n external-dns-operator get csv

   Copy code to clipboard

Procedure

1. Check the user profile by running the following command. The profile, such as system:admin, must have access to the kube-system namespace. If you do not have the credentials, you can fetch the credentials from the kube-system namespace to use the cloud provider client by running the following command:

   $ oc whoami

   Copy code to clipboard

2. Fetch the values from the aws-creds secret that exists in the kube-system namespace.

   $ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)

   Copy code to clipboard

   $ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

   Copy code to clipboard

3. Get the routes to check the domain:

   $ oc get routes --all-namespaces | grep console

   Copy code to clipboard

   Example output

   openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
   openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

   Copy code to clipboard

4. Get the list of DNS zones and find the DNS zone that corresponds to the domain of the route that you previously queried:

   $ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

   Copy code to clipboard

   Example output

   HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

   Copy code to clipboard

5. Create the ExternalDNS CR for the route source:

   $ cat <<EOF | oc create -f -
   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: sample-aws
   spec:
     domains:
     - filterType: Include
       matchType: Exact
       name: testextdnsoperator.apacshift.support
     provider:
       type: AWS
     source:
       type: OpenShiftRoute
       openshiftRouteOptions:
         routerName: default
   EOF

   Copy code to clipboard

   where:

   metadata.name

   Specifies the name of the external DNS resource.

   spec.domains

   By default all hosted zones are selected as potential targets. You can include a hosted zone that you need.

   domains.matchType

   Specifies that the matching of the domain from the target zone has to be exact. Exact as opposed to regular expression match.

   domains.name

   Specifies the exact domain of the zone you want to update. The hostname of the routes must be subdomains of the specified domain.

   provider.type

   Specifies the AWS Route53 DNS provider.

   source

   Specifies the options for the source of DNS records.

   source.type

   Specifies the OpenShiftRoute resource as the source for the DNS records which gets created in the previously specified DNS provider.

   openshiftRouteOptions.routerName

   If the source is OpenShiftRoute, then you can pass the OpenShift Ingress Controller name. External DNS Operator selects the canonical hostname of that router as the target while creating the CNAME record.

6. Check the records created for OpenShift Container Platform routes by using the following command:

   $ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

   Copy code to clipboard

Procedure

1. Get the Role ARN of the IAM Role that you created to allow Account B to access Account A’s Route 53 hosted zone by running the following command:

   $ aws --profile account-a iam get-role --role-name user-rol1 | head -1

   Copy code to clipboard

   Example output

   ROLE	arn:aws:iam::1234567890123:role/user-rol1	2023-09-14T17:21:54+00:00	3600	/	AROA3SGB2ZRKRT5NISNJN	user-rol1

   Copy code to clipboard

2. Locate the private hosted zone to use with Account A’s credentials by running the following command:

   $ aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

   Copy code to clipboard

   Example output

   HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support. 5

   Copy code to clipboard

3. Create the ExternalDNS object by running the following command:

   $ cat <<EOF | oc create -f -
   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: sample-aws
   spec:
     domains:
     - filterType: Include
       matchType: Exact
       name: testextdnsoperator.apacshift.support
     provider:
       type: AWS
       aws:
         assumeRole:
           arn: arn:aws:iam::12345678901234:role/user-rol1
     source:
       type: OpenShiftRoute
       openshiftRouteOptions:
         routerName: default
   EOF

   Copy code to clipboard

   where:

   arn

   Specifies the Role ARN to have DNS records created in Account A.

4. Check the records created for OpenShift Container Platform routes by entering the following command:

   $ aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-console

   Copy code to clipboard

Procedure

1. Fetch the credentials from the kube-system namespace to use the cloud provider client by running the following command:

   $ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)

   Copy code to clipboard

   $ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)

   Copy code to clipboard

   $ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)

   Copy code to clipboard

   $ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)

   Copy code to clipboard

   $ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

   Copy code to clipboard

2. Log in to Azure by running the following command:

   $ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

   Copy code to clipboard

3. Get a list of routes by running the following command:

   $ oc get routes --all-namespaces | grep console

   Copy code to clipboard

   Example output

   openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
   openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

   Copy code to clipboard

4. Get a list of DNS zones.

   1. For public DNS zones, enter the following command:

      $ az network dns zone list --resource-group "${RESOURCE_GROUP}"

      Copy code to clipboard

   2. For private DNS zones, enter the following command:

      $ az network private-dns zone list -g "${RESOURCE_GROUP}"

      Copy code to clipboard

5. Create a YAML file, for example, external-dns-sample-azure.yaml, that defines the ExternalDNS object:

   Example external-dns-sample-azure.yaml file

   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: sample-azure
   spec:
     zones:
     - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com"
     provider:
       type: Azure
     source:
       openshiftRouteOptions:
         routerName: default
       type: OpenShiftRoute
   # ...

   Copy code to clipboard

   where:

   metadata.name

   Specifies the External DNS name.

   spec.zones

   Specifies the zone ID. For a private DNS zone, change dnszones to privateDnsZones.

   provider.type

   Specifies the provider type.

   source.openshiftRouteOptions

   Specifies the options for the source of DNS records.

   routerName

   If the source type is OpenShiftRoute, you can pass the OpenShift Ingress Controller name. The External DNS Operator selects the canonical hostname of that router as the target while creating the CNAME record.

   source.type

   Specifies the route resource as the source for the Azure DNS records.

Troubleshooting

1. Check the records created for the routes.

   1. For public DNS zones, enter the following command:

      $ az network dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep console

      Copy code to clipboard

   2. For private DNS zones, enter the following command:

      $ az network private-dns record-set list -g "${RESOURCE_GROUP}" -z "${ZONE_NAME}" | grep console

      Copy code to clipboard

Procedure

1. Copy the gcp-credentials secret in the encoded-gcloud.json file by running the following command:

   $ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

   Copy code to clipboard

2. Export your Google credentials by running the following command:

   $ export GOOGLE_CREDENTIALS=decoded-gcloud.json

   Copy code to clipboard

3. Activate your account by using the following command:

   $ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

   Copy code to clipboard

4. Set your project by running the following command:

   $ gcloud config set project <project_id as per decoded-gcloud.json>

   Copy code to clipboard

5. Get a list of routes by running the following command:

   $ oc get routes --all-namespaces | grep console

   Copy code to clipboard

   Example output

   openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
   openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

   Copy code to clipboard

6. Get a list of managed zones, such as qe-cvs4g-private-zone test.gcp.example.com, by running the following command:

   $ gcloud dns managed-zones list | grep test.gcp.example.com

   Copy code to clipboard

7. Create a YAML file, for example, external-dns-sample-gcp.yaml, that defines the ExternalDNS object:

   Example external-dns-sample-gcp.yaml file

   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: sample-gcp
   spec:
     domains:
       - filterType: Include
         matchType: Exact
         name: test.gcp.example.com
     provider:
       type: GCP
     source:
       openshiftRouteOptions:
         routerName: default
       type: OpenShiftRoute
   # ...

   Copy code to clipboard

   where:

   metadata.name

   Specifies the External DNS name.

   spec.domains.filterType

   By default, all hosted zones are selected as potential targets. You can include your hosted zone.

   spec.domains.matchType

   Specifies the domain of the target that must match the string defined by the name key.

   spec.domains.name

   Specifies the exact domain of the zone you want to update. The hostname of the routes must be subdomains of the specified domain.

   spec.provider.type

   Specifies the provider type.

   source.openshiftRouteOptions

   Specifies options for the source of DNS records.

   openshiftRouteOptions.routerName

   If the source type is OpenShiftRoute, you can pass the OpenShift Ingress Controller name. External DNS selects the canonical hostname of that router as the target while creating a CNAME record.

   type

   Specifies the route resource as the source for Google Cloud DNS records.

8. Check the DNS records created for OpenShift Container Platform routes by running the following command:

   $ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console

   Copy code to clipboard

Procedure

1. Create a secret object with Infoblox credentials by running the following command:

   $ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

   Copy code to clipboard

2. Get a list of routes by running the following command:

   $ oc get routes --all-namespaces | grep console

   Copy code to clipboard

   Example output

   openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
   openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

   Copy code to clipboard

3. Create a YAML file, for example, external-dns-sample-infoblox.yaml, that defines the ExternalDNS object:

   Example external-dns-sample-infoblox.yaml file

   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: sample-infoblox
   spec:
     provider:
       type: Infoblox
       infoblox:
         credentials:
           name: infoblox-credentials
         gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
         wapiPort: 443
         wapiVersion: "2.3.1"
     domains:
     - filterType: Include
       matchType: Exact
       name: test.example.com
     source:
       type: OpenShiftRoute
       openshiftRouteOptions:
         routerName: default

   Copy code to clipboard

   where:

   metadata.name

   Specifies the External DNS name.

   provider.type

   Specifies the provider type.

   source.type

   Specifies options for the source of DNS records.

   routerName

   If the source type is OpenShiftRoute, you can pass the OpenShift Ingress Controller name. External DNS selects the canonical hostname of that router as the target while creating a CNAME record.

4. Create the ExternalDNS resource on Infoblox by running the following command:

   $ oc create -f external-dns-sample-infoblox.yaml

   Copy code to clipboard

5. From the Infoblox UI, check the DNS records created for console routes:

   1. Click Data Management → DNS → Zones.
   2. Select the zone name.

Procedure

1. Create the config map to contain the CA bundle in the external-dns-operator namespace by running the following command:

   $ oc -n external-dns-operator create configmap trusted-ca

   Copy code to clipboard

2. To inject the trusted CA bundle into the config map, add the config.openshift.io/inject-trusted-cabundle=true label to the config map by running the following command:

   $ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true

   Copy code to clipboard

3. Update the subscription of the External DNS Operator by running the following command:

   $ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

   Copy code to clipboard

Procedure

1. In the OpenShift Container Platform web console, navigate to Ecosystem → Software Catalog.

2. Type metallb in the Filter by keyword box to find the MetalLB Operator.

   You can also filter options by Infrastructure Features. For example, select Disconnected if you want to see Operators that work in disconnected environments, also known as restricted network environments.

3. Click the MetalLB Operator tile and click Install.

4. On the Install Operator page, accept the defaults and click Install.

   The web console displays the Installing Operator page with a status update. Wait until the Operator installs before continuing.

5. The web console displays the progress of the installation. When the installation is complete, click View installed Operators.

Verification

1. To confirm that the installation is successful:

   1. Navigate to the Ecosystem → Installed Operators page.
   2. Check that the Operator is installed in the metallb-system namespace and that its status is Succeeded.

2. If the Operator is not installed successfully, check the status of the Operator and review the logs:

   1. Navigate to the Ecosystem → Installed Operators page and inspect the Status column for any errors or failures.
   2. Navigate to the Workloads → Pods page and check the logs in any pods in the metallb-system project that are reporting issues.

Procedure

1. Create a namespace for the MetalLB Operator by entering the following command:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: metallb-system
   EOF

   Copy code to clipboard

2. Create an Operator group custom resource (CR) in the namespace:

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: metallb-operator
     namespace: metallb-system
   EOF

   Copy code to clipboard

3. Confirm the Operator group is installed in the namespace:

   $ oc get operatorgroup -n metallb-system

   Copy code to clipboard

   The following is example output:

   NAME               AGE
   metallb-operator   14m

   Copy code to clipboard

4. Create a Subscription CR:

   1. Define the Subscription CR and save the YAML file, for example, metallb-sub.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator-sub
        namespace: metallb-system
      spec:
        channel: stable
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

      Copy code to clipboard
      • For the spec.source parameter, must specify the redhat-operators value.

   2. To create the Subscription CR, run the following command:

      $ oc apply -f metallb-sub.yaml

      Copy code to clipboard

5. Optional: To ensure BGP and BFD metrics appear in Prometheus, you can label the namespace as in the following command:

   $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"

   Copy code to clipboard

1. Verify that the Operator installed successfully by running the following command. Wait until the PHASE displays Succeeded:

   $ oc get clusterserviceversion -n metallb-system \
     -o custom-columns=Name:.metadata.name,Phase:.status.phase

   Copy code to clipboard

   The following is example output:

   Name                                                Phase
   metallb-operator.{product-version}.0-nnnnnnnnnnnn   Succeeded

   Copy code to clipboard
   Note

   Installation of the Operator might take a few seconds.

2. Confirm that the install plan is in the namespace:

   $ oc get installplan -n metallb-system

   Copy code to clipboard

   The following is example output:

   NAME            CSV                                                 APPROVAL    APPROVED
   install-wzg94   metallb-operator.4.22.0-nnnnnnnnnnnn   Automatic   true

   Copy code to clipboard

Procedure

1. Create a single instance of a MetalLB custom resource:

   $ cat << EOF | oc apply -f -
   apiVersion: metallb.io/v1beta1
   kind: MetalLB
   metadata:
     name: metallb
     namespace: metallb-system
   EOF

   Copy code to clipboard
   • For the metadata.namespace parameter, substitute metallb-system with openshift-operators if you installed the MetalLB Operator using the web console.

1. Verify that the deployment for the controller is running:

   $ oc get deployment -n metallb-system controller

   Copy code to clipboard

   The following is example output:

   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
   controller   1/1     1            1           11m

   Copy code to clipboard

2. Verify that the daemon set for the speaker is running:

   $ oc get daemonset -n metallb-system speaker

   Copy code to clipboard

   The following is example output:

   NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
   speaker   6         6         6       6            6           kubernetes.io/os=linux   18m

   Copy code to clipboard

   The example output indicates six speaker pods. The number of speaker pods in your cluster might differ from the example output. Verify that the number of speaker pods equals the number of nodes in your cluster. For example, a single-node cluster has one speaker pod.

Procedure

1. Get the YAML definition of the metallb-operator subscription in the metallb-system namespace by entering the following command:

   $ oc -n metallb-system get subscription metallb-operator -o yaml

   Copy code to clipboard

2. Edit the Subscription CR by setting the installPlanApproval parameter to Manual:

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: metallb-operator
     namespace: metallb-system
   # ...
   spec:
      channel: stable
      installPlanApproval: Manual
      name: metallb-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
   # ...

   Copy code to clipboard

3. Find the latest OpenShift Container Platform 4.22 version of the MetalLB Operator by entering the following command:

   $ oc -n metallb-system get csv

   Copy code to clipboard

4. Check the install plan that exists in the namespace by entering the following command.

   $ oc -n metallb-system get installplan

   Copy code to clipboard

   The following example output shows install-tsz2g as a manual install plan:

   NAME            CSV                                     APPROVAL    APPROVED
   install-shpmd   metallb-operator.v4.22.0-202502261233   Automatic   true
   install-tsz2g   metallb-operator.v4.22.0-202503102139   Manual      false

   Copy code to clipboard

5. Edit the install plan that exists in the namespace by entering the following command. Ensure that you replace <name_of_installplan> with the name of the install plan, such as install-tsz2g.

   $ oc edit installplan <name_of_installplan> -n metallb-system

   Copy code to clipboard

   1. With the install plan open in your editor, set the spec.approval parameter to Manual and set the spec.approved parameter to true.

      Note

      After you edit the install plan, the upgrade operation starts. If you enter the oc -n metallb-system get csv command during the upgrade operation, the output might show the Replacing or the Pending status.

Procedure

1. Change managementState to Unmanaged in the DNS Operator by running the following command:

   oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

   Copy code to clipboard

2. Review managementState of the DNS Operator by using the jsonpath command-line JSON parser:

   $ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'

   Copy code to clipboard

Procedure

1. Modify the DNS Operator object named default:

   $ oc edit dns.operator/default

   Copy code to clipboard

   Cluster administrators can configure transport layer security (TLS) for forwarded DNS queries.

   Configuring DNS forwarding with TLS

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example_server
       zones:
       - example.com
       forwardPlugin:
         transportConfig:
           transport: TLS
           tls:
             caBundle:
               name: mycacert
             serverName: dnstls.example.com
         policy: Random
         upstreams:
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers:
       transportConfig:
         transport: TLS
         tls:
           caBundle:
             name: mycacert
           serverName: dnstls.example.com
       upstreams:
       - type: Network
         address: 1.2.3.4
         port: 53

   Copy code to clipboard

   where:

   spec.servers.name

   Must comply with the rfc6335 service name syntax.

   spec.servers.zones

   Must conform to the rfc1123 subdomain syntax. The cluster domain, cluster.local, is invalid for zones.

   spec.servers.forwardPlugin.transportConfig.transport

   Must be set to TLS when configuring TLS forwarding.

   spec.servers.forwardPlugin.transportConfig.tls.serverName

   Must be set to the server name indication (SNI) server name used to validate the upstream TLS certificate.

   spec.servers.forwardPlugin.policy

   Specifies the upstream selection policy. Defaults to Random; valid values are RoundRobin and Sequential.

   spec.servers.forwardPlugin.upstreams

   Must provide upstream resolvers; maximum 15 entries per forwardPlugin.

   spec.upstreamResolvers.upstreams

   Specifies an optional field to override the default policy for the default domain. Use the Network type only when TLS is enabled and provide an IP address. If omitted, queries use /etc/resolv.conf.

   spec.upstreamResolvers.upstreams.address

   Must be a valid IPv4 or IPv6 address.

   spec.upstreamResolvers.upstreams.port

   Specifies an optional field to provide a port number. Valid values are between 1 and 65535; defaults to 853 when omitted.

   Note

   If servers is undefined or invalid, the config map only contains the default server.

Verification

1. View the config map:

   $ oc get configmap/dns-default -n openshift-dns -o yaml

   Copy code to clipboard

   Sample DNS ConfigMap based on TLS forwarding example

   apiVersion: v1
   data:
     Corefile: |
       example.com:5353 {
           forward . 1.1.1.1 2.2.2.2:5353
       }
       bar.com:5353 example.com:5353 {
         forward . 3.3.3.3 4.4.4.4:5454
       }
       .:5353 {
           errors
           health
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               upstream
               fallthrough in-addr.arpa ip6.arpa
           }
           prometheus :9153
           forward . /etc/resolv.conf 1.2.3.4:53 {
               policy Random
           }
           cache 30
           reload
       }
   kind: ConfigMap
   metadata:
     labels:
       dns.operator.openshift.io/owning-dns: default
     name: dns-default
     namespace: openshift-dns

   Copy code to clipboard

   • The data.Corefile key contains the Corefile configuration for the DNS server. Changes to the forwardPlugin triggers a rolling update of the CoreDNS daemon set.

1. Create a Secret resource containing the custom certificate in the openshift-ingress namespace using the tls.crt and tls.key files.

   $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

   Copy code to clipboard

2. Update the IngressController CR to reference the new certificate secret:

   $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
     --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

   Copy code to clipboard

3. Verify the update was effective:

   $ echo Q |\
     openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
     openssl x509 -noout -subject -issuer -enddate

   Copy code to clipboard

   where:

   <domain>

   Specifies the base domain name for your cluster.

   Example output

   subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
   issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
   notAfter=May 10 08:32:45 2022 GM

   Copy code to clipboard

   Tip

   You can alternatively apply the following YAML to set a custom default certificate:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     defaultCertificate:
       name: custom-certs-default

   Copy code to clipboard

   The certificate secret name should match the value used to update the CR.

Procedure

1. Create a service account to authenticate with Thanos by running the following command:

   $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos

   Copy code to clipboard

   Example output

   Name:                thanos
   Namespace:           openshift-ingress-operator
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-kfvf2
   Mountable secrets:   thanos-dockercfg-kfvf2
   Tokens:              <none>
   Events:              <none>

   Copy code to clipboard

2. Manually create the service account secret token with the following command:

   $ oc apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: thanos-token
     namespace: openshift-ingress-operator
     annotations:
       kubernetes.io/service-account.name: thanos
   type: kubernetes.io/service-account-token
   EOF

   Copy code to clipboard

3. Define a TriggerAuthentication object within the openshift-ingress-operator namespace by using the service account’s token.

   1. Create the TriggerAuthentication object and pass the value of the secret variable to the TOKEN parameter:

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF

      Copy code to clipboard

4. Create and apply a role for reading metrics from Thanos:

   1. Create a new role, thanos-metrics-reader.yaml, that reads metrics from pods and nodes:

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get

      Copy code to clipboard

   2. Apply the new role by running the following command:

      $ oc apply -f thanos-metrics-reader.yaml

      Copy code to clipboard

5. Add the new role to the service account by entering the following commands:

   $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator

   Copy code to clipboard

   $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos

   Copy code to clipboard
   Note

   The argument add-cluster-role-to-user is only required if you use cross-namespace queries. The following step uses a query from the kube-metrics namespace which requires this argument.

6. Create a new ScaledObject YAML file, ingress-autoscaler.yaml, that targets the default Ingress Controller deployment:

   Example ScaledObject definition

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
     namespace: openshift-ingress-operator
   spec:
     scaleTargetRef: 1
       apiVersion: operator.openshift.io/v1
       kind: IngressController
       name: default
       envSourceContainerName: ingress-operator
     minReplicaCount: 1
     maxReplicaCount: 20 2
     cooldownPeriod: 1
     pollingInterval: 1
     triggers:
     - type: prometheus
       metricType: AverageValue
       metadata:
         serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 3
         namespace: openshift-ingress-operator 4
         metricName: 'kube-node-role'
         threshold: '1'
         query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 5
         authModes: "bearer"
       authenticationRef:
         name: keda-trigger-auth-prometheus

   Copy code to clipboard

   1

   The custom resource that you are targeting. In this case, the Ingress Controller.

   2

   Optional: The maximum number of replicas. If you omit this field, the default maximum is set to 100 replicas.

   3

   The Thanos service endpoint in the openshift-monitoring namespace.

   4

   The Ingress Operator namespace.

   5

   This expression evaluates to however many worker nodes are present in the deployed cluster.

   Important

   If you are using cross-namespace queries, you must target port 9091 and not port 9092 in the serverAddress field. You also must have elevated privileges to read metrics from this port.

7. Apply the custom resource definition by running the following command:

   $ oc apply -f ingress-autoscaler.yaml

   Copy code to clipboard