Improvements with hostPort and Proxy Protocol #421
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using hostPort, the ManageSieve port was not actually exposed — I believe this was simply forgotten in the template.
The second issue is that Proxy Protocol and publicly exposed ports do not necessarily require a Service. When using hostPort and deploying via DaemonSet, front.externalService can be disabled. I had to edit _helpers.tpl to account for this. The advantage of not using an externalService with an upstream Ingress Controller is that it avoids an unnecessary proxy layer.
The third issue occurs when using Proxy Protocol: by default, the chart outputs an error stating that ingress.realIpHeader should not have any value. However, with Proxy Protocol (which is likely the most common case when proxying TCP traffic), this field must indeed be left empty.
Additionally, I moved values that did not belong under ingress. to front..
These are breaking changes.