Add support to multiple match types

[jcmoraisjr]

Refactor in the HAProxy's frontend map builder to allow new match types.

The supported types are:

• Begin: case insensitive check of the start of the path, where /api matches /api/v1 and also /apiv1. This is the current behavior.
• Exact: case sensitive check of the full path.
• Prefix: case sensitive check of the start of the path, where /api matches /api/v1 but does not match /apiv1.
• Regex: case sensitive check of the path using an extended regular expression.

Begin, Exact and Prefix are configurable via k8s 1.18 ingress spec, which defaults to Begin. All of them are configurable via annotation. The ingress spec configuration has precedence over annotation config in the case of a conflict.

Tasks:

• Cleanup map config
• Refactor frontend map builder
• Implement new match types - Exact and Prefix
• Implement pathType (from k8s 1.18 spec) and path-type annotation
• Implement crt-list builder - remove Empty match type
• Ignore maps without content - remove from the cfg and do not create the file
• Exploratory tests
• Docs

[sergiimk]

Hi @jcmoraisjr, I have a question related to this PR if you don't mind:

We started using haproxy-ingress around February when we ran into missing support for regex matching and had to implement solution I shared in #551.

That solution allowed us to create multiple deployments of the same service and route traffic based on URLs to one or another such deployment.

For example if we have my-service application we would create deployments like:

• my-service-foobar
• my-service-baz
• my-service-default
  ... where foobar and baz groups would handle traffic only for some URLs configured via three different Ingress objects with rules like:

# "foo-bar" ingress
# handles /v1/foo/ and /v1/bar/
---
  rules:
  - host: my-service.kube.example.net
    http:
      paths:
      - backend:
          serviceName: my-service-foobar
          servicePort: http
        path: /v[0-9]+/(foo|bar)/

# "baz" ingress
# handles /v1/baz/
---
  rules:
  - host: my-service.kube.example.net
    http:
      paths:
      - backend:
          serviceName: my-service-baz
          servicePort: http
        path: /v[0-9]+/baz/

# "default" ingress
# handles all other paths
---
  rules:
  - host: my-service.kube.example.net
    http:
      paths:
      - backend:
          serviceName: my-service-default
          servicePort: http
        path: /

Note that all three ingresses are using the same host, so we relied on haproxy-ingress to merge the rules together for us.

Yesterday I have rebased #551 onto latest master and I noticed that this merging behaviour seems to be gone now. Instead of having multiple host-paths in the /etc/haproxy/maps/_global_http_front_regex.map controller only uses the first ingress it discovered for this host.

My question is:

• Is this behavior expected
• Is support for such merging coming back in this PR, or you think merging multiple Ingress objects with the same host was invalid behavior and we shouldn't have relied on it?

[jcmoraisjr]

Hi, merging distinct paths from distinct ingress objects and sharing the same hostname is a supported feature and will continue to be. I'll tag a new snapshot within the next few days, as soon as this PR is merged. If you find this functionality broken please file a new issue with reproducible steps.