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

Fix formatting issues in federated ingress docs

Browse Source
This commit is contained in:
Clenimar Filemon
2017-04-26 14:36:04 -03:00
committed by Andrew Chen
parent 5462769c4a
commit d3242d6a23
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/administer-federation/ingress.md
+8 -8
View File
@@ -60,7 +60,7 @@ Once created, the Federated Ingress automatically:
1. creates matching Kubernetes Ingress objects in every cluster 1. creates matching Kubernetes Ingress objects in every cluster
underlying your Cluster Federation, underlying your Cluster Federation,
2. ensures that all of these in-cluster ingress objects share the same 2. ensures that all of these in-cluster ingress objects share the same
logical global L7 (i.e. HTTP(S)) load balancer and IP address. logical global L7 (i.e. HTTP(S)) load balancer and IP address.
3. monitors the health and capacity of the service "shards" (i.e. your 3. monitors the health and capacity of the service "shards" (i.e. your
pods) behind this ingress in each cluster pods) behind this ingress in each cluster
4. ensures that all client connections are routed to an appropriate 4. ensures that all client connections are routed to an appropriate
@@ -75,7 +75,7 @@ rather a
[truly global, highly available load balancing managed service](https://cloud.google.com/load-balancing/), [truly global, highly available load balancing managed service](https://cloud.google.com/load-balancing/),
globally reachable via a single, static IP address. globally reachable via a single, static IP address.
Clients inside your federated Kubernetes clusters (i.e. Pods) will be Clients inside your federated Kubernetes clusters (i.e. Pods) will be
automatically routed to the cluster-local shard of the Federated Service automatically routed to the cluster-local shard of the Federated Service
backing the Ingress in their backing the Ingress in their
cluster if it exists and is healthy, or the closest healthy shard in a cluster if it exists and is healthy, or the closest healthy shard in a
@@ -103,14 +103,14 @@ and maintain matching Kubernetes ingresses in all of the clusters
underlying your federation. These cluster-specific ingresses (and underlying your federation. These cluster-specific ingresses (and
their associated ingress controllers) configure and manage the load their associated ingress controllers) configure and manage the load
balancing and health checking infrastructure that ensures that traffic balancing and health checking infrastructure that ensures that traffic
is load balanced to each cluster appropriately. is load balanced to each cluster appropriately.
You can verify this by checking in each of the underlying clusters, for example: You can verify this by checking in each of the underlying clusters, for example:
``` shell ``` shell
kubectl --context=gce-asia-east1a get ingress myingress kubectl --context=gce-asia-east1a get ingress myingress
NAME HOSTS ADDRESS PORTS AGE NAME HOSTS ADDRESS PORTS AGE
myingress * 130.211.5.194 80, 443 1m myingress * 130.211.5.194 80, 443 1m
``` ```
The above assumes that you have a context named 'gce-asia-east1a' The above assumes that you have a context named 'gce-asia-east1a'
@@ -172,11 +172,11 @@ ingresses function correctly, either start with new, empty clusters, or make
sure that you delete (and recreate if necessary) all pre-existing sure that you delete (and recreate if necessary) all pre-existing
Ingresses in the clusters comprising your federation. Ingresses in the clusters comprising your federation.
#Adding backend services and pods ## Adding backend services and pods
To render the underlying ingress shards healthy, we need to add To render the underlying ingress shards healthy, we need to add
backend Pods behind the service upon which the Ingress is based. There are several ways to achieve this, but backend Pods behind the service upon which the Ingress is based. There are several ways to achieve this, but
the easiest is to create a Federated Service and the easiest is to create a Federated Service and
Federated Replicaset. Details of how those Federated Replicaset. Details of how those
work are covered in the aforementioned user guides - here we'll simply use them, to work are covered in the aforementioned user guides - here we'll simply use them, to
create appropriately labelled pods and services in the 13 underlying clusters of create appropriately labelled pods and services in the 13 underlying clusters of
@@ -187,7 +187,7 @@ kubectl --context=federation-cluster create -f services/nginx.yaml
``` ```
``` shell ``` shell
kubectl --context=federation-cluster create -f myreplicaset.yaml kubectl --context=federation-cluster create -f myreplicaset.yaml
``` ```
Note that in order for your federated ingress to work correctly on Note that in order for your federated ingress to work correctly on
@@ -199,7 +199,7 @@ federated service. If you do not specify a node port for your
federated service, each cluster will choose it's own node port for federated service, each cluster will choose it's own node port for
its cluster-local shard of the service, and these will probably end its cluster-local shard of the service, and these will probably end
up being different, which is not what you want. up being different, which is not what you want.
You can verify this by checking in each of the underlying clusters, for example: You can verify this by checking in each of the underlying clusters, for example:
``` shell ``` shell