Auto-fixed docs

lavalamp · Jul 10, 2015 · c03a788 · c03a788
1 parent c4aab16
commit c03a788
Show file tree

Hide file tree

Showing 43 changed files with 86 additions and 89 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -29,9 +29,9 @@ certainly want the docs that go with that version.</h1>
 * The [API object documentation](http://kubernetes.io/third_party/swagger-ui/)
   is a detailed description of all fields found in core API objects.
 
-* An overview of the [Design of Kubernetes](design)
+* An overview of the [Design of Kubernetes](design/)
 
-* There are example files and walkthroughs in the [examples](../examples)
+* There are example files and walkthroughs in the [examples](../examples/)
   folder.
 
 

diff --git a/docs/accessing_the_api.md b/docs/accessing_the_api.md
@@ -24,8 +24,8 @@ By default the Kubernetes APIserver serves HTTP on 2 ports:
     - default is port 6443, change with `--secure-port` flag.
     - default IP is first non-localhost network interface, change with `--bind-address` flag.
     - serves HTTPS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
-    - uses token-file or client-certificate based [authentication](./authentication.md).
-    - uses policy-based [authorization](./authorization.md).
+    - uses token-file or client-certificate based [authentication](authentication.md).
+    - uses policy-based [authorization](authorization.md).
   3. Removed: ReadOnly Port
     - For security reasons, this had to be removed. Use the service account feature instead.
 

diff --git a/docs/admission_controllers.md b/docs/admission_controllers.md
@@ -46,7 +46,7 @@ commands in those containers, we strongly encourage enabling this plug-in.
 
 ### ServiceAccount
 
-This plug-in implements automation for [serviceAccounts]( service_accounts.md).
+This plug-in implements automation for [serviceAccounts](service_accounts.md).
 We strongly recommend using this plug-in if you intend to make use of Kubernetes ```ServiceAccount``` objects.
 
 ### SecurityContextDeny
@@ -59,7 +59,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
 enumerated in the ```ResourceQuota``` object in a ```Namespace```.  If you are using ```ResourceQuota```
 objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
 
-See the [resourceQuota design doc]( design/admission_control_resource_quota.md).
+See the [resourceQuota design doc](design/admission_control_resource_quota.md).
 
 It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins.  This is
 so that quota is not prematurely incremented only for the request to be rejected later in admission control.
@@ -70,7 +70,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
 enumerated in the ```LimitRange``` object in a ```Namespace```.  If you are using ```LimitRange``` objects in
 your Kubernetes deployment, you MUST use this plug-in to enforce those constraints.
 
-See the [limitRange design doc]( design/admission_control_limit_range.md).
+See the [limitRange design doc](design/admission_control_limit_range.md).
 
 ### NamespaceExists
 

diff --git a/docs/api-conventions.md b/docs/api-conventions.md
@@ -118,7 +118,7 @@ In order to preserve extensibility, in the future, we intend to explicitly conve
 
 Note that historical information status (e.g., last transition time, failure counts) is only provided at best effort, and is not guaranteed to not be lost.
 
-Status information that may be large (especially unbounded in size, such as lists of references to other objects -- see below) and/or rapidly changing, such as [resource usage](./design/resources.md#usage-data), should be put into separate objects, with possibly a reference from the original object. This helps to ensure that GETs and watch remain reasonably efficient for the majority of clients, which may not need that data.
+Status information that may be large (especially unbounded in size, such as lists of references to other objects -- see below) and/or rapidly changing, such as [resource usage](design/resources.md#usage-data), should be put into separate objects, with possibly a reference from the original object. This helps to ensure that GETs and watch remain reasonably efficient for the majority of clients, which may not need that data.
 
 #### References to related objects
 

diff --git a/docs/authorization.md b/docs/authorization.md
@@ -2,7 +2,7 @@
 
 
 In Kubernetes, authorization happens as a separate step from authentication.
-See the [authentication documentation](./authentication.md) for an 
+See the [authentication documentation](authentication.md) for an 
 overview of authentication.
 
 Authorization applies to all HTTP accesses on the main apiserver port. (The

diff --git a/docs/availability.md b/docs/availability.md
@@ -120,7 +120,7 @@ then you need `R + U` clusters.  If it is not (e.g you want to ensure low latenc
 cluster failure), then you need to have `R * U` clusters (`U` in each of `R` regions).  In any case, try to put each cluster in a different zone.
 
 Finally, if any of your clusters would need more than the maximum recommended number of nodes for a Kubernetes cluster, then
-you may need even more clusters.  Our [roadmap](./roadmap.md)
+you may need even more clusters.  Our [roadmap](roadmap.md)
 calls for maximum 100 node clusters at v1.0 and maximum 1000 node clusters in the middle of 2015.
 
 ## Working with multiple clusters

diff --git a/docs/cluster-admin-guide.md b/docs/cluster-admin-guide.md
@@ -64,13 +64,13 @@ project.](salt.md).
   Describes the environment for Kubelet managed containers on a Kubernetes
   node.
 
-* **Securing access to the API Server** [accessing the api]( accessing_the_api.md)
+* **Securing access to the API Server** [accessing the api](accessing_the_api.md)
 
-* **Authentication**  [authentication]( authentication.md)
+* **Authentication**  [authentication](authentication.md)
 
-* **Authorization** [authorization]( authorization.md)
+* **Authorization** [authorization](authorization.md)
 
-* **Admission Controllers** [admission_controllers]( admission_controllers.md)
+* **Admission Controllers** [admission_controllers](admission_controllers.md)
 
 
 

diff --git a/docs/compute_resources.md b/docs/compute_resources.md
@@ -9,7 +9,7 @@
   - [Troubleshooting](#troubleshooting)
   - [Planned Improvements](#planned-improvements)
 
-When specifying a [pod](./pods.md), you can optionally specify how much CPU and memory (RAM) each
+When specifying a [pod](pods.md), you can optionally specify how much CPU and memory (RAM) each
 container needs.  When containers have resource limits, the scheduler is able to make better
 decisions about which nodes to place pods on, and contention for resources can be handled in a
 consistent manner.
@@ -19,8 +19,8 @@ in units of cores.  Memory is specified in units of bytes.
 
 CPU and RAM are collectively refered to as *compute resources*, or just *resources*.  Compute
 resources are measureable quantities which can be requested, allocated, and consumed.  They are
-distinct from [API resources](./working_with_resources.md).  API resources, such as pods and
-[services](./services.md) are objects that can be written to and retrieved from the Kubernetes API
+distinct from [API resources](working_with_resources.md).  API resources, such as pods and
+[services](services.md) are objects that can be written to and retrieved from the Kubernetes API
 server.
 
 ## Container and Pod Resource Limits
@@ -136,19 +136,19 @@ Here are some example command lines that extract just the necessary information:
 - `kubectl get nodes -o yaml | grep '\sname\|cpu\|memory'`
 - `kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'`
 
-The [resource quota](./resource_quota_admin.md) feature can be configured
+The [resource quota](resource_quota_admin.md) feature can be configured
 to limit the total amount of resources that can be consumed.  If used in conjunction
 with namespaces, it can prevent one team from hogging all the resources.
 
 ## Planned Improvements
 
 The current system only allows resource quantities to be specified on a container.
 It is planned to improve accounting for resources which are shared by all containers in a pod,
-such as [EmptyDir volumes](./volumes.md#emptydir).
+such as [EmptyDir volumes](volumes.md#emptydir).
 
 The current system only supports container limits for CPU and Memory.
 It is planned to add new resource types, including a node disk space
-resource, and a framework for adding custom [resource types](./design/resources.md#resource-types).
+resource, and a framework for adding custom [resource types](design/resources.md#resource-types).
 
 The current system does not facilitate overcommitment of resources because resources reserved
 with container limits are assured.  It is planned to support multiple levels of [Quality of

diff --git a/docs/container-environment.md b/docs/container-environment.md
@@ -7,7 +7,7 @@ This document describes the environment for Kubelet managed containers on a Kube
 This cluster information makes it possible to build applications that are *cluster aware*.  
 Additionally, the Kubernetes container environment defines a series of hooks that are surfaced to optional hook handlers defined as part of individual containers.  Container hooks are somewhat analogous to operating system signals in a traditional process model.   However these hooks are designed to make it easier to build reliable, scalable cloud applications in the Kubernetes cluster.  Containers that participate in this cluster lifecycle become *cluster native*. 
 
-Another important part of the container environment is the file system that is available to the container.  In Kubernetes, the filesystem is a combination of an [image](./images.md) and one or more [volumes](./volumes.md).
+Another important part of the container environment is the file system that is available to the container.  In Kubernetes, the filesystem is a combination of an [image](images.md) and one or more [volumes](volumes.md).
 
 
 The following sections describe both the cluster information provided to containers, as well as the hooks and life-cycle that allows containers to interact with the management system.

diff --git a/docs/design/access.md b/docs/design/access.md
@@ -141,7 +141,7 @@ Improvements:
 ###Namespaces
 K8s will have a have a `namespace` API object.  It is similar to a Google Compute Engine `project`.  It provides a namespace for objects created by a group of people co-operating together, preventing name collisions with non-cooperating groups.  It also serves as a reference point for authorization policies.
 
-Namespaces are described in [namespace.md](namespaces.md).
+Namespaces are described in [namespaces.md](namespaces.md).
 
 In the Enterprise Profile:
    - a `userAccount` may have permission to access several `namespace`s.
@@ -151,7 +151,7 @@ In the Simple Profile:
 
 Namespaces versus userAccount vs Labels:
 - `userAccount`s are intended for audit logging (both name and UID should be logged), and to define who has access to `namespace`s.
-- `labels` (see [docs/labels.md](/docs/labels.md)) should be used to distinguish pods, users, and other objects that cooperate towards a common goal but are different in some way, such as version, or responsibilities.
+- `labels` (see [docs/labels.md](../../docs/labels.md)) should be used to distinguish pods, users, and other objects that cooperate towards a common goal but are different in some way, such as version, or responsibilities.
 - `namespace`s prevent name collisions between uncoordinated groups of people, and provide a place to attach common policies for co-operating groups of people.
 
 

diff --git a/docs/design/resources.md b/docs/design/resources.md
@@ -149,7 +149,7 @@ The following are planned future extensions to the resource model, included here
 
 ## Usage data
 
-Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, such as [Pods](pods.md) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.
+Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, such as [Pods](../pods.md) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.
 
 Singleton values for observed and predicted future usage will rapidly prove inadequate, so we will support the following structure for extended usage information: 
 

diff --git a/docs/design/secrets.md b/docs/design/secrets.md
@@ -71,7 +71,7 @@ service would also consume the secrets associated with the MySQL service.
 
 ### Use-Case: Secrets associated with service accounts
 
-[Service Accounts](./service_accounts.md) are proposed as a
+[Service Accounts](service_accounts.md) are proposed as a
 mechanism to decouple capabilities and security contexts from individual human users.  A
 `ServiceAccount` contains references to some number of secrets.  A `Pod` can specify that it is
 associated with a `ServiceAccount`.  Secrets should have a `Type` field to allow the Kubelet and
@@ -241,7 +241,7 @@ memory overcommit on the node.
 
 #### Secret data on the node: isolation
 
-Every pod will have a [security context](./security_context.md).
+Every pod will have a [security context](security_context.md).
 Secret data on the node should be isolated according to the security context of the container.  The
 Kubelet volume plugin API will be changed so that a volume plugin receives the security context of
 a volume along with the volume spec.  This will allow volume plugins to implement setting the
@@ -253,7 +253,7 @@ Several proposals / upstream patches are notable as background for this proposal
 
 1.  [Docker vault proposal](https://github.com/docker/docker/issues/10310)
 2.  [Specification for image/container standardization based on volumes](https://github.com/docker/docker/issues/9277)
-3.  [Kubernetes service account proposal](./service_accounts.md)
+3.  [Kubernetes service account proposal](service_accounts.md)
 4.  [Secrets proposal for docker (1)](https://github.com/docker/docker/pull/6075)
 5.  [Secrets proposal for docker (2)](https://github.com/docker/docker/pull/6697)
 

diff --git a/docs/design/security.md b/docs/design/security.md
@@ -63,14 +63,14 @@ Automated process users fall into the following categories:
 A pod runs in a *security context* under a *service account* that is defined by an administrator or project administrator, and the *secrets* a pod has access to is limited by that *service account*.
 
 
-1. The API should authenticate and authorize user actions [authn and authz](./access.md)
+1. The API should authenticate and authorize user actions [authn and authz](access.md)
 2. All infrastructure components (kubelets, kube-proxies, controllers, scheduler) should have an infrastructure user that they can authenticate with and be authorized to perform only the functions they require against the API.
 3. Most infrastructure components should use the API as a way of exchanging data and changing the system, and only the API should have access to the underlying data store (etcd)
-4. When containers run on the cluster and need to talk to other containers or the API server, they should be identified and authorized clearly as an autonomous process via a [service account](./service_accounts.md)
+4. When containers run on the cluster and need to talk to other containers or the API server, they should be identified and authorized clearly as an autonomous process via a [service account](service_accounts.md)
    1.  If the user who started a long-lived process is removed from access to the cluster, the process should be able to continue without interruption
    2.  If the user who started processes are removed from the cluster, administrators may wish to terminate their processes in bulk
    3.  When containers run with a service account, the user that created / triggered the service account behavior must be associated with the container's action
-5. When container processes run on the cluster, they should run in a [security context](./security_context.md) that isolates those processes via Linux user security, user namespaces, and permissions.
+5. When container processes run on the cluster, they should run in a [security context](security_context.md) that isolates those processes via Linux user security, user namespaces, and permissions.
    1.  Administrators should be able to configure the cluster to automatically confine all container processes as a non-root, randomly assigned UID
    2.  Administrators should be able to ensure that container processes within the same namespace are all assigned the same unix user UID
    3.  Administrators should be able to limit which developers and project administrators have access to higher privilege actions
@@ -79,7 +79,7 @@ A pod runs in a *security context* under a *service account* that is defined by
    6.  Developers may need to ensure their images work within higher security requirements specified by administrators
    7.  When available, Linux kernel user namespaces can be used to ensure 5.2 and 5.4 are met.
    8.  When application developers want to share filesytem data via distributed filesystems, the Unix user ids on those filesystems must be consistent across different container processes
-6. Developers should be able to define [secrets](./secrets.md) that are automatically added to the containers when pods are run
+6. Developers should be able to define [secrets](secrets.md) that are automatically added to the containers when pods are run
    1.  Secrets are files injected into the container whose values should not be displayed within a pod. Examples:
        1. An SSH private key for git cloning remote data
        2. A client certificate for accessing a remote system
@@ -93,11 +93,11 @@ A pod runs in a *security context* under a *service account* that is defined by
 
 ### Related design discussion
 
-* [Authorization and authentication](./access.md)
+* [Authorization and authentication](access.md)
 * [Secret distribution via files](https://github.com/GoogleCloudPlatform/kubernetes/pull/2030)
 * [Docker secrets](https://github.com/docker/docker/pull/6697)
 * [Docker vault](https://github.com/docker/docker/issues/10310)
-* [Service Accounts:](./service_accounts.md)
+* [Service Accounts:](service_accounts.md)
 * [Secret volumes](https://github.com/GoogleCloudPlatform/kubernetes/pull/4126)
 
 ## Specific Design Points

diff --git a/docs/design/security_context.md b/docs/design/security_context.md
@@ -32,7 +32,7 @@ Processes in pods will need to have consistent UID/GID/SELinux category labels i
 * The concept of a security context should not be tied to a particular security mechanism or platform 
   (ie. SELinux, AppArmor)
 * Applying a different security context to a scope (namespace or pod) requires a solution such as the one proposed for
-  [service accounts](./service_accounts.md).
+  [service accounts](service_accounts.md).
 
 ## Use Cases
 

diff --git a/docs/design/service_accounts.md b/docs/design/service_accounts.md
@@ -21,9 +21,9 @@ They also may interact with services other than the Kubernetes API, such as:
 A service account binds together several things:
   - a *name*, understood by users, and perhaps by peripheral systems, for an identity
   - a *principal* that can be authenticated and [authorized](../authorization.md)
-  - a [security context](./security_context.md), which defines the Linux Capabilities, User IDs, Groups IDs, and other
+  - a [security context](security_context.md), which defines the Linux Capabilities, User IDs, Groups IDs, and other
     capabilities and controls on interaction with the file system and OS.
-  - a set of [secrets](./secrets.md), which a container may use to
+  - a set of [secrets](secrets.md), which a container may use to
     access various networked resources.
 
 ## Design Discussion