* Chart: Explicitly set `runAsGroup`.
Set a default value for the runAsGroup in container securityContexts of
the controller and default backend.
Also set the runAsGroup for opentelemetry and webhook Job container
securityContexts.
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* Apply suggestions from code review
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
---------
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* Bump github.com/onsi/ginkgo/v2 from 2.19.0 to 2.19.1 in the all group
Bumps the all group with 1 update: [github.com/onsi/ginkgo/v2](https://github.com/onsi/ginkgo).
Updates `github.com/onsi/ginkgo/v2` from 2.19.0 to 2.19.1
- [Release notes](https://github.com/onsi/ginkgo/releases)
- [Changelog](https://github.com/onsi/ginkgo/blob/master/CHANGELOG.md)
- [Commits](https://github.com/onsi/ginkgo/compare/v2.19.0...v2.19.1)
---
updated-dependencies:
- dependency-name: github.com/onsi/ginkgo/v2
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: all
...
Signed-off-by: dependabot[bot] <support@github.com>
* Bump github.com/onsi/ginkgo/v2 from 2.19.0 to 2.19.1 elsewhere
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* docs: Clarify from-to-www redirect direction.
This was not clear to me when reading the docs whether the ingress will
redirect from non-www to with-www or the reverse. It's also not very
clear from just grepping around the codebase. I found the answer by
reading from this reddit link:
https://www.reddit.com/r/kubernetes/comments/pbl033/k8s_ingress_redirecting_www_to_nonwww_domains/
So, to save time for other people doing the same, which I assumes is a
lot of people since it's a common scenario, this little revision in the
docs is warranted.
* Docs: Implement suggestion.
---------
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* feat: add ssl patches for coroutines to work in lua ssl blocks
Signed-off-by: Jon Carl <grounded042@joncarl.com>
* switch to include more patches
Signed-off-by: Jon Carl <grounded042@joncarl.com>
---------
Signed-off-by: Jon Carl <grounded042@joncarl.com>
* chore: fix booleans to all have quotes around their values
Signed-off-by: Yoofi Quansah <ybquansah@gmail.com>
* Revert "chore: fix booleans to all have quotes around their values"
This reverts commit 7d91e4d9ed.
* chore: fix default values for boolean configuration
Signed-off-by: Yoofi Quansah <ybquansah@gmail.com>
---------
Signed-off-by: Yoofi Quansah <ybquansah@gmail.com>
* Fix helm install on cloud provider admonition block
* Add missing admonition type.
* Format link to AWS LB controller.
* Add nested YAML code block for annotations example
* Add a couple of line breaks for breathing and structure
* Fix admonition block title
* Another try
* Should be nice now
* feat: allow configuring nginx worker reload behaviour, to prevent multiple concurrent worker reloads
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
* appease linter, remove unnecessary log line
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
* Flip to using a positive behaviour flag instead of negative
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
* Update helm-docs
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
* Avoid calling GetBackendConfiguration() twice, use clearer name for helm chart option
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
* Fix helm-docs ordering
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
---------
Signed-off-by: Rafael da Fonseca <rafael.fonseca@wildlifestudios.com>
* Owners: Sort `ingress-nginx-maintainers` & `ingress-nginx-reviewers`.
* Owners: Update URL in aliases.
* Images: Remove owners as it's identical to global owners.
* Images: Remove global owners from `kube-webhook-certgen` owners.
* Owners: Remove members from aliases covered by other aliases.
ingress-nginx-helm-maintainers:
- cpanato: Covered by ingress-nginx-maintainers
- strongjz: Covered by ingress-nginx-maintainers
ingress-nginx-helm-reviewers:
- cpanato: Covered by ingress-nginx-reviewers
- strongjz: Covered by ingress-nginx-reviewers
ingress-nginx-docs-maintainers:
- tao12345666333: Covered by ingress-nginx-maintainers
* Owners: Promote myself to `ingress-nginx-maintainers` & `ingress-nginx-reviewers`.
* feat: add grpc buffer size in the nginx template
* feat: add grpc buffer size in the configmap struct
* feat: add test for GRCP buffer size configuration in the configmap
* chore: add documentation for the grcp buffer size configuration
* fix: fix the copyright year of the test
* fix: fix import order
* fix: fix ignore for the linter - reason was missing
* chore: seems like we don't need to ignore the error handling
* feature(geoip2_autoreload): GeoIP Autoreload
feature(geoip2_autoreload): fix lint
feature(geoip2_autoreload): changing flag interval
feature(geoip2_autoreload): tests - up and running
feature(geoip2_autoreload): tests - up and running
feature(geoip2): testing
feature(geoip2): remove typo
feature(geoip2_autoreload): fixing tests
* feature(geoip2_autoreload): working
* feature(geoip2_autoreload): including tests on geoip2 test file
Bumps the all group with 1 update: [k8s.io/component-base](https://github.com/kubernetes/component-base).
Updates `k8s.io/component-base` from 0.29.2 to 0.29.3
- [Commits](https://github.com/kubernetes/component-base/compare/v0.29.2...v0.29.3)
---
updated-dependencies:
- dependency-name: k8s.io/component-base
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: all
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* feat: deploy PDB if Keda is enabled and the minimum amount of replicas is greater than 1
* feat: add the corresponding unit-test to check PDB deployment with Keda
* chore: rename the test of PDB to follow suggested pattern
* chore: update the test-case suite name to the new format
* Update charts/ingress-nginx/templates/controller-poddisruptionbudget.yaml
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* Update charts/ingress-nginx/tests/controller-poddisruptionbudget_test.yaml
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
---------
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* [mTLS] Fix acme verfication when mTLS and Client CN verification is enabled
* revert mTLS location excluding acme-challenge since each location will match ultimately resulting in 404 for all request paths
As fixed in pull request #7829 for the ServiceMonitor resource, this is also needed for the PrometheusRule. When
upgrading the ingress-nginx chart in our environment (via Pulumi) from a really old version to the latest (4.2.0) we
noticed it wanted to delete the PrometheusRule resource. This PR should fix that.
Current implementation of OCSP stapling makes use of the DNS caching machinery[^1],
which results in resty.http not seeing the actual host name of the OCSP responder.
On HTTP level, this is already mitigated via overriding the Host header, but
if a given responder operates on a HTTPS endpoint (a setup which, admittedly, isn't
very popular due to its chicken-and-egg caveats involved but is nonetheless legal[^2])
the connection will fail to be established. A relevant (and a bit redacted) excerpt from logs:
2023/07/02 18:13:23 [info] 112#112: *29039 [lua] dns.lua:32: cache_set(): cache set for 'my.ocsp.responder' with value of [10.1.2.3, 10.4.5.6, 10.7.8.9] and ttl of 30., context: ngx.timer, client: 127.0.0.1, server: 0.0.0.0:442
2023/07/02 18:13:23 [error] 112#112: *29039 lua ssl certificate does not match host "10.1.2.3", context: ngx.timer, client: 127.0.0.1, server: 0.0.0.0:442
2023/07/02 18:13:23 [error] 112#112: *29039 [lua] certificate.lua:143: fetch_and_cache_ocsp_response(): could not get OCSP response: certificate host mismatch, context: ngx.timer, client: 127.0.0.1, server: 0.0.0.0:442
[^1]: https://github.com/kubernetes/ingress-nginx/blob/ebb6314/rootfs/etc/nginx/lua/certificate.lua#L81
[^2]: https://datatracker.ietf.org/doc/html/rfc2560#appendix-A.1.1
Before:
```
$ make print-e2e-suite
Reached DIND check ELSE block, inside run-in-docker.sh
Compiled e2e.test
Reached DIND check ELSE block, inside run-in-docker.sh
+ set -o errexit
+ set -o nounset
+ set -o pipefail
+++ dirname hack/print-e2e-suite.sh
++ cd hack/..
++ pwd -P
+ DIR=/go/src/k8s.io/ingress-nginx
+ /go/src/k8s.io/ingress-nginx/test/e2e/e2e.test -ginkgo.noColor -ginkgo.dryRun
+ sed 's|/go/src/k8s.io/ingress-nginx/|File: |g'
+ sed s/•//g
+ + head -n-3tail -n+5
You're using deprecated Ginkgo functionality:
=============================================
--ginkgo.dryRun is deprecated, use --ginkgo.dry-run instead
Learn more at: https://onsi.github.io/ginkgo/MIGRATING_TO_V2#changed-command-line-flags
--ginkgo.noColor is deprecated, use --ginkgo.no-color instead
Learn more at: https://onsi.github.io/ginkgo/MIGRATING_TO_V2#changed-command-line-flags
To silence deprecations that can be silenced set the following environment variable:
ACK_GINKGO_DEPRECATIONS=2.6.1
Will run 423 of 423 specs
```
After:
```
$ make print-e2e-suite
Reached DIND check ELSE block, inside run-in-docker.sh
Compiled e2e.test
Reached DIND check ELSE block, inside run-in-docker.sh
Will run 423 of 423 specs
------------------------------
[Annotations] service-upstream when using the default value (false) and enabling in the annotations should use the Service Cluster IP and Port
File: test/e2e/annotations/serviceupstream.go:41
[0.000 seconds]
------------------------------
[...]
```
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Add OTEL build test
* Simplify otel compilation
* Remove http2 deprecated arg
* Move image build to CI
* Turn image from scratch to optimize usage
* rollback image from scratch
* Final reviews on nginx v1.25 image
* Remove s390x from final image
* Added note to include '--ingress-class-by-name=true' for Multiple Ingress controllers instruction.
* Add note to include '-ingress-class-by-name=true' for Multiple Controllers instruction.
Fixing a typo that can mislead people : it looks like the prefix k8s.io/ is automatically stripped from ingress-class parameter value (which is not the case)
Change this:
"To prevent this situation to happening"
To this:
"To prevent this situation from happening"
Co-authored-by: Benjamin Porter <FreedomBen@users.noreply.github.com>
* Add more unit tests to helm chart
Signed-off-by: Stavros Foteinopoulos <stafot@gmail.com>
* Apply suggestions from code review
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* Apply suggestions from code review
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* Apply suggestions from code review
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* Use upstream helm-unittest repository
Signed-off-by: Stavros Foteinopoulos <stafot@gmail.com>
* Remove non existing value from controller unittest
Signed-off-by: Stavros Foteinopoulos <stafot@gmail.com>
* fix unit test
Signed-off-by: Stavros Foteinopoulos <stafot@gmail.com>
* Apply suggestions from code review
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* Apply suggestions from code review
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
---------
Signed-off-by: Stavros Foteinopoulos <stafot@gmail.com>
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* feat: allow configuration of registry, image, tag and digest in single values for opentelemetry addon
* feat: allow configuration of registry, image, tag and digest in single values for opentelemetry addon
* add ci test file
* fix: updated helm-docs with opentelemetry image value
* fix: ci test case
* fix: ci test case set default registry, image + tag
* fix: ci test case set default registry + image
* fix: remove unrequired comment
* feat!: use extraModules helper method for templating the image value
* image definition for OTel image is now split up in image, repo and registry values
* feat!: move distroless config under the image key
* update helm-docs
* Refactor template to generate the image name
* adapt test cases for extraModules
* implement code review
* try to fix ci test for opentelemetry
* upgrade go 1.21.5
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update golang gha
Signed-off-by: James Strong <strong.james.e@gmail.com>
* supgrade golang lint ci to v1.55.2
* sfix all golang lint ci errors
* sget a nginx build as well
* srevert some e2e changes
* srevert some e2e changes
---------
Signed-off-by: James Strong <strong.james.e@gmail.com>
* docs: Include default annotation prefix is docs
Most docs includes the annotation prefix
* docs: Update annotations docs for global-auth
Correct documentation to reflect whats possible. It is not possible to use `enable-global-auth: false` in ConfigMap.
* added proxy-intercept-errors config option
* fixed error when comparing locations
* fixed missing location config from annotation
added e2e test
* reversed logic for proxy-intercept-errors to disable-proxy-intercept-errors
* reversed logic to disable-proxy-intercept-errors
* reversed logic
* default has to be false
* put comment in same line as return
* run gofmt
* fixing wrong Boilerplate header
* updated code to new IngressAnnotation interface
* fixes to satisfy PR comments
* synced with upstream; fixed typo
* gofumpt disableproxyintercepterrors.go
* gofumpt
If a valid certificate is passed via `--default-ssl-certificate` it is
probably desiderable that we check its expiration!
Add a comment to explain that.
* Helpers: Align `ingress-nginx.namespace` to `ingress-nginx.name`.
* Templates: Remove quotes.
In alignment to others. Also does not make sense as `namespace` must conform to DNS.
* Admission Webhooks/Validating Webhook: Make use of `ingress-nginx.namespace`.
* KEDA: Remove comment.
* Templates: Add forgotten namespace definitions.
* Add a flag to enable or disable aio_write
Signed-off-by: z1cheng <imchench@gmail.com>
* Fix e2e test for aio_write
Signed-off-by: z1cheng <imchench@gmail.com>
* Remove redundant spaces to fix the 2e test
Signed-off-by: z1cheng <imchench@gmail.com>
---------
Signed-off-by: z1cheng <imchench@gmail.com>
Error: Failed to render chart: exit status 1: Error: YAML parse error on ingress-nginx/templates/controller-serviceaccount.yaml: error converting YAML to JSON: yaml: line 14: mapping values are not allowed in this context
Use --debug flag to render out invalid YAML
Error: plugin "diff" exited with error
* fix: Run make dev-env syntax error #10293
Signed-off-by: Son Bui <sonbv00@gmail.com>
* fix: Run make dev-env value too great for base #10294
---------
Signed-off-by: Son Bui <sonbv00@gmail.com>
* Add rollingUpdate strategy to each static deployment file
Signed-off-by: z1cheng <imchench@gmail.com>
* Update the templates and regenerate
Signed-off-by: z1cheng <imchench@gmail.com>
* Upgrade k8s version and add rolling update for exoscale
Signed-off-by: z1cheng <imchench@gmail.com>
* Add rolling update strategy to Oracle template
Signed-off-by: z1cheng <imchench@gmail.com>
* Revert the k8s version in generate-deploy-scripts.sh
Signed-off-by: z1cheng <imchench@gmail.com>
---------
Signed-off-by: z1cheng <imchench@gmail.com>
* Add validation to all annotations
* Add annotation validation for fcgi
* Fix reviews and fcgi e2e
* Add flag to disable cross namespace validation
* Add risk, flag for validation, tests
* Add missing formating
* Enable validation by default on tests
* Test validation flag
* remove ajp from list
* Finalize validation changes
* Add validations to CI
* Update helm docs
* Fix code review
* Use a better name for annotation risk
* Golang 1.20.6 for test runner
* alpine 3.18.2 as well
Signed-off-by: James Strong <strong.james.e@gmail.com>
---------
Signed-off-by: James Strong <strong.james.e@gmail.com>
* datadog: sample_rate omitted by default
* config: use *float32 with nil instead of float32 with sentinel value
* change some names
* gofmt -s -w internal/ingress/controller/nginx.go
In the current state, the docs on TCP/UDP aren't really clear on exactly whether/how TCP/UDP traffic is supported. This is an attempt to clarify the limitations inherent to k8s Ingress resources vs what can be accomplished with this controller.
* Update README.md
#9403 Add documentation for controller.service.internal.loadBalancerIP in Helm chart
* Update README.md
removed a duplicated row in the helm chart values
* #9403 added a doc to the internal loadBalancerIP
removed a comment from an already supported helm value and added a doc line
* #9403 Reverted a manual added line
Removed a manual added line in favour of helm doc
* #9403 re-generated the README with the last doc line added to the value.yaml
* #9403 removed trailing spaces
* removed trail spaces
* Remove variables with $ before feeding into url.Parse
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* Do not render invalid request mirroring config
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* Remove additional note from docs again
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
* Include quotes in e2e test for mirror proxy_pass
---------
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
Due to Kubernetes having deprecated the use of configmap as a mechanism
for elections, we have migrated to a mechanism based on leases
resources. However, the documentation has not been updated, resulting in
inconsistencies.
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
We can use alternative functions to avoid unnecessary byte/string
conversion calls and reduce allocations.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* Update dependabot to watch docker images
* Change to only /images on dependabot scan
---------
Co-authored-by: Ricardo Katz <rikatz@users.noreply.github.com>
Add support for --container flag, which sets an explicit container name
for exec operations. Defaults to `controller`.
Signed-off-by: Jacob Henner <code@ventricle.us>
* increase wait on web cert setup
Signed-off-by: James Strong <james.strong@chainguard.dev>
* add cmctl to check its working
Signed-off-by: James Strong <james.strong@chainguard.dev>
* fix wait cmd and update default k8s version
Signed-off-by: James Strong <james.strong@chainguard.dev>
* update the kubectl test commands
Signed-off-by: James Strong <james.strong@chainguard.dev>
* README: Update `external-dns` link. (#9866)
* add puerco and cpanato as approvers
Signed-off-by: James Strong <james.strong@chainguard.dev>
* update k8s versions for testing and remove cache deletion
Signed-off-by: James Strong <james.strong@chainguard.dev>
* upgrade default to 1.26 for testing
Signed-off-by: James Strong <james.strong@chainguard.dev>
---------
Signed-off-by: James Strong <james.strong@chainguard.dev>
Co-authored-by: Marco Ebert <marco@giantswarm.io>
* exclude creation and exporting of socket metrics via flag
* make exclude metric naming more consistent
* fix connect time metric update
* add documentation
* e2e test
* improve creation of metric mapping
* Fix indention issue for DaemonSets when using extraModules and extraInitContainers
* Improve documentation
* Unify and fix templating
* Enable support for the opentelemetry from values.yaml
update alpine and golang
remove nano
update go modules
remove need for openssl external cli
fix stale
Signed-off-by: James Strong <james.strong@chainguard.dev>
* Generate values.yaml with indentation of 2
Signed-off-by: Alan Clucas <alan@clucas.org>
* Fix review comments
---------
Signed-off-by: Alan Clucas <alan@clucas.org>
* Rework Ginkgo usage
Currently Ginkgo is launched multiple times with different options to
accomodate various use-cases. In particular, some specs needs to be run
sequentially because non-namespaced objects are created that conflicts
with concurent Helm deployments.
However Ginkgo is able to handle such cases natively, in particular
specs that needs to be run sequentially are supported (Serial spec).
This commit marks the specs that needs to be run sequentially as Serial
specs and runs the whole test suite from a single Ginkgo invocation. As
a result, a single JUnit report is now generated.
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Fix controller error in test
Error getting ConfigMap "$NAMESPACE/tcp-services": no object matching key "$NAMESPACE/tcp-services" in local store
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Replace "go get" invocations by "go install"
Executing "go get" changes the go.mod & go.sum files which is not the
case of "go install".
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Always clean out the Helm deployment
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Add E2E test to verify that changes to one or more configmap trigger an update
Signed-off-by: Hervé Werner <dud225@hotmail.com>
---------
Signed-off-by: Hervé Werner <dud225@hotmail.com>
* Replace deprecated command with environment file (#9581)
Signed-off-by: jongwooo <jongwooo.han@gmail.com>
* Allow to pass a target test (#9542)
* start 1.6.0 release
Signed-off-by: James Strong <strong.james.e@gmail.com>
* testing auto change
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Add mage files for changelog
Signed-off-by: James Strong <strong.james.e@gmail.com>
* change format
Signed-off-by: James Strong <strong.james.e@gmail.com>
* fixed boiler plate lint
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Align default value for keepalive_request with NGINX default (#9518)
* Align default value for keepalive_request with NGINX default
---------
Signed-off-by: jongwooo <jongwooo.han@gmail.com>
Signed-off-by: James Strong <strong.james.e@gmail.com>
Co-authored-by: Jongwoo Han <jongwooo.han@gmail.com>
Co-authored-by: Kir Shatrov <shatrov@me.com>
Co-authored-by: Christian Schaefer <chrisse.s@gmail.com>
* deps: bump k8s dependencies to remove go-autorest
* fix: update use of apiv1.LoadBalancerIngress
Due to changes in the Kubernetes API, we needed to switch to using
v1.IngressLoadBalancerIngress instead of apiv1.LoadBalancerIngress. The
struct is otherwise identical despite the name change.
* fix ingress status test cases
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Co-authored-by: Jintao Zhang <zhangjintao9020@gmail.com>
* update path type validation to be false and update e2e test scripts
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update to make tests clear
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update test params
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Adding else per pr comments
Signed-off-by: James Strong <james.strong@chainguard.dev>
---------
Signed-off-by: James Strong <strong.james.e@gmail.com>
Signed-off-by: James Strong <james.strong@chainguard.dev>
* deps: bump k8s dependencies to remove go-autorest
* fix: update use of apiv1.LoadBalancerIngress
Due to changes in the Kubernetes API, we needed to switch to using
v1.IngressLoadBalancerIngress instead of apiv1.LoadBalancerIngress. The
struct is otherwise identical despite the name change.
* fix ingress status test cases
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Co-authored-by: Jintao Zhang <zhangjintao9020@gmail.com>
Also add more detailed description to `nginx_ingress_controller_request_duration_seconds`
and `nginx_ingress_controller_response_duration_seconds` based on NGINX docs.
Also reformat the list so the descriptions are under the corresponding list item.
* feat: Add support for IP Deny List
* fixed gomod
* Update package
* go mod tidy
* Revert "go mod tidy"
This reverts commit e6a837e1e7.
* update ginko version
* Updates e2e tests
* fix test typo
* upgrade nginx base and e2e base
Signed-off-by: James Strong <james.strong@chainguard.dev>
* upgrade e2e base
Signed-off-by: James Strong <james.strong@chainguard.dev>
* update new build
Signed-off-by: James Strong <james.strong@chainguard.dev>
* update to latest e2e base
Signed-off-by: James Strong <james.strong@chainguard.dev>
* remove e2e update
Signed-off-by: James Strong <james.strong@chainguard.dev>
* remove e2e update
Signed-off-by: James Strong <james.strong@chainguard.dev>
Signed-off-by: James Strong <james.strong@chainguard.dev>
* add labels to dependabot prs
Signed-off-by: cpanato <ctadeu@gmail.com>
* sync hashes and versions dependabot can update the version comment now
Signed-off-by: cpanato <ctadeu@gmail.com>
Signed-off-by: cpanato <ctadeu@gmail.com>
* start upgrade to 1.19.4
Signed-off-by: James Strong <james.strong@chainguard.dev>
* add matrix to image test-image
Signed-off-by: James Strong <james.strong@chainguard.dev>
* update to alpine 3.17
Signed-off-by: James Strong <james.strong@chainguard.dev>
* remove need for curl
Signed-off-by: James Strong <james.strong@chainguard.dev>
Signed-off-by: James Strong <james.strong@chainguard.dev>
kind is already installed by default in the current GitHub Action
environment.
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Add a reference to docker-mac-net-connect for macOS users experiencing ingress not being exposed
Signed-off-by: TommyStarK <thomasmilox@gmail.com>
Signed-off-by: TommyStarK <thomasmilox@gmail.com>
Before this change, it appears on the website as:
> A weight of means implies all requests will be sent to the alternative service specified in the Ingress. `<weight-total>` defaults to 100, and can be increased via `nginx.ingress.kubernetes.io/canary-weight-total`.
Where there is the term `weight-total` as a pure html tag in the space. This fixes it to actually display it as text in the prose.
* fix(hpa): deprecated api version, bump to v2
* chore(hpa): abstract hpa apiVersion to helm value
* feat(hpa): add controller.autoscaling.apiVersion docs in README
* docs(hpa): quotes around apiVersion string type
* chore(hpa): run helm-docs in repo
* chore(hpa): remove local helm-docs module install and output
* docs(helm): add hpa controller.autoscaling.apiVersion description
* docs(hpa): remove autoscaling.apiVersion description as it fails ci
The missing controller.ingressClass would set the deployment to the default class but the controller.ingressClassResource.name would set the creation of a new IngressClass object.
For now this needs to be done twice, could be a fix in the chart later on.
* add workflow dispatch and update nginx base
Signed-off-by: James Strong <strong.james.e@gmail.com>
* e2e were failing, added a go mod tidy
Signed-off-by: James Strong <strong.james.e@gmail.com>
* e2e were failing, added a go mod tidy
Signed-off-by: James Strong <strong.james.e@gmail.com>
* push mod and sum from main
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Update NGINX_BASE
Co-authored-by: Jintao Zhang <tao12345666333@163.com>
Signed-off-by: James Strong <strong.james.e@gmail.com>
Co-authored-by: Jintao Zhang <tao12345666333@163.com>
* Automatically generate electionID from the fullname or use the set value.
* Updated the chart readme to include the new empty default.
* Rebuilt the Helm readme with helm-docs.
* upgrade to golang 1.19.2
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update e2e testing to 1.25 kind
Signed-off-by: James Strong <strong.james.e@gmail.com>
Signed-off-by: James Strong <strong.james.e@gmail.com>
Added more clarity to the docs with regards to the getting-started page
for developers.
Signed-off-by: afro-coder <leon9923@gmail.com>
Signed-off-by: afro-coder <leon9923@gmail.com>
When using multiple values for the `serviceAccount.annotations` values, the first line ends up indented 2 further than the following lines, resulting in a invalid yaml
* clean prometheus metrics
- add new histogram metrics with consistent names
- deprecate summary metrics with inconsistent names
* update prometheus metrics tests
* remove ingress_upstream_header_seconds metric
It hasn't been released so it is safe. Use header_duration_seconds metric.
* add documentation on prometheus metrics
* Support none keyword in log-format escape
## What this PR does / why we need it:
ingress-nginx does not support disabling escaping of special characters in the nginx log. This PR exposes the setting to support that functionality.
## Types of changes
- [ ] 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)
- [ ] Documentation only
## Which issue/s this PR fixes
<!--
(optional, in `fixes #<issue number>` format, will close that issue when PR gets merged):
fixes #
-->
## How Has This Been Tested?
Followed the [getting-started](96b6228a6b/docs/developer-guide/getting-started.md) guide. Used ppa:longsleep/golang-backports on WSL Ubuntu to establish a golang-1.18 environment with latest docker and recommended kind. Built the dev-env successfully; had issues with make test, but they are entirely unrelated to anything I touched. Ultimate test was
```
FOCUS=log-format make kind-e2e-test
...
Ginkgo ran 1 suite in 6m29.7437865s
Test Suite Passed
```
## Checklist:
<!--- 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
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.
I did not update docs/e2e-tests.md.
* gofmt -s ./internal/ingress/controller/config/config.go
* ci: setup version matrix for the helm chart e2e
Signed-off-by: wilmarguida <w.denouden@guida.nl>
* ci: sync all k8s version on CI steps
Signed-off-by: wilmarguida <w.denouden@guida.nl>
* ci: bump all k8s version to latest stable
Signed-off-by: wilmarguida <w.denouden@guida.nl>
Signed-off-by: wilmarguida <w.denouden@guida.nl>
This adds the new annotation `nginx.ingress.kubernetes.io/session-cookie-domain`
for setting the cookie `Domain` attribute of the sticky cookie.
Signed-off-by: Matthias Neugebauer <mtneug@mailbox.org>
Signed-off-by: Matthias Neugebauer <mtneug@mailbox.org>
This adds a link to the new contributor tips
in the developer guide present on the docs page
Signed-off-by: afro-coder <leon9923@gmail.com>
Signed-off-by: afro-coder <leon9923@gmail.com>
* fix: do not apply job-patch psp on Kubernetes 1.25 and newer
Signed-off-by: wilmarguida <w.denouden@guida.nl>
* fix: bump kubernetes version for helm chart CI to 1.25.0
Signed-off-by: wilmarguida <w.denouden@guida.nl>
Signed-off-by: wilmarguida <w.denouden@guida.nl>
This commit adds tips for new contributors along with references and
examples
Signed-off-by: afro-coder <leon9923@gmail.com>
Co-authored-by: Tanisha Banik <26tanishabanik@gmail.com>
Signed-off-by: afro-coder <leon9923@gmail.com>
Co-authored-by: Tanisha Banik <26tanishabanik@gmail.com>
* updates for fixing 1.3.1 release
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update chart readmea
Signed-off-by: James Strong <strong.james.e@gmail.com>
* updating chart
Signed-off-by: James Strong <strong.james.e@gmail.com>
* supdate wording of legacy drop
* supgraded helm docs
* one more time
Signed-off-by: James Strong <strong.james.e@gmail.com>
Signed-off-by: James Strong <strong.james.e@gmail.com>
* testing the fix
Signed-off-by: James Strong <strong.james.e@gmail.com>
* revert 1.3.1 while we fix the build
Signed-off-by: James Strong <strong.james.e@gmail.com>
Signed-off-by: James Strong <strong.james.e@gmail.com>
* fix: convert to LF line endings
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* Pin exact Go bugfix versions for CI jobs
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* Bump go.mod and Dockerfiles to Go 1.19.0
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* adding cve finding and adding release-notes to PR template
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update cve report with verbiage around open CVEs and not disclosures
Signed-off-by: James Strong <strong.james.e@gmail.com>
* fix then assignees
Signed-off-by: James Strong <strong.james.e@gmail.com>
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Make securityContext in admission-webhook more configurable e.g. to set seccompProfiles
Signed-off-by: Oliver Michels <oliver.michels@aldi-sued.com>
* Make securityContext in admission-webhook more configurable e.g. to set seccompProfiles
Signed-off-by: Oliver Michels <oliver.michels@aldi-sued.com>
* Make securityContext in admission-webhook more configurable e.g. to set seccompProfiles
Signed-off-by: Oliver Michels <oliver.michels@aldi-sued.com>
* Make securityContext in admission-webhook more configurable e.g. to set seccompProfiles
Signed-off-by: Oliver Michels <oliver.michels@aldi-sued.com>
Signed-off-by: Oliver Michels <oliver.michels@aldi-sued.com>
We removed the use of configmap as an election lock, so we will use the
Lease API to complete the election.
Before this, we used `MultiLock` to facilitate smooth migration of
existing users of ingress-nginx from configmap to LeaseLock.
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
* Feat: reimplement kubectl plugin release system
This commit does the following changes:
- Add GitHub Actions pipeline for releasing the plugin
- Removes the build/build-plugin.sh and replaces this with GoReleaser
- Adds the use of krew-release-bot for automatically updating the krew
release
- Removes the make target for build/build-plugin.sh
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* Fix: pin github actions stages with commit sha
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* feat: no longer generate versioned manifests
Updates the script to no longer generate multiple versioned deploy manifests.
The script will only generate the manifests for one given version of
Kubernetes.
See: https://github.com/kubernetes/ingress-nginx/issues/8824
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* fix: delete unnecessary versioned deploy manifests
See: https://github.com/kubernetes/ingress-nginx/issues/8824
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
* update GCE doc with proxy protocol and some fixes
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update gke docs
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update files to use one base image file
Signed-off-by: James Strong <strong.james.e@gmail.com>
* add chart test as well
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update e2e-test image building
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update e2e base image arg
Signed-off-by: James Strong <strong.james.e@gmail.com>
* add current e2e so test run
Signed-off-by: James Strong <strong.james.e@gmail.com>
* working on fixing build
* getting dev-env and make release to work
* test
* i think buildx is working on mac
* updates
* why docker for mac and linux cli differ
* fix target arch
* fix target arch
* fix loag issue
* fix issue
* update the chroot docker file
* fix docker base build
* mac is the issue
* env not getting to the e2e deployment.go file
* fix pull issue
* fix pull issue
* move test scripts into test folder
* clean up ci
* updates for PR
* remove unnesscary var
* Change helm release name in docs
Following step by step instructions in readme I ran into error:
Error: release: not found
And realized the commandline was differnent from description. Let
change description to match commandline?
* Fix verb tense in docs
* Update deploy.yaml
Removed the *service.beta.kubernetes.io/exoscale-loadbalancer-name* annotation so it uses service UID by default.
It thus removes the current limitation that prevent the installation of several ingress nginx controllers on different clusters belonging to the same organization.
* Removing default loadbalancer name
* pinning deps for CI
* update all the actions and pin them
* missed one
* update helm to another action
* typo on step
* typo on step
* Update .github/workflows/ci.yaml
Co-authored-by: Jintao Zhang <tao12345666333@163.com>
Co-authored-by: Jintao Zhang <tao12345666333@163.com>
* support extraEnvs for job resources in helm chart
Signed-off-by: Li, Eric <Xiannan.li@fmr.com>
* Update helm doc
* Update helm doc
* Updated helm doc - add controller.admissionWebhooks.extraEnvs
* Added some test data for webhook controller.admissionWebhooks.extraEnvs
* added new line at the end of deployment-webhook-extraEnvs-values.yaml
* Fixed helm chart test issue
* update ci kind version to v0.14.0
Signed-off-by: Abhishek Agarwal <abhishek.agarwal@mayadata.io>
* updated the ci strategy matrix k8s versions
Signed-off-by: Abhishek Agarwal <abhishek.agarwal@mayadata.io>
* Improve path rule
* Add nginx configuration tests
* Revert framework changes
* Add test to patched directives
* Fix root conf test
* Add comment in new function
When creating several ingresses at the same time a race condition can
happen by modifying a variable deep in another object. When this race
condition is triggered the generated nginx configuration is broken:
```
nginx: [emerg] invalid parameter "8.8.8.8/32,8" in /tmp/nginx-cfg4027854160:671
nginx: configuration file /tmp/nginx-cfg4027854160 test failed
```
Once it happens, the controller won't ever be able to generate the
configuration again. Thus the only option is to restart the process.
There is not really a good way to reproduce this issue. It happens quite
sporadically every 2 or 3 days. However, after this fix has been
applied, we haven't seen it happen after about 4 weeks.
Co-authored-by: Ruud van der Weijde <ruudvanderweijde@gmail.com>
This commit introduces a backwards compatible command line option
--report-status-classes which will enable reporting response status classes
(2xx, 3xx..) instead of status codes in exported metrics.
It adds description to the `Ingress Percentile Response Times and Transfer Rates` view, so that user knows that this latency data is independant of dashboard time range.
This PR also adds two new panel about the latency, where one shows latency as a timeseries graph and other shows heatmap of the latency distribution.
* disable modsecurity on error page
* fix modsecurity error pages test
* fix variable in nginx template
* disable modsecurity on all internal locations
* fix pipeline checks for gofmt
Signed-off-by: Florian Michel <florianmichel@hotmail.de>
X-CustomHeader looks more like an example than a header we would want to
accept in production. Added Range as a useful header that enables
operations on resources that can be fetched in chunks.
* nginx 1.19.10 keepalive_time parameter
* nginx v1.19.10 base image
* keepalive_time documentation
* base image
* restore base image
* e2e test
* replace default value in test
Display per method/path combos for various metrics, adjust titles, and sort tooltip by decreasing
Signed-off-by: Naseem Ullah <24660299+naseemkullah@users.noreply.github.com>
* Initial work on chrooting nginx process
* More improvements in chroot
* Fix charts and some file locations
* Fix symlink on non chrooted container
* fix psp test
* Add e2e tests to chroot image
* Fix logger
* Add internal logger in controller
* Fix overlay for chrooted tests
* Fix tests
* fix boilerplates
* Fix unittest to point to the right pid
* Fix PR review
* Add keepalive support for auth requests
* Fix typo
* Address PR comments
* Log warning when auth-url contains variable in its host:port
* Generate upstream name without replacing dots to underscores in server name
* Add comment in the nginx template when the keepalive upstream block is referenced
* Workaround for auth_request module ignores keepalive in upstream block
* The `auth_request` module does not support HTTP keepalives in upstream block:
https://trac.nginx.org/nginx/ticket/1579
* As a workaround we use ngx.location.capture but unfortunately it does not
support HTTP/2 so `use-http2` configuration parameter is needed.
* Handle PR comments
* Address PR comments
* Handle invalid values for int parameters
* Handle PR comments
* Fix e2e test
* force helm release to artifact hub
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update releaser version
Signed-off-by: James Strong <strong.james.e@gmail.com>
* release 1.1.3 details
fix the readme with right sha and version
remove helm label
fix issue 8329
fix the 1.20 service after the fix for ipv6
udpate readme and change for patches
* update helm doc
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update nginx base image to new alpine 3.14.4 build
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update test image
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Update nginx base image
Signed-off-by: Aditya Kamath <theunrealgeek@gmail.com>
Co-authored-by: James Strong <strong.james.e@gmail.com>
* 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)
* added fsGroup to admission createSecret and patchWebhook job
* added fsGroup to admission createSecret and patchWebhook job
* modified helm/README.md to add value for fsGroup
* fixed patch job values ordering
* remove manually edited README for replacement with helm-docs generated version
* re-adding charts/README.md generated by helm-docs
When the ingress controller loads certificates (new ones or following a
secret update), it performs a series of check to ensure its validity.
In our systems, we detected a case where, when the secret object is
compromised, for example when the certificate does not match the secret
key, different pods of the ingress controller are serving a different
version of the certificate.
This behaviour is due to the cache mechanism of the ingress controller,
keeping the last known certificate in case of corruption. When this
happens, old ingress-controller pods will keep serving the old one,
while new pods, by failing to load the corrupted certificates, would
use the default certificate, causing invalid certificates for its
clients.
This generates a random error on the client side, depending on the
actual pod instance it reaches.
In order to allow detecting occurences of those situations, add a metric
to expose, for all ingress controlller pods, detailed informations of
the currently loaded certificate.
This will, for example, allow setting an alert when there is a
certificate discrepency across all ingress controller pods using a query
similar to `sum(nginx_ingress_controller_ssl_certificate_info{host="name.tld"})by(serial_number)`
This also allows to catch other exceptions loading certificates (failing
to load the certificate from the k8s API, ...
Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com>
Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com>
* fix inconsistent-label-cardinality
for prometheus metrics: nginx_ingress_controller_requests
* add host to collectorLabels only if metricsPerHost is true
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>
* remove opentelemetry from main nginx image
* add opentelemetry sidecar image
* handle extra modules in helm chart
* fix running helm chart
* mount the modules volume in the init container
* merge the mounted folder
* fix the otel image
* fix licence year
* fix cloudbuild image
* use the same nginx version as in the main image
* only retrieve /etc/nginx/modules for now
This enables the use of the `helm-docs` tool on the Helm chart located in `charts/ingress-nginx`. This will make it possible to automatically document new variables in the `values.yaml` file.
Signed-off-by: Scott Crooks <scott.crooks@gmail.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.
* Disabled default modsecurity_rules_file if modsecurity-snippet is specifed
The default modsecurity_rules_file overwrites the ModSecurity-snippet if it is specified with custom config settings like "SecRuleEngine On". This will not let Modsecurity be in blocking mode even if "SecRuleEngine On" is specified in the ModSecurity-snippet configuration
* Remove unnecessary comments
Only have the default Modsecurity conf settings in case Modsecurity configuration snippet is not present and remove unnecessary comments
* Fixed modsecurity default file only if Modsecurity snippet present
Fixed if condition Modsecurity snippet present have modsecurity default config file
* Added e2e test to disabling modsecurity conf
Added e2e in case modsecurity-snippet enabled to disable settings in default modsecurity.conf
* Validate writing to a different location
Validate also modsecurity to write to a different location instead of the default directory
* Fixed the formatting
* Fixed if empty ModsecuritySnippet
* Fixed ModsecuritySnippet condition
* Fixed the condition also in ingress controller template
* Removed the default config condition in ingress controller template
* Fixed the default config condition in ingress controller template
* Fixed pull-ingress-nginx-test
* Revert "Fixed the default config condition in ingress controller template"
This reverts commit 9d38eca40f.
* Revert template_test
* Adjusted the formating %v
* use '-O2' instead of '-Og'
'-O2' produce production optimized binary while '-Og' is used mostly
for debugging
* use '-mtune=generic' instead of '-mtune=native'
'-mtune=native' produce optimal code for builder host system, but it
can be sub-optimal for execution host system
- 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
* allow set annotations for admission Jobs
Signed-off-by: Alex Co <tuanclq@gmail.com>
* Bump chart version & update CHANGELOG
Signed-off-by: Alex Co <tuanclq@gmail.com>
* Bump chart version again
Signed-off-by: Alex Co <tuanclq@gmail.com>
* Add example
Signed-off-by: Alex Co <tuanclq@gmail.com>
* 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>
* Add labels to RBAC resources
* Add labels to all resources
* Fix labels indentaton in patch jobs
* Add controller and default backend labels to pods
Signed-off-by: Muhammad Hamza Zaib <hamzazaib3202@gmail.com>
* Bump chart version and update changelog
Signed-off-by: Muhammad Hamza Zaib <hamzazaib3202@gmail.com>
the BASE_IMAGE `k8s.gcr.io/ingress-nginx/nginx:v20210915-g498892514@sha256:8c1e48123e64e3f2b90ed32a53babd9b5f5431dad26beecdcb8fc185ded3b6dd` was alreday patched
* 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.
* OWNERS_ALIASES: add ingress-nginx-kube-webhook-certgen-reviewers
For extra kube-webhook-certgen reviewers.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen: add separate owners
To add myself as a reviewer as discussed in #7641.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* priorityClassName should be in " "
Example: https://github.com/helm/charts/blob/master/stable/k8s-spot-rescheduler/templates/deployment.yaml#L28
* Update charts/ingress-nginx/templates/controller-deployment.yaml
Co-authored-by: Alex Harder <13860012+ChiefAlexander@users.noreply.github.com>
Co-authored-by: Ricardo Katz <rikatz@users.noreply.github.com>
Co-authored-by: Alex Harder <13860012+ChiefAlexander@users.noreply.github.com>
* Add support to ipFamilyPolicy and ipFamilies fields in Helm chart
As stated in the prerequisites' session of https://kubernetes.io/docs/concepts/services-networking/dual-stack/, in order to use Kubernetes IPv4/IPv6 dual stack, v1.20 is needed. This commit aims in supporting these dual-stack-ness in ingress-nginx's chart.
Signed-off-by: jaehnri <joao.henri.cr@gmail.com>
* Standardize documentation with two '#'s
Signed-off-by: jaehnri <joao.henri.cr@gmail.com>
* Bump Helm chart version to 4.1.0
Signed-off-by: jaehnri <joao.henri.cr@gmail.com>
* Update Helm Chart changelog with 4.1.0 description
Signed-off-by: jaehnri <joao.henri.cr@gmail.com>
* Revert Helm Chart bump and remove CHANGELOG
As there will be more things in the release, in the review of this PR, it was asked to revert the bumps:
https://github.com/kubernetes/ingress-nginx/pull/7651#pullrequestreview-757311449
Signed-off-by: jaehnri <joao.henri.cr@gmail.com>
* images/kube-webhook-certgen/rootfs: improve tests objects creation
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: use context with deadline for tests
So in case some operations are taking more time, we respect -timeout
flag.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: add missing tests implementation
It should've been added in 9acf62d867.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: fix patching only mutating webhook
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
As a follow up to PR #7641, this commit adds some basic e2e tests for
kube-webhook-certgen image.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
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.
* images/kube-webhook-certgen/rootfs/pkg/k8s: return err from functions
Initially only from some to preserve existing behavior.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: make patching return error
So we don't call log.Fatal in so many places, which makes code testable.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: require context
So initialize top-level contexts in tests and CLI, then pass them around
all the way down, so there is an ability e.g. to add timeouts to patch
operations, if needed and to follow general conventions.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: support patching APIService
APIService object is very similar to MutatingWebhookConfiguration and
ValidatingWebhookConfiguration objects, so support for patching it
shouldn't be too much of a burden.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/cmd: use new patch API
So old function PatchWebhookConfigurations can be unexported and CLI can
be extended to also support patching APIService.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: unexport old patch function
PatchObjects should be now used instead.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: add .gitignore
To ignore manually built binaries during development process.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/cmd: test patching
By adding a PatchConfig and Patch function, it is now possible to test
logic of flag validation, which was previously tied to CLI options.
This commit adds nice set of tests covering existing logic.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/cmd: improve formatting
Those strings will be changed anyway in future commits, so at first we
can properly capitalize used names.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/cmd: support patching APIService
As logic for creating a CA certificate and patching an object is almost
the same for both webhook configuration and API services, this commit
adds support to kube-webhook-certgen CLI to also patch APIService
objects, so they can be served over TLS as well.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: pass failure policy by value
k8s.k8s.patchWebhookConfigurations() always dereferences it and we do
not do a nil check, so the code may panic in some conditions, so it's
safer to just pass it by value, as it's just a wrapped string.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
it has two important bugfix:
1. should force convert weight to a number since it may cause dead loop
when weight is a string type "0".
2. out-of-bounds memory writing may happen in chash_point_sort.
Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
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
* images/kube-webhook-certgen/rootfs/README.md: remove trailing whitespace
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: improve code formatting
Automatically using gofumpt.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: remove executable bits from files
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/cmd: remove unreachable code
log.Fatal(|f) will alread call os.Exit(1), so this code is never
reached.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: fix unit tests
Right now they fail as everything else migrated from using v1beta1 to
v1.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs: create clientset in cmd package
So one can easily mock the client, without touching unexported parts of
the code and to soften the dependency between CLI code (kubeconfig
path).
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/cmd: simplify bool logic
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: improve formatting
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: improve variable names
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: refactor a bit
Move patching logic to separate functions.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
* images/kube-webhook-certgen/rootfs/pkg/k8s: fix error log messages
In patchMutating() function, log messages were waying still patching
validating webhook.
Signed-off-by: Mateusz Gozdek <mgozdek@microsoft.com>
- Add github action test-image-build
- Filters the images folder
and checks for changes
- If the changes are done then the
make build would be performed
* 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
Normally Ingress sinchronization for Services is triggered when
corresponding Service's Endpoints are added, deleted or modified.
Services of type ExternalName, however, do not have any endpoints
and hence do not trigger Ingress synchronization as only Update
events are being watched. This commit makes sure that Update and
Delete Service events also enqueue a syncIngress task.
* Change statusSync.runningAddresses() return type
Previously, this method returning a string slice containing the resolved
IP addresses / FQDNs to sync onto the Ingress. It was then converted
just before use into a slice of LoadBalancerIngresses.
This commit changes this logic so that this method generates
LoadBalancerIngress objects directly, and returns these. This has two
main benefits:
- Future work in syncing _both_ hostname and IP, or any other fields
that may be used in future (eg Ports), is now supported.
- There is less need to rely on net.ParseIP() to determine if a value is
an IP address or Hostname, as this can be correctly assigned at
generation time based on where each value came from.
* Sync both IP and Hostname to Ingress Status
Previously, if the IP address was set on a PublishService's
LoadBalancerIngress entries, only that would be synced. Hostname was
only synced as a fallback when the IP address was missing.
Now, both fields are checked independantly and both are synced if
present.
* 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
* Update to the base nginx image
* Revert "Update to the base nginx image"
This reverts commit ad43c1d060.
* Update test runner image
* correcting the sha and version of e2e test runner images
* Update to the base nginx image
* Revert "Update to the base nginx image"
This reverts commit ad43c1d060.
* Updated cloudbuild to increase build timeout value
* 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>
* Adding test cases for backend with nil service
Signed-off-by: Marcos <marcosnery.comp@gmail.com>
Co-authored-by: Renato Araujo <renatobritto@protonmail.com>
Co-authored-by: André Goretti <andremotta96@gmail.com>
Co-authored-by: Kalebe Lopes <calbkalebe@gmail.com>
* Add e2e test for backend nil service and add nil safeguard (#7344)
Co-authored-by: Renato Araujo <renatobritto@protonmail.com>
Co-authored-by: André Goretti <andremotta96@gmail.com>
Co-authored-by: Kalebe Lopes <calbkalebe@gmail.com>
* changing portuguese names to english in order to maintain the pattern
* updating boilerplate header
* adding second test case to also test valid path
Co-authored-by: Ricardo Katz <rikatz@users.noreply.github.com>
* Updating boilerplate
* fixing boilerplate
Signed-off-by: MarcosN <marcosnery.comp@gmail.com>
Co-authored-by: André Goretti <andremotta96@gmail.com>
Co-authored-by: Gabriel Albino <enggabrielalbino@gmail.com>
* Improving template test for cases where a nil backend service is included
Signed-off-by: MarcosN <marcosnery.comp@gmail.com>
Co-authored-by: André Goretti <andremotta96@gmail.com>
Co-authored-by: Gabriel Albino <enggabrielalbino@gmail.com>
Co-authored-by: Renato Araujo <renatobritto@protonmail.com>
Co-authored-by: André Goretti <andremotta96@gmail.com>
Co-authored-by: Kalebe Lopes <calbkalebe@gmail.com>
Co-authored-by: Ricardo Katz <rikatz@users.noreply.github.com>
Co-authored-by: Gabriel Albino <enggabrielalbino@gmail.com>
* release v1.0.0
Signed-off-by: Neha Lohia <nehapithadiya444@gmail.com>
* add the known issues no in changelog.md for release v1.0.0
Signed-off-by: Neha Lohia <nehapithadiya444@gmail.com>
* fix ingress-nginx panic when the certificate format is wrong.
Signed-off-by: wang_wenhu <976400757@qq.com>
* Add unit test.
Signed-off-by: wang_wenhu <976400757@qq.com>
* Update controller_test.go
* bump go.mod to 1.17
* bump github ci workflow to go 1.17
* bump e2e-test-runner version
* fix go mod error
* fix go fmt error
* fix boilerplate verification
Minor update to the helm chart to set the [appProtocol][1] field on all
http / https ports defined in the various services created by the helm
chart:
- http and https for controller-service
- http and https for controller-service-internal
- https for controler-service-webhook
- http for default-backend-service
These are only added in kubernetes >= 1.20, which is when this feature
became stable.
[1]: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol
* add e2e test for auth-response-headers annotation
* add e2e test for grpc with auth-response-headers
* fix forwarding of auth header to GRPC backends
* add test case for proxySetHeader(nil)
Rather than hard-coding the default response format as HTML, allow the default to be overridden by an environment variable. For example, given a REST API endpoint that defaults to responding in JSON, you may wish to configure the error messages to be JSON by default as well.
* 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
* helm: add feature to configure request and limit for container in createSecret and patchWebhook job
Signed-off-by: Bhumij Gupta <bhumijgupta@gmail.com>
* Remove empty line in helm template
Signed-off-by: Bhumij Gupta <bhumijgupta@gmail.com>
* Add test for admission webhook job container resources
Signed-off-by: Bhumij Gupta <bhumijgupta@gmail.com>
* Add new line character at the end of charts ci file
Signed-off-by: Bhumij Gupta <bhumijgupta@gmail.com>
* add auto backend protocol for HTTP/HTTPS
* e2e test for AUTO_HTTP backend protocol
* unit test for AUTO_HTTP backend protocol
Co-authored-by: Luca Del Monte <luca.delmonte5@gmail.com>
* 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>
* Rewrite clean-nginx-conf.sh to speed up admission webhook
* Less diff with original clean-nginx-conf.sh
* Add error handling, add documentation, add unit test
* indent code
* Don't ignore Getwd() error
* helm: add new ingressClass resource
* add ingress parameters support
This commit adds ingress parameters support.
Credits go to Ariel Vinas: ariel@craftech.io
The development.md file does not exist. Clicking on "Development" link on the Welcome page returns a 404.
We already have a Developer Guide. Having the Development page should not be required. Hence, I am proposing that we remove it.
The cla has been signed.
* 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>
There was a critical security compromise of the bash script
that was being downloaded as part of the coverage build:
https://about.codecov.io/security-update/
beginning January 31, 2021, there were periodic, unauthorized
alterations of our Bash Uploader script by a third party, which enabled
them to potentially export information stored in our users' continuous
integration (CI) environments. This information was then sent to a
third-party server outside of Codecov’s infrastructure.
The Bash Uploader is also used in these related uploaders:
Codecov-actions uploader for Github, the Codecov CircleCl Orb, and the
Codecov Bitrise Step (together, the “Bash Uploaders”). Therefore, these
related uploaders were also impacted by this event.
The altered version of the Bash Uploader script could potentially
affect:
Any credentials, tokens, or keys that our customers were passing through
their CI runner that would be accessible when the Bash Uploader script
was executed. Any services, datastores, and application code that could
be accessed with these credentials, tokens, or keys. The git remote
information (URL of the origin repository) of repositories using the
Bash Uploaders to upload coverage to Codecov in CI.
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>
* Prepare for v0.45.0 release
* Apply suggestions from code review
Co-authored-by: Elvin Efendi <elvin.efendiyev@gmail.com>
* Prepare for v0.45.0 release
Co-authored-by: Elvin Efendi <elvin.efendiyev@gmail.com>
The default value of ShowServerTokens aka server-tokens in the
global configmap was changed in commit
87aa96b468 in 2020-09-17 (release v0.40.0)
but one reference was overlooked in this comment.
Other documentation, implementation and testcases are all in agreement.
Correct the comment to align with others: server-tokens=false.
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.
Currently, the opentracing propagation instructions are set only if opentracing is configured globally.
This fix set the propagation instructions if opentracing is disabled globally, but enabled per ingress
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
nginx_ingress_controller_nginx_process_connections returns four elements
for each pod, one for each "state" (active, reading, waiting, writing).
The value of the element with state "active" is the sum of the other
three elements of other states:
active = reading + waiting + writing
So sum() returns a value that is 2x of the actual amount of connections.
To fix this we simply select elements with state "active".
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>
The label triage/support has been reclassified as kind/support. The
kind/* family of labels makes more logical sense, as they describe the
"kind" of thing an issue or PR is.
For more information, see the announcement email:
https://groups.google.com/g/kubernetes-dev/c/YcaJpsjjLKw/m/i15cLLx5CAAJ
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
Two new configuration options:
`disable-http-access-log`
`disable-stream-access-log`
Should resolve issue with enormous amount of `TCP 200` useless entries in logs
Signed-off-by: Andrey Voronkov <voronkovaa@gmail.com>
- **Current state of ingress object, if applicable**:
- `kubectl -n <appnamespace> get all,ing -o wide`
- `kubectl -n <appnamespace> describe ing <ingressname>`
- If applicable, then, your complete and exact curl/grpcurl command (redacted if required) and the reponse to the curl/grpcurl command with the -v flag
- **Others**:
- Any other related information like ;
- copy/paste of the snippet (if applicable)
- `kubectl describe ...` of any custom configmap(s) created and in use
- Any other related information that may help
**What happened**:
<!-- (please include exact error messages if you can) -->
**What you expected to happen**:
<!-- What do you think went wrong? -->
**How to reproduce it**:
**How to reproduce this issue**:
<!---
As minimally and precisely as possible. Keep in mind we do not have access to your cluster or application.
@ -60,28 +95,34 @@ Help up us (if possible) reproducing the issue using minikube or kind.
stale-issue-message:"This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach `#ingress-nginx-dev` on Kubernetes Slack."
stale-pr-message:"This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach `#ingress-nginx-dev` on Kubernetes Slack."
Read the following guide if you're interested in contributing to Ingress. [Make Ingress-Nginx Work for you, and the Community](https://youtu.be/GDm-7BlmPPg) from KubeCon Europe 2018 is a great video to get you started!!
Note that this guide refers to contributing to actual sources of the repository. If you interested in contributing through issue triaging, have a look at [this guide](./ISSUE_TRIAGE.md).
## Contributor License Agreements
We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
@ -15,14 +17,16 @@ Follow either of the two links above to access the appropriate CLA and instructi
***NOTE***: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.
## Finding Things That Need Help
## Finding Issues That Need Help
If you're new to the project and want to help, but don't know where to start, we have a semi-curated list of issues that should not need deep knowledge of the system. [Have a look and see if anything sounds interesting](https://github.com/kubernetes/ingress-nginx/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22help+wanted%22). Alternatively, read some of the docs on other controllers and try to write your own, file and fix any/all issues that come up, including gaps in documentation!
If you're new to the project and want to help, but don't know where to start, we have a semi-curated list of issues that should not need deep knowledge of the system. [Have a look and see if anything sounds interesting](https://github.com/kubernetes/ingress-nginx/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22help+wanted%22).
Alternatively, search for the label [`triage-accepted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3Atriage%2Faccepted+) if you have some experience with ingress-nginx. Note, that it could make sense to grab issues with higher priority first.
## Contributing a Patch
1. If you haven't already done so, sign a Contributor License Agreement (see details above).
1. Read the [Ingress development guide](docs/development.md).
1. Read the [Ingress development guide](docs/developer-guide/getting-started.md).
1. Fork the desired repo, develop and test your code changes.
1. Submit a pull request.
@ -30,7 +34,9 @@ All changes must be code reviewed. Coding conventions and standards are explaine
### Merge Approval
Ingress collaborators may add "LGTM" (Looks Good To Me) or an equivalent comment to indicate that a PR is acceptable. Any change requires at least one LGTM. No pull requests can be merged until at least one Ingress collaborator signs off with an LGTM.
Ingress Nginx collaborators may add "/lgtm" (Looks Good To Me) to indicate that a PR is acceptable. Any change requires at least one LGTM. No pull requests can be merged until at least one Ingress Nginx collaborator signs off with an LGTM. Adding the "/lgtm" comment result in the prow bot adding the `lgtm` label. Note that a pull request still needs an `approve` label from one of the owners.
Reviewers or members who want to become reviewers according to the [k8s membership ladder](https://github.com/kubernetes/community/blob/master/community-membership.md), could actively search for [pull requests that need a review](https://github.com/kubernetes/ingress-nginx/pulls?q=is%3Aopen+is%3Apr+label%3Atriage%2Faccepted).
## Support Channels
@ -41,3 +47,6 @@ Whether you are a user or contributor, official support channels include:
Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of.
## New Contributor Tips
If you're a new contributor, you can follow the [New Contributor Tips guide](NEW_CONTRIBUTOR.md)
As any kind of contributor (triage, reviewer ...), always have in mind that if a user came to us and raised an issue, the user may have a real problem. We must assume that, and not the opposite (the user needs to prove to us that this is a bug). Keeping that in mind, **be nice with users, even if you don’t agree with them**
Note that this guide refers to contributing through issue triaging. If you are interested in contributing to actual sources of the repository, see [this guide](./CONTRIBUTING.md).
## General Information
The triage process of the ingress-nginx maintainers is based on the [triage process guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) of the Kubernetes community
However the exact process of the ingress-nginx maintainers may differ in certain aspects. This doc gives a more precise overview on how the ingress-nginx maintainers approach the issue triage process and other processes that are related.
## Triage Flow (Issues)
This section describes the different stages of the triage flow for issues.
### Prepare Issues
New issues come in with the labels `needs-triage` and `needs-priority` and one of: `kind/bug`, `kind/feature` or `kind/support`. Unfortunately there are also some legacy issues that only have a `kind/*` label but neither `needs-triage` nor `needs-priority` . However for every issue that does not have the `triage-accepted` label the following steps have to be done to prepare them for further processing:
* Filter for issues [without the `triage-accepted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+-label%3Atriage%2Faccepted+is%3Aissue) label.
* Check if all necessary information are available. This is basically true, if people filled out the issue template correctly. If necessary information is missing, ask the author to add the missing information and add the label `triage/needs-information` if not already present. If already present, send the author a friendly reminder to add those.
* Check if the used versions of ingress-nginx and Kubernetes is supported. Note that [we only support n-3 versions](https://github.com/kubernetes/ingress-nginx#support-versions-table). If the version is not supported, ask the author to upgrade to newer versions and see if the error still persists.
* Read through the issue description and comments briefly to understand what the issue is about. Also check if the kind and area is correct, and adjust it if necessary. If the issue is understandable add the label `triage-accepted`.
* If at any point you don't know how to proceed with an issue during the triage process, tag one of the [core maintainers](OWNERS_ALIASES) in the issue to raise attention or alternatively come to [this slack channel](https://kubernetes.slack.com/archives/C021E147ZA4) which may be the quicker way as people tend to miss github notifications.
Note: Issues that are stale for 90 days are being closed automatically. However we could be missing a bug here, so from time to time it makes sense to go over the closed ones and see if there is something important. Use [this filter](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aclosed+is%3Aissue+label%3Alifecycle%2Frotten+) to find those.
Who and When?
* Basically everyone who wants to contribute can do the mentioned steps at any time.
### Issue Prioritization
For all issues, where all necessary information is available thus triage is accepted, we need to do some prioritization:
* Go through all issues with label [`triage-accepted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3Atriage%2Faccepted+).
* Add appropriate priority label: `priority/backlog`, `priority/critical-urgent`, `priority/awaiting-more-evidence`, `priority/important-longterm`, `priority/important-soon` or `good first issue`
Who and When?
* Basically every contributor should be able to do that.
* Tricky/important ones could be brought up during community meetings
## Triage Flow (Pull Requests)
This section describes the different stages of the triage flow for pull requests.
### Prepare Pull Requests
Pull requests come in with the labels `needs-triage`, `needs-priority` and `needs-kind` and one that indicates the size(`size/*`). Unfortunately there are also some legacy pull requests that only have a `size/*` label but neither `needs-triage` nor `needs-priority` . However for every pull request that does not have the `triage-accepted` label the following steps should be done to prepare them for further processing:
* Filter for pull requests [without the `triage-accepted`](https://github.com/kubernetes/ingress-nginx/pulls?q=is%3Aopen+-label%3Atriage%2Faccepted+is%3Apr) label.
* Check if the cla is signed and all necessary information are available. This is basically true, if people filled out the pull request template correctly. If everything is fine add the `triage-accepted` label.
* If at any point you don't know how to proceed with an issue during the triage process, tag one of the [core maintainers](OWNERS_ALIASES) in the issue to raise attention or alternatively come to [this slack channel](https://kubernetes.slack.com/archives/C021E147ZA4) which may be the quicker way as people tend to miss github notifications.
Who and When?
* Basically everyone who wants to contribute can do the mentioned steps at any time.
### Pull Request Prioritization
For all pull requests, where all necessary information is available and cla is signed thus triage is accepted, we need to do some prioritization:
* Go through all pull requests with label [`triage-accepted`](https://github.com/kubernetes/ingress-nginx/pulls?q=is%3Aopen+is%3Apr+label%3Atriage%2Faccepted).
* Sync the `kind/*` and `priority/*` label from the linked issue for the pull request. If the pull request does not have any issue associated (which normally should not be the case), add an appropriate priority and kind label (one of: `priority/backlog`, `priority/critical-urgent`, `priority/important-longterm`, `priority/important-soon`)
Who and When?
* Basically every contributor should be able to do that.
* Tricky/important ones could be brought up during community meetings
## Labels
Labels are helpful for issues or pull requests to indicate in which lifecycle state they are currently and to categorize them. This section describes the most important ones with the additional info about how to add those. A complete label list of the Kubernetes community can be found [here](https://github.com/kubernetes/kubernetes/labels) while a complete label list for this project can be found [here](https://github.com/kubernetes/ingress-nginx/labels). However, here the most important ones:
* Triage:
* [`needs-triage`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds-triage): Indicates that the issue or pull request needs triage. Automatically added.
* [`triage/accepted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Atriage%2Faccepted+is%3Aissue+): Indicates that the issue is ready for further processing. Add with `/triage accepted`.
* [`triage/needs-information`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Atriage%2Fneeds-information+is%3Aissue+): Indicates that the issue lacks information. Add with `/triage needs-information`.
* Kind:
* [`kind/bug`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Akind%2Fbug+is%3Aissue): Indicates that the issue is assumed to be a bug. Add with `/kind bug`. Remove with `/remove-kind bug`.
* [`kind/feature`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Akind%2Ffeature+is%3Aissue+): Indicates that the issue is a feature request. Add with `/kind feature`. Remove with `/remove-kind feature`.
* [`kind/documentation`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Akind%2Fdocumentation+is%3Aissue+): Indicates that the issue is documentation related. Add with `/kind documentation`. Remove with `/remove-kind documentation`.
* [`kind/support`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Akind%2Fsupport+is%3Aissue+): Indicates the the issue is a support request. Add with `/kind support`. Remove with `/remove-kind support`.
* Area:
* [`area/helm`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Aarea%2Fhelm+is%3Aissue+): Indicates that the issue is related to helm charts. Add with `/area helm`.
* [`area/lua`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Aarea%2Flua+is%3Aissue+): Indicates that the issue is related to lua. Add with `/area lua`.
* [`area/docs`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Aarea%2Fdocs+is%3Aissue): Indicates that the issue is related to documentation. Add with `/area docs` .
* Priority:
* [`needs-priority`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds-priority): Indicates that the issue has no prioritization yet. Automatically added.
* [`priority/critical-urgent`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Apriority%2Fcritical-urgent+is%3Aissue+): indicates that the issue has highest priority. Add with `/priority critical-urgent`.
* [`priority/important-soon`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Apriority%2Fimportant-soon+is%3Aissue+): indicates that the issue should be worked on either currently soon, ideally in time for the next release. Add with `/priority important-soon`.
* [`priority/important-longterm`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Apriority%2Fimportant-longterm+is%3Aissue+): indicates that the issue is not important for now, but should be worked on in one of the upcoming releases. Add with `/priority important-longterm`.
* [`priority/backlog`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Apriority%2Fbacklog+is%3Aissue+): Indicates that the issue has the lowest priority. Add with `/priority backlog`.
* Other:
* [`help wanted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22): indicates that the issue needs help from a contributor. Add with `/help`.
* [`good first issue`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22): indicates that the issue needs help from a contributor and is a good first issue for new contributors. Add with `/good-first-issue`.
## 1. BUILD the new Ingress-Nginx-Controller image
### a. Make changes in codebase
- Make changes as per issue
### b. Make changes to appropriate files in [images directory ](images)
- Make changes in /images
### c. Create Pull Request
- Open a Pull Request for your changes considering the following steps to fire cloudbuild of a new image for the Ingress-Nginx-Controller:
- In case of rare CVE fix or other reason to rebuild the nginx-base-image itself, look at the /images directory [NGINX Base Image](https://github.com/kubernetes/ingress-nginx/tree/main/images/nginx).
- Example [NGINX_VERSION](images/nginx/rootfs/build.sh#L21), [SHA256](images/nginx/rootfs/build.sh#L124).
- If you are updating any component in [build.sh](images/nginx/rootfs/build.sh) please also update the SHA256 checksum of that component as well, the cloud build will fail with an exit 10 if not.
### d. Merge
- Merging will fire cloudbuild, which will result in images being promoted to the [staging container registry](https://console.cloud.google.com/gcr/images/k8s-staging-ingress-nginx).
### e. Make sure cloudbuild is a success
- Wait for [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx). If you don't have access to cloudbuild, you can also have a look at [this](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), to see the progress of the build.
- Proceed only after cloud-build is successful in building a new Ingress-Nginx-Controller image.
## 2. If applicable, BUILD other images
- If applicable, then build a new image of any other related component, ONLY IF APPLICABLE TO THE RELEASE
### a. If applicable then make changes in relevant codebase
- Change code as per issue
### b. Make changes to appropriate files in [images directory ](images)
- Sometimes, you may also be needing to rebuild, images for one or multiple other related components of the Ingress-Nginx-Controller ecosystem. Make changes to the required files in the /images directory, if/as applicable, in the context of the release you are attempting. :
- Open pull request(s) accordingly, to fire cloudbuild for rebuilding the component's image (if applicable).
### d. Merge
- Merging will fire cloudbuild, which will result in images being promoted to the [staging container registry](https://console.cloud.google.com/gcr/images/k8s-staging-ingress-nginx).
### e. Make sure cloudbuild is a success
- Wait for [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx). If you don't have access to cloudbuild, you can also have a look at [this](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), to see the progress of the build.
- Proceed only after cloud-build is successful in building a new Ingress-Nginx-Controller image.
## 3. PROMOTE the Image(s):
Promoting the images basically means that images, that were pushed to staging container registry in the steps above, now are also pushed to the public container registry. Thus are publicly available. Follow these steps to promote images:
### a. Get the sha
- Get the sha of the new image(s) of the controller, (and any other component image IF APPLICABLE to release), from the cloudbuild, from steps above
- The sha is available in output from [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx)
- The sha is also visible here https://console.cloud.google.com/gcr/images/k8s-staging-ingress-nginx/global/controller
- The sha is also visible [here](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), after cloud build is finished. Click on the respective job, go to `Artifacts` section in the UI, then again `artifacts` in the directory browser. In the `build.log` at the very bottom you see something like this:
```
...
pushing manifest for us-central1-docker.pkg.dev/k8s-staging-images/ingress-nginx/controller:v1.0.2@sha256:e15fac6e8474d77e1f017edc33d804ce72a184e3c0a30963b2a0d7f0b89f6b16
...
```
### b. Add the new image to [k8s.io](http://github.com/kubernetes/k8s.io)
- The sha(s) from the step before (and the tag(s) for the new image(s) have to be added, as a new line, in a file, of the [k8s.io](http://github.com/kubernetes/k8s.io) project of Kubernetes organization.
- Fork that other project (if you don't have a fork already).
- Other project to fork [GitHub repo kubernetes/k8s.io](http://github.com/kubernetes/k8s.io)
- Fetch --all and rebase to upstream if already forked.
- Create a branch in your fork, named as the issue number for this release
- In the related branch, of your fork, edit the file /registry.k8s.io/images/k8s-staging-ingress-nginx/images.yaml.
- For making, it easier, you can edit your branch directly in the browser. But be careful about making any mistake.
- Insert the sha(s) & the tag(s), in a new line, in this file [Project kubernetes/k8s.io Ingress-Nginx-Controller Images](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/images/k8s-staging-ingress-nginx/images.yaml) Look at this [example PR and the diff](https://github.com/kubernetes/k8s.io/pull/2536) to see how it was done before
- Save and commit
### c. Create PR
- Open pull request to promote the new controller image.
### d. Merge
- Merge success is required for next step
- Proceed only after cloud-build is successful in building a new Ingress-Nginx-Controller image.
## 4. PREPARE for a new Release
- Make sure to get the tag and sha of the promoted image from the step before, either from cloudbuild or from [here](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/ingress-nginx/controller).
- This involves editing of several files. So carefully follow the steps below and double check all changes with diff/grep etc., repeatedly. Mistakes here impact endusers.
### a. Make sure your git workspace is ready
- Get your git workspace ready
- If not using a pre-existing fork, then Fork the repo kubernetes/ingress-nginx
- Clone (to laptop or wherever)
- Add upstream
- Set upstream url to no_push
- Checkout & switch to branch, named as per related new-release-issue-number
- If already forked, and upstream already added, then `git fetch --all` and `git rebase upstream/main` (not origin)
- Checkout a branch in your fork's clone
- Perform any other diligence as needed
- Prefer to edit only and only in your branch, in your Fork
- Change the below-mentioned [Fields in Chart.yaml](https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/Chart.yaml)
- version
- appVersion
- kubeVersion (**ONLY if applicable**)
- annotations
- artifacthub.io/prerelease: "true"
- artifacthub.io/changes: |
- Replace this line and other lines under this annotation with the Changelog. One process to generate the Changelog is described below
- Install and configure GitHub cli as per the docs of gh-cli https://cli.github.com/,
- Change dir to your clone, of your fork, of the ingress-nginx project
- Run the below command and save the output to a txt file
```
gh pr list -R kubernetes/ingress-nginx -s merged -L 38 -B main | cut -f1,2 | tee ~/Downloads/prlist.txt
```
- The -L 38 was used for 2 reasons.
- Default number of results is 30 and there were more than 30 PRs merged while releasing v1.1.1. If you see the current/soon-to-be-old changelog, you can look at the most recent PR number that has been accounted for already, and start from after that last accounted for PR.
- The other reason to use -L 38 was to omit the 39th, the 40th and the 41st line in the resulting list. These were non-relevant PRs.
- If you save the output of above command to a file called prlist.txt. It looks somewhat like this ;
```
% cat ~/Downloads/prlist.txt
8129 fix syntax in docs for multi-tls example
8120 Update go in runner and release v1.1.1
8119 Update to go v1.17.6
8118 Remove deprecated libraries, update other libs
8117 Fix codegen errors
8115 chart/ghaction: set the correct permission to have access to push a release
....
```
You can delete the lines, that refer to PRs of the release process itself. We only need to list the feature/bugfix PRs. You can also delete the lines that are housekeeping or not really worth mentioning in the changelog.
- you use some easy automation in bash/python/other, to get the PR-List that can be used in the changelog. For example, it's possible to use a bash scripty way, seen below, to convert those plaintext PR numbers into clickable links.
- If you saved the bash script content above, in a file like `$HOME/bin/prlist_to_changelog.sh`, then you could execute a command like this to get your prlist in a text file called changelog_content.txt;`
```
prlist_to_changelog.sh ~/Downloads/prlist.txt | tee ~/Downloads//changelog_content.txt
```
### d. Edit the values.yaml and run helm-docs
- [Fields to edit in values.yaml](https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/values.yaml)
- tag
- digest
- [helm-docs](https://github.com/norwoodj/helm-docs) is a tool that generates the README.md for a Helm chart automatically. In the CI pipeline workflow of GitHub actions (.github/workflows/ci.yaml), you can see how helm-docs is used. The CI pipeline is not designed to make commits back into the project, so we need to run helm-docs manually and commit the resulting generated README.md. You can obtain a recent version of the helm-docs binary here: https://github.com/norwoodj/helm-docs/releases.
```
helm-docs --chart-search-root charts
git diff charts/ingress-nginx/README.md
```
Take care of not leaving the helm-docs executable in your clone workspace or not committing the new README.md.
### e. Edit the static manifests
- Prepare to use a script to update the edit the static manifests and set the "image", "digest", "version" etc. fields to the desired value.
- This script depends on kustomize and helm. The versions are pinned in `hack/.tool-versions` and you can use [asdf](https://github.com/asdf-vm/asdf#asdf) to install them
- Execute the script to update static manifests using that script [hack/generate-deploy-scripts.sh](https://github.com/kubernetes/ingress-nginx/blob/main/hack/generate-deploy-scripts.sh)
- Open some of the manifests and check if the script worked properly
- Use `grep -ir image: | less` on the deploy directory, to view for any misses by the script on image digest value or other undesired changes. The script should properly set the image and the digest fields to the desired tag and semver
- Each time a release is made, a new section is added to the Changelog.md file
- A new section in the Changelog.md file consists of 3 components listed below
- the "Image"
- the "Description"
- the "PRs list"
- Look at the previous content to understand what the 3 components look like.
- You can easily get the "Image" from a yaml manifest but be sure to look at a manifest in your git clone now and not the upstream on github. This is because, if you are following this documentation, then you generated manifests with new updated digest for the image, in step 4e above. You also most likely promoted the new image in a step above. Look at the previous release section in Changelog.md. The format looks like `registry.k8s.io/ingress-nginx/controller:.......`. One example of a yaml file to look at is /deploy/static/provider/baremetal/deploy.yaml (in your git clone branch and not on the upstream).
- Next, you need to have a good overview of the changes introduced in this release and based on that you write a description. Look at previous descriptions. Ask the ingress-nginx-dev channel if required.
- And then you need to add a list of the PRs merged, since the previous release.
- One process to generate this list of PRs is already described above in step 4c. So if you are following this document, then you have done this already and very likely have retained the file containing the list of PRs, in the format that is needed.
### g. Edit the Documentation:
- Update the version in [docs/deploy/index.md](docs/deploy/index.md)
- Update Supported versions in the Support Versions table in the README.md
- Execute the script to update e2e docs [hack/generate-e2e-suite-doc.sh](https://github.com/kubernetes/ingress-nginx/blob/main/hack/generate-e2e-suite-doc.sh)
### h. Update README.md
- Update the table in README.md in the root of the project to reflect the support matrix. Add the new release version and details in there.
## 5. RELEASE new version
### a. Create PR
- Open PR for releasing the new version of the Ingress-Nginx-Controller ;
- Look at this PR for how it was done before [example PR](https://github.com/kubernetes/ingress-nginx/pull/7490)
- Create a PR
### b. Merge
- Merge should produce manifests as well as chart
- Check
- `helm repo update`
- `helm search repo ingress-nginx`
## 6. GitHub release
- Release to github
- Edit the ghpages file as needed
## TODO
- Automate & simplify as much as possible, whenever possible, however possible
Welcome to the Ingress Nginx new contributor tips.
This guide briefly outlines the necessary knowledge & tools, required to start working on Ingress-NGINX Issues.
### Prerequisites
- Basic understanding of linux
- Familiarity with the command line on linux
- OSI Model(Links below)
### Introduction
It all starts with the OSI model...
> The Open Systems Interconnection (OSI) model describes seven layers that computer systems use to communicate over a network. It was the first standard model for network communications, adopted by all major computer and telecommunication companies

#### Reading material for OSI Model
[OSI Model CertificationKits](https://www.certificationkits.com/cisco-certification/cisco-ccna-640-802-exam-certification-guide/cisco-ccna-the-osi-model/)
### Approaching the problem
Not everybody knows everything. But the factors that help are a love/passion for this to begin. But to move forward, it's the approach and not the knowledge that sustains prolonged joy, while working on issues. If the approach is simple and powered by good-wishes-for-community, then info & tools are forthcoming and easy.
Here we take a bird's eye-view of the hops in the network plumbing, that a packet takes, from source to destination, when we run `curl`, from a laptop to a nginx webserver process, running in a container, inside a pod, inside a Kubernetes cluster, created using `kind` or `minikube` or any other cluster-management tool.
### [Kind](https://kind.sigs.k8s.io/) cluster example on a Linux Host
#### TL;DR
The destination of the packet from the curl command, is looked up, in the `routing table`. Based on the route, the packet first travels to the virtual bridge `172.18.0.1` interface, created by docker, when we created the kind cluster on a laptop. Next the packet is forwarded to `172.18.0.2`(See below on how we got this IP address), within the kind cluster. The `kube-proxy` container creates iptables rules that make sure the packet goes to the correct pod ip in this case `10.244.0.5`
Command:
```
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
230e7246a32c kindest/node:v1.24.1 "/usr/local/bin/entr…" 2 weeks ago Up 54 seconds 127.0.0.1:38143->6443/tcp kind-control-plane
If this part is confusing, you would first need to understand what a [bridge](https://tldp.org/HOWTO/BRIDGE-STP-HOWTO/what-is-a-bridge.html) is and what [docker network](https://docs.docker.com/network/) is.
#### The journey of a curl packet.
Let's begin with creating a [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) Cluster on your laptop
```
# kind create cluster
```
This will create a cluster called `kind`, to view the clusters type
```
# kind get clusters
kind
```
Kind ships with `kubectl`, so we can use that to communicate with our clusters.
```
# kubectl get no -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
Output Relevance: From the above output, we can see that our nginx pod is being exposed as the `NodePort` service type, and now we can curl the Node IP `172.18.0.2` with the exposed port `32329`
Command: The pod has an IP as shown below
```
# kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
From the above output we can see that, there are two bridges connected to our systems network interface,one is the docker default bridge`docker0` and the other created by kind
`br-2fffe5cd5d9e`.
Since kind creates nodes as containers, this is easily accessible via `docker ps`.
```
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
230e7246a32c kindest/node:v1.24.1 "/usr/local/bin/entr…" 6 days ago Up 33 hours 127.0.0.1:38143->6443/tcp kind-control-plane
```
If we do a docker `exec` we can enter the container, we can also see the network interfaces within the container.
```
# docker exec -it 230e7246a32c bash
# root@kind-control-plane:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-2fffe5cd5d9e
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-be5b544733a3
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ethbr0
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ethbr0
192.168.39.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr2
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
```
Output Relevance: From the above output, you can see that the `iface`(Interface) for `172.18.0.0` is `br-2fffe5cd5d9e`, which means traffic that needs to go to `172.18.0.0` will go through `br-2fffe5cd5d9e` which is created by docker for the kind container (this is the node in case of kind cluster).
Now we need to understand how the packet travels from the container interface to the pod with IP `10.244.0.5`. The component that handles this is called kube-proxy
So what exactly is [kube-proxy](https://kubernetes.io/docs/concepts/overview/components/#kube-proxy):
> Kube-Proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.
kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster
So, as we can see that kube proxy handles the network rules required to aid the communication to the pods, we will look at the [iptables](https://linux.die.net/man/8/iptables)
> `iptables` is a command line interface used to set up and maintain tables for the Netfilter firewall for IPv4, included in the Linux kernel. The firewall matches packets with rules defined in these tables and then takes the specified action on a possible match. Tables is the name for a set of chains
Command:
```
# iptables -t nat -L PREROUTING -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service portals */
DOCKER_OUTPUT all -- 0.0.0.0/0 172.18.0.1
CNI-HOSTPORT-DNAT all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
```
```
# iptables-save | grep PREROUTING
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
```
Output Relevance:
> -A: append new iptable rule
> -j: jump to the target
> KUBE-SERVICES: target
> The above output appends a new rule for PREROUTING which every network packet will go through first as they try to access any kubernetes service
What is `PREROUTING` in iptables?
>PREROUTING: This chain is used to make any routing related decisions before (PRE) sending any packets
To dig in further we need to go to the target, `KUBE-SERVICES` for our nginx service.
As you can see the rules added by `kube-proxy` helps the packet reach to the destination service.
### Minikube KVM VM Example on Linux
#### TL;DR
Now we look at the curl packet journey on minikube. The `routing table` is looked up to know the destination of the curl packet. The packet then first travels to the virtual bridge `192.168.39.1`, created by minikube kvm2 driver, when we created the minikube cluster, on a linux laptop. Then this packet is forwarded to `192.168.39.57`, within the minikube VM. We have docker containers running in the VM. Among them, the `kube-proxy` container creates iptables rules that make sure the packet goes to the correct pod ip, in this case `172.17.0.4`.
To begin with the minikube example, we first need to create a minikube cluster on a linux laptop. In this example I'll be using the `kvm2` driver option for `minikube start` command, as default.
```
minikube start
😄 minikube v1.26.0 on Arch "rolling"
🆕 Kubernetes 1.24.2 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.24.2
✨ Using the kvm2 driver based on existing profile
👍 Starting control plane node minikube in cluster minikube
🏃 Updating the running kvm2 "minikube" VM ...
🐳 Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
▪ kubelet.housekeeping-interval=5m
🔎 Verifying Kubernetes components...
▪ Using image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1
▪ Using image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1
▪ Using image registry.k8s.io/ingress-nginx/controller:v1.2.1
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
Minikube creates a Virtual Machine using the KVM2 driver(Other drivers such as Virtualbox do exist see `minikube start --help` for more information ), you should be able to see this with the following output(You may have to use sudo to get this output)
```
$ virsh --connect qemu:///system list
Id Name State
--------------------------
1 minikube running
or
$ sudo virsh list
Id Name State
--------------------------
1 minikube running
```
Moving on, simply create a nginx deployment using `kubectl`.
Output Relevance: From the above output, we can see that our nginx pod is being exposed as the `NodePort` service type, and now we can curl the Node IP `192.168.39.57` with the exposed port `32007`
Command: The pod has an IP as shown below
```
# kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
Output Relevance: From the above output you can see there are two Virtual Bridges created by minikube when we created the cluster on the network. Here, `virbr0` is the default NAT network bridge while `virbr2` is a isolated network bridge on which the pods run.
Minikube creates a Virtual Machine, to enter the virtual machine we can simply do:
```
# minikube ssh
```
The interfaces within the Virtual Machine are as follows.
```
docker0 Link encap:Ethernet HWaddr 02:42:03:24:26:78
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-2fffe5cd5d9e
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-be5b544733a3
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ethbr0
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ethbr0
192.168.39.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr2
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
```
Output Relevance: As you can see multiple routes are defined here, of which our Virtual Machine Node IP(192.168.39.57) is also shown in the table, so the packet now knows where it has to go.
With that clear we now know how the packet goes from the laptop to the virtual bridge and then enters the Virtual Machine.
Inside the virtual machine, [kube-proxy](https://kubernetes.io/docs/concepts/overview/components/#kube-proxy) handles the routing using iptables.
So what exactly is [kube-proxy](https://kubernetes.io/docs/concepts/overview/components/#kube-proxy)(For those who skipped the kind example):
> Kube-Proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.
kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster
So, as we can see that kube proxy handles the network rules required to aid the communication to the pods, we will look at the [iptables](https://linux.die.net/man/8/iptables)
> `iptables` is a command line interface used to set up and maintain tables for the Netfilter firewall for IPv4, included in the Linux kernel. The firewall matches packets with rules defined in these tables and then takes the specified action on a possible match. Tables is the name for a set of chains
As you can see the rules added by kube-proxy helps the packet reach to the destination service.
### Connection termination
Connection termination is a type of event that occurs when there are load balancers present, the information for this is quite scarce, however I've found the following article, [IBM - Network Termination](https://www.ibm.com/docs/en/sva/9.0.4?topic=balancer-network-termination) that describes what it means by connection termination between clients(laptop) and server(load balancer) and the various other services.
### Different types of connection errors.
The following article on [TCP/IP errors](https://www.ibm.com/docs/en/db2/11.1?topic=message-tcpip-errors) has a list of the important tcp timeout errors that we need to know.
| No space is left on a device or system table.|The disk partition is full|
|No route to the host is available.|The routing table doesn't know where to route the packet.|
|Connection was reset by the partner.|This usually means the packet was dropped as soon as it reached the server can be due to a firewall.|
|The connection was timed out.|This indicates the firewall blocking your connection or the connection took too long.|
## OSI Model Layer 7 (Application Layer)
[What is layer 7?](https://www.cloudflare.com/learning/ddos/what-is-layer-7/)
#### Summary
Layer 7 refers to the seventh and topmost layer of the Open Systems Interconnect (OSI) Model known as the application layer. This is the highest layer which supports end-user processes and applications. Layer 7 identifies the communicating parties and the quality of service between them, considers privacy and user authentication, as well as identifies any constraints on the data syntax. This layer is wholly application-specific.
## Setting up Ingress-Nginx Controller
Since we are doing this on our local laptop, we are going to use the following tools:
- [Minikube using KVM driver](https://minikube.sigs.k8s.io/docs/start/) - The host is linux-based in our example
### So let's begin with Metallb and Ingress-Nginx setup.
For setting up metallb, we are going to follow the below steps:
- To begin the installation, we will execute:
```
minikube start
```
- To install Metallb, one can install it using the [manifest](https://metallb.universe.tf/installation/#installation-by-manifest) or by using [helm](https://metallb.universe.tf/installation/#installation-with-helm), for now we will use the Manifest method:
- We need to now configure Metallb, we are using [Layer 2 configuration](https://metallb.universe.tf/configuration/#announce-the-service-ips), let's head over to the [Metallb Configuration](https://metallb.universe.tf/configuration/) website, here you will see how to setup metallb.
>Layer 2 mode does not require the IPs to be bound to the network interfaces of your worker nodes. It works by responding to ARP requests on your local network directly, to give the machine’s MAC address to clients.
In order to advertise the IP coming from an IPAddressPool, an L2Advertisement instance must be associated to the IPAddressPool.
- We have modified the IP address pool so that our loadbalancer knows which subnet to choose an IP from.Since we have only one minikube IP we need to modify the code given in the documentation.
Save this as `metallb-config.yaml`:
```
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: first-pool
namespace: metallb-system
spec:
addresses:
# The configuration website show's you this
#- 192.168.10.0/24
#- 192.168.9.1-192.168.9.5
#- fc00:f853:0ccd:e799::/124
# We are going to change this to `minikube ip` as such
- 192.168.39.57/32
```
Now deploy it using `kubectl`
```
kubectl apply -f metallb-config.yaml
```
- Now that metallb is setup, let's install [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/#quick-start) on the laptop.
Note: We are using the install by manifest option from the Installation manual
The above output, creates an ingress, for us with the rule to match the service if the host is `httpd.dev.leonnunes.com`. The class here is retrieved from the below command.
We have setup `Ingress-Nginx`, using `nginx` as a class and `httpd` for this example.
In order to display the info on Layer - 7, we have extracted the Layer 7 information from a simple `curl` request, and then using `tcpdump` command within the `httpd` pod we extracted the network packets and opened it using the `Wireshark` utility.
The above output shows the information that the `httpd` pod receives. The `curl` command sends the host header, `Host: httpd.dev.leonnunes.com`, to the nginx controller, that then matches the rule and sends the information to the right controller
The following output shows what is sent via the laptop.
* Added httpd.dev.leonnunes.com:80:192.168.39.57 to DNS cache
* Trying 192.168.39.57:80...
* Connected to 192.168.39.57 (192.168.39.57) port 80 (#0)
> GET / HTTP/1.1
> Host: httpd.dev.leonnunes.com
> User-Agent: curl/7.84.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
<HTTP/1.1200OK
<Date:Mon,22Aug202216:05:27GMT
<Content-Type:text/html
<Content-Length:45
<Connection:keep-alive
<Last-Modified:Mon,11Jun200718:53:14GMT
<ETag:"2d-432a5e4a73a80"
<Accept-Ranges:bytes
<
<html><body><h1>It works!</h1></body></html>
* Connection #0 to host 192.168.39.57 left intact
```
As you can see from the above output there are several headers added to the curl output after it reaches the `httpd` pod, these headers are added by the Ingress Nginx Controller.
- [netstat](https://www.lifewire.com/netstat-command-2618098) - List network details
- [curl](https://linuxhandbook.com/curl-command-examples/) - Curl a website from the command line
- [ifconfig](https://www.tecmint.com/ifconfig-command-examples/)/[ip](https://www.geeksforgeeks.org/ip-command-in-linux-with-examples/) - Show ip address configuration
## Help us to improve the NGINX Ingress controller [completing the survey](https://docs.google.com/forms/d/15ULTOvYDsV920V0GWrspew4yyjEmTAi740Wr34UgKwA/viewform)
ingress-nginx is an Ingress controller for Kubernetes using [NGINX](https://www.nginx.org/) as a reverse proxy and load balancer.
ingress-nginx is an Ingress controller for Kubernetes using [NGINX](https://www.nginx.org/) as a reverse proxy and load
balancer.
Learn more about Ingress on the main [Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/) documentation site.
[Learn more about Ingress on the Kubernetes documentation site](https://kubernetes.io/docs/concepts/services-networking/ingress/).
## Get started
See the [Getting Started](https://kubernetes.github.io/ingress-nginx/deploy/) document.
Do not use in multi-tenant Kubernetes production installations. This project assumes that users that can create Ingress objects are administrators of the cluster. See the [FAQ](https://kubernetes.github.io/ingress-nginx/faq/#faq) for more.
## Troubleshooting
If you encounter issues, review the [troubleshooting docs](docs/troubleshooting.md), [file an issue](https://github.com/kubernetes/ingress-nginx/issues), or talk to us on the [#ingress-nginx channel](https://kubernetes.slack.com/messages/ingress-nginx) on the Kubernetes Slack server.
## Contributing
Thanks for taking the time to join our community and start contributing!
- This project adheres to the [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md). By participating in this project, you agree to abide by its terms.
- See [CONTRIBUTING.md](CONTRIBUTING.md) for 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](https://github.com/kubernetes/ingress-nginx).
- Read [`CONTRIBUTING.md`](CONTRIBUTING.md) and check out [help-wanted](https://github.com/kubernetes/ingress-nginx/labels/help%20wanted) issues
- Submit github issues for any feature enhancements, bugs or documentation problems
- **Support**: Join to [Kubernetes Slack](http://slack.kubernetes.io/) in the [#ingress-nginx](https://kubernetes.slack.com/messages/CANQGM8BA/) channel to ask questions to get support from the maintainers and other users
- The [github issues](https://github.com/kubernetes/ingress-nginx/issues) in the repository are **exclusively** for bug reports and feature requests.
- **Discuss**: Tweet using the `#IngressNginx` hashtag
Supported versions for the ingress-nginx project mean that we have completed E2E tests, and they are passing for
the versions listed. Ingress-Nginx versions **may** work on older versions, but the project does not make that guarantee.
## Issues
| Supported | Ingress-NGINX version | k8s supported version | Alpine Version | Nginx Version | Helm Chart Version |
Please make sure to read the [Issue Reporting Checklist](https://github.com/kubernetes/ingress-nginx/blob/master/CONTRIBUTING.md#issue-reporting-guidelines) before opening an issue. Issues not conforming to the guidelines **may be closed immediately**.
See [this article](https://kubernetes.io/blog/2021/07/26/update-with-ingress-nginx/) if you want upgrade to the stable
Ingress API.
## Get Involved
Thanks for taking the time to join our community and start contributing!
- This project adheres to the [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md).
By participating in this project, you agree to abide by its terms.
- **Contributing**: Contributions of all kinds are welcome!
- Read [`CONTRIBUTING.md`](CONTRIBUTING.md) for information about setting up your environment, the workflow that we
expect, and instructions on the developer certificate of origin that we require.
- Submit GitHub issues for any feature enhancements, bugs, or documentation problems.
- Please make sure to read the [Issue Reporting Checklist](https://github.com/kubernetes/ingress-nginx/blob/main/CONTRIBUTING.md#issue-reporting-guidelines) before opening an issue. Issues not conforming to the guidelines **may be closed immediately**.
- Join the [#ingress-nginx-users](https://kubernetes.slack.com/messages/CANQGM8BA/) channel inside the [Kubernetes Slack](http://slack.kubernetes.io/) to ask questions or get support from the maintainers and other users.
- The [GitHub issues](https://github.com/kubernetes/ingress-nginx/issues) in the repository are **exclusively** for bug reports and feature requests.
- **Discuss**: Tweet using the `#IngressNginx` hashtag or sharing with us [@IngressNginx](https://twitter.com/IngressNGINX).
* Adapt dashboards for Grafana 11 compatibility (#11399)
* Rename variable to fix typo (#11395)
* Fix helm install on cloud provider admonition block (#11394)
* edited helm-install tips (#11393)
* added info for aws helm install (#11390)
* added multiplecontrollers-howto to faq (#11389)
* removed tlsv1 & tlsv1.1 (#11343)
* feat: Add grpc timeouts annotations (#11258)
* sfix position of options (#11379)
* add workflow to helm release and update ct for branch (#11378)
* Accept user defined annotations in IngressClass (#11362)
* Docs: Remove opentracing and zipkin from docs (#11361)
* Allow configuring nginx worker reload behaviour, to prevent multiple concurrent worker reloads which can lead to high resource usage and OOMKill (#10884)
* chore(deps): group update k8s.io packages to v0.30.0 (#11344)
* Fix function name in comment (#11296)
* fix path in file changed detected message (#11271)
* chore: fix function names in comment (#11280)
* fix: update kube version requirement to 1.21 (#11275)
* release helm chart from release branch (#11276)
* update k8s version to latest kind release (#11240)
* feat: add annotation to allow to add custom response headers (#9742)
* remove _ssl_expire_time_seconds metric by identifier (#9706)
* update post submit helm ci and clean up (#11220)
* Chart: Add unit tests for default backend & topology spread constraints. (#11218)
* sort default backend hpa metrics (#11215)
* updated certgen image shatag (#11214)
* feature(default_backend): topologySpreadConstraints on default backend (#11197)
* bumped certgeimage tag (#11212)
* changed testrunner image sha (#11207)
* updated baseimage & deleted a useless file (#11208)
* Chart: Make `controller.config` templatable. (#11181)
* chunking related faq update (#11196)
* bump ginkgo to 2-17-1 in testrunner (#11202)
* Owners: Promote Gacko to `ingress-nginx-maintainers`&`ingress-nginx-reviewers`. (#11165)
* Fix-semver (#11193)
* refactor helm ci tests part I (#11178)
* fixes brotli build issue (#10484)
* bump ginkgo to v2.17.1 (#11177)
* Proposal: e2e tests for regex patterns (#11174)
* Controller: Make Leader Election TTL configurable. (#11142)
This changes the default of the following CLI arguments:
* `--enable-metrics` gets disabled by default.
* Tests & Docs: Bump `e2e-test-echo` to v1.0.1. (#12147)
* Images: Trigger `e2e-test-echo` build. (#12140)
* ⚠️ Images: Drop `s390x`. (#12137) ⚠️
Support for the `s390x` architecture has already been removed from the controller image. This also removes it from the NGINX base image and CI relevant images.
* Images: Build `s390x` controller. (#12126)
* Chart: Bump Kube Webhook CertGen. (#12119)
* Tests & Docs: Bump images. (#12118)
* Cloud Build: Bump `gcb-docker-gcloud` to v20240718-5ef92b5c36. (#12113)
* Images: Trigger other builds. (#12110)
* Tests: Bump `e2e-test-runner` to v20241004-114a6abb. (#12103)
OpenTelemetry is still supported, but since the module is built into the controller image since v1.10, we hereby remove the init container and image which were used to install it upon controller startup.
* Tests: Bump `e2e-test-runner` to v20241104-02a3933e. (#12312)
* Docs: Add CPU usage note for `--metrics-per-undefined-host`. (#12310)
* Images: Trigger `test-runner` build. (#12308)
* Config: Fix panic on invalid `lua-shared-dict`. (#12283)
* Docs: fix limit-rate-after references (#12278)
* Chart: Rework ServiceMonitor. (#12269)
* Chart: Add ServiceAccount tests. (#12263)
* CI: Fix chart testing. (#12258)
* [fix] fix nginx temp configs cleanup (#12225)
* Chart: Suggest `matchLabelKeys` in Topology Spread Constraints. (#12202)
* Docs: Add Pod Security Admission. (#12195)
* Docs: Clarify external & service port in TCP/UDP services explanation. (#12192)
* Images: Trigger controller build. (#12154)
* ⚠️ Metrics: Disable by default. (#12153) ⚠️
This changes the default of the following CLI arguments:
* `--enable-metrics` gets disabled by default.
* Tests & Docs: Bump `e2e-test-echo` to v1.0.1. (#12147)
* Images: Trigger `e2e-test-echo` build. (#12140)
* ⚠️ Images: Drop `s390x`. (#12137) ⚠️
Support for the `s390x` architecture has already been removed from the controller image. This also removes it from the NGINX base image and CI relevant images.
* Images: Build `s390x` controller. (#12126)
* Chart: Bump Kube Webhook CertGen. (#12119)
* Tests & Docs: Bump images. (#12118)
* Cloud Build: Bump `gcb-docker-gcloud` to v20240718-5ef92b5c36. (#12113)
* Images: Trigger other builds. (#12110)
* Tests: Bump `e2e-test-runner` to v20241004-114a6abb. (#12103)
OpenTelemetry is still supported, but since the module is built into the controller image since v1.10, we hereby remove the init container and image which were used to install it upon controller startup.
* update all container tags with date and sha, upgrade all containers (#9834)
* updated NGINX_BASE image in project (#9829)
* ISO 8601 date format (#9682)
* Values: Fix indention of commented values. (#9812)
* The Ingress-Nginx project recently released version 1.7.0 of the controller, but the deployment documentation still referenced version 1.6.4. This commit updates the documentation to reference the latest version, ensuring that users have access to the most up-to-date information. Fixes#9787 (#9788)
### Dependency updates:
* Bump github.com/opencontainers/runc from 1.1.6 to 1.1.7 (#9912)
* Bump github.com/prometheus/client_golang from 1.14.0 to 1.15.0 (#9868)
* Bump aquasecurity/trivy-action from 0.9.2 to 0.10.0 (#9888)
* Bump github.com/opencontainers/runc from 1.1.5 to 1.1.6 (#9867)
* Bump actions/checkout from 3.5.0 to 3.5.2 (#9870)
* Bump golang.org/x/crypto from 0.7.0 to 0.8.0 (#9838)
* Bump github.com/spf13/cobra from 1.6.1 to 1.7.0 (#9839)
* Bump actions/add-to-project from 0.4.1 to 0.5.0 (#9840)
* Bump actions/checkout from 3.4.0 to 3.5.0 (#9798)
* Bump ossf/scorecard-action from 2.1.2 to 2.1.3 (#9823)
* Bump github.com/opencontainers/runc from 1.1.4 to 1.1.5 (#9806)
* Bump actions/stale from 7.0.0 to 8.0.0 (#9799)
* Bump rajatjindal/krew-release-bot from 0.0.43 to 0.0.46 (#9797)
* Bump actions/setup-go from 3.5.0 to 4.0.0 (#9796)
* Bump github.com/imdario/mergo from 0.3.13 to 0.3.15 (#9795)
* Bump google.golang.org/grpc from 1.53.0 to 1.54.0 (#9794)
* Bump sigs.k8s.io/controller-runtime from 0.14.5 to 0.14.6 (#9822)
* Update documentation to reflect project name; Ingress-Nginx Controller
For improving security, our 1.8.0 release includes a [new, **optional** validation ](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#strict-validate-path-type) that limits the characters accepted on ".spec paths.path" when pathType=Exact or athType=Prefix, to alphanumeric characters only.
More information can be found on our [Google doc](https://docs.google.com/document/d/1HPvaEwHRuMSkXYkVIJ-w7IpijKdHfNynm_4N2Akt0CQ/edit?usp=sharing), our new [ingress-nginx-dev mailing list](https://groups.google.com/a/kubernetes.io/g/ingress-nginx-dev/c/ebbBMo-zX-w) or in our [docs](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#strict-validate-path-type)
### Community Updates
We are now posting updates and release to our twitter handle, [@IngressNginx](https://twitter.com/IngressNGINX) and
on our new [ingress-nginx-dev mailing list](https://groups.google.com/a/kubernetes.io/g/ingress-nginx-dev/c/ebbBMo-zX-w)
### All changes:
* Add legacy to OpenTelemetry migration doc (#10011)
* changed tagsha to recent builds (#10001)
* change to alpine318 baseimage (#10000)
* images: upgrade to Alpine 3.18 (#9997)
* openssl CVE fix (#9996)
* PodDisruptionBudget spec logic update (#9904)
* Admission warning (#9975)
* Add OPA examples on pathType restrictions (#9992)
* updated testrunner image tag+sha (#9987)
* bumped ginkgo to v2.9.5 (#9985)
* helm: Fix opentelemetry module installation for daemonset (#9792)
* OpenTelemetry default config (#9978)
* Correct annotations in monitoring docs (#9976)
* fix: avoid builds and tests for changes to markdown (#9962)
* Validate path types (#9967)
* HPA: Use capabilities & align manifests. (#9521)
* Use dl.k8s.io instead of hardcoded GCS URIs (#9946)
* add option for annotations in PodDisruptionBudget (#9843)
* chore: update httpbin to httpbun (#9919)
* image_update (#9942)
* Add geoname id value into $geoip2_*_geoname_id variables (#9527)
* Update annotations.md (#9933)
* Update charts/* to keep project name display aligned (#9931)
* Keep project name display aligned (#9920)
### Dependencies updates:
* Bump github.com/imdario/mergo from 0.3.15 to 0.3.16 (#10008)
* Bump github.com/prometheus/common from 0.43.0 to 0.44.0 (#10007)
* Bump k8s.io/klog/v2 from 2.90.1 to 2.100.1 (#9913)
* Bump github.com/onsi/ginkgo/v2 from 2.9.0 to 2.9.5 (#9980)
* Bump golang.org/x/crypto from 0.8.0 to 0.9.0 (#9982)
* Bump actions/setup-go from 4.0.0 to 4.0.1 (#9984)
* Bump securego/gosec from 2.15.0 to 2.16.0 (#9983)
* Bump github.com/prometheus/common from 0.42.0 to 0.43.0 (#9981)
* Bump github.com/prometheus/client_model from 0.3.0 to 0.4.0 (#9937)
* Bump google.golang.org/grpc from 1.54.0 to 1.55.0 (#9936)
* netlify: Only trigger preview when there are changes in docs. (#10144)
* changed to updated baseimage and reverted tag (#10143)
* Fix loadBalancerClass value (#10139)
* Added a doc line to the missing helm value service.internal.loadBalancerIP (#9406)
* Set grpc :authority header from request header (#8912)
* bump pinned golang to 1.20.5 (#10127)
* update test runner (#10125)
* chore: remove echo from snippet tests (#10110)
* Update typo in docs for lb scheme (#10117)
* golang 1.20.5 bump (#10120)
* feat(helm): Add loadBalancerClass (#9562)
* chore: remove echo friom canary tests (#10089)
* fix: obsolete warnings (#10029)
* docs: change Dockefile url ref main (#10087)
* Revert "Remove fastcgi feature" (#10081)
* docs: add netlify configuration (#10073)
* add distroless otel init (#10035)
* chore: move httpbun to be part of framework (#9955)
* Remove fastcgi feature (#9864)
* Fix mirror-target values without path separator and port (#9889)
* Adding feature to upgrade Oracle Cloud Infrastructure's Flexible Load Balancer and adjusting Health Check that were critical in the previous configuration (#9961)
* add support for keda fallback settings (#9993)
* unnecessary use of fmt.Sprint (S1039) (#10049)
* chore: pkg imported more than once (#10048)
* tracing: upgrade to dd-opentracing-cpp v1.3.7 (#10031)
* fix: add canary to sidebar in examples (#10068)
* docs: add lua testing documentation (#10060)
* docs: canary weighted deployments example (#10067)
The command deploys ingress-nginx on the Kubernetes cluster in the default configuration.
@ -37,11 +36,7 @@ _See [helm install](https://helm.sh/docs/helm/helm_install/) for command documen
## Uninstall Chart
```console
# Helm 3
$ helm uninstall [RELEASE_NAME]
# Helm 2
# helm delete --purge [RELEASE_NAME]
helm uninstall [RELEASE_NAME]
```
This removes all the Kubernetes components associated with the chart and deletes the release.
@ -51,16 +46,11 @@ _See [helm uninstall](https://helm.sh/docs/helm/helm_uninstall/) for command doc
## Upgrading Chart
```console
# Helm 3 or 2
$ helm upgrade [RELEASE_NAME] [CHART] --install
helm upgrade [RELEASE_NAME] [CHART] --install
```
_See [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) for command documentation._
### Upgrading With Zero Downtime in Production
By default the ingress-nginx controller has service interruptions whenever it's pods are restarted or redeployed. In order to fix that, see the excellent blog post by Lindsay Landry from Codecademy: [Kubernetes: Nginx and Zero Downtime in Production](https://medium.com/codecademy-engineering/kubernetes-nginx-and-zero-downtime-in-production-2c910c6a5ed8).
### Migrating from stable/nginx-ingress
There are two main ways to migrate a release from `stable/nginx-ingress` to `ingress-nginx/ingress-nginx` chart:
@ -71,7 +61,6 @@ There are two main ways to migrate a release from `stable/nginx-ingress` to `ing
1. Redirect your DNS traffic from the old controller to the new controller
1. Log traffic from both controllers during this changeover
1. [Uninstall](#uninstall-chart) the old controller once traffic has fully drained from it
1. For details on all of these steps see [Upgrading With Zero Downtime in Production](#upgrading-with-zero-downtime-in-production)
Note that there are some different and upgraded configurations between the two charts, described by Rimas Mocevicius from JFrog in the "Upgrading to ingress-nginx Helm chart" section of [Migrating from Helm chart nginx-ingress to ingress-nginx](https://rimusz.net/migrating-to-ingress-nginx). As the `ingress-nginx/ingress-nginx` chart continues to update, you will want to check current differences by running [helm configuration](#configuration) commands on both charts.
@ -80,11 +69,7 @@ Note that there are some different and upgraded configurations between the two c
See [Customizing the Chart Before Installing](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing). To see all configurable options with detailed comments, visit the chart's [values.yaml](./values.yaml), or run these configuration commands:
```console
# Helm 2
$ helm inspect values ingress-nginx/ingress-nginx
# Helm 3
$ helm show values ingress-nginx/ingress-nginx
helm show values ingress-nginx/ingress-nginx
```
### PodDisruptionBudget
@ -94,21 +79,22 @@ else it would make it impossible to evacuate a node. See [gh issue #7127](https:
### Prometheus Metrics
The Nginx ingress controller can export Prometheus metrics, by setting `controller.metrics.enabled` to `true`.
The Ingress-Nginx Controller can export Prometheus metrics, by setting `controller.metrics.enabled` to `true`.
You can add Prometheus annotations to the metrics service using `controller.metrics.service.annotations`. Alternatively, if you use the Prometheus Operator, you can enable ServiceMonitor creation using `controller.metrics.serviceMonitor.enabled`.
You can add Prometheus annotations to the metrics service using `controller.metrics.service.annotations`.
Alternatively, if you use the Prometheus Operator, you can enable ServiceMonitor creation using `controller.metrics.serviceMonitor.enabled`. And set `controller.metrics.serviceMonitor.additionalLabels.release="prometheus"`. "release=prometheus" should match the label configured in the prometheus servicemonitor ( see `kubectl get servicemonitor prometheus-kube-prom-prometheus -oyaml -n prometheus`)
### ingress-nginx nginx\_status page/stats server
Previous versions of this chart had a `controller.stats.*` configuration block, which is now obsolete due to the following changes in nginx ingress controller:
Previous versions of this chart had a `controller.stats.*` configuration block, which is now obsolete due to the following changes in Ingress-Nginx Controller:
- In [0.16.1](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0161), the vts (virtual host traffic status) dashboard was removed
- In [0.23.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0230), the status page at port 18080 is now a unix socket webserver only available at localhost.
You can use `curl --unix-socket /tmp/nginx-status-server.sock http://localhost/nginx_status` inside the controller container to access it locally, or use the snippet from [nginx-ingress changelog](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0230) to re-enable the http server
- In [0.16.1](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0161), the vts (virtual host traffic status) dashboard was removed
- In [0.23.0](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0230), the status page at port 18080 is now a unix socket webserver only available at localhost.
You can use `curl --unix-socket /tmp/nginx-status-server.sock http://localhost/nginx_status` inside the controller container to access it locally, or use the snippet from [nginx-ingress changelog](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0230) to re-enable the http server
### ExternalDNS Service Configuration
Add an [ExternalDNS](https://github.com/kubernetes-incubator/external-dns) annotation to the LoadBalancer service:
Add an [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) annotation to the LoadBalancer service:
```yaml
controller:
@ -119,7 +105,7 @@ controller:
### AWS L7 ELB with SSL Termination
Annotate the controller as shown in the [nginx-ingress l7 patch](https://github.com/kubernetes/ingress-nginx/blob/master/deploy/aws/l7/service-l7.yaml):
Annotate the controller as shown in the [nginx-ingress l7 patch](https://github.com/kubernetes/ingress-nginx/blob/ab3a789caae65eec4ad6e3b46b19750b481b6bce/deploy/aws/l7/service-l7.yaml):
To configure the LoadBalancer service with the [route53-mapper addon](https://github.com/kubernetes/kops/tree/master/addons/route53-mapper), add the `domainName` annotation and `dns` label:
```yaml
controller:
service:
labels:
dns: "route53"
annotations:
domainName: "kubernetes-example.com"
```
### Additional Internal Load Balancer
This setup is useful when you need both external and internal load balancers but don't want to have multiple ingress controllers and multiple ingress objects per application.
The load balancer annotations of more cloud service providers can be found: [Internal load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer).
An use case for this scenario is having a split-view DNS setup where the public zone CNAME records point to the external balancer URL while the private zone CNAME records point to the internal balancer URL. This way, you only need one ingress kubernetes object.
Optionally you can set `controller.service.loadBalancerIP` if you need a static IP for the resulting `LoadBalancer`.
### Ingress Admission Webhooks
With nginx-ingress-controller version 0.25+, the nginx ingress controller pod exposes an endpoint that will integrate with the `validatingwebhookconfiguration` Kubernetes feature to prevent bad ingress from being added to the cluster.
With nginx-ingress-controller version 0.25+, the Ingress-Nginx Controller pod exposes an endpoint that will integrate with the `validatingwebhookconfiguration` Kubernetes feature to prevent bad ingress from being added to the cluster.
**This feature is enabled by default since 0.31.0.**
With nginx-ingress-controller in 0.25.* work only with kubernetes 1.14+, 0.26 fix [this issue](https://github.com/kubernetes/ingress-nginx/pull/4521)
#### How the Chart Configures the Hooks
A validating and configuration requires the endpoint to which the request is sent to use TLS. It is possible to set up custom certificates to do this, but in most cases, a self-signed certificate is enough. The setup of this component requires some more complex orchestration when using helm. The steps are created to be idempotent and to allow turning the feature on and off without running into helm quirks.
1. A pre-install hook provisions a certificate into the same namespace using a format compatible with provisioning using end user certificates. If the certificate already exists, the hook exits.
2. The Ingress-Nginx Controller pod is configured to use a TLS proxy container, which will load that certificate.
3. Validating and Mutating webhook configurations are created in the cluster.
4. A post-install hook reads the CA from the secret created by step 1 and patches the Validating and Mutating webhook configurations. This process will allow a custom CA provisioned by some other process to also be patched into the webhook configurations. The chosen failure policy is also patched into the webhook configurations
#### Alternatives
It should be possible to use [cert-manager/cert-manager](https://github.com/cert-manager/cert-manager) if a more complete solution is required.
You can enable automatic self-signed TLS certificate provisioning via cert-manager by setting the `controller.admissionWebhooks.certManager.enabled` value to true.
Please ensure that cert-manager is correctly installed and configured.
### Helm Error When Upgrading: spec.clusterIP: Invalid value: ""
If you are upgrading this chart from a version between 0.31.0 and 1.2.2 then you may get an error like this:
@ -208,3 +228,349 @@ Error: UPGRADE FAILED: Service "?????-controller" is invalid: spec.clusterIP: In
Detail of how and why are in [this issue](https://github.com/helm/charts/pull/13646) but to resolve this you can set `xxxx.service.omitClusterIP` to `true` where `xxxx` is the service referenced in the error.
As of version `1.26.0` of this chart, by simply not providing any clusterIP value, `invalid: spec.clusterIP: Invalid value: "": field is immutable` will no longer occur since `clusterIP: ""` will not be rendered.
### Pod Security Admission
You can use Pod Security Admission by applying labels to the `ingress-nginx` namespace as instructed by the [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels).
Example:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: ingress-nginx
labels:
kubernetes.io/metadata.name: ingress-nginx
name: ingress-nginx
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.31
```
## Values
| Key | Type | Default | Description |
|-----|------|---------|-------------|
| commonLabels | object | `{}` | |
| controller.addHeaders | object | `{}` | Will add custom headers before sending response traffic to the client according to: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#add-headers |
| controller.affinity | object | `{}` | Affinity and anti-affinity rules for server scheduling to nodes # Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity # |
| controller.allowSnippetAnnotations | bool | `false` | This configuration defines if Ingress Controller should allow users to set their own *-snippet annotations, otherwise this is forbidden / dropped when users add those annotations. Global snippets in ConfigMap are still respected |
| controller.annotations | object | `{}` | Annotations to be added to the controller Deployment or DaemonSet # |
| controller.autoscaling.maxReplicas | int | `11` | |
| controller.autoscaling.minReplicas | int | `1` | |
| controller.autoscaling.targetCPUUtilizationPercentage | int | `50` | |
| controller.autoscaling.targetMemoryUtilizationPercentage | int | `50` | |
| controller.autoscalingTemplate | list | `[]` | |
| controller.config | object | `{}` | Global configuration passed to the ConfigMap consumed by the controller. Values may contain Helm templates. Ref.: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/ |
| controller.configAnnotations | object | `{}` | Annotations to be added to the controller config configuration configmap. |
| controller.configMapNamespace | string | `""` | Allows customization of the configmap / nginx-configmap namespace; defaults to $(POD_NAMESPACE) |
| controller.containerName | string | `"controller"` | Configures the controller container name |
| controller.containerPort | object | `{"http":80,"https":443}` | Configures the ports that the nginx-controller listens on |
| controller.dnsConfig | object | `{}` | Optionally customize the pod dnsConfig. |
| controller.dnsPolicy | string | `"ClusterFirst"` | Optionally change this to ClusterFirstWithHostNet in case you have 'hostNetwork: true'. By default, while using host network, name resolution uses the host's DNS. If you wish nginx-controller to keep resolving names inside the k8s network, use ClusterFirstWithHostNet. |
| controller.electionID | string | `""` | Election ID to use for status update, by default it uses the controller name combined with a suffix of 'leader' |
| controller.electionTTL | string | `""` | Duration a leader election is valid before it's getting re-elected, e.g. `15s`, `10m` or `1h`. (Default: 30s) |
| controller.enableMimalloc | bool | `true` | Enable mimalloc as a drop-in replacement for malloc. # ref: https://github.com/microsoft/mimalloc # |
| controller.enableTopologyAwareRouting | bool | `false` | This configuration enables Topology Aware Routing feature, used together with service annotation service.kubernetes.io/topology-mode="auto" Defaults to false |
| controller.extraArgs | object | `{}` | Additional command line arguments to pass to Ingress-Nginx Controller E.g. to specify the default SSL certificate you can use |
| controller.extraContainers | list | `[]` | Additional containers to be added to the controller pod. See https://github.com/lemonldap-ng-controller/lemonldap-ng-controller as example. |
| controller.extraEnvs | list | `[]` | Additional environment variables to set |
| controller.extraInitContainers | list | `[]` | Containers, which are run before the app containers are started. |
| controller.extraModules | list | `[]` | Modules, which are mounted into the core nginx image. |
| controller.extraVolumeMounts | list | `[]` | Additional volumeMounts to the controller main container. |
| controller.extraVolumes | list | `[]` | Additional volumes to the controller pod. |
| controller.healthCheckHost | string | `""` | Address to bind the health check endpoint. It is better to set this option to the internal node address if the Ingress-Nginx Controller is running in the `hostNetwork: true` mode. |
| controller.healthCheckPath | string | `"/healthz"` | Path of the health check endpoint. All requests received on the port defined by the healthz-port parameter are forwarded internally to this path. |
| controller.hostAliases | list | `[]` | Optionally customize the pod hostAliases. |
| controller.hostNetwork | bool | `false` | Required for use with CNI based kubernetes installations (such as ones set up by kubeadm), since CNI and hostport don't mix yet. Can be deprecated once https://github.com/kubernetes/kubernetes/issues/23920 is merged |
| controller.hostPort.enabled | bool | `false` | Enable 'hostPort' or not |
| controller.hostPort.ports.http | int | `80` | 'hostPort' http port |
| controller.hostPort.ports.https | int | `443` | 'hostPort' https port |
| controller.hostname | object | `{}` | Optionally customize the pod hostname. |
| controller.image.runAsGroup | int | `82` | This value must not be changed using the official image. uid=101(www-data) gid=82(www-data) groups=82(www-data) |
| controller.image.runAsUser | int | `101` | This value must not be changed using the official image. uid=101(www-data) gid=82(www-data) groups=82(www-data) |
| controller.ingressClass | string | `"nginx"` | For backwards compatibility with ingress.class annotation, use ingressClass. Algorithm is as follows, first ingressClassName is considered, if not present, controller looks for ingress.class annotation |
| controller.ingressClassByName | bool | `false` | Process IngressClass per name (additionally as per spec.controller). |
| controller.ingressClassResource | object | `{"aliases":[],"annotations":{},"controllerValue":"k8s.io/ingress-nginx","default":false,"enabled":true,"name":"nginx","parameters":{}}` | This section refers to the creation of the IngressClass resource. IngressClasses are immutable and cannot be changed after creation. We do not support namespaced IngressClasses, yet, so a ClusterRole and a ClusterRoleBinding is required. |
| controller.ingressClassResource.aliases | list | `[]` | Aliases of this IngressClass. Creates copies with identical settings but the respective alias as name. Useful for development environments with only one Ingress Controller but production-like Ingress resources. `default` gets enabled on the original IngressClass only. |
| controller.ingressClassResource.annotations | object | `{}` | Annotations to be added to the IngressClass resource. |
| controller.ingressClassResource.controllerValue | string | `"k8s.io/ingress-nginx"` | Controller of the IngressClass. An Ingress Controller looks for IngressClasses it should reconcile by this value. This value is also being set as the `--controller-class` argument of this Ingress Controller. Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class |
| controller.ingressClassResource.default | bool | `false` | If true, Ingresses without `ingressClassName` get assigned to this IngressClass on creation. Ingress creation gets rejected if there are multiple default IngressClasses. Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/#default-ingress-class |
| controller.ingressClassResource.enabled | bool | `true` | Create the IngressClass or not |
| controller.ingressClassResource.name | string | `"nginx"` | Name of the IngressClass |
| controller.ingressClassResource.parameters | object | `{}` | A link to a custom resource containing additional configuration for the controller. This is optional if the controller consuming this IngressClass does not require additional parameters. Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class |
| controller.kind | string | `"Deployment"` | Use a `DaemonSet` or `Deployment` |
| controller.labels | object | `{}` | Labels to be added to the controller Deployment or DaemonSet and other resources that do not have option to specify labels # |
| controller.lifecycle | object | `{"preStop":{"exec":{"command":["/wait-shutdown"]}}}` | Improve connection draining when ingress controller pod is deleted using a lifecycle hook: With this new hook, we increased the default terminationGracePeriodSeconds from 30 seconds to 300, allowing the draining of connections up to five minutes. If the active connections end before that, the pod will terminate gracefully at that time. To effectively take advantage of this feature, the Configmap feature worker-shutdown-timeout new value is 240s instead of 10s. # |
| controller.livenessProbe.failureThreshold | int | `5` | |
| controller.metrics.service.enabled | bool | `true` | Enable the metrics service or not. |
| controller.metrics.service.externalIPs | list | `[]` | List of IP addresses at which the stats-exporter service is available # Ref: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips # |
| controller.metrics.service.labels | object | `{}` | Labels to be added to the metrics service resource |
| controller.metrics.service.loadBalancerSourceRanges | list | `[]` | |
| controller.metrics.service.servicePort | int | `10254` | |
| controller.metrics.serviceMonitor.labelLimit | int | `0` | Per-scrape limit on number of labels that will be accepted for a sample. |
| controller.metrics.serviceMonitor.labelNameLengthLimit | int | `0` | Per-scrape limit on length of labels name that will be accepted for a sample. |
| controller.metrics.serviceMonitor.labelValueLengthLimit | int | `0` | Per-scrape limit on length of labels value that will be accepted for a sample. |
| controller.metrics.serviceMonitor.metricRelabelings | list | `[]` | |
| controller.metrics.serviceMonitor.targetLabels | list | `[]` | |
| controller.metrics.serviceMonitor.targetLimit | int | `0` | Defines a limit on the number of scraped targets that will be accepted. |
| controller.minAvailable | int | `1` | Minimum available pods set in PodDisruptionBudget. Define either 'minAvailable' or 'maxUnavailable', never both. |
| controller.minReadySeconds | int | `0` | `minReadySeconds` to avoid killing pods before we are ready # |
| controller.name | string | `"controller"` | |
| controller.networkPolicy.enabled | bool | `false` | Enable 'networkPolicy' or not |
| controller.nodeSelector | object | `{"kubernetes.io/os":"linux"}` | Node labels for controller pod assignment # Ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ # |
| controller.podAnnotations | object | `{}` | Annotations to be added to controller pods # |
| controller.podLabels | object | `{}` | Labels to add to the pod container metadata |
| controller.progressDeadlineSeconds | int | `0` | Specifies the number of seconds you want to wait for the controller deployment to progress before the system reports back that it has failed. Ref.: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#progress-deadline-seconds |
| controller.proxySetHeaders | object | `{}` | Will add custom headers before sending traffic to backends according to https://github.com/kubernetes/ingress-nginx/tree/main/docs/examples/customization/custom-headers |
| controller.publishService | object | `{"enabled":true,"pathOverride":""}` | Allows customization of the source of the IP address or FQDN to report in the ingress status field. By default, it reads the information provided by the service. If disable, the status field reports the IP address of the node or nodes where an ingress controller pod is running. |
| controller.publishService.enabled | bool | `true` | Enable 'publishService' or not |
| controller.publishService.pathOverride | string | `""` | Allows overriding of the publish service to bind to Must be <namespace>/<service_name> |
| controller.readinessProbe.failureThreshold | int | `3` | |
| controller.readinessProbe.initialDelaySeconds | int | `10` | |
| controller.readinessProbe.periodSeconds | int | `10` | |
| controller.readinessProbe.successThreshold | int | `1` | |
| controller.readinessProbe.timeoutSeconds | int | `1` | |
| controller.replicaCount | int | `1` | |
| controller.reportNodeInternalIp | bool | `false` | Bare-metal considerations via the host network https://kubernetes.github.io/ingress-nginx/deploy/baremetal/#via-the-host-network Ingress status was blank because there is no Service exposing the Ingress-Nginx Controller in a configuration using the host network, the default --publish-service flag used in standard cloud setups does not apply |
| controller.scope.enabled | bool | `false` | Enable 'scope' or not |
| controller.scope.namespace | string | `""` | Namespace to limit the controller to; defaults to $(POD_NAMESPACE) |
| controller.scope.namespaceSelector | string | `""` | When scope.enabled == false, instead of watching all namespaces, we watching namespaces whose labels only match with namespaceSelector. Format like foo=bar. Defaults to empty, means watching all namespaces. |
| controller.service.annotations | object | `{}` | Annotations to be added to the external controller service. See `controller.service.internal.annotations` for annotations to be added to the internal controller service. |
| controller.service.appProtocol | bool | `true` | Declare the app protocol of the external HTTP and HTTPS listeners or not. Supersedes provider-specific annotations for declaring the backend protocol. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol |
| controller.service.clusterIP | string | `""` | Pre-defined cluster internal IP address of the external controller service. Take care of collisions with existing services. This value is immutable. Set once, it can not be changed without deleting and re-creating the service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address |
| controller.service.clusterIPs | list | `[]` | Pre-defined cluster internal IP addresses of the external controller service. Take care of collisions with existing services. This value is immutable. Set once, it can not be changed without deleting and re-creating the service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address |
| controller.service.enableHttp | bool | `true` | Enable the HTTP listener on both controller services or not. |
| controller.service.enableHttps | bool | `true` | Enable the HTTPS listener on both controller services or not. |
| controller.service.enabled | bool | `true` | Enable controller services or not. This does not influence the creation of either the admission webhook or the metrics service. |
| controller.service.external.enabled | bool | `true` | Enable the external controller service or not. Useful for internal-only deployments. |
| controller.service.external.labels | object | `{}` | Labels to be added to the external controller service. |
| controller.service.externalIPs | list | `[]` | List of node IP addresses at which the external controller service is available. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips |
| controller.service.externalTrafficPolicy | string | `""` | External traffic policy of the external controller service. Set to "Local" to preserve source IP on providers supporting it. Ref: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip |
| controller.service.internal.annotations | object | `{}` | Annotations to be added to the internal controller service. Mandatory for the internal controller service to be created. Varies with the cloud service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer |
| controller.service.internal.appProtocol | bool | `true` | Declare the app protocol of the internal HTTP and HTTPS listeners or not. Supersedes provider-specific annotations for declaring the backend protocol. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol |
| controller.service.internal.clusterIP | string | `""` | Pre-defined cluster internal IP address of the internal controller service. Take care of collisions with existing services. This value is immutable. Set once, it can not be changed without deleting and re-creating the service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address |
| controller.service.internal.clusterIPs | list | `[]` | Pre-defined cluster internal IP addresses of the internal controller service. Take care of collisions with existing services. This value is immutable. Set once, it can not be changed without deleting and re-creating the service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address |
| controller.service.internal.enabled | bool | `false` | Enable the internal controller service or not. Remember to configure `controller.service.internal.annotations` when enabling this. |
| controller.service.internal.externalIPs | list | `[]` | List of node IP addresses at which the internal controller service is available. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips |
| controller.service.internal.externalTrafficPolicy | string | `""` | External traffic policy of the internal controller service. Set to "Local" to preserve source IP on providers supporting it. Ref: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip |
| controller.service.internal.ipFamilies | list | `["IPv4"]` | List of IP families (e.g. IPv4, IPv6) assigned to the internal controller service. This field is usually assigned automatically based on cluster configuration and the `ipFamilyPolicy` field. Ref: https://kubernetes.io/docs/concepts/services-networking/dual-stack/#services |
| controller.service.internal.ipFamilyPolicy | string | `"SingleStack"` | Represents the dual-stack capabilities of the internal controller service. Possible values are SingleStack, PreferDualStack or RequireDualStack. Fields `ipFamilies` and `clusterIP` depend on the value of this field. Ref: https://kubernetes.io/docs/concepts/services-networking/dual-stack/#services |
| controller.service.internal.labels | object | `{}` | Labels to be added to the internal controller service. |
| controller.service.internal.loadBalancerClass | string | `""` | Load balancer class of the internal controller service. Used by cloud providers to select a load balancer implementation other than the cloud provider default. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-class |
| controller.service.internal.loadBalancerIP | string | `""` | Deprecated: Pre-defined IP address of the internal controller service. Used by cloud providers to connect the resulting load balancer service to a pre-existing static IP. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer |
| controller.service.internal.loadBalancerSourceRanges | list | `[]` | Restrict access to the internal controller service. Values must be CIDRs. Allows any source address by default. |
| controller.service.internal.nodePorts.http | string | `""` | Node port allocated for the internal HTTP listener. If left empty, the service controller allocates one from the configured node port range. |
| controller.service.internal.nodePorts.https | string | `""` | Node port allocated for the internal HTTPS listener. If left empty, the service controller allocates one from the configured node port range. |
| controller.service.internal.nodePorts.tcp | object | `{}` | Node port mapping for internal TCP listeners. If left empty, the service controller allocates them from the configured node port range. Example: tcp: 8080: 30080 |
| controller.service.internal.nodePorts.udp | object | `{}` | Node port mapping for internal UDP listeners. If left empty, the service controller allocates them from the configured node port range. Example: udp: 53: 30053 |
| controller.service.internal.sessionAffinity | string | `""` | Session affinity of the internal controller service. Must be either "None" or "ClientIP" if set. Defaults to "None". Ref: https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity |
| controller.service.internal.trafficDistribution | string | `""` | Traffic distribution policy of the internal controller service. Set to "PreferClose" to route traffic to endpoints that are topologically closer to the client. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#traffic-distribution |
| controller.service.internal.type | string | `""` | Type of the internal controller service. Defaults to the value of `controller.service.type`. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types |
| controller.service.ipFamilies | list | `["IPv4"]` | List of IP families (e.g. IPv4, IPv6) assigned to the external controller service. This field is usually assigned automatically based on cluster configuration and the `ipFamilyPolicy` field. Ref: https://kubernetes.io/docs/concepts/services-networking/dual-stack/#services |
| controller.service.ipFamilyPolicy | string | `"SingleStack"` | Represents the dual-stack capabilities of the external controller service. Possible values are SingleStack, PreferDualStack or RequireDualStack. Fields `ipFamilies` and `clusterIP` depend on the value of this field. Ref: https://kubernetes.io/docs/concepts/services-networking/dual-stack/#services |
| controller.service.labels | object | `{}` | Labels to be added to both controller services. |
| controller.service.loadBalancerClass | string | `""` | Load balancer class of the external controller service. Used by cloud providers to select a load balancer implementation other than the cloud provider default. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-class |
| controller.service.loadBalancerIP | string | `""` | Deprecated: Pre-defined IP address of the external controller service. Used by cloud providers to connect the resulting load balancer service to a pre-existing static IP. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer |
| controller.service.loadBalancerSourceRanges | list | `[]` | Restrict access to the external controller service. Values must be CIDRs. Allows any source address by default. |
| controller.service.nodePorts.http | string | `""` | Node port allocated for the external HTTP listener. If left empty, the service controller allocates one from the configured node port range. |
| controller.service.nodePorts.https | string | `""` | Node port allocated for the external HTTPS listener. If left empty, the service controller allocates one from the configured node port range. |
| controller.service.nodePorts.tcp | object | `{}` | Node port mapping for external TCP listeners. If left empty, the service controller allocates them from the configured node port range. Example: tcp: 8080: 30080 |
| controller.service.nodePorts.udp | object | `{}` | Node port mapping for external UDP listeners. If left empty, the service controller allocates them from the configured node port range. Example: udp: 53: 30053 |
| controller.service.ports.http | int | `80` | Port the external HTTP listener is published with. |
| controller.service.ports.https | int | `443` | Port the external HTTPS listener is published with. |
| controller.service.sessionAffinity | string | `""` | Session affinity of the external controller service. Must be either "None" or "ClientIP" if set. Defaults to "None". Ref: https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity |
| controller.service.targetPorts.http | string | `"http"` | Port of the ingress controller the external HTTP listener is mapped to. |
| controller.service.targetPorts.https | string | `"https"` | Port of the ingress controller the external HTTPS listener is mapped to. |
| controller.service.trafficDistribution | string | `""` | Traffic distribution policy of the external controller service. Set to "PreferClose" to route traffic to endpoints that are topologically closer to the client. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#traffic-distribution |
| controller.service.type | string | `"LoadBalancer"` | Type of the external controller service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types |
| controller.tcp.annotations | object | `{}` | Annotations to be added to the tcp config configmap |
| controller.tcp.configMapNamespace | string | `""` | Allows customization of the tcp-services-configmap; defaults to $(POD_NAMESPACE) |
| controller.terminationGracePeriodSeconds | int | `300` | `terminationGracePeriodSeconds` to avoid killing pods before we are ready # wait up to five minutes for the drain of connections # |
| controller.tolerations | list | `[]` | Node tolerations for server scheduling to nodes with taints # Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ # |
| controller.topologySpreadConstraints | list | `[]` | Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. # Ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ # |
| controller.udp.annotations | object | `{}` | Annotations to be added to the udp config configmap |
| controller.udp.configMapNamespace | string | `""` | Allows customization of the udp-services-configmap; defaults to $(POD_NAMESPACE) |
| controller.unhealthyPodEvictionPolicy | string | `""` | Eviction policy for unhealthy pods guarded by PodDisruptionBudget. Ref: https://kubernetes.io/blog/2023/01/06/unhealthy-pod-eviction-policy-for-pdbs/ |
| controller.updateStrategy | object | `{}` | The update strategy to apply to the Deployment or DaemonSet # |
| controller.watchIngressWithoutClass | bool | `false` | Process Ingress objects without ingressClass annotation/ingressClassName field Overrides value for --watch-ingress-without-class flag of the controller binary Defaults to false |
| defaultBackend.affinity | object | `{}` | Affinity and anti-affinity rules for server scheduling to nodes # Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity |
| defaultBackend.labels | object | `{}` | Labels to be added to the default backend resources |
| defaultBackend.livenessProbe.failureThreshold | int | `3` | |
| defaultBackend.livenessProbe.initialDelaySeconds | int | `30` | |
| defaultBackend.livenessProbe.periodSeconds | int | `10` | |
| defaultBackend.livenessProbe.successThreshold | int | `1` | |
| defaultBackend.livenessProbe.timeoutSeconds | int | `5` | |
| defaultBackend.minAvailable | int | `1` | Minimum available pods set in PodDisruptionBudget. Define either 'minAvailable' or 'maxUnavailable', never both. |
| defaultBackend.minReadySeconds | int | `0` | `minReadySeconds` to avoid killing pods before we are ready # |
| defaultBackend.service.clusterIPs | list | `[]` | Pre-defined cluster internal IP addresses of the default backend service. Take care of collisions with existing services. This value is immutable. Set once, it can not be changed without deleting and re-creating the service. Ref: https://kubernetes.io/docs/concepts/services-networking/service/#choosing-your-own-ip-address |
| defaultBackend.service.externalIPs | list | `[]` | List of IP addresses at which the default backend service is available # Ref: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips # |
| defaultBackend.service.loadBalancerSourceRanges | list | `[]` | |
| defaultBackend.service.servicePort | int | `80` | |
| defaultBackend.tolerations | list | `[]` | Node tolerations for server scheduling to nodes with taints # Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ # |
| defaultBackend.topologySpreadConstraints | list | `[]` | Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. Ref.: https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ |
| defaultBackend.unhealthyPodEvictionPolicy | string | `""` | Eviction policy for unhealthy pods guarded by PodDisruptionBudget. Ref: https://kubernetes.io/blog/2023/01/06/unhealthy-pod-eviction-policy-for-pdbs/ |
| defaultBackend.updateStrategy | object | `{}` | The update strategy to apply to the Deployment or DaemonSet # |
| dhParam | string | `""` | A base64-encoded Diffie-Hellman parameter. This can be generated with: `openssl dhparam 4096 2> /dev/null | base64` # Ref: https://github.com/kubernetes/ingress-nginx/tree/main/docs/examples/customization/ssl-dh-param |
| imagePullSecrets | list | `[]` | Optional array of imagePullSecrets containing private registry credentials # Ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ |
| namespaceOverride | string | `""` | Override the deployment namespace; defaults to .Release.Namespace |
| portNamePrefix | string | `""` | Prefix for TCP and UDP ports names in ingress controller service # Some cloud providers, like Yandex Cloud may have a requirements for a port name regex to support cloud load balancer integration |
The command deploys ingress-nginx on the Kubernetes cluster in the default configuration.
_See [configuration](#configuration) below._
_See [helm install](https://helm.sh/docs/helm/helm_install/) for command documentation._
## Uninstall Chart
```console
helm uninstall [RELEASE_NAME]
```
This removes all the Kubernetes components associated with the chart and deletes the release.
_See [helm uninstall](https://helm.sh/docs/helm/helm_uninstall/) for command documentation._
## Upgrading Chart
```console
helm upgrade [RELEASE_NAME] [CHART] --install
```
_See [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) for command documentation._
### Migrating from stable/nginx-ingress
There are two main ways to migrate a release from `stable/nginx-ingress` to `ingress-nginx/ingress-nginx` chart:
1. For Nginx Ingress controllers used for non-critical services, the easiest method is to [uninstall](#uninstall-chart) the old release and [install](#install-chart) the new one
1. For critical services in production that require zero-downtime, you will want to:
1. [Install](#install-chart) a second Ingress controller
1. Redirect your DNS traffic from the old controller to the new controller
1. Log traffic from both controllers during this changeover
1. [Uninstall](#uninstall-chart) the old controller once traffic has fully drained from it
Note that there are some different and upgraded configurations between the two charts, described by Rimas Mocevicius from JFrog in the "Upgrading to ingress-nginx Helm chart" section of [Migrating from Helm chart nginx-ingress to ingress-nginx](https://rimusz.net/migrating-to-ingress-nginx). As the `ingress-nginx/ingress-nginx` chart continues to update, you will want to check current differences by running [helm configuration](#configuration) commands on both charts.
## Configuration
See [Customizing the Chart Before Installing](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing). To see all configurable options with detailed comments, visit the chart's [values.yaml](./values.yaml), or run these configuration commands:
```console
helm show values ingress-nginx/ingress-nginx
```
### PodDisruptionBudget
Note that the PodDisruptionBudget resource will only be defined if the replicaCount is greater than one,
else it would make it impossible to evacuate a node. See [gh issue #7127](https://github.com/helm/charts/issues/7127) for more info.
### Prometheus Metrics
The Ingress-Nginx Controller can export Prometheus metrics, by setting `controller.metrics.enabled` to `true`.
You can add Prometheus annotations to the metrics service using `controller.metrics.service.annotations`.
Alternatively, if you use the Prometheus Operator, you can enable ServiceMonitor creation using `controller.metrics.serviceMonitor.enabled`. And set `controller.metrics.serviceMonitor.additionalLabels.release="prometheus"`. "release=prometheus" should match the label configured in the prometheus servicemonitor ( see `kubectl get servicemonitor prometheus-kube-prom-prometheus -oyaml -n prometheus`)
### ingress-nginx nginx\_status page/stats server
Previous versions of this chart had a `controller.stats.*` configuration block, which is now obsolete due to the following changes in Ingress-Nginx Controller:
- In [0.16.1](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0161), the vts (virtual host traffic status) dashboard was removed
- In [0.23.0](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0230), the status page at port 18080 is now a unix socket webserver only available at localhost.
You can use `curl --unix-socket /tmp/nginx-status-server.sock http://localhost/nginx_status` inside the controller container to access it locally, or use the snippet from [nginx-ingress changelog](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0230) to re-enable the http server
### ExternalDNS Service Configuration
Add an [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) annotation to the LoadBalancer service:
Annotate the controller as shown in the [nginx-ingress l7 patch](https://github.com/kubernetes/ingress-nginx/blob/ab3a789caae65eec4ad6e3b46b19750b481b6bce/deploy/aws/l7/service-l7.yaml):
This setup is useful when you need both external and internal load balancers but don't want to have multiple ingress controllers and multiple ingress objects per application.
By default, the ingress object will point to the external load balancer address, but if correctly configured, you can make use of the internal one if the URL you are looking up resolves to the internal load balancer's URL.
You'll need to set both the following values:
`controller.service.internal.enabled`
`controller.service.internal.annotations`
If one of them is missing the internal load balancer will not be deployed. Example you may have `controller.service.internal.enabled=true` but no annotations set, in this case no action will be taken.
`controller.service.internal.annotations` varies with the cloud service you're using.
The load balancer annotations of more cloud service providers can be found: [Internal load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer).
An use case for this scenario is having a split-view DNS setup where the public zone CNAME records point to the external balancer URL while the private zone CNAME records point to the internal balancer URL. This way, you only need one ingress kubernetes object.
Optionally you can set `controller.service.loadBalancerIP` if you need a static IP for the resulting `LoadBalancer`.
### Ingress Admission Webhooks
With nginx-ingress-controller version 0.25+, the Ingress-Nginx Controller pod exposes an endpoint that will integrate with the `validatingwebhookconfiguration` Kubernetes feature to prevent bad ingress from being added to the cluster.
**This feature is enabled by default since 0.31.0.**
With nginx-ingress-controller in 0.25.* work only with kubernetes 1.14+, 0.26 fix [this issue](https://github.com/kubernetes/ingress-nginx/pull/4521)
#### How the Chart Configures the Hooks
A validating and configuration requires the endpoint to which the request is sent to use TLS. It is possible to set up custom certificates to do this, but in most cases, a self-signed certificate is enough. The setup of this component requires some more complex orchestration when using helm. The steps are created to be idempotent and to allow turning the feature on and off without running into helm quirks.
1. A pre-install hook provisions a certificate into the same namespace using a format compatible with provisioning using end user certificates. If the certificate already exists, the hook exits.
2. The Ingress-Nginx Controller pod is configured to use a TLS proxy container, which will load that certificate.
3. Validating and Mutating webhook configurations are created in the cluster.
4. A post-install hook reads the CA from the secret created by step 1 and patches the Validating and Mutating webhook configurations. This process will allow a custom CA provisioned by some other process to also be patched into the webhook configurations. The chosen failure policy is also patched into the webhook configurations
#### Alternatives
It should be possible to use [cert-manager/cert-manager](https://github.com/cert-manager/cert-manager) if a more complete solution is required.
You can enable automatic self-signed TLS certificate provisioning via cert-manager by setting the `controller.admissionWebhooks.certManager.enabled` value to true.
Please ensure that cert-manager is correctly installed and configured.
### Helm Error When Upgrading: spec.clusterIP: Invalid value: ""
If you are upgrading this chart from a version between 0.31.0 and 1.2.2 then you may get an error like this:
```console
Error: UPGRADE FAILED: Service "?????-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable
```
Detail of how and why are in [this issue](https://github.com/helm/charts/pull/13646) but to resolve this you can set `xxxx.service.omitClusterIP` to `true` where `xxxx` is the service referenced in the error.
As of version `1.26.0` of this chart, by simply not providing any clusterIP value, `invalid: spec.clusterIP: Invalid value: "": field is immutable` will no longer occur since `clusterIP: ""` will not be rendered.
### Pod Security Admission
You can use Pod Security Admission by applying labels to the `ingress-nginx` namespace as instructed by the [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels).
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.11.0
* [#5879](https://github.com/kubernetes/ingress-nginx/pull/5879) Update helm chart for v0.34.0
* [#5671](https://github.com/kubernetes/ingress-nginx/pull/5671) Make liveness probe more fault tolerant than readiness probe
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.11.1
* [#5900](https://github.com/kubernetes/ingress-nginx/pull/5900) Release helm chart for v0.34.1
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.11.2
* [#5951](https://github.com/kubernetes/ingress-nginx/pull/5951) Bump chart patch version
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.11.3
* [#6038](https://github.com/kubernetes/ingress-nginx/pull/6038) Bump chart version PATCH
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.12.0
* [#6039](https://github.com/kubernetes/ingress-nginx/pull/6039) Add configurable serviceMonitor metricRelabelling and targetLabels
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.14.0
* [#6104](https://github.com/kubernetes/ingress-nginx/pull/6104) Misc fixes for nginx-ingress chart for better keel and prometheus-operator integration
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.15.0
* [#6087](https://github.com/kubernetes/ingress-nginx/pull/6087) Adding parameter for externalTrafficPolicy in internal controller service spec
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.16.0
* [#6154](https://github.com/kubernetes/ingress-nginx/pull/6154) add `topologySpreadConstraint` to controller
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.9.0
* [#5795](https://github.com/kubernetes/ingress-nginx/pull/5795) Use fully qualified images to avoid cri-o issues
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).
### 2.9.1
* [#5823](https://github.com/kubernetes/ingress-nginx/pull/5823) Add quoting to sysctls because numeric values need to be presented as strings (#5823)
This file documents all notable changes to [ingress-nginx](https://github.com/kubernetes/ingress-nginx) Helm Chart. The release numbering uses [semantic versioning](http://semver.org).