Step-by-step instructions for a workaround you can perform to prevent the istio-ingressgateway IP from being changed.

Imagine this scenario: You have a Kubernetes cluster with the Istio add-on installed, and you need to update the Istio version. However, the version of the add-on that you installed is no longer supported and you cannot simply update it. You have to remove the current version and install a new version, but you may have a problem here — when you remove and install it again, you have no guarantee that the IP of istio-ingressgateway will be the same.

So, in this case, if you have that IP set for any NAT (Network Address Translation), firewall rules, or any other situation, you may have problems.

There is a workaround that you can perform and prevent the IP from being changed, and this article will provide step-by-step instructions.

Workaround

To resolve this problem, follow these steps:

  1. Identify your istio-ingressgateway external IP
  2. Verify external IPs available for your cluster 
  3. Create dummy load balancer services for all available external IPs (except for the istio-ingressgateway IP)
  4. Disable the Istio add-on (unsupported version)
  5. Wait for the istio-system namespace to be deleted 
  6. Enable the Istio add-on (supported version)
  7. Check the istio-ingressgateway external IP (it should be the desired external IP)
  8. Delete all the dummy services you created 

Step-by-step instructions

Step 1: Identify your istio-ingressgateway external IP

kubectl get service istio-ingressgateway -n istio-system

Take a look at the EXTERNAL-IP column, — it is your IP.

Step 2: Verify all external IPs available for your cluster

kubectl get cm -n kube-system ibm-cloud-provider-vlan-ip-config -o json

Take a look at “vlanipmap.json” — in this field, you have all IPs available for your cluster. You need to count the number of IPs available to find out how many services you will need to create. 

For example, if you have 29 IPs available, you will need to create 28 services, because 1 IP is already being used by istio-ingressgateway.

Step 3: Create dummy load balancer services

You will need to create a yaml file with the desired number of services. We are providing an example that contains 28 services, and you can adapt it to your needs.

Example: dummy_svc.yml

---
apiVersion: v1
kind: Service
metadata:
  name: example-service-1
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9365
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-2
spec:
  selector:
    app: example
  ports:
    - port: 8766
      targetPort: 9366
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-3
spec:
  selector:
    app: example
  ports:
    - port: 8767
      targetPort: 9367
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-4
spec:
  selector:
    app: example
  ports:
    - port: 8768
      targetPort: 9368
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-5
spec:
  selector:
    app: example
  ports:
    - port: 8769
      targetPort: 9369
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-6
spec:
  selector:
    app: example
  ports:
    - port: 8770
      targetPort: 9370
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-7
spec:
  selector:
    app: example
  ports:
    - port: 8771
      targetPort: 9371
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-8
spec:
  selector:
    app: example
  ports:
    - port: 8772
      targetPort: 9372
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-9
spec:
  selector:
    app: example
  ports:
    - port: 8773
      targetPort: 9373
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-10
spec:
  selector:
    app: example
  ports:
    - port: 8774
      targetPort: 9374
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-11
spec:
  selector:
    app: example
  ports:
    - port: 8775
      targetPort: 9375
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-12
spec:
  selector:
    app: example
  ports:
    - port: 8776
      targetPort: 9376
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-13
spec:
  selector:
    app: example
  ports:
    - port: 8777
      targetPort: 9377
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-14
spec:
  selector:
    app: example
  ports:
    - port: 8778
      targetPort: 9378
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-15
spec:
  selector:
    app: example
  ports:
    - port: 8779
      targetPort: 9379
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-16
spec:
  selector:
    app: example
  ports:
    - port: 8780
      targetPort: 9380
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-17
spec:
  selector:
    app: example
  ports:
    - port: 8781
      targetPort: 9381
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-18
spec:
  selector:
    app: example
  ports:
    - port: 8782
      targetPort: 9382
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-19
spec:
  selector:
    app: example
  ports:
    - port: 8783
      targetPort: 9383
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-20
spec:
  selector:
    app: example
  ports:
    - port: 8784
      targetPort: 9384
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-21
spec:
  selector:
    app: example
  ports:
    - port: 8785
      targetPort: 9385
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-22
spec:
  selector:
    app: example
  ports:
    - port: 8786
      targetPort: 9386
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-23
spec:
  selector:
    app: example
  ports:
    - port: 8787
      targetPort: 9387
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-24
spec:
  selector:
    app: example
  ports:
    - port: 8788
      targetPort: 9388
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-25
spec:
  selector:
    app: example
  ports:
    - port: 8789
      targetPort: 9389
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-26
spec:
  selector:
    app: example
  ports:
    - port: 8790
      targetPort: 9390
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-27
spec:
  selector:
    app: example
  ports:
    - port: 8791
      targetPort: 9391
  externalTrafficPolicy: Local
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: example-service-28
spec:
  selector:
    app: example
  ports:
    - port: 8792
      targetPort: 9392
  externalTrafficPolicy: Local
  type: LoadBalancer

After the file is created, simply create the services:

kubectl apply -f dummy_svc.yml

Confirm that the services were created:

kubectl get services -A -o wide |grep LoadBalancer

Step 4: Disable the Istio add-on 

In the IBM Cloud Portal, access your cluster, select the Add-ons option, click Managed Istio, and click on the Uninstall option.

Step 5: Wait for the istio-system namespace to be deleted 

kubectl get pods -o wide -n istio-system

Wait until there is no Istio component running.

Step 6: Enable the Istio add-on

ibmcloud ks cluster addon enable istio --version <version> -c <ClusterID>

You must follow the process until the installation is completed. You can follow the status through the IBM Cloud console, in the Add-ons tab on your cluster, or if you prefer, you can follow the creation of the pods through the command line.

You can execute the commands below to follow the creation of pods and services:

kubectl get pods -o wide -n istio-system
kubectl get services -n istio-system

Step 7: Check the istio-ingressgateway external IP (it should be the desired external IP)  

kubectl get service istio-ingressgateway -n istio-system

Take a look at the EXTERNAL-IP column — it is your IP.

Step 8: Delete all the dummy services you created 

kubectl delete -f dummy_svc.yml

Conclusion

The idea behind this workaround is to allocate all IPs with dummy services so that when removing and installing the Istio add-on, you only have one IP available for use. So we guarantee that when removing and installing, we will keep the same IP.

In this article, we are reporting the procedure for the istio-ingressgateway, as it was a situation that we experienced with one of our customers, but this procedure is not restricted to Istio. If you have any service that you need to recreate and want to ensure that it will go up with the same IP, you can use the same idea exposed in this article.

Learn more

Categories

More from Cloud

IBM Cloud VMware as a Service introduces multitenant as a new, cost-efficient consumption model

4 min read - Businesses often struggle with ongoing operational needs like monitoring, patching and maintenance of their VMware infrastructure or the added concerns over capacity management. At the same time, cost efficiency and control are very important. Not all workloads have identical needs and different business applications have variable requirements. For example, production applications and regulated workloads may require strong isolation, but development/testing, training environments, disaster recovery sites or other applications may have lower availability requirements or they can be ephemeral in nature,…

IBM accelerates enterprise AI for clients with new capabilities on IBM Z

5 min read - Today, we are excited to unveil a new suite of AI offerings for IBM Z that are designed to help clients improve business outcomes by speeding the implementation of enterprise AI on IBM Z across a wide variety of use cases and industries. We are bringing artificial intelligence (AI) to emerging use cases that our clients (like Swiss insurance provider La Mobilière) have begun exploring, such as enhancing the accuracy of insurance policy recommendations, increasing the accuracy and timeliness of…

IBM NS1 Connect: How IBM is delivering network connectivity with premium DNS offerings

4 min read - For most enterprises, how their users access applications and data is an essential part of doing business, and how they service those application and data responses has a direct correlation to revenue generation.    According to We Are Social’s Digital 2023 Global Overview Report, there are 5.19 billion people around the world using the internet in 2023. There’s an imperative need for businesses to trust their networks to deliver meaningful content to address customer needs.  So how responsive is the…

IBM Cloud Databases for MongoDB (Enterprise Edition): Changes to backup functionality

< 1 min read - We are announcing that IBM Cloud Databases for MongoDB (Enterprise Edition) will no longer support the creation of On Demand backups beginning on March 1, 2024. On Demand backups are being replaced by the recently deployed Point in Time Recovery (PITR) capabilities in the Enterprise Edition of our popular fully managed MongoDB service. With PITR, you can restore a copy of your database to any point in the past seven days. This gives you granular access to the past state…