Skip to content

Commit 65b5e10

Browse files
chenopischenopis
committed
Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into chenopis-user-journeys
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (21 commits) Remove User FAQ refer links (#5467) fix link of secret ZTE-SH-CN-debug-stateful-set-2017-09-19 use para. page.version to replace specific version update the admission-controllers.md index.md what-is-kubernetes.md link Fix incorrect links update aggregated-api-servers.md link update api-group link fix version.md link Monthly 404 fix (#5494) Fix spelling mistake. Adding Treasure Data to KCSP page (#5488) Update docs/admin/authentication.md (#5408) ZTE-SH-CN-debug-pod-replication-controller-2017-09-14-14 ZTE-SH-CN-define-command-argument-container (#5381) Update index.md Update Kompose docs Improve host aliases page (#5443) Add link to AlwaysPullImages admission controller Revert "create homepage for user journeys" ... # Conflicts: # docs/home/index.md
2 parents dae6482 + cd67108 commit 65b5e10

File tree

24 files changed

+832
-291
lines changed

24 files changed

+832
-291
lines changed

‎_data/tasks.yml

-4
Original file line numberDiff line numberDiff line change
@@ -158,8 +158,6 @@ toc:
158158
- docs/tasks/administer-cluster/configure-multiple-schedulers.md
159159
- docs/tasks/administer-cluster/ip-masq-agent.md
160160
- docs/tasks/administer-cluster/dns-custom-nameservers.md
161-
- title: Change Cluster Size
162-
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
163161

164162
- title: Federation - Run an App on Multiple Clusters
165163
section:
@@ -185,5 +183,3 @@ toc:
185183
- title: Manage GPUs
186184
section:
187185
- docs/tasks/manage-gpus/scheduling-gpus.md
188-
189-

‎_includes/partner-script.js

+2-2
Original file line numberDiff line numberDiff line change
@@ -261,7 +261,7 @@
261261
},
262262
{
263263
type: 2,
264-
name: 'inwinSTACK',
264+
name: 'InwinSTACK',
265265
logo: 'inwinstack',
266266
link: 'http://www.inwinstack.com/index.php/en/solutions-en/',
267267
blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.'
@@ -498,7 +498,7 @@
498498
blurb: 'Generate a real-time, auto-discovered application topology map! Monitor Kubernetes pods and namespaces without any code instrumentation.'
499499
},
500500
{
501-
type: 0,
501+
type: 2,
502502
name: 'Treasure Data',
503503
logo: 'treasure-data',
504504
link: 'https://fluentd.treasuredata.com/kubernetes-logging/',

‎_redirects

+124-32
Large diffs are not rendered by default.

‎cn/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md

+87
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title: 调试Pods和Replication Controllers
3+
---
4+
5+
* TOC
6+
{:toc}
7+
8+
## 调试Pods
9+
10+
调试一个pod的第一步是观察它。使用下面的命令检查这个pod的当前状态和最近事件：
11+
12+
$ kubectl describe pods ${POD_NAME}
13+
14+
看看pod中的容器的状态。他们都是`Running`吗？有最近重启了吗？
15+
16+
根据pod的状态继续调试。
17+
18+
### 我的Pod保持Pending
19+
20+
如果一个pod被卡在`Pending`中，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足
21+
阻止调度。 看看上面的命令`kubectl describe ...`的输出。调度器的消息中应该会包含无法调度Pod的原因。
22+
理由包括：
23+
24+
#### 资源不足
25+
26+
您可能已经耗尽了集群中供应的CPU或内存。在这个情况下你可以尝试几件事情：
27+
28+
* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。
29+
30+
* [终止不需要的pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
31+
为pending中的pods提供空间。
32+
33+
* 检查该pod是否不大于您的节点。例如，如果全部节点具有`cpu:1`容量，那么具有`cpu: 1.1`请求的pod永远不会被调度。
34+
35+
您可以使用`kubectl get nodes -o <format>`命令来检查节点容量。
36+
下面是一些能够提取必要信息的命令示例：
37+
38+
kubectl get nodes -o yaml | grep '\sname\|cpu\|memory'
39+
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
40+
41+
可以考虑配置[资源配额](/docs/concepts/policy/resource-quotas/)来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
42+
43+
#### 使用hostPort
44+
45+
当你将一个pod绑定到一个`hostPort`时，这个pod能被调度的位置数量有限。
46+
在大多数情况下，`hostPort`是不必要的; 尝试使用服务对象来暴露您的pod。
47+
如果你需要`hostPort`，那么你可以调度的Pod数量不能超过集群的节点个数。
48+
49+
### 我的Pod一直在Waiting
50+
51+
如果一个pod被卡在`Waiting`状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
52+
再次，来自`kubectl describe ...`的内容应该是可以提供信息的。
53+
最常见的原因`Waiting`的pod是无法拉取镜像。有三件事要检查：
54+
55+
* 确保您的镜像的名称正确。
56+
* 您是否将镜像推送到存储库？
57+
* 在您的机器上手动运行`docker pull <image>`，看看是否可以拉取镜像。
58+
59+
### 我的Pod一直Crashing或者有别的不健康状态
60+
61+
首先，查看当前容器的日志：
62+
63+
$ kubectl logs ${POD_NAME} ${CONTAINER_NAME}
64+
65+
如果您的容器先前已崩溃，则可以访问上一个容器的崩溃日志：
66+
67+
$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
68+
69+
或者，您可以使用`exec`在该容器内运行命令：
70+
71+
$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
72+
73+
请注意，`-c ${CONTAINER_NAME}`是可选的，对于pod只包含一个容器可以省略。
74+
75+
例如，要查看正在运行的Cassandra pod的日志，可以运行：
76+
77+
$ kubectl exec cassandra -- cat /var/log/cassandra/system.log
78+
79+
如果这些方法都不起作用，您可以找到该运行pod所在的主机并SSH到该主机。
80+
81+
## 调试Replication Controllers
82+
83+
Replication Controllers相当简单。他们能或不能创建pod。如果他们无法创建pod，那么请参考
84+
[上面的说明](#debugging_pods)来调试你的pod。
85+
86+
您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。
87+

‎cn/docs/tasks/debug-application-cluster/debug-stateful-set.md

+77
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
---
2+
title: 调试StatefulSet
3+
---
4+
5+
{% capture overview %}
6+
7+
此任务展示如何调试StatefulSet。
8+
9+
{% endcapture %}
10+
11+
{% capture prerequisites %}
12+
13+
14+
* 你需要有一个Kubernetes集群，通过必要的配置使kubectl命令行工具与您的集群进行通信。
15+
* 你应该有一个运行中的StatefulSet，以便用于调试。
16+
17+
{% endcapture %}
18+
19+
{% capture steps %}
20+
21+
## 调试StatefulSet
22+
23+
由于StatefulSet在创建时设置了`app=myapp`标签，列出仅属于该StatefulSet的所有pod时，可以使用以下命令：
24+
25+
```shell
26+
kubectl get pods -l app=myapp
27+
```
28+
29+
如果您发现列出的任何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。
30+
31+
StatefulSets提供调试机制，可以使用注解来暂停所有控制器在Pod上的操作。在任何StatefulSet Pod上设置`pod.alpha.kubernetes.io/initialized`注解为`"false"`将*暂停* StatefulSet的所有操作。暂停时，StatefulSet将不执行任何伸缩操作。一旦调试钩子设置完成后，就可以在StatefulSet pod的容器内执行命令，而不会造成伸缩操作的干扰。您可以通过执行以下命令将注解设置为`"false"`：
32+
33+
```shell
34+
kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --overwrite
35+
```
36+
37+
当注解设置为`"false"`时，StatefulSet在其Pods变得不健康或不可用时将不会响应。StatefulSet不会创建副本Pod直到每个Pod上删除注解或将注解设置为`"true"`。
38+
39+
### 逐步初始化
40+
41+
创建StatefulSet之前，您可以通过使用和上文相同的注解，即将yaml文件中`.spec.template.metadata.annotations`里的`pod.alpha.kubernetes.io/initialized`字段设置为`"false"`，对竞态条件的StatefulSet进行调试。
42+
43+
```yaml
44+
apiVersion: apps/v1beta1
45+
kind: StatefulSet
46+
metadata:
47+
name: my-app
48+
spec:
49+
serviceName: "my-app"
50+
replicas: 3
51+
template:
52+
metadata:
53+
labels:
54+
app: my-app
55+
annotations:
56+
pod.alpha.kubernetes.io/initialized: "false"
57+
...
58+
...
59+
...
60+
61+
```
62+
63+
设置注解后，如果创建了StatefulSet，您可以等待每个Pod来验证它是否正确初始化。StatefulSet将不会创建任何后续的Pods，直到在已经创建的每个Pod上将调试注解设置为`"true"` (或删除)。 您可以通过执行以下命令将注解设置为`"true"`：
64+
65+
```shell
66+
kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="true" --overwrite
67+
```
68+
69+
{% endcapture %}
70+
71+
{% capture whatsnext %}
72+
73+
点击链接[调试init-container](/docs/tasks/troubleshoot/debug-init-containers/)，了解更多信息。
74+
75+
{% endcapture %}
76+
77+
{% include templates/task.md %}

‎cn/docs/tasks/inject-data-application/commands.yaml

+12
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
apiVersion: v1
2+
kind: Pod
3+
metadata:
4+
name: command-demo
5+
labels:
6+
purpose: demonstrate-command
7+
spec:
8+
containers:
9+
- name: command-demo-container
10+
image: debian
11+
command: ["printenv"]
12+
args: ["HOSTNAME", "KUBERNETES_PORT"]

‎cn/docs/tasks/inject-data-application/define-command-argument-container.md

+128
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,128 @@
1+
---
2+
title: 为容器设置启动时要执行的命令及其入参
3+
---
4+
5+
{% capture overview %}
6+
7+
本页将展示如何为Kubernetes Pod下的容器设置启动时要执行的命令及其入参。
8+
9+
{% endcapture %}
10+
11+
12+
{% capture prerequisites %}
13+
14+
{% include task-tutorial-prereqs.md %}
15+
16+
{% endcapture %}
17+
18+
19+
{% capture steps %}
20+
21+
## 创建Pod时为其下的容器设置启动时要执行的命令及其入参
22+
23+
创建Pod时，可以为其下的容器设置启动时要执行的命令及其入参。如果要设置命令，就
24+
填写在配置文件的`command`字段下，如果要设置命令的入参，就填写在配置文件的`args
25+
`字段下。一旦Pod创建完成，该命令及其入参就无法再进行更改了。
26+
27+
如果在配置文件中设置了容器启动时要执行的命令及其入参，那么容器镜像中自带的命令
28+
与入参将会被覆盖而不再执行。如果配置文件中只是设置了入参，却没有设置其对应的命
29+
令，那么容器镜像中自带的命令会使用该新入参作为其执行时的入参。
30+
31+
本示例中，将创建一个只包含单个容器的Pod。在Pod配置文件中设置了一个命令与两个入参：
32+
33+
{% include code.html language="yaml" file="commands.yaml" ghlink="/cn/docs/tasks/inject-data-application/commands.yaml" %}
34+
35+
1. 基于YAML文件创建一个Pod：
36+
37+
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml
38+
39+
1. 获取一下当前正在运行的Pods信息：
40+
41+
kubectl get pods
42+
43+
查询结果显示在command-demo这个Pod下运行的容器已经启动完成
44+
45+
1. 如果要获取容器启动时执行命令的输出结果，可以通过Pod的日志进行查看
46+
47+
kubectl logs command-demo
48+
49+
日志中显示了HOSTNAME 与KUBERNETES_PORT 这两个环境变量的值：
50+
51+
command-demo
52+
tcp://10.3.240.1:443
53+
54+
## 使用环境变量来设置入参
55+
56+
在上面的示例中，我们直接将一串字符作为命令的入参。除此之外，我们还可以
57+
将环境变量作为命令的入参。
58+
59+
env:
60+
- name: MESSAGE
61+
value: "hello world"
62+
command: ["/bin/echo"]
63+
args: ["$(MESSAGE)"]
64+
65+
这样一来，我们就可以将那些用来设置环境变量的方法应用于设置命令的入参，其
66+
中包括了[ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
67+
与
68+
[Secrets](/docs/concepts/configuration/secret/).
69+
70+
**注意：** 环境变量需要加上括号，类似于`"$(VAR)"`。这是在`command`
71+
或 `args`字段使用变量的格式要求。
72+
{: .note}
73+
74+
## 通过shell来执行命令
75+
76+
有时候，需要通过shell来执行命令。 例如，命令可能由多个命令组合而成，抑或包含
77+
在一个shell脚本中。这时，就可以通过如下方式在shell中执行命令：
78+
79+
command: ["/bin/sh"]
80+
args: ["-c", "while true; do echo hello; sleep 10;done"]
81+
82+
## 注意
83+
84+
下表给出了Docker 与 Kubernetes中对应的字段名称。
85+
86+
| Description | Docker field name | Kubernetes field name |
87+
|----------------------------------------|------------------------|-----------------------|
88+
| The command run by the container | Entrypoint | command |
89+
| The arguments passed to the command | Cmd | args |
90+
91+
如果要覆盖默认的Entrypoint 与 Cmd，需要遵循如下规则：
92+
93+
* 如果在容器配置中没有设置`command` 或者 `args`，那么将使用Docker镜像自带的命
94+
令及其入参。
95+
96+
* 如果在容器配置中只设置了`command`但是没有设置`args`,那么容器启动时只会执行该
97+
命令，Docker镜像中自带的命令及其入参会被忽略。
98+
99+
* 如果在容器配置中只设置了`args`,那么Docker镜像中自带的命令会使用该新入参作为
100+
其执行时的入参。
101+
102+
* 如果在容器配置中同时设置了`command` 与 `args`，那么Docker镜像中自带的命令及
103+
其入参会被忽略。容器启动时只会执行配置中设置的命令，并使用配置中设置的入参作为
104+
命令的入参。
105+
106+
下表涵盖了各类设置场景：
107+
108+
| Image Entrypoint | Image Cmd | Container command | Container args | Command run |
109+
|--------------------|------------------|---------------------|--------------------|------------------|
110+
| `[/ep-1]` | `[foo bar]` | &lt;not set&gt; | &lt;not set&gt; | `[ep-1 foo bar]` |
111+
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | &lt;not set&gt; | `[ep-2]` |
112+
| `[/ep-1]` | `[foo bar]` | &lt;not set&gt; | `[zoo boo]` | `[ep-1 zoo boo]` |
113+
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
114+
115+
116+
{% endcapture %}
117+
118+
{% capture whatsnext %}
119+
120+
* 获取更多资讯可参考 [containers and commands](/docs/user-guide/containers/).
121+
* 获取更多资讯可参考 [configuring pods and containers](/docs/tasks/).
122+
* 获取更多资讯可参考 [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
123+
* 参考 [Container](/docs/api-reference/{{page.version}}/#container-v1-core).
124+
125+
{% endcapture %}
126+
127+
128+
{% include templates/task.md %}

‎docs/admin/admission-controllers.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -238,7 +238,7 @@ When the plug-in sets a compute resource request, it does this by *annotating* t
238238
the pod spec rather than mutating the `container.resources` fields.
239239
The annotations added contain the information on what compute resources were auto-populated.
240240

241-
See the [InitialResouces proposal](https://git.k8s.io/community/contributors/design-proposals/initial-resources.md) for more details.
241+
See the [InitialResouces proposal](https://git.k8s.io/community/contributors/design-proposals/autoscaling/initial-resources.md) for more details.
242242

243243
### LimitPodHardAntiAffinity
244244

@@ -253,7 +253,7 @@ your Kubernetes deployment, you MUST use this plug-in to enforce those constrain
253253
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
254254
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
255255

256-
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
256+
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
257257

258258
### NamespaceAutoProvision
259259

@@ -373,7 +373,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
373373
enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota`
374374
objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
375375

376-
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
376+
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
377377

378378
It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins. This is
379379
so that quota is not prematurely incremented only for the request to be rejected later in admission control.

0 commit comments

Comments
 (0)