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

max connection annotations not being taken into account with extension services for external authorization #6307

Open
codymoss-bnet opened this issue Mar 28, 2024 · 2 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor.

Comments

@codymoss-bnet
Copy link

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

  1. Followed guide: https://projectcontour.io/docs/1.28/guides/external-authorization/ to get an external auth setup
  2. Alter the service projectcontour-auth/htpasswd to have annotations
annotations:
    projectcontour.io/max-connections: "8192"
    projectcontour.io/max-pending-requests: "8192"
    projectcontour.io/max-requests: "8192"
  1. Run the following commands to expose envoy admin api
ENVOY_POD=$(kubectl -n projectcontour get pod -l app=envoy -o name | head -1)
kubectl -n projectcontour port-forward $ENVOY_POD 9001
  1. In another terminal window check extension service is now set to 8192 via api call curl http://localhost:9001/clusters

After checking though I see extension service is still set to 1024 for max_connections, max_pending_requests, and max_requests.

What did you expect to happen:

I expected for the annotations to function like http proxy services and be picked up and changed in the envoy clusters

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

I went through the guide to have a repeatable pattern. I tested via my local rancher-desktop cluster but I saw the same result with contour 1.25 on an EKS cluster running 1.26.x.

Let me know if you need anymore info.

Environment:

  • Contour version: 1.28
  • Kubernetes version: (use kubectl version):
Client Version: v1.29.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.7+k3s1
  • Kubernetes installer & version: rancher-desktop v1.13.1
  • Cloud provider or hardware configuration: Mac os M1
  • OS (e.g. from /etc/os-release): Senoma 4.4.1 (23E224)
@codymoss-bnet codymoss-bnet added kind/bug Categorizes issue or PR as related to a bug. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. labels Mar 28, 2024
Copy link

Hey @codymoss-bnet! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

Copy link

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

  • Mark this Issue as fresh by commenting
  • Close this Issue
  • Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 29, 2024
@sunjayBhatia sunjayBhatia removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor.
Projects
None yet
Development

No branches or pull requests

2 participants