클래식 클러스터: 오염된 노드를 사용할 때 소스 IP를 유지하는 데 실패하는 이유가 무엇입니까?

클래식 인프라

서비스 구성 파일에서 externalTrafficPolicy 을 Local 으로 변경하여 인그레스 ALB에 대한 소스 IP 보존 활성화 서비스를 제공합니다. 그러나 앱의 백엔드 서비스에 트래픽이 도달하지 않습니다.

Ingress ALB 서비스에 대해 소스 IP 주소 보존을 사용으로 설정하면 클라이언트 요청의 소스 IP 주소가 보존됩니다. 해당 서비스는 요청 패킷의 IP 주소가 변경되지 않았음을 보장하기 위해 동일한 작업자 노드에 있는 앱 팟(Pod)에만 트래픽을 전달합니다.

일반적으로 Ingress ALB 서비스 포드는 앱 포드와 동일한 워커 노드에 배포됩니다. 그러나 일부 상황에서는 서비스 파드와 앱 파드가 동일한 워커 노드에서 스케줄되지 않을 수 있습니다. 워커 노드에서 Kubernetes 틴트를 사용하면, 틴트 톨러레이션이 없는 모든 파드는 틴트된 워커 노드에서 실행되지 않는다. 사용한 오염 유형에 따라 소스 IP 보존이 작동하지 않을 수 있습니다:

  • 에지 노드 오염: 사용자가 클러스터의 각 공용 VLAN에 있는 둘 이상의 작업자 노드에 dedicated=edge 레이블을 추가하여 이러한 작업자 노드에만 Ingress 팟(Pod)이 배치되도록 하였습니다. 그 후에는 이러한 에지 노드 또한 오염시켜 다른 워크로드가 이러한 에지 노드에서 실행되지 않도록 하였습니다. 그러나 앱 배치에 에지 노드 친화성 규칙 및 오염 허용을 추가하지는 않았습니다. 앱 팟(Pod)이 서비스 팟(Pod)과 동일한 오염된 노드에 스케줄될 수 없으므로 앱의 백엔드 서비스에 트래픽이 도달하지 않습니다.

  • 사용자 정의 오염: 사용자가 여러 노드에 사용자 정의 오염을 사용하여 해당 오염 허용이 있는 팟(Pod)만 이러한 노드에 배치될 수 있도록 하였습니다. 그 후 앱과 Ingress 서비스의 배치에 친화성 규칙 및 오염 허용을 추가하여 이들의 팟(Pod)이 이러한 노드에만 배치되도록 하였습니다. 그러나 ibm-cloud-provider-ip 네임스페이스에서 자동으로 작성된 keepalived ibm-system 팟(Pod)은 ALB 팟(Pod) 및 앱 팟(Pod)이 항상 동일한 작업자 노드로 스케줄되도록 보장합니다. 이러한 keepalived 팟(Pod)에는 사용된 사용자 정의 오염에 대한 오염 허용이 없습니다. 이들은 앱 팟(Pod)이 실행 중인 동일한 오염된 노드에 스케줄될 수 없으므로 앱의 백엔드 서비스에 트래픽이 도달하지 않습니다.

다음 선택사항 중 하나를 선택하여 문제를 해결하십시오.

이전 단계를 완료했지만 keepalived 파드가 여전히 예약되지 않은 경우 keepalived 파드에 대한 자세한 정보를 수집하세요:

  1. keepalived 팟(Pod)을 가져오십시오.
    kubectl get pods -n ibm-system
  2. 출력에서 ibm-cloud-provider-ipStatus**가 **인 Pending 팟(Pod)을 찾으십시오. 예:
    ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t     0/1       Pending   0          2m        <none>          <none>
ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-8ptvg     0/1       Pending   0          2m        <none>          <none>
  3. 각 keepalived 포드에 대해 설명하고 이벤트 섹션을 검토합니다. 나열된 오류 또는 경고 메시지를 해결합니다.
    kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system