Merge branch 'master' into release-1.8
This commit is contained in:
@@ -160,8 +160,6 @@ toc:
|
||||
- docs/tasks/administer-cluster/configure-multiple-schedulers.md
|
||||
- docs/tasks/administer-cluster/ip-masq-agent.md
|
||||
- docs/tasks/administer-cluster/dns-custom-nameservers.md
|
||||
- title: Change Cluster Size
|
||||
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
|
||||
|
||||
- title: Federation - Run an App on Multiple Clusters
|
||||
section:
|
||||
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: 配置命名空间下pod总数
|
||||
---
|
||||
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
本文主要描述如何配置一个命名空间下可运行的pod总数。资源配额详细信息可查看:[资源配额](/docs/api-reference/v1.7/#resourcequota-v1-core)
|
||||
。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## 创建一个命名空间
|
||||
|
||||
首先创建一个命名空间,这样可以将本次操作中创建的资源与集群其他资源隔离开来。
|
||||
|
||||
```shell
|
||||
kubectl create namespace quota-pod-example
|
||||
```
|
||||
|
||||
## 创建资源配额
|
||||
|
||||
下面是一个资源配额的配置文件:
|
||||
|
||||
{% include code.html language="yaml" file="quota-pod.yaml" ghlink="/docs/tasks/administer-cluster/quota-pod.yaml" %}
|
||||
|
||||
创建这个资源配额:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/administer-cluster/quota-pod.yaml --namespace=quota-pod-example
|
||||
```
|
||||
|
||||
查看资源配额的详细信息:
|
||||
|
||||
```shell
|
||||
kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
从输出的信息我们可以看到,该命名空间下pod的配额是2个,目前创建的pods数为0,配额使用率为0。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
hard:
|
||||
pods: "2"
|
||||
status:
|
||||
hard:
|
||||
pods: "2"
|
||||
used:
|
||||
pods: "0"
|
||||
```
|
||||
|
||||
下面是一个Deployment的配置文件:
|
||||
|
||||
{% include code.html language="yaml" file="quota-pod-deployment.yaml" ghlink="/docs/tasks/administer-cluster/quota-pod-deployment.yaml" %}
|
||||
|
||||
在配置文件中, `replicas: 3` 告诉kubernetes尝试创建三个pods,且运行相同的应用。
|
||||
|
||||
创建这个Deployment:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/administer-cluster/quota-pod-deployment.yaml --namespace=quota-pod-example
|
||||
```
|
||||
|
||||
查看Deployment的详细信息:
|
||||
|
||||
```shell
|
||||
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
从输出的信息我们可以看到,尽管尝试创建三个pod,但是由于配额的限制,只有两个pod能被成功创建。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
...
|
||||
replicas: 3
|
||||
...
|
||||
status:
|
||||
availableReplicas: 2
|
||||
...
|
||||
lastUpdateTime: 2017-07-07T20:57:05Z
|
||||
message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
|
||||
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
|
||||
```
|
||||
|
||||
## 清理
|
||||
|
||||
删除命名空间:
|
||||
|
||||
```shell
|
||||
kubectl delete namespace quota-pod-example
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
### 对于集群管理
|
||||
|
||||
* [配置命名空间下,内存默认的request值和limit值](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [配置命名空间下,CPU默认的request值和limit值](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [配置命名空间下,内存的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [配置命名空间下,CPU的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [配置命名空间下,内存和CPU的配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [配置命名空间下,API对象的配额](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 对于应用开发
|
||||
|
||||
* [给容器和pod分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [给容器和pod分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [配置pod的QoS](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
title: 给容器分配非透明整型资源
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
本页展示了如何给容器分配非透明整型资源。
|
||||
|
||||
{% include feature-state-alpha.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
在做这个练习之前,请在[给节点配置非透明整型资源](/docs/tasks/administer-cluster/opaque-integer-resource-node/)文档中进行练习,
|
||||
该文档介绍了在一个节点上配置dongle资源。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## 给Pod分配非透明整型资源
|
||||
|
||||
为了请求一个非透明整型资源,需要在容器配置文件中包含`resources:requests`字段。
|
||||
非透明整型资源类型前缀是`pod.alpha.kubernetes.io/opaque-int-resource-`。
|
||||
|
||||
下面是含有一个容器的Pod的配置文件:
|
||||
|
||||
{% include code.html language="yaml" file="oir-pod.yaml" ghlink="/cn/docs/tasks/configure-pod-container/oir-pod.yaml" %}
|
||||
|
||||
在配置文件中,可以看到容器请求了3个dongles资源。
|
||||
|
||||
创建Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/oir-pod.yaml
|
||||
```
|
||||
|
||||
验证Pod是否正在运行:
|
||||
|
||||
```shell
|
||||
kubectl get pod oir-demo
|
||||
```
|
||||
|
||||
查询Pod的状态:
|
||||
|
||||
```shell
|
||||
kubectl describe pod oir-demo
|
||||
```
|
||||
|
||||
输出显示了dongle请求:
|
||||
|
||||
```yaml
|
||||
Requests:
|
||||
pod.alpha.kubernetes.io/opaque-int-resource-dongle: 3
|
||||
```
|
||||
|
||||
## 尝试创建第二个Pod
|
||||
|
||||
下面是含有一个容器的Pod的配置文件。该容器请求了两个dongles资源。
|
||||
|
||||
{% include code.html language="yaml" file="oir-pod-2.yaml" ghlink="/docs/tasks/configure-pod-container/oir-pod-2.yaml" %}
|
||||
|
||||
Kubernetes无法再满足两个dongles的请求,因为第一个Pod已经使用了四个可用dongles中的三个。
|
||||
|
||||
尝试创建Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/oir-pod-2.yaml
|
||||
```
|
||||
|
||||
查询Pod的状态
|
||||
|
||||
```shell
|
||||
kubectl describe pod oir-demo-2
|
||||
```
|
||||
|
||||
输出显示该Pod无法被调度,因为没有节点有两个可用的dongles资源:
|
||||
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status
|
||||
PodScheduled False
|
||||
...
|
||||
Events:
|
||||
...
|
||||
... Warning FailedScheduling pod (oir-demo-2) failed to fit in any node
|
||||
fit failure summary on nodes : Insufficient pod.alpha.kubernetes.io/opaque-int-resource-dongle (1)
|
||||
```
|
||||
|
||||
查看Pod的状态:
|
||||
|
||||
```shell
|
||||
kubectl get pod oir-demo-2
|
||||
```
|
||||
|
||||
输出显示Pod已创建,但是没有被调度并运行在节点上。
|
||||
它的状态为Pending:
|
||||
|
||||
```yaml
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
oir-demo-2 0/1 Pending 0 6m
|
||||
```
|
||||
|
||||
## 删除
|
||||
|
||||
删除本练习中创建的Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod oir-demo
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
### 对于应用开发者
|
||||
|
||||
* [分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
* [分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
### 对于集群管理员
|
||||
|
||||
* [给节点配置非透明整型资源](/docs/tasks/administer-cluster/opaque-integer-resource-node/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: 调试StatefulSet
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
此任务展示如何调试StatefulSet。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
|
||||
* 你需要有一个Kubernetes集群,通过必要的配置使kubectl命令行工具与您的集群进行通信。
|
||||
* 你应该有一个运行中的StatefulSet,以便用于调试。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## 调试StatefulSet
|
||||
|
||||
由于StatefulSet在创建时设置了`app=myapp`标签,列出仅属于该StatefulSet的所有pod时,可以使用以下命令:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=myapp
|
||||
```
|
||||
|
||||
如果您发现列出的任何Pods长时间处于`Unknown` 或`Terminating`状态,关于如何处理它们的说明任务,请参阅[删除 StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/)。您可以参考[调试 Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods)指南来调试StatefulSet中的各个Pod。
|
||||
|
||||
StatefulSets提供调试机制,可以使用注解来暂停所有控制器在Pod上的操作。在任何StatefulSet Pod上设置`pod.alpha.kubernetes.io/initialized`注解为`"false"`将*暂停* StatefulSet的所有操作。暂停时,StatefulSet将不执行任何伸缩操作。一旦调试钩子设置完成后,就可以在StatefulSet pod的容器内执行命令,而不会造成伸缩操作的干扰。您可以通过执行以下命令将注解设置为`"false"`:
|
||||
|
||||
```shell
|
||||
kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --overwrite
|
||||
```
|
||||
|
||||
当注解设置为`"false"`时,StatefulSet在其Pods变得不健康或不可用时将不会响应。StatefulSet不会创建副本Pod直到每个Pod上删除注解或将注解设置为`"true"`。
|
||||
|
||||
### 逐步初始化
|
||||
|
||||
创建StatefulSet之前,您可以通过使用和上文相同的注解,即将yaml文件中`.spec.template.metadata.annotations`里的`pod.alpha.kubernetes.io/initialized`字段设置为`"false"`,对竞态条件的StatefulSet进行调试。
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1beta1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
serviceName: "my-app"
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: my-app
|
||||
annotations:
|
||||
pod.alpha.kubernetes.io/initialized: "false"
|
||||
...
|
||||
...
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
设置注解后,如果创建了StatefulSet,您可以等待每个Pod来验证它是否正确初始化。StatefulSet将不会创建任何后续的Pods,直到在已经创建的每个Pod上将调试注解设置为`"true"` (或删除)。 您可以通过执行以下命令将注解设置为`"true"`:
|
||||
|
||||
```shell
|
||||
kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="true" --overwrite
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
点击链接[调试init-container](/docs/tasks/troubleshoot/debug-init-containers/),了解更多信息。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: 为容器设置环境变量
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
本页将展示如何为kubernetes Pod下的容器设置环境变量。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## 为容器设置一个环境变量
|
||||
|
||||
创建Pod时,可以为其下的容器设置环境变量。通过配置文件的`env`或者`envFrom` 字段来设置环境变量。
|
||||
|
||||
本示例中,将创建一个只包含单个容器的Pod。Pod的配置文件中设置环境变量的名称为`DEMO_GREETING`,
|
||||
其值为`"Hello from the environment"`。下面是Pod的配置文件内容:
|
||||
|
||||
{% include code.html language="yaml" file="envars.yaml" ghlink="/docs/tasks/inject-data-application/envars.yaml" %}
|
||||
|
||||
1. 基于YAML文件创建一个Pod:
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/envars.yaml
|
||||
|
||||
1. 获取一下当前正在运行的Pods信息:
|
||||
|
||||
kubectl get pods -l purpose=demonstrate-envars
|
||||
|
||||
查询结果应为:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
|
||||
1. 进入该Pod下的容器并打开一个命令终端:
|
||||
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
|
||||
1. 在命令终端中通过执行`printenv`打印出环境变量。
|
||||
|
||||
root@envar-demo:/# printenv
|
||||
|
||||
打印结果应为:
|
||||
|
||||
NODE_VERSION=4.4.2
|
||||
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
|
||||
HOSTNAME=envar-demo
|
||||
...
|
||||
DEMO_GREETING=Hello from the environment
|
||||
|
||||
1. 通过键入`exit`退出命令终端。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* 有关环境变量的更多信息,请参阅[这里](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/)。
|
||||
* 有关如何通过环境变量来使用Secret,请参阅[这里](/docs/user-guide/secrets/#using-secrets-as-environment-variables)。
|
||||
* 关于[EnvVarSource](/docs/api-reference/{{page.version}}/#envvarsource-v1-core)资源的信息。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: envar-demo
|
||||
labels:
|
||||
purpose: demonstrate-envars
|
||||
spec:
|
||||
containers:
|
||||
- name: envar-demo-container
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
env:
|
||||
- name: DEMO_GREETING
|
||||
value: "Hello from the environment"
|
||||
@@ -0,0 +1,225 @@
|
||||
---
|
||||
approvers:
|
||||
- janetkuo
|
||||
title: 基于Replication Controller执行滚动升级
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## 概述
|
||||
|
||||
**注**: 创建副本应用的首选方法是使用[Deployment](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps),Deployment使用[ReplicaSet](/docs/api-reference/{{page.version}}/#replicaset-v1beta1-extensions)来进行副本控制。
|
||||
更多信息, 查看[使用Deployment运行一个无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
|
||||
|
||||
为了在更新服务的同时不中断业务, `kubectl` 支持['滚动更新'](/docs/user-guide/kubectl/v1.6/#rolling-update),它一次更新一个pod,而不是同时停止整个服务。 有关更多信息,请参阅 [滚动更新设计文档](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) 和 [滚动更新示例](/docs/tasks/run-application/rolling-update-replication-controller/)。
|
||||
|
||||
请注意, `kubectl rolling-update` 仅支持Replication Controllers。 但是,如果使用Replication Controllers部署应用,请考虑将其切换到[Deployments](/docs/concepts/workloads/controllers/deployment/). Deployment是一种被推荐使用的更高级别的控制器,它可以对应用进行声明性的自动滚动更新。 如果您仍然希望保留您的Replication Controllers并使用 `kubectl rolling-update`进行滚动更新, 请继续往下阅读:
|
||||
|
||||
滚动更新可以对replication controller所管理的Pod的配置进行变更,变更可以通过一个新的配置文件来进行,或者,如果只更新镜像,则可以直接指定新的容器镜像。
|
||||
|
||||
滚动更新的工作流程:
|
||||
|
||||
1. 通过新的配置创建一个replication controller
|
||||
2. 在新的控制器上增加副本数,在旧的上面减少副本数,直到副本数达到期望值
|
||||
3. 删除之前的replication controller
|
||||
|
||||
使用`kubectl rolling-update`命令来进行滚动更新:
|
||||
|
||||
$ kubectl rolling-update NAME \
|
||||
([NEW_NAME] --image=IMAGE | -f FILE)
|
||||
|
||||
## 通过配置文件更新
|
||||
|
||||
通过配置文件来进行滚动更新,需要在`kubectl rolling-update`命令后面带上新的配置文件:
|
||||
|
||||
$ kubectl rolling-update NAME -f FILE
|
||||
|
||||
这个配置文件必须满足以下条件:
|
||||
|
||||
* 指定不同的`metadata.name`值
|
||||
|
||||
* 至少要修改`spec.selector`中的一个标签值
|
||||
|
||||
* `metadata.namespace`字段必须相同
|
||||
|
||||
Replication Controllers的配置文件详细介绍见[创建Replication Controllers](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
|
||||
|
||||
### 示例
|
||||
|
||||
// 通过新的配置文件frontend-v2.json来更新frontend-v1的pods
|
||||
$ kubectl rolling-update frontend-v1 -f frontend-v2.json
|
||||
|
||||
// 将frontend-v2.json数据传到标准输入来更新frontend-v1的pods
|
||||
$ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
|
||||
|
||||
## 更新容器镜像
|
||||
|
||||
仅更新容器镜像的话,可通过如下命令,该命令可以指定一个新的控制器名称(可选),通过`--image`参数来指定新的镜像名称和标签。
|
||||
|
||||
$ kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
|
||||
|
||||
`--image`参数仅支持单容器pod,多容器pod使用`--image`参数会返回错误。
|
||||
|
||||
如果没有指定 `NEW_NAME` ,新的replication controller创建后会使用一个临时名称,当更新完成,旧的controller被删除后,新的controller名称会被更新成旧的controller名称。
|
||||
|
||||
如果`IMAGE:TAG` 和当前值相同,更新就会失败。 因此,我们建议使用版本号来作为标签,而不是使用 `:latest`。从一个 `image:latest`镜像升级到一个新的 `image:latest` 镜像将会失败,即使这两个镜像不是相同的。
|
||||
所以,我们不建议使用 `:latest` 来作为标签,详细信息见[最佳配置实践](/docs/concepts/configuration/overview/#container-images) 。
|
||||
|
||||
### 示例
|
||||
|
||||
// 更新frontend-v1的pod到frontend-v2
|
||||
$ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
|
||||
|
||||
// 更新frontend的pods,不更改replication controller的名称
|
||||
$ kubectl rolling-update frontend --image=image:v2
|
||||
|
||||
## 必选和可选字段
|
||||
|
||||
必选字段:
|
||||
|
||||
* `NAME`: 需要进行滚动更新的replication controller名称
|
||||
|
||||
下面两个字段选其一:
|
||||
|
||||
* `-f FILE`: 新的replication controller的配置文件,JSON或者YAML格式均可。配置文件必须指定一个新的顶层`id`值,且至少包含一个现有`spec.selector`中的键值对。
|
||||
详细信息见[通过Replication Controller运行无状态应用](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/#replication-controller-configuration-file)。
|
||||
<br>
|
||||
<br>
|
||||
或者:
|
||||
<br>
|
||||
<br>
|
||||
* `--image IMAGE:TAG`: 更新后的镜像的名称和标签。必须和当前的image:tag不同。
|
||||
|
||||
可选字段包括:
|
||||
|
||||
* `NEW_NAME`: 只和 `--image` 一起使用,不和 `-f FILE` 一起使用。标识新的replication controller的名称。
|
||||
* `--poll-interval DURATION`: 在更新后轮询控制器状态的间隔时间。有效单位有 `ns` (纳秒),`us` 或 `µs`(微秒),`ms`(毫秒),`s`(秒),`m`(分钟)或 `h`(小时)。 单位可以自由组合(例如 `1m30s`)。 默认值为 `3s`。
|
||||
* `--timeout DURATION`: 退出更新之前,等待控制器更新一个pod的最大时间。默认是`5m0s`。有效单位如`--poll-interval`所述。
|
||||
* `--update-period DURATION`: 更新两个pod之间等待的时间,默认值是`1m0s`。有效单位如`--poll-interval`所述。
|
||||
|
||||
有关`kubectl rolling-update`命令的更多信息见[`kubectl`参考](/docs/user-guide/kubectl/v1.6/#rolling-update).
|
||||
|
||||
## 实践
|
||||
|
||||
现在你运行了一个1.7.9版本的nginx应用:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ReplicationController
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
replicas: 5
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
要更新到1.9.1版本,你可以使用[`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md)来指定一个新的镜像:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx --image=nginx:1.9.1
|
||||
Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
|
||||
```
|
||||
|
||||
在终端上打开另一个窗口 ,你可以看到`kubectl` 给每个pod都增加了一个值为配置文件哈希值的 `deployment` 标签,用来区分新旧pod:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l app=nginx -L deployment
|
||||
NAME READY STATUS RESTARTS AGE DEPLOYMENT
|
||||
my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z 1/1 Running 0 1m ccba8fbd8cc8160970f63f9a2696fc46
|
||||
my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh 1/1 Running 0 35s ccba8fbd8cc8160970f63f9a2696fc46
|
||||
my-nginx-divi2 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
|
||||
my-nginx-o0ef1 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
|
||||
my-nginx-q6all 1/1 Running 0 8m 2d1d7a8f682934a254002b56404b813e
|
||||
```
|
||||
|
||||
使用`kubectl rolling-update`可以实时看到更新的进度:
|
||||
|
||||
```
|
||||
Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 1
|
||||
Scaling my-nginx down to 2
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 2
|
||||
Scaling my-nginx down to 1
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 3
|
||||
Scaling my-nginx down to 0
|
||||
Update succeeded. Deleting old controller: my-nginx
|
||||
Renaming my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 to my-nginx
|
||||
replicationcontroller "my-nginx" rolling updated
|
||||
```
|
||||
|
||||
如果遇到问题,你可以中途停止滚动更新,并且使用 `--rollback` 来回滚到以前的版本:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx --rollback
|
||||
Setting "my-nginx" replicas to 1
|
||||
Continuing update with existing controller my-nginx.
|
||||
Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
|
||||
Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 down to 0
|
||||
Update succeeded. Deleting my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
|
||||
replicationcontroller "my-nginx" rolling updated
|
||||
```
|
||||
|
||||
这个例子说明容器的不变性是个巨大的优点。
|
||||
|
||||
如果你不仅仅是需要更新镜像,(例如,更新命令参数,环境变量等),你可以创建一个新的replication controller配置文件,包含一个新的名称和不同的标签值,例如:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ReplicationController
|
||||
metadata:
|
||||
name: my-nginx-v4
|
||||
spec:
|
||||
replicas: 5
|
||||
selector:
|
||||
app: nginx
|
||||
deployment: v4
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
deployment: v4
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.9.2
|
||||
args: ["nginx", "-T"]
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
然后使用它来进行更新:
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
|
||||
Created my-nginx-v4
|
||||
Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
|
||||
Scaling my-nginx-v4 up to 1
|
||||
Scaling my-nginx down to 3
|
||||
Scaling my-nginx-v4 up to 2
|
||||
Scaling my-nginx down to 2
|
||||
Scaling my-nginx-v4 up to 3
|
||||
Scaling my-nginx down to 1
|
||||
Scaling my-nginx-v4 up to 4
|
||||
Scaling my-nginx down to 0
|
||||
Scaling my-nginx-v4 up to 5
|
||||
Update succeeded. Deleting old controller: my-nginx
|
||||
replicationcontroller "my-nginx-v4" rolling updated
|
||||
```
|
||||
|
||||
## 故障分析
|
||||
|
||||
如果更新过程中,达到超时时长`timeout`后还没更新完成,则更新会失败。这时,一些pod会属于新的replication controller,一些会属于旧的。
|
||||
|
||||
如果更新失败,可以尝试使用同样的命令来继续更新过程。
|
||||
|
||||
在尝试更新之前如果需要回滚到之前的状态,可在之前的命令后面添加`--rollback=true`参数,这将回退所有的更改。
|
||||
@@ -7,7 +7,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://git.k8s.io/community/contributors/design-proposals/secrets.md) for more information.
|
||||
a docker image. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
@@ -118,7 +118,7 @@ data:
|
||||
```
|
||||
|
||||
The data field is a map. Its keys must match
|
||||
[`DNS_SUBDOMAIN`](https://git.k8s.io/community/contributors/design-proposals/identifiers.md), except that leading dots are also
|
||||
[`DNS_SUBDOMAIN`](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md), except that leading dots are also
|
||||
allowed. The values are arbitrary data, encoded using base64.
|
||||
|
||||
Create the secret using [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create):
|
||||
@@ -688,7 +688,7 @@ the app needs.
|
||||
For improved performance over a looping `get`, clients can design resources that
|
||||
reference a secret then `watch` the resource, re-requesting the secret when the
|
||||
reference changes. Additionally, a ["bulk watch" API](
|
||||
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md)
|
||||
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)
|
||||
to let clients `watch` individual resources has also been proposed, and will likely
|
||||
be available in future releases of Kubernetes.
|
||||
|
||||
|
||||
@@ -39,7 +39,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. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
|
||||
|
||||
Note that API versioning and Software versioning are only indirectly related. The [API and release
|
||||
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/versioning.md) describes the relationship between API versioning and
|
||||
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and
|
||||
software versioning.
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ in more detail in the [API Changes documentation](https://git.k8s.io/community/c
|
||||
|
||||
## API groups
|
||||
|
||||
To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-group.md).
|
||||
To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
|
||||
The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
|
||||
|
||||
Currently there are several API groups in use:
|
||||
@@ -84,7 +84,7 @@ There are two supported paths to extending the API with [custom resources](/docs
|
||||
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
|
||||
is for users with very basic CRUD needs.
|
||||
1. Coming soon: users needing the full set of Kubernetes API semantics can implement their own apiserver
|
||||
and use the [aggregator](https://git.k8s.io/community/contributors/design-proposals/aggregated-api-servers.md)
|
||||
and use the [aggregator](https://git.k8s.io/community/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||
to make it seamless for clients.
|
||||
|
||||
|
||||
|
||||
@@ -147,9 +147,9 @@ dns_setup: true
|
||||
This will finally setup your whole Kubernetes cluster for you.
|
||||
|
||||
```shell
|
||||
cd ~/contrib/ansible/
|
||||
cd ~/contrib/ansible/scripts/
|
||||
|
||||
./scripts/deploy-cluster.sh
|
||||
./deploy-cluster.sh
|
||||
```
|
||||
|
||||
## Testing and using your new cluster
|
||||
|
||||
@@ -34,9 +34,3 @@ The [Tools](/docs/tools/) page contains a list of native and third-party tools f
|
||||
## Troubleshooting
|
||||
|
||||
The [Troubleshooting](/docs/tasks/debug-application-cluster/troubleshooting) page outlines some resources for troubleshooting and finding help.
|
||||
|
||||
## Frequently Asked Questions
|
||||
|
||||
* [User FAQ](https://github.com/kubernetes/kubernetes/wiki/User-FAQ)
|
||||
* [Debugging FAQ](https://github.com/kubernetes/kubernetes/wiki/Debugging-FAQ)
|
||||
* [Services FAQ](https://github.com/kubernetes/kubernetes/wiki/Services-FAQ)
|
||||
|
||||
@@ -79,7 +79,7 @@ You will install these packages on all of your machines:
|
||||
**Note:** If you already have kubeadm installed, you should do a `apt-get update &&
|
||||
apt-get upgrade` or `yum update` to get the latest version of kubeadm. See the
|
||||
kubeadm release notes if you want to read about the different [kubeadm
|
||||
releases](https://github.com/kubernetes/kubeadm/blob/master/CHANGELOG.md)
|
||||
releases](https://github.com/kubernetes/kubeadm/blob/master/CHANGELOG.md).
|
||||
|
||||
For each machine:
|
||||
|
||||
@@ -116,12 +116,12 @@ For each machine:
|
||||
systemctl enable kubelet && systemctl start kubelet
|
||||
```
|
||||
|
||||
The kubelet is now restarting every few seconds, as it waits in a crashloop for
|
||||
kubeadm to tell it what to do.
|
||||
The kubelet is now restarting every few seconds, as it waits in a crashloop for
|
||||
kubeadm to tell it what to do.
|
||||
|
||||
Note: Disabling SELinux by running `setenforce 0` is required to allow
|
||||
containers to access the host filesystem, which is required by pod networks for
|
||||
example. You have to do this until SELinux support is improved in the kubelet.
|
||||
**Note:** Disabling SELinux by running `setenforce 0` is required to allow
|
||||
containers to access the host filesystem, which is required by pod networks for
|
||||
example. You have to do this until SELinux support is improved in the kubelet.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -264,7 +264,7 @@ kubectl config view
|
||||
```
|
||||
|
||||
The output shows merged information from all the files listed in your `KUBECONFIG`
|
||||
environnment variable. In particular, notice that the merged information has the
|
||||
environment variable. In particular, notice that the merged information has the
|
||||
`dev-ramp-up` context from the `config-demo-2` file and the three contexts from
|
||||
the `config-demo` file:
|
||||
|
||||
|
||||
@@ -12,10 +12,6 @@ This is *not* a guide for people who want to debug their cluster. For that you
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## FAQ
|
||||
|
||||
Users are highly encouraged to check out our [FAQ](https://github.com/kubernetes/kubernetes/wiki/User-FAQ).
|
||||
|
||||
## Diagnosing the problem
|
||||
|
||||
The first step in troubleshooting is triage. What is the problem? Is it your Pods, your Replication Controller or
|
||||
|
||||
@@ -31,12 +31,6 @@ development scenarios. The [Reference](/docs/reference/) section provides
|
||||
detailed documentation on the [Kubernetes API](/docs/api-reference/{{page.version}}/)
|
||||
and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl-overview/).
|
||||
|
||||
We also have a number of FAQ pages:
|
||||
|
||||
* [User FAQ](https://github.com/kubernetes/kubernetes/wiki/User-FAQ)
|
||||
* [Debugging FAQ](https://github.com/kubernetes/kubernetes/wiki/Debugging-FAQ)
|
||||
* [Services FAQ](https://github.com/kubernetes/kubernetes/wiki/Services-FAQ)
|
||||
|
||||
You may also find the Stack Overflow topics relevant:
|
||||
|
||||
* [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes)
|
||||
|
||||
@@ -12,7 +12,7 @@ This document describes the current state of Horizontal Pod Autoscaling in Kuber
|
||||
|
||||
With Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods
|
||||
in a replication controller, deployment or replica set based on observed CPU utilization
|
||||
(or, with alpha support, on some other, application-provided metrics). Note that Horizontal
|
||||
(or, with alpha support, on some other, application-provided metrics). Note that Horizontal
|
||||
Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSet.
|
||||
|
||||
The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller.
|
||||
@@ -44,7 +44,7 @@ or the custom metrics API (for all other metrics).
|
||||
|
||||
Please note that if some of the pod's containers do not have the relevant resource request set,
|
||||
CPU utilization for the pod will not be defined and the autoscaler will not take any action
|
||||
for that metric. See the [autoscaling algorithm design document](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#autoscaling-algorithm) for further
|
||||
for that metric. See the [autoscaling algorithm design document](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm) for further
|
||||
details about how the autoscaling algorithm works.
|
||||
|
||||
* For per-pod custom metrics, the controller functions similarly to per-pod resource metrics,
|
||||
@@ -64,7 +64,7 @@ See [Support for custom metrics](#support-for-custom-metrics) for more details o
|
||||
|
||||
The autoscaler accesses corresponding replication controller, deployment or replica set by scale sub-resource.
|
||||
Scale is an interface that allows you to dynamically set the number of replicas and examine each of their current states.
|
||||
More details on scale sub-resource can be found [here](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#scale-subresource).
|
||||
More details on scale sub-resource can be found [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
|
||||
|
||||
|
||||
## API Object
|
||||
@@ -78,7 +78,7 @@ can be found in `autoscaling/v2alpha1`. The new fields introduced in `autoscalin
|
||||
are preserved as annotations when working with `autoscaling/v1`.
|
||||
|
||||
More details about the API object can be found at
|
||||
[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
|
||||
[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
|
||||
|
||||
## Support for Horizontal Pod Autoscaler in kubectl
|
||||
|
||||
@@ -149,6 +149,6 @@ custom metrics API with the API aggregation layer. Both of these API servers mus
|
||||
|
||||
## Further reading
|
||||
|
||||
* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md).
|
||||
* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
|
||||
* kubectl autoscale command: [kubectl autoscale](/docs/user-guide/kubectl/v1.6/#autoscale).
|
||||
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
|
||||
@@ -131,7 +131,7 @@ Optional fields are:
|
||||
is `1m0s`. Valid units are as described for `--poll-interval` above.
|
||||
|
||||
Additional information about the `kubectl rolling-update` command is available
|
||||
from the [`kubectl` reference](/docs/user-guide/kubectl/v1.6/#rolling-update).
|
||||
from the [`kubectl` reference](/docs/user-guide/kubectl/{{page.version}}/#rolling-update).
|
||||
|
||||
## Walkthrough
|
||||
|
||||
|
||||
@@ -399,7 +399,7 @@ three replicas.
|
||||
|
||||
```shell
|
||||
kubectl patch sts web -p '{"spec":{"replicas":3}}'
|
||||
"web" patched
|
||||
statefulset "web" patched
|
||||
```
|
||||
|
||||
Wait for `web-4` and `web-3` to transition to Terminating.
|
||||
|
||||
Reference in New Issue
Block a user