Ingress 디버깅
가상 사설 클라우드 기존 인프라
클러스터에 앱의 Ingress 리소스를 작성하여 앱을 노출했습니다. 그러나 Ingress 하위 도메인 또는 ALB의 IP 주소를 통해 앱에 연결하려고 할 때 연결에 실패하거나 제한시간 초과됩니다.
다음 절의 단계는 Ingress 설정을 디버깅하는 데 도움이 될 수 있습니다.
시작하기 전에 IBM Cloud Kubernetes Service에 대한 다음 IBM Cloud IAM 액세스 정책 이 있는지 확인하십시오. - 클러스터에 대한 편집자 또는 관리자 플랫폼 역할 - 작성자 또는 관리자 서비스 액세스 역할
1단계: 앱 배치 확인
Ingress를 디버그하기 전에 먼저 앱 배치 디버깅을 확인하십시오.
Ingress 문제는 앱 배치 또는 앱을 노출하는 ClusterIP 서비스의 기본 문제로 종종 발생합니다. 예를 들어, 앱 레이블 및 서비스 선택기가 일치하지 않거나 앱 및 서비스 대상 포트가 일치하지 않을 수 있습니다.
2단계: Ingress 배치 및 ALB 팟(Pod) 로그에서 오류 메시지 확인
Ingress 리소스 배치 이벤트와 ALB 팟(Pod) 로그에서 오류 메시지를 확인하여 시작하십시오. 이러한 오류 메시지는 오류의 근본 원인을 파악하고, 다음 섹션에서 Ingress 설정을 더 자세히 디버깅하는 데 도움이 될 수 있습니다.
-
Ingress 리소스 배치를 확인하고 경고 또는 오류 메시지를 찾으십시오.
kubectl describe ingress <myingress>출력의 Events 섹션에서 Ingress 리소스 또는 사용된 특정 어노테이션의 올바르지 않은 값에 대한 경고 메시지가 표시될 수 있습니다. Ingress( NGINX 기반 ALB)의 경우, Ingress 리소스 구성 문서 또는 어노테이션 문서를 참조하십시오. Traefik 기반 ALB의 경우, Ingress 리소스 구성 문서 또는 Ingress Controller 구성 문서를 참조하십시오.
NAME: myingress Namespace: default Address: 169.xx.xxx.xxx,169.xx.xxx.xxx Default backend: <default> Rules: Host Path Backends ---- ---- -------- mycluster-<hash>-0000.us-south.containers.appdomain.cloud /tea myservice1:80 (<none>) /coffee myservice2:80 (<none>) Annotations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 26s (x8 over 19m) nginx-ingress-controller Scheduled for sync Normal Sync 26s (x8 over 19m) nginx-ingress-controller Scheduled for sync -
ALB 팟(Pod)의 상태를 확인하십시오.
- 클러스터에서 실행 중인 ALB 팟(Pod)을 가져오십시오.
kubectl get pods -n kube-system | grep alb ``` 2. **STATUS** 열을 확인하여 모든 팟(Pod)이 실행 중인지 확인하십시오. 3. 팟(Pod)이 `Running` 상태가 아니면 ALB를 사용 중지한 후에 이를 다시 사용할 수 있습니다. 다음 명령에서 `<ALB_ID>`을(를) 팟의 ALB ID로 바꾸십시오. 예를 들어, 실행 중이 아닌 팟(Pod)의 이름이 `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z`이면 ALB ID는 `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`입니다. * 클래식 클러스터: ```sh {: pre} ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID> ``` ```sh {: pre} ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID> ``` * VPC 클러스터: ```sh {: pre} ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID> ``` ```sh {: pre} ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID> ``` -
ALB에 대한 로그를 확인하십시오.
- 클러스터에서 실행 중인 ALB 팟(Pod)의 ID를 가져오십시오.
kubectl get pods -n kube-system | grep alb ``` 1. Ingress( NGINX ) 기반 ALB의 경우, 각 ALB 포드에 있는 `nginx-ingress` 컨테이너의 로그를 확인하십시오. Traefik 기반 ALB의 경우, 각 ALB 포드에 있는 `traefik` 컨테이너의 로그를 확인하세요. ```sh {: pre} kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system ``` 1. ALB 로그에서 오류 메시지를 찾으십시오.
3단계: ALB 하위 도메인 및 공인 IP 주소에 대한 Ping 실행
Ingress 하위 도메인과 ALB의 공인 IP 주소에 대한 가용성을 확인하십시오. 또한, IBM NS1 에서 ALB에 접근하여 상태 점검을 수행할 수 있도록 설정하십시오.
-
공용 ALB가 청취하는 IP 주소(클래식) 또는 호스트 이름(VPC)를 가져오십시오.
ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>dal10및dal13에서 작업자 노드의 클래식 다중 구역 클러스터에 대한 예제 출력:ALB ID Enabled Status Type ALB IP Zone Build ALB VLAN ID NLB Version private-cr24a9f2caf6554648836337d240064935-alb1 false disabled private - dal13 ingress:1.1.2_2507_iks 2294021 - private-cr24a9f2caf6554648836337d240064935-alb2 false disabled private - dal10 ingress:1.1.2_2507_iks 2234947 - public-cr24a9f2caf6554648836337d240064935-alb1 true enabled public 169.62.196.238 dal13 ingress:1.1.2_2507_iks 2294019 - public-cr24a9f2caf6554648836337d240064935-alb2 true enabled public 169.46.52.222 dal10 ingress:1.1.2_2507_iks 2234945 -- 공용 ALB에 IP 주소(클래식) 또는 호스트 이름(VPC)이 없는 경우 Ingress ALB가 구역에 배치되지 않음을 참조하십시오.
-
ALB 상태 검사에서 ALB IP 주소에 도달할 수 있는지 확인하십시오.
-
일반 사항: Calico 의 DNAT 이전 네트워크 정책이나 다른 사용자 지정 방화벽을 사용하여 클러스터로 들어오는 트래픽을 차단하는 경우, Kubernetes 제어 플레인에서 Kubernetes 및 IBM NS1 의 IPv4 IP 주소에서 ALB의 IP 주소로 들어오는 포트 80 또는 443에 대한 인바운드 액세스를 허용해야 합니다. 그래야 제어 플레인이 ALB의 상태를 확인할 수 있습니다. 예를 들어, Calico 정책을 사용하는 경우, Calico 용 사전 DNAT 정책 생성 를 통해 IBM NS1의 소스 IP 주소 에서 포트 80을 통해 ALB IP 주소로의 인바운드 액세스를 허용하고, 클러스터가 위치한 리전의 제어 플레인 서브넷 를 허용합니다.
-
VPC: 클러스터 인그레스에 대한 VPC LBaaS (LoadBalancer-as-a-Service) 인스턴스에 사용자 지정 보안 그룹이 있는 경우 보안 그룹 규칙이 Kubernetes 컨트롤 플레인 IP 주소에서 포트 443으로의 필요한 상태 확인 트래픽을 허용하는지 확인합니다.
-
-
ALB IP(클래식) 또는 호스트 이름(VPC)의 상태를 검사하십시오.
- 각 공용 ALB의 IP 주소(클래식) 또는 호스트 이름(VPC)에 ping을 실행하여, 각 ALB가 패킷을 정상적으로 수신할 수 있는지 확인하십시오. 사설 ALB를 사용 중이면 사설 네트워크에서만 해당 IP 주소(클래식) 또는 호스트 이름(VPC)에 대해 ping을 실행할 수 있습니다.
ping <ALB_IP> ``` * CLI가 제한시간 초과를 리턴하고 작업자 노드를 보호하는 사용자 정의 방화벽이 있는 경우, 방화벽에서 ICMP가 허용되는지 확인하십시오. * 방화벽이 없거나 방화벽이 Ping 실행을 차단하지 않고 Ping 실행이 여전히 제한시간을 초과하는 경우에는 [ABL 팟(Pod)의 상태를 확인](#check_pods)하십시오. * 다중 구역 클러스터에만 해당: MZLB 상태 검사를 사용하여 ALB IP(클래식) 또는 호스트 이름(VPC)의 상태를 판별할 수 있습니다. 다음의 HTTP cURL 명령에서는 ALB IP에 대해 `albhealth` 또는 `healthy` 상태를 리턴하도록 IBM Cloud Kubernetes Service에 의해 구성된 `unhealthy` 호스트를 사용합니다. ```sh {: pre} curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>" ``` 명령 예제: ```sh {: pre} curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud" ``` 출력 예 ```sh {: screen} healthy ``` 하나 이상의 IP가 `unhealthy`를 리턴하면 [ALB 팟(Pod)의 상태를 확인](#check_pods)하십시오. -
IBM 제공 Ingress 하위 도메인을 가져오십시오.
ibmcloud ks cluster get --cluster <cluster_name_or_ID> | grep Ingress출력 예
Ingress Subdomain: mycluster-<hash>-0000.us-south.containers.appdomain.cloud Ingress Secret: mycluster-<hash>-0000 -
이 절의 1단계에서 가져온 각 공용 ALB에 대한 IP(클래식) 또는 호스트 이름(VPC)이 클러스터의 IBM 제공 Ingress 하위 도메인에 등록되었는지 확인하십시오. 예를 들어, 클래식 다중 구역 클러스터에서 작업자 노드가 있는 각 구역의 공용 ALB IP는 동일한 하위 도메인으로 등록되어야 합니다.
kubectl get ingress -o wide출력 예
NAME HOSTS ADDRESS PORTS AGE myingressresource mycluster-<hash>-0000.us-south.containers.appdomain.cloud 169.46.52.222,169.62.196.238 80 1h
4단계: 도메인 맵핑 및 Ingress 리소스 구성 확인
- 사용자 정의 도메인을 사용하는 경우에는 DNS 제공자를 사용하여 사용자 정의 도메인을 IBM 제공 하위 도메인 또는 ALB의 공인 IP 주소로 맵핑했는지 확인하십시오. 참고로, IBM에서 IBM 하위 도메인의 자동 상태 검사를 제공하고 실패한 IP를 DNS 응답에서 제거하므로 CNAME을 사용하도록 권장합니다.
- IBM 제공 하위 도메인 CNAME: 사용자 정의 도메인이 표준 이름 레코드(CNAME)에 있는 클러스터의 IBM 제공 하위 도메인에 맵핑되었는지 확인하십시오.
host www.my-domain.com ``` 출력 예 ```sh {: screen} www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222 mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238 ``` * **공인 IP 주소 A 레코드**: 사용자 정의 도메인이 A 레코드에 있는 ALB의 포터블 공인 IP 주소에 맵핑되었는지 확인하십시오. IP는 [이전 절](#ping)의 1단계에서 가져온 공용 ALB IP와 일치해야 합니다. ```sh {: pre} host www.my-domain.com ``` 출력 예 ```sh {: screen} www.my-domain.com has address 169.46.52.222 www.my-domain.com has address 169.62.196.238 ``` - 클러스터의 Ingress 리소스 구성 파일을 확인하십시오.
kubectl get ingress -o yaml-
하나의 호스트를 하나의 Ingress 리소스에서만 정의했는지 확인하십시오. 여러 Ingress 리소스에 하나의 호스트를 정의하면 ALB가 올바르게 트래픽을 전달하지 않으면서 오류가 발생할 수 있습니다.
-
하위 도메인 및 TLS 인증서가 올바른지 확인하십시오. IBM 제공 Ingress 하위 도메인 및 TLS 인증서를 찾으려면
ibmcloud ks cluster get --cluster <cluster_name_or_ID>를 실행하십시오. -
Ingress의 path 섹션에 구성된 동일한 경로에서 앱이 청취하는지 확인하십시오. 루트 경로에서 청취하도록 앱이 설정된 경우에는
/를 경로로 사용하십시오. 이 경로로 들어오는 트래픽을 앱이 수신 대기 중인 다른 경로로 라우팅해야 하는 경우,**잉그레스-NGINX**에[경로 재작성](/docs/containers?topic=containers-comm-ingress-annotations#alb-rewrite-paths)어노테이션을 사용하십시오. Traefik의 경우,ReplacePath미들웨어를 사용하십시오. -
필요하면 리소스 구성 YAML을 편집하십시오. 편집기를 닫으면 변경사항이 저장되고 자동으로 적용됩니다.
kubectl edit ingress <myingressresource> ``` -
Classic 환경에서 디버깅을 위해 DNS에서 ALB 제거하기
특정 ALB IP를 통해 앱에 액세스할 수 없는 경우에는 해당 DNS 등록을 사용 중지하여 프로덕션에서 ALB를 임시로 제거할 수 있습니다. 그리고 ALB의 IP 주소를 사용하여 해당 ALB에서 디버깅 테스트를 실행할 수 있습니다.
예를 들어, 2개의 구역에 다중 구역 클러스터가 있으며 2개의 공용 ALB의 IP 주소가 169.46.52.222 및 169.62.196.238이라고 가정합니다. 상태 검사가 두 번째 구역의 ALB에 대해 정상 상태(healthy)를 리턴하지만, 이를 통해 앱에 직접 접속할 수 없습니다. 사용자는 디버깅을 위해 프로덕션에서 해당 ALB의 IP 주소 169.62.196.238을
제거하기로 결정합니다. 첫 번째 구역의 ALB IP 169.46.52.222는 사용자의 도메인에 등록되어 있으며, 사용자가 두 번째 구역의 ALB를 디버깅하는 동안 트래픽을 계속 라우팅합니다.
-
다음 명령어를 사용하여 도메인 이름에서 IP 주소를 제거하십시오. update 명령어는 등록된 IP 주소를 완전히 대체하므로, 명령어에는 정상적으로 작동하는 IP 주소만 지정해야 합니다:
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 -
IBM ( NS1 ) 서버를 확인하여, 해당 도메인의 DNS 등록 정보에서 ALB IP 주소가 제거되었는지 확인하십시오. 참고로, DNS 등록을 업데이트하려면 수 분이 소요될 수 있습니다.
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.netExample output that confirms that only the healthy ALB IP,
169.46.52.222, remains in the DNS registration and that the unhealthy ALB IP,169.62.196.238, has been removed:mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222 -
이제 ALB IP가 프로덕션에서 제거되었으므로 이를 통해 앱에 대해 디버깅 테스트를 실행할 수 있습니다. 이 IP를 통해 앱에 대한 통신을 테스트하기 위해, 예제 값을 사용자 자신의 값으로 대체하여 다음 cURL 명령을 실행할 수 있습니다.
curl -X GET --resolve mycluster-<hash>-0000.us-south.containers.appdomain.cloud:443:169.62.196.238 https://mycluster-<hash>-0000.us-south.containers.appdomain.cloud/- 모든 항목이 올바르게 구성되어 있으면 앱으로부터 예상된 응답을 받습니다.
- 응답에서 오류를 받는 경우, 이 특정 ALB에만 적용되는 구성이나 앱에 오류가 있을 수 있습니다. 앱 코드와 Ingress 리소스 구성 파일 (Ingress- NGINX ) 을 확인하거나, Traefik의 Ingress Controller 구성 문서를 참조하거나, 해당 ALB에만 적용한 기타 구성 사항을 확인해 보세요.
-
디버깅을 마친 후에는 다음 명령어를 사용하여 ALB의 DNS 등록을 복원하십시오:
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 --ip 169.62.196.238 -
IBM ( NS1 ) 서버를 확인하여, 도메인의 DNS 등록 정보에서 ALB IP 주소가 복원되었는지 확인하십시오. 참고로, DNS 등록을 업데이트하려면 수 분이 소요될 수 있습니다.
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net출력 예
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222 mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238