You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/virt-about-cluster-checkup-framework.adoc
+3-4Lines changed: 3 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,15 +8,14 @@
8
8
9
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
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.
11
+
By using predefined checkups, cluster administrators and developers 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
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.
13
+
Running a predefined checkup in an existing namespace involves setting up a service account for the checkup, creating the `Role` and `RoleBinding` 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.
14
14
15
15
[IMPORTANT]
16
16
====
17
17
You must always:
18
18
19
19
* Verify that the checkup image is from a trustworthy source before applying it.
20
-
* Review the checkup permissions before creating the `ClusterRole` and `Role` objects.
21
-
* Verify the name of the `ServiceAccount` in the config map. This is because the framework automatically binds these permissions to the checkup instance.
20
+
* Review the checkup permissions before creating the `Role` and `RoleBinding` objects.
= Checking network connectivity and latency for virtual machines on a secondary network
8
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.
9
+
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.
10
10
11
11
To run a checkup for the first time, follow the steps in the procedure.
12
12
@@ -15,87 +15,12 @@ If you have previously run a checkup, skip to step 5 of the procedure because th
15
15
.Prerequisites
16
16
17
17
* You installed the OpenShift CLI (`oc`).
18
-
* You logged in to the cluster as a user with the `cluster-admin` role.
19
18
* The cluster has at least two worker nodes.
20
19
* The Multus Container Network Interface (CNI) plug-in is installed on the cluster.
21
20
* You configured a network attachment definition for a namespace.
22
21
23
22
.Procedure
24
23
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
-
- delete
58
-
- apiGroups: [ "rbac.authorization.k8s.io" ]
59
-
resources:
60
-
- roles
61
-
- rolebindings
62
-
verbs:
63
-
- get
64
-
- list
65
-
- create
66
-
- delete
67
-
- apiGroups: [ "batch" ]
68
-
resources: [ "jobs" ]
69
-
verbs:
70
-
- get
71
-
- list
72
-
- create
73
-
- delete
74
-
- watch
75
-
---
76
-
apiVersion: rbac.authorization.k8s.io/v1
77
-
kind: ClusterRoleBinding
78
-
metadata:
79
-
name: kiagnose
80
-
roleRef:
81
-
apiGroup: rbac.authorization.k8s.io
82
-
kind: ClusterRole
83
-
name: kiagnose
84
-
subjects:
85
-
- kind: ServiceAccount
86
-
name: kiagnose
87
-
namespace: kiagnose
88
-
...
89
-
----
90
-
====
91
-
92
-
. Apply the framework manifest:
93
-
+
94
-
[source,terminal]
95
-
----
96
-
$ oc apply -f <framework_manifest>.yaml
97
-
----
98
-
99
24
. Create a manifest file that contains the `ServiceAccount`, `Role`, and `RoleBinding` objects with permissions that the checkup requires for cluster access:
<1> Specify the namespace where the checkup is to be executed. This must be an existing namespace where the `NetworkAttachmentDefinition` object resides.
<1> `<target_namespace>` is the namespace where the checkup is to be run. This must be an existing namespace where the `NetworkAttachmentDefinition` object resides.
151
94
152
95
. 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.
<1> The namespace where the checkup is to be executed. This must be an existing namespace where the `NetworkAttachmentDefinition` object resides.
174
-
<2> The namespace where the `NetworkAttachmentDefinition` object resides.
175
-
<3> The name of the `NetworkAttachmentDefinition` object.
176
-
<4> Optional: The maximum desired latency, in milliseconds, between the virtual machines. If the measured latency exceeds this value, the checkup fails.
177
-
<5> Optional: The duration of the latency check, in seconds.
178
-
<6> Optional: When specified, latency is measured from this node to the target node. If the source node is specified, the `spec.param.target_node` field cannot be empty.
179
-
<7> Optional: When specified, latency is measured from the source node to this node.
180
-
181
-
. Apply the config map manifest in the framework’s namespace:
<1> The name of the `NetworkAttachmentDefinition` object.
114
+
<2> Optional: The maximum desired latency, in milliseconds, between the virtual machines. If the measured latency exceeds this value, the checkup fails.
115
+
<3> Optional: The duration of the latency check, in seconds.
116
+
<4> Optional: When specified, latency is measured from this node to the target node. If the source node is specified, the `spec.param.target_node` field cannot be empty.
117
+
<5> Optional: When specified, latency is measured from the source node to this node.
118
+
119
+
. Apply the config map manifest in the target namespace:
. Review the results of the latency checkup by running the following command. If the maximum measured latency is greater than the value of the `spec.param.max_desired_latency_milliseconds` attribute, the checkup fails and returns an error.
0 commit comments