From 850c16e2c2b2744933163c2b0f245df97761a317 Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Fri, 19 Feb 2016 15:41:04 -0800 Subject: [PATCH] Variabalizing t the GitHub release branch so outbound links are version-specific across pages --- _config.yml | 1 + v1.1/docs/admin/admission-controllers.md | 6 +++--- v1.1/docs/admin/high-availability.md | 2 +- v1.1/docs/admin/limitrange/index.md | 2 +- v1.1/docs/admin/multi-cluster.md | 2 +- v1.1/docs/admin/namespaces.md | 10 +++++----- v1.1/docs/admin/networking.md | 2 +- v1.1/docs/admin/node.md | 2 +- v1.1/docs/admin/resource-quota.md | 2 +- v1.1/docs/admin/resourcequota/index.md | 2 +- v1.1/docs/api.md | 6 +++--- v1.1/docs/devel/api-conventions.md | 4 ++-- v1.1/docs/devel/api_changes.md | 2 +- v1.1/docs/devel/developer-guides/vagrant.md | 2 +- v1.1/docs/devel/index.md | 2 +- v1.1/docs/devel/scheduler.md | 2 +- v1.1/docs/devel/scheduler_algorithm.md | 2 +- v1.1/docs/getting-started-guides/aws.md | 4 ++-- v1.1/docs/getting-started-guides/coreos/azure/index.md | 2 +- .../getting-started-guides/coreos/bare_metal_calico.md | 2 +- .../coreos/bare_metal_offline.md | 2 +- v1.1/docs/getting-started-guides/dcos.md | 4 ++-- v1.1/docs/getting-started-guides/docker-multinode.md | 2 +- v1.1/docs/getting-started-guides/gce.md | 2 +- v1.1/docs/getting-started-guides/juju.md | 2 +- v1.1/docs/getting-started-guides/logging.md | 8 ++++---- v1.1/docs/getting-started-guides/mesos-docker.md | 2 +- v1.1/docs/getting-started-guides/rkt/index.md | 2 +- v1.1/docs/getting-started-guides/ubuntu-calico.md | 2 +- v1.1/docs/getting-started-guides/ubuntu.md | 2 +- v1.1/docs/getting-started-guides/vagrant.md | 2 +- v1.1/docs/index.md | 4 ++-- v1.1/docs/user-guide/accessing-the-cluster.md | 4 ++-- v1.1/docs/user-guide/compute-resources.md | 4 ++-- v1.1/docs/user-guide/configuring-containers.md | 2 +- v1.1/docs/user-guide/connecting-applications.md | 4 ++-- v1.1/docs/user-guide/environment-guide/index.md | 2 +- v1.1/docs/user-guide/horizontal-pod-autoscaler.md | 8 ++++---- .../user-guide/horizontal-pod-autoscaling/index.md | 4 ++-- v1.1/docs/user-guide/identifiers.md | 2 +- v1.1/docs/user-guide/logging.md | 4 ++-- v1.1/docs/user-guide/managing-deployments.md | 6 +++--- v1.1/docs/user-guide/node-selection/index.md | 2 +- v1.1/docs/user-guide/persistent-volumes.md | 4 ++-- v1.1/docs/user-guide/persistent-volumes/index.md | 2 +- v1.1/docs/user-guide/production-pods.md | 6 +++--- v1.1/docs/user-guide/secrets.md | 4 ++-- v1.1/docs/user-guide/secrets/index.md | 2 +- v1.1/docs/user-guide/security-context.md | 2 +- v1.1/docs/user-guide/update-demo/index.md | 2 +- v1.1/docs/user-guide/volumes.md | 10 +++++----- v1.1/docs/user-guide/walkthrough/index.md | 4 ++-- v1.1/docs/user-guide/walkthrough/k8s201.md | 2 +- v1.1/docs/whatisk8s.md | 4 ++-- 54 files changed, 89 insertions(+), 88 deletions(-) diff --git a/_config.yml b/_config.yml index 484bc25dce..cbe226e456 100644 --- a/_config.yml +++ b/_config.yml @@ -20,4 +20,5 @@ defaults: versionfilesafe: "v1_1" layout: docwithnav showedit: true + githubbranch: “release-1.1” permalink: pretty \ No newline at end of file diff --git a/v1.1/docs/admin/admission-controllers.md b/v1.1/docs/admin/admission-controllers.md index 9cedccab18..8a2c332930 100644 --- a/v1.1/docs/admin/admission-controllers.md +++ b/v1.1/docs/admin/admission-controllers.md @@ -75,7 +75,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](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](resourcequota/) for more details. +See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](resourcequota/) for more details. 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. @@ -88,7 +88,7 @@ your Kubernetes deployment, you MUST use this plug-in to enforce those constrain be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger applies a 0.1 CPU requirement to all Pods in the `default` namespace. -See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_limit_range.md) and the [example of Limit Range](limitrange/) for more details. +See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](limitrange/) for more details. ### InitialResources (experimental) @@ -97,7 +97,7 @@ then the plug-in auto-populates a compute resource request based on historical u If there is not enough data to make a decision the Request is left unchanged. When the plug-in sets a compute resource request, it annotates the pod with information on what compute resources it auto-populated. -See the [InitialResouces proposal](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/initial-resources.md) for more details. +See the [InitialResouces proposal](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/initial-resources.md) for more details. ### NamespaceExists (deprecated) diff --git a/v1.1/docs/admin/high-availability.md b/v1.1/docs/admin/high-availability.md index de584ac3e3..573ae21169 100644 --- a/v1.1/docs/admin/high-availability.md +++ b/v1.1/docs/admin/high-availability.md @@ -185,7 +185,7 @@ master election. On each of the three apiserver nodes, we run a small utility a election protocol using etcd "compare and swap". If the apiserver node wins the election, it starts the master component it is managing (e.g. the scheduler), if it loses the election, it ensures that any master components running on the node (e.g. the scheduler) are stopped. -In the future, we expect to more tightly integrate this lease-locking into the scheduler and controller-manager binaries directly, as described in the [high availability design proposal](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/high-availability.md) +In the future, we expect to more tightly integrate this lease-locking into the scheduler and controller-manager binaries directly, as described in the [high availability design proposal](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/high-availability.md) ### Installing configuration files diff --git a/v1.1/docs/admin/limitrange/index.md b/v1.1/docs/admin/limitrange/index.md index 4948e2b8d8..db756720df 100644 --- a/v1.1/docs/admin/limitrange/index.md +++ b/v1.1/docs/admin/limitrange/index.md @@ -26,7 +26,7 @@ This example demonstrates how limits can be applied to a Kubernetes namespace to min/max resource limits per pod. In addition, this example demonstrates how you can apply default resource limits to pods in the absence of an end-user specified value. -See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/{{page.version}}/docs/user-guide/compute-resources) +See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/{{page.version}}/docs/user-guide/compute-resources) ## Step 0: Prerequisites diff --git a/v1.1/docs/admin/multi-cluster.md b/v1.1/docs/admin/multi-cluster.md index 3aaa1e807a..87b719ee51 100644 --- a/v1.1/docs/admin/multi-cluster.md +++ b/v1.1/docs/admin/multi-cluster.md @@ -7,7 +7,7 @@ This document describes some of the issues to consider when making a decision ab Note that at present, Kubernetes does not offer a mechanism to aggregate multiple clusters into a single virtual cluster. However, -we [plan to do this in the future](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/federation.md). +we [plan to do this in the future](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/federation.md). ## Scope of a single cluster diff --git a/v1.1/docs/admin/namespaces.md b/v1.1/docs/admin/namespaces.md index 03a7e4b990..663c035952 100644 --- a/v1.1/docs/admin/namespaces.md +++ b/v1.1/docs/admin/namespaces.md @@ -84,13 +84,13 @@ to define *Hard* resource usage limits that a *Namespace* may consume. A limit range defines min/max constraints on the amount of resources a single entity can consume in a *Namespace*. -See [Admission control: Limit Range](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_limit_range.md) +See [Admission control: Limit Range](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_limit_range.md) A namespace can be in one of two phases: * `Active` the namespace is in use * `Terminating` the namespace is being deleted, and can not be used for new objects -See the [design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/namespaces.md#phases) for more details. +See the [design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/namespaces.md#phases) for more details. ### Creating a new namespace @@ -105,7 +105,7 @@ metadata: Note that the name of your namespace must be a DNS compatible label. -More information on the `finalizers` field can be found in the namespace [design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/namespaces.md#finalizers). +More information on the `finalizers` field can be found in the namespace [design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/namespaces.md#finalizers). Then run: @@ -141,5 +141,5 @@ across namespaces, you need to use the fully qualified domain name (FQDN). ## Design -Details of the design of namespaces in Kubernetes, including a [detailed example](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace) -can be found in the [namespaces design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/namespaces.md) \ No newline at end of file +Details of the design of namespaces in Kubernetes, including a [detailed example](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace) +can be found in the [namespaces design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/namespaces.md) \ No newline at end of file diff --git a/v1.1/docs/admin/networking.md b/v1.1/docs/admin/networking.md index 0fb472954c..8a9e1875d1 100644 --- a/v1.1/docs/admin/networking.md +++ b/v1.1/docs/admin/networking.md @@ -181,4 +181,4 @@ IPs. The early design of the networking model and its rationale, and some future plans are described in more detail in the [networking design -document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/networking.md). \ No newline at end of file +document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/networking.md). \ No newline at end of file diff --git a/v1.1/docs/admin/node.md b/v1.1/docs/admin/node.md index 97cd1c2c64..07e9e1bd51 100644 --- a/v1.1/docs/admin/node.md +++ b/v1.1/docs/admin/node.md @@ -10,7 +10,7 @@ title: "Node" may be a VM or physical machine, depending on the cluster. Each node has the services necessary to run [Pods](/{{page.version}}/docs/user-guide/pods) and is managed by the master components. The services on a node include docker, kubelet and network proxy. See -[The Kubernetes Node](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md#the-kubernetes-node) section in the +[The Kubernetes Node](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/architecture.md#the-kubernetes-node) section in the architecture design doc for more details. ## Node Status diff --git a/v1.1/docs/admin/resource-quota.md b/v1.1/docs/admin/resource-quota.md index 10fe37af63..48c48b5ca5 100755 --- a/v1.1/docs/admin/resource-quota.md +++ b/v1.1/docs/admin/resource-quota.md @@ -151,4 +151,4 @@ See a [detailed example for how to use resource quota](resourcequota/). ## Read More -See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_resource_quota.md) for more information. +See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_resource_quota.md) for more information. diff --git a/v1.1/docs/admin/resourcequota/index.md b/v1.1/docs/admin/resourcequota/index.md index cd6ba94c40..bb784cb804 100644 --- a/v1.1/docs/admin/resourcequota/index.md +++ b/v1.1/docs/admin/resourcequota/index.md @@ -3,7 +3,7 @@ title: "Resource Quota" --- This example demonstrates how [resource quota](/{{page.version}}/docs/admin/admission-controllers/#resourcequota) and [limitsranger](/{{page.version}}/docs/admin/admission-controllers/#limitranger) can be applied to a Kubernetes namespace. -See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_resource_quota.md) for more information. +See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_resource_quota.md) for more information. This example assumes you have a functional Kubernetes setup. diff --git a/v1.1/docs/api.md b/v1.1/docs/api.md index ef2a96e16e..af2000a647 100644 --- a/v1.1/docs/api.md +++ b/v1.1/docs/api.md @@ -30,7 +30,7 @@ multiple API versions, each at a different API path, such as `/api/v1` or We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-lifed and/or experimental APIs. Note that API versioning and Software versioning are only indirectly related. The [API and release -versioning proposal](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/versioning.md) describes the relationship between API versioning and +versioning proposal](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/versioning.md) describes the relationship between API versioning and software versioning. @@ -60,7 +60,7 @@ in more detail in the [API Changes documentation](/{{page.version}}/docs/devel/a ## API groups To make it easier to extend the Kubernetes API, we are in the process of implementing [*API -groups*](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/api-group.md). These are simply different interfaces to read and/or modify the +groups*](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/api-group.md). These are simply different interfaces to read and/or modify the same underlying resources. The API group is specified in a REST path and in the `apiVersion` field of a serialized object. @@ -73,7 +73,7 @@ Currently there are two API groups in use: In the future we expect that there will be more API groups, all at REST path `/apis/$API_GROUP` and using `apiVersion: $API_GROUP/$VERSION`. We expect that there will be a way for (third parties to -create their own API groups](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/extending-api.md), and to avoid naming collisions. +create their own API groups](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/extending-api.md), and to avoid naming collisions. ## Enabling resources in the extensions group diff --git a/v1.1/docs/devel/api-conventions.md b/v1.1/docs/devel/api-conventions.md index 7e79dd550b..87c48588b1 100644 --- a/v1.1/docs/devel/api-conventions.md +++ b/v1.1/docs/devel/api-conventions.md @@ -139,13 +139,13 @@ In general, condition values may change back and forth, but some condition trans A typical oscillating condition type is `Ready`, which indicates the object was believed to be fully operational at the time it was last probed. A possible monotonic condition could be `Succeeded`. A `False` status for `Succeeded` would imply failure. An object that was still active would not have a `Succeeded` condition, or its status would be `Unknown`. -Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion. +Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion. In condition types, and everywhere else they appear in the API, **`Reason`** is intended to be a one-word, CamelCase representation of the category of cause of the current status, and **`Message`** is intended to be a human-readable phrase or sentence, which may contain specific details of the individual occurrence. `Reason` is intended to be used in concise output, such as one-line `kubectl get` output, and in summarizing occurrences of causes, whereas `Message` is intended to be presented to users in detailed status explanations, such as `kubectl describe` output. Historical information status (e.g., last transition time, failure counts) is only provided with reasonable effort, and is not guaranteed to not be lost. -Status information that may be large (especially proportional in size to collections of other resources, such as lists of references to other objects -- see below) and/or rapidly changing, such as [resource usage](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/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 proportional in size to collections of other resources, such as lists of references to other objects -- see below) and/or rapidly changing, such as [resource usage](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/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. Some resources report the `observedGeneration`, which is the `generation` most recently observed by the component responsible for acting upon changes to the desired state of the resource. This can be used, for instance, to ensure that the reported status reflects the most recent desired status. diff --git a/v1.1/docs/devel/api_changes.md b/v1.1/docs/devel/api_changes.md index 738a3bdc89..a7ec388a12 100644 --- a/v1.1/docs/devel/api_changes.md +++ b/v1.1/docs/devel/api_changes.md @@ -251,7 +251,7 @@ Breaking compatibility of a beta or stable API version, such as v1, is unaccepta Compatibility for experimental or alpha APIs is not strictly required, but breaking compatibility should not be done lightly, as it disrupts all users of the feature. Experimental APIs may be removed. Alpha and beta API versions may be deprecated -and eventually removed wholesale, as described in the [versioning document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/versioning.md). +and eventually removed wholesale, as described in the [versioning document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/versioning.md). Document incompatible changes across API versions under the [conversion tips](/{{page.version}}/docs/api/). If your change is going to be backward incompatible or might be a breaking change for API diff --git a/v1.1/docs/devel/developer-guides/vagrant.md b/v1.1/docs/devel/developer-guides/vagrant.md index 8884c1ecae..3b9408deef 100644 --- a/v1.1/docs/devel/developer-guides/vagrant.md +++ b/v1.1/docs/devel/developer-guides/vagrant.md @@ -251,7 +251,7 @@ my-nginx nginx run=my-nginx 3 ``` We did not start any services, hence there are none listed. But we see three replicas displayed properly. -Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) application to learn how to create a service. +Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) application to learn how to create a service. You can already play with scaling the replicas with: ```shell diff --git a/v1.1/docs/devel/index.md b/v1.1/docs/devel/index.md index b065074e75..d21173eae1 100644 --- a/v1.1/docs/devel/index.md +++ b/v1.1/docs/devel/index.md @@ -64,7 +64,7 @@ Guide](/{{page.version}}/docs/admin/). Authorization applies to all HTTP requests on the main apiserver port. This doc explains the available authorization implementations. -* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control.md)) +* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control.md)) ## Building releases diff --git a/v1.1/docs/devel/scheduler.md b/v1.1/docs/devel/scheduler.md index aabab798bb..92f6318e83 100755 --- a/v1.1/docs/devel/scheduler.md +++ b/v1.1/docs/devel/scheduler.md @@ -35,7 +35,7 @@ the policies used are selected by the functions `defaultPredicates()` and `defau However, the choice of policies can be overridden by passing the command-line flag `--policy-config-file` to the scheduler, pointing to a JSON file specifying which scheduling policies to use. See -[examples/scheduler-policy-config.json](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/scheduler-policy-config.json) for an example +[examples/scheduler-policy-config.json](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/scheduler-policy-config.json) for an example config file. (Note that the config file format is versioned; the API is defined in [plugin/pkg/scheduler/api](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/api/)). Thus to add a new scheduling policy, you should modify predicates.go or priorities.go, diff --git a/v1.1/docs/devel/scheduler_algorithm.md b/v1.1/docs/devel/scheduler_algorithm.md index a6b730f3e8..7d751b27e7 100755 --- a/v1.1/docs/devel/scheduler_algorithm.md +++ b/v1.1/docs/devel/scheduler_algorithm.md @@ -8,7 +8,7 @@ For each unscheduled Pod, the Kubernetes scheduler tries to find a node across t The purpose of filtering the nodes is to filter out the nodes that do not meet certain requirements of the Pod. For example, if the free resource on a node (measured by the capacity minus the sum of the resource requests of all the Pods that already run on the node) is less than the Pod's required resource, the node should not be considered in the ranking phase so it is filtered out. Currently, there are several "predicates" implementing different filtering policies, including: - `NoDiskConflict`: Evaluate if a pod can fit due to the volumes it requests, and those that are already mounted. -- `PodFitsResources`: Check if the free resource (CPU and Memory) meets the requirement of the Pod. The free resource is measured by the capacity minus the sum of requests of all Pods on the node. To learn more about the resource QoS in Kubernetes, please check [QoS proposal](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/resource-qos.md). +- `PodFitsResources`: Check if the free resource (CPU and Memory) meets the requirement of the Pod. The free resource is measured by the capacity minus the sum of requests of all Pods on the node. To learn more about the resource QoS in Kubernetes, please check [QoS proposal](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/resource-qos.md). - `PodFitsHostPorts`: Check if any HostPort required by the Pod is already occupied on the node. - `PodFitsHost`: Filter out all nodes except the one specified in the PodSpec's NodeName field. - `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](/{{page.version}}/docs/user-guide/node-selection/) is an example of how to use `nodeSelector` field). diff --git a/v1.1/docs/getting-started-guides/aws.md b/v1.1/docs/getting-started-guides/aws.md index 86fe368554..9d2ee8416e 100644 --- a/v1.1/docs/getting-started-guides/aws.md +++ b/v1.1/docs/getting-started-guides/aws.md @@ -84,9 +84,9 @@ For more information, please read [kubeconfig files](/{{page.version}}/docs/user See [a simple nginx example](/{{page.version}}/docs/user-guide/simple-nginx) to try out your new cluster. -The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) +The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) -For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) +For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) ## Tearing down the cluster diff --git a/v1.1/docs/getting-started-guides/coreos/azure/index.md b/v1.1/docs/getting-started-guides/coreos/azure/index.md index 26c6f2c26e..73e5a0e3c1 100644 --- a/v1.1/docs/getting-started-guides/coreos/azure/index.md +++ b/v1.1/docs/getting-started-guides/coreos/azure/index.md @@ -212,7 +212,7 @@ You then should be able to access it from anywhere via the Azure virtual IP for You now have a full-blow cluster running in Azure, congrats! -You should probably try deploy other [example apps](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) or write your own ;) +You should probably try deploy other [example apps](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) or write your own ;) ## Tear down... diff --git a/v1.1/docs/getting-started-guides/coreos/bare_metal_calico.md b/v1.1/docs/getting-started-guides/coreos/bare_metal_calico.md index 4448f7069a..3779adcbcd 100644 --- a/v1.1/docs/getting-started-guides/coreos/bare_metal_calico.md +++ b/v1.1/docs/getting-started-guides/coreos/bare_metal_calico.md @@ -117,4 +117,4 @@ Once complete, restart the server. When it comes back up, you should have SSH a ## Testing the Cluster You should now have a functional bare-metal Kubernetes cluster with one master and two compute hosts. -Try running the [guestbook demo](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) to test out your new cluster! \ No newline at end of file +Try running the [guestbook demo](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) to test out your new cluster! \ No newline at end of file diff --git a/v1.1/docs/getting-started-guides/coreos/bare_metal_offline.md b/v1.1/docs/getting-started-guides/coreos/bare_metal_offline.md index 1076af3059..8b2440f2c5 100644 --- a/v1.1/docs/getting-started-guides/coreos/bare_metal_offline.md +++ b/v1.1/docs/getting-started-guides/coreos/bare_metal_offline.md @@ -648,7 +648,7 @@ Now that the CoreOS with Kubernetes installed is up and running lets spin up som See [a simple nginx example](/{{page.version}}/docs/user-guide/simple-nginx) to try out your new cluster. -For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/). +For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/). ## Helping commands for debugging diff --git a/v1.1/docs/getting-started-guides/dcos.md b/v1.1/docs/getting-started-guides/dcos.md index e2de048bcd..7dd1af3698 100644 --- a/v1.1/docs/getting-started-guides/dcos.md +++ b/v1.1/docs/getting-started-guides/dcos.md @@ -28,7 +28,7 @@ Explore the following resources for more information about Kubernetes, Kubernete - [DCOS Documentation](https://docs.mesosphere.com/) - [Managing DCOS Services](https://docs.mesosphere.com/services/kubernetes/) -- [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) +- [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) - [Kubernetes on Mesos Documentation](https://releases.k8s.io/release-1.1/contrib/mesos/README.md) - [Kubernetes on Mesos Release Notes](https://github.com/mesosphere/kubernetes-mesos/releases) - [Kubernetes on DCOS Package Source](https://github.com/mesosphere/kubernetes-mesos) @@ -105,7 +105,7 @@ $ dcos kubectl get pods --namespace=kube-system Names and ages may vary. -Now that Kubernetes is installed on DCOS, you may wish to explore the [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) or the [Kubernetes User Guide](/{{page.version}}/docs/user-guide/). +Now that Kubernetes is installed on DCOS, you may wish to explore the [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) or the [Kubernetes User Guide](/{{page.version}}/docs/user-guide/). ## Uninstall diff --git a/v1.1/docs/getting-started-guides/docker-multinode.md b/v1.1/docs/getting-started-guides/docker-multinode.md index 2563f9ad88..dc9118a42b 100644 --- a/v1.1/docs/getting-started-guides/docker-multinode.md +++ b/v1.1/docs/getting-started-guides/docker-multinode.md @@ -81,4 +81,4 @@ See [here](/{{page.version}}/docs/getting-started-guides/docker-multinode/deploy Once your cluster has been created you can [test it out](/{{page.version}}/docs/getting-started-guides/docker-multinode/testing) -For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) +For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) diff --git a/v1.1/docs/getting-started-guides/gce.md b/v1.1/docs/getting-started-guides/gce.md index 37a390b383..5635a967a9 100644 --- a/v1.1/docs/getting-started-guides/gce.md +++ b/v1.1/docs/getting-started-guides/gce.md @@ -152,7 +152,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh Then, see [a simple nginx example](/{{page.version}}/docs/user-guide/simple-nginx) to try out your new cluster. -For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/). The [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) is a good "getting started" walkthrough. +For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/). The [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) is a good "getting started" walkthrough. ### Tearing down the cluster diff --git a/v1.1/docs/getting-started-guides/juju.md b/v1.1/docs/getting-started-guides/juju.md index d849cd88bf..16515e3c53 100644 --- a/v1.1/docs/getting-started-guides/juju.md +++ b/v1.1/docs/getting-started-guides/juju.md @@ -192,7 +192,7 @@ juju add-unit docker # creates unit docker/2, kubernetes/2, docker-flannel/2 ## Launch the "k8petstore" example app -The [k8petstore example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/k8petstore/) is available as a +The [k8petstore example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/k8petstore/) is available as a [juju action](https://jujucharms.com/docs/devel/actions). ```shell diff --git a/v1.1/docs/getting-started-guides/logging.md b/v1.1/docs/getting-started-guides/logging.md index 8dd6ffd5fb..c1632c4efb 100644 --- a/v1.1/docs/getting-started-guides/logging.md +++ b/v1.1/docs/getting-started-guides/logging.md @@ -19,12 +19,12 @@ monitoring-heapster-v1-20ej 0/1 Running 9 32 Here is the same information in a picture which shows how the pods might be placed on specific nodes. -![Cluster](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/diagrams/cloud-logging.png) +![Cluster](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/diagrams/cloud-logging.png) This diagram shows four nodes created on a Google Compute Engine cluster with the name of each VM node on a purple background. The internal and public IPs of each node are shown on gray boxes and the pods running in each node are shown in green boxes. Each pod box shows the name of the pod and the namespace it runs in, the IP address of the pod and the images which are run as part of the pod's execution. Here we see that every node is running a fluentd-cloud-logging pod which is collecting the log output of the containers running on the same node and sending them to Google Cloud Logging. A pod which provides the [cluster DNS service](/{{page.version}}/docs/admin/dns) runs on one of the nodes and a pod which provides monitoring support runs on another node. -To help explain how cluster level logging works let's start off with a synthetic log generator pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/counter-pod.yaml): +To help explain how cluster level logging works let's start off with a synthetic log generator pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/counter-pod.yaml): @@ -41,7 +41,7 @@ spec: 'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done'] ``` -[Download example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/counter-pod.yaml) +[Download example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/counter-pod.yaml) This pod specification has one container which runs a bash script when the container is born. This script simply writes out the value of a counter and the date once per second and runs indefinitely. Let's create the pod in the default @@ -64,7 +64,7 @@ This step may take a few minutes to download the ubuntu:14.04 image during which One of the nodes is now running the counter pod: -![Counter Pod](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/diagrams/27gf-counter.png) +![Counter Pod](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/diagrams/27gf-counter.png) When the pod status changes to `Running` we can use the kubectl logs command to view the output of this counter pod. diff --git a/v1.1/docs/getting-started-guides/mesos-docker.md b/v1.1/docs/getting-started-guides/mesos-docker.md index a563ab555d..168e122705 100644 --- a/v1.1/docs/getting-started-guides/mesos-docker.md +++ b/v1.1/docs/getting-started-guides/mesos-docker.md @@ -184,7 +184,7 @@ host machine (mac). To learn more about Pods, Volumes, Labels, Services, and Replication Controllers, start with the [Kubernetes Walkthrough](/{{page.version}}/docs/user-guide/walkthrough/). - To skip to a more advanced example, see the [Guestbook Example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) + To skip to a more advanced example, see the [Guestbook Example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) 1. Destroy cluster diff --git a/v1.1/docs/getting-started-guides/rkt/index.md b/v1.1/docs/getting-started-guides/rkt/index.md index 21205acdeb..c6191166de 100644 --- a/v1.1/docs/getting-started-guides/rkt/index.md +++ b/v1.1/docs/getting-started-guides/rkt/index.md @@ -94,7 +94,7 @@ scripts. The master node is always Ubuntu. See [a simple nginx example](/{{page.version}}/docs/user-guide/simple-nginx) to try out your new cluster. -For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/). +For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/). ### Debugging diff --git a/v1.1/docs/getting-started-guides/ubuntu-calico.md b/v1.1/docs/getting-started-guides/ubuntu-calico.md index 9826cee2ce..f86d1f4f08 100644 --- a/v1.1/docs/getting-started-guides/ubuntu-calico.md +++ b/v1.1/docs/getting-started-guides/ubuntu-calico.md @@ -242,7 +242,7 @@ Replace `` in `calico-kubernetes-ubuntu-demo-master/dns/skydns-rc.yam ## Launch other Services With Calico-Kubernetes -At this point, you have a fully functioning cluster running on kubernetes with a master and 2 nodes networked with Calico. You can now follow any of the [standard documentation](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) to set up other services on your cluster. +At this point, you have a fully functioning cluster running on kubernetes with a master and 2 nodes networked with Calico. You can now follow any of the [standard documentation](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) to set up other services on your cluster. ## Connectivity to outside the cluster diff --git a/v1.1/docs/getting-started-guides/ubuntu.md b/v1.1/docs/getting-started-guides/ubuntu.md index f247041362..03bbeecf7e 100644 --- a/v1.1/docs/getting-started-guides/ubuntu.md +++ b/v1.1/docs/getting-started-guides/ubuntu.md @@ -139,7 +139,7 @@ NAME LABELS STATUS 10.10.103.250 kubernetes.io/hostname=10.10.103.250 Ready ``` -Also you can run Kubernetes [guest-example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) to build a redis backend cluster on the k8s． +Also you can run Kubernetes [guest-example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) to build a redis backend cluster on the k8s． ### Deploy addons diff --git a/v1.1/docs/getting-started-guides/vagrant.md b/v1.1/docs/getting-started-guides/vagrant.md index 5940c216c4..b61c0b4c1a 100644 --- a/v1.1/docs/getting-started-guides/vagrant.md +++ b/v1.1/docs/getting-started-guides/vagrant.md @@ -240,7 +240,7 @@ my-nginx 10.0.0.1 80/TCP run=my-nginx ``` We did not start any services, hence there are none listed. But we see three replicas displayed properly. -Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) application to learn how to create a service. +Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) application to learn how to create a service. You can already play with scaling the replicas with: ```shell diff --git a/v1.1/docs/index.md b/v1.1/docs/index.md index f08d7dbd42..fe59329e8a 100644 --- a/v1.1/docs/index.md +++ b/v1.1/docs/index.md @@ -17,9 +17,9 @@ title: "Kubernetes Documentation: releases.k8s.io/release-1.1" * 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](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/) +* An overview of the [Design of Kubernetes](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/) -* There are example files and walkthroughs in the [examples](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples) +* There are example files and walkthroughs in the [examples](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples) folder. * If something went wrong, see the [troubleshooting](troubleshooting) document for how to debug. diff --git a/v1.1/docs/user-guide/accessing-the-cluster.md b/v1.1/docs/user-guide/accessing-the-cluster.md index 42b344cfea..4cacf6363a 100644 --- a/v1.1/docs/user-guide/accessing-the-cluster.md +++ b/v1.1/docs/user-guide/accessing-the-cluster.md @@ -22,7 +22,7 @@ Check the location and credentials that kubectl knows about with this command: $ kubectl config view ``` -Many of the [examples](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) provide an introduction to using +Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) provide an introduction to using kubectl and complete documentation is found in the [kubectl manual](kubectl/kubectl). ### Directly accessing the REST API @@ -125,7 +125,7 @@ From within a pod the recommended ways to connect to API are: process within a container. This proxies the Kubernetes API to the localhost interface of the pod, so that other processes in any container of the pod can access it. See this [example of using kubectl proxy - in a pod](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/kubectl-container/). + in a pod](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/kubectl-container/). - use the Go client library, and create a client using the `client.NewInCluster()` factory. This handles locating and authenticating to the apiserver. diff --git a/v1.1/docs/user-guide/compute-resources.md b/v1.1/docs/user-guide/compute-resources.md index 659a5b807a..3fc0ebabe9 100644 --- a/v1.1/docs/user-guide/compute-resources.md +++ b/v1.1/docs/user-guide/compute-resources.md @@ -9,7 +9,7 @@ container needs. When containers have their resource requests specified, the sc able to make better decisions about which nodes to place pods on; and when containers have their limits specified, contention for resources on a node can be handled in a specified manner. For more details about the difference between requests and limits, please refer to -[Resource QoS](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/resource-qos.md). +[Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/resource-qos.md). *CPU* and *memory* are each a *resource type*. A resource type has a base unit. CPU is specified in units of cores. Memory is specified in units of bytes. @@ -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/blob/release-1.1/docs/design/resources.md#resource-types). +resource, and a framework for adding custom [resource types](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/resources.md#resource-types). Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168). diff --git a/v1.1/docs/user-guide/configuring-containers.md b/v1.1/docs/user-guide/configuring-containers.md index cb3cbad1d3..281ba759ab 100644 --- a/v1.1/docs/user-guide/configuring-containers.md +++ b/v1.1/docs/user-guide/configuring-containers.md @@ -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/release-1.1/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/{{ page.githubbranch }}/docs/design/expansion): ```yaml command: ["/bin/echo"] diff --git a/v1.1/docs/user-guide/connecting-applications.md b/v1.1/docs/user-guide/connecting-applications.md index 0191411db2..4deaca260c 100644 --- a/v1.1/docs/user-guide/connecting-applications.md +++ b/v1.1/docs/user-guide/connecting-applications.md @@ -198,7 +198,7 @@ Till now we have only accessed the nginx server from within the cluster. Before * An nginx server configured to use the certificates * A [secret](secrets) that makes the certificates accessible to pods -You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/https-nginx/), in short: +You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/https-nginx/), in short: ```shell $ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json @@ -262,7 +262,7 @@ spec: Noteworthy points about the nginx-app manifest: - It contains both rc and service specification in the same file -- The [nginx server](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/https-nginx/default.conf) serves http traffic on port 80 and https traffic on 443, and nginx Service exposes both ports. +- The [nginx server](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/https-nginx/default.conf) serves http traffic on port 80 and https traffic on 443, and nginx Service exposes both ports. - Each container has access to the keys through a volume mounted at /etc/nginx/ssl. This is setup *before* the nginx server is started. ```shell diff --git a/v1.1/docs/user-guide/environment-guide/index.md b/v1.1/docs/user-guide/environment-guide/index.md index f09a3645fc..10ea1da5ef 100644 --- a/v1.1/docs/user-guide/environment-guide/index.md +++ b/v1.1/docs/user-guide/environment-guide/index.md @@ -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/release-1.1/docs/design/namespaces.md) are retrieved from the +[namespace](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/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 diff --git a/v1.1/docs/user-guide/horizontal-pod-autoscaler.md b/v1.1/docs/user-guide/horizontal-pod-autoscaler.md index 5d4875333f..a232e4221b 100644 --- a/v1.1/docs/user-guide/horizontal-pod-autoscaler.md +++ b/v1.1/docs/user-guide/horizontal-pod-autoscaler.md @@ -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/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm). +Further details of the autoscaling algorithm are given [here](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/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/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#scale-subresource). +More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/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](/{{page.version}}/docs/api/)#api-versioning)). More details about the API object can be found at -[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). +[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/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/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md). +* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/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/). diff --git a/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md b/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md index 39fd221613..d0d5ae5c14 100644 --- a/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md +++ b/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md @@ -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/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm. +See [here](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm. We will create the autoscaler by executing the following command: @@ -102,7 +102,7 @@ $ kubectl create -f docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.ya horizontalpodautoscaler "php-apache" created ``` -Alternatively, we can create the autoscaler using [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_autoscale.md). +Alternatively, we can create the autoscaler using [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/user-guide/kubectl/kubectl_autoscale.md). The following command will create the equivalent autoscaler as defined in the [hpa-php-apache.yaml](hpa-php-apache.yaml) file: ```shell diff --git a/v1.1/docs/user-guide/identifiers.md b/v1.1/docs/user-guide/identifiers.md index c913a99191..08815aaf33 100644 --- a/v1.1/docs/user-guide/identifiers.md +++ b/v1.1/docs/user-guide/identifiers.md @@ -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/blob/release-1.1/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/{{ page.githubbranch }}/docs/design/identifiers.md) for the precise syntax rules for names. ## UIDs diff --git a/v1.1/docs/user-guide/logging.md b/v1.1/docs/user-guide/logging.md index 670a7a91aa..38f6f9282c 100644 --- a/v1.1/docs/user-guide/logging.md +++ b/v1.1/docs/user-guide/logging.md @@ -10,7 +10,7 @@ Kubernetes components, such as kubelet and apiserver, use the [glog](https://god ## Examining the logs of running containers The logs of a running container may be fetched using the command `kubectl logs`. For example, given -this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard +this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard output every second. (You can find different pod specifications [here](logging-demo/).) @@ -28,7 +28,7 @@ spec: 'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done'] ``` -[Download example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/counter-pod.yaml) +[Download example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/counter-pod.yaml) we can run the pod: diff --git a/v1.1/docs/user-guide/managing-deployments.md b/v1.1/docs/user-guide/managing-deployments.md index f7026bed45..798b9cb00c 100644 --- a/v1.1/docs/user-guide/managing-deployments.md +++ b/v1.1/docs/user-guide/managing-deployments.md @@ -113,7 +113,7 @@ my-nginx-svc app=nginx app=nginx 10.0.152.174 80/TCP The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another. -For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels: +For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels: ```yaml labels: @@ -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/blob/release-1.1/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/{{ page.githubbranch }}/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/blob/release-1.1/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/{{ page.githubbranch }}/docs/design/simple-rolling-update.md): ```shell $ kubectl rolling-update my-nginx --image=nginx:1.9.1 diff --git a/v1.1/docs/user-guide/node-selection/index.md b/v1.1/docs/user-guide/node-selection/index.md index 974263f01d..1ef8ed38fb 100644 --- a/v1.1/docs/user-guide/node-selection/index.md +++ b/v1.1/docs/user-guide/node-selection/index.md @@ -15,7 +15,7 @@ Then, to add a label to the node you've chosen, run `kubectl label nodes -This example demonstrates the usage of Kubernetes to perform a [rolling update](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_rolling-update.md) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](/{{page.version}}/docs/user-guide/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. +This example demonstrates the usage of Kubernetes to perform a [rolling update](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/user-guide/kubectl/kubectl_rolling-update.md) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](/{{page.version}}/docs/user-guide/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/{{ page.githubbranch }}/docs/design/simple-rolling-update.md) for more information. ### Step Zero: Prerequisites diff --git a/v1.1/docs/user-guide/volumes.md b/v1.1/docs/user-guide/volumes.md index 5beca5225f..7c298c7a40 100644 --- a/v1.1/docs/user-guide/volumes.md +++ b/v1.1/docs/user-guide/volumes.md @@ -235,7 +235,7 @@ writers simultaneously. __Important: You must have your own NFS server running with the share exported before you can use it__ -See the [NFS example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/nfs/) for more details. +See the [NFS example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/nfs/) for more details. ### iscsi @@ -254,7 +254,7 @@ and then serve it in parallel from as many pods as you need. Unfortunately, iSCSI volumes can only be mounted by a single consumer in read-write mode - no simultaneous readers allowed. -See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/iscsi/) for more details. +See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/iscsi/) for more details. ### flocker @@ -269,7 +269,7 @@ can be "handed off" between pods as required. __Important: You must have your own Flocker installation running before you can use it__ -See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/flocker/) for more details. +See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/flocker/) for more details. ### glusterfs @@ -284,7 +284,7 @@ simultaneously. __Important: You must have your own GlusterFS installation running before you can use it__ -See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/glusterfs/) for more details. +See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/glusterfs/) for more details. ### rbd @@ -304,7 +304,7 @@ and then serve it in parallel from as many pods as you need. Unfortunately, RBD volumes can only be mounted by a single consumer in read-write mode - no simultaneous writers allowed. -See the [RBD example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/rbd/) for more details. +See the [RBD example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/rbd/) for more details. ### gitRepo diff --git a/v1.1/docs/user-guide/walkthrough/index.md b/v1.1/docs/user-guide/walkthrough/index.md index 5fac7c4058..1ab95aa805 100644 --- a/v1.1/docs/user-guide/walkthrough/index.md +++ b/v1.1/docs/user-guide/walkthrough/index.md @@ -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/blob/release-1.1/docs/design/README.md) for more details. +See the [design document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/README.md) for more details. #### Pod Management @@ -179,4 +179,4 @@ Finally, we have also introduced an environment variable to the `git-monitor` co ## What's Next? Continue on to [Kubernetes 201](k8s201) or -for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) \ No newline at end of file +for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) \ No newline at end of file diff --git a/v1.1/docs/user-guide/walkthrough/k8s201.md b/v1.1/docs/user-guide/walkthrough/k8s201.md index 6abcac802a..ea3cd6c2ac 100644 --- a/v1.1/docs/user-guide/walkthrough/k8s201.md +++ b/v1.1/docs/user-guide/walkthrough/k8s201.md @@ -274,4 +274,4 @@ For more information about health checking, see [Container Probes](/{{page.versi ## What's Next? -For a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/). \ No newline at end of file +For a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/). \ No newline at end of file diff --git a/v1.1/docs/whatisk8s.md b/v1.1/docs/whatisk8s.md index ede8661b58..68660cbec6 100644 --- a/v1.1/docs/whatisk8s.md +++ b/v1.1/docs/whatisk8s.md @@ -75,9 +75,9 @@ Even though Kubernetes provides a lot of functionality, there are always new sce [Labels](/{{page.version}}/docs/user-guide/labels) empower users to organize their resources however they please. [Annotations](/{{page.version}}/docs/user-guide/annotations) enable users to decorate resources with custom information to facilitate their workflows and provide an easy way for management tools to checkpoint state. -Additionally, the [Kubernetes control plane](/{{page.version}}/docs/admin/cluster-components) is built upon the same [APIs](/{{page.version}}/docs/api/) that are available to developers and users. Users can write their own controllers, [schedulers](/{{page.version}}/docs/devel/scheduler), etc., if they choose, with [their own APIs](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/extending-api.md) that can be targeted by a general-purpose [command-line tool](/{{page.version}}/docs/user-guide/kubectl-overview). +Additionally, the [Kubernetes control plane](/{{page.version}}/docs/admin/cluster-components) is built upon the same [APIs](/{{page.version}}/docs/api/) that are available to developers and users. Users can write their own controllers, [schedulers](/{{page.version}}/docs/devel/scheduler), etc., if they choose, with [their own APIs](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/extending-api.md) that can be targeted by a general-purpose [command-line tool](/{{page.version}}/docs/user-guide/kubectl-overview). -This [design](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/principles.md) has enabled a number of other systems to build atop Kubernetes. +This [design](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/principles.md) has enabled a number of other systems to build atop Kubernetes. #### Kubernetes is not: