Docker and Kubernetes terminology for .NET developers

Posted: (EET/GMT+2)

 

If you are starting with Docker or Kubernetes as a .NET developer, the terminology can feel more complicated than the actual tools.

Here are a few core terms that show up often when deploying ASP.NET Core applications in containers.

Docker image

An image is a packaged snapshot of your application and its runtime dependencies. For ASP.NET Core applications, the image usually starts from one of the official .NET runtime images. In your Dockerfile, you might have a line like this:

FROM mcr.microsoft.com/dotnet/aspnet:6.0

You build the image once and run containers from it.

Container

A container is a running instance of an image. You can think of it as a lightweight, isolated process environment. The start a container from image myapp, you could say:

docker run -p 8080:80 myapp

Containers are intended to be disposable. If one stops, the platform should create a new one instead of repairing the old instance manually.

Dockerfile

The Dockerfile describes how the image is built.

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src

COPY . .
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app

COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

For .NET applications, multi-stage builds have became common because they reduce the final image size significantly. That is, one image is used for building, and another for running.

Next, let's take a look at Kubernetes, the container orchestration platform.

Kubernetes Pod

A Pod is the smallest deployable unit in Kubernetes. In many ASP.NET Core deployments, a Pod contains one running container.

If the container crashes, Kubernetes creates a replacement automatically.

Deployment

A Deployment defines how Pods are managed.

For example:

  • how many instances should run
  • which image version is used
  • how updates are rolled out.

This is where scaling and rolling updates are usually configured.

Service

A Kubernetes Service provides stable networking in front of Pods.

Because Pods can be recreated at any time, their IP addresses are not stable. The Service acts as the consistent endpoint for traffic.

Ingress

An Ingress handles HTTP routing into the cluster.

For example:

  • api.contoso.com: the API service
  • portal.contoso.com: the frontend service.

In production environments, TLS certificates are commonly attached at the Ingress layer.

Registry

A registry stores Docker images.

Common examples include Docker Hub and Azure Container Registry (ACR).

A typical deployment flow is along these lines:

dotnet publish
docker build
docker push
kubectl apply

Tip: Kubernetes is mostly about orchestration, not container creation. Docker builds and runs containers, while Kubernetes manages them across multiple servers.

For ASP.NET Core developers, the important shift is operational thinking: applications are expected to restart cleanly, scale horizontally, and store persistent state outside the container itself.

Hope this helps!