Keep project name display aligned (#9920)
This commit is contained in:
guessi
GitHub
parent
3d73327994
commit
788b3606b1
23 changed files with 51 additions and 51 deletions
|
|
@ -68,7 +68,7 @@ They are set in the container spec of the `ingress-nginx-controller` Deployment
|
|||
| `--validating-webhook` | The address to start an admission controller on to validate incoming ingresses. Takes the form "<host>:port". If not provided, no admission controller is started. |
|
||||
| `--validating-webhook-certificate` | The path of the validating webhook certificate PEM. |
|
||||
| `--validating-webhook-key` | The path of the validating webhook key PEM. |
|
||||
| `--version` | Show release information about the NGINX Ingress controller and exit. |
|
||||
| `--version` | Show release information about the Ingress-Nginx Controller and exit. |
|
||||
| `--watch-ingress-without-class` | Define if Ingress Controller should also watch for Ingresses without an IngressClass or the annotation specified. (default false) |
|
||||
| `--watch-namespace` | Namespace the controller watches for updates to Kubernetes objects. This includes Ingresses, Services and all configuration resources. All namespaces are watched if this parameter is left empty. |
|
||||
| `--watch-namespace-selector` | The controller will watch namespaces whose labels match the given selector. This flag only takes effective when `--watch-namespace` is empty. |
|
||||
|
|
|
|||
|
|
@ -2,5 +2,5 @@
|
|||
|
||||
- [Pain(less) NGINX Ingress](http://danielfm.me/posts/painless-nginx-ingress.html)
|
||||
- [Accessing Kubernetes Pods from Outside of the Cluster](http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster)
|
||||
- [Kubernetes - Redirect HTTP to HTTPS with ELB and the nginx ingress controller](https://dev.to/tomhoule/kubernetes---redirect-http-to-https-with-elb-and-the-nginx-ingress-controller)
|
||||
- [Kubernetes - Redirect HTTP to HTTPS with ELB and the Ingress-Nginx Controller](https://dev.to/tomhoule/kubernetes---redirect-http-to-https-with-elb-and-the-nginx-ingress-controller)
|
||||
- [Configure Nginx Ingress Controller for TLS termination on Kubernetes on Azure](https://blogs.technet.microsoft.com/livedevopsinjapan/2017/02/28/configure-nginx-ingress-controller-for-tls-termination-on-kubernetes-on-azure-2/)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ The default value of these settings is `60 seconds`.
|
|||
A more adequate value to support websockets is a value higher than one hour (`3600`).
|
||||
|
||||
!!! Important
|
||||
If the NGINX ingress controller is exposed with a service `type=LoadBalancer` make sure the protocol between the loadbalancer and NGINX is TCP.
|
||||
If the Ingress-Nginx Controller is exposed with a service `type=LoadBalancer` make sure the protocol between the loadbalancer and NGINX is TCP.
|
||||
|
||||
## Optimizing TLS Time To First Byte (TTTFB)
|
||||
|
||||
|
|
@ -52,4 +52,4 @@ The previous behavior can be restored using `retry-non-idempotent=true` in the c
|
|||
|
||||
## Why endpoints and not services
|
||||
|
||||
The NGINX ingress controller does not use [Services](http://kubernetes.io/docs/user-guide/services) to route traffic to the pods. Instead it uses the Endpoints API in order to bypass [kube-proxy](http://kubernetes.io/docs/admin/kube-proxy/) to allow NGINX features like session affinity and custom load balancing algorithms. It also removes some overhead, such as conntrack entries for iptables DNAT.
|
||||
The Ingress-Nginx Controller does not use [Services](http://kubernetes.io/docs/user-guide/services) to route traffic to the pods. Instead it uses the Endpoints API in order to bypass [kube-proxy](http://kubernetes.io/docs/admin/kube-proxy/) to allow NGINX features like session affinity and custom load balancing algorithms. It also removes some overhead, such as conntrack entries for iptables DNAT.
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@ Two different methods to install and configure Prometheus and Grafana are descri
|
|||
|
||||
## Prometheus and Grafana installation using Pod Annotations
|
||||
|
||||
This tutorial will show you how to install [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/) for scraping the metrics of the NGINX Ingress controller.
|
||||
This tutorial will show you how to install [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/) for scraping the metrics of the Ingress-Nginx Controller.
|
||||
|
||||
!!! important
|
||||
This example uses `emptyDir` volumes for Prometheus and Grafana. This means once the pod gets terminated you will lose all the data.
|
||||
|
||||
### Before You Begin
|
||||
|
||||
- The NGINX Ingress controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
|
||||
- The Ingress-Nginx Controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
|
||||
|
||||
- The controller should be configured for exporting metrics. This requires 3 configurations to the controller. These configurations are :
|
||||
1. controller.metrics.enabled=true
|
||||
|
|
@ -184,9 +184,9 @@ According to the above example, this URL will be http://10.192.0.3:31086
|
|||
## Prometheus and Grafana installation using Service Monitors
|
||||
This document assumes you're using helm and using the kube-prometheus-stack package to install Prometheus and Grafana.
|
||||
|
||||
### Verify NGINX Ingress controller is installed
|
||||
### Verify Ingress-Nginx Controller is installed
|
||||
|
||||
- The NGINX Ingress controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
|
||||
- The Ingress-Nginx Controller should already be deployed according to the deployment instructions [here](../deploy/index.md).
|
||||
|
||||
- To check if Ingress controller is deployed,
|
||||
```
|
||||
|
|
@ -214,7 +214,7 @@ This document assumes you're using helm and using the kube-prometheus-stack pack
|
|||
|
||||
- If prometheus is not installed, then you can install from [here](https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack)
|
||||
|
||||
### Re-configure NGINX Ingress controller
|
||||
### Re-configure Ingress-Nginx Controller
|
||||
|
||||
- The Ingress NGINX controller needs to be reconfigured for exporting metrics. This requires 3 additional configurations to the controller. These configurations are :
|
||||
```
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ spec:
|
|||
|
||||
then setting the corresponding `kubernetes.io/ingress.class: "internal-nginx"` annotation on your Ingresses.
|
||||
|
||||
To reiterate, setting the annotation to any value which does not match a valid ingress class will force the NGINX Ingress controller to ignore your Ingress.
|
||||
If you are only running a single NGINX ingress controller, this can be achieved by setting the annotation to any value except "nginx" or an empty string.
|
||||
To reiterate, setting the annotation to any value which does not match a valid ingress class will force the Ingress-Nginx Controller to ignore your Ingress.
|
||||
If you are only running a single Ingress-Nginx Controller, this can be achieved by setting the annotation to any value except "nginx" or an empty string.
|
||||
|
||||
Do this if you wish to use one of the other Ingress controllers at the same time as the NGINX controller.
|
||||
|
|
|
|||
|
|
@ -598,7 +598,7 @@ the User guide.
|
|||
|
||||
### Service Upstream
|
||||
|
||||
By default the NGINX ingress controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration.
|
||||
By default the Ingress-Nginx Controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration.
|
||||
|
||||
The `nginx.ingress.kubernetes.io/service-upstream` annotation disables that behavior and instead uses a single upstream in NGINX, the service's Cluster IP and port.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Enables requests served by NGINX for distributed telemetry via The OpenTelemetry Project.
|
||||
|
||||
Using the third party module [opentelemetry-cpp-contrib/nginx](https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/main/instrumentation/nginx) the NGINX ingress controller can configure NGINX to enable [OpenTelemetry](http://opentelemetry.io) instrumentation.
|
||||
Using the third party module [opentelemetry-cpp-contrib/nginx](https://github.com/open-telemetry/opentelemetry-cpp-contrib/tree/main/instrumentation/nginx) the Ingress-Nginx Controller can configure NGINX to enable [OpenTelemetry](http://opentelemetry.io) instrumentation.
|
||||
By default this feature is disabled.
|
||||
|
||||
## Usage
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Enables requests served by NGINX for distributed tracing via The OpenTracing Project.
|
||||
|
||||
Using the third party module [opentracing-contrib/nginx-opentracing](https://github.com/opentracing-contrib/nginx-opentracing) the NGINX ingress controller can configure NGINX to enable [OpenTracing](http://opentracing.io) instrumentation.
|
||||
Using the third party module [opentracing-contrib/nginx-opentracing](https://github.com/opentracing-contrib/nginx-opentracing) the Ingress-Nginx Controller can configure NGINX to enable [OpenTracing](http://opentracing.io) instrumentation.
|
||||
By default this feature is disabled.
|
||||
|
||||
## Usage
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue