Addon: Ingress

This addon adds a Traefik Ingress Controller for MicroK8s. It is enabled by running the command:

microk8s enable ingress

Note: Starting with MicroK8s 1.35, the ingress addon uses Traefik as the default ingress controller. Prior versions (< 1.35) used NGINX Ingress Controller. Existing Ingress resources with ingressClassName: nginx will continue to work. See the Backward Compatibility section for details.

Options

The addon supports the following options:

  • -V VERSION - Traefik Helm chart version
  • -r REPOSITORY - Traefik Helm chart repository
  • -g GW_VERSION - Gateway API CRD version
  • --default-ssl-certificate NAMESPACE/NAME - Kubernetes TLS Secret to use as Traefik’s default TLS certificate

Creating Ingress Resources

With the Ingress addon enabled, HTTP/HTTPS ingress rules can be created with an Ingress resource. The addon provides three IngressClass options:

  • public (default) - backward compatible with the previous NGINX setup
  • traefik - standard Traefik ingress class
  • nginx - for users migrating from nginx-based ingress resources

For example:

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

Gateway API Support

The addon also includes Gateway API support. You can create HTTPRoute resources for modern routing:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: traefik-gateway
    namespace: ingress
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: some-service
      port: 80

Configuring Default TLS Certificate

To set a default TLS certificate for all HTTPS traffic:

microk8s enable ingress --default-ssl-certificate my-namespace/my-tls-secret

Backward Compatibility

Users migrating from the previous NGINX-based ingress addon can continue using their existing Ingress resources. The addon includes:

  • An nginx IngressClass that routes through Traefik
  • Support for common NGINX ingress annotations via the kubernetesIngressNginx provider

If you encounter unexpected behavior with ingress routing, restarting the addon may resolve the issue:

microk8s disable ingress
microk8s enable ingress

Disabling the Addon

To disable the ingress addon:

microk8s disable ingress

This will remove Traefik, Gateway API CRDs, and clean up any legacy NGINX ingress resources.

Wondering what will be recommended way to have microk8s service multiple wildcard https subdomains, e.g. *.dev.contoso.com, *.stage.contoso.com

At moment it seems to be impossible without heavily changing internals

We recently merged a PR [1] that would allow you to set the default-ssl-certificate [2] via a secret while enabling the ingress add-on:

microk8s enable ingress:default-ssl-certificate=namespace/secret_name

This work is on latest/edge and will be officially out with the 1.19 release.

[1] https://github.com/ubuntu/microk8s/pull/1231
[2] https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-ssl-certificate

1 Like

Yes but this one going to work only if we have single wildcard certificate per cluster, e.g. if I have *.dev.contoso.com indeed I can use it as default one with proposed default-ssl-certificate setting which is awesome and at least solves half of problem

The problem still persists if cluster is serving multiple wildcard domains, e.g. *.dev.contoso.com, *.stage.contoso.com - we can not use any of them as deafult cert

So at moment it seems that the easiest way will be ho have N clusters where N is number of wildcard certificates or hack ingress

[REQUEST] Will you please add the name and namespace of Ingress’s ConfigMap to the document?

I finally found that name nginx-load-balancer-microk8s-conf though. If the name appeared on the document, we wouldn’t have to look for the command line options of the controller.

1 Like

Hello Team,

Using the code provided in the document results in the below error:


kubectl apply -f ingress.yaml
Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
ingress.networking.k8s.io/http-ingress configured


If we change the Ingress to “networking.k8s.io/v1” it results in the below error:


kubectl apply -f ingress.yaml
error: error validating “ingress.yaml”: error validating data: [ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field “serviceName” in io.k8s.api.networking.v1.IngressBackend, ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field “servicePort” in io.k8s.api.networking.v1.IngressBackend]; if you choose to ignore these errors, turn validation off with --validate=false


What should the correct documentation for Ingress be referred too??

Thank you,
Anish

Hi, currently the nginx ingress doesn’t support the v1 networking api.

The networking.k8s.io/v1 has some breaking changes to the manifest. It is not just changing the version. We also need to upgrade the ingress controller.

For now refer to the 1.18 ingress documentation.

Apologies for any confusion.

How do we apply this to already enabled ingress? Do we have to disable and enable again with the option?

Any way to use let’s encrypt certbot to renew certs with microk8s ingress?
Can microk8s ingress redirect port 80 to 443 ?

Can regular nginx in a pod route to clusterIP address or is there something that would make this not work?

Is the code for

image: Google Cloud console

open source?
Where can I find this code or documentation? I’m looking the github repo for microk8s and looks to me this consumes the configmap? is this

Installation Guide - Ingress-Nginx Controller

Yes microk8s uses the nginx ingress.

Hi @John_Grabner

The ingress controller should be in https://github.com/kubernetes/ingress-nginx

The ingress manifest we use in MicroK8s is in https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/actions/ingress.yaml

I encountered many examples that used an ingress.class: nginx annotation as shown below:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx

Since this page states that it’s a nginx ingress, the above seemed appropriate to include in resource definitions. However, the ingress.class of the controller created by this addon is actually public.

Should we add a kubernetes.io/ingress.class: public annotation to the example to clarify this, and document this in the page text?

1 Like

How can I deploy a second nginx ingress controller to microk8s? I need one controller to serve private intranet traffic and the other to serve public traffic.

this should be right

thanks, will test that out

networking.k8s.io/v1 is now supported with nginx, and should be updated in the docs.

Also a useful example would be showing how to ingress the dashboard:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: kube-system
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/configuration-snippet: |-
      proxy_ssl_server_name on;
      proxy_ssl_name $host;
  name: dashboard
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubernetes-dashboard
            port:
              number: 443
4 Likes

Hello,

is there a reason why the ingressClass name was changed to ‘public’ compared to ‘nginx’ in the upstream helm chart?

I tried to install the cert-manager and usually that’s a quick task but due to the me unknown ingressClass name it took hours. Maybe this should be mentioned on the Ingress add-on docs page.

Best
Tom

1 Like

Hi Tom,
I found out there is a new resource definition for and this makes sense:

Hope this helps.

Cheers

Guido

I know about the IngressClass resource, but what I am wondering about is why the name got changed to ‘public’ compared to ‘nginx’ in the upstream helm chart of the nginx IngressController. It is nowhere mentioned and unfortunately I did not expect it to be changed, so I tried to set up the cert-manager with ‘nginx’ as the ingessClass name - which of course failed without any error message and so it wasn’t trivial for me to fix the issue.