Spelling errors in /docs/
parent
5c5ebf0bf1
commit
83a6c52ddc
|
@ -24,7 +24,7 @@ general.
|
|||
|
||||
## Overview
|
||||
|
||||
Events in federation control plane (refered to as "federation events" in
|
||||
Events in federation control plane (referred to as "federation events" in
|
||||
this guide) are very similar to the traditional Kubernetes
|
||||
Events providing the same functionality.
|
||||
Federation Events are stored only in federation control plane and are not passed on to the underlying kubernetes clusters.
|
||||
|
|
|
@ -232,7 +232,7 @@ due to caching by intermediate DNS servers.
|
|||
The above set of DNS records is automatically kept in sync with the
|
||||
current state of health of all service shards globally by the
|
||||
Federated Service system. DNS resolver libraries (which are invoked by
|
||||
all clients) automatically traverse the hiearchy of 'CNAME' and 'A'
|
||||
all clients) automatically traverse the hierarchy of 'CNAME' and 'A'
|
||||
records to return the correct set of healthy IP addresses. Clients can
|
||||
then select any one of the returned addresses to initiate a network
|
||||
connection (and fail over automatically to one of the other equivalent
|
||||
|
@ -295,7 +295,7 @@ availability zones and regions other than the ones local to a Pod by
|
|||
specifying the appropriate DNS names explicitly, and not relying on
|
||||
automatic DNS expansion. For example,
|
||||
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
|
||||
resolve to all of the currently healthy service shards in europe, even
|
||||
resolve to all of the currently healthy service shards in Europe, even
|
||||
if the Pod issuing the lookup is located in the U.S., and irrespective
|
||||
of whether or not there are healthy shards of the service in the U.S.
|
||||
This is useful for remote monitoring and other similar applications.
|
||||
|
@ -316,7 +316,7 @@ us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.ex
|
|||
nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com.
|
||||
```
|
||||
That way your clients can always use the short form on the left, and
|
||||
always be automatcally routed to the closest healthy shard on their
|
||||
always be automatically routed to the closest healthy shard on their
|
||||
home continent. All of the required failover is handled for you
|
||||
automatically by Kubernetes Cluster Federation. Future releases will
|
||||
improve upon this even further.
|
||||
|
|
|
@ -159,7 +159,7 @@ reasons:
|
|||
* This is uncommon and would have to be done by someone with root access to nodes.
|
||||
* All containers in a pod are terminated, requiring a restart (RestartPolicyAlways) AND the record of init container completion has been lost due to garbage collection.
|
||||
|
||||
## Support and compatibilty
|
||||
## Support and compatibility
|
||||
|
||||
A cluster with Kubelet and Apiserver version 1.4.0 or greater supports init
|
||||
containers with the beta annotations. Support varies for other combinations of
|
||||
|
|
|
@ -666,7 +666,7 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
|
|||
|
||||
### Use-case: Dotfiles in secret volume
|
||||
|
||||
In order to make piece of data 'hidden' (ie, in a file whose name begins with a dot character), simply
|
||||
In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply
|
||||
make that key begin with a dot. For example, when the following secret is mounted into a volume:
|
||||
|
||||
```json
|
||||
|
|
|
@ -500,7 +500,7 @@ within AWS Certificate Manager.
|
|||
},
|
||||
```
|
||||
|
||||
The second annotation specificies which protocol a pod speaks. For HTTPS and
|
||||
The second annotation specifies which protocol a pod speaks. For HTTPS and
|
||||
SSL, the ELB will expect the pod to authenticate itself over the encrypted
|
||||
connection.
|
||||
|
||||
|
|
Loading…
Reference in New Issue