From 092ab3d50987d94eb622d89f8f4168251d7d6a22 Mon Sep 17 00:00:00 2001 From: linweibin Date: Tue, 15 Aug 2017 18:53:22 +0800 Subject: [PATCH] Fix some typos and syntax errors Fix some typos and syntax errors involving cluster.md, ingress.md and replicaset.md --- docs/tasks/administer-federation/cluster.md | 2 +- docs/tasks/administer-federation/ingress.md | 10 +++++----- docs/tasks/administer-federation/replicaset.md | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/tasks/administer-federation/cluster.md b/docs/tasks/administer-federation/cluster.md index 7d5a718b12..09d4076ea2 100644 --- a/docs/tasks/administer-federation/cluster.md +++ b/docs/tasks/administer-federation/cluster.md @@ -102,7 +102,7 @@ Currently, only integers are supported with `Gt` or `Lt`. ## Clusters API reference -The full clusters API reference is currently in `federation/v1beta1` and more details can be found in details in the +The full clusters API reference is currently in `federation/v1beta1` and more details can be found in the [Federation API reference page](/docs/reference/federation/). {% endcapture %} diff --git a/docs/tasks/administer-federation/ingress.md b/docs/tasks/administer-federation/ingress.md index 281d2c536f..3de0493810 100644 --- a/docs/tasks/administer-federation/ingress.md +++ b/docs/tasks/administer-federation/ingress.md @@ -78,7 +78,7 @@ You can create a federated ingress in any of the usual ways, for example, using ``` shell kubectl --context=federation-cluster create -f myingress.yaml ``` -For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/) +For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/). The '--context=federation-cluster' flag tells kubectl to submit the request to the Federation API endpoint, with the appropriate credentials. If you have not yet configured such a context, see the @@ -183,7 +183,7 @@ services need to be identical. If you're using a federated service this is easy to do. Simply pick a node port that is not already being used in any of your clusters, and add that to the spec of your 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 its own node port for its cluster-local shard of the service, and these will probably end up being different, which is not what you want. @@ -253,7 +253,7 @@ how to bring up a cluster federation correctly (or have your cluster administrat Check that: -1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`) +1. Your clusters are correctly registered in the Cluster Federation API. (`kubectl describe clusters`) 2. Your clusters are all 'Active'. This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints. If not, consult the event logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`) @@ -276,7 +276,7 @@ Check that: 2. The load balancer controllers in each of your clusters are of the correct type ("GLBC") and have been correctly reconfigured by the federation control plane to share a global GCE load balancer (this - should happen automatically). If they of the correct type, and + should happen automatically). If they are of the correct type, and have been correctly reconfigured, the UID data item in the GLBC configmap in each cluster will be identical across all clusters. See @@ -291,7 +291,7 @@ Check that: your GLBC will interfere with the behavior of your federated ingresses created after the reconfiguration (see [the GLBC docs](https://github.com/kubernetes/ingress/blob/7dcb4ae17d5def23d3e9c878f3146ac6df61b09d/controllers/gce/README.md) - for further information. To remedy this, + for further information). To remedy this, delete any ingresses created before the cluster joined the federation (and had its GLBC reconfigured), and recreate them if necessary. diff --git a/docs/tasks/administer-federation/replicaset.md b/docs/tasks/administer-federation/replicaset.md index ea20022148..896442b35b 100644 --- a/docs/tasks/administer-federation/replicaset.md +++ b/docs/tasks/administer-federation/replicaset.md @@ -56,7 +56,7 @@ federation ReplicaSet. ### Spreading Replicas in Underlying Clusters -By default, replicas are spread equally in all the underlying clusters. For ex: +By default, replicas are spread equally in all the underlying clusters. For example: if you have 3 registered clusters and you create a federated ReplicaSet with `spec.replicas = 9`, then each ReplicaSet in the 3 clusters will have `spec.replicas=3`.