whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Links for Reference section

Browse Source
This commit is contained in:
johndmulhausen
2016-02-18 02:41:14 -08:00
parent a260aa49b1
commit 668195b6cf
33 changed files with 131 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_data/v1_1/guides.yml
-4
View File
@@ -145,10 +145,6 @@ toc:
path: /v1.1/docs/user-guide/production-pods/
- title: Creating Pods with the Downward API
path: /v1.1/docs/user-guide/downward-api/
- title: Using Secrets
path: /v1.1/docs/user-guide/secrets/
- title: Using Persistent Volumes
path: /v1.1/docs/user-guide/persistent-volumes/
- title: Updating Live Pods
path: /v1.1/docs/user-guide/update-demo/
_data/v1_1/reference.yml
+87 -16
View File
@@ -8,17 +8,90 @@ toc:
section:
- title: Kubernetes API Overview
path: /v1.1/docs/api/
- title: Kubernetes API Reference
path: /v1.1/api-ref/
- title: Kubernetes API Operations
path: http://kubernetes.io/v1.1/docs/api-reference/v1/operations.html
- title: Kubernetes API Definitions
path: http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html
- title: Extensions API
section:
- title: Extensions API Operations
path: http://kubernetes.io/v1.1/docs/api-reference/extensions/v1beta1/operations.html
- title: Extensions API Definitions
path: http://kubernetes.io/v1.1/docs/api-reference/extensions/v1beta1/definitions.html
- title: kubectl
section:
- title: kubectl Overview
path: /v1.1/docs/user-guide/kubectl-overview/
- title: kubectl for Docker Users
path: /v1.1/reference/docker-cli-to-kubectl/
- title: kubectl Reference (pretend the child nodes are here)
path: /v1.1/docs/user-guide/kubectl/kubectl/
path: /v1.1/docs/user-guide/docker-cli-to-kubectl/
- title: kubectl
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl.md
- title: kubectl annotate
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_annotate.md
- title: kubectl api-versions
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_api-versions.md
- title: kubectl apply
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_apply.md
- title: kubectl attach
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_attach.md
- title: kubectl autoscale
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_autoscale.md
- title: kubectl cluster-info
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_cluster-info.md
- title: kubectl config
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config.md
- title: kubectl config set-cluster
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-cluster.md
- title: kubectl config set-context
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-context.md
- title: kubectl set-credentials
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-credentials.md
- title: kubectl config set
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set.md
- title: kubectl config unset
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_unset.md
- title: kubectl config use-context
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_use-context.md
- title: kubectl config view
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_view.md
- title: kubectl create
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md
- title: kubectl delete
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_delete.md
- title: kubectl describe
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_describe.md
- title: kubectl edit
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_edit.md
- title: kubectl exec
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_exec.md
- title: kubectl expose
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_expose.md
- title: kubectl get
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_get.md
- title: kubectl label
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_label.md
- title: kubectl logs
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_logs.md
- title: kubectl patch
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_patch.md
- title: kubectl port-forward
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_port-forward.md
- title: kubectl proxy
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_proxy.md
- title: kubectl replace
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_replace.md
- title: kubectl rolling-update
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_rolling-update.md
- title: kubectl run
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_run.md
- title: kubectl scale
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_scale.md
- title: kubectl stop
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_stop.md
- title: kubectl version
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_version.md
- title: JSONpath
path: /v1.1/docs/user-guide/jsonpath/
@@ -26,7 +99,7 @@ toc:
- title: kube-apiserver
section:
- title: Overview
path: /v1.1/docs/admin/kube-apiserver/
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-apiserver.md
- title: Authorization Plugins
path: /v1.1/docs/admin/authorization/
- title: Authentication
@@ -39,13 +112,13 @@ toc:
path: /v1.1/docs/admin/service-accounts-admin/
- title: kub-scheduler
path: /v1.1/docs/admin/kube-scheduler/
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-scheduler.md
- title: kubelet
path: /v1.1/docs/admin/kubelet/
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kubelet.md
- title: kube-proxy
path: /v1.1/docs/admin/kube-proxy/
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-proxy.md
- title: etcd
path: /v1.1/docs/admin/etcd/
@@ -56,8 +129,6 @@ toc:
path: /v1.1/docs/user-guide/container-environment/
- title: Images
path: /v1.1/docs/user-guide/images/
- title: Downward API
path: /v1.1/docs/user-guide/downward-api/
- title: Pods
path: /v1.1/docs/user-guide/pods/
- title: Labels and Selectors
@@ -96,14 +167,14 @@ toc:
- title: Kubernetes Design Docs
section:
- title: Kubernetes Architecture
path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/architecture.md
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md
- title: Kubernetes Design Overview
path: https://github.com/kubernetes/kubernetes/blob/master/docs/design/
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/
- title: Security in Kubernetes
path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/security.md
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security.md
- title: Kubernetes Identity and Access Management
path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/access.md
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/access.md
- title: Security Contexts
path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/security_context.md
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security_context.md
- title: Kubernetes OpenVSwitch GRE/VxLAN networking
path: /v1.1/docs/admin/ovs-networking/
v1.1/api-ref.md
-16
View File
@@ -1,16 +0,0 @@
---
title: "Kubernetes API Reference"
---
Use these reference documents to learn how to interact with Kubernetes through the REST API.
You can also view details about the *Extensions API*. For more about extensions, see [API versioning](/{{page.version}}/docs/api).
<p>Table of Contents:</p>
<ul id="toclist"></ul>
<script>
$(function() {
$('#toclist').load( location.pathname + " #gentocapiref li" );
});
</script>
v1.1/docs/admin/admission-controllers.md
+2 -2
View File
@@ -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/tree/master/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/release-1.1/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/tree/master/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/release-1.1/docs/design/admission_control_limit_range.md) and the [example of Limit Range](limitrange/) for more details.
### InitialResources (experimental)
v1.1/docs/admin/limitrange/index.md
+1 -1
View File
@@ -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/tree/master/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/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)
## Step 0: Prerequisites
v1.1/docs/admin/namespaces.md
+5 -5
View File
@@ -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/tree/master/docs/design/admission_control_limit_range.md)
See [Admission control: Limit Range](https://github.com/kubernetes/kubernetes/blob/release-1.1/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/tree/master/docs/design/namespaces.md#phases) for more details.
See the [design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/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/tree/master/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/release-1.1/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/tree/master/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace)
can be found in the [namespaces design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/namespaces.md)
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)
v1.1/docs/admin/networking.md
+1 -1
View File
@@ -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/tree/master/docs/design/networking.md).
document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/networking.md).
v1.1/docs/admin/node.md
+1 -1
View File
@@ -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/tree/master/docs/design/architecture.md#the-kubernetes-node) section in the
[The Kubernetes Node](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md#the-kubernetes-node) section in the
architecture design doc for more details.
## Node Status
v1.1/docs/admin/resource-quota.md
+1 -1
View File
@@ -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/tree/master/docs/design/admission_control_resource_quota.md) for more information.
See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_resource_quota.md) for more information.
v1.1/docs/admin/resourcequota/index.md
+1 -1
View File
@@ -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/tree/master/docs/design/admission_control_resource_quota.md) for more information.
See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control_resource_quota.md) for more information.
This example assumes you have a functional Kubernetes setup.
v1.1/docs/api.md
+2 -2
View File
@@ -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/tree/master/docs/design/versioning.md) describes the relationship between API versioning and
versioning proposal](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/versioning.md) describes the relationship between API versioning and
software versioning.
@@ -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/tree/master/docs/design/extending-api.md), and to avoid naming collisions.
create their own API groups](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/extending-api.md), and to avoid naming collisions.
## Enabling resources in the extensions group
v1.1/docs/devel/api-conventions.md
+2 -2
View File
@@ -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/tree/master/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/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.
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/tree/master/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/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.
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.
v1.1/docs/devel/api_changes.md
+1 -1
View File
@@ -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/tree/master/docs/design/versioning.md).
and eventually removed wholesale, as described in the [versioning document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/versioning.md).
Document incompatible changes across API versions under the [conversion tips](../api).
If your change is going to be backward incompatible or might be a breaking change for API
v1.1/docs/devel/index.md
+1 -1
View File
@@ -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/tree/master/docs/design/admission_control.md))
* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/admission_control.md))
## Building releases
v1.1/docs/index.md
+1 -1
View File
@@ -17,7 +17,7 @@ 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/tree/master/docs/design/)
* An overview of the [Design of Kubernetes](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/)
* There are example files and walkthroughs in the [examples](https://github.com/kubernetes/kubernetes/tree/master/examples)
folder.
v1.1/docs/user-guide/compute-resources.md
+1 -1
View File
@@ -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).
v1.1/docs/user-guide/configuring-containers.md
+1 -1
View File
@@ -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"]
v1.1/docs/user-guide/environment-guide/index.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/horizontal-pod-autoscaler.md
+4 -4
View File
@@ -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/).
v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md
+1 -1
View File
@@ -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:
v1.1/docs/user-guide/identifiers.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/managing-deployments.md
+2 -2
View File
@@ -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
v1.1/docs/user-guide/node-selection/index.md
+1 -1
View File
@@ -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.
v1.1/docs/user-guide/persistent-volumes.md
+2 -2
View File
@@ -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
v1.1/docs/user-guide/persistent-volumes/index.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/production-pods.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/secrets.md
+2 -2
View File
@@ -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.
v1.1/docs/user-guide/secrets/index.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/security-context.md
+1 -1
View File
@@ -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.
v1.1/docs/user-guide/update-demo/index.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/walkthrough/index.md
+1 -1
View File
@@ -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
v1.1/docs/user-guide/working-with-resources.md
+1 -1
View File
@@ -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).
v1.1/docs/whatisk8s.md
+2 -2
View File
@@ -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](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/tree/master/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](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).
This [design](https://github.com/kubernetes/kubernetes/tree/master/docs/design/principles.md) has enabled a number of other systems to build atop Kubernetes.
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.
#### Kubernetes is not: