지원콘솔개발자평가판 시작연락처

14.11. 클러스터 검사 실행

OpenShift Virtualization에는 클러스터 유지 관리 및 문제 해결에 사용할 수 있는 사전 정의된 점검이 포함되어 있습니다.

중요

OpenShift Container Platform 클러스터 검사 프레임워크는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

14.11.1. OpenShift Container Platform 클러스터 검사 프레임워크 정보

점검 은 특정 클러스터 기능이 예상대로 작동하는지 확인할 수 있는 자동화된 테스트 워크로드입니다. 클러스터 점검 프레임워크는 네이티브 Kubernetes 리소스를 사용하여 검사를 구성하고 실행합니다.

클러스터 관리자와 개발자는 사전 정의된 점검을 사용하여 클러스터 유지 관리를 개선하고, 예기치 않은 동작을 해결하고, 오류를 최소화하며, 시간을 절약할 수 있습니다. 또한 수표의 결과를 검토하고 추가 분석을 위해 전문가와 공유할 수 있습니다. 벤더는 제공하는 기능 또는 서비스에 대한 점검 확인을 작성하고 게시하여 고객 환경이 올바르게 구성되었는지 확인할 수 있습니다.

기존 네임스페이스에서 사전 정의된 점검을 실행하려면 점검에 대한 서비스 계정을 설정하고, 서비스 계정에 대한 Role 및 RoleBinding 오브젝트를 생성하며, 검사에 대한 권한을 활성화하며, 입력 구성 맵 및 검사 작업을 생성해야 합니다. 검사를 여러 번 실행할 수 있습니다.

중요

항상 다음을 수행해야 합니다.

  • 이미지를 적용하기 전에 이미지 점검 소스의 출처가 있는지 확인합니다.
  • Role 및 RoleBinding 오브젝트를 생성하기 전에 점검 권한을 검토합니다.

14.11.2. 보조 네트워크에서 가상 머신의 네트워크 연결 및 대기 시간 확인

사전 정의된 점검을 사용하여 네트워크 연결을 확인하고 보조 네트워크 인터페이스에 연결된 두 가상 머신(VM) 간의 대기 시간을 측정합니다.

처음으로 검사를 실행하려면 절차의 단계를 따르십시오.

이전에 검사를 실행한 경우 프레임워크를 설치하고 점검에 대한 권한을 활성화하는 단계가 필요하기 때문에 5단계의 절차로 건너뜁니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에는 두 개 이상의 작업자 노드가 있습니다.
  • Multus CNI(Container Network Interface) 플러그인이 클러스터에 설치되어 있습니다.
  • 네임스페이스에 대한 네트워크 연결 정의를 구성하셨습니다.

절차

  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. 작업 매니페스트를 적용합니다. 점검에서는 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

    출력 구성 맵(success)의 예

    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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.