Istio 수신 게이트웨이에 대한 ibm-cloud-provider-ip 팟(Pod)이 pending 상태로 멈춰 있는 이유는 무엇입니까?

가상 프라이빗 클라우드 클래식 인프라

다중 구역 클러스터 한정

kubectl get pod -n ibm-system을 실행하면 Istio 수신 게이트웨이의 외부 IP 주소를 제공하는 ibm-cloud-provider-ip 팟(Pod)이 pending 상태로 멈춰 있습니다.

또한 ibm-cloud-provider-ip 팟에 대해 kubectl describe pod <pod_name> -n ibm-system을(를) 실행하면 출력의 팟 이벤트 섹션에 스케줄링 충돌 오류가 있습니다.

게이트웨이에 대한 ibm-cloud-provider-ip 팟(Pod)을 식별하려는 경우에는 kubectl get service -n istio-system을 실행하여 게이트웨이의 로드 밸런서 서비스를 찾고, EXTERNAL-IP를 기록한 후 ibm-cloud-provider-ip 팟(Pod) 이름에서 해당 IP 주소를 찾아볼 수 있습니다.

istio-ingressgateway 로드 밸런서 서비스를 작성하면, 이 로드 밸런서에 외부 IP 주소를 제공하기 위해 ibm-cloud-provider-ip 팟(Pod)이 작성됩니다.

이러한 ibm-cloud-provider-ip 팟(Pod)에는 이 팟(Pod)이 해당 IP 주소의 소스인 서브넷과 동일한 구역에 작성되도록 하는 노드 친화성 규칙이 있습니다. 그러나 ExternalTrafficPolicy 로드 밸런서 서비스의 istio-ingressgateway 설정이 Local로 설정된 경우 ibm-cloud-provider-ip 팟(Pod)에는 게이트웨이 로드 밸런서 팟(Pod)과 동일한 구역에 배치되도록 하는 팟(Pod) 친화성 규칙도 있게 됩니다. IP 주소 및 게이트웨이 로드 밸런서가 클러스터의 다른 구역에 있으면 ibm-cloud-provider-ip 팟을 제대로 배치할 수 없습니다.

ibm-cloud-provider-ip 및 istio-ingressgateway 팟이 같은 구역에 없는지 확인하려면 다음을 수행하십시오.

  1. ** 팟(Pod)이 배치된 **NODEistio-ingressgateway를 식별하십시오.

    kubectl get pod -n istio-system -o wide

  2. 게이트웨이의 로드 밸런서 서비스의 EXTERNAL-IP 주소를 가져오십시오.

    kubectl get service -n istio-system

  3. 로드 밸런서에 대한 ** 팟(Pod)이 배치된 **NODEibm-cloud-provider-ip를 식별하십시오. <IP-with-hyphens>을(를) 이전 단계에서 찾은 IP 주소로 바꾸십시오. IP 주소에서 마침표(.) 대신 하이픈(-)을 사용하십시오. 예를 들어, 169.12.345.67은(는) 169-12-345-67이(가) 됩니다.

    kubectl get pod -n ibm-system -o wide -l ibm-cloud-provider-ip=<IP-with-hyphens>

  4. 작업자 노드가 있는 구역을 나열하십시오. 1단계와 3단계에서 찾은 작업자 노드를 비교하여 팟(Pod)이 서로 다른 구역의 작업자 노드에 배치되었는지 판별하십시오.

    kubectl get node --no-headers -L ibm-cloud.kubernetes.io/zone

    출력 예

    10.176.48.106   Ready   <none>   529d    v1.36+IKS   dal10
10.176.48.107   Ready   <none>   196d    v1.36+IKS   dal10
10.184.58.23    Ready   <none>   2y38d   v1.36+IKS   dal12
10.184.58.42    Ready   <none>   529d    v1.36+IKS   dal12

이 문제를 해결하려는 경우에는 istio-ingressgateway 팟(Pod)을 ibm-cloud-provider-ip 팟(Pod)이 있는 구역으로 이동하거나, 그 반대를 수행할 수 있습니다.

  • istio-ingressgateway 팟(Pod) 이동: 게이트웨이의 로드 밸런서가 이동한 후 동일한 외부 IP 주소를 유지합니다. 그러나 추가 기능의 버전 1.9 이하에서는 Istio 패치 업데이트 중에 게이트웨이의 구역 레이블이 자동으로 채워질 때 사용자가 적용한 변경사항을 겹쳐쓸 수 있습니다.
  • ibm-cloud-provider-ip 팟(Pod) 이동: 게이트웨이가 이동한 후 동일한 외부 IP 주소를 유지하지 않으며, 새 IP 주소가 지정됩니다. 그러나 추가 기능 업데이트 중에 겹쳐쓰는 변경사항은 없습니다.

istio-ingressgateway 팟(Pod) 이동

istio-ingressgateway 팟(Pod)을 ibm-cloud-provider-ip 팟(Pod)과 동일한 구역으로 이동하십시오.

  1. managed-istio-custom configmap 리소스를 편집하십시오.
    kubectl edit cm managed-istio-custom -n ibm-operators
  2. 이동하려는 게이트웨이에 대해, istio-ingressgateway-zone-1|2|3 설정을 ibm-cloud-provider-ip 팟(Pod)이 있는 구역으로 변경하십시오.
  3. 구성 파일을 저장하고 닫으십시오. istio-ingressgateway 팟(Pod)이 ibm-cloud-provider-ip 팟(Pod)과 동일한 구역에 있는 작업자 노드로 이동되며 ibm-cloud-provider-ip 팟(Pod)이 올바르게 배치됩니다.
  4. 이제 팟(Pod)들이 동일한 구역에 있는지 확인하려면 발생 원인 절의 단계를 따르십시오.

ibm-cloud-provider-ip 팟(Pod) 이동

ibm-cloud-provider-ip 팟(Pod)을 istio-ingressgateway 팟(Pod)과 동일한 구역으로 이동하십시오.

  1. managed-istio-custom configmap 리소스를 편집하십시오.

    kubectl edit cm managed-istio-custom -n ibm-operators

  2. 게이트웨이에 대한 istio-ingressgateway-zone-<1|2|3> 설정의 이름을 기록하십시오. 이 예제 configmap에서 dal10에 있는 게이트웨이의 ibm-cloud-provider-ip 팟을 이동하려면 istio-ingressgateway-zone-1(이)라는 키를 기록해 두십시오.

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "true"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  3. 해당 istio-ingressgateway-public-<1|2|3>-enabled 설정을 "false"(으)로 변경하여 게이트웨이를 일시적으로 사용 안함으로 설정하십시오. 이 configmap 예에서, ibm-cloud-provider-ip에 있는 게이트웨이에 대한 dal10 팟(Pod)을 이동하려는 경우에는 istio-ingressgateway-public-1-enabled를 "false"로 변경하십시오.

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "false"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  4. 구성 파일을 저장하고 닫으십시오.

  5. 게이트웨이의 로드 밸런서 팟(Pod)이 삭제되었는지 확인하십시오. 변경이 완료되는 데 최대 30분이 소요될 수 있다는 점을 참고하십시오.

    kubectl get service -n istio-system -o wide

  6. managed-istio-custom configmap 리소스를 여십시오.

    kubectl edit cm managed-istio-custom -n ibm-operators

  7. istio-ingressgateway-public-<1|2|3>-enabled 설정을 다시 "true"(으)로 변경하여 게이트웨이를 다시 사용으로 설정하십시오.

  8. 구성 파일을 저장하고 닫으십시오. 게이트웨이(istio-ingressgateway 팟(Pod))에 대한 새 로드 밸런서 서비스가 작성되며 이 로드 밸런서에 대한 ibm-cloud-provider-ip 팟(Pod)이 istio-ingressgateway 팟(Pod)과 동일한 구역에 있는 작업자 노드에 배치됩니다.

  9. 이제 팟(Pod)들이 동일한 구역에 있는지 확인하려면 발생 원인 절의 단계를 따르십시오.