When you are using kubernetes you have a cluster, and clusters are rarely small. Your gripes may come in different flavours though. The cluster won’t fit on your local box any more. You most probably have people in your team that need the cluster as well. You need the feedback faster than deploying your changes to the cluster. What to do with all those problems?
Run a bridge that will route traffic to your local version of one of the microservices. Easy. You will run your service locally that will interact with a kubernetes cluster without interrupting anyone. Sounds amazing, doesn’t it.
To illustrate this let’s run a sample app in a cluster and then do some “development” and “debugging”. This will not affect the “development” environment for other people that could use it. The code will be isolated and your team will be happy.
Run the sample app
There is a sample app in the repo of Bridge To Kubernetes and we will use that. Go grab it from https://github.com/Azure/Bridge-To-Kubernetes and run it, you will need `Minikube` for that (unless you have your own k8s cluster, then you know what to do). Here’s how you install it and below is how you deploy the app.
# in the root of the app
minikube start --driver=docker
kubectl create namespace todo-app
kubectl apply -n todo-app -f deployment.yaml
Those commands above will start the cluster and deploy the app. I’d recommend you run kubectl get services -n todo-app next. If you are seeing pending under EXTERNAL-IP you need a tunnel running to be able to work. After that next call to kubectl get services -n todo-app should show IP address.
minikube tunnel # <- in a separate terminal
kubectl get services -n todo-app
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.0.49.177 127.0.0.1 80:30145/TCP 18h
Start the bridge
You are now ready to start the bridge. There are two ways of running the bridge. You can have your app isolated and non isolated. When you run a non isolated app all traffic will be routed from the cluster to your local machine. This will interrupt work of other people so we will not do that. In case of an isolated app your local app will be an additional service that you can reach only if you use a specific URL. As you can imagine that is very useful when working with a team as you may work along side other people without disrupting them. I’m going for isolated mode as it is more interesting to show.
This next bit is done in Visual Studio Code. There is a CLI for it but I had not had any luck in running application in isolated mode. Please go here https://learn.microsoft.com/en-us/visualstudio/bridge/bridge-to-kubernetes-sample#debug-the-stats-api-service and follow all the steps until the question about isolating your local service. You need to answer yes here, the example is based on no (non isolated app). This action will prompt you to enter password as the EndpointManager needs to configure hosts file.
Set a breakpoint somewhere in server.js file, most preferably in functions serving /stats endpoint. I did mine on this line. Then open address 127.0.0.1 in a browser and click stats link.
You have breakpoint set in the method serving this url but nothing happens in VSCode. That is correct as the call is not routed to your local micro service. How to trigger the breakpoint you may ask? There is a different address you need to open, to get it press CMD + SHIFT + P and search for “Bridge to Kubernetes: Open Menu”. You see on the screenshot under what address my local service is. Yours will be most likely different.
Open this address in the browser, you may click the option in the menu. Press stats there and the breakpoint will be triggered. You will drop to VSCode. You are not affecting other users with this. If you don’t believe me leave the code at the breakpoint and open 127.0.0.1 again. When you click stats you will get a page without any locking. Amazing if you ask me.
With this tool you can develop code with a remote cluster, and even with a whole team. Very useful.