add support for TLS route

[sarthyparty]

Proposed changes

Problem: TLSRoute was not supported by NGF.

Solution: Watched for changes to TLSRoutes, added validation and tests, added TLSRoute to graph, and converted Kubernetes TLSRoute spec to nginx config.

Testing: Full code coverage to all code added and enabled one of the TLS Passthrough tests.

Closes #686

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.

[sarthyparty]

@pleshakov @kate-osborn

Is there a need for separate nginx servers for each hostname? For example, if the graph has a L4Route with hostnames "app.example.com" and "cafe.example.com", the code will currently create a map and two nginx servers like this:

map {
    app.example.com app.example.com443.sock
    cafe.example.com cafe.example.com443.sock
}

server {
    listen app.example.com443.sock
    proxy_pass upstream_1
}

server {
    listen cafe.example.com443.sock
    proxy_pass upstream_1
}

Rather it might be better to do it like this

map {
    app.example.com upstream_1.sock
    cafe.example.com upstream_1.sock
}

server {
    listen upstream_1.sock
    proxy_pass upstream_1
}

[pleshakov]

@sarthyparty

having separate servers will help with handling edge cases like below.

Let's say an application developer creates this TLSRoute:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name:  first
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - app.example.com
  rules:
  - backendRefs:
    - name: my-backend-1
      port: 443

Another application developer creates this TLSRoute after the first one was created:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name:  second
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - app.example.com
  - cafe.example.com
  rules:
  - backendRefs:
    - name: my-backend-2
      port: 443

Based on this https://gateway-api.sigs.k8s.io/guides/api-design/#conflicts,

NGF needs to be configured
app.example.com -> my-backend-1
cafe.example.com -> my-backend-2

Having a server per hostname makes handling this edge case easy

[sarthyparty]

thanks!

[kate-osborn]

@sarthyparty

having separate servers will help with handling edge cases like below.

Let's say an application developer creates this TLSRoute:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name:  first
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - app.example.com
  rules:
  - backendRefs:
    - name: my-backend-1
      port: 443

Another application developer creates this TLSRoute after the first one was created:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name:  first
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - app.example.com
  - cafe.example.com
  rules:
  - backendRefs:
    - name: my-backend-2
      port: 443

Based on this https://gateway-api.sigs.k8s.io/guides/api-design/#conflicts,

NGF needs to be configured app.example.com -> my-backend-1 cafe.example.com -> my-backend-2

Having a server per hostname makes handling this edge case easy

@pleshakov I'm assuming the second TLSRoute in this example would be created with a different name? Otherwise, the second TLSRoute would just update the first...

[pleshakov]

@kate-osborn

@pleshakov I'm assuming the second TLSRoute in this example would be created with a different name? Otherwise, the second TLSRoute would just update the first...

good catch. updated

[kate-osborn]

@sarthyparty can you also add a test case, or modify an existing test case, to TestBuildConfiguration? Anytime we modify the BuildConfiguration function, we update or add to TestBuildConfiguration. This ensures that we don't have any regressions when we add something new to the config.

[sjberman]

I'm guessing the feature/tls-passthrough branch probably needs to be rebased on main if it hasn't recently, but does this work account for the fix in #2314 to ensure TLSRoutes are considered as well?

[kate-osborn]

I'm guessing the feature/tls-passthrough branch probably needs to be rebased on main if it hasn't recently, but does this work account for the fix in #2314 to ensure TLSRoutes are considered as well?

It will after the rebase and some additional work. @sarthyparty is working on that now

[sjberman]

Before merging, can we give this PR a better title? Focus on the fact that it's related to TLSRoute

[kate-osborn]

Before merging, can we give this PR a better title? Focus on the fact that it's related to TLSRoute

Yep, but keep in mind this is just going to be merged to the feature branch.

[kate-osborn]

leaving a partial review

[kate-osborn]

Just a few more test changes

[kate-osborn]

🚀 🚀

[sindhushiv]

Good Work @sarthyparty

[bjee19]

🚀 🚀 🎉 🎉