a714fb69db
<!--- Provide a general summary of your changes in the Title above --->
<!--- Why is this change required? What problem does it solve? -->
Introduces the CLI command flag `--disable-full-test`
By default, it doesn't alter the current behavior of the tests performed by the admission controller.
With or Without the flag, a full checkOverlap is actioned, without any alteration
and the object `pcfg` is created with the whole set of ingreses.
If the flag is set to true, it does manipulate the size of `pcfg` up to the content of $this single ingress.
This is achieved by overriding pcfg content by just the last slice that got recently appended to the object `ings`
```
if n.cfg.DisableFullValidationTest {
_, _, pcfg = n.getConfiguration(ings[len(ings)-1:])
}
```
The following steps of generateTemplate and testTemplate are significally reduced to a signle scenario
```
content, err := n.generateTemplate(cfg, *pcfg)
...
err = n.testTemplate(content)
```
This flag doesn't avoid the proper testing of collisions, neither bad syntaxis within the rendered
configuration of the ingress.
But it does eliminate a scenario, which I wasn't able to produce, where by for some reason even proper rendering
and valid values, without collisions of host/path may end into an invalid nginx.conf
The reasoning for this Feature is:
- Test duration increases by the number of ingresses in the cluster.
- File size grows to very important numbers 150-200Mb on clusters with just 2000~ ingresses.
- Tests in that scenario, takes approximately 20s using the last 0.48.1 improvements
- Produces a considerable memory consumption, as well as CPU, compute, that affects directly the containers
that serve traffic.
Since the flag is trully optional, and by default is disabled I fell as a good thing to have that can definitively
help on large-scale scenarios that still want to have a reasonable set of tests in place at a lower cost.
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Tested with the build kit the following scenarios on a cluster with 1000~ ingresses:
- With Flag Disabled or Flag, not present (current status as per 0.48.1)
collision scenario (wrong snippet content):
`kubectl apply -f ../collision-syntax.yaml 0.18s user 0.05s system 3% cpu 6.639 total`
collisions scenario (duplicated host):
`kubectl apply -f ../collision-host.yaml 0.17s user 0.05s system 3% cpu 6.245 total`
create/update:
`kubectl apply -f ing-215.yaml 0.16s user 0.05s system 3% cpu 5.845 total`
- With Flag Enabled (true):
collision scenario (wrong snippet content):
`kubectl apply -f ../collision.yaml 0.18s user 0.02s system 57% cpu 0.347 total`
collision scenario (duplicated host):
`kubectl apply -f ../collision.yaml 0.21s user 0.06s system 85% cpu 0.318 total`
create/update:
`kubectl apply -f ing-973.yaml 0.17s user 0.03s system 72% cpu 0.271 total`
As part of the test, I did verified that the created nginx for the test was of a smaller size, and that it didnt affect negatively the final nginx.conf (of a much larger side) where this was merged by the next steps in place after the validation. I couldn't observe any other change in the behaviour and so far the routine looks simple and non harmful.
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I've read the [CONTRIBUTION](https://github.com/kubernetes/ingress-nginx/blob/main/CONTRIBUTING.md) guide
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
For the test part, I would need to understand the placement and test case that this would require, I wasn't able to see an existing scenario for this
|
||
|---|---|---|
| .github | ||
| build | ||
| charts/ingress-nginx | ||
| cmd | ||
| deploy | ||
| docs | ||
| hack | ||
| images | ||
| internal | ||
| rootfs | ||
| test | ||
| version | ||
| .codecov.yml | ||
| .gitignore | ||
| .luacheckrc | ||
| Changelog.md | ||
| cloudbuild.yaml | ||
| code-of-conduct.md | ||
| CONTRIBUTING.md | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| mkdocs.yml | ||
| OWNERS | ||
| OWNERS_ALIASES | ||
| README.md | ||
| RELEASE.md | ||
| SECURITY.md | ||
| SECURITY_CONTACTS | ||
| stable.txt | ||
| TAG | ||
NGINX Ingress Controller
Overview
ingress-nginx is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
Learn more about Ingress on the main Kubernetes documentation site.
Get started
See the Getting Started document.
Troubleshooting
If you encounter issues, review the troubleshooting docs, file an issue, or talk to us on the #ingress-nginx channel on the Kubernetes Slack server.
Changelog
See the list of releases to find out about feature changes.
For detailed changes for each release; please check the Changelog.md file.
For detailed changes on the ingress-nginx helm chart, please check the following CHANGELOG.md file.
Support Versions table
| Ingress-nginx version | k8s supported version | Alpine Version | Nginx Version |
|---|---|---|---|
| v1.0.0 | 1.22, 1.21, 1.20, 1.19 | 3.13.5 | 1.20.1 |
| v0.49.0 | 1.21, 1.20, 1.19 | 3.13.5 | 1.20.1 |
| v0.48.1 | 1.21, 1.20, 1.19 | 3.13.5 | 1.20.1 |
| v0.47.0 | 1.21, 1.20, 1.19 | 3.13.5 | 1.20.1 |
| v0.46.0 | 1.21, 1.20, 1.19 | 3.13.2 | 1.19.6 |
Get Involved
Thanks for taking the time to join our community and start contributing!
-
This project adheres to the Kubernetes Community Code of Conduct. By participating in this project, you agree to abide by its terms.
-
Contributing: Contributions of all kind are welcome!
-
Read
CONTRIBUTING.mdfor information about setting up your environment, the workflow that we expect, and instructions on the developer certificate of origin that we require. -
Check out the open issues, especially help-wanted ones.
-
Join our Kubernetes Slack channel for developer discussion : #ingress-nginx-dev.
-
Submit github issues for any feature enhancements, bugs or documentation problems. Please make sure to read the Issue Reporting Checklist before opening an issue. Issues not conforming to the guidelines may be closed immediately.
-
-
Support: Join the the #ingress-nginx-users channel inside the Kubernetes Slack to ask questions or get support from the maintainers and other users.
- The github issues in the repository are exclusively for bug reports and feature requests.
-
Discuss: Tweet using the
#IngressNginxhashtag.