{"id":"IL-0463","org":"Harness","date":"2026-05-12","docs":[],"title":{"en":"Secure Connect connectors timed out after a GKE control plane upgrade left Harness's internal load balancer unreachable","ko":"Harness Secure Connect 의 내부 로드 밸런서에 닿을 수 없게 되어 Secure Connect 를 쓰는 git 커넥터 검사와 CI 파이프라인이 실패했다"},"domain":["kubernetes","gcp","networking"],"impact":{"scope":"Secure Connect-enabled git connector tests and CI pipelines (Continuous Integration Enterprise Mac and Linux Cloud Builds in Prod 1, Prod 2 and Prod 3); connectors without Secure Connect were unaffected","users":"Harness customers using Secure Connect","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.harness.io/incidents/743r4kg80xj7","kind":"official-status","archived":null}],"summary":{"en":"Harness's Secure Connect runs on FRPS (Fast Reverse Proxy Server) in a GKE cluster, behind an internal Kubernetes LoadBalancer service. On 12 May 2026 an automated GKE control plane upgrade ran in two phases in quick succession. Each phase restarts the GKE cloud controller manager, which manages the IP addresses of LoadBalancer services and, as part of its reconciliation after a restart, deletes and re-inserts IP address reservations. The second phase began before the first reconciliation had finished, so the controller deleted the reservation for the internal FRPS load balancer and was interrupted before it could acquire it again. Harness states that none of its application deployments caused or contributed to the issue.\n\nA rollout restart of FRPS restored client connections to the server but not the orphaned IP. Harness then deleted and recreated the internal service frps-internal, which made GKE provision a new load balancer with a new IP address, and updated the Cloud DNS A record to the new IP, restoring end-to-end routing. Connectivity was confirmed by internal tests and by affected customers. The status page shows the incident under investigation at 14:38 PDT and resolved at 16:10 PDT.","ko":"2026-05-12 에 Harness 의 Secure Connect 서비스가 크게 끊겨, Secure Connect 로 git 커넥터 검사와 CI 파이프라인을 돌리던 고객이 연결 타임아웃과 실패를 겪었다. Secure Connect 의 내부 FRPS, 곧 Fast Reverse Proxy Server 인프라를 돌리는 GKE 클러스터에서 컨트롤 플레인 자동 업그레이드가 두 단계로 빠르게 이어서 실행됐다. 단계마다 쿠버네티스 LoadBalancer 서비스의 IP 주소 수명을 관리하는 GKE 클라우드 컨트롤러 매니저가 재시작됐다. 이 컨트롤러는 재시작할 때 정상 조정 과정으로 IP 주소 예약을 지웠다가 다시 넣는다. 첫 조정이 끝나기 전에 두 번째 단계가 시작되면서 경쟁 상태가 생겼고, 컨트롤러는 내부 FRPS 로드 밸런서의 IP 예약을 지운 뒤 다시 잡기 전에 중단됐다. 그 결과 로드 밸런서에 닿을 수 없게 됐다. Harness 애플리케이션 배포는 원인도 아니고 피해를 키우지도 않았다.\n\nHarness 는 FRPS 디플로이먼트를 롤아웃 재시작해 클라이언트 연결을 되살렸지만 IP 문제는 남았다. 내부 쿠버네티스 서비스 frps-internal 을 지우고 다시 만들어 GKE 가 새 IP 로 새 로드 밸런서를 만들게 했고, Cloud DNS A 레코드를 새 IP 로 바꿔 Secure Connect 트래픽의 경로를 처음부터 끝까지 되살렸다. 내부 테스트와 영향받은 고객이 연결을 확인했다. 상태 페이지 기준으로 14:38 PDT 에 조사를 시작해 14:40 에 원인을 찾았고, 15:50 에 수정을 적용해 지켜보다가 16:10 에 해결로 닫았다."},"trigger":{"en":"An automated GKE control plane upgrade on the cluster that hosts Harness's internal Secure Connect FRPS (Fast Reverse Proxy Server) infrastructure.","ko":"Secure Connect 의 내부 FRPS 인프라를 돌리는 GKE 클러스터에서 컨트롤 플레인 자동 업그레이드가 두 단계로 잇달아 실행됐고, 단계마다 GKE 클라우드 컨트롤러 매니저가 재시작됐다."},"severity":"unknown","symptoms":["network-unreachable","resources-deleted"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["gke-control-plane","cloud-controller-manager","cloud-load-balancer"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Ran a rollout restart of the FRPS deployment, which restored client connectivity to FRPS but not the lost IP","ko":"FRPS 디플로이먼트를 롤아웃 재시작해 클라이언트가 FRPS 서버에 다시 연결되게 했다. IP 예약이 사라진 근본 문제는 이 조치로 풀리지 않았다."}},{"text":{"en":"Deleted and recreated the internal service frps-internal so GKE provisioned a new load balancer and IP","ko":"내부 쿠버네티스 서비스 frps-internal 을 지우고 다시 만들어, GKE 가 새 IP 주소로 새 로드 밸런서를 만들게 했다."}},{"text":{"en":"Updated the Cloud DNS A record to the new load balancer IP","ko":"Cloud DNS A 레코드가 새 로드 밸런서 IP 를 가리키게 바꿔, Secure Connect 트래픽 전체의 경로를 되살렸다."}}],"action_items":[],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"On 12 May 2026, Harness customers who used Secure Connect saw git connector tests fail with connection timeouts and CI pipelines hang or fail, while connectors without Secure Connect kept working. Continuous Integration Enterprise Mac and Linux Cloud Builds in Prod 1, Prod 2 and Prod 3 were affected.\n\nA load balancer that Secure Connect depends on had been left unreachable. A rollout restart of the FRPS deployment restored client connectivity to the FRPS server but did not fix the problem, because the IP address reservation of the internal load balancer was gone.","ko":"Secure Connect 를 켠 커넥터를 쓰려던 고객이 연결 타임아웃과 실패를 겪었다. Secure Connect 를 켠 git 커넥터 테스트가 연결 타임아웃으로 실패했고, Secure Connect 를 켠 CI 파이프라인은 멈추거나 실패했다. Secure Connect 없이 도는 커넥터는 정상이었다.\n\n영향은 Prod 1, Prod 2, Prod 3 의 Continuous Integration Enterprise(CIE) - Mac Cloud Builds 와 Continuous Integration Enterprise(CIE) - Linux Cloud Builds 에 미쳤다. 상태 페이지에는 2026-05-12 14:38 PDT 에 조사 중으로 처음 올라왔다.\n\nFRPS 디플로이먼트를 롤아웃 재시작하자 클라이언트가 FRPS 서버에 다시 연결됐지만, 근본 문제인 IP 예약이 사라진 상태는 그대로였다."},"updated_at":"2026-11-14T12:34:11.121169Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0463","org_slug":"harness"}