39.3. HTTP 서비스에 대한 외부 액세스 디버깅

클러스터 외부의 시스템에 있고 클러스터에서 제공하는 리소스에 액세스하려는 경우 공용 IP 주소에서 수신 대기하고 클러스터 내부의 트래픽을 "라우팅"하는 Pod에서 프로세스를 실행해야 합니다. OpenShift Container Platform 라우터 는 HTTP, HTTPS(SNI 사용), WebSockets 또는 TLS(SNI 사용)의 해당 목적을 제공합니다.

클러스터 외부에서 HTTP 서비스에 액세스할 수 없다고 가정하면 문제가 발생하는 시스템의 명령줄에서 문제를 재현하여 시작합니다. 시도:

curl -kv http://foo.example.com:8000/bar    # But replace the argument with your URL

이 기능이 작동하면 버그를 적시에서 재현하시겠습니까? 서비스에 작동하는 일부 포드와 없는 포드가 있을 수도 있습니다. 그러면 39.4절. “라우터 디버깅” 섹션으로 이동합니다.

실패한 경우 DNS 이름을 IP 주소로 확인하겠습니다 (아직 그렇지 않은 것으로 가정).

dig +short foo.example.com                  # But replace the hostname with yours

IP 주소를 다시 제공하지 않으면 DNS 문제를 해결해야 하지만 이 가이드의 범위를 벗어납니다.

다음으로 ping -c 주소와 tracepath 주소를 사용하여 라우터 호스트에 연결할 수 있는지 확인합니다. ICMP 패킷에 응답하지 않을 수 있습니다. 이 경우 해당 테스트가 실패하지만 라우터 시스템에 연결할 수 있습니다. 어느 경우 telnet 명령을 사용하여 라우터의 포트에 직접 액세스하십시오.

telnet 1.2.3.4 8000

다음을 얻을 수 있습니다.

Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.

이 경우 IP 주소의 포트에서 수신 대기 중인 항목이 있습니다. 좋습니다. ctrl-] 을 누른 다음 Enter 키를 누르고 close 를 입력하여 telnet을 종료합니다. 39.4절. “라우터 디버깅” 섹션으로 이동하여 라우터의 다른 항목을 확인합니다.

또는 다음을 얻을 수 있습니다.

Trying 1.2.3.4...
telnet: connect to address 1.2.3.4: Connection refused

라우터가 해당 포트에서 수신 대기하지 않음을 알려주는 것은 무엇입니까. 라우터 구성 방법에 대한 자세한 내용은 39.4절. “라우터 디버깅” 섹션을 참조하십시오.

또는 다음을 볼 수 있습니다.

Trying 1.2.3.4...
  telnet: connect to address 1.2.3.4: Connection timed out

이는 해당 IP 주소의 아무 것도와도 통신할 수 없음을 알려줍니다. 라우팅, 방화벽 및 해당 IP 주소에서 라우터를 수신 대기하는지 확인합니다. 라우터를 디버깅하려면 39.4절. “라우터 디버깅” 섹션을 참조하십시오. IP 라우팅 및 방화벽 문제의 경우 이 가이드의 보기가 아닌 디버깅입니다.