DEV Community: Emmanuel Di Nicola

Deploying Traefik as an Ingress Controller. (Part 1)

Emmanuel Di Nicola — Tue, 07 Jan 2025 08:51:57 +0000

In the world of Kubernetes, managing traffic and securing APIs are critical tasks for any DevOps professional. This guide is the first in a three-part series designed to streamline your journey into modern application architecture:

Part 1: Deploying Traefik as an Ingress Controller

Part 2: Configuring KrakenD as an API Gateway.

Part 3: Building services that leverage Traefik and KrakenD for seamless traffic management and API integration.

In this first part, we will focus on deploying Traefik, a powerful Ingress Controller that simplifies external traffic management within Kubernetes environments. Whether you're experimenting with Kubernetes or managing production workloads, this guide will equip you with the knowledge to integrate Traefik effectively.

Why Traefik and KrakenD?

Traefik

Traefik is a modern, cloud-native reverse proxy and load balancer. Its dynamic configuration and seamless integration with Kubernetes make it ideal for handling HTTP and HTTPS traffic in microservices environments. Additionally, extensive features like middleware, TLS management, and monitoring reduce operational overhead. This makes Traefik a go-to solution for both small-scale and enterprise deployments.

KrakenD

KrakenD is an open-source API Gateway designed for high performance and flexibility. It handles complex operations such as request routing, aggregation, and transformation, allowing developers to expose APIs in a structured and efficient manner. With KrakenD, you can aggregate multiple microservices into a single endpoint, reducing latency and simplifying client interactions.

This series will ultimately demonstrate how to combine these tools to create robust, scalable architectures for modern applications.

All files mentioned in this guide are available in the GitHub repository: traefik-krakend-k8s-setup under the folder 1. traefik.

Prerequisites

To follow along, ensure you have the following:

A Kubernetes Cluster: This can be a local setup using Minikube or Kind, or a managed cluster like AWS EKS, Google GKE, or Azure AKS.
kubectl CLI: Installed and configured to interact with your cluster.
Helm CLI: Installed for managing Kubernetes packages.

Architecture Overview

This guide will cover:

Deploying Traefik to manage external traffic.

Step 1: Setting Up Traefik

Installing Traefik CRDs

To enable advanced features, start by installing Traefik's Custom Resource Definitions (CRDs):

helm repo add traefik https://traefik.github.io/charts
helm repo update
kubectl apply --server-side -k https://github.com/traefik/traefik-helm-chart/traefik/crds/

Creating Namespaces

Namespaces help organize Kubernetes resources. Create namespaces for Traefik, your applications, and KrakenD:

00-init-namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: traefik
---
apiVersion: v1
kind: Namespace
metadata:
  name: my-application
---
apiVersion: v1
kind: Namespace
metadata:
  name: krakend

Apply the namespaces:

kubectl apply -f 00-init-namespace.yaml

Configuring TLS

TLS is crucial for securing data, authenticating servers, and establishing trust with users. Certificates are necessary to enable encryption and verify server identity. Here, we use a self-signed certificate for internal or testing purposes.

Enable HTTPS by generating a self-signed certificate:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout wildcard.mydns.local.key -out wildcard.mydns.local.crt -subj "/CN=*.mydns.local" -addext "subjectAltName=DNS:*.mydns.local,DNS:mydns.local"

Store the certificate in Kubernetes:

kubectl create secret tls traefik-tls-secret --key ./wildcard.mydns.local.key --cert ./wildcard.mydns.local.crt -n traefik

Define a default TLS store:

In Traefik, certificates are grouped together in certificates stores.

Note that, any store definition other than the default one (named default) will be ignored, and there is therefore only one globally available TLS store.

00-just-tls.yaml:

apiVersion: traefik.io/v1alpha1
kind: TLSStore
metadata:
  name: default
  namespace: traefik
spec:
  defaultCertificate:
    secretName: traefik-tls-secret

Apply the TLS store configuration:

kubectl apply -f 00-just-tls.yaml

Granting Permissions

ClusterRole defines the set of permissions needed for Traefik to manage Kubernetes resources.
ServiceAccount provides an identity for Traefik within the cluster.
ClusterRoleBinding then associates this ClusterRole with the ServiceAccount, allowing Traefik to perform actions like reading endpoints or updating ingresses across all namespaces.

Create a ClusterRole for Traefik to interact with Kubernetes resources:

00-traefik-clusterrole.yaml:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik-role
rules:
- apiGroups:
  - ""
  resources:
  - services
  - secrets
  - nodes
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - list
  - watch
- apiGroups:
  - extensions
  - networking.k8s.io
  resources:
  - ingresses
  - ingressclasses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions
  - networking.k8s.io
  resources:
  - ingresses/status
  verbs:
  - update
- apiGroups:
  - traefik.io
  resources:
  - middlewares
  - middlewaretcps
  - ingressroutes
  - traefikservices
  - ingressroutetcps
  - ingressrouteudps
  - tlsoptions
  - tlsstores
  - serverstransports
  verbs:
  - get
  - list
  - watch

Note: This role grants all the permissions Traefik typically needs. If you’re not using certain features (for example, custom Traefik CRDs or managing Ingress status), feel free to remove those permissions. Just ensure you don’t remove anything you rely on, or Traefik may lose necessary functionality.

Apply the ClusterRole:

kubectl apply -f 00-traefik-clusterrole.yaml

Create a ServiceAccount and bind it to the ClusterRole:

01-traefik-serviceaccount.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-account
  namespace: traefik

02-traefik-clusterrole-binding.yaml:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-role
subjects:
- kind: ServiceAccount
  name: traefik-account
  namespace: traefik

Apply these configurations:

kubectl apply -f 01-traefik-serviceaccount.yaml
kubectl apply -f 02-traefik-clusterrole-binding.yaml

Deploying Traefik

To deploy Traefik in Kubernetes, create a Deployment that specifies Traefik's container image, resource requirements, and other necessary configurations. This Deployment will manage the Traefik pods, ensuring they run with the desired settings and scale as needed.

Create a Deployment for Traefik:

04-traefik-deployment.yaml:

kind: Deployment
apiVersion: apps/v1
metadata:
  name: traefik-deployment
  namespace: traefik
  labels:
    app: traefik
spec:
  replicas: 1
  selector:
    matchLabels:
      app: traefik
  template:
    metadata:
      labels:
        app: traefik
    spec:
      serviceAccountName: traefik-account
      containers:
      - name: traefik
        image: traefik:v3.2
        args:
        - --accesslog
        - --providers.kubernetescrd
        - --providers.kubernetesingress
        - --log.level=DEBUG
        - --entrypoints.web.address=:80
        - --entrypoints.websecure.address=:443
        - --entrypoints.web.http.redirections.entrypoint.to=websecure
        - --entrypoints.web.http.redirections.entrypoint.scheme=https
        - --entrypoints.websecure.http.tls=true
        ports:
        - name: websecure
          containerPort: 443
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 65532
          runAsGroup: 65532
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          seccompProfile:
            type: RuntimeDefault
        resources:
          requests:
            cpu: 200m
            memory: 100Mi
          limits:
            cpu: 200m
            memory: 100Mi

Note: The securityContext settings follow best practices for container security. Review your organization’s policies and ensure these align with specific requirements.

Apply the Deployment:

kubectl apply -f 04-traefik-deployment.yaml

Exposing Traefik

Create a LoadBalancer service to expose Traefik externally. This service will provide an external IP, making Traefik accessible for incoming traffic from outside the Kubernetes cluster.

05-traefik-web-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: traefik-web-service
  namespace: traefik
spec:
  type: LoadBalancer
  ports:
  - name: websecure
    port: 443
    targetPort: 443
  selector:
    app: traefik

Apply the service configuration:

kubectl apply -f 05-traefik-web-service.yaml

With this, your Traefik deployment is ready to manage external traffic efficiently.

What’s Next?

In Part 2, we will deploy KrakenD and configure it as a high-performance API Gateway to manage backend services. This will set the stage for building robust applications in Part 3, where Traefik and KrakenD will work together seamlessly to handle traffic and API integration.

Share Your Experience

If you found this guide helpful, share your experience or ask questions in the comments. We’d love to hear about your Kubernetes journey and how tools like Traefik and KrakenD fit into your workflow. Stay tuned for more DevOps insights and tutorials!

Exception Handling in C#

Emmanuel Di Nicola — Mon, 02 Dec 2024 15:19:34 +0000

Table of Contents

What Is an Exception in C#?
Types of Exceptions
Using try-catch-finally
How to Avoid Exceptions
- 4.1 Input Validation
- 4.2 Use TryParse for Safe Conversions
Centralizing Exception Handling
- 5.1 Built-in Middleware in ASP.NET Core
- 5.2 Custom Middleware
- 5.3 IExceptionHandler in .NET 8 and Later [Recommended]
Using Result Objects to Avoid Exceptions
- 6.1 What Is a Result Object?
- 6.2 Example of a Result<T> Class
- 6.3 Using Result<T> in a Method
- 6.4 Handling Results
Creating Custom Exceptions
- 7.1 Why Create Custom Exceptions?
- 7.2 How to Create a Custom Exception
- 7.3 Converting Standard Exceptions to Custom Exceptions
Best Practices for Custom Exceptions
- 8.1 Use Descriptive Names
- 8.2 Avoid Unnecessary Exceptions
Final Recommendation: Limit the Use of Exceptions
- Example: Exception vs. Result Object
- Performance Benchmark: Exception vs. Result Object

1. What Is an Exception in C#?

In C#, an exception is an unexpected event that occurs when an operation cannot be executed as intended. Exceptions allow you to handle runtime errors gracefully and define specific actions to prevent your program from crashing abruptly. Proper exception handling is essential for maintaining a good user experience and ensuring the stability of your application.

Example: In a data processing application, an exception might alert you to an error (like missing data) without stopping the entire process.

2. Types of Exceptions

Managed Exceptions: Predictable errors that your program can handle, such as a missing file. In this case, the program can create a new file or notify the user, allowing execution to continue smoothly.
Unhandled Exceptions: Serious errors often beyond the immediate control of your program. These errors might require stopping the program to prevent malfunctions or data loss.

3. Using `try-catch-finally`

Use try-catch-finally blocks to manage exceptions in a structured way:

try
{
    // Attempt to execute an operation
}
catch (Exception ex)
{
    // Handle the exception if the operation fails
}
finally
{
    // Execute code that should always run
}

catch: Captures specific exceptions. For example, when trying to open a nonexistent file, you can inform the user without crashing the program.
finally: Executes cleanup operations, like closing a file or releasing resources, ensuring resources are available even if an error occurs.

4. How to Avoid Exceptions

4.1 Input Validation

Before performing an operation, validate inputs to avoid common errors.

Example: Before dividing two numbers, ensure the denominator isn't zero.

if (divisor != 0)
{
    int result = numerator / divisor;
}
else
{
    Console.WriteLine("Error: The divisor cannot be zero.");
}

This proactive check prevents errors.

4.2 Use `TryParse` for Safe Conversions

Use TryParse to avoid errors when converting text to numbers, preventing exceptions from non-numeric input.

if (int.TryParse(input, out int result))
{
    Console.WriteLine("Conversion successful: " + result);
}
else
{
    Console.WriteLine("Invalid input.");
}

TryParse safely checks if a conversion is possible before attempting it.

5. Centralizing Exception Handling

In large applications, it's advisable to centralize exception handling using middleware, acting as a single control point, simplifying maintenance and enhancing reliability.

5.1 Built-in Middleware in ASP.NET Core

ASP.NET Core provides built-in middleware, UseExceptionHandler, which intercepts all exceptions in the application when configured in Program.cs. This middleware adds an error-handling mechanism to the application's processing pipeline, managing exceptions centrally.

Basic Implementation of Built-in Middleware:

app.UseExceptionHandler(options =>
{
    options.Run(async context =>
    {
        context.Response.StatusCode = (int)HttpStatusCode.BadRequest;
        context.Response.ContentType = "application/json";
        var exception = context.Features.Get<IExceptionHandlerFeature>();
        if (exception != null)
        {
            var message = $"{exception.Error.Message}";
            await context.Response.WriteAsync(message).ConfigureAwait(false);
        }
    });
});

5.2 Custom Middleware

In some cases, creating custom middleware allows for more detailed exception handling.

Custom Middleware Example for ASP.NET Core:

using System.Net;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;

public class GlobalExceptionHandlingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<GlobalExceptionHandlingMiddleware> _logger;

    public GlobalExceptionHandlingMiddleware(RequestDelegate next, ILogger<GlobalExceptionHandlingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "An unhandled exception has occurred.");
            await HandleExceptionAsync(context, ex);
        }
    }

    private async Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        var problemDetails = new ProblemDetails
        {
            Status = (int)HttpStatusCode.InternalServerError,
            Title = exception.Message,
            Detail = exception.StackTrace
        };

        context.Response.ContentType = "application/problem+json";
        context.Response.StatusCode = problemDetails.Status.Value;

        await context.Response.WriteAsJsonAsync(problemDetails);
    }
}

Adding the Custom Middleware:

app.UseMiddleware<GlobalExceptionHandlingMiddleware>();
app.UseRouting();
app.UseEndpoints(endpoints =>
{
    endpoints.MapControllers();
});

Integrating this middleware ensures all incoming requests are processed centrally. Any unhandled exceptions will be captured and managed, providing a uniform response to users.

5.3 `IExceptionHandler` in .NET 8 and Later [Recommended]

.NET 8 introduces the IExceptionHandler interface, the recommended method for global exception handling. It's now used internally by ASP.NET Core applications for default exception handling.

Implementing IExceptionHandler:

using System.Net;
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Hosting;

public class ExceptionToProblemDetailsHandler : IExceptionHandler
{
    private readonly IProblemDetailsService _problemDetailsService;
    private readonly IHostEnvironment _hostEnvironment;

    public ExceptionToProblemDetailsHandler(IProblemDetailsService problemDetailsService, IHostEnvironment hostEnvironment)
    {
        _problemDetailsService = problemDetailsService;
        _hostEnvironment = hostEnvironment;
    }

    public async ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
    {
        bool isDevEnv = _hostEnvironment.IsDevelopment() || _hostEnvironment.EnvironmentName == "qa" || _hostEnvironment.EnvironmentName == "acc";

        httpContext.Response.StatusCode = (int)HttpStatusCode.InternalServerError;

        var problemDetails = new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Title = "An error occurred",
            Detail = "An unexpected error occurred. Please try again later."
        };

        if (isDevEnv)
        {
            problemDetails.Extensions["exception"] = new
            {
                details = exception.ToString(),
                headers = httpContext.Request.Headers.ToDictionary(h => h.Key, h => h.Value.ToString()),
                path = httpContext.Request.Path,
                endpoint = $"{httpContext.Request.Method}: {httpContext.Request.Path}",
                routeValues = httpContext.Request.RouteValues.ToDictionary(r => r.Key, r => r.Value?.ToString() ?? string.Empty)
            };
        }

        await _problemDetailsService.WriteAsync(new ProblemDetailsContext
        {
            HttpContext = httpContext,
            ProblemDetails = problemDetails,
            Exception = exception
        });

        return true;
    }
}

In Program.cs:

builder.Services.AddExceptionHandler<ExceptionToProblemDetailsHandler>();
builder.Services.AddProblemDetails();
app.UseExceptionHandler();

This code registers your IExceptionHandler implementation with the application's service container, along with ProblemDetails.

Suppressing `ExceptionHandlerMiddleware` Logs

The built-in middleware generates additional logs in the console. To avoid duplicate error messages, disable these logs by adding the following line in appsettings.json or using Serilog:

Configuration in appsettings.json:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware": "None"
    }
  },
  "AllowedHosts": "*"
}

With Serilog:

Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .Filter.ByExcluding(logEvent =>
        logEvent.Properties.ContainsKey("SourceContext") &&
        logEvent.Properties["SourceContext"].ToString().Contains("Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware"))
    .CreateLogger();

6. Using Result Objects to Avoid Exceptions

6.1 What Is a Result Object?

Result<T> allows you to return a result instead of throwing an exception. This gives you better control over errors, such as returning a response indicating an operation failed without interrupting the application's execution.

6.2 Example of a `Result<T>` Class

public class Result<T>
{
    public bool IsSuccess { get; }
    public T? Value { get; }
    public string? Error { get; }

    private Result(bool isSuccess, T? value, string? error)
    {
        IsSuccess = isSuccess;
        Value = value;
        Error = error;
    }

    public static Result<T> Success(T value) =>
        new Result<T>(true, value, null);

    public static Result<T> Failure(string error) =>
        new Result<T>(false, default, error);
}

This class returns information about the success or failure of an operation without using exceptions.

6.3 Using `Result<T>` in a Method

Here's an example of using the Result<T> class:

public Result<int> Divide(int numerator, int denominator)
{
    if (denominator == 0)
    {
        return Result<int>.Failure("The denominator cannot be zero.");
    }
    return Result<int>.Success(numerator / denominator);
}

If the denominator is zero, an error message is returned instead of throwing an exception.

6.4 Handling Results

To check if an operation succeeded or failed:

var result = Divide(10, 0);

if (result.IsSuccess)
{
    Console.WriteLine("The result is: " + result.Value);
}
else
{
    Console.WriteLine("Error: " + result.Error);
}

This allows more flexible error handling and avoids interruptions.

7. Creating Custom Exceptions

7.1 Why Create Custom Exceptions?

Clarity: Custom exceptions provide clearer messages about what went wrong. For example, an InvalidUserInputException is more informative than a generic Exception.
Precision: They allow you to capture specific errors, making them easier to resolve.

7.2 How to Create a Custom Exception

To create a custom exception, define a new class that inherits from Exception:

public class MyCustomException : Exception
{
    public MyCustomException() { }

    public MyCustomException(string message)
        : base(message) { }

    public MyCustomException(string message, Exception innerException)
        : base(message, innerException) { }
}

Custom exceptions provide more details about errors and useful contextual information.

7.3 Converting Standard Exceptions to Custom Exceptions

Here's how to transform a standard exception into a custom exception:

try
{
    int result = 10 / divisor;
}
catch (DivideByZeroException ex)
{
    throw new MyCustomException("An error occurred during division because the divisor was zero.", ex);
}

Custom exceptions offer better context on errors, making them easier to resolve.

8. Best Practices for Custom Exceptions

8.1 Use Descriptive Names

Ensure the exception name is explicit and reflects the nature of the error. For example, InvalidUserInputException is more descriptive than MyException. A good name makes the code more readable and helps developers quickly understand the problem.

8.2 Avoid Unnecessary Exceptions

Don't create custom exceptions for every minor issue. Focus on exceptions that add real value and help differentiate important scenarios. Too many exceptions can make the code confusing and hard to maintain.

9. Final Recommendation: Limit the Use of Exceptions

It's recommended to limit the use of exceptions in an application because managing them is performance-intensive. Exceptions interrupt the normal program flow and trigger a series of handling and stack unwinding operations, which can be costly, especially when used in loops or for regular control flow.

Instead of systematically using exceptions, consider mechanisms like Result<T> to signal operational failures in methods and control flow. This avoids the overhead of exceptions while maintaining lighter and more performant control.

Example: Exception vs. Result Object

Here's a simple example comparing the use of an exception with a Result<T>:

Using an Exception

public int DivideWithException(int numerator, int denominator)
{
    if (denominator == 0)
    {
        throw new DivideByZeroException("The denominator cannot be zero.");
    }
    return numerator / denominator;
}

Using `Result<T>`

public Result<int> DivideWithResult(int numerator, int denominator)
{
    if (denominator == 0)
    {
        return Result<int>.Failure("The denominator cannot be zero.");
    }
    return Result<int>.Success(numerator / denominator);
}

By using Result<T>, we avoid the cost of an exception when the denominator is zero. The method simply returns a failure result, allowing the calling code to handle the failure without triggering a costly interruption.

Performance Benchmark: Exception vs. Result Object

A simple performance test was conducted using BenchmarkDotNet, with memory and CPU diagnostics enabled to accurately measure the difference between the two approaches. The benchmark code is configured with BenchmarkDotNet diagnosers, including MemoryDiagnoser, ThreadingDiagnoser, and EtwProfiler (specific to Windows for detailed CPU profiling).

Benchmark Code

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Diagnostics.Windows;
using BenchmarkDotNet.Running;
using System.Threading.Tasks;

[MemoryDiagnoser]
[ThreadingDiagnoser]
[EtwProfiler] // Usable only on Windows for detailed CPU profiling
public class ExceptionVsResultBenchmark
{
    [Benchmark]
    public void TestDivideWithException()
    {
        for (int i = 0; i < 1000; i++)
        {
            try
            {
                DivideWithException(10, i % 2 == 0 ? 1 : 0);
            }
            catch { }
        }
    }

    [Benchmark]
    public void TestDivideWithResult()
    {
        for (int i = 0; i < 1000; i++)
        {
            DivideWithResult(10, i % 2 == 0 ? 1 : 0);
        }
    }

    public int DivideWithException(int numerator, int denominator)
    {
        return denominator == 0 ? throw new DivideByZeroException() : numerator / denominator;
    }

    public Result<int> DivideWithResult(int numerator, int denominator)
    {
        return denominator == 0
            ? Result<int>.Failure("The denominator cannot be zero.")
            : Result<int>.Success(numerator / denominator);
    }
}

public class Result<T>
{
    public bool IsSuccess { get; }
    public T? Value { get; }
    public string? Error { get; }

    protected Result(bool isSuccess, T? value, string? error)
    {
        IsSuccess = isSuccess;
        Value = value;
        Error = error;
    }

    public static Result<T> Success(T value) => new Result<T>(true, value, null);
    public static Result<T> Failure(string error) => new Result<T>(false, default, error);
}

public class Program
{
    public static void Main(string[] args)
    {
        var summary = BenchmarkRunner.Run<ExceptionVsResultBenchmark>();
    }
}

Benchmark Results

Method	Mean	Error	StdDev	Gen0 Allocations	Allocated Memory
TestDivideWithException	1,734.131 μs	34.5458 μs	77.9755 μs	7.8125	109.38 KB
TestDivideWithResult	2.531 μs	0.0662 μs	0.1846 μs	2.4452	31.25 KB

Interpretation:

Exception Approach: Significantly higher execution time and memory allocation.
Result Object Approach: Much faster and uses less memory.

These results highlight the importance of limiting the use of exceptions to exceptional or unforeseen situations and favoring alternatives like Result<T> to signal errors more efficiently in code.