Changing a Service from type: LoadBalancer to type: ClusterIP doesn't remove status.loadBalancer.ingress[]

[dsharp-pivotal]

Steps to reproduce the issue:

1. minikube start --memory 8192 --cpus 8 --disk-size 80g
2. minikube tunnel
3. Create a Service my-svc with type: LoadBalancer
4. Observe kubectl get service my-svc -o yaml shows status.loadBalancer.ingress[0].ip with the service's clusterIP
5. kubectl patch service my-svc --type=merge -p "spec: {type: ClusterIP}"

Actual:

status.loadBalancer.ingress[0].ip remains.

Expected:

status.loadBalancer.ingress should be removed.

This would help automated tests that need to work with both minikube and cloud k8s clusters like GKE, that test adding and removing external access on Service.

We took a look at LoadBalancerEmulator, and saw that it has a method cleanupService(). However, it is only called on Services with type: LoadBalancer, and the cleanup methods are only called during shutdown.

Ideally, it seems like PatchServices should reconcile all Services to add or remove status.loadBalancer.ingress as appropriate.

[priyawadhwa]

Hey @dsharp-pivotal thanks for opening this issue. Just to clarify, it seems like your expected outcome depends on changing the functionality of kubectl patch service, is that what you intended?

I'm not very familiar with minikube tunnel but I wonder if there's something we could do there to stop tunneling if a service type is changed from LoadBalancer to something else. That could be enough to test adding/removing external access to a Service.

[dsharp-pivotal]

Hey @dsharp-pivotal thanks for opening this issue. Just to clarify, it seems like your expected outcome depends on changing the functionality of kubectl patch service, is that what you intended?

kubectl patch is just one way to change the contents of the Service.spec. You could achieve the same results with kubectl edit or kubectl apply. The important bit is changing spec.type from LoadBalancer to ClusterIP. That should result in an observable change in the Service.status.loadBalancer.ingress[].

I'm not very familiar with minikube tunnel but I wonder if there's something we could do there to stop tunneling if a service type is changed from LoadBalancer to something else. That could be enough to test adding/removing external access to a Service.

I don't care terribly much about whether or not the tunnel still works (although indeed ideally the tunnel would stop working). I want to be able to observe, via Service.status, that the Service no longer has an ingress IP.

Please take a look at LoadBalancerEmulator: https://github.com/kubernetes/minikube/blob/master/pkg/minikube/tunnel/loadbalancer_patcher.go

Due to how it's implemented, it will add Service.status.loadBalancer.ingress[].IP to Services with spec.type == LoadBalancer, but it will never remove it if the type is changed away from LoadBalancer.

[vishjain]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[dsharp-pivotal]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten