Managing Ingress

Overview

Fissile does not manage ingress by itself, not directly.

It only provides a variable usable in charts which when set is expected to activate ingress-related templating in the chart.

While the standard support for services.loadbalanced provided by fissile is not suppressed checks are added to misconfiguration, i.e. attempts to use both loadbalanced and ingress together.

API to role manifests

The new variable is named services.ingress.

Its default value is nil, expected to prevent any of ingress-related templating.

When set to a string, the existing machinery will disable externalIP like for loadbalanced operation, but keep service types at ClusterIP. Ingress is then responsible for proper load balancing.

The chart derived from the role manifest is expected to activate all its resources related to ingress, i.e. ingress resource itself, and possibly related secrets (holding TLS certificates).

Note that none of the ingress resources will be generated by fissile. It is expected that the developer will add suitable definitions to the resources and templates generated by fissile.

Attempting to use both loadbalanced and ingress together is checked for in the generated chart and will be reported via a rendering failure.

API to operators

An operator wishing to use ingress for a chart C supporting such has to set the variable services.ingress to the name of the controller it wants to take responsibility for the ingress resources of C.

The NGINX Ingress Controller for example reacts to the name 'nginx'.

Note that depending on the nature of the resources in C the operator may have to perform additional commands, for example to properly set up secrets with required TLS certificates and the like. The developer of C will have to provide the instructions for that, this is even further outside the scope of fissile's support for ingress.

Example

To put all of the previous into perspective here a larger example, based on SUSE CAP, aka SCF.

CAP currently consists of two charts, one for SCF, the other for UAA.

To support ingress a third chart will be required, to deploy some ingress controller. The developers of CAP may provide an example chart and controller, or not. Regardless, the user (operator) of CAP will be free to choose their own controller.

As both SCF and UAA have services to expose via ingress each of their charts will be extended with ingress resources. As both of the services use TLS to secure communications the ingress resources include a secret (per chart) which declares the necessary TLS certificates.

Below is the template containing the ingress resources for SCF. Of note

• The entire template is guarded by if .Values.services.ingress. This disables the template if ingress is not activated by the operator (default).

• The TLS certificate and key properties of the secret are empty. The current system for deployment is not able to fill these automatically. This means that the chart will have to come with instructions/steps/commands explaining how to fill these during the deployment of CAP, if ingress is chosen.

• The references to .Values.env.DOMAIN are to a property of the SCF chart. Information like this and others, which are not available through the role manifest, is the main reason for why fissile does not attempt to generate ingress resources from a role manifest, but delegates this to the chart developer.

• Also, given that CAP deploys two charts whose components talk to each other the instructions will have to talk about setting up DNS for the ingress endpoint.

• Both of these things are what the last paragraph in the refers to, chart-specific instructions wholly outside of what fissile can do for ingress.

{{- if .Values.services.ingress }}
---
apiVersion: "v1"
kind: "Secret"
type: kubernetes.io/tls
metadata:
  name: "{{ .Release.Namespace }}-secrets-nic"
data:
  tls.crt: ""
  tls.key: ""
---
# This ingress specifies routing and access for the cloud controller
# public SCF service, i.e. "api.<domain>" and other services in that
# domain hierarchy.
#
# Note that the two other services (tcp routing, app ssh access) are
# not suitable to routing via http, and not specified. IOW they are
# TCP, which is not supported by the current ingress specification.
# Although specific controllers may do so in a custom manner.

apiVersion: "extensions/v1beta1"
kind: "Ingress"
metadata:
  name: "ingress-scf"
  namespace: {{ .Release.Namespace | quote }}
  annotations:
    nginx.ingress.kubernetes.io/secure-backends: "true"
    kubernetes.io/ingress.class: {{ .Values.services.ingress }}
spec:
  tls:
  - secretName: "{{ .Release.Namespace }}-secrets-nic"
    hosts:
    - "*.{{ .Values.env.DOMAIN }}"
    - "{{ .Values.env.DOMAIN }}"
  rules:
    - host: "*.{{ .Values.env.DOMAIN }}"
      http:
        paths:
          - path: "/"
            backend:
              serviceName: "router-gorouter-public"
              servicePort: 443
    - host: "{{ .Values.env.DOMAIN }}"
      http:
        paths:
          - path: "/"
            backend:
              serviceName: "router-gorouter-public"
              servicePort: 443
{{- end }}