Merge pull request #23283 from sftim/20200820_improve_diagrams_for_ingress

Switch Ingress concept to use MermaidJS diagrams
This commit is contained in:
Kubernetes Prow Robot
2020-09-23 08:04:09 -07:00
committed by GitHub
2 changed files with 67 additions and 17 deletions
+10
View File
@@ -61,6 +61,15 @@ body.td-404 main .error-details {
margin-bottom: 0; margin-bottom: 0;
} }
/* Global - Mermaid.js diagrams */
.mermaid {
overflow-x: auto;
max-width: 80%;
border: 1px solid rgb(222, 226, 230);
border-radius: 5px;
}
/* HEADER */ /* HEADER */
.td-navbar { .td-navbar {
@@ -542,3 +551,4 @@ body.td-documentation {
} }
} }
} }
@@ -29,13 +29,24 @@ For clarity, this guide defines the following terms:
{{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster. {{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
Traffic routing is controlled by rules defined on the Ingress resource. Traffic routing is controlled by rules defined on the Ingress resource.
```none Here is a simple example where an Ingress sends all its traffic to one Service:
internet {{< mermaid >}}
| graph LR;
[ Ingress ] client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress];
--|-----|-- ingress-->|routing rule|service[Service];
[ Services ] subgraph cluster
``` ingress;
service-->pod1[Pod];
service-->pod2[Pod];
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class ingress,service,pod1,pod2 k8s;
class client plain;
class cluster cluster;
{{</ mermaid >}}
An Ingress may 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 may 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.
@@ -274,10 +285,25 @@ A fanout configuration routes traffic from a single IP address to more than one
based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers 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: down to a minimum. For example, a setup like:
``` {{< mermaid >}}
foo.bar.com -> 178.91.123.132 -> / foo service1:4200 graph LR;
/ bar service2:8080 client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress, 178.91.123.132];
``` ingress-->|/foo|service1[Service service1:4200];
ingress-->|/bar|service2[Service service2:8080];
subgraph cluster
ingress;
service1-->pod1[Pod];
service1-->pod2[Pod];
service2-->pod3[Pod];
service2-->pod4[Pod];
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
class client plain;
class cluster cluster;
{{</ mermaid >}}
would require an Ingress such as: would require an Ingress such as:
@@ -321,11 +347,26 @@ you are using, you may need to create a default-http-backend
Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address. Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
```none {{< mermaid >}}
foo.bar.com --| |-> foo.bar.com service1:80 graph LR;
| 178.91.123.132 | client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress, 178.91.123.132];
bar.foo.com --| |-> bar.foo.com service2:80 ingress-->|Host: foo.bar.com|service1[Service service1:80];
``` ingress-->|Host: bar.foo.com|service2[Service service2:80];
subgraph cluster
ingress;
service1-->pod1[Pod];
service1-->pod2[Pod];
service2-->pod3[Pod];
service2-->pod4[Pod];
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
class client plain;
class cluster cluster;
{{</ mermaid >}}
The following Ingress tells the backing load balancer 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). the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
@@ -508,4 +549,3 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) * Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
* Learn about [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/) * 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/) * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)