Links for Reference section

2016-02-18 02:41:14 -08:00
parent a260aa49b1
commit 668195b6cf
33 changed files with 131 additions and 80 deletions
@@ -238,7 +238,7 @@ such as [EmptyDir volumes](volumes/#emptydir).

 The current system only supports container requests and 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](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md#resource-types).
+resource, and a framework for adding custom [resource types](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/resources.md#resource-types).

 Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168).

@@ -89,7 +89,7 @@ spec:  # specification of the pod's contents
    args: ["/bin/echo \"${MESSAGE}\""]
 ```

-However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](https://github.com/kubernetes/kubernetes/blob/master/docs/design/expansion):
+However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/expansion):

 ```yaml
 command: ["/bin/echo"]
@@ -69,7 +69,7 @@ Backend Namespace: default
 ```

 First the frontend pod's information is printed. The pod name and
-[namespace](https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces.md) are retrieved from the
+[namespace](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/namespaces.md) are retrieved from the
 [Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
 an environment variable set in the [pod
 definition](show-rc.yaml). Then, the dynamic Kubernetes environment
@@ -28,21 +28,21 @@ Then, it compares the arithmetic mean of the pods' CPU utilization with the targ
 CPU utilization is the recent CPU usage of a pod divided by the sum of CPU requested by the pod's containers.
 Please note that if some of the pod's containers do not have CPU request set,
 CPU utilization for the pod will not be defined and the autoscaler will not take any action.
-Further details of the autoscaling algorithm are given [here](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm).
+Further details of the autoscaling algorithm are given [here](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm).

 Autoscaler uses heapster to collect CPU utilization.
 Therefore, it is required to deploy heapster monitoring in your cluster for autoscaling to work.

 Autoscaler accesses corresponding replication controller or deployment by scale sub-resource.
 Scale is an interface which allows to dynamically set the number of replicas and to learn the current state of them.
-More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#scale-subresource).
+More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#scale-subresource).


 ## API Object

 Horizontal pod autoscaler is a top-level resource in the Kubernetes REST API (currently in [beta](../api/#api-versioning)).
 More details about the API object can be found at
-[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).

 ## Support for horizontal pod autoscaler in kubectl

@@ -73,7 +73,7 @@ the horizontal pod autoscaler will not be bound to the new replication controlle

 ## Further reading

-* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md).
+* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md).
 * Manual of autoscale command in kubectl: [kubectl autoscale](kubectl/kubectl_autoscale).
 * Usage example of [Horizontal Pod Autoscaler](horizontal-pod-autoscaling/).

@@ -93,7 +93,7 @@ controlled by the php-apache replication controller we created in the first step
 Roughly speaking, the horizontal autoscaler will increase and decrease the number of replicas
 (via the replication controller) so as to maintain an average CPU utilization across all Pods of 50%
 (since each pod requests 200 milli-cores by [kubectl run](#kubectl-run), this means average CPU utilization of 100 milli-cores).
-See [here](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
+See [here](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.

 We will create the autoscaler by executing the following command:

@@ -7,7 +7,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](labels) an

 ## Names

-Names are generally client-provided.  Only one object of a given kind can have a given name at a time (i.e., they are spatially unique).  But if you delete an object, you can make a new object with the same name.  Names are the used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`.   By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions.  See the [identifiers design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/identifiers.md) for the precise syntax rules for names.
+Names are generally client-provided.  Only one object of a given kind can have a given name at a time (i.e., they are spatially unique).  But if you delete an object, you can make a new object with the same name.  Names are the used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`.   By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions.  See the [identifiers design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/identifiers.md) for the precise syntax rules for names.

 ## UIDs

@@ -233,7 +233,7 @@ my-nginx-o0ef1   1/1       Running   0          1h

 At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.

-To update a service without an outage, `kubectl` supports what is called ['rolling update'?](kubectl/kubectl_rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/simple-rolling-update.md) and the [example of rolling update](update-demo/) for more information.
+To update a service without an outage, `kubectl` supports what is called ['rolling update'?](kubectl/kubectl_rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/simple-rolling-update.md) and the [example of rolling update](update-demo/) for more information.

 Let's say you were running version 1.7.9 of nginx:

@@ -256,7 +256,7 @@ spec:
        - containerPort: 80
 ```

-To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://github.com/kubernetes/kubernetes/tree/master/docs/design/simple-rolling-update.md):
+To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/simple-rolling-update.md):

 ```shell
 $ kubectl rolling-update my-nginx --image=nginx:1.9.1
@@ -15,7 +15,7 @@ Then, to add a label to the node you've chosen, run `kubectl label nodes <node-n

 If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.

-Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
+Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.

 You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.

@@ -80,7 +80,7 @@ apiVersion: v1

 ### Capacity

-Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md) to understand the units expected by `capacity`.
+Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/resources.md) to understand the units expected by `capacity`.

 Currently, storage size is the only resource that can be set or requested.  Future attributes may include IOPS, throughput, etc.

@@ -146,7 +146,7 @@ Claims use the same conventions as volumes when requesting storage with specific

 ### Resources

-Claims, like pods, can request specific quantities of a resource.  In this case, the request is for storage.  The same [resource model](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md) applies to both volumes and claims.
+Claims, like pods, can request specific quantities of a resource.  In this case, the request is for storage.  The same [resource model](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/resources.md) applies to both volumes and claims.

 ## Claims As Volumes

@@ -6,7 +6,7 @@ nginx serving content from your persistent volume.

 This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.

-See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage.md) for more information.
+See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/persistent-storage.md) for more information.

 ## Provisioning

@@ -104,7 +104,7 @@ spec:
          name: supersecret
 ```

-For more details, see the [secrets document](secrets), [example](secrets/) and [design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets.md).
+For more details, see the [secrets document](secrets), [example](secrets/) and [design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/secrets.md).

 ## Authenticating with a private image registry

@@ -4,7 +4,7 @@ title: "Secrets"
 Objects of type `secret` are intended to hold sensitive information, such as
 passwords, OAuth tokens, and ssh keys.  Putting this information in a `secret`
 is safer and more flexible than putting it verbatim in a `pod` definition or in
-a docker image. See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets.md) for more information.
+a docker image. See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/secrets.md) for more information.

 * TOC
 {:toc}
@@ -51,7 +51,7 @@ data:
 ```

 The data field is a map.  Its keys must match
-[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/tree/master/docs/design/identifiers.md), except that leading dots are also
+[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/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.
@@ -1,7 +1,7 @@
 ---
 title: "Secrets example"
 ---
-Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets.md) for more information.
+Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/secrets.md) for more information.

 ## Step Zero: Prerequisites

@@ -1,4 +1,4 @@
 ---
 title: "Security Contexts"
 ---
-A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/kubernetes/tree/master/docs/design/security_context.md) for more details.
+A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security_context.md) for more details.
@@ -21,7 +21,7 @@ limitations under the License.

 # Rolling update example

-This example demonstrates the usage of Kubernetes to perform a [rolling update](../kubectl/kubectl_rolling-update) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](../managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/simple-rolling-update.md) for more information.
+This example demonstrates the usage of Kubernetes to perform a [rolling update](../kubectl/kubectl_rolling-update) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](../managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/simple-rolling-update.md) for more information.

 ### Step Zero: Prerequisites

@@ -43,7 +43,7 @@ spec:

 A pod definition is a declaration of a _desired state_.  Desired state is a very important concept in the Kubernetes model.  Many things present a desired state to the system, and it is Kubernetes' responsibility to make sure that the current state matches the desired state.  For example, when you create a Pod, you declare that you want the containers in it to be running.  If the containers happen to not be running (e.g. program failure, ...), Kubernetes will continue to (re-)create them for you in order to drive them to the desired state. This process continues until the Pod is deleted.

-See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/README.md) for more details.
+See the [design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/README.md) for more details.


 #### Pod Management
@@ -51,4 +51,4 @@ The API will generally not modify fields that you have set; it just sets ones wh

 ## <a name="finding_schema_docs"></a>Finding Documentation on Resource Fields

-You can browse auto-generated API documentation at the [project website](http://kubernetes.io/v1.1/api-ref) or on [github](https://releases.k8s.io/release-1.1/docs/api-reference).
+You can browse auto-generated API documentation at the [project website](/{{page.version}}/docs/api/) or on [github](https://releases.k8s.io/release-1.1/docs/api-reference).