Skip to content

Commit

Permalink
Make typography more consistent
Browse files Browse the repository at this point in the history
  • Loading branch information
errordeveloper committed Aug 19, 2015
1 parent c69dff8 commit cb34253
Show file tree
Hide file tree
Showing 8 changed files with 63 additions and 63 deletions.
6 changes: 3 additions & 3 deletions docs/admin/networking.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,8 +80,8 @@ uses host-private networking. It creates a virtual bridge, called `docker0` by
default, and allocates a subnet from one of the private address blocks defined
in [RFC1918](https://tools.ietf.org/html/rfc1918) for that bridge. For each
container that Docker creates, it allocates a virtual ethernet device (called
`veth`) which is attached to the bridge. The veth is mapped to appear as eth0
in the container, using Linux namespaces. The in-container eth0 interface is
`veth`) which is attached to the bridge. The veth is mapped to appear as `eth0`
in the container, using Linux namespaces. The in-container `eth0` interface is
given an IP address from the bridge's address range.

The result is that Docker containers can talk to other containers only if they
Expand Down Expand Up @@ -147,7 +147,7 @@ here.

For the Google Compute Engine cluster configuration scripts, we use [advanced
routing](https://developers.google.com/compute/docs/networking#routing) to
assign each VM a subnet (default is /24 - 254 IPs). Any traffic bound for that
assign each VM a subnet (default is `/24` - 254 IPs). Any traffic bound for that
subnet will be routed directly to the VM by the GCE network fabric. This is in
addition to the "main" IP address assigned to the VM, which is NAT'ed for
outbound internet access. A linux bridge (called `cbr0`) is configured to exist
Expand Down
12 changes: 6 additions & 6 deletions docs/design/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Documentation for other releases can be found at

# Kubernetes architecture

A running Kubernetes cluster contains node agents (kubelet) and master components (APIs, scheduler, etc), on top of a distributed storage solution. This diagram shows our desired eventual state, though we're still working on a few things, like making kubelet itself (all our components, really) run within containers, and making the scheduler 100% pluggable.
A running Kubernetes cluster contains node agents (`kubelet`) and master components (APIs, scheduler, etc), on top of a distributed storage solution. This diagram shows our desired eventual state, though we're still working on a few things, like making `kubelet` itself (all our components, really) run within containers, and making the scheduler 100% pluggable.

![Architecture Diagram](architecture.png?raw=true "Architecture overview")

Expand All @@ -45,21 +45,21 @@ The Kubernetes node has the services necessary to run application containers and

Each node runs Docker, of course. Docker takes care of the details of downloading images and running containers.

### Kubelet
### `kubelet`

The **Kubelet** manages [pods](../user-guide/pods.md) and their containers, their images, their volumes, etc.
The `kubelet` manages [pods](../user-guide/pods.md) and their containers, their images, their volumes, etc.

### Kube-Proxy
### `kube-proxy`

Each node also runs a simple network proxy and load balancer (see the [services FAQ](https://github.com/GoogleCloudPlatform/kubernetes/wiki/Services-FAQ) for more details). This reflects `services` (see [the services doc](../user-guide/services.md) for more details) as defined in the Kubernetes API on each node and can do simple TCP and UDP stream forwarding (round robin) across a set of backends.

Service endpoints are currently found via [DNS](../admin/dns.md) or through environment variables (both [Docker-links-compatible](https://docs.docker.com/userguide/dockerlinks/) and Kubernetes {FOO}_SERVICE_HOST and {FOO}_SERVICE_PORT variables are supported). These variables resolve to ports managed by the service proxy.
Service endpoints are currently found via [DNS](../admin/dns.md) or through environment variables (both [Docker-links-compatible](https://docs.docker.com/userguide/dockerlinks/) and Kubernetes `{FOO}_SERVICE_HOST` and `{FOO}_SERVICE_PORT` variables are supported). These variables resolve to ports managed by the service proxy.

## The Kubernetes Control Plane

The Kubernetes control plane is split into a set of components. Currently they all run on a single _master_ node, but that is expected to change soon in order to support high-availability clusters. These components work together to provide a unified view of the cluster.

### etcd
### `etcd`

All persistent master state is stored in an instance of `etcd`. This provides a great way to store configuration data reliably. With `watch` support, coordinating components can be notified very quickly of changes.

Expand Down
36 changes: 18 additions & 18 deletions docs/getting-started-guides/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -137,8 +137,8 @@ GKE | | | GCE | [docs](https://clou
Vagrant | Saltstack | Fedora | OVS | [docs](vagrant.md) | [][2] | Project
GCE | Saltstack | Debian | GCE | [docs](gce.md) | [][1] | Project
Azure | CoreOS | CoreOS | Weave | [docs](coreos/azure/README.md) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin))
Docker Single Node | custom | N/A | local | [docs](docker.md) | | Project (@brendandburns)
Docker Multi Node | Flannel | N/A | local | [docs](docker-multinode.md) | | Project (@brendandburns)
Docker Single Node | custom | N/A | local | [docs](docker.md) | | Project ([@brendandburns](https://github.com/brendandburns))
Docker Multi Node | Flannel | N/A | local | [docs](docker-multinode.md) | | Project ([@brendandburns](https://github.com/brendandburns))
Bare-metal | Ansible | Fedora | flannel | [docs](fedora/fedora_ansible_config.md) | | Project
Bare-metal | custom | Fedora | _none_ | [docs](fedora/fedora_manual_config.md) | | Project
Bare-metal | custom | Fedora | flannel | [docs](fedora/flannel_multi_node_cluster.md) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
Expand All @@ -147,26 +147,26 @@ KVM | custom | Fedora | flannel | [docs](fedora/flann
Mesos/Docker | custom | Ubuntu | Docker | [docs](mesos-docker.md) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
Mesos/GCE | | | | [docs](mesos.md) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
AWS | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community
GCE | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community [@pires](https://github.com/pires)
Vagrant | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community ( [@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles) )
Bare-metal (Offline) | CoreOS | CoreOS | flannel | [docs](coreos/bare_metal_offline.md) | | Community([@jeffbean](https://github.com/jeffbean))
Bare-metal | CoreOS | CoreOS | Calico | [docs](coreos/bare_metal_calico.md) | | Community([@caseydavenport](https://github.com/caseydavenport))
CloudStack | Ansible | CoreOS | flannel | [docs](cloudstack.md) | | Community (@runseb)
Vmware | | Debian | OVS | [docs](vsphere.md) | | Community (@pietern)
Bare-metal | custom | CentOS | _none_ | [docs](centos/centos_manual_config.md) | | Community(@coolsvap)
GCE | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community ([@pires](https://github.com/pires))
Vagrant | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
Bare-metal (Offline) | CoreOS | CoreOS | flannel | [docs](coreos/bare_metal_offline.md) | | Community ([@jeffbean](https://github.com/jeffbean))
Bare-metal | CoreOS | CoreOS | Calico | [docs](coreos/bare_metal_calico.md) | | Community ([@caseydavenport](https://github.com/caseydavenport))
CloudStack | Ansible | CoreOS | flannel | [docs](cloudstack.md) | | Community ([@runseb](https://github.com/runseb))
Vmware | | Debian | OVS | [docs](vsphere.md) | | Community ([@pietern](https://github.com/pietern))
Bare-metal | custom | CentOS | _none_ | [docs](centos/centos_manual_config.md) | | Community ([@coolsvap](https://github.com/coolsvap))
AWS | Juju | Ubuntu | flannel | [docs](juju.md) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
OpenStack/HPCloud | Juju | Ubuntu | flannel | [docs](juju.md) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
Joyent | Juju | Ubuntu | flannel | [docs](juju.md) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
AWS | Saltstack | Ubuntu | OVS | [docs](aws.md) | | Community (@justinsb)
Vmware | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community (@kelseyhightower)
AWS | Saltstack | Ubuntu | OVS | [docs](aws.md) | | Community ([@justinsb](https://github.com/justinsb))
Vmware | CoreOS | CoreOS | flannel | [docs](coreos.md) | | Community ([@kelseyhightower](https://github.com/kelseyhightower))
Azure | Saltstack | Ubuntu | OpenVPN | [docs](azure.md) | | Community
Bare-metal | custom | Ubuntu | Calico | [docs](ubuntu-calico.md) | | Community (@djosborne)
Bare-metal | custom | Ubuntu | flannel | [docs](ubuntu.md) | | Community (@resouer @WIZARD-CXY)
Local | | | _none_ | [docs](locally.md) | | Community (@preillyme)
libvirt/KVM | CoreOS | CoreOS | libvirt/KVM | [docs](libvirt-coreos.md) | | Community (@lhuard1A)
oVirt | | | | [docs](ovirt.md) | | Community (@simon3z)
Rackspace | CoreOS | CoreOS | flannel | [docs](rackspace.md) | | Community (@doublerr)
any | any | any | any | [docs](scratch.md) | | Community (@erictune)
Bare-metal | custom | Ubuntu | Calico | [docs](ubuntu-calico.md) | | Community ([@djosborne](https://github.com/djosborne))
Bare-metal | custom | Ubuntu | flannel | [docs](ubuntu.md) | | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
Local | | | _none_ | [docs](locally.md) | | Community ([@preillyme](https://github.com/preillyme))
libvirt/KVM | CoreOS | CoreOS | libvirt/KVM | [docs](libvirt-coreos.md) | | Community ([@lhuard1A](https://github.com/lhuard1A))
oVirt | | | | [docs](ovirt.md) | | Community ([@simon3z](https://github.com/simon3z))
Rackspace | CoreOS | CoreOS | flannel | [docs](rackspace.md) | | Community ([@doublerr](https://github.com/doublerr))
any | any | any | any | [docs](scratch.md) | | Community ([@erictune](https://github.com/erictune))


*Note*: The above table is ordered by version test/used in notes followed by support level.
Expand Down
2 changes: 1 addition & 1 deletion docs/user-guide/namespaces.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
8 changes: 4 additions & 4 deletions docs/user-guide/secrets.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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**.

Expand Down Expand Up @@ -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:

Expand Down
8 changes: 4 additions & 4 deletions docs/user-guide/service-accounts.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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
Expand Down
Loading

0 comments on commit cb34253

Please sign in to comment.