github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Make typography more consistent

Browse Source
This commit is contained in:
Ilya Dmitrichenko
2015-08-19 12:01:50 +01:00
parent c69dff8b69
commit cb3425351a
8 changed files with 63 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/user-guide/namespaces.md
View File

@@ -45,7 +45,7 @@ need the features they provide.
Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces.
Namespaces are a way to divide cluster resources between multiple uses (via [resource quota](../../docs/admin/resource-quota.md).
Namespaces are a way to divide cluster resources between multiple uses (via [resource quota])(../../docs/admin/resource-quota.md).
In future versions of Kubernetes, objects in the same namespace will have the same
access control policies by default.

8
docs/user-guide/secrets.md
View File

@@ -105,7 +105,7 @@ data:
```
The data field is a map. Its keys must match
[DNS_SUBDOMAIN](../design/identifiers.md), except that leading dots are also
[`DNS_SUBDOMAIN`](../design/identifiers.md), except that leading dots are also
allowed. The values are arbitrary data, encoded using base64. The values of
username and password in the example above, before base64 encoding,
are `value-1` and `value-2`, respectively, with carriage return and newline characters at the end.
@@ -167,8 +167,8 @@ Use of imagePullSecrets is described in the [images documentation](images.md#spe
*This feature is planned but not implemented. See [issue
9902](http://issue.k8s.io/9902).*
You can reference manually created secrets from a [service account](service-accounts.md).
Then, pods which use that service account will have
You can reference manually created secrets from a [Service Account](service-accounts.md).
Then, pods which use that Service Account will have
`volumeMounts` and/or `imagePullSecrets` added to them.
The secrets will be mounted at **TBD**.
@@ -441,7 +441,7 @@ Both containers will have the following files present on their filesystems:
Note how the specs for the two pods differ only in one field; this facilitates
creating pods with different capabilities from a common pod config template.
You could further simplify the base pod specification by using two service accounts:
You could further simplify the base pod specification by using two Service Accounts:
one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
`test-user` with the `test-db-secret`. Then, the pod spec can be shortened to, for example:

8
docs/user-guide/service-accounts.md
View File

@@ -43,12 +43,12 @@ as recommended by the Kubernetes project. Your cluster administrator may have
customized the behavior in your cluster, in which case this documentation may
not apply.*
When you (a human) access the cluster (e.g. using kubectl), you are
When you (a human) access the cluster (e.g. using `kubectl`), you are
authenticated by the apiserver as a particular User Account (currently this is
usually "admin", unless your cluster administrator has customized your
usually `admin`, unless your cluster administrator has customized your
cluster). Processes in containers inside pods can also contact the apiserver.
When they do, they are authenticated as a particular Service Account (e.g.
"default").
`default`).
## Using the Default Service Account to access the API server.
@@ -63,7 +63,7 @@ You can access the API using a proxy or with a client library, as described in
## Using Multiple Service Accounts.
Every namespace has a default service account resource called "default".
Every namespace has a default service account resource called `default`.
You can list this and any other serviceAccount resources in the namespace with this command:
```console

24
docs/user-guide/services.md
View File

@@ -96,7 +96,7 @@ which redirects to the backend `Pods`.
A `Service` in Kubernetes is a REST object, similar to a `Pod`. Like all of the
REST objects, a `Service` definition can be POSTed to the apiserver to create a
new instance. For example, suppose you have a set of `Pods` that each expose
port 9376 and carry a label "app=MyApp".
port 9376 and carry a label `"app=MyApp"`.
```json
{
@@ -121,7 +121,7 @@ port 9376 and carry a label "app=MyApp".
```
This specification will create a new `Service` object named "my-service" which
targets TCP port 9376 on any `Pod` with the "app=MyApp" label. This `Service`
targets TCP port 9376 on any `Pod` with the `"app=MyApp"` label. This `Service`
will also be assigned an IP address (sometimes called the "cluster IP"), which
is used by the service proxies (see below). The `Service`'s selector will be
evaluated continuously and the results will be POSTed to an `Endpoints` object
@@ -266,7 +266,7 @@ request. To do this, set the `spec.clusterIP` field. For example, if you
already have an existing DNS entry that you wish to replace, or legacy systems
that are configured for a specific IP address and difficult to re-configure.
The IP address that a user chooses must be a valid IP address and within the
service-cluster-ip-range CIDR range that is specified by flag to the API
`service-cluster-ip-range` CIDR range that is specified by flag to the API
server. If the IP address value is invalid, the apiserver returns a 422 HTTP
status code to indicate that the value is invalid.
@@ -299,7 +299,7 @@ compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
where the Service name is upper-cased and dashes are converted to underscores.
For example, the Service "redis-master" which exposes TCP port 6379 and has been
For example, the Service `"redis-master"` which exposes TCP port 6379 and has been
allocated cluster IP address 10.0.0.11 produces the following environment
variables:
@@ -325,17 +325,17 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of
DNS records for each. If DNS has been enabled throughout the cluster then all
`Pods` should be able to do name resolution of `Services` automatically.
For example, if you have a `Service` called "my-service" in Kubernetes
`Namespace` "my-ns" a DNS record for "my-service.my-ns" is created. `Pods`
which exist in the "my-ns" `Namespace` should be able to find it by simply doing
a name lookup for "my-service". `Pods` which exist in other `Namespaces` must
qualify the name as "my-service.my-ns". The result of these name lookups is the
For example, if you have a `Service` called `"my-service"` in Kubernetes
`Namespace` `"my-ns"` a DNS record for `"my-service.my-ns"` is created. `Pods`
which exist in the `"my-ns"` `Namespace` should be able to find it by simply doing
a name lookup for `"my-service"`. `Pods` which exist in other `Namespaces` must
qualify the name as `"my-service.my-ns"`. The result of these name lookups is the
cluster IP.
Kubernetes also supports DNS SRV (service) records for named ports. If the
"my-service.my-ns" `Service` has a port named "http" with protocol `TCP`, you
can do a DNS SRV query for "_http._tcp.my-service.my-ns" to discover the port
number for "http".
`"my-service.my-ns"` `Service` has a port named `"http"` with protocol `TCP`, you
can do a DNS SRV query for `"_http._tcp.my-service.my-ns"` to discover the port
number for `"http"`.
## Headless services

30
docs/user-guide/volumes.md
View File

@@ -91,9 +91,9 @@ medium that backs it, and the contents of it are determined by the particular
volume type used.
To use a volume, a pod specifies what volumes to provide for the pod (the
[spec.volumes](http://kubernetes.io/third_party/swagger-ui/#!/v1/createPod)
[`spec.volumes`](http://kubernetes.io/third_party/swagger-ui/#!/v1/createPod)
field) and where to mount those into containers(the
[spec.containers.volumeMounts](http://kubernetes.io/third_party/swagger-ui/#!/v1/createPod)
[`spec.containers.volumeMounts`](http://kubernetes.io/third_party/swagger-ui/#!/v1/createPod)
field).
A process in a container sees a filesystem view composed from their Docker
@@ -107,17 +107,17 @@ mount each volume.
## Types of Volumes
Kubernetes supports several types of Volumes:
* emptyDir
* hostPath
* gcePersistentDisk
* awsElasticBlockStore
* nfs
* iscsi
* glusterfs
* rbd
* gitRepo
* secret
* persistentVolumeClaim
* `emptyDir`
* `hostPath`
* `gcePersistentDisk`
* `awsElasticBlockStore`
* `nfs`
* `iscsi`
* `glusterfs`
* `rbd`
* `gitRepo`
* `secret`
* `persistentVolumeClaim`
We welcome additional contributions.
@@ -291,8 +291,8 @@ See the [NFS example](../../examples/nfs/) for more details.
For example, [this file](../../examples/nfs/nfs-web-pod.yaml) demonstrates how to
specify the usage of an NFS volume within a pod.
In this example one can see that a `volumeMount` called "nfs" is being mounted
onto `/var/www/html` in the container "web". The volume "nfs" is defined as
In this example one can see that a `volumeMount` called `nfs` is being mounted
onto `/var/www/html` in the container `web`. The volume "nfs" is defined as
type `nfs`, with the NFS server serving from `nfs-server.default.kube.local`
and exporting directory `/` as the share. The mount being created in this
example is writeable.