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

Improve concept page for Ingress (#14313)

Browse Source 
* Highlight feature state for Ingress concept

* Fix command output marked as shell script

* Write "load balancer" as two words

* Clarify prerequisites for Ingress

* Tidy & reword

* Add link to Ingress Controllers topic

(further reading)

* Use a glossary tooltip for Secret

(readers may not have encountered that concept yet)

* Update term definitions in Ingress concept

- Adopt wording from glossary
  (NB: glossary_definition shortcode didn't seem suitable)
- Replace terms with glossary_tooltip where appropriate
This commit is contained in:
Tim Bannister
2019-06-11 04:34:15 +01:00
committed by Kubernetes Prow Robot
parent f7d6afedec
commit 38aff0f8bb
1 changed files with 59 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/services-networking/ingress.md
+59 -53
View File
@@ -7,23 +7,34 @@ weight: 40
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
{{% /capture %}}
{{% capture body %}}
## Terminology
For the sake of clarity, this guide defines the following terms:
* Node: A single virtual or physical machine in a Kubernetes cluster.
* Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes.
* Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/).
* Service: A Kubernetes [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
Node
: A worker machine in Kubernetes, part of a cluster.
Cluster
: A set of Nodes that run containerized applications managed by Kubernetes. For this example, and in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
Edge router
: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
Cluster network
: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes [networking model](/docs/concepts/cluster-administration/networking/).
Service
: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
## What is Ingress?
Ingress, added in Kubernetes v1.1, exposes HTTP and HTTPS routes from outside the cluster to
Ingress exposes HTTP and HTTPS routes from outside the cluster to
{{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
Traffic routing is controlled by rules defined on the Ingress resource.
@@ -35,7 +46,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.
[ Services ]
```
An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic.
An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) or
@@ -43,25 +54,12 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
## Prerequisites
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
Before you start using an Ingress, there are a few things you should understand. The Ingress is a beta resource.
{{< note >}}
You must have an [Ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
{{< /note >}}
GCE/Google Kubernetes Engine deploys an Ingress controller on the master. Review the
[beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations)
of this controller if you are using GCE/GKE.
In environments other than GCE/Google Kubernetes Engine, you may need to
[deploy an ingress controller](https://kubernetes.github.io/ingress-nginx/deploy/). There are a number of
You may need to deploy an ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). There are a number of
[ingress controllers](/docs/concepts/services-networking/ingress-controllers) you may choose from.
### Before you begin
Ideally, all ingress controllers should fulfill this specification, but the various ingress
Ideally, all ingress controllers should fit the reference specification. In reality, the various ingress
controllers operate slightly differently.
{{< note >}}
@@ -70,7 +68,7 @@ Make sure you review your ingress controller's documentation to understand the c
## The Ingress Resource
A minimal ingress resource example:
A minimal Ingress resource example:
```yaml
apiVersion: networking.k8s.io/v1beta1
@@ -89,7 +87,7 @@ spec:
servicePort: 80
```
As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
Ingress frequently uses annotations to configure some options depending on the Ingress controller, an example of which
is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
@@ -97,7 +95,7 @@ spec:
your choice of Ingress controller to learn which annotations are supported.
The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
has all the information needed to configure a loadbalancer or proxy server. Most importantly, it
has all the information needed to configure a load balancer or proxy server. Most importantly, it
contains a list of rules matched against all incoming requests. Ingress resource only supports rules
for directing HTTP traffic.
@@ -108,9 +106,9 @@ Each http rule contains the following information:
* 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,
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 `serviceName`
* a list of paths (for example, `/testpath`), each of which has an associated backend defined with a `serviceName`
and `servicePort`. Both the host and path must match the content of an incoming request before the
loadbalancer will direct traffic to the referenced service.
load balancer will direct traffic to the referenced service.
* A backend is a combination of service and port names as described in the
[services doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
Ingress matching the host and path of the rule will be sent to the listed backend.
@@ -136,13 +134,14 @@ There are existing Kubernetes concepts that allow you to expose a single Service
{{< codenew file="service/networking/ingress.yaml" >}}
If you create it using `kubectl apply -f` you should see:
If you create it using `kubectl apply -f` you should be able to view the state
of the Ingress you just added:
```shell
kubectl get ingress test-ingress
```
```shell
```
NAME HOSTS ADDRESS PORTS AGE
test-ingress * 107.178.254.228 80 59s
```
@@ -158,10 +157,10 @@ Until that time you will often see the address listed as `<pending>`.
### Simple fanout
A fanout configuration routes traffic from a single IP address to more than one service,
based on the HTTP URI being requested. An Ingress allows you to keep the number of loadbalancers
based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
down to a minimum. For example, a setup like:
```shell
```none
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
/ bar service2:8080
```
@@ -196,7 +195,7 @@ When you create the ingress with `kubectl apply -f`:
kubectl describe ingress simple-fanout-example
```
```shell
```
Name: simple-fanout-example
Namespace: default
Address: 178.91.123.132
@@ -215,14 +214,15 @@ Events:
Normal ADD 22s loadbalancer-controller default/test
```
The Ingress controller provisions an implementation specific loadbalancer
The Ingress controller provisions an implementation-specific load balancer
that satisfies the Ingress, as long as the services (`s1`, `s2`) exist.
When it has done so, you can see the address of the loadbalancer at the
When it has done so, you can see the address of the load balancer at the
Address field.
{{< note >}}
Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) you are using, you may need to
create a default-http-backend [Service](/docs/concepts/services-networking/service/).
Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers)
you are using, you may need to create a default-http-backend
[Service](/docs/concepts/services-networking/service/).
{{< /note >}}
### Name based virtual hosting
@@ -235,7 +235,7 @@ foo.bar.com --| |-> foo.bar.com s1:80
bar.foo.com --| |-> bar.foo.com s2:80
```
The following Ingress tells the backing loadbalancer to route requests based on
The following Ingress tells the backing load balancer to route requests based on
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
```yaml
@@ -261,7 +261,9 @@ spec:
If you create an Ingress resource without any hosts defined in the rules, then any
web traffic to the IP address of your Ingress controller can be matched without a name based
virtual host being required. For example, the following Ingress resource will route traffic
virtual host being required.
For example, the following Ingress resource will route traffic
requested for `first.bar.com` to `service1`, `second.foo.com` to `service2`, and any traffic
to the IP address without a hostname defined in request (that is, without a request header being
presented) to `service3`.
@@ -294,7 +296,7 @@ spec:
### TLS
You can secure an Ingress by specifying a [secret](/docs/concepts/configuration/secret)
You can secure an Ingress by specifying a {{< glossary_tooltip term_id="secret" >}}
that contains a TLS private key and certificate. Currently the Ingress only
supports a single TLS port, 443, and assumes TLS termination. If the TLS
configuration section in an Ingress specifies different hosts, they will be
@@ -316,8 +318,8 @@ type: kubernetes.io/tls
```
Referencing this secret in an Ingress will tell the Ingress controller to
secure the channel from the client to the loadbalancer using TLS. You need to make
sure the TLS secret you created came from a certificate that contains a CN
secure the channel from the client to the load balancer using TLS. You need to make
sure the TLS secret you created came from a certificate that contains a CN
for `sslexample.foo.com`.
```yaml
@@ -354,14 +356,14 @@ An Ingress controller is bootstrapped with some load balancing policy settings
that it applies to all Ingress, such as the load balancing algorithm, backend
weight scheme, and others. More advanced load balancing concepts
(e.g. persistent sessions, dynamic weights) are not yet exposed through the
Ingress. You can still get these features through the
[service loadbalancer](https://github.com/kubernetes/ingress-nginx).
Ingress. You can instead get these features through the load balancer used for
a Service.
It's also worth noting that even though health checks are not exposed directly
through the Ingress, there exist parallel concepts in Kubernetes such as
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
which allow you to achieve the same end result. Please review the controller
specific docs to see how they handle health checks (
that allow you to achieve the same end result. Please review the controller
specific documentation to see how they handle health checks (
[nginx](https://git.k8s.io/ingress-nginx/README.md),
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
@@ -373,7 +375,7 @@ To update an existing Ingress to add a new Host, you can update it by editing th
kubectl describe ingress test
```
```shell
```
Name: test
Namespace: default
Address: 178.91.123.132
@@ -395,7 +397,8 @@ Events:
kubectl edit ingress test
```
This should pop up an editor with the existing yaml, modify it to include the new Host:
This should pop up an editor with the existing configuration in yaml format.
Modify it to include the new Host:
```yaml
spec:
@@ -417,14 +420,16 @@ spec:
..
```
Saving the yaml will update the resource in the API server, which should tell the
Ingress controller to reconfigure the loadbalancer.
After you save your changes, kubectl will update the resource in the API server, which should tell the
Ingress controller to reconfigure the load balancer.
Verify this:
```shell
kubectl describe ingress test
```
```shell
```
Name: test
Namespace: default
Address: 178.91.123.132
@@ -444,7 +449,7 @@ Events:
Normal ADD 45s loadbalancer-controller default/test
```
You can achieve the same by invoking `kubectl replace -f` on a modified Ingress yaml file.
You can achieve the same outcome by invoking `kubectl replace -f` on a modified Ingress yaml file.
## Failing across availability zones
@@ -455,7 +460,7 @@ for details on deploying Ingress in a federated cluster.
## Future Work
Track [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
for more details on the evolution of the ingress and related resources. You may also track the
for more details on the evolution of Ingress and related resources. You may also track the
[Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the
evolution of various Ingress controllers.
@@ -469,5 +474,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
{{% /capture %}}
{{% capture whatsnext %}}
* Learn about [ingress controllers](/docs/concepts/services-networking/ingress-controllers/)
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
{{% /capture %}}