Managing Virtual Machines with Red Hat OpenShift Virtualization

Instructions

1. As the admin user, navigate to the Red Hat OpenShift web console, and confirm that the mariadb-server VM and the mariadb-client VM are running.

   1. From a command line, log in to your Red Hat OpenShift cluster as the admin user with redhatocp as the password.

      [student@workstation ~]$ oc login -u admin -p redhatocp \
        https://api.ocp4.example.com:6443
      Login Successful
      ...output omitted...

   2. Identify the URL for the OpenShift web console.

      [student@workstation ~]$ oc whoami --show-console
      https://console-openshift-console.apps.ocp4.example.com

   3. Set the network-services project as the active project.

      [student@workstation ~]$ oc project network-services
      Now using project "network-services" on server "https://api.ocp4.example.com:6443".

   4. Open a web browser and navigate to https://console-openshift-console.apps.ocp4.example.com. Select htpasswd_provider and log in as the admin user with redhatocp as the password.

   5. Navigate to Virtualization → VirtualMachines and then select the network-services project. Confirm that the mariadb-client and mariadb-server VMs are running.

2. Add the app: mariadb-server label to the mariadb-server VM. You use this label later in the exercise.

   1. From the web console, navigate to Virtualization → VirtualMachines, select the mariadb-server VM, and then navigate to the YAML tab to access the YAML editor.

   2. Add the app: mariadb-server label in the .spec.template.metadata.labels path.

      ...output omitted...
      spec:
        dataVolumeTemplates:
        ...output omitted...
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: mariadb-server
              flavor.template.kubevirt.io/small: "true"
              kubevirt.io/domain: mariadb-server
              kubevirt.io/size: small
              ...output omitted...

      Click Save to save the changes.

   3. Restart the VM so that Kubernetes re-creates an instance that includes the new label. From the web console, click Actions → Restart.

   4. From the command line, use oc get vmi,pods command to confirm that Kubernetes re-creates the VMI resource and the virt-launcher pod. You might have to run the command several times because it takes time for the pod to start.

      [student@workstation ~]$ oc get vmi,pods
      NAME                                               AGE  PHASE    IP         ...
      virtualmachineinstance.kubevirt.io/mariadb-client  24m  Running  10.8.2.33  ...
      virtualmachineinstance.kubevirt.io/mariadb-server  94s  Running  10.11.0.41 ...
      
      NAME                                     READY   STATUS    RESTARTS   AGE
      pod/virt-launcher-mariadb-client-dcjtc   1/1     Running   0          24m
      pod/virt-launcher-mariadb-server-274ts   1/1     Running   0          94s

3. Create a service named mariadb with the ClusterIP type. Use the app: mariadb-server label for the selector. The service must listen on TCP port 3306 and forward the traffic to the VM on port 3306.

   1. From the web console, navigate to Networking → Services, select the network-services project, and then click Create Service. Complete the YAML file with the following content and then click Create.

      By using this configuration, the DNS operator creates the mariadb.network-services.svc.cluster.local record.

      apiVersion: v1
      kind: Service
      metadata:
        name: mariadb
        namespace: network-services
      spec:
        type: ClusterIP
        selector:
          app: mariadb-server
        ports:
          - protocol: TCP
            port: 3306
            targetPort: 3306

      The lab command prepared the ~/DO316/labs/network-services/solutions/mariadb.yaml file so that you can compare it with your version.

   2. From the command line, confirm that the mariadb service has an active endpoint.

      [student@workstation ~]$ oc get endpoints
      NAME      ENDPOINTS         AGE
      mariadb   10.11.0.41:3306   110s

4. Log in to the mariadb-client VM, and then verify database connectivity.

   1. From the web console, navigate to Virtualization → VirtualMachines, select the mariadb-client VM, and then access the Console tab.

   2. Log in as the developer user with developer as the password.

   3. Connect to the sakila database that is running on the mariadb-server VM. Use the DNS service name to access the database and log in as the devuser user with developer as the password.

      [developer@mariadb-client ~]$ mysql -u devuser -p'developer' \
        -h mariadb.network-services.svc.cluster.local sakila
      Welcome to the MariaDB monitor. Commands end with ; or \g.
      Your MariaDB connection id is 9
      Server version: 10.3.28-MariaDB MariaDB Server
      
      Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
      
      Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
      
      MariaDB [(sakila)]>

   4. List the tables of the sakila database, and log out.

      MariaDB [sakila]> SHOW TABLES;
      \+------------------+
      | Tables_in_sakila |
      \+------------------+
      | actors           |
      | actor_info       |
      | address          |
      | category         |
      ...output omitted...
      
      MariaDB [sakila]> quit
      Bye
      [developer@mariadb-client ~]$

   5. Inspect and confirm that the DHCP server that is running inside the virt-launcher pod configures the VM system to use the short service name.

      Review the search line in the /etc/resolv.conf file.

      With that configuration, you can refer to the mariadb service as mariadb, mariadb.network-services, or mariadb.network-services.svc.

      [developer@mariadb-client ~]$ cat /etc/resolv.conf
      # Generated by NetworkManager
      search network-services.svc.cluster.local svc.cluster.local cluster.local ocp4.example.com srv.example.com
      nameserver 172.30.0.10
      [developer@mariadb-client ~]$

   6. Access the sakila database by using the mariadb.network-services host. Log out of the database after confirming that you can use the short name.

      [developer@mariadb-client ~]$ mysql -u devuser -p'developer' \
        -h mariadb.network-services sakila
      Welcome to the MariaDB monitor. Commands end with ; or \g.
      ...output omitted...
      MariaDB [sakila]> quit
      Bye
      [developer@mariadb-client ~]$

5. Verify that you can access the database that is running on the mariadb-server VM from any namespace. Start an interactive pod by using the quay.io/redhattraining/mariadb:10.5 image, which provides the mysql client command.

   1. From the command line, run a temporary interactive pod in the default namespace. The pod uses the quay.io/redhattraining/mariadb:10.5 image, which provides the mysql command.

      [student@workstation ~]$ oc run testdb -it --rm -n default \
        --image=quay.io/redhattraining/mariadb:10.5 --command \
        -- mysql --connect-timeout=5 -u devuser -p'developer' \
        -h mariadb.network-services.svc.cluster.local sakila
      If you don't see a command prompt, try pressing enter.
      
      MariaDB [(sakila)]>

      Note

      You can copy and paste the command from the ~/DO316/labs/network-services/solutions/commands.txt file that the lab command prepared for you.

   2. Execute an SQL query to verify connectivity. When done, log out of the database.

      The test confirms that you can access the service from any namespace.

      MariaDB [sakila]> SHOW TABLES;
      \+----------------------------+
      | Tables_in_sakila           |
      \+----------------------------+
      | actor                      |
      | actor_info                 |
      | address                    |
      | category                   |
      ...output omitted...
      MariaDB [sakila]> quit
      Bye
      Session ended, resume using 'oc attach testdb -c testdb -i -t' command when the pod is running
      pod "testdb" deleted
      [student@workstation ~]$

6. Protect the database server so that only clients running in the network-services namespace can access it.

   1. Add the allowing=db-clients label to the network-services namespace. You use that label later when you create the network policy.

      From the web console, navigate to Administration → Namespaces, select the network-services namespace, and then access the Details tab. Click Edit in the Labels section.

      Add the allowing=db-clients label and then click Save. Do not remove any labels that might exist.

   2. Prepare the network policy resource. From the web console, navigate to Networking → NetworkPolicies, select the network-services project, click Create Network Policy, and then click YAML view. Complete the file with the following content and then click Create.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-db-clients
        namespace: network-services
      spec:
        podSelector: 
          matchLabels:
            app: mariadb-server
        ingress: 
        - from:
          - namespaceSelector:
              matchLabels:
                allowing: db-clients
          ports:
          - port: 3306
            protocol: TCP

      	The podSelector section indicates that the policy applies to pods with the app: mariadb-server label. You previously set that label to the virt-launcher pod, which is associated with the mariadb-server VM.
      	The ingress section enables inbound connections to port 3306 from all pods in namespaces with the allowing: db-clients label.

      Note

      The ~/DO316/labs/network-services/solutions/policy.yaml file contains the correct configuration, and you can use it for comparison.

7. Confirm that the mariadb-client VM can still access the database. That VM is running in the network-services namespace. Confirm that pods that are running in a different namespace can no longer access the database.

   1. Access the serial console of the mariadb-client VM, and connect to the database server to use the sakila database to list the available tables.

      [developer@mariadb-client ~]$ mysql -u devuser -p'developer' \
        -h mariadb.network-services sakila
      ...output omitted...
      MariaDB [sakila]> SHOW TABLES;
      \+------------------+
      | Tables_in_sakila |
      \+------------------+
      | actors           |
      | actor_info       |
      | address          |
      | category         |
      ...output omitted...

   2. From the command line, run the test pod again in the default namespace. The command does not display the MariaDB prompt, and times out after five seconds. The timeout confirms that you can access the database only from namespaces with the allowing: db-clients label.

      [student@workstation ~]$ oc run testdb -it --rm -n default \
        --image=quay.io/redhattraining/mariadb:10.5 --command -- \
        mysql --connect-timeout=5 -u devuser -p'developer' \
        -h mariadb.network-services.svc.cluster.local sakila
      If you don't see a command prompt, try pressing enter.
      
      Enter
      
      ERROR 2002 (HY000): Can't connect to MySQL server on 'mariadb.network-services.svc.cluster.local' (115)
      ...output omitted...