whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixing some issues in Ingress docs

Browse Source
This commit is contained in:
Rob Scott
2020-07-09 17:56:18 -07:00
parent 95a77e30db
commit b8d8b9984d
1 changed files with 15 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/services-networking/ingress.md
+15 -13
View File
@@ -84,11 +84,13 @@ Each HTTP rule contains the following information:
* An optional host. In this example, no host is specified, so the rule applies to all inbound * An optional host. In this example, no host is specified, so the rule applies to all inbound
HTTP traffic through the IP address specified. If a host is provided (for example, HTTP traffic through the IP address specified. If a host is provided (for example,
foo.bar.com), the rules apply to that host. foo.bar.com), the rules apply to that host.
* A list of paths (for example, `/testpath`), each of which has an associated backend defined with a `service.Name` * A list of paths (for example, `/testpath`), each of which has an associated
and a `service.Port.Name` or `service.Port.Number`. Both the host and path must match the content of an incoming request before the backend defined with a `service.name` and a `service.port.name` or
load balancer directs traffic to the referenced Service. `service.port.number`. Both the host and path must match the content of an
incoming request before the load balancer directs traffic to the referenced
Service.
* A backend is a combination of Service and port names as described in the * A backend is a combination of Service and port names as described in the
[Service doc](/docs/concepts/services-networking/service/) or a [custom resource backend](#resource-backends) by way of a CRD. HTTP (and HTTPS) requests to the [Service doc](/docs/concepts/services-networking/service/) or a [custom resource backend](#resource-backend) by way of a CRD. HTTP (and HTTPS) requests to the
Ingress that matches the host and path of the rule are sent to the listed backend. Ingress that matches the host and path of the rule are sent to the listed backend.
A `defaultBackend` is often configured in an Ingress controller to service any requests that do not A `defaultBackend` is often configured in an Ingress controller to service any requests that do not
@@ -104,10 +106,10 @@ routed to your default backend.
### Resource Backends {#resource-backend} ### Resource Backends {#resource-backend}
A _`Resource`_ backend is an ObjectRef to another Kubernetes resource within the A `Resource` backend is an ObjectRef to another Kubernetes resource within the
same namespace of the Ingress object. A _`Resource`_ is a mutually exclusive same namespace of the Ingress object. A `Resource` is a mutually exclusive
setting with Service, and will fail validation if both are specified. A common setting with Service, and will fail validation if both are specified. A common
usage for a _`Resource`_ backend is to ingress data to a object storage backend usage for a `Resource` backend is to ingress data to an object storage backend
with static assets. with static assets.
{{< codenew file="service/networking/ingress-resource-backend.yaml" >}} {{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
@@ -138,13 +140,13 @@ Each path in an Ingress is required to have a corresponding path type. Paths
that do not include an explicit `pathType` will fail validation. There are three that do not include an explicit `pathType` will fail validation. There are three
supported path types: supported path types:
* _`ImplementationSpecific`_: With this path type, matching is up to the * `ImplementationSpecific`: With this path type, matching is up to the
IngressClass. Implementations can treat this as a separate `pathType` or treat IngressClass. Implementations can treat this as a separate `pathType` or treat
it identically to `Prefix` or `Exact` path types. it identically to `Prefix` or `Exact` path types.
* _`Exact`_: Matches the URL path exactly and with case sensitivity. * `Exact`: Matches the URL path exactly and with case sensitivity.
* _`Prefix`_: Matches based on a URL path prefix split by `/`. Matching is case * `Prefix`: Matches based on a URL path prefix split by `/`. Matching is case
sensitive and done on a path element by element basis. A path element refers sensitive and done on a path element by element basis. A path element refers
to the list of labels in the path split by the `/` separator. A request is a to the list of labels in the path split by the `/` separator. A request is a
match for path _p_ if every _p_ is an element-wise prefix of _p_ of the match for path _p_ if every _p_ is an element-wise prefix of _p_ of the
@@ -185,9 +187,9 @@ type over prefix path type.
## Hostname Wildcards ## Hostname Wildcards
Hosts can be precise matches (for example “`foo.bar.com`”) or a wildcard (for Hosts can be precise matches (for example “`foo.bar.com`”) or a wildcard (for
example “`*.foo.com`”). Precise matches require that the http host header example “`*.foo.com`”). Precise matches require that the HTTP `host` header
matches the Host setting. Wildcard matches require the http host header is equal matches the `host` field. Wildcard matches require the HTTP `host` header is
to the suffix of the wildcard rule. equal to the suffix of the wildcard rule.
| Host | Host header | Match? | | Host | Host header | Match? |
| ----------- |-------------------| --------------------------------------------------| | ----------- |-------------------| --------------------------------------------------|