* fix Ingress resources in docs
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* move to ingressClassName
* fix more Ingress resource examples
* empty commit
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* make NOTES.txt aware of version + add notice about ingress version to examples main page
* add link to legacy documentation
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* move generic instructions to the beginning of the file
* add an example of ingress resource creation
* simplify a few commands to make them shorter and simpler
* add short paragraphs about PROXY protocol and traffic policy
This tries to address the concerns I expressed in #7701.
* Add Initial support for multiple cors origins in nginx
- bump cluster version for `make dev-env`
- add buildOriginRegex function in nginx.tmpl
- add e2e 4 e2e tests for cors.go
- refers to feature request #5496
* add tests + use search to identify '*' origin
* add tests + use search to identify '*' origin
Signed-off-by: Christopher Larivière <lariviere.c@gmail.com>
* fix "should enable cors test" looking at improper values
* Modify tests and add some logic for origin validation
- add origin validation in cors ingress annotations
- add extra tests to validate regex
- properly escape regex using "QuoteMeta"
- fix some copy/paste errors
* add TrimSpace and length validation before adding a new origin
* modify documentation for cors and remove dangling comment
* add support for optional port mapping on origin
* support single-level wildcard subdomains + tests
* Remove automatic `*` fonctionality from incorrect origins
- use []string instead of basic string to avoid reparsing in template.go
- fix typo in docs
- modify template to properly enable only if the whole block is enabled
- modify cors parsing
- test properly by validating that the value returned is the proper
origin
- update unit tests and annotation tests
* Re-add `*` when no cors origins are supplied + fix tests
- fix e2e tests to allow for `*`
- re-add `*` to cors parsing if trimmed cors-allow-origin is empty
(supplied but empty) and if it wasn't supplied at all.
* remove unecessary logic for building cors origin + remove comments
- add some edge cases in e2e tests
- rework logic for building cors origin
there was no need for logic in template.go for buildCorsOriginRegex
if there is a `*` it ill be short-circuited by first if.
if it's a wildcard domain or any domain (without a wildcard), it MUST
match the main/cors.go regex format.
if there's a star in a wildcard domain, it must be replaced with
`[A-Za-z0-9]+`
* add missing check in e2e tests
Small text format changes to section "I have more than one controller running in my cluster, and I want to use the new spec?" to allow for better readability.
Proposal to add information to Helm Installation
I can into an issue recently which cost me the better part of an afternoon and evening. The only information about some changes, I was not aware of, was in this blog post about improvements in 1.18.
The information about the errors I was receiving lead me to dead ends prior to finding that blog post. `IngressClass` and `ingressClassName` are thrown around a lot and it can be confusing but it helped me to eventually find a solution.
I kept getting `Error: rendered manifests contain a resource that already exists. Unable to continue with install: IngressClass "nginx" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata ...` and could not figure out how to fix it.
I believe adding the proposed changes, or a version of them, would help eliminate that frustration I experienced for other users that may run into these issues.
Since kube-lego has not been maintained in quite a while,
I thought it would be best to remove the documentation about it
and replace it with information about cert-manager.
* added another documentation example
* added end of file newline
* Revert "added end of file newline"
This reverts commit 2d196ffba3.
* added another documentation example
* Fix old tag of custom error pages used in example
* Move nginx-errors to k8s registry
Since the setup for the custom-error-messages was really different from
the other images that are build using cloudbuild, I changed it to "fit
in better"
* Use Go version 1.17 for custom-error-pages
Since Go >= 1.16 required the use of modules, I also initialized the module using the name k8s.io/ingress-nginx/custom-error-pages
It is possible to change this behavior on an ingress level, which works
well when you only have a few of them. When running several dozen
ingress and with a high change rate of running pods it makes it easier
to define this configuration on a global level.
This change is completely backwards compatible, only adding the
possibility of defining a new key in the configmap.
<!--- 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
