Case Study Extension: Developing .NET Microservices for Kubernetes

In this chapter, we bridge the insights from Chapter 21, Case Study, where we explored the practical implementation of .NET microservices, with the foundational knowledge of Kubernetes presented in Chapter 20, Kubernetes. Our focus here is on preparing .NET code for seamless integration with Kubernetes, encompassing the complete development cycle—from coding to debugging, and even troubleshooting post-deployment challenges.

We will guide you through the process of setting up a development workstation optimized for Kubernetes, learn the intricacies of packaging code with Docker, and understand how to organize your codebase for flawless execution across varied environments, such as Docker Desktop, local minikube installations, and production or staging Kubernetes clusters.

Also, this chapter delves into the nuances of remote debugging, providing you with the necessary skills to efficiently troubleshoot...

Technical requirements

This chapter requires Visual Studio 2022 free Community Edition or better, with all the database tools installed.

You will also need these:

• WSL (Windows Subsystem for Linux) and Docker Desktop for Windows. Detailed instructions on how to install both of them are given in the Technical requirements section of Chapter 11, Applying a Microservice Architecture to Your Enterprise Application.
• A Minikube installation that specifies Docker as a virtualization tool. Minikube installation is described in the Using Minikube section of Chapter 20, Kubernetes.
• A SQL Server database that allows TCP/IP connections. You can’t use SQL Server Express LocalDB, which comes with Visual Studio installation, since it doesn’t allow TCP/IP connections. So you need either a full SQL Express installation or an Azure SQL Server database. More details on how to fulfill this requirement will be given in the Tools needed for .NET Kubernetes development...

The Tools needed for .NET Kubernetes development

Each single microservice can be unit-tested and debugged independently from the remainder of its application, with the technique you learned Chapter 9, Testing Your Enterprise Application. You don’t need to package it inside a Docker image to do this.

However, debugging and performing integration tests on the whole application or parts of it requires that all involved microservices interact and are packaged as in the final application.

You can use a staging environment to beta-test your application. Prior to staging deployment, ensure your application’s stability in the development environment to prevent time-consuming troubleshooting, because the staging environment doesn’t have all the facilities that are available in a development environment. Otherwise, troubleshooting all frequent bugs and crashes discovered in the staging environment might imply an unacceptable time cost.

Therefore, it is preferable...

Organizing the development process

Since Visual Studio and other IDEs offer good support for Docker and a good integration with Docker Desktop, the best option for most of the development time is working with just Dockerized images without running them inside of Minicube.

In fact, as we will see shortly, once we have added Docker support to our projects, it is enough to click the Run Visual Studio button to start all our Dockerized microservices and to enable them to communicate through a Docker network. Conversely, running our application in Minikube requires several manual steps, and it takes some time to load the Docker images on Minikube and to create all the necessary Kubernetes objects.

Doing this in Visual Studio is super easy. It is enough to add Docker support for all microservice projects in your solution and to select the option of launching several projects simultaneously when the solution is run. Then, Visual Studio will automatically perform all the necessary...

Running your application in Minikube

When Visual Studio runs your microservices with Docker, it creates special images that also contain information needed by the Visual Studio debugger and have a dev version name. These special images can be run just from Visual Studio, and if you try to launch them manually, you will get an error. For the same reason, you can’t use them in Minikube.

Therefore, the first step for running your microservice in Minikube is to create different “standard” images. You can do this by right-clicking both the FakeSource and GrpcMicroService Docker files in Visual Studio Solution Explorer and by selecting Build Docker Image.

This way, you will create a grpcmicroservice and a fakesource image, both with the latest version name, as shown in the image below:

Figure 22.9: Creating Minikube-ready Docker images

As a next step, you must start Minikube:

minikube start

Now, you must load your Docker images inside of...

Remote debugging a Kubernetes application

As a final step, we will debug GrpcMicroService with Bridge to Kubernetes. Let’s set GrpcMicroService as a starting project and change the project start from Docker to Bridge to Kubernetes, as shown in the image below:

Figure 22.11: Debugging GrpcMicroService with Bridge to Kubernetes

Let’s place a breakpoint in the GrpcMicroService->HostedServices-> ProcessPurchases.cs file inside of the if block, as shown below:

if (toProcess.Count > 0)
{
	…
}

Then, start debugging. As soon as you click the run button, a window appears that prompts you to configure Bridge to Kubernetes:

Figure 22.12: Configuring Bridge to Kubernetes

If the window above doesn’t open, or you can’t see any Minikube node, Kubectl is probably not working or configured for Minikube. Try issuing a Kubectl command like kubectl get all. If you face any issues, try stopping and restarting Minikube with...

Summary

In this chapter, we explained how to prepare a developer workstation for .NET Kubernetes development and how to organize code testing and bug-fix cycles.

We also explained how to define a Docker virtual network to ensure microservices communication during development and name conventions for hostnames and Kubernetes services, enabling the same code to run both on the Docker virtual network, Minikube, and any other Kubernetes cluster.

Finally, we explained all the steps needed to run an application in Minikube and how to test it with Bridge to Kubernetes.

We’ve now reached the end of our journey through this book, and what a journey it has been!

Packed with numerous new and challenging ideas, this book is sure to be your good friend on your journey as a software architect.

These learnings will not only empower you to craft innovative solutions but also support your growth in the dynamic world of software projects. We sincerely hope you’ve...

Questions

1. Why can’t the SQL Server installation that comes with Visual Studio be used for Kubernetes development?
2. What is Bridge to Kubernetes?
3. Is it true that Bridge to Kubernetes works just with Minikube?
4. How do you load the Minikube images cache?
5. How do we define Minikube as the Kubectl default cluster?

Further reading

Most of the references in this chapter are the same as those previously listed in Chapter 11, Applying a Microservice Architecture to Your Enterprise Application, and Chapter 14, Implementing Microservices with .NET. Here, it is worth adding the link to the official documentation about Bridge to Kubernetes: https://learn.microsoft.com/en-us/visualstudio/bridge/

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the authors, and learn about new releases – follow the QR code below:

https://packt.link/SoftwareArchitectureCSharp12Dotnet8