Merge pull request #25188 from tengqm/zh-sync-12
[zh] Sync changes from English site (12)
This commit is contained in:
commit
c37cac5afd
|
@ -281,8 +281,8 @@ PodTemplates are specifications for creating Pods, and are included in workload
|
|||
-->
|
||||
### Pod 模版 {#pod-templates}
|
||||
|
||||
{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用 _Pod 模板(Pod Template)_
|
||||
来替你创建 Pod 并管理它们。
|
||||
{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用
|
||||
_Pod 模板(Pod Template)_ 来替你创建 Pod 并管理它们。
|
||||
|
||||
Pod 模板是包含在工作负载对象中的规范,用来创建 Pod。这类负载资源包括
|
||||
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
|
||||
|
|
|
@ -18,14 +18,14 @@ This page shows how to configure a Pod to use a
|
|||
for storage.
|
||||
Here is a summary of the process:
|
||||
|
||||
1. A cluster administrator creates a PersistentVolume that is backed by physical
|
||||
storage. The administrator does not associate the volume with any Pod.
|
||||
1. You, as cluster administrator, create a PersistentVolume backed by physical
|
||||
storage. You do not associate the volume with any Pod.
|
||||
|
||||
1. You, now taking the role of a developer / cluster user, create a
|
||||
PersistentVolumeClaim that is automatically bound to a suitable
|
||||
PersistentVolume.
|
||||
|
||||
1. The user creates a Pod that uses the PersistentVolumeClaim as storage.
|
||||
1. You create a Pod that uses the above PersistentVolumeClaim for storage.
|
||||
-->
|
||||
本文介绍如何配置 Pod 使用
|
||||
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
|
||||
|
@ -45,15 +45,16 @@ PersistentVolume.
|
|||
* You need to have a Kubernetes cluster that has only one Node, and the kubectl
|
||||
command-line tool must be configured to communicate with your cluster. If you
|
||||
do not already have a single-node cluster, you can create one by using
|
||||
[Minikube](/docs/getting-started-guides/minikube).
|
||||
[Minikube](https://minikube.sigs.k8s.io/docs/).
|
||||
|
||||
* Familiarize yourself with the material in
|
||||
[Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
-->
|
||||
|
||||
* 你需要一个包含单个节点的 Kubernetes 集群,并且必须配置 kubectl 命令行工具以便与集群交互。
|
||||
如果还没有单节点集群,可以使用 [Minikube](/zh/docs/setup/learning-environment/minikube/) 创建一个。
|
||||
|
||||
如果还没有单节点集群,可以使用
|
||||
[Minikube](https://minikube.sigs.k8s.io/docs/) 创建一个。
|
||||
.
|
||||
* 熟悉[持久卷](/zh/docs/concepts/storage/persistent-volumes/)中的材料。
|
||||
|
||||
<!-- steps -->
|
||||
|
@ -420,8 +421,8 @@ metadata:
|
|||
<!--
|
||||
When a Pod consumes a PersistentVolume that has a GID annotation, the annotated GID
|
||||
is applied to all Containers in the Pod in the same way that GIDs specified in the
|
||||
Pod’s security context are. Every GID, whether it originates from a PersistentVolume
|
||||
annotation or the Pod’s specification, is applied to the first process run in
|
||||
Pod's security context are. Every GID, whether it originates from a PersistentVolume
|
||||
annotation or the Pod's specification, is applied to the first process run in
|
||||
each Container.
|
||||
-->
|
||||
当 Pod 使用带有 GID 注解的 PersistentVolume 时,注解的 GID 会被应用于 Pod 中的所有容器,
|
||||
|
|
|
@ -8,14 +8,12 @@ content_type: task
|
|||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- Random-Liu
|
||||
- feiskyer
|
||||
- mrunalp
|
||||
title: Debugging Kubernetes nodes with crictl
|
||||
content_type: task
|
||||
---
|
||||
-->
|
||||
|
||||
|
||||
|
@ -27,54 +25,46 @@ content_type: task
|
|||
`crictl` is a command-line interface for CRI-compatible container runtimes.
|
||||
You can use it to inspect and debug container runtimes and applications on a
|
||||
Kubernetes node. `crictl` and its source are hosted in the
|
||||
[cri-tools](https://github.com/kubernetes-incubator/cri-tools) repository.
|
||||
[cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository.
|
||||
-->
|
||||
|
||||
`crictl` 是 CRI 兼容的容器运行时命令行接口。
|
||||
您可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。
|
||||
`crictl`和它的源代码在 [cri-tools](https://github.com/kubernetes-incubator/cri-tools) 代码库。
|
||||
|
||||
|
||||
你可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。
|
||||
`crictl` 和它的源代码在
|
||||
[cri-tools](https://github.com/kubernetes-sigs/cri-tools) 代码库。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
<!--
|
||||
`crictl` requires a Linux operating system with a CRI runtime.
|
||||
-->
|
||||
|
||||
`crictl` 需要带有 CRI 运行时的 Linux 操作系统。
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Installing crictl
|
||||
|
||||
You can download a compressed archive `crictl` from the cri-tools [release
|
||||
page](https://github.com/kubernetes-incubator/cri-tools/releases), for several
|
||||
page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
|
||||
different architectures. Download the version that corresponds to your version
|
||||
of Kubernetes. Extract it and move it to a location on your system path, such as
|
||||
`/usr/local/bin/`.
|
||||
-->
|
||||
|
||||
## 安装 crictl
|
||||
|
||||
您可以从 cri-tools [发布页面](https://github.com/kubernetes-incubator/cri-tools/releases)下载一个压缩的 `crictl` 归档文件,用于几种不同的架构。
|
||||
下载与您的 kubernetes 版本相对应的版本。
|
||||
你可以从 cri-tools [发布页面](https://github.com/kubernetes-sigs/cri-tools/releases)
|
||||
下载一个压缩的 `crictl` 归档文件,用于几种不同的架构。
|
||||
下载与你的 kubernetes 版本相对应的版本。
|
||||
提取它并将其移动到系统路径上的某个位置,例如`/usr/local/bin/`。
|
||||
|
||||
<!--
|
||||
## General usage
|
||||
-->
|
||||
|
||||
## 一般用法
|
||||
|
||||
<!--
|
||||
The `crictl` command has several subcommands and runtime flags. Use
|
||||
`crictl help` or `crictl <subcommand> help` for more details.
|
||||
-->
|
||||
## 一般用法
|
||||
|
||||
`crictl` 命令有几个子命令和运行时参数。
|
||||
有关详细信息,请使用 `crictl help` 或 `crictl <subcommand> help` 获取帮助信息。
|
||||
|
@ -83,38 +73,36 @@ The `crictl` command has several subcommands and runtime flags. Use
|
|||
`crictl` connects to `unix:///var/run/dockershim.sock` by default. For other
|
||||
runtimes, you can set the endpoint in multiple different ways:
|
||||
-->
|
||||
|
||||
`crictl` 默认连接到 `unix:///var/run/dockershim.sock`。
|
||||
对于其他的运行时,您可以用多种不同的方法设置端点:
|
||||
对于其他的运行时,你可以用多种不同的方法设置端点:
|
||||
|
||||
<!--
|
||||
- By setting flags `--runtime-endpoint` and `--image-endpoint`
|
||||
- By setting environment variables `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT`
|
||||
- By setting the endpoint in the config file `--config=/etc/crictl.yaml`
|
||||
-->
|
||||
|
||||
- 通过设置参数 `--runtime-endpoint` 和 `--image-endpoint`
|
||||
- 通过设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`
|
||||
- 通过在配置文件中设置端点 `--config=/etc/crictl.yaml`
|
||||
|
||||
|
||||
<!--
|
||||
You can also specify timeout values when connecting to the server and enable or
|
||||
disable debugging, by specifying `timeout` or `debug` values in the configuration
|
||||
file or using the `--timeout` and `--debug` command-line flags.
|
||||
-->
|
||||
|
||||
您还可以在连接到服务器并启用或禁用调试时指定超时值,方法是在配置文件中指定 `timeout` 或 `debug` 值,或者使用 `--timeout` 和 `--debug` 命令行参数。
|
||||
你还可以在连接到服务器并启用或禁用调试时指定超时值,方法是在配置文件中指定
|
||||
`timeout` 或 `debug` 值,或者使用 `--timeout` 和 `--debug` 命令行参数。
|
||||
|
||||
<!--
|
||||
To view or edit the current configuration, view or edit the contents of
|
||||
`/etc/crictl.yaml`.
|
||||
-->
|
||||
|
||||
要查看或编辑当前配置,请查看或编辑 `/etc/crictl.yaml` 的内容。
|
||||
|
||||
```sh
|
||||
```shell
|
||||
cat /etc/crictl.yaml
|
||||
```
|
||||
```
|
||||
runtime-endpoint: unix:///var/run/dockershim.sock
|
||||
image-endpoint: unix:///var/run/dockershim.sock
|
||||
timeout: 10
|
||||
|
@ -126,18 +114,17 @@ debug: true
|
|||
|
||||
The following examples show some `crictl` commands and example output.
|
||||
-->
|
||||
|
||||
## crictl 命令示例
|
||||
|
||||
{{< warning >}}
|
||||
|
||||
<!--If you use `crictl` to create pod sandboxes or containers on a running
|
||||
<!--
|
||||
If you use `crictl` to create pod sandboxes or containers on a running
|
||||
Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
|
||||
general purpose workflow tool, but a tool that is useful for debugging.-->
|
||||
|
||||
如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器,kubelet 最终将删除它们。
|
||||
`crictl`不是一个通用的工作流工具,而是一个对调试有用的工具。
|
||||
|
||||
general purpose workflow tool, but a tool that is useful for debugging.
|
||||
-->
|
||||
如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器,
|
||||
kubelet 最终将删除它们。
|
||||
`crictl` 不是一个通用的工作流工具,而是一个对调试有用的工具。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
|
@ -145,14 +132,14 @@ general purpose workflow tool, but a tool that is useful for debugging.-->
|
|||
|
||||
List all pods:
|
||||
-->
|
||||
|
||||
### 打印 Pod 清单
|
||||
|
||||
打印所有 Pod 的清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl pods
|
||||
```
|
||||
|
||||
```none
|
||||
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
|
||||
926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0
|
||||
|
@ -164,12 +151,12 @@ a86316e96fa89 17 hours ago Ready kube-proxy-gblk4
|
|||
<!--
|
||||
List pods by name:
|
||||
-->
|
||||
|
||||
根据名称打印 Pod 清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl pods --name nginx-65899c769f-wv2gp
|
||||
```
|
||||
|
||||
```none
|
||||
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
|
||||
4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0
|
||||
|
@ -178,10 +165,9 @@ POD ID CREATED STATE NAME
|
|||
<!--
|
||||
List pods by label:
|
||||
-->
|
||||
|
||||
根据标签打印 Pod 清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl pods --label run=nginx
|
||||
```
|
||||
```none
|
||||
|
@ -194,12 +180,11 @@ POD ID CREATED STATE NAME
|
|||
|
||||
List all images:
|
||||
-->
|
||||
|
||||
### 打印镜像清单
|
||||
|
||||
打印所有镜像清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl images
|
||||
```
|
||||
```none
|
||||
|
@ -213,10 +198,9 @@ nginx latest cd5239a0906a6
|
|||
<!--
|
||||
List images by repository:
|
||||
-->
|
||||
|
||||
根据仓库打印镜像清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl images nginx
|
||||
```
|
||||
```none
|
||||
|
@ -227,10 +211,9 @@ nginx latest cd5239a0906a6 109MB
|
|||
<!--
|
||||
Only list image IDs:
|
||||
-->
|
||||
|
||||
只打印镜像 ID:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl images -q
|
||||
```
|
||||
```none
|
||||
|
@ -245,12 +228,11 @@ sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569
|
|||
|
||||
List all containers:
|
||||
-->
|
||||
|
||||
### 打印容器清单
|
||||
|
||||
打印所有容器清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl ps -a
|
||||
```
|
||||
```none
|
||||
|
@ -264,10 +246,9 @@ CONTAINER ID IMAGE
|
|||
<!--
|
||||
List running containers:
|
||||
-->
|
||||
|
||||
打印正在运行的容器清单:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl ps
|
||||
```
|
||||
```none
|
||||
|
@ -280,10 +261,9 @@ CONTAINER ID IMAGE
|
|||
<!--
|
||||
### Execute a command in a running container
|
||||
-->
|
||||
|
||||
### 在正在运行的容器上执行命令
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl exec -i -t 1f73f2d81bf98 ls
|
||||
```
|
||||
```none
|
||||
|
@ -295,12 +275,11 @@ bin dev etc home proc root sys tmp usr var
|
|||
|
||||
Get all container logs:
|
||||
-->
|
||||
|
||||
### 获取容器日志
|
||||
|
||||
获取容器的所有日志:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl logs 87d3992f84f74
|
||||
```
|
||||
```none
|
||||
|
@ -312,10 +291,9 @@ crictl logs 87d3992f84f74
|
|||
<!--
|
||||
Get only the latest `N` lines of logs:
|
||||
-->
|
||||
|
||||
获取最近的 `N` 行日志:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl logs --tail=1 87d3992f84f74
|
||||
```
|
||||
```none
|
||||
|
@ -329,38 +307,37 @@ Using `crictl` to run a pod sandbox is useful for debugging container runtimes.
|
|||
On a running Kubernetes cluster, the sandbox will eventually be stopped and
|
||||
deleted by the Kubelet.
|
||||
-->
|
||||
|
||||
### 运行 Pod 沙盒
|
||||
|
||||
用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。
|
||||
在运行的 Kubernetes 集群中,沙盒会随机地被 kubelet 停止和删除。
|
||||
|
||||
1. <!--Create a JSON file like the following:-->
|
||||
编写下面的 JSON 文件:
|
||||
1. <!--Create a JSON file like the following:-->
|
||||
编写下面的 JSON 文件:
|
||||
|
||||
```json
|
||||
{
|
||||
"metadata": {
|
||||
"name": "nginx-sandbox",
|
||||
"namespace": "default",
|
||||
"attempt": 1,
|
||||
"uid": "hdishd83djaidwnduwk28bcsb"
|
||||
},
|
||||
"logDirectory": "/tmp",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"metadata": {
|
||||
"name": "nginx-sandbox",
|
||||
"namespace": "default",
|
||||
"attempt": 1,
|
||||
"uid": "hdishd83djaidwnduwk28bcsb"
|
||||
},
|
||||
"logDirectory": "/tmp",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. <!--Use the `crictl runp` command to apply the JSON and run the sandbox.-->
|
||||
使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
|
||||
2. <!--Use the `crictl runp` command to apply the JSON and run the sandbox.-->
|
||||
使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
|
||||
|
||||
```bash
|
||||
crictl runp pod-config.json
|
||||
```
|
||||
```shell
|
||||
crictl runp pod-config.json
|
||||
```
|
||||
|
||||
<!--The ID of the sandbox is returned.-->
|
||||
返回了沙盒的 ID。
|
||||
<!--The ID of the sandbox is returned.-->
|
||||
返回了沙盒的 ID。
|
||||
|
||||
<!--
|
||||
### Create a container
|
||||
|
@ -369,91 +346,88 @@ Using `crictl` to create a container is useful for debugging container runtimes.
|
|||
On a running Kubernetes cluster, the sandbox will eventually be stopped and
|
||||
deleted by the Kubelet.
|
||||
-->
|
||||
|
||||
### 创建容器
|
||||
|
||||
用 `crictl` 创建容器对容器运行时排错很有帮助。
|
||||
在运行的 Kubernetes 集群中,沙盒会随机的被 kubelet 停止和删除。
|
||||
|
||||
1. <!--Pull a busybox image-->
|
||||
拉取 busybox 镜像
|
||||
|
||||
1. <!--Pull a busybox image-->
|
||||
拉取 busybox 镜像
|
||||
```bash
|
||||
crictl pull busybox
|
||||
Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
|
||||
```
|
||||
|
||||
```bash
|
||||
crictl pull busybox
|
||||
Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
|
||||
```
|
||||
2. <!--Create configs for the pod and the container:-->
|
||||
创建 Pod 和容器的配置:
|
||||
|
||||
2. <!--Create configs for the pod and the container:-->
|
||||
创建 Pod 和容器的配置:
|
||||
<!--**Pod config**:-->
|
||||
**Pod 配置**:
|
||||
```yaml
|
||||
{
|
||||
"metadata": {
|
||||
"name": "nginx-sandbox",
|
||||
"namespace": "default",
|
||||
"attempt": 1,
|
||||
"uid": "hdishd83djaidwnduwk28bcsb"
|
||||
},
|
||||
"log_directory": "/tmp",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--**Pod config**:-->
|
||||
**Pod 配置**:
|
||||
```yaml
|
||||
{
|
||||
"metadata": {
|
||||
"name": "nginx-sandbox",
|
||||
"namespace": "default",
|
||||
"attempt": 1,
|
||||
"uid": "hdishd83djaidwnduwk28bcsb"
|
||||
},
|
||||
"log_directory": "/tmp",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
```
|
||||
<!--**Container config**:-->
|
||||
**容器配置**:
|
||||
```yaml
|
||||
{
|
||||
"metadata": {
|
||||
"name": "busybox"
|
||||
},
|
||||
"image":{
|
||||
"image": "busybox"
|
||||
},
|
||||
"command": [
|
||||
"top"
|
||||
],
|
||||
"log_path":"busybox.log",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--**Container config**:-->
|
||||
**容器配置**:
|
||||
```yaml
|
||||
{
|
||||
"metadata": {
|
||||
"name": "busybox"
|
||||
},
|
||||
"image":{
|
||||
"image": "busybox"
|
||||
},
|
||||
"command": [
|
||||
"top"
|
||||
],
|
||||
"log_path":"busybox.log",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
```
|
||||
3. <!--Create the container, passing the ID of the previously-created pod, the
|
||||
container config file, and the pod config file. The ID of the container is
|
||||
returned.-->
|
||||
创建容器,传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
|
||||
|
||||
3. <!--Create the container, passing the ID of the previously-created pod, the
|
||||
container config file, and the pod config file. The ID of the container is
|
||||
returned.-->
|
||||
创建容器,传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
|
||||
```bash
|
||||
crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
|
||||
```
|
||||
|
||||
```bash
|
||||
crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
|
||||
```
|
||||
4. <!--List all containers and verify that the newly-created container has its
|
||||
state set to `Created`.-->
|
||||
查询所有容器并确认新创建的容器状态为 `Created`。
|
||||
|
||||
4. <!--List all containers and verify that the newly-created container has its
|
||||
state set to `Created`.-->
|
||||
查询所有容器并确认新创建的容器状态为 `Created`。
|
||||
|
||||
```bash
|
||||
crictl ps -a
|
||||
```
|
||||
```none
|
||||
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
|
||||
3e025dd50a72d busybox 32 seconds ago Created busybox 0
|
||||
```
|
||||
```bash
|
||||
crictl ps -a
|
||||
```
|
||||
```none
|
||||
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
|
||||
3e025dd50a72d busybox 32 seconds ago Created busybox 0
|
||||
```
|
||||
|
||||
<!--
|
||||
### Start a container
|
||||
|
||||
To start a container, pass its ID to `crictl start`:
|
||||
-->
|
||||
|
||||
### 启动容器
|
||||
|
||||
要启动容器,要将容器 ID 传给 `crictl start`:
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
|
||||
```
|
||||
```none
|
||||
|
@ -463,27 +437,20 @@ crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
|
|||
<!--
|
||||
Check the container has its state set to `Running`.
|
||||
-->
|
||||
|
||||
确认容器的状态为 `Running`。
|
||||
|
||||
```bash
|
||||
```shell
|
||||
crictl ps
|
||||
```
|
||||
```none
|
||||
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
|
||||
3e025dd50a72d busybox About a minute ago Running busybox 0
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
<!--
|
||||
See [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)
|
||||
See [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)
|
||||
for more information.
|
||||
-->
|
||||
|
||||
更多信息请参考 [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)。
|
||||
|
||||
更多信息请参考 [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)。
|
||||
|
||||
|
|
|
@ -15,10 +15,11 @@ content_type: concept
|
|||
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
|
||||
problem you are experiencing. See
|
||||
the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
|
||||
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
|
||||
-->
|
||||
本篇文档是介绍集群故障排查的;我们假设对于你碰到的问题,你已经排除了是由应用程序造成的。
|
||||
对于应用的调试,请参阅[应用故障排查指南](/zh/docs/tasks/debug-application-cluster/debug-application/)。
|
||||
对于应用的调试,请参阅
|
||||
[应用故障排查指南](/zh/docs/tasks/debug-application-cluster/debug-application/)。
|
||||
你也可以访问[故障排查](/zh/docs/tasks/debug-application-cluster/troubleshooting/)
|
||||
来获取更多的信息。
|
||||
|
||||
|
|
|
@ -21,8 +21,8 @@ content_type: task
|
|||
<!--
|
||||
This page shows how to investigate problems related to the execution of
|
||||
Init Containers. The example command lines below refer to the Pod as
|
||||
`<pod-name>` and the Init Containers as `<init-container-1>` and
|
||||
`<init-container-2>`.
|
||||
`<pod-name>` and the Init Containers as `<init-container-1>` and
|
||||
`<init-container-2>`.
|
||||
-->
|
||||
此页显示如何核查与 Init 容器执行相关的问题。
|
||||
下面的示例命令行将 Pod 称为 `<pod-name>`,而 Init 容器称为 `<init-container-1>` 和
|
||||
|
@ -34,7 +34,7 @@ Init Containers. The example command lines below refer to the Pod as
|
|||
|
||||
<!--
|
||||
* You should be familiar with the basics of
|
||||
[Init Containers](/docs/concepts/abstractions/init-containers/).
|
||||
[Init Containers](/docs/concepts/workloads/pods/init-containers/).
|
||||
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
|
||||
-->
|
||||
|
||||
|
|
|
@ -77,9 +77,9 @@ can not schedule your pod. Reasons include:
|
|||
You may have exhausted the supply of CPU or Memory in your cluster. In this
|
||||
case you can try several things:
|
||||
|
||||
* [Add more nodes](/docs/admin/cluster-management/#resizing-a-cluster) to the cluster.
|
||||
* Add more nodes to the cluster.
|
||||
|
||||
* [Terminate unneeded pods](/docs/user-guide/pods/single-container/#deleting_a_pod)
|
||||
* [Terminate unneeded pods](/docs/concepts/workloads/pods/#pod-termination)
|
||||
to make room for pending pods.
|
||||
|
||||
* Check that the pod is not larger than your nodes. For example, if all
|
||||
|
@ -94,7 +94,7 @@ case you can try several things:
|
|||
|
||||
你可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情:
|
||||
|
||||
* [添加更多节点](/zh/docs/tasks/administer-cluster/cluster-management/) 到集群。
|
||||
* 向集群中添加节点。
|
||||
|
||||
* [终止不需要的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
|
||||
为 Pending 状态的 Pod 提供空间。
|
||||
|
|
|
@ -965,7 +965,7 @@ This might sound unlikely, but it does happen and it is supposed to work.
|
|||
This can happen when the network is not properly configured for "hairpin"
|
||||
traffic, usually when `kube-proxy` is running in `iptables` mode and Pods
|
||||
are connected with bridge network. The `Kubelet` exposes a `hairpin-mode`
|
||||
[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance
|
||||
[flag](/docs/reference/command-line-tools-reference/kubelet/) that allows endpoints of a Service to loadbalance
|
||||
back to themselves if they try to access their own Service VIP. The
|
||||
`hairpin-mode` flag must either be set to `hairpin-veth` or
|
||||
`promiscuous-bridge`.
|
||||
|
@ -977,7 +977,8 @@ back to themselves if they try to access their own Service VIP. The
|
|||
|
||||
如果网络没有为“发夹模式(Hairpin)”流量生成正确配置,
|
||||
通常当 `kube-proxy` 以 `iptables` 模式运行,并且 Pod 与桥接网络连接时,就会发生这种情况。
|
||||
`kubelet` 提供了 `hairpin-mode`[标志](/zh/docs/reference/command-line-tools-reference/kubelet/),
|
||||
`kubelet` 提供了 `hairpin-mode`
|
||||
[标志](/zh/docs/reference/command-line-tools-reference/kubelet/)。
|
||||
如果 Service 的末端尝试访问自己的 Service VIP,则该端点可以把流量负载均衡回来到它们自身。
|
||||
`hairpin-mode` 标志必须被设置为 `hairpin-veth` 或者 `promiscuous-bridge`。
|
||||
|
||||
|
@ -1068,7 +1069,7 @@ Service is not working. Please let us know what is going on, so we can help
|
|||
investigate!
|
||||
|
||||
Contact us on
|
||||
[Slack](/docs/troubleshooting/#slack) or
|
||||
[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack) or
|
||||
[Forum](https://discuss.kubernetes.io) or
|
||||
[GitHub](https://github.com/kubernetes/kubernetes).
|
||||
-->
|
||||
|
@ -1087,7 +1088,8 @@ Contact us on
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
Visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
Visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)
|
||||
for more information.
|
||||
-->
|
||||
访问[故障排查文档](/zh/docs/tasks/debug-application-cluster/troubleshooting/) 获取更多信息。
|
||||
|
||||
|
|
|
@ -37,13 +37,13 @@ kubectl get pods -l app=myapp
|
|||
|
||||
<!--
|
||||
If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,
|
||||
refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for
|
||||
refer to the [Deleting StatefulSet Pods](/docs/tasks/run-application/delete-stateful-set/) task for
|
||||
instructions on how to deal with them.
|
||||
You can debug individual Pods in a StatefulSet using the
|
||||
[Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
|
||||
-->
|
||||
如果你发现列出的任何 Pod 长时间处于 `Unknown` 或 `Terminating` 状态,请参阅
|
||||
[删除 StatefulSet Pods](/zh/docs/tasks/manage-stateful-set/delete-pods/)
|
||||
[删除 StatefulSet Pods](/zh/docs/tasks/run-application/delete-stateful-set/)
|
||||
了解如何处理它们的说明。
|
||||
你可以参考[调试 Pods](/zh/docs/tasks/debug-application-cluster/debug-application/)
|
||||
来调试 StatefulSet 中的各个 Pod。
|
||||
|
|
|
@ -15,7 +15,8 @@ title: Tools for Monitoring Resources
|
|||
To scale an application and provide a reliable service, you need to
|
||||
understand how the application behaves when it is deployed. You can examine
|
||||
application performance in a Kubernetes cluster by examining the containers,
|
||||
[pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and
|
||||
[pods](/docs/concepts/workloads/pods/),
|
||||
[services](/docs/concepts/services-networking/service/), and
|
||||
the characteristics of the overall cluster. Kubernetes provides detailed
|
||||
information about an application's resource usage at each of these levels.
|
||||
This information allows you to evaluate your application's performance and
|
||||
|
@ -23,7 +24,8 @@ where bottlenecks can be removed to improve overall performance.
|
|||
-->
|
||||
要扩展应用程序并提供可靠的服务,你需要了解应用程序在部署时的行为。
|
||||
你可以通过检测容器检查 Kubernetes 集群中的应用程序性能,
|
||||
[Pods](/zh/docs/concepts/workloads/pods), [服务](/zh/docs/concepts/services-networking/service/)
|
||||
[Pods](/zh/docs/concepts/workloads/pods),
|
||||
[服务](/zh/docs/concepts/services-networking/service/)
|
||||
和整个集群的特征。
|
||||
Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
|
||||
此信息使你可以评估应用程序的性能,以及在何处可以消除瓶颈以提高整体性能。
|
||||
|
@ -31,7 +33,9 @@ Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细
|
|||
<!-- body -->
|
||||
|
||||
<!--
|
||||
In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
|
||||
In Kubernetes, application monitoring does not depend on a single monitoring solution.
|
||||
On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or
|
||||
[full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
|
||||
-->
|
||||
在 Kubernetes 中,应用程序监控不依赖单个监控解决方案。
|
||||
在新集群上,你可以使用[资源度量](#resource-metrics-pipeline)或
|
||||
|
@ -41,24 +45,26 @@ In Kubernetes, application monitoring does not depend on a single monitoring sol
|
|||
## Resource metrics pipeline
|
||||
|
||||
The resource metrics pipeline provides a limited set of metrics related to
|
||||
cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
|
||||
cluster components such as the
|
||||
[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale)
|
||||
controller, as well as the `kubectl top` utility.
|
||||
These metrics are collected by the lightweight, short-term, in-memory
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
|
||||
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) and
|
||||
are exposed via the `metrics.k8s.io` API.
|
||||
-->
|
||||
## 资源度量管道 {#resource-metrics-pipeline}
|
||||
|
||||
资源指标管道提供了一组与集群组件,例如
|
||||
[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)控制器,
|
||||
以及 `kubectl top` 实用程序相关的有限度量。
|
||||
[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
控制器以及 `kubectl top` 实用程序相关的有限度量。
|
||||
这些指标是由轻量级的、短期、内存存储的
|
||||
[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的,
|
||||
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 收集的,
|
||||
通过 `metrics.k8s.io` 公开。
|
||||
|
||||
<!--
|
||||
metrics-server discovers all nodes on the cluster and
|
||||
queries each node's
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet/) for CPU and
|
||||
memory usage. The kubelet acts as a bridge between the Kubernetes master and
|
||||
the nodes, managing the pods and containers running on a machine. The kubelet
|
||||
translates each pod into its constituent containers and fetches individual
|
||||
|
@ -70,12 +76,14 @@ This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated
|
|||
read-only ports.
|
||||
-->
|
||||
度量服务器发现集群中的所有节点,并且查询每个节点的
|
||||
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
|
||||
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
|
||||
以获取 CPU 和内存使用情况。
|
||||
Kubelet 充当 Kubernetes 主节点与节点之间的桥梁,管理机器上运行的 Pod 和容器。
|
||||
kubelet 将每个 pod 转换为其组成的容器,并在容器运行时通过容器运行时界面获取各个容器使用情况统计信息。
|
||||
kubelet 将每个 Pod 转换为其组成的容器,并在容器运行时通过容器运行时接口
|
||||
获取各个容器使用情况统计信息。
|
||||
kubelet 从集成的 cAdvisor 获取此信息,以进行旧式 Docker 集成。
|
||||
然后,它通过 metrics-server Resource Metrics API 公开聚合的 pod 资源使用情况统计信息。
|
||||
该 API 在 kubelet 的经过身份验证和只读的端口上的`/metrics/resource/v1beta1`中提供。
|
||||
该 API 在 kubelet 的经过身份验证和只读的端口上的 `/metrics/resource/v1beta1` 中提供。
|
||||
|
||||
<!--
|
||||
## Full metrics pipeline
|
||||
|
@ -90,7 +98,8 @@ then exposes them to Kubernetes via an adapter by implementing either the
|
|||
## 完整度量管道 {#full-metrics-pipeline}
|
||||
|
||||
一个完整度量管道可以让你访问更丰富的度量。
|
||||
Kubernetes 还可以根据集群的当前状态,使用 Pod 水平自动扩缩器等机制,通过自动调用扩展或调整集群来响应这些度量。
|
||||
Kubernetes 还可以根据集群的当前状态,使用 Pod 水平自动扩缩器等机制,
|
||||
通过自动调用扩展或调整集群来响应这些度量。
|
||||
监控管道从 kubelet 获取度量值,然后通过适配器将它们公开给 Kubernetes,
|
||||
方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
|
||||
|
||||
|
@ -98,7 +107,7 @@ Kubernetes 还可以根据集群的当前状态,使用 Pod 水平自动扩缩
|
|||
[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
|
||||
Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.
|
||||
-->
|
||||
[Prometheus](https://prometheus.io) 是一个 CNCF 项目,可以原生监控 Kubernetes、节点和
|
||||
Prometheus 本身。
|
||||
[Prometheus](https://prometheus.io) 是一个 CNCF 项目,可以原生监控 Kubernetes、
|
||||
节点和 Prometheus 本身。
|
||||
完整度量管道项目不属于 CNCF 的一部分,不在 Kubernetes 文档的范围之内。
|
||||
|
||||
|
|
|
@ -108,6 +108,28 @@ configuration file.
|
|||
|
||||
* `kubectl delete -f <filename|url>`
|
||||
|
||||
<!-- note
|
||||
If configuration file has specified the `generateName` field in the `metadata`
|
||||
section instead of the `name` field, you cannot delete the object using
|
||||
`kubectl delete -f <filename|url>`.
|
||||
You will have to use other flags for deleting the object. For example:
|
||||
|
||||
```shell
|
||||
kubectl delete <type> <name>
|
||||
kubectl delete <type> -l <label>
|
||||
```
|
||||
-->
|
||||
{{< note >}}
|
||||
如果配置文件在 `metadata` 节中设置了 `generateName` 字段而非 `name` 字段,
|
||||
你无法使用 `kubectl delete -f <filename|url>` 来删除该对象。
|
||||
你必须使用其他标志才能删除对象。例如:
|
||||
|
||||
```shell
|
||||
kubectl delete <type> <name>
|
||||
kubectl delete <type> -l <label>
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## How to view an object
|
||||
|
||||
|
|
|
@ -1,7 +1,4 @@
|
|||
---
|
||||
reviewers:
|
||||
- lachie83
|
||||
- khenidak
|
||||
title: 验证 IPv4/IPv6 双协议栈
|
||||
content_type: task
|
||||
---
|
||||
|
@ -17,7 +14,7 @@ content_type: task
|
|||
<!--
|
||||
This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clusters.
|
||||
-->
|
||||
这篇文章分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
|
||||
本文分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
@ -25,14 +22,14 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
|
|||
* Kubernetes 1.16 or later
|
||||
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
|
||||
* Kubenet network plugin
|
||||
* Kube-proxy running in mode IPVS
|
||||
* [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster
|
||||
-->
|
||||
* Kubernetes 1.16 或更高版本
|
||||
* 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口)
|
||||
* 一个能够支持双协议栈的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/),
|
||||
* 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 Kubernetes 节点
|
||||
提供可路由的 IPv4/IPv6 网络接口)
|
||||
* 一个能够支持双协议栈的
|
||||
[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/),
|
||||
(如 kubenet 或 Calico)。
|
||||
* Kube-proxy 在 IPVS 模式下运行
|
||||
* [启用双协议栈](/zh/docs/concepts/services-networking/dual-stack/) 集群
|
||||
|
||||
<!-- steps -->
|
||||
|
@ -89,7 +86,8 @@ Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name
|
|||
-->
|
||||
### 验证 Pod 寻址
|
||||
|
||||
验证 Pod 已分配了 IPv4 和 IPv6 地址。(用集群中的有效 Pod 替换 Pod 名称。在此示例中, Pod 名称为 pod01)
|
||||
验证 Pod 已分配了 IPv4 和 IPv6 地址。(用集群中的有效 Pod 替换 Pod 名称。
|
||||
在此示例中, Pod 名称为 pod01)
|
||||
|
||||
```shell
|
||||
kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}'
|
||||
|
@ -103,20 +101,22 @@ a00:100::4
|
|||
<!--
|
||||
You can also validate Pod IPs using the Downward API via the `status.podIPs` fieldPath. The following snippet demonstrates how you can expose the Pod IPs via an environment variable called `MY_POD_IPS` within a container.
|
||||
-->
|
||||
您也可以通过 `status.podIPs` 使用 Downward API 验证 Pod IP。以下代码段演示了如何通过容器内称为 `MY_POD_IPS` 的环境变量公开 Pod 的 IP 地址。
|
||||
你也可以通过 `status.podIPs` 使用 Downward API 验证 Pod IP。
|
||||
以下代码段演示了如何通过容器内称为 `MY_POD_IPS` 的环境变量公开 Pod 的 IP 地址。
|
||||
|
||||
```
|
||||
env:
|
||||
- name: MY_POD_IPS
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: status.podIPs
|
||||
```yaml
|
||||
env:
|
||||
- name: MY_POD_IPS
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: status.podIPs
|
||||
```
|
||||
|
||||
<!--
|
||||
The following command prints the value of the `MY_POD_IPS` environment variable from within a container. The value is a comma separated list that corresponds to the Pod's IPv4 and IPv6 addresses.
|
||||
-->
|
||||
使用以下命令打印出容器内部 `MY_POD_IPS` 环境变量的值。该值是一个逗号分隔的列表,与 Pod 的 IPv4 和 IPv6 地址相对应。
|
||||
使用以下命令打印出容器内部 `MY_POD_IPS` 环境变量的值。
|
||||
该值是一个逗号分隔的列表,与 Pod 的 IPv4 和 IPv6 地址相对应。
|
||||
|
||||
```shell
|
||||
kubectl exec -it pod01 -- set | grep MY_POD_IPS
|
||||
|
@ -129,7 +129,9 @@ MY_POD_IPS=10.244.1.4,a00:100::4
|
|||
<!--
|
||||
The Pod's IP addresses will also be written to `/etc/hosts` within a container. The following command executes a cat on `/etc/hosts` on a dual stack Pod. From the output you can verify both the IPv4 and IPv6 IP address for the Pod.
|
||||
-->
|
||||
Pod 的 IP 地址也将被写入容器内的 `/etc/hosts` 文件中。在双栈 Pod 上执行 cat `/etc/hosts` 命令操作。从输出结果中,您可以验证 Pod 的 IPv4 和 IPv6 地址。
|
||||
Pod 的 IP 地址也将被写入容器内的 `/etc/hosts` 文件中。
|
||||
在双栈 Pod 上执行 cat `/etc/hosts` 命令操作。
|
||||
从输出结果中,你可以验证 Pod 的 IPv4 和 IPv6 地址。
|
||||
|
||||
```shell
|
||||
kubectl exec -it pod01 -- cat /etc/hosts
|
||||
|
@ -155,15 +157,17 @@ Create the following Service without the `ipFamily` field set. When this field i
|
|||
## 验证服务
|
||||
|
||||
在不设置 `ipFamily` 字段的情况下创建以下服务。
|
||||
如果未设置此字段,则服务会通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志从第一个配置的范围中获取 IP。
|
||||
如果未设置此字段,则服务会通过 kube-controller-manager 上的
|
||||
`--service-cluster-ip-range` 标志从第一个配置的范围中获取 IP。
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
<!--
|
||||
By viewing the YAML for the Service you can observe that the Service has the `ipFamily` field has set to reflect the address family of the first configured range set via `--service-cluster-ip-range` flag on kube-controller-manager.
|
||||
-->
|
||||
通过查看该服务的 YAML ,您可以观察到该服务的 `ipFamily` 字段已设置为反映通过
|
||||
kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置的第一个配置范围的地址族。
|
||||
通过查看该服务的 YAML ,你可以观察到该服务的 `ipFamily` 字段已被设置。
|
||||
其取值反映的是通过 kube-controller-manager 的 `--service-cluster-ip-range`
|
||||
标志所设置的第一个地址范围的地址族。
|
||||
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
|
@ -207,9 +211,12 @@ Create the following Service with the `ipFamily` field set to `IPv6`.
|
|||
Validate that the Service gets a cluster IP address from the IPv6 address block. You may then validate access to the service via the IP and port.
|
||||
-->
|
||||
验证服务是否是 IPv6 地址块获取集群 IP 地址。
|
||||
然后,您可以通过 IP 和端口验证对服务的访问。
|
||||
然后,你可以通过 IP 和端口验证对服务的访问。
|
||||
|
||||
```shell
|
||||
kubectl get svc -l app=MyApp
|
||||
```
|
||||
```
|
||||
kubectl get svc -l app=MyApp
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service ClusterIP fe80:20d::d06b <none> 80/TCP 9s
|
||||
```
|
||||
|
@ -221,7 +228,8 @@ If the cloud provider supports the provisioning of IPv6 enabled external load ba
|
|||
-->
|
||||
### 创建双协议栈负载均衡服务
|
||||
|
||||
如果云提供商支持配置启用 IPv6 的外部负载均衡器,则将 `ipFamily` 字段设置为 `IPv6` 并将 `type` 字段设置为 `LoadBalancer`的方式创建以下服务
|
||||
如果云提供商支持配置启用 IPv6 的外部负载均衡器,则将 `ipFamily` 字段设置为
|
||||
`IPv6` 并将 `type` 字段设置为 `LoadBalancer` 的方式创建以下服务:
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
|
||||
|
||||
|
@ -229,9 +237,12 @@ If the cloud provider supports the provisioning of IPv6 enabled external load ba
|
|||
Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port.
|
||||
-->
|
||||
验证服务是否从 IPv6 地址块中接收到 `CLUSTER-IP` 地址以及 `EXTERNAL-IP`。
|
||||
然后,您可以通过 IP 和端口验证对服务的访问。
|
||||
然后,你可以通过 IP 和端口验证对服务的访问。
|
||||
|
||||
```shell
|
||||
kubectl get svc -l app=MyApp
|
||||
```
|
||||
```
|
||||
kubectl get svc -l app=MyApp
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s
|
||||
```
|
||||
|
|
|
@ -772,7 +772,22 @@ behavior:
|
|||
selectPolicy: Disabled
|
||||
```
|
||||
|
||||
<!--
|
||||
## Implicit maintenance-mode deactivation
|
||||
|
||||
You can implicitly deactivate the HPA for a target without the
|
||||
need to change the HPA configuration itself. If the target's desired replica count
|
||||
is set to 0, and the HPA's minimum replica count is greater than 0, the HPA
|
||||
stops adjusting the target (and sets the `ScalingActive` Condition on itself
|
||||
to `false`) until you reactivate it by manually adjusting the target's desired
|
||||
replica count or HPA's minimum replica count.
|
||||
-->
|
||||
## 隐式维护状态禁用
|
||||
|
||||
你可以在不必更改 HPA 配置的情况下隐式地为某个目标禁用 HPA。
|
||||
如果此目标的期望副本个数被设置为 0,而 HPA 的最小副本个数大于 0,
|
||||
则 HPA 会停止调整目标(并将其自身的 `ScalingActive` 状况设置为 `false`),
|
||||
直到你通过手动调整目标的期望副本个数或 HPA 的最小副本个数来重新激活。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
@ -782,6 +797,6 @@ behavior:
|
|||
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
-->
|
||||
* 设计文档:[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md)
|
||||
* `kubectl autoscale` 命令: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* `kubectl autoscale` 命令:[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* 使用示例:[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ on general patterns for running stateful applications in Kubernetes.
|
|||
* This tutorial assumes you are familiar with
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
|
||||
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
|
||||
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/),
|
||||
[Services](/docs/concepts/services-networking/service/), and
|
||||
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
* Some familiarity with MySQL helps, but this tutorial aims to present
|
||||
|
@ -490,13 +490,14 @@ running while you force a Pod out of the Ready state.
|
|||
<!--
|
||||
### Break the Readiness Probe
|
||||
|
||||
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
|
||||
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
|
||||
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
|
||||
to make sure the server is up and able to execute queries.
|
||||
-->
|
||||
### 破坏就绪态探测
|
||||
|
||||
`mysql` 容器的[就绪态探测](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
|
||||
`mysql` 容器的
|
||||
[就绪态探测](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
|
||||
运行命令 `mysql -h 127.0.0.1 -e 'SELECT 1'`,以确保服务器已启动并能够执行查询。
|
||||
|
||||
<!--
|
||||
|
|
|
@ -5,143 +5,237 @@ content_type: tutorial
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to run an application using a Kubernetes Deployment object.
|
||||
-->
|
||||
本文介绍通过Kubernetes Deployment对象如何去运行一个应用.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* 创建一个nginx deployment.
|
||||
* 使用kubectl列举关于deployment信息.
|
||||
* 更新deployment.
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
* Create an nginx deployment.
|
||||
* Use kubectl to list information about the deployment.
|
||||
* Update the deployment.
|
||||
-->
|
||||
* 创建一个 nginx Deployment.
|
||||
* 使用 kubectl 列举关于 Deployment 的信息.
|
||||
* 更新 Deployment。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## 创建和探究一个nginx deployment
|
||||
<!--
|
||||
## Creating and exploring an nginx deployment
|
||||
|
||||
你可以通过创建一个Kubernetes Deployment对象来运行一个应用, 可以在一个YAML文件中描述Deployment. 例如, 下面这个YAML文件描述了一个运行nginx:1.7.9 Docker镜像的Deployment:
|
||||
You can run an application by creating a Kubernetes Deployment object, and you
|
||||
can describe a Deployment in a YAML file. For example, this YAML file describes
|
||||
a Deployment that runs the nginx:1.14.2 Docker image:
|
||||
-->
|
||||
## 创建并了解一个 nginx Deployment
|
||||
|
||||
你可以通过创建一个 Kubernetes Deployment 对象来运行一个应用, 且你可以在一个
|
||||
YAML 文件中描述 Deployment。例如, 下面这个 YAML 文件描述了一个运行 nginx:1.7.9
|
||||
Docker 镜像的 Deployment:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Create a Deployment based on the YAML file:
|
||||
-->
|
||||
1. 通过 YAML 文件创建一个 Deployment:
|
||||
|
||||
1. 通过YAML文件创建一个Deployment:
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
```
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
<!--
|
||||
1. Display information about the Deployment:
|
||||
-->
|
||||
2. 显示 Deployment 相关信息:
|
||||
|
||||
1. 展示Deployment相关信息:
|
||||
```shell
|
||||
kubectl describe deployment nginx-deployment
|
||||
```
|
||||
|
||||
kubectl describe deployment nginx-deployment
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于这样:
|
||||
|
||||
user@computer:~/website$ kubectl describe deployment nginx-deployment
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
|
||||
Labels: app=nginx
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=nginx
|
||||
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.7.9
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
|
||||
No events.
|
||||
```
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
|
||||
Labels: app=nginx
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=nginx
|
||||
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.7.9
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
|
||||
No events.
|
||||
```
|
||||
|
||||
1. 列出deployment创建的pods:
|
||||
<!--
|
||||
1. List the Pods created by the deployment:
|
||||
-->
|
||||
3. 列出 Deployment 创建的 Pods:
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
```shell
|
||||
kubectl get pods -l app=nginx
|
||||
```
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
|
||||
nginx-deployment-1771418926-r18az 1/1 Running 0 16h
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于这样:
|
||||
|
||||
1. 展示某一个pod信息:
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
|
||||
nginx-deployment-1771418926-r18az 1/1 Running 0 16h
|
||||
```
|
||||
|
||||
kubectl describe pod <pod-name>
|
||||
<!--
|
||||
1. Display information about a Pod:
|
||||
-->
|
||||
4. 展示某一个 Pod 信息:
|
||||
|
||||
该处 `<pod-name>` 指某一pod的名称.
|
||||
```shell
|
||||
kubectl describe pod <pod-name>
|
||||
```
|
||||
|
||||
## 更新deployment
|
||||
<!--
|
||||
where `<pod-name>` is the name of one of your Pods.
|
||||
-->
|
||||
这里的 `<pod-name>` 是某一 Pod 的名称。
|
||||
|
||||
你可以通过更新一个新的YAML文件来更新deployment. 下面的YAML文件指定该deployment镜像更新为nginx 1.8.
|
||||
<!--
|
||||
## Updating the deployment
|
||||
|
||||
You can update the deployment by applying a new YAML file. This YAML file
|
||||
specifies that the deployment should be updated to use nginx 1.16.1.
|
||||
-->
|
||||
## 更新 Deployment
|
||||
|
||||
你可以通过更新一个新的 YAML 文件来更新 Deployment。下面的 YAML 文件指定该
|
||||
Deployment 镜像更新为 nginx 1.16.1。
|
||||
|
||||
{{< codenew file="application/deployment-update.yaml" >}}
|
||||
|
||||
1. 应用新的YAML:
|
||||
<!--
|
||||
1. Apply the new YAML file:
|
||||
-->
|
||||
1. 应用新的 YAML:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
|
||||
```
|
||||
|
||||
1. 查看该deployment创建的pods以新的名称同时删除旧的pods:
|
||||
<!--
|
||||
1. Watch the deployment create pods with new names and delete the old pods:
|
||||
-->
|
||||
2. 查看该 Deployment 以新的名称创建 Pods 同时删除旧的 Pods:
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
```shell
|
||||
kubectl get pods -l app=nginx
|
||||
```
|
||||
<!--
|
||||
## Scaling the application by increasing the replica count
|
||||
|
||||
## 通过增加副本数来弹缩应用
|
||||
You can increase the number of Pods in your Deployment by applying a new YAML
|
||||
file. This YAML file sets `replicas` to 4, which specifies that the Deployment
|
||||
should have four Pods:
|
||||
-->
|
||||
## 通过增加副本数来扩缩应用
|
||||
|
||||
你可以通过应用新的YAML文件来增加Deployment中pods的数量. 该YAML文件将`replicas`设置为4, 指定该Deployment应有4个pods:
|
||||
你可以通过应用新的 YAML 文件来增加 Deployment 中 Pods 的数量。
|
||||
下面的 YAML 文件将 `replicas` 设置为 4,指定该 Deployment 应有 4 个 Pods:
|
||||
|
||||
{{< codenew file="application/deployment-scale.yaml" >}}
|
||||
|
||||
1. 应用新的YAML文件:
|
||||
<!--
|
||||
1. Apply the new YAML file:
|
||||
-->
|
||||
1. 应用新的 YAML 文件:
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
|
||||
```
|
||||
|
||||
1. 验证Deployment有4个pods:
|
||||
<!--
|
||||
1. Verify that the Deployment has four Pods:
|
||||
-->
|
||||
2. 验证 Deployment 有 4 个 Pods:
|
||||
|
||||
kubectl get pods -l app=nginx
|
||||
```shell
|
||||
kubectl get pods -l app=nginx
|
||||
```
|
||||
|
||||
输出的结果类似于:
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出的结果类似于:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-148880595-4zdqq 1/1 Running 0 25s
|
||||
nginx-deployment-148880595-6zgi1 1/1 Running 0 25s
|
||||
nginx-deployment-148880595-fxcez 1/1 Running 0 2m
|
||||
nginx-deployment-148880595-rwovn 1/1 Running 0 2m
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-148880595-4zdqq 1/1 Running 0 25s
|
||||
nginx-deployment-148880595-6zgi1 1/1 Running 0 25s
|
||||
nginx-deployment-148880595-fxcez 1/1 Running 0 2m
|
||||
nginx-deployment-148880595-rwovn 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
## 删除deployment
|
||||
<!--
|
||||
## Deleting a deployment
|
||||
|
||||
通过名称删除deployment:
|
||||
Delete the deployment by name:
|
||||
-->
|
||||
## 删除 Deployment
|
||||
|
||||
kubectl delete deployment nginx-deployment
|
||||
通过名称删除 Deployment:
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
## ReplicationControllers -- the Old Way
|
||||
|
||||
The preferred way to create a replicated application is to use a Deployment,
|
||||
which in turn uses a ReplicaSet. Before the Deployment and ReplicaSet were
|
||||
added to Kubernetes, replicated applications were configured using a
|
||||
[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
|
||||
-->
|
||||
## ReplicationControllers -- 旧的方式
|
||||
|
||||
创建一个多副本应用首选方法是使用Deployment,反过来使用ReplicaSet. 在Deployment和ReplicaSet加入到Kubernetes之前, 多副本应用通过[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)来配置.
|
||||
|
||||
|
||||
|
||||
创建一个多副本应用首选方法是使用 Deployment,Deployment 内部使用 ReplicaSet。
|
||||
在 Deployment 和 ReplicaSet 被引入到 Kubernetes 之前,多副本应用通过
|
||||
[ReplicationController](/zh/docs/concepts/workloads/controllers/replicationcontroller/)
|
||||
来配置。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* 了解更多 [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
|
||||
-->
|
||||
* 进一步了解 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)。
|
||||
|
||||
|
|
|
@ -39,10 +39,12 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
|
|||
* 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。
|
||||
* 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。
|
||||
* 服务目录需要 Kubernetes 1.7+ 版本。
|
||||
* [安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/),以便将其配置为连接到 Kubernetes v1.7+ 集群。
|
||||
* 要安装服务目录,kubectl 用户必须绑定到 *cluster-admin* 角色。为了确保这是正确的,请运行以下命令:
|
||||
* [安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/),
|
||||
以便将其配置为连接到 Kubernetes v1.7+ 集群。
|
||||
* 要安装服务目录,kubectl 用户必须绑定到 *cluster-admin* 角色。
|
||||
为了确保这是正确的,请运行以下命令:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
|
||||
```
|
||||
|
||||
|
@ -113,9 +115,9 @@ sc uninstall
|
|||
|
||||
<!--
|
||||
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
|
||||
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
|
||||
* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
|
||||
-->
|
||||
* 查看 [服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。
|
||||
* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
|
||||
* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。
|
||||
* 探索 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目。
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue