update docs

kubernetes · Dec 16, 2021 · b7d25a7 · b7d25a7
1 parent 72a5b42
commit b7d25a7
Show file tree

Hide file tree

Showing 2 changed files with 31 additions and 50 deletions.
diff --git a/RELEASE.md b/RELEASE.md
@@ -1,14 +1,14 @@
 # RELEASE PROCESS
 
-## 1. BUILD the new Ingress-Nginx-Controller image 
+## 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 
+- Make changes in /images
 
 ### c. Create Pull Request
 
@@ -18,15 +18,15 @@
 
   - 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.  
+  - 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. 
+- 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.
 
@@ -42,7 +42,7 @@
 ### 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.  :
-   
+
   - [e2e](https://github.com/kubernetes/ingress-nginx/tree/main/test/e2e-image)
 
     - Update references to e2e-test-runner image [If applicable] :
@@ -72,24 +72,24 @@
 
 ### 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. 
+- 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: 
+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 
+- 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: 
+  - 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:
 
   ```
   ...
@@ -99,7 +99,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 ### 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. 
+- 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).
 
@@ -113,7 +113,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 - 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/k8s.gcr.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 
+- 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/k8s.gcr.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
 
@@ -130,13 +130,13 @@ Promoting the images basically means that images, that were pushed to staging co
 
 ## 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). 
+- 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 different 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 
+- Get your git workspace ready
 
   - If not using a pre-existing fork, then Fork the repo kubernetes/ingress-nginx
 
@@ -165,7 +165,7 @@ Promoting the images basically means that images, that were pushed to staging co
     - appVersion
     - kubeVersion (**ONLY if applicable**)
     - annotations
-      - artifacthub.io/prerelease: "true" 
+      - artifacthub.io/prerelease: "true"
       - artifacthub.io/changes: |
         - Add the titles of the PRs merged after previous release
 
@@ -179,41 +179,18 @@ Promoting the images basically means that images, that were pushed to staging co
 
   - 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
 
-  - This script depends on python and a specific python package `pip3 install ruamel.yaml`
+  - 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)
 
-  - Execute the script to update static manifests using that script [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 to search for any misses by the script or undesired changes
 
   - The script should properly set the image and the digest fields to the desired tag and semver
 
-  - Manually fix one problem that the script can not take care of.
-
-    - This problem is wrong formatting of a snippet in the file [deploy-tls-termination.yaml](https://github.com/kubernetes/ingress-nginx/blob/main/deploy/static/provider/aws/deploy-tls-termination.yaml)
-    - In the configMap section, for the configMap named ingress-nginx-controller, the "configMap.data" spec has a snippet
-
-    - This snippet becomes a single line, formatted with the newline character "\n"
-
-    - That single line formatted with "\n" needs to be changed as it does not meet yaml requirements
-
-    - At the time of writing this doc, the 'configMap.data' spec is at line number 39.
-
-    - So editing begins at line 40 (at the time of writing this doc)
-
-    - Make that snippet look like this ;
-      ```
-      data:
-        http-snippet:|
-          server{
-          listen 2443;
-          return 308 https://$host$request_uri;
-          }
-      ```
-
 ### f. Edit the changelog
-  [Changelog.md](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md) 
+  [Changelog.md](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md)
     - Add the PRs merged after previous release
     - One useful command to get this list is
       ```
@@ -222,7 +199,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 ### 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 
+    - Update Supported versions in the Support Versions table in the README.md
 
 ### h. Edit stable.txt
 
@@ -238,7 +215,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 - 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 
+  - Create a PR
 
 ### b. Merge
 

diff --git a/docs/deploy/index.md b/docs/deploy/index.md
@@ -55,8 +55,11 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/cont
 !!! info
     The YAML manifest in the command above was generated with `helm template`, so you will end up with almost the same resources as if you had used Helm to install the controller.
 
-If you are running an old version of Kubernetes (1.18 or earlier), please read
-[this paragraph](#running-on-Kubernetes-versions-older-than-1.19) for specific instructions.
+!!! attention
+  If you are running an old version of Kubernetes (1.18 or earlier), please read
+  [this paragraph](#running-on-Kubernetes-versions-older-than-1.19) for specific instructions.
+  Because of api deprecations, the default manifest may not work on your cluster.
+  Specific manifests for supported Kubernetes versions are available within a subfolder of each provider.
 
 ### Pre-flight check
 
@@ -186,12 +189,13 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/cont
 
 ##### TLS termination in AWS Load Balancer (NLB)
 
-By default, TLS is terminated in the ingress controller. But it is also possible to terminate TLS in the Load Balancer. This section explains how to do that on AWS with using an NLB.
+By default, TLS is terminated in the ingress controller. But it is also possible to terminate TLS in the Load Balancer. This section explains how to do that on AWS using an NLB.
 
-1. Download the the [deploy-tls-termination.yaml](https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/aws/deploy-tls-termination.yaml) template:
-   ```console
-   wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/aws/deploy-tls-termination.yaml
-   ```
+1. Download the [deploy.yaml](https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/aws/nlb-with-tls-termination/deploy.yaml) template
+
+  ```console
+  wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/aws/nlb-with-tls-termination/deploy.yaml
+  ```
 
 2. Edit the file and change the VPC CIDR in use for the Kubernetes cluster:
    ```
@@ -205,7 +209,7 @@ By default, TLS is terminated in the ingress controller. But it is also possible
 
 4. Deploy the manifest:
    ```console
-   kubectl apply -f deploy-tls-termination.yaml
+   kubectl apply -f deploy.yaml
    ```
 
 ##### NLB Idle Timeouts