diff options
| author | Quinton Hoole <quinton@google.com> | 2016-07-29 13:46:48 -0700 |
|---|---|---|
| committer | Quinton Hoole <quinton@google.com> | 2016-11-11 14:03:27 -0800 |
| commit | 8ed294b220fed0146ac32cce499f107d0f450ee9 (patch) | |
| tree | af5e2f1a1d70c2f00aedc0cdb9f4aec0274127f4 | |
| parent | a7cc2e70378cbd0fd2c5c492e90b7ad209f9eb5b (diff) | |
run hack/update-munge-docs.sh
| -rw-r--r-- | federated-ingress.md | 56 |
1 files changed, 45 insertions, 11 deletions
diff --git a/federated-ingress.md b/federated-ingress.md index 772ce2d6..c0ab3381 100644 --- a/federated-ingress.md +++ b/federated-ingress.md @@ -1,4 +1,33 @@ -#Kubernetes Federated Ingress +<!-- BEGIN MUNGE: UNVERSIONED_WARNING --> + +<!-- BEGIN STRIP_FOR_RELEASE --> + +<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" + width="25" height="25"> +<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" + width="25" height="25"> +<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" + width="25" height="25"> +<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" + width="25" height="25"> +<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" + width="25" height="25"> + +<h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2> + +If you are using a released version of Kubernetes, you should +refer to the docs that go with that version. + +Documentation for other releases can be found at +[releases.k8s.io](http://releases.k8s.io). +</strong> +-- + +<!-- END STRIP_FOR_RELEASE --> + +<!-- END MUNGE: UNVERSIONED_WARNING --> + +# Kubernetes Federated Ingress Requirements and High Level Design @@ -57,7 +86,7 @@ In summary, all of [GCE L7 Load Balancer](https://cloud.google.com/compute/docs/ 1. Single global virtual (a.k.a. "anycast") IP address ("VIP" - no dependence on dynamic DNS) 1. Geo-locality for both external and GCP-internal clients -1. Load-based overflow to next-closest geo-locality (i.e. cluster). Based on either queries per second, or CPU load (unfortunately on the first-hop target VM, not the final destination K8s Service). +1. Load-based overflow to next-closest geo-locality (i.e. cluster). Based on either queries per second, or CPU load (unfortunately on the first-hop target VM, not the final destination K8s Service). 1. URL-based request direction (different backend services can fulfill each different URL). 1. HTTPS request termination (at the GCE load balancer, with server SSL certs) @@ -65,8 +94,8 @@ In summary, all of [GCE L7 Load Balancer](https://cloud.google.com/compute/docs/ 1. Federation user creates (federated) Ingress object 1. Federated Ingress Controller creates Ingress object in each cluster in the federation -1. Each cluster-level Ingress Controller ("GLBC") creates Google L7 Load Balancer machinery (forwarding rules, target proxy, URL map, backend service, health check) which ensures that traffic to the Ingress (backed by a Service), is directed to one of the nodes in the cluster. -1. KubeProxy redirects to one of the backend Pods (currently round-robin, per KubeProxy instance) +1. Each cluster-level Ingress Controller ("GLBC") creates Google L7 Load Balancer machinery (forwarding rules, target proxy, URL map, backend service, health check) which ensures that traffic to the Ingress (backed by a Service), is directed to one of the nodes in the cluster. +1. KubeProxy redirects to one of the backend Pods (currently round-robin, per KubeProxy instance) An alternative implementation approach involves lifting the current Federated Ingress Controller functionality up into the Federation @@ -119,8 +148,8 @@ balancers 1. Federation user creates (federated) Ingress object 1. Federated Ingress Controller creates Ingress object in each cluster in the federation -1. Each cluster-level AWS Ingress Controller creates/updates - 1. (regional) AWS Elastic Load Balancer machinery which ensures that traffic to the Ingress (backed by a Service), is directed to one of the nodes in one of the clusters in the region. +1. Each cluster-level AWS Ingress Controller creates/updates + 1. (regional) AWS Elastic Load Balancer machinery which ensures that traffic to the Ingress (backed by a Service), is directed to one of the nodes in one of the clusters in the region. 1. (global) AWS Route53 DNS machinery which ensures that clients are directed to the closest non-overloaded (regional) elastic load balancer. 1. KubeProxy redirects to one of the backend Pods (currently round-robin, per KubeProxy instance) in the destination K8s cluster. @@ -131,7 +160,7 @@ Most of this remains is currently unimplemented ([AWS Ingress controller](https: Route53](https://github.com/kubernetes/contrib/pull/841). 1. K8s AWS Ingress Controller -1. Re-uses all of the non-GCE specific Federation machinery discussed above under "GCP-only...". +1. Re-uses all of the non-GCE specific Federation machinery discussed above under "GCP-only...". ### Pros @@ -151,7 +180,7 @@ Route53](https://github.com/kubernetes/contrib/pull/841). ### Summary -Use GCP Federated Ingress machinery described above, augmented with additional HA-proxy backends in all GCP clusters to proxy to non-GCP clusters (via either Service External IP's, or VPN directly to KubeProxy or Pods). +Use GCP Federated Ingress machinery described above, augmented with additional HA-proxy backends in all GCP clusters to proxy to non-GCP clusters (via either Service External IP's, or VPN directly to KubeProxy or Pods). ### Features @@ -172,11 +201,16 @@ Assuming that GCP-only (see above) is complete: 1. Works for cross-cloud. -### Cons +### Cons -1. Traffic to non-GCP clusters proxies through GCP clusters. Additional bandwidth costs (3x?) in those cases. +1. Traffic to non-GCP clusters proxies through GCP clusters. Additional bandwidth costs (3x?) in those cases. ## Cross-cloud via AWS -In theory the same approach as "Cross-cloud via GCP" above could be used, except that AWS infrastructure would be used to get traffic first to an AWS cluster, and then proxied onwards to non-AWS and/or on-prem clusters. +In theory the same approach as "Cross-cloud via GCP" above could be used, except that AWS infrastructure would be used to get traffic first to an AWS cluster, and then proxied onwards to non-AWS and/or on-prem clusters. Detail docs TBD. + + +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> +[]() +<!-- END MUNGE: GENERATED_ANALYTICS --> |
