How to Scale End-to-End Observability in AWS Environments

Microsoft Launches Bridge to Kubernetes

Sept. 27, 2020, 10:21 p.m.

TL;DR

Last week, Microsoft has launched its Bridge to Kubernetes service, a Visual Studio extension that enables developers to write, test, and debug microservice code locally while consuming dependencies from a Kubernetes environment.

Microsoft announces General Availability of Bridge to Kubernetes (Photo by Alex Azabache on Unsplash)

Key Facts

1
The Bridge to Kubernetes is an iterative development tool in Visual Studio and VS Code, previously known as Local Process with Kubernetes
2
It enables developers to write, test and debug microservice code on their development machines while consuming dependencies and inheriting configurations from a Kubernetes environment.
3
Microservice applications are made up of several services calling each other and each one has its own configuration and dependencies. This makes developing and managing microservices, time-consuming and complicated. Running the application locally may help, but it will add more complexity.
4
Microsoft Bridge to Kubernetes solves this problem by connecting the developer's development workstation to their Kubernetes cluster, which eliminates the need to manually source, configure and compile external dependencies on the development workstation.
5
Instead of redeploying a new cluster, Microsoft Bridge to Kubernetes allows developers to test and develop services in the context of the full application quickly and without creating any additional Docker or Kubernetes configuration.

Details

Bridge to Kubernetes is initially available in VS Code and will be available soon in Visual Studio, but it supports all Kubernetes.

According to Visual Studio documentation, when Bridge to Kubernetes establishes a connection to your cluster, it:

Prompts you to configure the service to replace on your cluster, the port on your development computer to use for your code, and the launch task for your code as a one-time action.
Replaces the container in the pod on the cluster with a remote agent container that redirects traffic to your development computer.
Runs kubectl port-forward on your development computer to forward traffic from your development computer to the remote agent running in your cluster.
Collects environment information from your cluster using the remote agent. This environment information includes environment variables, visible services, volume mounts, and secret mounts.
Sets up the environment in Visual Studio so the service on your development computer can access the same variables as if it were running on the cluster.
Updates your hosts file to map services on your cluster to local IP addresses on your development computer. These hosts file entries allow code running on your development computer to make requests to other services running in your cluster. To update your hosts file, Bridge to Kubernetes will ask for administrator access on your development computer when connecting to your cluster.
Starts running and debugging your code on your development computer. If necessary, Bridge to Kubernetes will free required ports on your development computer by stopping services or processes that are currently using those ports.

The project code is available on Github.

Bridge to Kubernetes lets you work in isolation from colleagues using the same cluster and namespace by leveraging our new routing technology. You can also apply the isolation capability outside the Bridge to Kubernetes experience, such as directly from a GitHub pull request. You can test changes from a PR directly in Kubernetes before the pull request is merged into the main branch of your repo.
Nick Greenfield
Program Manager, Bridge to Kubernetes