支持控制台（Console）开发人员开始试用联系人

14.11. 运行集群检查

OpenShift Virtualization 包括预定义的检查，可用于集群维护和故障排除。

重要

OpenShift Container Platform 集群检查框架只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

14.11.1. 关于 OpenShift Container Platform 集群检查框架

checkup 是一个自动测试工作负载，可让您验证特定的集群功能是否按预期工作。集群检查框架使用原生 Kubernetes 资源来配置和执行检查。

通过使用预定义的检查，集群管理员和开发人员可以提高集群可维护性，排除意外行为，最小化错误并节省时间。还可以检查结果并与专家分享，以进一步进行分析。供应商可以编写和发布它们所提供的功能或服务的检查，并验证其客户环境是否已正确配置。

在现有命名空间中运行预定义的检查涉及为检查设置服务帐户，为服务帐户创建 Role 和 RoleBinding 对象，启用检查权限，以及创建输入配置映射和检查作业。您可以多次运行检查。

重要

您必须始终：

  • 在应用之前，验证检查镜像是否来自可信源。
  • 在创建 Role 和 RoleBinding 对象前，查看检查权限。

14.11.2. 检查二级网络上的虚拟机的网络连接和延迟

您可以使用预定义的检查来验证附加到二级网络接口的两个虚拟机 (VM) 之间的网络连接和测量延迟。

要第一次运行检查，请按照以下步骤执行。

如果您之前已运行检查，请跳至步骤 5 步，因为安装框架的步骤并不需要启用检查权限。

先决条件

  • 已安装 OpenShift CLI（oc）。
  • 集群至少有两个 worker 节点。
  • Multus Container Network Interface (CNI) 插件已安装在集群中。
  • 为命名空间配置了网络附加定义。

流程

  1. 创建一个包含 ServiceAccount、Role 和 RoleBinding 对象的清单文件，其具有检查集群访问权限所需的权限：

    例 14.3. 角色清单文件示例

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vm-latency-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubevirt-vm-latency-checker
rules:
- apiGroups: ["kubevirt.io"]
  resources: ["virtualmachineinstances"]
  verbs: ["get", "create", "delete"]
- apiGroups: ["subresources.kubevirt.io"]
  resources: ["virtualmachineinstances/console"]
  verbs: ["get"]
- apiGroups: ["k8s.cni.cncf.io"]
  resources: ["network-attachment-definitions"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubevirt-vm-latency-checker
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kubevirt-vm-latency-checker
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kiagnose-configmap-access
rules:
- apiGroups: [ "" ]
  resources: [ "configmaps" ]
  verbs: ["get", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kiagnose-configmap-access
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kiagnose-configmap-access
  apiGroup: rbac.authorization.k8s.io

  2. 应用检查角色清单： 

    $ oc apply -n <target_namespace> -f <latency_roles>.yaml 1
    1
    <target_namespace> 是要运行检查的命名空间。这必须是 NetworkAttachmentDefinition 对象所在的现有命名空间。

  3. 创建包含检查的输入参数的 ConfigMap 清单。配置映射提供运行检查的框架输入并存储检查的结果。

    输入配置映射示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
data:
  spec.timeout: 5m
  spec.param.network_attachment_definition_namespace: <target_namespace>
  spec.param.network_attachment_definition_name: "blue-network" 1
  spec.param.max_desired_latency_milliseconds: "10" 2
  spec.param.sample_duration_seconds: "5" 3
  spec.param.source_node: "worker1" 4
  spec.param.target_node: "worker2" 5

    1
    NetworkAttachmentDefinition 对象的名称。
    2
    可选：虚拟机之间所需最大延迟（以毫秒为单位）。如果测量的延迟超过这个值，则检查会失败。
    3
    可选：延迟检查的持续时间，以秒为单位。
    4
    可选：指定时，延迟从此节点测量到目标节点。如果指定了源节点，spec.param.target_node 字段将无法为空。
    5
    可选：指定时，延迟从源节点测量到这个节点。

  4. 应用目标命名空间中的配置映射清单： 

    $ oc apply -n <target_namespace> -f <latency_config_map>.yaml

  5. 创建一个 Job 对象以运行检查：

    任务清单示例

    apiVersion: batch/v1
kind: Job
metadata:
  name: kubevirt-vm-latency-checkup
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccountName: vm-latency-checkup-sa
      restartPolicy: Never
      containers:
        - name: vm-latency-checkup
          image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup:v4.12.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
            runAsNonRoot: true
            seccompProfile:
              type: "RuntimeDefault"
          env:
            - name: CONFIGMAP_NAMESPACE
              value: <target_namespace>
            - name: CONFIGMAP_NAME
              value: kubevirt-vm-latency-checkup-config

  6. 应用 Job 清单。检查程序使用 ping 程序来验证连接和测量延迟。 

    $ oc apply -n <target_namespace> -f <latency_job>.yaml

  7. 等待作业完成： 

    $ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m

  8. 运行以下命令，检查延迟检查的结果。如果测量的最大延迟大于 spec.param.max_desired_latency_milliseconds 属性的值，则检查将失败并返回错误。 

    $ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml

    输出配置映射（成功）示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
  namespace: <target_namespace>
data:
  spec.timeout: 5m
  spec.param.network_attachment_definition_namespace: <target_namespace>
  spec.param.network_attachment_definition_name: "blue-network"
  spec.param.max_desired_latency_milliseconds: "10"
  spec.param.sample_duration_seconds: "5"
  spec.param.source_node: "worker1"
  spec.param.target_node: "worker2"
  status.succeeded: "true"
  status.failureReason: ""
  status.completionTimestamp: "2022-01-01T09:00:00Z"
  status.startTimestamp: "2022-01-01T09:00:07Z"
  status.result.avgLatencyNanoSec: "177000"
  status.result.maxLatencyNanoSec: "244000" 1
  status.result.measurementDurationSec: "5"
  status.result.minLatencyNanoSec: "135000"
  status.result.sourceNode: "worker1"
  status.result.targetNode: "worker2"

    1
    以纳秒为单位的最大测量延迟。

  9. 可选： 要在检查失败时查看详细作业日志，请使用以下命令： 

    $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>

  10. 运行以下命令删除之前创建的作业和配置映射资源： 

    $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
    $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config

  11. 可选：如果您不计划运行另一个检查，请删除检查角色和框架清单文件。 

    $ oc delete -f <file_name>.yaml

14.11.3. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.