LoadBalancer"-type services to get stuck. Commit aaf46c4 added the carry in order to reduce unnecessary cloud-provider API calls, but it is no longer needed and causes problems with recent changes to the clean-up logic for services with type "LoadBalancer". At the time the commit was written, the service controller added every newly created service to its work queue, which was also used for update and delete events. When a worker for this queue subsequently processed the service, it would check if the service needed an external load-balancer, and if not, it would then check if a load balancer existed for the service (in case the service had been added to the queue by an update that changed its type from "LoadBalancer", in which case any previously provisioned load-balancer would need to be deleted). To perform this check, the worker would make a GetLoadBalancer API call using the cloud provider. Commit aaf46c4 added a check to skip the GetLoadBalancer call if the service's status indicated that it had no associated load-balancer, which should always be the case for a newly created service if its type is not "LoadBalancer". Later, upstream commit aa3f81d modified the service controller's logic to add a newly created service to the work queue only if its type were "LoadBalancer", thereby obviating the need for the check that commit aaf46c4 had added. The upstream commit also modified the service controller's load-balancer clean-up logic, and the check that commit aaf46c4 added breaks this new logic. This commit fixes bug 1798282. https://bugzilla.redhat.com/show_bug.cgi?id=1798282 * vendor/k8s.io/kubernetes/pkg/controller/service/controller.go (syncLoadBalancerIfNeeded): Delete check for empty load balancer status.