3
votes

We are using managed Kubernetes in Azure (AKS) and have run out of public IP addresses. We only need one, but AKS creates a new public IP every time we deploy a service and it does not delete it when the service is deleted. For example:

apiVersion: v1
kind: Service
metadata:
  name: somename
spec:
  ports:
  - port: 443
    targetPort: 443
  selector:
    app: somename
  # Also tried this to reuse public IP in AKS MC resource group
  # https://docs.microsoft.com/en-my/azure/aks/static-ip
  # loadBalancerIP: x.x.x.x
  type: LoadBalancer

Every time this is deployed (kubectl create -f svc.yml) a new public IP is created. When it is deleted (kubectl delete -f svc.yml) the IP remains. Trying to reuse one of the existing IPs with loadBalanceIP as in the comments above fails, "Public ip address ... is referenced by multiple ipconfigs in resource ...".

We have created a service request but it takes ages, so I'm hoping this will be faster. I don't dare to just delete the public IPs in the AKS managed resource as that may cause issues down the line.

Is there a way to safely release or reuse the public IPs? We are using Kubernetes version 1.7.12. We have deleted the deployment referenced by the service as well, it makes no difference.

1
Hi, you should use apply instead of create when you are deploying an application in the cluster. Now if you update already existed application public IP will not change. - Suresh Vishnoi
Thanks! That will reduce churn, but it will still not release old addresses, so it is only a stop-gap solution. If a new address is created every time a load balancer is created and not reclaimed when it is destroyed they will run out eventually. - ewramner
yea. I am using AKS as well. However, I did not encounter this error. It's supposed to be deleted from the external loadbalancer when the service is deleted. - Suresh Vishnoi
Do you use Kubernetes 1.7.x or one of the newer versions? - ewramner
I am having k8s 1.8.1 - Suresh Vishnoi

1 Answers

1
votes

It should delete the IPs after some time (like 5 minutes tops). So the issue you are having is a bug. You can check k8s events to find the error and look at it.

Also, its perfectly safe to delete Azure resources. k8s wont freak out if they are gone.

Tested with k8s 1.9.1