검색

7.5. 네트워크 문제 해결

download PDF

7.5.1. 네트워크 인터페이스 선택 방법

베어 메탈 또는 둘 이상의 NIC(네트워크 인터페이스 컨트롤러)가 있는 가상 머신에 설치할 경우 OpenShift Container Platform이 Kubernetes API 서버와의 통신에 사용하는 NIC는 노드가 부팅될 때 systemd에서 실행하는 nodeip-configuration.service 서비스 유닛에 의해 결정됩니다. nodeip-configuration.service 는 기본 경로와 연결된 인터페이스에서 IP를 선택합니다.

nodeip-configuration.service 서비스에서 올바른 NIC를 확인한 후 서비스는 /etc/systemd/system/kubelet.service.d/20-nodenet.conf 파일을 만듭니다. 20-nodenet.conf 파일은 KUBELET_NODE_IP 환경 변수를 서비스가 선택한 IP 주소로 설정합니다.

kubelet 서비스가 시작되면 20-nodenet.conf 파일에서 환경 변수 값을 읽고 IP 주소를 --node-ip kubelet 명령줄 인수 값으로 설정합니다. 결과적으로 kubelet 서비스는 선택한 IP 주소를 노드 IP 주소로 사용합니다.

설치 후 하드웨어 또는 네트워킹을 재구성하거나 노드 IP가 기본 라우팅 인터페이스에서 제공되지 않는 네트워킹 레이아웃이 있는 경우 재부팅 후 nodeip-configuration.service 서비스에서 다른 NIC를 선택할 수 있습니다. 경우에 따라 oc get nodes -o wide 명령의 출력에서 INTERNAL-IP 열을 검토하여 다른 NIC가 선택되었는지 감지할 수 있습니다.

다른 NIC가 선택되어 네트워크 통신이 중단되거나 잘못 구성된 경우 EtcdCertSignerControllerDegraded 오류가 표시될 수 있습니다. NODEIP_HINT 변수를 포함하는 힌트 파일을 생성하여 기본 IP 선택 논리를 덮어쓸 수 있습니다. 자세한 내용은 선택 사항: 기본 노드 IP 선택 논리를 참조하십시오.

7.5.1.1. 선택 사항: 기본 노드 IP 선택 논리를 덮어 쓰기

기본 IP 선택 논리를 재정의하려면 NODEIP_HINT 변수를 포함하는 힌트 파일을 생성하여 기본 IP 선택 논리를 재정의할 수 있습니다. 힌트 파일을 만들면 NODEIP_HINT 변수에 지정된 IP 주소 서브넷의 인터페이스에서 특정 노드 IP 주소를 선택할 수 있습니다.

예를 들어 노드에 주소가 10.0.0.10/24eth0 과 주소가 192.0.2.5/24eth1 이 있고 기본 경로는 eth0 (10.0.0.10)을 가리킵니다. 노드 IP 주소는 일반적으로 10.0.0.10 IP 주소를 사용합니다.

사용자는 서브넷의 알려진 IP를 가리키도록 NODEIP_HINT 변수를 구성할 수 있습니다(예: 192.0.2.1 과 같은 서브넷 게이트웨이) 다른 서브넷 192.0.2.0/24 가 선택되도록 합니다. 따라서 eth1192.0.2.5 IP 주소가 노드에 사용됩니다.

다음 절차에서는 기본 노드 IP 선택 논리를 재정의하는 방법을 보여줍니다.

프로세스

  1. 힌트 파일을 /etc/default/nodeip-configuration 파일에 추가합니다. 예를 들면 다음과 같습니다.

    NODEIP_HINT=192.0.2.1
    중요
    • 노드의 정확한 IP 주소를 힌트로 사용하지 마십시오(예: 192.0.2.5). 노드의 정확한 IP 주소를 사용하면 노드가 힌트 IP 주소를 사용하는 경우 올바르게 구성되지 않습니다.
    • 힌트 파일의 IP 주소는 올바른 서브넷을 결정하는 데만 사용됩니다. 힌트 파일에 나타나는 결과로 트래픽을 수신하지 않습니다.
  2. 다음 명령을 실행하여 base-64 로 인코딩된 콘텐츠를 생성합니다.

    $ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0

    출력 예

    Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==

  3. 클러스터를 배포하기 전에 masterworker 역할에 대한 머신 구성 매니페스트를 생성하여 힌트를 활성화합니다.

    99-nodeip-hint-master.yaml

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-nodeip-hint-master
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<encoded_content> 1
            mode: 0644
            overwrite: true
            path: /etc/default/nodeip-configuration

    1
    <encoded_contents>/etc/default/nodeip-configuration 파일의 base64 인코딩 콘텐츠(예: Tk9ERUlQX0hJTlQ9MTkyLjAuMC=== ) 로 바꿉니다. 쉼표 이후와 인코딩된 콘텐츠 전에는 공백을 사용할 수 없습니다.

    99-nodeip-hint-worker.yaml

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
       name: 99-nodeip-hint-worker
    spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,<encoded_content> 1
           mode: 0644
           overwrite: true
           path: /etc/default/nodeip-configuration

    1
    <encoded_contents>/etc/default/nodeip-configuration 파일의 base64 인코딩 콘텐츠(예: Tk9ERUlQX0hJTlQ9MTkyLjAuMC=== ) 로 바꿉니다. 쉼표 이후와 인코딩된 콘텐츠 전에는 공백을 사용할 수 없습니다.
  4. 클러스터 구성을 저장하는 디렉터리에 매니페스트를 저장합니다(예: ~/clusterconfigs ).
  5. 클러스터를 배포합니다.

7.5.1.2. 보조 OVS 브리지를 사용하도록 OVN-Kubernetes 구성

OVN-Kubernetes는 OpenShift Container Platform 노드의 외부 게이트웨이를 정의하는 데 사용하는 추가 또는 보조 Open vSwitch(OVS) 브리지 br-ex1 을 생성하고 여러 외부 게이트웨이(MEG) 구현을 생성할 수 있습니다. AdminPolicyBasedExternalRoute CR(사용자 정의 리소스)에서 MEG를 정의할 수 있습니다. MEG 구현에서는 Pod에 여러 게이트웨이, ECMP( equal-cost multipath) 경로 및 BFD( Bidirectional Forwarding Detection) 구현에 액세스할 수 있습니다.

여러 외부 게이트웨이(MEG) 기능의 영향을 받는 Pod의 사용 사례를 고려하고 노드에서 다른 인터페이스(예: br-ex1 )로 트래픽을 송신하려는 경우를 고려하십시오. MEG의 영향을 받지 않는 Pod의 송신 트래픽은 기본 OVS br-ex 브리지로 라우팅됩니다.

중요

현재 MEG는 송신 IP, 송신 방화벽 또는 송신 라우터와 같은 다른 송신 기능과 함께 사용할 수 없습니다. 송신 IP와 같은 송신 기능과 함께 MEG를 사용하면 라우팅 및 트래픽 흐름 충돌이 발생할 수 있습니다. 이는 OVN-Kubernetes가 라우팅 및 소스 네트워크 주소 변환(SNAT)을 처리하는 방식 때문에 발생합니다. 이로 인해 라우팅이 일관되지 않으며 반환 경로가 들어오는 경로를 패치해야 하는 일부 환경에서 연결이 중단될 수 있습니다.

머신 구성 매니페스트 파일의 인터페이스 정의에 추가 브릿지를 정의해야 합니다. Machine Config Operator는 매니페스트를 사용하여 호스트의 /etc/ovnk/extra_bridge 에 새 파일을 생성합니다. 새 파일에는 추가 OVS 브리지가 노드에 대해 구성하는 네트워크 인터페이스의 이름이 포함되어 있습니다.

매니페스트 파일을 생성하고 편집한 후 Machine Config Operator가 다음 순서로 작업을 완료합니다.

  1. 선택한 머신 구성 풀에 따라 노드를 단일 순서로 드레이닝합니다.
  2. 각 노드가 추가 br-ex1 브리지 네트워크 구성을 수신하도록 Ignition 구성 파일을 각 노드에 삽입합니다.
  3. br-ex MAC 주소가 br-ex 가 네트워크 연결에 사용하는 인터페이스의 MAC 주소와 일치하는지 확인합니다.
  4. 새 인터페이스 정의를 참조하는 configure-ovs.sh 쉘 스크립트를 실행합니다.
  5. br-exbr-ex1 을 호스트 노드에 추가합니다.
  6. 노드를 분리합니다.
참고

모든 노드가 Ready 상태로 돌아가고 OVN-Kubernetes Operator가 br-ex 및 br-ex 1 을 감지하고 구성한 후 Operator는 k8s.ovn.org/l3-gateway-config 주석을 각 노드에 적용합니다.

추가 br-ex1 브리지 및 항상 기본 br-ex 브리지가 필요한 상황에 대한 자세한 내용은 "Localnet 토폴로지에 대한 구성"을 참조하십시오.

프로세스

  1. 선택 사항: 추가 브릿지 br-ex1 에서 다음 단계를 완료하여 사용할 수 있는 인터페이스 연결을 생성합니다. 예제 단계에서는 모두 머신 구성 매니페스트 파일에 정의된 새 본딩 및 해당 종속 인터페이스를 생성하는 방법을 보여줍니다. 추가 브릿지는 MachineConfig 오브젝트를 사용하여 추가 본딩 인터페이스를 형성합니다.

    중요

    추가 인터페이스를 정의하기 위해 Kubernetes NMState Operator를 사용하거나 NodeNetworkConfigurationPolicy (NNCP) 매니페스트 파일을 정의하지 마십시오.

    또한 본딩 인터페이스를 정의할 때 기존 br-ex OVN Kubernetes 네트워크 배포에서 추가 인터페이스 또는 하위 인터페이스를 사용하지 않는지 확인합니다.

    1. 다음 인터페이스 정의 파일을 생성합니다. 호스트 노드가 정의 파일에 액세스할 수 있도록 이러한 파일이 머신 구성 매니페스트 파일에 추가됩니다.

      eno1.config라는 첫 번째 인터페이스 정의 파일의 예

      [connection]
      id=eno1
      type=ethernet
      interface-name=eno1
      master=bond1
      slave-type=bond
      autoconnect=true
      autoconnect-priority=20

      eno2.config라는 두 번째 인터페이스 정의 파일의 예

      [connection]
      id=eno2
      type=ethernet
      interface-name=eno2
      master=bond1
      slave-type=bond
      autoconnect=true
      autoconnect-priority=20

      bond1.config라는 두 번째 본딩 인터페이스 정의 파일의 예

      [connection]
      id=bond1
      type=bond
      interface-name=bond1
      autoconnect=true
      connection.autoconnect-slaves=1
      autoconnect-priority=20
      
      [bond]
      mode=802.3ad
      miimon=100
      xmit_hash_policy="layer3+4"
      
      [ipv4]
      method=auto

    2. 다음 명령을 실행하여 정의 파일을 Base64 인코딩 문자열로 변환합니다.

      $ base64 <directory_path>/en01.config
      $ base64 <directory_path>/eno2.config
      $ base64 <directory_path>/bond1.config
  2. 환경 변수를 준비합니다. < machine_role >을 worker 와 같은 노드 역할로 바꾸고 < interface_name >을 추가 br-ex 브리지 이름의 이름으로 바꿉니다.

    $ export ROLE=<machine_role>
  3. 머신 구성 매니페스트 파일에 각 인터페이스 정의를 정의합니다.

    bond1,eno1en02에 대한 정의가 추가된 머신 구성 파일의 예

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: ${worker}
      name: 12-${ROLE}-sec-bridge-cni
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:;base64,<base-64-encoded-contents-for-bond1.conf>
            path: /etc/NetworkManager/system-connections/bond1.nmconnection
            filesystem: root
            mode: 0600
          - contents:
              source: data:;base64,<base-64-encoded-contents-for-eno1.conf>
            path: /etc/NetworkManager/system-connections/eno1.nmconnection
            filesystem: root
            mode: 0600
          - contents:
              source: data:;base64,<base-64-encoded-contents-for-eno2.conf>
            path: /etc/NetworkManager/system-connections/eno2.nmconnection
            filesystem: root
            mode: 0600
    # ...

  4. 터미널에 다음 명령을 입력하여 네트워크 플러그인을 구성하기 위한 머신 구성 매니페스트 파일을 생성합니다.

    $ oc create -f <machine_config_file_name>
  5. OVN-Kubernetes 네트워크 플러그인을 사용하여 extra_bridge 파일 을 생성하여 노드에 OVS(Open vSwitch) 브리지 br-ex1 을 만듭니다. 파일을 호스트의 /etc/ovnk/extra_bridge 경로에 저장해야 합니다. 파일에는 노드의 기본 IP 주소가 있는 br-ex 를 지원하는 기본 인터페이스가 아닌 추가 브릿지를 지원하는 인터페이스 이름을 지정해야 합니다.

    추가 인터페이스를 참조하는 extra_bridge 파일 /etc/ovnk/extra_bridge 에 대한 설정 예

    bond1

  6. 클러스터에서 재시작한 모든 노드에서 br-ex1 을 호스팅하는 기존 정적 인터페이스를 정의하는 머신 구성 매니페스트 파일을 생성합니다.

    br-ex1호스팅 인터페이스로 bond1 을 정의하는 머신 구성 파일의 예

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: ${worker}
      name: 12-worker-extra-bridge
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/ovnk/extra_bridge
              mode: 0420
              overwrite: true
              contents:
                source: data:text/plain;charset=utf-8,bond1
              filesystem: root

  7. 선택한 노드에 머신 구성을 적용합니다.

    $ oc create -f <machine_config_file_name>
  8. 선택 사항: /var/lib/ovnk/iface_default_hint 리소스를 생성하는 머신 구성 파일을 생성하여 노드의 br-ex 선택 논리를 덮어쓸 수 있습니다.

    참고

    리소스에는 br-ex 가 클러스터에 대해 선택하는 인터페이스의 이름이 나열됩니다. 기본적으로 br-ex 는 시스템 네트워크의 부팅 순서 및 IP 주소 서브넷을 기반으로 노드의 기본 인터페이스를 선택합니다. 특정 머신 네트워크 구성을 사용하려면 br-ex 가 호스트 노드의 기본 인터페이스 또는 본딩을 계속 선택해야 할 수 있습니다.

    1. 호스트 노드에 머신 구성 파일을 생성하여 기본 인터페이스를 재정의합니다.

      중요

      br-ex 선택 논리를 변경하기 위해 이 머신 구성 파일만 생성합니다. 이 파일을 사용하여 클러스터에 있는 기존 노드의 IP 주소를 변경하는 것은 지원되지 않습니다.

      기본 인터페이스를 재정의하는 머신 구성 파일의 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: ${worker}
        name: 12-worker-br-ex-override
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            files:
              - path: /var/lib/ovnk/iface_default_hint
                mode: 0420
                overwrite: true
                contents:
                  source: data:text/plain;charset=utf-8,bond0 1
                filesystem: root

      1
      머신 구성 파일을 노드에 적용하기 전에 bond0 이 노드에 있는지 확인합니다.
    2. 클러스터의 모든 새 노드에 구성을 적용하기 전에 호스트 노드를 재부팅하여 br-ex 가 의도한 인터페이스를 선택하고 br-ex1 에 정의된 새 인터페이스와 충돌하지 않는지 확인합니다.
    3. 클러스터의 모든 새 노드에 머신 구성 파일을 적용합니다.

      $ oc create -f <machine_config_file_name>

검증

  1. 클러스터에서 exgw-ip-addresses 라벨을 사용하여 노드의 IP 주소를 확인하여 노드가 기본 브리지 대신 추가 브릿지를 사용하는지 확인합니다.

    $ oc get nodes -o json | grep --color exgw-ip-addresses

    출력 예

    "k8s.ovn.org/l3-gateway-config":
       \"exgw-ip-address\":\"172.xx.xx.yy/24\",\"next-hops\":[\"xx.xx.xx.xx\"],

  2. 호스트 노드에서 네트워크 인터페이스 이름을 검토하여 대상 노드에 추가 브릿지가 있는지 확인합니다.

    $ oc debug node/<node_name> -- chroot /host sh -c "ip a | grep mtu | grep br-ex"

    출력 예

    Starting pod/worker-1-debug ...
    To use host binaries, run `chroot /host`
    # ...
    5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    6: br-ex1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000

  3. 선택 사항: /var/lib/ovnk/iface_default_hint 를 사용하는 경우 br-ex 의 MAC 주소가 선택한 기본 인터페이스의 MAC 주소와 일치하는지 확인합니다.

    $ oc debug node/<node_name> -- chroot /host sh -c "ip a | grep -A1 -E 'br-ex|bond0'

    br-ex 의 기본 인터페이스를 bond0으로 표시하는 출력 예

    Starting pod/worker-1-debug ...
    To use host binaries, run `chroot /host`
    # ...
    sh-5.1# ip a | grep -A1 -E 'br-ex|bond0'
    2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
        link/ether fa:16:3e:47:99:98 brd ff:ff:ff:ff:ff:ff
    --
    5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
        link/ether fa:16:3e:47:99:98 brd ff:ff:ff:ff:ff:ff
        inet 10.xx.xx.xx/21 brd 10.xx.xx.255 scope global dynamic noprefixroute br-ex

7.5.2. Open vSwitch 문제 해결

일부 OVS(Open vSwitch) 문제를 해결하려면 자세한 정보를 포함하도록 로그 수준을 구성해야 할 수 있습니다.

노드에서 로그 수준을 일시적으로 수정하는 경우 다음 예와 같이 노드의 머신 구성 데몬에서 로그 메시지를 받을 수 있습니다.

E0514 12:47:17.998892    2281 daemon.go:1350] content mismatch for file /etc/systemd/system/ovs-vswitchd.service: [Unit]

불일치와 관련된 로그 메시지를 방지하려면 문제 해결을 완료한 후 로그 수준 변경 사항을 되돌립니다.

7.5.2.1. 일시적으로 Open vSwitch 로그 수준 구성

단기 문제 해결을 위해 OVS(Open vSwitch) 로그 수준을 일시적으로 구성할 수 있습니다. 다음 절차에 따라 노드를 재부팅할 필요가 없습니다. 또한 노드를 재부팅할 때 마다 구성 변경 사항이 유지되지 않습니다.

이 절차를 수행하여 로그 수준을 변경하면 ovs-vswitchd.service에 대한 콘텐츠 불일치가 있음을 나타내는 머신 구성 데몬에서 로그 메시지를 수신할 수 있습니다. 로그 메시지를 방지하려면 이 절차를 반복하고 로그 수준을 원래 값으로 설정합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 노드의 디버그 Pod를 시작합니다.

    $ oc debug node/<node_name>
  2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 root 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트 파일 시스템에서 바이너리를 실행할 수 있습니다.

    # chroot /host
  3. OVS 모듈의 현재 syslog 수준을 확인합니다.

    # ovs-appctl vlog/list

    다음 예제 출력은 info로 설정된 syslog의 로그 수준을 보여줍니다.

    출력 예

                     console    syslog    file
                     -------    ------    ------
    backtrace          OFF       INFO       INFO
    bfd                OFF       INFO       INFO
    bond               OFF       INFO       INFO
    bridge             OFF       INFO       INFO
    bundle             OFF       INFO       INFO
    bundles            OFF       INFO       INFO
    cfm                OFF       INFO       INFO
    collectors         OFF       INFO       INFO
    command_line       OFF       INFO       INFO
    connmgr            OFF       INFO       INFO
    conntrack          OFF       INFO       INFO
    conntrack_tp       OFF       INFO       INFO
    coverage           OFF       INFO       INFO
    ct_dpif            OFF       INFO       INFO
    daemon             OFF       INFO       INFO
    daemon_unix        OFF       INFO       INFO
    dns_resolve        OFF       INFO       INFO
    dpdk               OFF       INFO       INFO
    ...

  4. /etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf 파일에서 로그 수준을 지정합니다.

    Restart=always
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /var/lib/openvswitch'
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /etc/openvswitch'
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /run/openvswitch'
    ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg
    ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg

    이전 예에서 로그 수준은 dbg로 설정됩니다. syslog:<log_level>off,emer,err,warn,info 또는 dbg로 설정하여 마지막 두 행을 변경합니다. off 로그 수준은 모든 로그 메시지를 필터링합니다.

  5. 서비스를 다시 시작하십시오.

    # systemctl daemon-reload
    # systemctl restart ovs-vswitchd

7.5.2.2. 영구적으로 Open vSwitch 로그 수준 구성

OVS(Open vSwitch) 로그 수준을 장기적으로 변경할 경우 로그 수준을 영구적으로 변경할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 다음 예제와 같은 MachineConfig 오브젝트를 사용하여 99-change-ovs-loglevel.yaml과 같은 파일을 생성합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master  1
      name: 99-change-ovs-loglevel
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - dropins:
            - contents: |
                [Service]
                  ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg  2
                  ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg
              name: 20-ovs-vswitchd-restart.conf
            name: ovs-vswitchd.service
    1
    이 절차를 수행하여 컨트롤 플레인 노드를 구성한 후 절차를 반복하고 역할을 worker로 설정하여 작업자 노드를 구성합니다.
    2
    syslog:<log_level> 값을 설정합니다. 로그 수준은 off,emer,err,warn,info 또는 dbg 입니다. 값을 off로 설정하면 모든 로그 메시지가 필터링됩니다.
  2. 머신 구성을 적용합니다.

    $ oc apply -f 99-change-ovs-loglevel.yaml

7.5.2.3. Open vSwitch 로그 표시

다음 절차에 따라 OVS(Open vSwitch) 로그를 표시합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  • 다음 명령 중 하나를 실행합니다.

    • 클러스터 외부에서 oc 명령을 사용하여 로그를 표시합니다.

      $ oc adm node-logs <node_name> -u ovs-vswitchd
    • 클러스터의 노드에 로그인한 후 로그를 표시합니다.

      # journalctl -b -f -u ovs-vswitchd.service

      노드에 로그인하는 한 가지 방법은 oc debug node/<node_name> 명령을 사용하는 것입니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.