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

Merge branch 'master' into logging-sidecar-refactoring-2

Browse Source
This commit is contained in:
Steve Perry
2017-01-25 09:07:11 -08:00
committed by GitHub
parent a2deedd3f5 52c2292dda
commit 5be3af942c
41 changed files with 477 additions and 162 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user-guide/compute-resources.md
+5 -6
View File
@@ -122,17 +122,16 @@ runner (Docker or rkt).
When using Docker:
- The `spec.containers[].resources.requests.cpu` is converted to its core value (potentially fractional),
and multiplied by 1024, and used as the value of the [`--cpu-shares`](
https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag to the `docker run`
command.
and multiplied by 1024, and used as the value of the [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint)
flag to the `docker run` command.
- The `spec.containers[].resources.limits.cpu` is converted to its millicore value,
multiplied by 100000, and then divided by 1000, and used as the value of the [`--cpu-quota`](
https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag to the `docker run`
https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) flag to the `docker run`
command. The [`--cpu-period`] flag is set to 100000 which represents the default 100ms period
for measuring quota usage. The kubelet enforces cpu limits if it was started with the
[`--cpu-cfs-quota`] flag set to true. As of version 1.2, this flag will now default to true.
- The `spec.containers[].resources.limits.memory` is converted to an integer, and used as the value
of the [`--memory`](https://docs.docker.com/reference/run/#runtime-constraints-on-resources) flag
of the [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) flag
to the `docker run` command.
**TODO: document behavior for rkt**
@@ -362,7 +361,7 @@ such as [EmptyDir volumes](/docs/user-guide/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/{{page.githubbranch}}/docs/design/resources.md#resource-types).
resource, and a framework for adding custom [resource types](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/resources.md).
Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168).
docs/user-guide/configmap/index.md
+64 -3
View File
@@ -291,6 +291,34 @@ SPECIAL_LEVEL_KEY=very
SPECIAL_TYPE_KEY=charm
```
#### Optional ConfigMap in environment variables
There might be situations where environment variables are not
always required. These environment variables can be marked as optional in a
pod like so:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: a-config
key: akey
optional: true
restartPolicy: Never
```
When this pod is run, the output will be empty.
### Use-Case: Set command-line arguments with ConfigMap
ConfigMaps can also be used to set the value of the command or arguments in a container. This is
@@ -422,6 +450,38 @@ very
You can project keys to specific paths and specific permissions on a per-file
basis. The [Secrets](/docs/user-guide/secrets/) user guide explains the syntax.
#### Optional ConfigMap via volume plugin
Volumes and files provided by a ConfigMap can be also be marked as optional.
The ConfigMap or the key specified does not have to exist. The mount path for
such items will always be created.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "ls /etc/config" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: no-config
optional: true
restartPolicy: Never
```
When this pod is run, the output will be:
```shell
```
## Real World Example: Configuring Redis
Let's take a look at a real-world example: configuring redis using ConfigMap. Say we want to inject
@@ -517,9 +577,10 @@ $ kubectl exec -it redis redis-cli
## Restrictions
ConfigMaps must be created before they are consumed in pods. Controllers may be written to tolerate
missing configuration data; consult individual components configured via ConfigMap on a case-by-case
basis.
ConfigMaps must be created before they are consumed in pods unless they are
marked as optional. Controllers may be written to tolerate missing
configuration data; consult individual components configured via ConfigMap on
a case-by-case basis.
ConfigMaps reside in a namespace. They can only be referenced by pods in the same namespace.
docs/user-guide/environment-guide/index.md
+1 -1
View File
@@ -79,7 +79,7 @@ First the frontend pod's information is printed. The pod name and
[namespace](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md) are retrieved from the
[Downward API](/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
an environment variable set in the [pod
definition](/docs/user-guide/environment-guide/show-rc.yaml). Then, the dynamic Kubernetes environment
definition](https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/user-guide/environment-guide/show-rc.yaml). Then, the dynamic Kubernetes environment
variables are scanned and printed. These are used to find the backend
service, named `backend-srv`. Finally, the frontend pod queries the
backend service and prints the information returned. Again the backend
docs/user-guide/federation/index.md
+3 -1
View File
@@ -37,13 +37,15 @@ Once we have the control plane setup, we can start creating federation API
resources.
The following guides explain some of the resources in detail:
* [ConfigMap](/docs/user-guide/federation/configmap/)
* [DaemonSets](/docs/user-guide/federation/daemonsets/)
* [Deployment](/docs/user-guide/federation/deployment/)
* [Events](/docs/user-guide/federation/events/)
* [Ingress](/docs/user-guide/federation/federated-ingress/)
* [Namespaces](/docs/user-guide/federation/namespaces/)
* [ReplicaSets](/docs/user-guide/federation/replicasets/)
* [Secrets](/docs/user-guide/federation/secrets/)
* [Services](/docs/user-guide/federation/federated-services/)
<!-- TODO: Add more guides here -->
[API reference docs](/docs/federation/api-reference/) lists all the
resources supported by federation apiserver.
docs/user-guide/garbage-collection.md
+1 -1
View File
@@ -27,7 +27,7 @@ You can set up owner-dependent relationships among other objects by manually set
When deleting an object, you can request the GC to ***asynchronously*** delete its dependents by ***explicitly*** specifying `deleteOptions.orphanDependents=false` in the deletion request that you send to the API server. A 200 OK response from the API server indicates the owner is deleted.
In Kubernetes version 1.5, synchronous garbage collection is under active development. See the [tracking [issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details.
In Kubernetes version 1.5, synchronous garbage collection is under active development. See the tracking [issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details.
If you specify `deleteOptions.orphanDependents=true`, or leave it blank, then the GC will first reset the `ownerReferences` in the dependents, then delete the owner. Note that the deletion of the owner object is asynchronous, that is, a 200 OK response will be sent by the API server before the owner object gets deleted.
docs/user-guide/jobs/work-queue-2/index.md
+1 -1
View File
@@ -31,7 +31,7 @@ Here is an overview of the steps in this example:
## Starting Redis
For this example, for simplicitly, we will start a single instance of Redis.
See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/redis/README.md) for an example
See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook) for an example
of deploying Redis scalably and redundantly.
Start a temporary Pod running Redis and a service so we can find it.
docs/user-guide/kubectl-cheatsheet.md
+1 -1
View File
@@ -200,7 +200,7 @@ $ kubectl logs my-pod # dump pod logs (stdout)
$ kubectl logs -f my-pod # stream pod logs (stdout)
$ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
$ kubectl attach my-pod -i # Attach to Running Container
$ kubectl port-forward my-pod 5000 6000 # Forward port 6000 of Pod to your to 5000 on your local machine
$ kubectl port-forward my-pod 5000:6000 # Forward port 6000 of Pod to your to 5000 on your local machine
$ kubectl port-forward my-svc 6000 # Forward port to service
$ kubectl exec my-pod -- ls / # Run command in existing pod (1 container case)
$ kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)
docs/user-guide/petset.md
+2 -2
View File
@@ -42,7 +42,7 @@ This doc assumes familiarity with the following Kubernetes concepts:
* [Cluster DNS](/docs/admin/dns/)
* [Headless Services](/docs/user-guide/services/#headless-services)
* [Persistent Volumes](/docs/user-guide/volumes/)
* [Persistent Volume Provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md)
* [Persistent Volume Provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/persistent-volume-provisioning/README.md)
You need a working Kubernetes cluster at version >= 1.3, with a healthy DNS [cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md) at version >= 15. You cannot use PetSet on a hosted Kubernetes provider that has disabled `alpha` resources.
@@ -98,7 +98,7 @@ Before you start deploying applications as PetSets, there are a few limitations
* PetSet is an *alpha* resource, not available in any Kubernetes release prior to 1.3.
* As with all alpha/beta resources, it can be disabled through the `--runtime-config` option passed to the apiserver, and in fact most likely will be disabled on hosted offerings of Kubernetes.
* The only updatable field on a PetSet is `replicas`
* The storage for a given pet must either be provisioned by a [persistent volume provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that persistent volume provisioning is also currently in alpha.
* The storage for a given pet must either be provisioned by a [persistent volume provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that persistent volume provisioning is also currently in alpha.
* Deleting and/or scaling a PetSet down will *not* delete the volumes associated with the PetSet. This is done to ensure safety first, your data is more valuable than an auto purge of all related PetSet resources. **Deleting the Persistent Volume Claims will result in a deletion of the associated volumes**.
* All PetSets currently require a "governing service", or a Service responsible for the network identity of the pets. The user is responsible for this Service.
* Updating an existing PetSet is currently a manual process, meaning you either need to deploy a new PetSet with the new image version, or orphan Pets one by one, update their image, and join them back to the cluster.
docs/user-guide/pods/init-container.md
+2 -2
View File
@@ -20,7 +20,7 @@ the next one is started. If the init container fails, Kubernetes will restart
the pod until the init container succeeds. If a pod is marked as `RestartNever`,
the pod will fail if the init container fails.
You specify a container as an init container by adding an annotation
You specify a container as an init container by adding an annotation.
The annotation key is `pod.beta.kubernetes.io/init-containers`. The annotation
value is a JSON array of [objects of type `v1.Container`
](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_container)
@@ -155,7 +155,7 @@ reasons:
* An init container image is changed by a user updating the Pod Spec.
* App container image changes only restart the app container.
* The pod infrastructure container is restarted
* The pod infrastructure container is restarted.
* This is uncommon and would have to be done by someone with root access to nodes.
* All containers in a pod are terminated, requiring a restart (RestartPolicyAlways) AND the record of init container completion has been lost due to garbage collection.
docs/user-guide/pods/pod-spec-common.json
+1 -1
View File
@@ -24,7 +24,7 @@
}
],
"resources": {
"cpu": ""
"cpu": "",
"memory": ""
}
}
docs/user-guide/secrets/index.md
+67 -7
View File
@@ -372,6 +372,41 @@ files.
When a secret being already consumed in a volume is updated, projected keys are eventually updated as well.
The update time depends on the kubelet syncing period.
#### Optional Secrets as Files from a Pod
Volumes and files provided by a Secret can be also be marked as optional.
The Secret or the key within a Secret does not have to exist. The mount path for
such items will always be created.
```json
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "mypod",
"namespace": "myns"
},
"spec": {
"containers": [{
"name": "mypod",
"image": "redis",
"volumeMounts": [{
"name": "foo",
"mountPath": "/etc/foo"
}]
}],
"volumes": [{
"name": "foo",
"secret": {
"secretName": "mysecret",
"defaultMode": 256,
"optional": true
}
}]
}
}
```
#### Using Secrets as Environment Variables
To use a secret in an environment variable in a pod:
@@ -418,6 +453,30 @@ $ echo $SECRET_PASSWORD
1f2d1e2e67df
```
#### Optional Secrets from Environment Variables
You may not want to require all your secrets to exist. They can be marked as
optional as shown in the pod:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: optional-secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: OPTIONAL_SECRET
valueFrom:
secretKeyRef:
name: mysecret
key: username
optional: true
restartPolicy: Never
```
#### Using imagePullSecrets
An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry
@@ -449,7 +508,8 @@ can be automatically attached to pods based on their service account.
Secret volume sources are validated to ensure that the specified object
reference actually points to an object of type `Secret`. Therefore, a secret
needs to be created before any pods that depend on it.
needs to be created before any pods that depend on it, unless it is marked as
optional.
Secret API objects reside in a namespace. They can only be referenced by pods
in that same namespace.
@@ -469,12 +529,12 @@ not common ways to create pods.)
When a pod is created via the API, there is no check whether a referenced
secret exists. Once a pod is scheduled, the kubelet will try to fetch the
secret value. If the secret cannot be fetched because it does not exist or
because of a temporary lack of connection to the API server, kubelet will
periodically retry. It will report an event about the pod explaining the
reason it is not started yet. Once the secret is fetched, the kubelet will
create and mount a volume containing it. None of the pod's containers will
start until all the pod's volumes are mounted.
secret value. If a required secret cannot be fetched because it does not
exist or because of a temporary lack of connection to the API server, the
kubelet will periodically retry. It will report an event about the pod
explaining the reason it is not started yet. Once the secret is fetched, the
kubelet will create and mount a volume containing it. None of the pod's
containers will start until all the pod's volumes are mounted.
## Use cases
docs/user-guide/sharing-clusters.md
+1 -2
View File
@@ -105,8 +105,7 @@ and/or run `kubectl config -h`.
1. `--kubeconfig=/path/to/.kube/config` command line flag
2. `KUBECONFIG=/path/to/.kube/config` env variable
3. `$PWD/.kube/config`
4. `$HOME/.kube/config`
3. `$HOME/.kube/config`
If you create clusters A, B on host1, and clusters C, D on host2, you can
make all four clusters available on both hosts by running
docs/user-guide/thirdpartyresources.md
+3
View File
@@ -9,6 +9,9 @@ title: Third Party Resources
## What is ThirdPartyResource?
**WARNING: ThirdPartyResources are not yet considered stable, and the API and/or storage could change before GA.
Development and outstanding issues are tracked at [https://github.com/kubernetes/features/issues/95](https://github.com/kubernetes/features/issues/95).**
Kubernetes comes with many built-in API objects. However, there are often times when you might need to extend Kubernetes with their own API objects in order to do custom automation.
`ThirdPartyResource` objects are a way to extend the Kubernetes API with a new API object type. The new API object type will be given an API endpoint URL and support CRUD operations, and watch API. You can then create custom objects using this API endpoint. You can think of `ThirdPartyResources` as being much like the schema for a database table. Once you have created the table, you can then start storing rows in the table. Once created, `ThirdPartyResources` can act as the data model behind custom controllers or automation programs.
docs/user-guide/ui.md
+3 -3
View File
@@ -42,9 +42,9 @@ The UI can _only_ be accessed from the machine where the command is executed. Se
You may access the UI directly via the Kubernetes master apiserver. Open a browser and navigate to `https://<kubernetes-master>/ui`, where `<kubernetes-master>` is IP address or domain name of the Kubernetes
master.
Please note, this works only if the apiserver is set up to allow authentication with username and password. This is not currently the case with the some setup tools (e.g., `kubeadm`). Refer to the [authentication admin documentation](/docs/admin/authentication/) for information on how to configure authentication manually.
Please note, this works only if the apiserver is set up to allow authentication with username and password. This is not currently the case with some setup tools (e.g., `kubeadm`). Refer to the [authentication admin documentation](/docs/admin/authentication/) for information on how to configure authentication manually.
If the username and password is configured but unknown to you, then use `kubectl config view` to find it.
If the username and password are configured but unknown to you, then use `kubectl config view` to find it.
## Welcome view
@@ -66,7 +66,7 @@ The deploy wizard expects that you provide the following information:
- **App name** (mandatory): Name for your application. A [label](/docs/user-guide/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
The application name must be unique within the selected Kubernetes [namespace](/docs/admin/namespaces/). It must start and end with a lowercase character, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
The application name must be unique within the selected Kubernetes [namespace](/docs/admin/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
- **Container image** (mandatory): The URL of a public Docker [container image](/docs/user-guide/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
docs/user-guide/update-demo/index.md
+7 -7
View File
@@ -1,9 +1,9 @@
---
assignees:
- mikedanese
title: Rolling Update Demo
---
---
assignees:
- mikedanese
title: Rolling Update Demo
---
This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/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.
The files for this example are viewable in [our docs repo
@@ -67,7 +67,7 @@ The rolling-update command in kubectl will do 2 things:
Watch the [demo website](http://localhost:8001/static/index.html), it will update one pod every 10 seconds until all of the pods have the new image.
Note that the new replication controller definition does not include the replica count, so the current replica count of the old replication controller is preserved.
But if the replica count had been specified, the final replica count of the new replication controller will be equal this number.
But if the replica count had been specified, the final replica count of the new replication controller will be equal to this number.
### Step Five: Bring down the pods