From f36c2b11f2b166a99e78171bfced2494480cc521 Mon Sep 17 00:00:00 2001 From: Avital Pinnick Date: Tue, 18 Apr 2023 12:36:12 +0300 Subject: [PATCH] BZ2187603: SCC and SA for DPDK checkup Signed-off-by: Avital Pinnick --- .../virt-checking-cluster-dpdk-readiness.adoc | 89 ++++++++++++++++--- ...easuring-latency-vm-secondary-network.adoc | 31 ++++--- .../monitoring/virt-monitoring-overview.adoc | 4 +- 3 files changed, 98 insertions(+), 26 deletions(-) diff --git a/modules/virt-checking-cluster-dpdk-readiness.adoc b/modules/virt-checking-cluster-dpdk-readiness.adoc index 4497db3f5b..017a8232a9 100644 --- a/modules/virt-checking-cluster-dpdk-readiness.adoc +++ b/modules/virt-checking-cluster-dpdk-readiness.adoc @@ -4,9 +4,19 @@ :_content-type: PROCEDURE [id="virt-checking-cluster-dpdk-readiness_{context}"] -= Checking cluster readiness to run DPDK applications with zero packet loss += DPDK checkup -Use a predefined checkup to verify if your {product-title} cluster node can run a virtual machine (VM) with a Data Plane Development Kit (DPDK) workload. The checkup runs traffic between a traffic generator pod and a VM running a test DPDK application, and checks for packet loss. +Use a predefined checkup to verify that your {product-title} cluster node can run a virtual machine (VM) with a Data Plane Development Kit (DPDK) workload with zero packet loss. The DPDK checkup runs traffic between a traffic generator pod and a VM running a test DPDK application. + +You run a DPDK checkup by performing the following steps: + +. Create a service account, role, and role bindings for the DPDK checkup and a service account for the traffic generator pod. +. Create a security context constraints resource for the traffic generator pod. +. Create a config map to provide the input to run the checkup and to store the results. +. Create a job to run the checkup. +. Review the results in the config map. +. Optional: To rerun the checkup, delete the existing config map and job and then create a new config map and job. +. When you are finished, delete the DPDK checkup resources. .Prerequisites * You have access to the cluster as a user with `cluster-admin` permissions. @@ -14,9 +24,10 @@ Use a predefined checkup to verify if your {product-title} cluster node can run * You have configured the compute nodes to run DPDK applications on VMs with zero packet loss. .Procedure -. Create a manifest file that contains the `ServiceAccount`, `Role`, and `RoleBinding` objects with permissions that the checkup requires for cluster access: + +. Create a `ServiceAccount`, `Role`, and `RoleBinding` manifest for the DPDK checkup and the traffic generator pod: + -.Example roles manifest +.Example service account, role, and rolebinding manifest file [%collapsible] ==== [source,yaml] @@ -80,17 +91,71 @@ roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: kubevirt-dpdk-checker +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: dpdk-checkup-traffic-gen-sa ---- ==== -. Apply the checkup roles manifest: +. Apply the `ServiceAccount`, `Role`, and `RoleBinding` manifest: + [source,terminal] ---- -$ oc apply -n -f .yaml +$ oc apply -n -f .yaml ---- -. Create a `ConfigMap` manifest that contains the input parameters for the checkup. The config map also stores the results of the checkup. +. Create a `SecurityContextConstraints` manifest for the traffic generator pod: ++ +.Example security context constraints manifest +[source,yaml] +---- +apiVersion: security.openshift.io/v1 +kind: SecurityContextConstraints +metadata: + name: dpdk-checkup-traffic-gen +allowHostDirVolumePlugin: true +allowHostIPC: false +allowHostNetwork: false +allowHostPID: false +allowHostPorts: false +allowPrivilegeEscalation: false +allowPrivilegedContainer: false +allowedCapabilities: +- IPC_LOCK +- NET_ADMIN +- NET_RAW +- SYS_RESOURCE +defaultAddCapabilities: null +fsGroup: + type: RunAsAny +groups: [] +readOnlyRootFilesystem: false +requiredDropCapabilities: null +runAsUser: + type: RunAsAny +seLinuxContext: + type: RunAsAny +seccompProfiles: +- runtime/default +- unconfined +supplementalGroups: + type: RunAsAny +users: +- system:serviceaccount:dpdk-checkup-ns:dpdk-checkup-traffic-gen-sa +volumes: +- hostPath +---- + +. Apply the `SecurityContextConstraints` manifest: ++ +[source,terminal] +---- +$ oc apply -f .yaml +---- + +. Create a `ConfigMap` manifest that contains the input parameters for the checkup: + .Example input config map [source,yaml] @@ -111,14 +176,14 @@ data: <3> The container image for the traffic generator. In this example, the image is pulled from the upstream Project Quay Container Registry. <4> The container disk image for the VM. In this example, the image is pulled from the upstream Project Quay Container Registry. -. Apply the config map manifest in the target namespace: +. Apply the `ConfigMap` manifest in the target namespace: + [source,terminal] ---- $ oc apply -n -f .yaml ---- -. Create a `Job` object to run the checkup: +. Create a `Job` manifest to run the checkup: + .Example job manifest [source,yaml] @@ -198,7 +263,7 @@ data: status.result.dropRate: 0 ---- -. Delete the job and config map resources that you previously created by running the following commands: +. Delete the job and config map that you previously created by running the following commands: + [source,terminal] ---- @@ -210,9 +275,9 @@ $ oc delete job -n dpdk-checkup $ oc delete config-map -n dpdk-checkup-config ---- -. Optional: If you do not plan to run another checkup, delete the checkup roles manifest: +. Optional: If you do not plan to run another checkup, delete the `ServiceAccount`, `Role`, and `RoleBinding` manifest: + [source,terminal] ---- -$ oc delete -f .yaml +$ oc delete -f .yaml ---- diff --git a/modules/virt-measuring-latency-vm-secondary-network.adoc b/modules/virt-measuring-latency-vm-secondary-network.adoc index b8e71edbe8..d7192ec20b 100644 --- a/modules/virt-measuring-latency-vm-secondary-network.adoc +++ b/modules/virt-measuring-latency-vm-secondary-network.adoc @@ -4,13 +4,18 @@ :_content-type: PROCEDURE [id="virt-measuring-latency-vm-secondary-network_{context}"] -= Checking network connectivity and latency for virtual machines on a secondary network += Virtual machine latency checkup -You use a predefined checkup to verify network connectivity and measure latency between two virtual machines (VMs) that are attached to a secondary network interface. +You use a predefined checkup to verify network connectivity and measure latency between two virtual machines (VMs) that are attached to a secondary network interface. The latency checkup uses the ping utility. -To run a checkup for the first time, follow the steps in the procedure. +You run a latency checkup by performing the following steps: -If you have previously run a checkup, skip to step 5 of the procedure because the steps to install the framework and enable permissions for the checkup are not required. +. Create a service account, roles, and rolebindings to provide cluster access permissions to the latency checkup. +. Create a config map to provide the input to run the checkup and to store the results. +. Create a job to run the checkup. +. Review the results in the config map. +. Optional: To rerun the checkup, delete the existing config map and job and then create a new config map and job. +. When you are finished, delete the latency checkup resources. .Prerequisites @@ -21,7 +26,7 @@ If you have previously run a checkup, skip to step 5 of the procedure because th .Procedure -. Create a manifest file that contains the `ServiceAccount`, `Role`, and `RoleBinding` objects with permissions that the checkup requires for cluster access: +. Create a `ServiceAccount`, `Role`, and `RoleBinding` manifest for the latency checkup: + .Example role manifest file [%collapsible] @@ -84,15 +89,15 @@ roleRef: ---- ==== -. Apply the checkup roles manifest: +. Apply the `ServiceAccount`, `Role`, and `RoleBinding` manifest: + [source,terminal] ---- -$ oc apply -n -f .yaml <1> +$ oc apply -n -f .yaml <1> ---- <1> `` is the namespace where the checkup is to be run. This must be an existing namespace where the `NetworkAttachmentDefinition` object resides. -. Create a `ConfigMap` manifest that contains the input parameters for the checkup. The config map provides the input for the framework to run the checkup and also stores the results of the checkup. +. Create a `ConfigMap` manifest that contains the input parameters for the checkup: + .Example input config map [source,yaml] @@ -123,7 +128,7 @@ data: $ oc apply -n -f .yaml ---- -. Create a `Job` object to run the checkup: +. Create a `Job` manifest to run the checkup: + .Example job manifest [source,yaml] @@ -155,7 +160,7 @@ spec: value: kubevirt-vm-latency-checkup-config ---- -. Apply the `Job` manifest. The checkup uses the ping utility to verify connectivity and measure latency. +. Apply the `Job` manifest: + [source,terminal] ---- @@ -212,7 +217,7 @@ data: $ oc logs job.batch/kubevirt-vm-latency-checkup -n ---- -. Delete the job and config map resources that you previously created by running the following commands: +. Delete the job and config map that you previously created by running the following commands: + [source,terminal] ---- @@ -224,9 +229,9 @@ $ oc delete job -n kubevirt-vm-latency-checkup $ oc delete config-map -n kubevirt-vm-latency-checkup-config ---- -. Optional: If you do not plan to run another checkup, delete the checkup role and framework manifest files. +. Optional: If you do not plan to run another checkup, delete the roles manifest: + [source,terminal] ---- -$ oc delete -f .yaml +$ oc delete -f .yaml ---- diff --git a/virt/support/monitoring/virt-monitoring-overview.adoc b/virt/support/monitoring/virt-monitoring-overview.adoc index e6de26deb9..69b836a08c 100644 --- a/virt/support/monitoring/virt-monitoring-overview.adoc +++ b/virt/support/monitoring/virt-monitoring-overview.adoc @@ -9,7 +9,9 @@ toc::[] You can monitor the health of your cluster and virtual machines (VMs) with the following tools: xref:../../../virt/support/monitoring/virt-running-cluster-checkups.adoc#virt-running-cluster-checkups[{product-title} cluster checkup framework]:: -Check network connectivity and latency by using predefined, automated tests. +Run automated tests on your cluster with the {product-title} cluster checkup framework to check the following conditions: +* Network connectivity and latency between two VMs attached to a secondary network interface +* VM running a Data Plane Development Kit (DPDK) workload with zero packet loss :FeatureName: The {product-title} cluster checkup framework include::snippets/technology-preview.adoc[]