Skip to content

Commit 9cacce4

Browse files
author
Shikha Jhala
committed
CNV-17454: Network latency checkup
1 parent 1a0b9d2 commit 9cacce4

File tree

4 files changed

+293
-0
lines changed

4 files changed

+293
-0
lines changed

‎_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3358,6 +3358,8 @@ Topics:
33583358
File: virt-reviewing-vm-dashboard
33593359
- Name: OpenShift cluster monitoring, logging, and Telemetry
33603360
File: virt-openshift-cluster-monitoring
3361+
- Name: Running OpenShift cluster checkups
3362+
File: virt-running-cluster-checkups
33613363
- Name: Prometheus queries for virtual resources
33623364
File: virt-prometheus-queries
33633365
- Name: Exposing custom metrics for virtual machines

‎modules/virt-about-cluster-checkup-framework.adoc

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/logging_events_monitoring/virt-running-cluster-checkups.adoc
4+
5+
:_content-type: CONCEPT
6+
[id="virt-about-cluster-checkup-framework_{context}"]
7+
= About the {product-title} cluster checkup framework
8+
9+
A _checkup_ is an automated test workload that allows you to verify if a specific cluster functionality works as expected. The cluster checkup framework uses native Kubernetes resources to configure and execute the checkup.
10+
11+
By using predefined checkups, cluster administrators can improve cluster maintainability, troubleshoot unexpected behavior, minimize errors, and save time. They can also review the results of the checkup and share them with experts for further analysis. Vendors can write and publish checkups for features or services that they provide and verify that their customer environments are configured correctly.
12+
13+
Running a predefined checkup in the cluster involves setting up the namespace and service account for the framework, creating the `ClusterRole` and `ClusterRoleBinding` objects for the service account, enabling permissions for the checkup, and creating the input config map and the checkup job. You can run a checkup multiple times.

‎modules/virt-measuring-latency-vm-secondary-network.adoc

Lines changed: 256 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,256 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/logging_events_monitoring/virt-running-cluster-checkups.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="virt-measuring-latency-vm-secondary-network_{context}"]
7+
= Checking network connectivity and latency for virtual machines on a secondary network
8+
9+
As a cluster administrator, you use a predefined checkup to verify network connectivity and measure latency between virtual machines (VMs) that are attached to a secondary network interface.
10+
11+
To run a checkup for the first time, follow the steps in the procedure.
12+
13+
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.
14+
15+
.Prerequisites
16+
17+
* You installed the OpenShift CLI (`oc`).
18+
* You logged in to the cluster as a user with the `cluster-admin` role.
19+
* The cluster has at least two worker nodes.
20+
* The Multus Container Network Interface (CNI) plug-in is installed on the cluster.
21+
* You configured a network attachment definition for a namespace.
22+
23+
.Procedure
24+
25+
. Create a configuration file that contains the resources to set up the framework. This includes a namespace and service account for the framework, and the `ClusterRole` and `ClusterRoleBinding` objects to define permissions for the service account.
26+
+
27+
.Example framework manifest file
28+
[%collapsible]
29+
====
30+
[source,yaml]
31+
----
32+
---
33+
apiVersion: v1
34+
kind: Namespace
35+
metadata:
36+
name: kiagnose
37+
---
38+
apiVersion: v1
39+
kind: ServiceAccount
40+
metadata:
41+
name: kiagnose
42+
namespace: kiagnose
43+
---
44+
apiVersion: rbac.authorization.k8s.io/v1
45+
kind: ClusterRole
46+
metadata:
47+
name: kiagnose
48+
rules:
49+
- apiGroups: [ "" ]
50+
resources: [ "configmaps" ]
51+
verbs:
52+
- get
53+
- list
54+
- create
55+
- update
56+
- patch
57+
- apiGroups: [ "" ]
58+
resources: [ "namespaces" ]
59+
verbs:
60+
- get
61+
- list
62+
- create
63+
- delete
64+
- watch
65+
- apiGroups: [ "" ]
66+
resources: [ "serviceaccounts" ]
67+
verbs:
68+
- get
69+
- list
70+
- create
71+
- apiGroups: [ "rbac.authorization.k8s.io" ]
72+
resources:
73+
- roles
74+
- rolebindings
75+
- clusterrolebindings
76+
verbs:
77+
- get
78+
- list
79+
- create
80+
- delete
81+
- apiGroups: [ "rbac.authorization.k8s.io" ]
82+
resources:
83+
- clusterroles
84+
verbs:
85+
- get
86+
- list
87+
- create
88+
- bind
89+
- apiGroups: [ "batch" ]
90+
resources: [ "jobs" ]
91+
verbs:
92+
- get
93+
- list
94+
- create
95+
- delete
96+
- watch
97+
---
98+
apiVersion: rbac.authorization.k8s.io/v1
99+
kind: ClusterRoleBinding
100+
metadata:
101+
name: kiagnose
102+
roleRef:
103+
apiGroup: rbac.authorization.k8s.io
104+
kind: ClusterRole
105+
name: kiagnose
106+
subjects:
107+
- kind: ServiceAccount
108+
name: kiagnose
109+
namespace: kiagnose
110+
...
111+
----
112+
====
113+
114+
. Apply the framework manifest:
115+
+
116+
[source,terminal]
117+
----
118+
$ oc apply -f <framework_manifest>.yaml
119+
----
120+
121+
. Create a configuration file that contains the `ClusterRole` and `Role` objects with permissions that the checkup requires for cluster access:
122+
+
123+
.Example cluster role manifest file
124+
[source,yaml]
125+
----
126+
apiVersion: rbac.authorization.k8s.io/v1
127+
kind: ClusterRole
128+
metadata:
129+
name: kubevirt-vm-latency-checker
130+
rules:
131+
- apiGroups: ["kubevirt.io"]
132+
resources: ["virtualmachineinstances"]
133+
verbs: ["get", "create", "delete"]
134+
- apiGroups: ["subresources.kubevirt.io"]
135+
resources: ["virtualmachineinstances/console"]
136+
verbs: ["get"]
137+
- apiGroups: ["k8s.cni.cncf.io"]
138+
resources: ["network-attachment-definitions"]
139+
verbs: ["get"]
140+
----
141+
142+
. Apply the checkup roles manifest:
143+
+
144+
[source,terminal]
145+
----
146+
$ oc apply -f <latency_roles>.yaml
147+
----
148+
149+
. 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.
150+
+
151+
.Example input config map
152+
[source,yaml]
153+
----
154+
apiVersion: v1
155+
kind: ConfigMap
156+
metadata:
157+
name: kubevirt-vm-latency-checkup
158+
namespace: kiagnose
159+
data:
160+
spec.image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup:v4.11.0
161+
spec.timeout: 10m
162+
spec.clusterRoles: |
163+
kubevirt-vmis-manager
164+
spec.param.network_attachment_definition_namespace: "default" <1>
165+
spec.param.network_attachment_definition_name: "bridge-network" <2>
166+
spec.param.max_desired_latency_milliseconds: "10" <3>
167+
spec.param.sample_duration_seconds: "5" <4>
168+
----
169+
<1> The namespace where the `NetworkAttachmentDefinition` object resides.
170+
<2> The name of the `NetworkAttachmentDefinition` object.
171+
<3> Optional: The maximum desired latency, in milliseconds, between the virtual machines. If the measured latency exceeds this value, the check fails.
172+
<4> Optional: The duration of the latency check, in seconds.
173+
174+
. Create the config map in the framework’s namespace:
175+
+
176+
[source,terminal]
177+
----
178+
$ oc apply -f <latency_config_map>.yaml
179+
----
180+
181+
. Create a `Job` object to run the checkup:
182+
+
183+
.Example job manifest
184+
[source,yaml]
185+
----
186+
apiVersion: batch/v1
187+
kind: Job
188+
metadata:
189+
name: kubevirt-vm-latency-checkup
190+
namespace: kiagnose
191+
spec:
192+
backoffLimit: 0
193+
template:
194+
spec:
195+
serviceAccount: kiagnose
196+
restartPolicy: Never
197+
containers:
198+
- name: framework
199+
image: registry.redhat.io/container-native-virtualization/checkup-framework:v4.11.0
200+
env:
201+
- name: CONFIGMAP_NAMESPACE
202+
value: kiagnose
203+
- name: CONFIGMAP_NAME
204+
value: kubevirt-vm-latency-checkup
205+
----
206+
207+
. Apply the `Job` manifest. The checkup uses the ping utility to verify connectivity and measure latency.
208+
+
209+
[source,terminal]
210+
----
211+
$ oc apply -f <latency_job>.yaml
212+
----
213+
214+
. Wait for the job to complete:
215+
+
216+
[source,terminal]
217+
----
218+
$ oc wait --for=condition=complete --timeout=10m job.batch/kubevirt-vm-latency-checkup -n kiagnose
219+
----
220+
221+
. Review the results of the latency checkup by retrieving the status of the `ConfigMap` object. If the measured latency is greater than the value of the `spec.param.max_desired_latency_milliseconds` attribute, the checkup fails and returns an error.
222+
+
223+
[source,terminal]
224+
----
225+
$ oc get configmap kubevirt-vm-latency-checkup -n kiagnose -o yaml
226+
----
227+
+
228+
.Example output config map (success)
229+
[source,yaml]
230+
----
231+
apiVersion: v1
232+
kind: ConfigMap
233+
metadata:
234+
name: kubevirt-vm-latency-checkup
235+
namespace: kiagnose
236+
...
237+
status.succeeded: "true"
238+
status.failureReason: ""
239+
status.result.minLatencyNanoSec: 2000
240+
status.result.maxLatencyNanoSec: 3000
241+
status.result.avgLatencyNanoSec: 2500
242+
status.results.measurementDurationSec: 300
243+
...
244+
----
245+
246+
. Delete the framework and checkup resources that you previously created. This includes the job, config map, cluster role, and framework manifest files.
247+
+
248+
[NOTE]
249+
====
250+
Do not delete the framework and cluster role manifest files if you plan to run another checkup.
251+
====
252+
+
253+
[source,terminal]
254+
----
255+
$ oc delete -f <file_name>.yaml
256+
----

‎virt/logging_events_monitoring/virt-running-cluster-checkups.adoc

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
:_content-type: ASSEMBLY
2+
[id="virt-running-cluster-checkups"]
3+
= Running cluster checkups
4+
include::_attributes/common-attributes.adoc[]
5+
:context: virt-running-cluster-checkups
6+
7+
toc::[]
8+
9+
{VirtProductName} {VirtVersion} includes a diagnostic framework to run predefined checkups that can be used for cluster maintenance and troubleshooting.
10+
11+
:FeatureName: The {product-title} cluster checkup framework
12+
include::snippets/technology-preview.adoc[]
13+
14+
15+
include::modules/virt-about-cluster-checkup-framework.adoc[leveloffset=+1]
16+
17+
include::modules/virt-measuring-latency-vm-secondary-network.adoc[leveloffset=+1]
18+
19+
[role="_additional-resources"]
20+
[id="additional-resources_running-cluster-checkups"]
21+
== Additional resources
22+
* xref:../../virt/virtual_machines/vm_networking/virt-attaching-vm-multiple-networks.adoc#virt-attaching-vm-multiple-networks[Attaching a virtual machine to multiple networks]

0 commit comments

Comments
 (0)