Understanding Kubernetes Default Ingress Class

Table of Contents

1. Core Concepts
2. Typical Usage Example
3. Common Practices
4. Best Practices
5. Conclusion
6. References

Core Concepts

Ingress and Ingress Controllers

An Ingress is an API object that manages external access to the services in a Kubernetes cluster, typically HTTP. It allows you to consolidate your routing rules into a single resource. An Ingress controller, on the other hand, is a daemon that watches the Ingress resources and configures an HTTP load balancer accordingly. Popular ingress controllers include Nginx Ingress Controller, Traefik, and HAProxy Ingress.

Ingress Classes

Kubernetes introduced the IngressClass resource in version 1.18 to provide a way to configure different ingress controllers in a cluster. An IngressClass object defines a class of ingress controllers, and an Ingress resource can specify which IngressClass it belongs to using the kubernetes.io/ingress.class annotation or the spec.ingressClassName field.

Default Ingress Class

A default ingress class is an IngressClass that is marked as the default for the cluster. When an Ingress resource is created without specifying an IngressClass, it will be automatically associated with the default IngressClass. To mark an IngressClass as the default, you need to add the ingressclass.kubernetes.io/is-default-class annotation with a value of true.

Typical Usage Example

Let’s assume you have a Kubernetes cluster with the Nginx Ingress Controller installed. You want to set the Nginx Ingress Controller as the default ingress class and create an Ingress resource without specifying the class explicitly.

Step 1: Create the IngressClass

First, create an IngressClass object for the Nginx Ingress Controller and mark it as the default:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-nginx

Apply this configuration using kubectl apply -f ingressclass.yaml.

Step 2: Create a Service

Create a simple service and deployment:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: nginx:1.14.2
          ports:
            - containerPort: 8080

Apply this configuration using kubectl apply -f service-deployment.yaml.

Step 3: Create an Ingress Resource

Create an Ingress resource without specifying the IngressClass:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Apply this configuration using kubectl apply -f ingress.yaml. Since the Nginx IngressClass is marked as the default, this Ingress resource will be processed by the Nginx Ingress Controller.

Common Practices

Multiple Ingress Controllers

In a production environment, you may have multiple ingress controllers deployed for different purposes. For example, you may use the Nginx Ingress Controller for HTTP traffic and the Traefik Ingress Controller for internal microservices. In such cases, it’s important to clearly define the default ingress class and use explicit IngressClass specifications for non - default ingress controllers.

Monitoring and Logging

Set up monitoring and logging for your ingress controllers. Most ingress controllers provide metrics and logs that can be used to troubleshoot issues and monitor the health of your application. Tools like Prometheus and Grafana can be used to collect and visualize these metrics.

Security

Ensure that your ingress controllers are properly secured. This includes using TLS encryption for all incoming traffic, configuring access control lists, and keeping your ingress controllers up - to - date with the latest security patches.

Best Practices

Use Explicit Ingress Classes

Although a default ingress class simplifies the creation of Ingress resources, it’s a good practice to use explicit IngressClass specifications in your Ingress resources. This makes your configuration more readable and less error - prone, especially in a cluster with multiple ingress controllers.

Version Control

Keep your Kubernetes manifests, including IngressClass and Ingress resources, under version control. This allows you to track changes, collaborate with other developers, and roll back to previous versions if necessary.

Testing

Before deploying changes to your production environment, test your Ingress configurations in a staging or development environment. This helps to catch any issues early and ensures that your application works as expected.

Conclusion

The Kubernetes default ingress class is a powerful feature that simplifies the management of external access to applications in a cluster. By understanding the core concepts, following typical usage examples, adopting common practices, and implementing best practices, you can effectively use the default ingress class to manage your ingress resources. Remember to use explicit IngressClass specifications, keep your configurations under version control, and test your changes before deploying them to production.

References

• Kubernetes Documentation: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class
• Nginx Ingress Controller Documentation: https://kubernetes.github.io/ingress-nginx/
• Traefik Ingress Controller Documentation: https://doc.traefik.io/traefik/providers/kubernetes-ingress/

• ←Previous
• Next→