added info for aws helm install (#11390)
This commit is contained in:
Long Wu Yuan
GitHub
parent
8f4f15f8e3
commit
5fea717bdb
1 changed files with 71 additions and 54 deletions
|
|
@ -83,6 +83,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/cont
|
|||
### Firewall configuration
|
||||
|
||||
To check which ports are used by your installation of ingress-nginx, look at the output of `kubectl -n ingress-nginx get pod -o yaml`. In general, you need:
|
||||
|
||||
- Port 8443 open between all hosts on which the kubernetes nodes are running. This is used for the ingress-nginx [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/).
|
||||
- Port 80 (for HTTP) and/or 443 (for HTTPS) open to the public on the kubernetes nodes to which the DNS of your apps are pointing.
|
||||
|
||||
|
|
@ -104,7 +105,6 @@ kubectl wait --namespace ingress-nginx \
|
|||
--timeout=120s
|
||||
```
|
||||
|
||||
|
||||
### Local testing
|
||||
|
||||
Let's create a simple web server and the associated service:
|
||||
|
|
@ -135,6 +135,7 @@ kubectl port-forward --namespace=ingress-nginx service/ingress-nginx-controller
|
|||
[This issue](https://github.com/kubernetes/ingress-nginx/issues/10014#issuecomment-1567791549described) shows a typical DNS problem and its solution.
|
||||
|
||||
At this point, you can access your deployment using curl ;
|
||||
|
||||
```console
|
||||
curl --resolve demo.localdev.me:8080:127.0.0.1 http://demo.localdev.me:8080
|
||||
```
|
||||
|
|
@ -164,13 +165,13 @@ kubectl create ingress demo --class=nginx \
|
|||
```
|
||||
|
||||
Alternatively, the above command can be rewritten as follows for the ```--rule``` command and below.
|
||||
|
||||
```console
|
||||
kubectl create ingress demo --class=nginx \
|
||||
--rule www.demo.io/=demo:80
|
||||
```
|
||||
|
||||
|
||||
You should then be able to see the "It works!" page when you connect to http://www.demo.io/. Congratulations,
|
||||
You should then be able to see the "It works!" page when you connect to <http://www.demo.io/>. Congratulations,
|
||||
you are serving a public website hosted on a Kubernetes cluster! 🎉
|
||||
|
||||
## Environment-specific instructions
|
||||
|
|
@ -246,6 +247,18 @@ In AWS, we use a Network load balancer (NLB) to expose the Ingress-Nginx Control
|
|||
[Network load balancing on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html)
|
||||
with [AWS Load Balancer Controller](https://github.com/kubernetes-sigs/aws-load-balancer-controller).
|
||||
|
||||
!!! helm install on AWS
|
||||
There have been too many attempts at using helm to install the controller on AWS recently.
|
||||
The ingress-nginx-controller helm-chart is generic and not aimed at installing on AWS on any other infra provider.
|
||||
There are annotations and configurations that are applicable only to AWS.
|
||||
Please run `helm template` and compare with the static yaml manifests you see below.
|
||||
A user is expected to use annotations for
|
||||
(a) internal/external
|
||||
(b) type - nlb
|
||||
(c) sqcurity-groups
|
||||
(d) and other such requirements
|
||||
during their ``helm install`` process.
|
||||
|
||||
##### Network Load Balancer (NLB)
|
||||
|
||||
```console
|
||||
|
|
@ -264,16 +277,19 @@ This section explains how to do that on AWS using an NLB.
|
|||
```
|
||||
|
||||
2. Edit the file and change the VPC CIDR in use for the Kubernetes cluster:
|
||||
|
||||
```
|
||||
proxy-real-ip-cidr: XXX.XXX.XXX/XX
|
||||
```
|
||||
|
||||
3. Change the AWS Certificate Manager (ACM) ID as well:
|
||||
|
||||
```
|
||||
arn:aws:acm:us-west-2:XXXXXXXX:certificate/XXXXXX-XXXXXXX-XXXXXXX-XXXXXXXX
|
||||
```
|
||||
|
||||
4. Deploy the manifest:
|
||||
|
||||
```console
|
||||
kubectl apply -f deploy.yaml
|
||||
```
|
||||
|
|
@ -304,7 +320,6 @@ kubectl create clusterrolebinding cluster-admin-binding \
|
|||
|
||||
Then, the ingress controller can be installed like this:
|
||||
|
||||
|
||||
```console
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.1/deploy/static/provider/cloud/deploy.yaml
|
||||
```
|
||||
|
|
@ -333,8 +348,8 @@ More information with regard to Azure annotations for ingress controller can be
|
|||
```console
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.1/deploy/static/provider/do/deploy.yaml
|
||||
```
|
||||
- By default the service object of the ingress-nginx-controller for Digital-Ocean, only configures one annotation. Its this one `service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"`. While this makes the service functional, it was reported that the Digital-Ocean LoadBalancer graphs shows `no data`, unless a few other annotations are also configured. Some of these other annotations require values that can not be generic and hence not forced in a out-of-the-box installation. These annotations and a discussion on them is well documented in [this issue](https://github.com/kubernetes/ingress-nginx/issues/8965). Please refer to the issue to add annotations, with values specific to user, to get graphs of the DO-LB populated with data.
|
||||
|
||||
- By default the service object of the ingress-nginx-controller for Digital-Ocean, only configures one annotation. Its this one `service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"`. While this makes the service functional, it was reported that the Digital-Ocean LoadBalancer graphs shows `no data`, unless a few other annotations are also configured. Some of these other annotations require values that can not be generic and hence not forced in a out-of-the-box installation. These annotations and a discussion on them is well documented in [this issue](https://github.com/kubernetes/ingress-nginx/issues/8965). Please refer to the issue to add annotations, with values specific to user, to get graphs of the DO-LB populated with data.
|
||||
|
||||
#### Scaleway
|
||||
|
||||
|
|
@ -439,11 +454,13 @@ Ingress resources evolved over time. They started with `apiVersion: extensions/v
|
|||
then moved to `apiVersion: networking.k8s.io/v1beta1` and more recently to `apiVersion: networking.k8s.io/v1`.
|
||||
|
||||
Here is how these Ingress versions are supported in Kubernetes:
|
||||
|
||||
- before Kubernetes 1.19, only `v1beta1` Ingress resources are supported
|
||||
- from Kubernetes 1.19 to 1.21, both `v1beta1` and `v1` Ingress resources are supported
|
||||
- in Kubernetes 1.22 and above, only `v1` Ingress resources are supported
|
||||
|
||||
And here is how these Ingress versions are supported in Ingress-Nginx Controller:
|
||||
|
||||
- before version 1.0, only `v1beta1` Ingress resources are supported
|
||||
- in version 1.0 and above, only `v1` Ingress resources are
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue