Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apps wc: Fixed network policy to always allow ingress probe #2284

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Xartos
Copy link
Contributor

@Xartos Xartos commented Sep 18, 2024

Warning

This is a public repository, ensure not to disclose:

  • personal data beyond what is necessary for interacting with this pull request, nor
  • business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

  • kind/feature
  • kind/improvement
  • kind/deprecation
  • kind/documentation
  • kind/clean-up
  • kind/bug
  • kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

  • kind/admin-change
  • kind/dev-change
  • kind/security
  • kind/adr

What does this PR do / why do we need this PR?

...

  • Fixes #

Information to reviewers

On clusters that didn't use host port for nginx, the ingress to nginx health didn't always work (If the request was bounced between nodes). This fixes that.

Checklist

  • Proper commit message prefix on all commits
  • Change checks:
    • The change is transparent
    • The change is disruptive
    • The change requires no migration steps
    • The change requires migration steps
    • The change upgrades CRDs
    • The change updates the config and the schema
  • Documentation checks:
  • Metrics checks:
    • The metrics are still exposed and present in Grafana after the change
    • The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
    • The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
  • Logs checks:
    • The logs do not show any errors after the change
  • Pod Security Policy checks:
    • Any changed pod is covered by Pod Security Admission
    • Any changed pod is covered by Gatekeeper Pod Security Policies
    • The change does not cause any pods to be blocked by Pod Security Admission or Policies
  • Network Policy checks:
    • Any changed pod is covered by Network Policies
    • The change does not cause any dropped packets in the NetworkPolicy Dashboard
  • Audit checks:
    • The change does not cause any unnecessary Kubernetes audit events
    • The change requires changes to Kubernetes audit policy
  • Falco checks:
    • The change does not cause any alerts to be generated by Falco
  • Bug checks:
    • The bug fix is covered by regression tests

@simonklb
Copy link
Contributor

Could you explain why this is only needed for the workload cluster? I would have assumed that the ingress healthcheck is done the same way for both clusters?

@Zash
Copy link
Contributor

Zash commented Sep 26, 2024

Is this related to the sc→wc probes?

@Xartos
Copy link
Contributor Author

Xartos commented Sep 27, 2024

Could you explain why this is only needed for the workload cluster? I would have assumed that the ingress healthcheck is done the same way for both clusters?

As @Zash mentions, this is for the sc -> wc probes. So when we use the "new" ingress-nignx.<base-domain> the request will be reverse-proxied and sent to the ingress-nginx service and will be LBd between the endpoints. So from networkpolicys point of view it's sent from the controller pod to itself more or less

Copy link
Contributor

@simonklb simonklb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Talked offline. I was worried that this would make us miss unnecessary extra hops inside the cluster for ingress traffic. This actually seem to already be the case because we do not make use externalTrafficPolicy: "Local" which we likely should be able to (since the external loadbalancers should only target nodes that runs the ingress-nginx controller).

I'm fine with merging this now but I'd like this to be removed if we are able to use externalTrafficPolicy: "Local" instead to prevent in-cluster routing for ingress traffic. Maybe add a TODO comment to re-evaluate this?

@Xartos
Copy link
Contributor Author

Xartos commented Oct 4, 2024

@simonklb Is this fine 38ab1e1 ? Then we support both

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants