* 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: Chakrit Wichian <service@chakrit.net>
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
* add k8s 1.30 to ci build
Signed-off-by: James Strong <strong.james.e@gmail.com>
* force all ci to run on workflow dispatch
Signed-off-by: James Strong <strong.james.e@gmail.com>
* correct the 1.30 version
Signed-off-by: James Strong <strong.james.e@gmail.com>
* Update .github/workflows/ci.yaml
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
---------
Signed-off-by: James Strong <strong.james.e@gmail.com>
Co-authored-by: James Strong <strong.james.e@gmail.com>
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>
Co-authored-by: Jon Carl <grounded042@joncarl.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
---------
Co-authored-by: Jérémie Tarot <silopolis@gmail.com>
The controller depends on the v1 version of EndpointSlice, but the discovery.k8s.io/v1 API was first introduced in Kubernetes version 1.21.
Co-authored-by: NierYYDS <141559828+NierYYDS@users.noreply.github.com>
* force nginx rebuild
Signed-off-by: James Strong <strong.james.e@gmail.com>
* update test image and go version
Signed-off-by: James Strong <strong.james.e@gmail.com>
---------
Signed-off-by: James Strong <strong.james.e@gmail.com>
Co-authored-by: James Strong <strong.james.e@gmail.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: ramonboorges@gmail.com <ramonboorges@gmail.com>
Co-authored-by: Marco Ebert <marco_ebert@icloud.com>
echo "Please use helm-docs in your clone, of your fork, of the project, and commit a updated README.md for the chart. https://github.com/kubernetes/ingress-nginx/blob/main/RELEASE.md#d-edit-the-valuesyaml-and-run-helm-docs"
This minor version release, introduces 2 breaking changes. For the first time, an option to jail/chroot the nginx process, inside the controller container, is being introduced.. This provides an additional layer of security, for sensitive information like K8S serviceaccounts. This release also brings a special new feature of deep inspection into objects. The inspection is a walk through of all the spec, checking for possible attempts to escape configs. Currently such an inspection only occurs for `networking.Ingress`. Additionally there are fixes for the recently announced CVEs on busybox & ssl_client. And there is a fix to a recently introduced redirection related bug, that was setting the protocol on URLs to "nil".
This minor version release, introduces 2 breaking changes. For the first time, an option to jail/chroot the nginx process, inside the controller container, is being introduced. This provides an additional layer of security, for sensitive information like K8S serviceaccounts. This release also brings a special new feature of deep inspection into objects. The inspection is a walk through of all the spec, checking for possible attempts to escape configs. Currently such an inspection only occurs for `networking.Ingress`. Additionally there are fixes for the recently announced CVEs on busybox & ssl_client. And there is a fix to a recently introduced redirection related bug, that was setting the protocol on URLs to "nil".
This release bumps grpc version to 1.44.0 & runc to version 1.1.0. The release also re-introduces the ingress.class annotation, which was previously declared as deprecated. Besides that, several bug fixes and improvements are listed below.
We have disabled the builtin ssl_session_cache due to possible memory fragmentation. This should not impact the majority of users, but please let us know
We have disabled the builtin ssl_session_cache due to possible memory fragmentation. This should not impact the majority of users, but please let us know
* Ingress controller now (starting from v1.0.0) mandates cluster scoped access to IngressClass. This leads to problems when updating old Ingress controller to newest version, as described [here](https://github.com/kubernetes/ingress-nginx/issues/7510). We plan to fix it in v1.0.4, see [this](https://github.com/kubernetes/ingress-nginx/pull/7578).
* Ingress controller now (starting from v1.0.0) mandates cluster scoped access to IngressClass. This leads to problems when updating old Ingress controller to newest version, as described [here](https://github.com/kubernetes/ingress-nginx/issues/7510). We plan to fix it in v1.0.4, see [this](https://github.com/kubernetes/ingress-nginx/pull/7578).
* Ingress controller now (starting from v1.0.0) mandates cluster scoped access to IngressClass. This leads to problems when updating old Ingress controller to newest version, as described [here](https://github.com/kubernetes/ingress-nginx/issues/7510). We plan to fix it in v1.0.3, see [this](https://github.com/kubernetes/ingress-nginx/pull/7578).
* Ingress controller now (starting from v1.0.0) mandates cluster scoped access to IngressClass. This leads to problems when updating old Ingress controller to newest version, as described [here](https://github.com/kubernetes/ingress-nginx/issues/7510). We plan to fix it in v1.0.3, see [this](https://github.com/kubernetes/ingress-nginx/pull/7578).
* Ingress controller now (starting from v1.0.0) mandates cluster scoped access to IngressClass. This leads to problems when updating old Ingress controller to newest version, as described [here](https://github.com/kubernetes/ingress-nginx/issues/7510). We plan to fix it in v1.0.2, see [this](https://github.com/kubernetes/ingress-nginx/pull/7578).
* Ingress controller now (starting from v1.0.0) mandates cluster scoped access to IngressClass. This leads to problems when updating old Ingress controller to newest version, as described [here](https://github.com/kubernetes/ingress-nginx/issues/7510). We plan to fix it in v1.0.2, see [this](https://github.com/kubernetes/ingress-nginx/pull/7578).
_New Features:_
@ -883,7 +883,7 @@ _Changes:_
test #7255
- [X] [#7216](https://github.com/kubernetes/ingress-nginx/pull/7216) Admission: Skip validation checks if an ingress
is marked as deleted #7216
### 1.0.0-beta.3
** This is a breaking change**
@ -2057,7 +2057,7 @@ _Breaking Changes:_
```
Due to upcoming data privacy regulations, we are making significant changes to how you access free GeoLite2 databases starting December 30, 2019.
Learn more on our blog https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
Learn more on our blog https://blog.maxmind.com/2019/12/significant-changes-to-accessing-and-using-geolite2-databases/
```
Because of this change, it is not clear we can provide the databases directly from the docker image.
@ -2193,7 +2193,7 @@ _New Features:_
If the active connections end before that, the pod will terminate gracefully at that time.
To efectively take advantage of this feature, the Configmap feature [worker-shutdown-timeout](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#worker-shutdown-timeout) new value is `240s` instead of `10s`.
To effectively take advantage of this feature, the Configmap feature [worker-shutdown-timeout](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#worker-shutdown-timeout) new value is `240s` instead of `10s`.
**IMPORTANT:** this value has a side effect during reloads, consuming more memory until the old NGINX workers are replaced.
@ -2603,7 +2603,7 @@ _New Features:_
_Breaking changes:_
- The NGINX server listening in port 18080 was removed. It was replaced by a server using an unix socket as port [#3684](https://github.com/kubernetes/ingress-nginx/pull/3684)
This server was internal to the ingress controller. In case this was being acceded from the outside, you can restore the old server using the `http-snipet` feature in the configuration configmap like:
This server was internal to the ingress controller. In case this was being acceded from the outside, you can restore the old server using the `http-snippet` feature in the configuration configmap like:
@ -177,21 +177,21 @@ Promoting the images basically means that images, that were pushed to staging co
```
- 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 ommit the 39th, the 40th and the 41st line in the resulting list. These were non-relevant PRs.
- 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
% 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
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, its possible to use a bash scripty way, seen below, to convert those plaintext PR numbers into clickable links.
- 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.
```
#!/usr/bin/bash
@ -205,7 +205,7 @@ Promoting the images basically means that images, that were pushed to staging co
done <$file
```
- There was a parsing issue and path issue on MacOS, so above scrpt had to be modified and MacOS monterey compatible script is below ;
- There was a parsing issue and path issue on MacOS, so above script had to be modified and MacOS monterey compatible script is below ;
```
#!/bin/bash
@ -226,19 +226,18 @@ Promoting the images basically means that images, that were pushed to staging co
```
### 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. But the CI pipeline is not designed to make commits back into the project. So we need to run helm-docs manually, and check in the resulting autogenerated README.md at the path /charts/ingress-nginx/README.md
- [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.
```
GOBIN=$PWD GO111MODULE=on go install github.com/norwoodj/helm-docs/cmd/helm-docs@v1.11.0
@ -20,14 +20,14 @@ It all starts with 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, its 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.
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 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`
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:
```
@ -435,7 +435,7 @@ virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
```
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 simple do:
Minikube creates a Virtual Machine, to enter the virtual machine we can simply do:
```
# minikube ssh
```
@ -707,7 +707,7 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
httpd ClusterIP 10.104.111.0 <none> 80/TCP 13s
```
Once we have this we can now create an ingress using the following
Once we have this we can now create an ingress using the following
The above output shows the information that the `httpd` pod recieves. 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 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.
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 documentation site](https://kubernetes.io/docs/concepts/services-networking/ingress/).
[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),
@ -28,7 +29,7 @@ If you encounter issues, review the [troubleshooting docs](docs/troubleshooting.
See [the list of releases](https://github.com/kubernetes/ingress-nginx/releases) for all changes.
For detailed changes for each release, please check the [changelog-$version.md](./changelog) file for the release version.
For detailed changes on the `ingress-nginx` helm chart, please check the changelog folder for a specific version
For detailed changes on the `ingress-nginx` helm chart, please check the changelog folder for a specific version.
See [this article](https://kubernetes.io/blog/2021/07/26/update-with-ingress-nginx/) if you want upgrade to the stable
Ingress API.
@ -65,7 +68,6 @@ 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
@ -74,8 +76,8 @@ Thanks for taking the time to join our community and start contributing!
- 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).
To use, add `ingressClassName: nginx` spec field or the `kubernetes.io/ingress.class: nginx` annotation to your Ingress resources.
@ -10,7 +10,7 @@ This chart bootstraps an ingress-nginx deployment on a [Kubernetes](http://kuber
## Requirements
Kubernetes: `>=1.20.0-0`
Kubernetes: `>=1.21.0-0`
## Get Repo Info
@ -229,6 +229,24 @@ Detail of how and why are in [this issue](https://github.com/helm/charts/pull/13
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 |
@ -253,11 +271,11 @@ As of version `1.26.0` of this chart, by simply not providing any clusterIP valu
| 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.controllerValue | string | `"k8s.io/ingress-nginx"` | Controller-value of the controller that is processing this ingressClass |
| controller.ingressClassResource.default | bool | `false` | Is this the default ingressClass for the cluster |
| controller.ingressClassResource.enabled | bool | `true` | Is this ingressClass enabled or not |
| controller.ingressClassResource.name | string | `"nginx"` | Name of the ingressClass |
| controller.ingressClassResource.parameters | object | `{}` | Parameters is a link to a custom resource containing additional configuration for the controller. This is optional if the controller does not require extra parameters. |
| controller.ingressClassResource | object | `{"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.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 |
@ -389,11 +408,11 @@ As of version `1.26.0` of this chart, by simply not providing any clusterIP valu
| controller.opentelemetry.containerSecurityContext.runAsUser | int | `65532` | The image's default user, inherited from its base image `cgr.dev/chainguard/static`. |
@ -226,4 +226,22 @@ Detail of how and why are in [this issue](https://github.com/helm/charts/pull/13
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).
### 4.10.0
* - "Update Ingress-Nginx version controller-v1.10.0"
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).
### 4.10.1
* - "update post submit helm ci and clean up (#11221)"
* - "refactor helm ci tests part I (#11188)"
* - "Update Ingress-Nginx version controller-v1.10.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).
### 4.10.2
* Chores: Align security contacts & chart maintainers to actual owners. (#11480)
* Fix helm install on cloud provider admonition block (#11412)
* edited helm-install tips (#11411)
* added info for aws helm install (#11410)
* add workflow to helm release and update ct for branch (#11317)
* Merge pull request #11277 from strongjz/chart-1.10.1 (#11314)
* release helm chart from release branch (#11278)
* update post submit helm ci and clean up (#11221)
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).
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).
