39.6. 노드 네트워킹으로 노드 디버깅
작동하지 않는 엔드포인트 목록을 사용하여 노드 연결을 테스트해야 합니다.
모든 노드에 예상 IP 주소가 있는지 확인합니다.
# oc get hostsubnet NAME HOST HOST IP SUBNET rh71-os1.example.com rh71-os1.example.com 192.168.122.46 10.1.1.0/24 rh71-os2.example.com rh71-os2.example.com 192.168.122.18 10.1.2.0/24 rh71-os3.example.com rh71-os3.example.com 192.168.122.202 10.1.0.0/24
DHCP를 사용하는 경우 변경할 수 있습니다. 호스트 이름, IP 주소 및 서브넷이 예상과 일치하는지 확인합니다. 노드 세부 정보가 변경된 경우
oc edit hostsubnet을 사용하여 항목을 수정합니다.노드 주소와 호스트 이름이 올바른지 확인한 후 끝점 IP 및 노드 IP를 나열합니다.
# oc get pods --selector=docker-registry \ --template='{{range .items}}HostIP: {{.status.hostIP}} PodIP: {{.status.podIP}}{{end}}{{"\n"}}' HostIP: 192.168.122.202 PodIP: 10.128.0.4이전에 기록한 엔드포인트 IP 주소를 찾아
PodIP항목에서 찾고 해당HostIP주소를 찾습니다. 그런 다음HostIP의 주소를 사용하여 노드 호스트 수준에서 연결을 테스트합니다.-
ping -c 3 <IP_address>: 응답이 없는 것은 중간 라우터가 ICMP 트래픽을 차단한다는 것을 의미할 수 있습니다. tracepath <IP_address>: 모든 홉에서 ICMP 패킷을 반환하는 경우 타겟으로 이동한 IP 경로를 표시합니다.추적 경로와ping이 모두 실패하는 경우 로컬 또는 가상 네트워크에서 연결 문제를 찾습니다.
-
로컬 네트워킹의 경우 다음을 확인하십시오.
패킷이 대상 주소로 전송되는 경로를 확인합니다.
# ip route get 192.168.122.202 192.168.122.202 dev ens3 src 192.168.122.46 cache위의 예에서 소스 주소가
192.168.122.46인ens3이라는 인터페이스를 종료하고 타겟으로 직접 이동합니다. 예상한 인터페이스인 경우ip a show dev ens3을 사용하여 인터페이스 세부 정보를 가져오고 이 예상 인터페이스인지 확인합니다.대체 결과는 다음과 같을 수 있습니다.
# ip route get 192.168.122.202 1.2.3.4 via 192.168.122.1 dev ens3 src 192.168.122.46
IP 값을
통해를 통과하여 적절하게 라우팅합니다. 트래픽이 올바르게 라우팅되고 있는지 확인합니다. 디버깅 경로 트래픽은 이 가이드의 범위를 벗어납니다.
다음을 사용하여 노드 간 네트워킹에 대한 기타 디버깅 옵션을 해결할 수 있습니다.
-
양쪽 끝에 이더넷 링크가 있습니까?
ethtool <network_interface>의 출력에서Link detected: yes를 찾습니다. -
이중 설정과 이더넷 속도가 양쪽 끝에 적절한가요? 나머지
ethtool <network_interface>정보를 살펴봅니다. - 케이블이 올바르게 연결되어 있습니까? 올바른 포트에?
- 스위치가 올바르게 구성되어 있습니까?
노드 간 연결에 문제가 없음을 확인하고 나면 양쪽 끝에 있는 SDN 구성을 확인해야 합니다.
