Bridge to Kubernetes

What is "Bridge to Kubernetes" and how does it contribute to enhancing the Developer Experience (DX)?

In this post, we will delve into Bridge to Kubernetes by examining a Sample ASP.NET Core Web API.

What is Bridge to Kubernetes?

Bridge to Kubernetes is an iterative development tool for authoring microservice applications that target Kubernetes. Bridge to Kubernetes allows you to run and debug code on your development computer while it remains connected to your Kubernetes cluster along with the rest of your application or services. In my earlier blog post on Remocal, I showcased the use of mirrord.

Prerequisites

  • A Kubernetes cluster

    NOTE: According to Microsoft documentation, Bridge to Kubernetes does not work with Docker for Desktop Kubernetes clusters. Therefore, for this exercise, I have utilized Kind to setup a multi-node kubernetes cluster.

  • Docker Desktop

    It is used to create a local Docker Container Registry. For instructions on how to set it up, please refer to the section Preparation of Local Docker Container Registry in the blog "Demystifying Kubernetes for developers.

  • Bridge to Kubernetes Visual Studio Code Extension

    Rapid Kubernetes development for teams.

  • Kompose

    Kompose is a conversion tool for Docker Compose to container orchestrators such as Kubernetes (or OpenShift).

  • Lens

    Lens is a Kubernetes platform that provides tools for seamless interaction with Kubernetes clusters, and an environment for secure and effective work within teams and organizations.

Creation of DEMO API

# Using below command, you can create a ASP.NET Core Web API.
dotnet new webapi -n b2k-api
# Once created, you can use command to see if it working fine.
dotnet run

Creation of Docker & Docker Compose files

Using the Command Palette... option, you can add docker and docker-compose files to the b2k-api project.

Build Image and Push to local registry

Once docker file is ready, you can build and push the image to the local registry using the Command Palette... option as

Creation of Kubernetes manifest file

Kompose helps to create Kubernetes manifest files from Docker Compose file.

kompose convert
INFO Kubernetes file "b2kapi-service.yaml" created
INFO Kubernetes file "b2kapi-deployment.yaml" created

For simplicity, I have merged both files into one named b2kapi-deployment.yaml and updated the image location to the local registry.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: /usr/local/bin/kompose convert
    kompose.version: 1.32.0 (HEAD)
  labels:
    io.kompose.service: b2kapi
  name: b2kapi
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: b2kapi
  template:
    metadata:
      annotations:
        kompose.cmd: /usr/local/bin/kompose convert
        kompose.version: 1.32.0 (HEAD)
      labels:
        io.kompose.network/b2k-api-default: "true"
        io.kompose.service: b2kapi
    spec:
      containers:
        - image: localhost:5000/b2kapi:latest
          name: b2kapi
          ports:
            - containerPort: 5001
              hostPort: 5001
              protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    kompose.cmd: /usr/local/bin/kompose convert
    kompose.version: 1.32.0 (HEAD)
  labels:
    io.kompose.service: b2kapi
  name: b2kapi
spec:
  ports:
    - name: "5001"
      port: 5001
      targetPort: 5001
  selector:
    io.kompose.service: b2kapi

Creation of Kind Kubernetes Cluster

The following configuration is used to creating a multi-node cluster.

# create a kind-config.yaml describing kind cluster details.
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
    endpoint = ["http://my-registry:5000"]
nodes:
- role: control-plane
- role: worker
- role: worker
# Run this command to create a kind cluster based on kind-config.yaml
kind create --config kind-config.yaml
docker network connect "kind" "my-registry" # Refer your local container registry

Deployment of DEMO API to Kubernetes Cluster

Now that all artifacts (e.g., Images, Local Registry, Kubernetes Cluster) are ready, we can deploy the application using the command below.

kubectl apply -f b2kapi-deployment.yaml

Using Lens

The Lens tool facilitates quick verification of deployments and service port-forwarding. Since we are not using ingress, we opted for port-forwarding. The following images provide a glimpse of pods, services, port-forwarding, and accessing the API from outside the cluster.

Start debugging

You can initiate the debugging process by selecting Debug (Local Tunnel) option.

If Bridge To Kubernetes is not installed, it will prompt you to install it and request administrative privileges.

While the Debug process is being prepared, you can find more details referring to terminal window, output window.

If you observe the pod details using Lens carefully, you may notice that the existing pod is killed, two new pods are created, and once you terminate the debugging activity, the original pod is automatically restored. This is how Bridge-To-Kubernetes operates.

Finally, if you set a breakpoint and initiate a request to the service, it will pause at the breakpoint, enabling you to continue with regular debugging activities.

Limitations

  • A pod may only have a single container running in that pod for Bridge to Kubernetes to successfully connect.
  • Currently, Bridge to Kubernetes pods must be Linux containers. Windows containers aren't supported.
  • Bridge to Kubernetes needs elevated permissions to run on your development computer in order to edit your hosts file.
  • Bridge to Kubernetes can't be used on clusters with Azure Dev Spaces enabled.

Happy Debugging...