* The name can't use _(underscore)! So fix it!
The name can't use _(underscore)! So fix it!
* Fix configMap name can't use _(underscore)
Fix configMap name can't use _(underscore)
The annotation for the controller class was inconsistent in the example. From my best understanding, I have tried to fix the inconsistency.
Also, removed an incomplete sentence. And made one sentence more clear by breaking it up.
* add explanation about ingressClassResource.default for helm users
Also cleaned up the entire "I have only one instance of the
Ingress-NGINX controller in my cluster" section
* docs: default ingressclass only when running one controller
* fix link to what is the flag watch ingress
* clarify usage of default ingress class annotation
* regenerate at 4.0.12
* bash for loop and static values files
* add .tool-versions
* fixup static manifests with kustomize instead of python
* remove spec.replicas where set
* generate manifests for all supported versions
* update docs
* remove all versions except default (1.20) for now
* update to 1.1.1/4.0.15
* clarify link
* Add section headers
* console blocks
* grpc example json was not valid
* multi-tls update text
The preceding point 1 related to 4f2cb51ef8/ingress/controllers/nginx/examples/ingress.yaml
and the deployments referenced in 4f2cb51ef8/ingress/controllers/nginx/examples/README.md
They are not relevant to the current instructions.
* add whitespace around parens
* grammar
setup would be a proper noun, but it is not the intended concept, which is a state
* grammar
* is-only
* via
* Use bullets for choices
* ingress-controller
nginx is a distinct brand.
generally this repo talks about ingress-controller, although it is quite inconsistent about how...
* drop stray paren
* OAuth is a brand and needs an article here
also GitHub is a brand
* Indent text under numbered lists
* use e.g.
* Document that customer header config maps changes do not trigger updates
This should be removed if
https://github.com/kubernetes/ingress-nginx/issues/5238
is fixed.
* article
* period
* infinitive verb + period
* clarify that the gRPC server is responsible for listening for TCP traffic and not some other part of the backend application
* avoid using ; and reword
* whitespace
* brand: gRPC
* only-does is the right form
`for` adds nothing here
* spelling: GitHub
* punctuation
`;` is generally not the right punctuation...
* drop stray `to`
* sentence
* backticks
* fix link
* Improve readability of compare/vs
* Renumber list
* punctuation
* Favor Ingress-NGINX and Ingress NGINX
* Simplify custom header restart text
* Undo typo damage
Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
* Added docs for --ingress-class-by-name flag in the cli arguments page
Signed-off-by: bhumijgupta <bhumijgupta@gmail.com>
* Updated docs to match the flag description in code
Signed-off-by: bhumijgupta <bhumijgupta@gmail.com>
In "Checking ingress controller version", the paragraph cites the incorrect name for the executable (the one in the code block is correct).
This commit fixes that inconsistency.
- Revise to be more in line with the style guide for Kubernetes official docs
- Avoid recommending that readers use `k8s.io` namespaced controller names
for their own custom controller configuration.
Co-authored-by: James Strong <strong.james.e@gmail.com>
Co-authored-by: James Strong <strong.james.e@gmail.com>
Small changes, mostly:
- formatting (especially in lists, since mkdocs doesn't seem
to support nested lists)
- use the same level of warning when it makes sense
(intead of "danger", "failure", etc)
- improve wording in a few places
- re-order a few operations
- move a few sentences that were out of place
* Fix names in documentation
This fixes the documentation to reflect the name change from
`nginx-ingress` to `ingress-nginx`.
Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>
* Revert accidental changelog update
Signed-off-by: Reinhard Nägele <unguiculus@gmail.com>
* 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
* Fix indentation of nested list in AuthTLS annotations
Also, put `<annotation>`: <description text>` on a single line in
Markdown markup, which will match what gets rendered eventually.
On the other hand, for the line on auth-tls-secret (This annotation
expects the Secret name in the form "namespace/secretName"), its
Markdown markup suggests that the author wanted the line to start on its
own line, but currently this gets rendered on the same line. It's nice
for this to be on its own line, since it's kind of a "note" about the
annotation syntax. Format/indent the markup appropriately so that it
shows up on its line.
* Fix indentation of nested list in CORS annotations
Also, put `<annotation>`: <description text>` on a single line in
Markdown markup, which will match what gets rendered eventually.
On the other hand, for lines noting the allowed characters (This is a
multi-valued field...), its Markdown markup suggests that the author
wanted the line to start on its own line, but currently this gets
rendered on the same line. It's nice for this to be on its own line,
since it's kind of a "note" about the annotation syntax. Format/indent
the markup appropriately so that it shows up on its line.
* Replace f.HTTPTestClientWithTLSConfig() in AuthTLS E2E, the odd one out for requests without client certs
* Demonstrate and document that auth-tls-secret enables the other AuthTLS annotations like verify client, depth
* Split E2E for auth-tls-error-page and *-pass-certificate-to-upstream
* Add a flag to specify address to bind the healthz server
Signed-off-by: m.nabokikh <maksim.nabokikh@flant.com>
* Add healthz host to the helm chart
Signed-off-by: m.nabokikh <maksim.nabokikh@flant.com>
* Apply suggestions from code review
Co-authored-by: Ricardo Katz <rikatz@users.noreply.github.com>
Co-authored-by: Ricardo Katz <rikatz@users.noreply.github.com>
* Add documentation for monitoring without helm
As someone who is currently learning Kubernetes without using helm, I wasn't able to get the ingress controller to export metrics without asking someone more experienced for help.
I think a bit more information would be a good addition for my fellow Kubernetes newcomers.
If there are any wording/ formatting issues, I will be happy to update this.
* Fix typo
* Update troubleshooting.md
Made the troubleshooting steps a bit more fluid IMHO.
* Update troubleshooting.md
Fixed introduced troubleshooting workflow change.
* Update troubleshooting.md
Fixed token path in new proposed workflow.
* Update troubleshooting.md
Fixed terminology (pod vs. container)
* Changed verb to get CLA refresh.
* Updating PR with requested changes.
Signed-off-by: Robert Jackson <robert@aztek.io>
* Create development guide section
Signed-off-by: Ricardo Pchevuzinske Katz <ricardo.katz@gmail.com>
* Apply suggestions from code review
Co-authored-by: Alex Zhang <tokers@apache.org>
* Typo solving and removing some TODOs
Co-authored-by: Alex Zhang <tokers@apache.org>
Added documentation and sample YAML that demonstrate how to use
NGINX Ingress Controller to provision a load balancer on Oracle Cloud
Infrastructure. The following use cases are included:
- public and private load balancers
Signed-off-by: Ali Mukadam <ali.mukadam@oracle.com>
The same setup instruction for Mac also works on Windows 10. I tested on my own Windows 10 setup. Some other people on the Internet also pointed it out. I think Docker Desktop is supposed to provide feature parity between these platforms. So, I think we can rely on Docker Desktop to keep the behaviour and allow the same instructions to work on both platforms.
The current documentation does not provide information for the difference between `:PROXY` and `::PROXY`. I have added a bit of documentation that defines the difference between the two `PROXY` fields.
Without v19.03.0 or later with experimental feature on Local build failed.
requirement of version and experimental feature on should be present in this doc
PRs #6226 and #6143 changed the configuration defaults but didn't update
all the configuration defaults docs in the user guide.
This PR updates the user guide to be in sync with the defaults.
Signed-off-by: Stevo Slavić <sslavic@gmail.com>
Improvements to the documentation of Client Certificate Authentication. (auth-tls-* annotations).
- Mention that these rules are applied per host and not per Ingress/path
- Include more possible and default values
- Describe the headers that are sent to the upstream services
Add an option to find the ingress-controller pod name to exclude the admission pod
The original "kubectl get pod" will sometime return the admission pod which is in completed status.
