7.5. 네트워크 문제 해결
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/24 인 eth0 과 주소가 192.0.2.5/24 인 eth1 이 있고 기본 경로는 eth0 (10.0.0.10)을 가리킵니다. 노드 IP 주소는 일반적으로 10.0.0.10 IP 주소를 사용합니다.
사용자는 서브넷의 알려진 IP를 가리키도록 NODEIP_HINT 변수를 구성할 수 있습니다(예: 192.0.2.1 과 같은 서브넷 게이트웨이) 다른 서브넷 192.0.2.0/24 가 선택되도록 합니다. 따라서 eth1 의 192.0.2.5 IP 주소가 노드에 사용됩니다.
다음 절차에서는 기본 노드 IP 선택 논리를 재정의하는 방법을 보여줍니다.
프로세스
힌트 파일을
/etc/default/nodeip-configuration파일에 추가합니다. 예를 들면 다음과 같습니다.NODEIP_HINT=192.0.2.1중요-
노드의 정확한 IP 주소를 힌트로 사용하지 마십시오(예:
192.0.2.5). 노드의 정확한 IP 주소를 사용하면 노드가 힌트 IP 주소를 사용하는 경우 올바르게 구성되지 않습니다. - 힌트 파일의 IP 주소는 올바른 서브넷을 결정하는 데만 사용됩니다. 힌트 파일에 나타나는 결과로 트래픽을 수신하지 않습니다.
-
노드의 정확한 IP 주소를 힌트로 사용하지 마십시오(예:
다음 명령을 실행하여
base-64로 인코딩된 콘텐츠를 생성합니다.$ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0출력 예
Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==클러스터를 배포하기 전에
master및worker역할에 대한 머신 구성 매니페스트를 생성하여 힌트를 활성화합니다.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 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<encoded_contents>를/etc/default/nodeip-configuration파일의 base64 인코딩 콘텐츠(예:Tk9ERUlQX0hJTlQ9MTkyLjAuMC=== )로 바꿉니다. 쉼표 이후와 인코딩된 콘텐츠 전에는 공백을 사용할 수 없습니다.
-
클러스터 구성을 저장하는 디렉터리에 매니페스트를 저장합니다(예:
~/clusterconfigs). - 클러스터를 배포합니다.
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가 다음 순서로 작업을 완료합니다.
- 선택한 머신 구성 풀에 따라 노드를 단일 순서로 드레이닝합니다.
-
각 노드가 추가
br-ex1브리지 네트워크 구성을 수신하도록 Ignition 구성 파일을 각 노드에 삽입합니다. -
br-exMAC 주소가br-ex가 네트워크 연결에 사용하는 인터페이스의 MAC 주소와 일치하는지 확인합니다. -
새 인터페이스 정의를 참조하는
configure-ovs.sh쉘 스크립트를 실행합니다. -
br-ex및br-ex1을 호스트 노드에 추가합니다. - 노드를 분리합니다.
모든 노드가 Ready 상태로 돌아가고 OVN-Kubernetes Operator가 br-ex 및 을 감지하고 구성한 후 Operator는 br-ex 1k8s.ovn.org/l3-gateway-config 주석을 각 노드에 적용합니다.
추가 br-ex1 브리지 및 항상 기본 br-ex 브리지가 필요한 상황에 대한 자세한 내용은 "Localnet 토폴로지에 대한 구성"을 참조하십시오.
프로세스
선택 사항: 추가 브릿지
br-ex1에서 다음 단계를 완료하여 사용할 수 있는 인터페이스 연결을 생성합니다. 예제 단계에서는 모두 머신 구성 매니페스트 파일에 정의된 새 본딩 및 해당 종속 인터페이스를 생성하는 방법을 보여줍니다. 추가 브릿지는MachineConfig오브젝트를 사용하여 추가 본딩 인터페이스를 형성합니다.중요추가 인터페이스를 정의하기 위해 Kubernetes NMState Operator를 사용하거나
NodeNetworkConfigurationPolicy(NNCP) 매니페스트 파일을 정의하지 마십시오.또한
본딩인터페이스를 정의할 때 기존br-exOVN Kubernetes 네트워크 배포에서 추가 인터페이스 또는 하위 인터페이스를 사용하지 않는지 확인합니다.다음 인터페이스 정의 파일을 생성합니다. 호스트 노드가 정의 파일에 액세스할 수 있도록 이러한 파일이 머신 구성 매니페스트 파일에 추가됩니다.
eno1.config라는 첫 번째 인터페이스 정의 파일의 예[connection] id=eno1 type=ethernet interface-name=eno1 master=bond1 slave-type=bond autoconnect=true autoconnect-priority=20eno2.config라는 두 번째 인터페이스 정의 파일의 예[connection] id=eno2 type=ethernet interface-name=eno2 master=bond1 slave-type=bond autoconnect=true autoconnect-priority=20bond1.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다음 명령을 실행하여 정의 파일을 Base64 인코딩 문자열로 변환합니다.
$ base64 <directory_path>/en01.config$ base64 <directory_path>/eno2.config$ base64 <directory_path>/bond1.config
환경 변수를 준비합니다. <
machine_role>을worker와 같은 노드 역할로 바꾸고 <interface_name>을 추가br-ex브리지 이름의 이름으로 바꿉니다.$ export ROLE=<machine_role>머신 구성 매니페스트 파일에 각 인터페이스 정의를 정의합니다.
bond1,eno1및en02에 대한 정의가 추가된 머신 구성 파일의 예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 # ...터미널에 다음 명령을 입력하여 네트워크 플러그인을 구성하기 위한 머신 구성 매니페스트 파일을 생성합니다.
$ oc create -f <machine_config_file_name>OVN-Kubernetes 네트워크 플러그인을 사용하여
extra_bridge파일 을 생성하여 노드에 OVS(Open vSwitch) 브리지br-ex1을 만듭니다. 파일을 호스트의/etc/ovnk/extra_bridge경로에 저장해야 합니다. 파일에는 노드의 기본 IP 주소가 있는br-ex를 지원하는 기본 인터페이스가 아닌 추가 브릿지를 지원하는 인터페이스 이름을 지정해야 합니다.추가 인터페이스를 참조하는
extra_bridge파일/etc/ovnk/extra_bridge에 대한 설정 예bond1클러스터에서 재시작한 모든 노드에서
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선택한 노드에 머신 구성을 적용합니다.
$ oc create -f <machine_config_file_name>선택 사항:
/var/lib/ovnk/iface_default_hint리소스를 생성하는 머신 구성 파일을 생성하여 노드의br-ex선택 논리를 덮어쓸 수 있습니다.참고리소스에는
br-ex가 클러스터에 대해 선택하는 인터페이스의 이름이 나열됩니다. 기본적으로br-ex는 시스템 네트워크의 부팅 순서 및 IP 주소 서브넷을 기반으로 노드의 기본 인터페이스를 선택합니다. 특정 머신 네트워크 구성을 사용하려면br-ex가 호스트 노드의 기본 인터페이스 또는 본딩을 계속 선택해야 할 수 있습니다.호스트 노드에 머신 구성 파일을 생성하여 기본 인터페이스를 재정의합니다.
중요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,bond01 filesystem: root- 1
- 머신 구성 파일을 노드에 적용하기 전에
bond0이 노드에 있는지 확인합니다.
-
클러스터의 모든 새 노드에 구성을 적용하기 전에 호스트 노드를 재부팅하여
br-ex가 의도한 인터페이스를 선택하고br-ex1에 정의된 새 인터페이스와 충돌하지 않는지 확인합니다. 클러스터의 모든 새 노드에 머신 구성 파일을 적용합니다.
$ oc create -f <machine_config_file_name>
검증
클러스터에서
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\"],호스트 노드에서 네트워크 인터페이스 이름을 검토하여 대상 노드에 추가 브릿지가 있는지 확인합니다.
$ 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선택 사항:
/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