From 15845b322333caff3ba1fde4de2946cee41ebaa6 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 9 Aug 2020 19:17:48 +0800 Subject: [PATCH] [zh] Tidy up and fix links in tasks section (1/10) --- content/zh/docs/tasks/_index.md | 173 +------ .../tasks/debug-application-cluster/audit.md | 465 +++++++++--------- .../debug-application-introspection.md | 128 +++-- .../debug-cluster.md | 279 ++++++++--- .../debug-pod-replication-controller.md | 163 ++---- .../debug-stateful-set.md | 93 ++-- .../tasks/debug-application-cluster/falco.md | 239 --------- .../troubleshooting.md | 91 ++-- .../zh/docs/tasks/example-task-template.md | 107 ---- 9 files changed, 635 insertions(+), 1103 deletions(-) delete mode 100644 content/zh/docs/tasks/debug-application-cluster/falco.md delete mode 100644 content/zh/docs/tasks/example-task-template.md diff --git a/content/zh/docs/tasks/_index.md b/content/zh/docs/tasks/_index.md index 892ea33b1e..dff8e43aa2 100644 --- a/content/zh/docs/tasks/_index.md +++ b/content/zh/docs/tasks/_index.md @@ -5,188 +5,19 @@ weight: 50 content_type: concept --- -{{< toc >}} - - -Kubernetes 文档这一部分包含的一些页面展示如何去做单个任务。一个任务页面展示了如何执行操作单一的项目，通常是通过给出若干步骤。 - - - - -## Web 用户界面 (Dashboard) - -部署和访问 Dashboard Web 用户界面，以帮助您管理和监控 Kubernetes 集群中的容器化应用程序。 - - - -## 使用 kubectl 命令行 - -下载并设置用于直接管理 Kubernetes 集群的 kubectl 命令行工具。 - - - -## 配置 Pod 和容器 - -执行 Pod 和容器的常见配置任务。 - - - -## 运行应用程序 - -执行常见的应用程序管理任务，例如滚动更新、将信息注入 Pod、以及 Pod 水平自动伸缩。 - - - -## 运行 Job - -使用并行处理方式运行 Job。 - - - -## 访问集群中的应用程序 - -配置负载均衡和端口转发、或者设置防火墙、或者配置 DNS 以访问集群中的应用程序。 - - - -## 监控、日志记录和调试 - -设置监控和日志记录以对集群进行故障排除或者调试容器化应用程序。 - - - -## 访问 Kubernetes API - -了解直接访问 Kubernetes API 的各种方法。 - - - -## 使用 TLS - -配置您的应用程序去信任和使用集群的根证书机构（ CA ）。 - - - -## 管理集群 - -了解管理集群的常见任务。 - - - -## 管理联邦 - -配置集群联邦中的组件。 - - - -## 管理状态应用程序 - -执行管理有状态应用程序的常见任务，包括扩展、删除和调试 StatefulSets。 - - - -## 集群 Daemons - -执行管理 DaemonSet 的常见任务，例如执行滚动更新。 - - - -## 管理 GPU - -配置和调度 NVIDIA GPU 作为集群中节点使用的资源。 - - - -## 管理 HugePage - -配置和调度 HugePage 作为集群中的可调度资源。 - - - - - -## {{% heading "whatsnext" %}} - - -如果您想编写任务页面，请参阅[创建文档提取请求](/docs/home/contribute/create-pull-request/)。 - - +Kubernetes 文档这一部分包含的一些页面展示如何去完成单个任务。 +每个任务页面是一般通过给出若干步骤展示如何执行完成某事。 diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md index 594ba79b27..274bee2ed4 100644 --- a/content/zh/docs/tasks/debug-application-cluster/audit.md +++ b/content/zh/docs/tasks/debug-application-cluster/audit.md @@ -1,12 +1,15 @@ --- +title: 审计 +content_type: concept +--- + {{< feature-state state="beta" >}} @@ -17,7 +20,8 @@ the sequence of activities that have affected system by individual users, admini or other components of the system. It allows cluster administrator to answer the following questions: --> -Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。 +Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录每个用户、管理员 +或系统其他组件影响系统的活动顺序。 它能帮助集群管理员处理以下问题： -[Kube-apiserver][kube-apiserver] 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。 -您可以在 [设计方案][auditing-proposal] 中找到更多详细信息。 -该策略确定记录的内容并且在后端存储记录。当前的后端支持日志文件和 webhook。 +[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。 +该策略确定要记录的内容和用来存储记录的后端。当前的后端支持日志文件和 webhook。 - 每个请求都可以用相关的 "stage" 记录。已知的 stage 有： - `RequestReceived` - 事件的 stage 将在审计处理器接收到请求后，并且在委托给其余处理器之前生成。 - -- `ResponseStarted` - 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时间运行的请求生成（例如 watch）。 - +- `ResponseStarted` - 在响应消息的头部发送后，但是响应消息体发送前。 + 这个阶段仅为长时间运行的请求生成（例如 watch）。 - `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。 - `Panic` - 当 panic 发生时生成。 -{{< note >}} -**注意** 审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。 +{{< note >}} +审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。 此外，内存消耗取决于审计日志记录的配置。 {{< /note >}} @@ -96,10 +95,13 @@ they should include. The audit policy object structure is defined in the compared against the list of rules in order. The first matching rule sets the "audit level" of the event. The known audit levels are: --> -## 审计策略 +## 审计策略 {#audit-policy} -审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。审计策略对象结构在 [`audit.k8s.io` API 组][auditing-api] 中定义。 -处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 [审计级别][auditing-level]。已知的审计级别有： +审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。 +审计策略对象结构定义在 +[`audit.k8s.io` API 组](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go) +处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 +"审计级别"。已知的审计级别有： - `None` - 符合这条规则的日志将不会记录。 -- `Metadata` - 记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。 -- `Request` - 记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。 -- `RequestResponse` - 记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。 +- `Metadata` - 记录请求的元数据（请求的用户、时间戳、资源、动词等等）， + 但是不记录请求或者响应的消息体。 +- `Request` - 记录事件的元数据和请求的消息体，但是不记录响应的消息体。 + 这不适用于非资源类型的请求。 +- `RequestResponse` - 记录事件的元数据，请求和响应的消息体。这不适用于非资源类型的请求。 -您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。 +你可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 `kube-apiserver`。 +如果不设置该标志，则不记录事件。 注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。 以下是一个审计策略文件的示例： @@ -133,10 +138,10 @@ Below is an example audit policy file: -您可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求： +你可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求： ```yaml -# Log all requests at the Metadata level. +# 在 Metadata 级别为所有请求生成日志 apiVersion: audit.k8s.io/v1beta1 kind: Policy rules: @@ -144,10 +149,14 @@ rules: ``` -管理员构建自己的审计配置文件时，应使用 [GCE 使用的审计配置文件][gce-audit-profile] 作为参考。 +管理员构建自己的审计配置文件时，可参考 +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh) +脚本，该脚本生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。 +[]。 -## 审计后端 +## 审计后端 {#audit-backends} -审计后端实现将审计事件导出到外部存储。 -[Kube-apiserver][kube-apiserver] 提供两个后端： +审计后端实现将审计事件导出到外部存储。 `Kube-apiserver` 提供两个后端： - Log 后端，将事件写入到磁盘 - Webhook 后端，将事件发送到外部 API -在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。当前版本的 API 是 [`v1beta1`][auditing-api]。 +在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。 +当前版本的 API 是 +[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go). -{{< note >}} -**注意：** 在 patch 请求的情况下，请求的消息体需要是一个 JSON 串指定 patch 操作，而不是一个完整的 Kubernetes API 对象 JSON 串。 -例如，以下的示例是一个合法的 patch 请求消息体，该请求对应 `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。 +{{< note >}} +在 patch 请求的情况下，请求的消息体需要是一个 JSON 串指定 patch 操作， +而不是一个完整的 Kubernetes API 对象 JSON 串。 +例如，以下的示例是一个合法的 patch 请求消息体，该请求对应 +`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。 ```json [ @@ -204,7 +216,8 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags: --> ### Log 后端 -Log 后端将审计事件写入 JSON 格式的文件。您可以使用以下 [kube-apiserver][kube-apiserver] 标志配置 Log 审计后端： +Log 后端将审计事件写入 JSON 格式的文件。你可以使用以下 `kube-apiserver` 标志配置 +Log 审计后端： +如果 `kube-apiserver` 被配置为运行在 Pod 中，请记得将包含策略文件和日志文件的 +位置用 `hostPath` 挂载到 Pod 中。例如， + +``` +--audit-policy-file=/etc/kubernetes/audit-policy.yaml +--audit-log-path=/var/log/audit.log +``` + +接下来挂载数据卷： + +``` +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/audit.log + name: audit-log + readOnly: false +``` + + +下面是 hostPath 卷本身。 + +``` +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/audit.log + type: FileOrCreate + +``` + -### Webhook 后端 +### Webhook 后端 {#webhook-backend} -Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 [kube-apiserver][kube-apiserver] 相同的API。 -您可以使用如下 kube-apiserver 标志来配置 webhook 审计后端： +Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 `kube-apiserver` 相同的API。 +你可以使用如下 kube-apiserver 标志来配置 webhook 审计后端： -- `--audit-webhook-config-file` webhook 配置文件的路径。Webhook 配置文件实际上是一个 [kubeconfig][kubeconfig]。 +- `--audit-webhook-config-file` webhook 配置文件的路径。Webhook 配置文件实际上是一个 + [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) - `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。 webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。 + +### 批处理 {#batching} -log 和 webhook 后端都支持 batch。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数，请在参数名称中将 `webhook` 替换为 `log`。 -默认情况下，在 `webhook` 中启用 batch，在 `log` 中禁用 batch。同样，默认情况下，在 `webhook` 中启用限制，在 `log` 中禁用限制。 +log 和 webhook 后端都支持批处理。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数， +请在参数名称中将 `webhook` 替换为 `log`。 +默认情况下，在 `webhook` 中启用批处理，在 `log` 中禁用批处理。 +同样，默认情况下，在 `webhook` 中启用带宽限制，在 `log` 中禁用带宽限制。 - `--audit-webhook-mode` 定义缓存策略，可选值如下： - `batch` - 以批处理缓存事件和异步的过程。这是默认值。 - - `blocking` - 阻止 API server 处理每个单独事件的响应。 + - `blocking` - 在 API 服务器处理每个单独事件时，阻塞其响应。 + - `blocking-strict` - 与 `blocking` 相同，不过当审计日志在 RequestReceived 阶段 + 失败时，整个 API 服务请求会失效。 -但是，在大多数情况下，默认参数应该足够了，您不必手动设置它们。您可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。 +但是，在大多数情况下，默认参数应该足够了，你不必手动设置它们。 +你可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。 - `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。 - `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。 -## 多集群配置 +## 多 API 服务器的配置 -如果您通过 [aggregation layer][kube-aggregator] 对 Kubernetes API 进行扩展，那么您也可以为聚合的 apiserver 设置审计日志。 -想要这么做，您需要以上述的格式给聚合的 apiserver 配置参数，并且配置日志管道以采用审计日志。不同的 apiserver 可以配置不同的审计配置和策略。 +如果你通过[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +对 Kubernetes API 进行扩展，那么你也可以为聚合的 API 服务器设置审计日志。 +想要这么做，你需要以上述的格式给聚合的 API 服务器配置参数，并且配置日志管道以采用审计日志。 +不同的 API 服务器可以配置不同的审计配置和策略。 -## 日志选择器示例 +## 日志收集器示例 ### 使用 fluentd 从日志文件中选择并且分发审计日志 -[Fluentd][fluentd] 是一个开源的数据采集器，可以从统一的日志层中采集。 +[Fluentd](https://www.fluentd.org/) 是一个开源的数据采集器，可以从统一的日志层中采集。 在以下示例中，我们将使用 fluentd 来按照命名空间划分审计事件。 -1. 在 kube-apiserver node 节点上安装 [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc] + +{{< note >}} +`fluent-plugin-forest` 和 `fluent-plugin-rewrite-tag-filter` fluentd 的插件。 +你可以在 [fluentd plugin-management](https://docs.fluentd.org/v1.0/articles/plugin-management) +了解安装插件相关的细节。 +{{< /note >}} + + +1. 在 kube-apiserver 节点上安装 [`fluentd`](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd)、 +, `fluent-plugin-forest` 和 `fluent-plugin-rewrite-tag-filter`。 + 1. 为 fluentd 创建一个配置文件 - ```none - $ cat < /etc/fluentd/config - # fluentd conf runs in the same host with kube-apiserver - + ```none + $ cat < /etc/fluentd/config + # fluentd 运行在 kube-apiserver 相同的主机上 + @type tail - # audit log path of kube-apiserver + # kube-apiserver 审计日志路径 path /var/log/audit pos_file /var/log/audit.pos format json time_key time time_format %Y-%m-%dT%H:%M:%S.%N%z tag audit - + - + #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13 type record_transformer enable_ruby namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])} - + - - # route audit according to namespace element in context + + # 根据上下文中的名字空间元素对审计进行路由 @type rewrite_tag_filter rewriterule1 namespace ^(.+) ${tag}.$1 - + - + @type record_transformer remove_keys namespace - + - + @type forest subtype file remove_prefix audit @@ -401,119 +484,124 @@ In this example, we will use fluentd to split audit events by different namespac format json include_time_key true - - ``` + + ``` -1. 启动 fluentd +3. 启动 fluentd - ```shell - $ fluentd -c /etc/fluentd/config -vv - ``` + ```shell + fluentd -c /etc/fluentd/config -vv + ``` -1. 给 kube-apiserver 配置以下参数并启动： +4. 给 kube-apiserver 配置以下参数并启动： - ```shell - --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json - ``` + ```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json + ``` -1. 在 `/var/log/audit-*.log` 文件中检查不同命名空间的审计事件 +5. 在 `/var/log/audit-*.log` 文件中检查不同命名空间的审计事件 ### 使用 logstash 采集并分发 webhook 后端的审计事件 -[Logstash][logstash] 是一个开源的、服务器端的数据处理工具。在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。 +[Logstash](https://www.elastic.co/products/logstash) 是一个开源的、服务器端的数据处理工具。 +在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。 + +1. 安装 [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html) -1. 安装 [logstash][logstash_install_doc] 1. 为 logstash 创建配置文件 - ```none - $ cat < /etc/logstash/config - input{ - http{ - #TODO, figure out a way to use kubeconfig file to authenticate to logstash - #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl - port=>8888 - } - } - filter{ - split{ - # Webhook audit backend sends several events together with EventList - # split each event here. - field=>[items] - # We only need event subelement, remove others. - remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host] - } - mutate{ - rename => {items=>event} - } - } - output{ - file{ - # Audit events from different users will be saved into different files. - path=>"/var/log/kube-audit-%{[event][user][username]}/audit" - } - } - ``` + ```none + cat < /etc/logstash/config + input{ + http{ + #TODO, figure out a way to use kubeconfig file to authenticate to logstash + #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl + port=>8888 + } + } + filter{ + split{ + # Webhook 审计后端与 EventList 一起发送若干事件 + # 对事件进行分割 + field=>[items] + # 我们只需要 event 子元素，去掉其他元素 + remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host] + } + mutate{ + rename => {items=>event} + } + } + output{ + file{ + # 来自不同用户的审计事件会被保存到不同文件中 + path=>"/var/log/kube-audit-%{[event][user][username]}/audit" + } + } + ``` -1. 启动 logstash +3. 启动 logstash - ```shell - $ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/ - ``` + ```shell + bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/ + ``` -1. 为 kube-apiserver webhook 审计后端创建一个 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) +4. 为 kube-apiserver webhook 审计后端创建一个 + [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) - ```none - $ cat < /etc/kubernetes/audit-webhook-kubeconfig - apiVersion: v1 - clusters: - - cluster: - server: http://:8888 - name: logstash - contexts: - - context: - cluster: logstash - user: "" - name: default-context - current-context: default-context - kind: Config - preferences: {} - users: [] - EOF - ``` + ```bash + cat < /etc/kubernetes/audit-webhook-kubeconfig + apiVersion: v1 + clusters: + - cluster: + server: http://:8888 + name: logstash + contexts: + - context: + cluster: logstash + user: "" + name: default-context + current-context: default-context + kind: Config + preferences: {} + users: [] + EOF + ``` -1. 为 kube-apiserver 配置以下参数并启动： +5. 为 kube-apiserver 配置以下参数并启动： - ```shell - --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig - ``` + ```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig + ``` -1. 在 logstash node 节点的 `/var/log/kube-audit-*/audit` 目录中检查审计事件 +6. 在 logstash 节点的 `/var/log/kube-audit-*/audit` 目录中检查审计事件 -注意到，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。 +请注意，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。 +例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。 + +## {{% heading "whatsnext" %}} -## 传统的审计 - -__注意：__ 传统审计已被弃用，自 1.8 版本以后默认禁用，并且将会在 1.12 版本中彻底移除。 -如果想要回退到传统的审计功能，请使用 [kube-apiserver][kube-apiserver] 中 feature gate 的 `AdvancedAuditing` 功能来禁用高级审核功能： - -``` ---feature-gates=AdvancedAuditing=false -``` - - -在传统格式中，每个审计文件条目包含两行： - -1. 请求行包含唯一 ID 以匹配响应和请求元数据，例如源 IP、请求用户、模拟信息和请求的资源等。 -2. 响应行包含与请求行和响应代码相匹配的唯一 ID。 - -``` -2017-03-21T03:57:09.106841886-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" ip="127.0.0.1" method="GET" user="admin" groups="\"system:masters\",\"system:authenticated\"" as="" asgroups="" namespace="default" uri="/api/v1/namespaces/default/pods" -2017-03-21T03:57:09.108403639-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" response="200" -``` - - -### 配置 - -[Kube-apiserver][kube-apiserver] 提供以下选项，负责配置审核日志的位置和处理方式： - - -- `audit-log-path` - 使审计日志指向请求被记录到的文件，'-' 表示标准输出。 -- `audit-log-maxage` - 根据文件名中编码的时间戳指定保留旧审计日志文件的最大天数。 -- `audit-log-maxbackup` - 指定要保留的旧审计日志文件的最大数量。 -- `audit-log-maxsize` - 指定审核日志文件的最大大小（兆字节）。默认为100MB。 - - -如果审核日志文件已经存在，则 Kubernetes 会将新的审核日志附加到该文件。 -否则，Kubernetes 会在您在 `audit-log-path` 中指定的位置创建一个审计日志文件。 -如果审计日志文件超过了您在 `audit-log-maxsize` 中指定的大小，则 Kubernetes 将通过在文件名（在文件扩展名之前）附加当前时间戳并重新创建一个新的审计日志文件来重命名当前日志文件。 -Kubernetes 可能会在创建新的日志文件时删除旧的日志文件; 您可以通过指定 `audit-log-maxbackup` 和 `audit-log-maxage` 选项来配置保留多少文件以及它们的保留时间。 - -[kube-apiserver]: /docs/admin/kube-apiserver -[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md -[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1beta1/types.go -[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 -[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ -[fluentd]: http://www.fluentd.org/ -[fluentd_install_doc]: https://docs.fluentd.org/v/0.12/articles/quickstart#step1-installing-fluentd -[logstash]: https://www.elastic.co/products/logstash -[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html -[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation +* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations) diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md index 6be1e8946f..51e1f353b8 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -17,46 +17,43 @@ your pods. But there are a number of ways to get even more information about you 前面我们介绍了如何使用 `kubectl get pods` 来查询 pod 的简单信息。 除此之外，还有一系列的方法来获取应用的更详细信息。 - - - -## 使用 `kubectl describe pod` 命令获取 pod 详情 +## 使用 `kubectl describe pod` 命令获取 Pod 详情 -与之前的例子类似，我们使用一个 Deployment 来创建两个 pod。 +与之前的例子类似，我们使用一个 Deployment 来创建两个 Pod。 {{< codenew file="application/nginx-with-request.yaml" >}} -使用如下命令创建 deployment： +使用如下命令创建 Deployment： ```shell kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml ``` -```none +``` deployment.apps/nginx-deployment created ``` -使用如下命令查看 pod 状态： +使用如下命令查看 Pod 状态： ```shell kubectl get pods ``` -```none +``` NAME READY STATUS RESTARTS AGE nginx-deployment-1006230814-6winp 1/1 Running 0 11s nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s @@ -65,13 +62,13 @@ nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s -我们可以使用 `kubectl describe pod` 命令来查询每个 pod 的更多信息，比如： +我们可以使用 `kubectl describe pod` 命令来查询每个 Pod 的更多信息，比如： ```shell kubectl describe pod nginx-deployment-1006230814-6winp ``` -```none +``` Name: nginx-deployment-1006230814-6winp Namespace: default Node: kubernetes-node-wul5/10.240.0.9 @@ -130,34 +127,37 @@ Events: Here you can see configuration information about the container(s) and Pod (labels, resource requirements, etc.), as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.). --> -这里可以看到容器和 pod 的 label、资源需求等配置信息，还可以看到状态、就绪状态、重启次数、事件等状态信息。 +这里可以看到容器和 Pod 的标签、资源需求等配置信息，还可以看到状态、就绪态、 +重启次数、事件等状态信息。 -容器状态包括 Waiting、Running 和 Terminated。 -根据状态的不同，将提供额外的信息——在这里您可以看到，对于处于运行状态的容器，系统会告诉您容器的启动时间。 +容器状态是 Waiting、Running 和 Terminated 之一。 +根据状态的不同，还有对应的额外的信息 —— 在这里你可以看到， +对于处于运行状态的容器，系统会告诉你容器的启动时间。 -Ready 指示是否通过了最后一个就绪探测。 -(在本例中，容器没有配置就绪探测；如果没有配置就绪探测，则假定容器已经就绪。) +Ready 指示是否通过了最后一个就绪态探测。 +(在本例中，容器没有配置就绪态探测；如果没有配置就绪态探测，则假定容器已经就绪。) -Restart Count 告诉您容器已重启的次数； -这些信息对于定位配置了“always”重启策略的容器持续崩溃问题非常有用。 +Restart Count 告诉你容器已重启的次数； +这些信息对于定位配置了 “Always” 重启策略的容器持续崩溃问题非常有用。 -目前，唯一与 Pod 有关的状态是就绪状态，这表明 Pod 能够为请求提供服务，并且应该添加到相应服务的负载平衡池中。 +目前，唯一与 Pod 有关的状态是 Ready 状况，该状况表明 Pod 能够为请求提供服务， +并且应该添加到相应服务的负载均衡池中。 -最后，您将看到与 Pod 相关的近期事件。 -系统通过指示第一次和最后一次看到它以及看到它的次数来压缩多个相同的事件。 -“From”表示记录事件的组件， -“SubobjectPath”告诉您引用了哪个对象(例如pod中的容器)， -“Reason”和“Message”告诉您发生了什么。 - +最后，你还可以看到与 Pod 相关的近期事件。 +系统通过指示第一次和最后一次看到事件以及看到该事件的次数来压缩多个相同的事件。 +“From” 标明记录事件的组件， +“SubobjectPath” 告诉你引用了哪个对象（例如 Pod 中的容器）， +“Reason” 和 “Message” 告诉你发生了什么。 -## 例子: 调试 Pending Pods - -一个常见的场景是，当你创建了一个 Pod，但是他没有被调度到任何一个 node，可以使用 event 来调试。 -比如说，这个 Pod 需求的资源比较多，没有任何一个 node 能够满足，或者它指定了一个标签，没有 node 被匹配到。 -假如，我们创建之前的 Deployment 时指定副本数是5（不再是2），并且需求 600 millicore（不再是 500）， -对于一个4个节点的集群并且每个节点只有1个CPU。 -这个情况下，至少有一个 Pod 不能被调度。 -（需要注意的是，其他集群组件，比如 fluentd、skydns等等会在每个 node 上运行， -如果我们需求 1000 millicore，那么将不会有 Pod 会被调度。） +## 例子: 调试 Pending 状态的 Pod + +可以使用事件来调试的一个常见的场景是，你创建 Pod 无法被调度到任何节点。 +比如，Pod 请求的资源比较多，没有任何一个节点能够满足，或者它指定了一个标签，没有节点可匹配。 +假定我们创建之前的 Deployment 时指定副本数是 5（不再是 2），并且请求 600 毫核（不再是 500）， +对于一个 4 个节点的集群，若每个节点只有 1 个 CPU，这时至少有一个 Pod 不能被调度。 +（需要注意的是，其他集群插件 Pod，比如 fluentd、skydns 等等会在每个节点上运行， +如果我们需求 1000 毫核，将不会有 Pod 会被调度。） ```shell kubectl get pods ``` -```none +``` NAME READY STATUS RESTARTS AGE nginx-deployment-1006230814-6winp 1/1 Running 0 7m nginx-deployment-1006230814-fmgu3 1/1 Running 0 7m @@ -211,13 +208,14 @@ nginx-deployment-1370807587-fz9sd 0/1 Pending 0 1m -为了查找 Pod nginx-deployment-1370807587-fz9sd 没有运行的原因，我们可以使用 `kubectl describe pod` 命令查询处理 pending 状态的 Pod： +为了查找 Pod nginx-deployment-1370807587-fz9sd 没有运行的原因，我们可以使用 +`kubectl describe pod` 命令描述 Pod，查看其事件： ```shell kubectl describe pod nginx-deployment-1370807587-fz9sd ``` -```none +``` Name: nginx-deployment-1370807587-fz9sd Namespace: default Node: / @@ -256,13 +254,13 @@ Here you can see the event generated by the scheduler saying that the Pod failed The message tells us that there were not enough resources for the Pod on any of the nodes. --> 这里你可以看到由调度器记录的事件，它表明了 Pod 不能被调度的原因是 `FailedScheduling`（也可能是其他值）。 -这个信息表明，没有任何 node 拥有足够多的资源。 +其 message 部分表明没有任何节点拥有足够多的资源。 -要纠正这种情况，可以使用“kubectl scale”更新部署，以指定四个或更少的副本。 +要纠正这种情况，可以使用 `kubectl scale` 更新 Deployment，以指定 4 个或更少的副本。 (或者你可以让 Pod 继续保持这个状态，这是无害的。) -与您在“kubectl describe pod”结尾处看到的一样，这些事件都将保存在 etcd 中，并提供关于集群中正在发生的事情的高级信息。 +你在 `kubectl describe pod` 结尾处看到的事件都保存在 etcd 中， +并提供关于集群中正在发生的事情的高级信息。 如果需要列出所有事件，可使用命令： ```shell @@ -282,9 +281,9 @@ but you have to remember that events are namespaced. This means that if you're interested in events for some namespaced object (e.g. what happened with Pods in namespace `my-namespace`) you need to explicitly provide a namespace to the command: --> -但是，需要注意的是，事件是按照 namespace 分组的。 -如果你对些些 namespace 下的对象感兴趣（比如查看 namespace `my-namespace` 下的 Pod 事件）, -你需要显式的在命令行中指定 namespace： +但是，需要注意的是，事件是区分名字空间的。 +如果你对某些名字空间域的对象（比如 `my-namespace` 名字下的 Pod）的事件感兴趣, +你需要显式地在命令行中指定名字空间： ```shell kubectl get events --namespace=my-namespace @@ -293,7 +292,7 @@ kubectl get events --namespace=my-namespace -查看所有 namespace 的事件，可使用 `--all-namespaces` 参数： +查看所有 namespace 的事件，可使用 `--all-namespaces` 参数。 -除了 `kubectl describe pod` 以外，另一种获取 Pod 额外信息（超越 `kubectl get pod`）的方法是给 `kubectl get pod` 增加 `-o yaml` 输出格式参数。 -这将以YAML格式为您提供比“kubectl describe pod”更多的信息——实际上是系统拥有的关于pod的所有信息。 -在这里，您将看到注释(没有标签限制的键值元数据，由Kubernetes系统组件在内部使用)、重启策略、端口和卷。 +除了 `kubectl describe pod` 以外，另一种获取 Pod 额外信息（除了 `kubectl get pod`）的方法 +是给 `kubectl get pod` 增加 `-o yaml` 输出格式参数。 +该命令将以 YAML 格式为你提供比 `kubectl describe pod` 更多的信息 —— 实际上是系统拥有的关于 Pod 的所有信息。 +在这里，你将看到注解（没有标签限制的键值元数据，由 Kubernetes 系统组件在内部使用）、 +重启策略、端口和卷等。 ```shell kubectl get pod nginx-deployment-1006230814-6winp -o yaml @@ -382,10 +383,7 @@ status: -## 例子: 调试 down/unreachable node - -有时候，在调试时，查看节点的状态是很有用的——例如，因为您已经注意到节点上运行的 Pod 的奇怪行为， +## 示例：调试宕机或无法联系的节点 + +有时候，在调试时，查看节点的状态是很有用的 —— 例如，因为你已经注意到节点上运行的 Pod 的奇怪行为， 或者想了解为什么 Pod 不会调度到节点上。 -与Pods一样，您可以使用 `kubectl describe node` 和 `kubectl get node -o yaml` 来查询节点的详细信息。 -例如，如果某个节点关闭(与网络断开连接，或者 kubelet 挂掉，无法重新启动，等等)，您将看到以下情况。 -请注意显示节点未就绪的事件，也请注意 pod 不再运行(它们在5分钟未就绪状态后被驱逐)。 +与 Pod 一样，你可以使用 `kubectl describe node` 和 `kubectl get node -o yaml` 来查询节点的详细信息。 +例如，如果某个节点宕机（与网络断开连接，或者 kubelet 挂掉无法重新启动等等），你将看到以下情况。 +请注意显示节点未就绪的事件，也请注意 Pod 不再运行(它们在5分钟未就绪状态后被驱逐)。 ```shell kubectl get nodes ``` -```none +``` NAME STATUS ROLES AGE VERSION kubernetes-node-861h NotReady 1h v1.13.0 kubernetes-node-bols Ready 1h v1.13.0 @@ -518,11 +518,8 @@ status: systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E ``` - - ## {{% heading "whatsnext" %}} - @@ -536,11 +533,10 @@ Learn about additional debugging tools, including: * [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/) --> -* [日志](/docs/concepts/cluster-administration/logging/) -* [监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) -* [使用 `exec` 进入容器](/docs/tasks/debug-application-cluster/get-shell-running-container/) -* [使用代理连接容器](/docs/tasks/extend-kubernetes/http-proxy-access-api/) -* [使用端口转发连接容器](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* [使用 crictl 检查节点](/docs/tasks/debug-application-cluster/crictl/) - +* [日志](/zh/docs/concepts/cluster-administration/logging/) +* [监控](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +* [使用 `exec` 进入容器](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/) +* [使用代理连接容器](/zh/docs/tasks/extend-kubernetes/http-proxy-access-api/) +* [使用端口转发连接容器](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* [使用 crictl 检查节点](/zh/docs/tasks/debug-application-cluster/crictl/) diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md index 548600633e..0735ed6bd6 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md @@ -1,14 +1,39 @@ --- title: 集群故障排查 +content_type: concept --- + + + + 本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。 -对于应用的调试，请参阅[应用故障排查指南](/cn/docs/tasks/debug-application-cluster/debug-application)。 -你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多的信息。 +对于应用的调试，请参阅[应用故障排查指南](/zh/docs/tasks/debug-application-cluster/debug-application/)。 +你也可以访问[故障排查](/zh/docs/tasks/debug-application-cluster/troubleshooting/) +来获取更多的信息。 -## 显示出集群的节点列表 + -调试的第一步是查看所有的节点是否都正确的注册。 + +## 列举集群节点 + +调试的第一步是查看所有的节点是否都已正确注册。 运行 @@ -16,99 +41,211 @@ title: 集群故障排查 kubectl get nodes ``` -接下来，验证你的所有节点都能够显示出来，并且都处于`Ready`状态。 + +验证你所希望看见的所有节点都能够显示出来，并且都处于 `Ready` 状态。 -现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。 -(注意，对于基于systemd的系统，你可能需要使用`journalctl`) +为了了解你的集群的总体健康状况详情，你可以运行： +```shell +kubectl cluster-info dump +``` + +## 查看日志 + +到这里，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关日志文件所在的位置。 +（注意，对于基于 systemd 的系统，你可能需要使用`journalctl`）。 + + +### 主控节点 +* `/var/log/kube-apiserver.log` - API 服务器, 提供API服务 +* `/var/log/kube-scheduler.log` - 调度器, 负责产生调度决策 +* `/var/log/kube-controller-manager.log` - 管理副本控制器的控制器 + + -## 集群故障模式的概述 +### 工作节点 -下面是一个不完整的列表，列举了一些可能出错的场景，以及通过调整集群配置来解决相关问题的方法。 +* `/var/log/kubelet.log` - `kubelet`，负责在节点运行容器 +* `/var/log/kube-proxy.log` - `kube-proxy`, 负责服务的负载均衡 -根本原因： - - VM(s)关机 + +## 集群故障模式的一般性概述 + +下面是一个不完整的列表，列举了一些可能的出错场景，以及通过调整集群配置来解决相关问题的方法。 + + +### 根本原因 + + - VM(s) 关机 - 集群之间，或者集群和用户之间网络分裂 - - Kubernetes软件本身崩溃了 - - 数据丢失或者持久化存储不可用(如:GCE PD 或 AWS EBS卷) - - 操作错误，如：Kubernetes或者应用程序配置错误 + - Kubernetes 软件本身崩溃 + - 数据丢失或者持久化存储不可用（如：GCE PD 或 AWS EBS 卷） + - 操作错误，如：Kubernetes 或者应用程序配置错误 -具体情况: + +### 具体情况: -缓解措施: +- API 服务器所在的 VM 关机或者 API 服务器崩溃 + - 结果 + - 不能停止、更新或者启动新的 Pod、服务或副本控制器 + - 现有的 Pod 和服务在不依赖 Kubernetes API 的情况下应该能继续正常工作 +- API 服务器的后端存储丢失 + - 结果 + - API 服务器应该不能启动 + - kubelet 将不能访问 API 服务器，但是能够继续运行之前的 Pod 和提供相同的服务代理 + - 在 API 服务器重启之前，需要手动恢复或者重建 API 服务器的状态 + +- Kubernetes 服务组件（节点控制器、副本控制器管理器、调度器等）所在的 VM 关机或者崩溃 + - 当前，这些控制器是和 API 服务器在一起运行的，它们不可用的现象是与 API 服务器类似的 + - 将来，这些控制器也会复制为多份，并且可能不在运行于同一节点上 + - 它们没有自己的持久状态 +- 单个节点（VM 或者物理机）关机 + - 结果 + - 此节点上的所有 Pod 都停止运行 +- 网络分裂 + - 结果 + - 分区 A 认为分区 B 中所有的节点都已宕机；分区 B 认为 API 服务器宕机 + （假定主控节点所在的 VM 位于分区 A 内)。 + +- kubelet 软件故障 + - 结果 + - 崩溃的 kubelet 就不能在其所在的节点上启动新的 Pod + - kubelet 可能删掉 Pod 或者不删 + - 节点被标识为非健康态 + - 副本控制器会在其它的节点上启动新的 Pod +- 集群操作错误 + - 结果 + - 丢失 Pod 或服务等等 + - 丢失 API 服务器的后端存储 + - 用户无法读取API + - 等等 -- 措施：对于IaaS上的VMs，使用IaaS的自动VM重启功能 - - 缓解：Apiserver VM关机或apiserver崩溃 - - 缓解：Kubernetes服务组件所在的VM关机或崩溃 + +### 缓解措施： + +- 措施：对于 IaaS 上的 VMs，使用 IaaS 的自动 VM 重启功能 + - 缓解：API 服务器 VM 关机或 API 服务器崩溃 + - 缓解：Kubernetes 服务组件所在的 VM 关机或崩溃 + +- 措施: 对于运行 API 服务器和 etcd 的 VM，使用 IaaS 提供的可靠的存储（例如 GCE PD 或者 AWS EBS 卷） + - 缓解：API 服务器后端存储的丢失 + +- 措施：使用[高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)的配置 + - 缓解：主控节点 VM 关机或者主控节点组件（调度器、API 服务器、控制器管理器）崩馈 - 将容许一个或多个节点或组件同时出现故障 - - 缓解：apiserver后端存储(例如etcd的数据目录)丢失 - - 假定你使用了集群化的etcd。 + - 缓解：API 服务器后端存储（例如 etcd 的数据目录）丢失 + - 假定你使用了高可用的 etcd 配置 -- 措施：定期的对apiserver的PDs/EBS卷进行快照 - - 缓解：apiserver后端存储丢失 + +- 措施：定期对 API 服务器的 PDs/EBS 卷执行快照操作 + - 缓解：API 服务器后端存储丢失 - 缓解：一些操作错误的场景 - - 缓解：一些Kubernetes软件本身故障的场景 + - 缓解：一些 Kubernetes 软件本身故障的场景 -- 措施：在pods的前面使用副本控制器或服务 +- 措施：在 Pod 的前面使用副本控制器或服务 - 缓解：节点关机 - - 缓解：Kubelet软件故障 + - 缓解：kubelet 软件故障 - 措施：应用（容器）设计成容许异常重启 - 缓解：节点关机 - - 缓解：Kubelet软件故障 + - 缓解：kubelet 软件故障 -- 措施：[多个独立的集群](/docs/admin/multi-cluster)(并且避免一次性地对所有的集群进行有风险性的修改) - - 缓解：以上列出的所有情况 diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 671f7cf67a..8f2721eb7a 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -1,16 +1,12 @@ --- -reviewers: -- bprashanth -title: 调试 Pods 和 Replication Controllers +title: 调试 Pods 和 ReplicationControllers content_type: task --- @@ -18,37 +14,31 @@ content_type: task -此页面告诉您如何调试 Pod 和 ReplicationController。 - +此页面展示如何调试 Pod 和 ReplicationController。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* 您应该先熟悉 - [Pods](/docs/concepts/workloads/pods/pod/) 和 [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。 - - +* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/pod/) 和 + [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。 -## 调试 Pod - +## 调试 Pod {#debugging-pods} -调试一个 pod 的第一步是观察它。使用下面的命令检查这个 pod 的当前状态和最近事件： +调试一个 pod 的第一步是观察它。使用下面的命令检查 Pod 的当前状态和最近事件： ```shell kubectl describe pods ${POD_NAME} @@ -60,14 +50,13 @@ there been recent restarts? Continue debugging depending on the state of the pods. --> -看看 pod 中的容器的状态。他们都是 `Running` 吗？有最近重启了吗？ +看看 Pod 中的容器的状态。它们都是 `Running` 吗？最近有重启吗？ -根据 pod 的状态继续调试。 +根据 Pod 的状态继续调试。 -### 我的 Pod 卡在 Pending -如果一个 pod 被卡在 `Pending` 状态，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足而 -阻止调度。 看看上面的命令 `kubectl describe ...` 的输出。调度器的消息中应该会包含无法调度 Pod 的原因。 +### 我的 Pod 停滞在 Pending 状态 + +如果 Pod 被卡在 `Pending` 状态，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足而 +导致无法调度。 查看上面的命令 `kubectl describe ...` 的输出。调度器的消息中应该会包含无法调度 Pod 的原因。 原因包括： -#### 资源不足 - -您可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情： +#### 资源不足 -* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。 +你可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情： -* [终止不需要的 pod](/docs/user-guide/pods/single-container/#deleting_a_pod) - 为 pending 中的 pod 提供空间。 +* [添加更多节点](/zh/docs/tasks/administer-cluster/cluster-management/) 到集群。 -* 检查该 pod 是否不大于您的节点。例如，如果全部节点具有 `cpu:1` 容量，那么具有 `cpu: 1.1` 请求的 pod 永远不会被调度。 +* [终止不需要的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) + 为 Pending 状态的 Pod 提供空间。 - 您可以使用 `kubectl get nodes -o ` 命令来检查节点容量。 - 下面是一些能够提取必要信息的命令示例： +* 检查该 Pod 是否不大于你的节点。例如，如果全部节点具有 `cpu:1` 容量，那么具有 + 请求为 `cpu: 1.1` 的 Pod 永远不会被调度。 - ```shell - kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:' - kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}' - ``` + 你可以使用 `kubectl get nodes -o ` 命令来检查节点容量。 + 下面是一些能够提取必要信息的命令示例： + + ```shell + kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:' + kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}' + ``` - 可以考虑配置 [资源配额](/docs/concepts/policy/resource-quotas/) 来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。 + 可以考虑配置[资源配额](/zh/docs/concepts/policy/resource-quotas/) 来限制可耗用的资源总量。 + 如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。 -#### 使用hostPort - -当你将一个 pod 绑定到一个 `hostPort` 时，这个 pod 能被调度的位置数量有限。 -在大多数情况下，`hostPort` 是不必要的; 尝试使用服务对象来暴露您的 pod。 +#### 使用hostPort + +当你将一个 Pod 绑定到某 `hostPort` 时，这个 Pod 能被调度的位置数量有限。 +在大多数情况下，`hostPort` 是不必要的; 尝试使用服务对象来暴露你的 Pod。 如果你需要 `hostPort`，那么你可以调度的 Pod 数量不能超过集群的节点个数。 -### 我的 Pod 一直在 Waiting - -如果一个 pod 被卡在 `Waiting` 状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。 -再次，来自 `kubectl describe ...` 的内容应该是可以提供信息的。 -最常见的原因 `Waiting` 的 pod 是无法拉取镜像。有三件事要检查： +### 我的 Pod 一直在 Waiting -* 确保您的镜像的名称正确。 -* 您是否将镜像推送到存储库？ -* 在您的机器上手动运行 `docker pull `，看看是否可以拉取镜像。 +如果 Pod 一直停滞在 `Waiting` 状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。 +再次，来自 `kubectl describe ...` 的内容应该是可以是很有用的。 +最常见的原因 `Waiting` 的 Pod 是无法拉取镜像。有三件事要检查： +* 确保你的镜像的名称正确。 +* 你是否将镜像推送到存储库？ +* 在你的机器上手动运行 `docker pull `，看看是否可以拉取镜像。 -### 我的 Pod 一直 Crashing 或者有别的不健康状态 +### 我的 Pod 一直 Crashing 或者其他不健康状态 -首先，查看当前容器的日志： - - $ kubectl logs ${POD_NAME} ${CONTAINER_NAME} - -如果您的容器先前已崩溃，则可以访问上一个容器的崩溃日志： - - $ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} - -或者，您可以使用 `exec` 在该容器内运行命令： - - $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} - - - -{{< note >}} -`-c ${CONTAINER_NAME}` 是可选的，对于只包含一个容器的 pod 可以省略。 -{{< /note >}} - - -例如，要查看正在运行的Cassandra pod的日志，可以运行： - -```shell -kubectl exec cassandra -- cat /var/log/cassandra/system.log -``` - - -如果这些方法都不起作用，您可以找到该运行 pod 所在的主机并 SSH 到该主机。 +一旦 Pod 已经被调度，就可以依据 +[调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/) +展开进一步的调试工作。 -## 调试 Replication Controller - -Replication Controller 相当简单。他们只会能或不能创建 pod。如果他们无法创建 pod，那么请参考 -[上面的说明](#debugging_pods) 来调试你的pod。 +## 调试 Replication Controller + +Replication Controller 相当简单。它们或者能或者不能创建 Pod。如果它们无法创建 Pod， +请参考[上面的说明](#debugging_pods) 来调试你的 Pod。 -您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。 - +你也可以使用 `kubectl describe rc ${CONTROLLER_NAME}` 来检查和副本控制器有关的事件。 diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md index e6ad084295..7131a23a52 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -4,77 +4,54 @@ content_type: task --- - -此任务展示如何调试StatefulSet。 - - + +此任务展示如何调试 StatefulSet。 ## {{% heading "prerequisites" %}} - - -* 你需要有一个Kubernetes集群，通过必要的配置使kubectl命令行工具与您的集群进行通信。 -* 你应该有一个运行中的StatefulSet，以便用于调试。 - - + +* 你需要有一个 Kubernetes 集群，已配置好的 kubectl 命令行工具与你的集群进行通信。 +* 你应该有一个运行中的 StatefulSet，以便用于调试。 -## 调试StatefulSet + +## 调试 StatefulSet {#debuggin-a-statefulset} + +StatefulSet 在创建 Pod 时为其设置了 `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.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.alpha.kubernetes.io/initialized="true" --overwrite -``` - - + +如果你发现列出的任何 Pod 长时间处于 `Unknown` 或 `Terminating` 状态，请参阅 +[删除 StatefulSet Pods](/zh/docs/tasks/manage-stateful-set/delete-pods/) +了解如何处理它们的说明。 +你可以参考[调试 Pods](/zh/docs/tasks/debug-application-cluster/debug-application/) +来调试 StatefulSet 中的各个 Pod。 ## {{% heading "whatsnext" %}} - -点击链接[调试init-container](/docs/tasks/troubleshoot/debug-init-containers/)，了解更多信息。 - - - + +* 进一步了解如何[调试 Init 容器](/zh/docs/tasks/debug-application-cluster/debug-init-containers/) diff --git a/content/zh/docs/tasks/debug-application-cluster/falco.md b/content/zh/docs/tasks/debug-application-cluster/falco.md deleted file mode 100644 index 585d044677..0000000000 --- a/content/zh/docs/tasks/debug-application-cluster/falco.md +++ /dev/null @@ -1,239 +0,0 @@ ---- -reviewers: -- soltysh -- sttts -- ericchiang -content_type: concept -title: 使用 Falco 审计 ---- - - - -### 使用 Falco 采集审计事件 - - -[Falco](https://falco.org/)是一个开源项目，用于为云原生平台提供入侵和异常检测。本节介绍如何设置 Falco、如何将审计事件发送到 Falco 公开的 Kubernetes Audit 端点、以及 Falco 如何应用一组规则来自动检测可疑行为。 - - - - - - -#### 安装 Falco - - -使用以下方法安装 Falco ： - - -- [独立安装 Falco][falco_installation] -- [Kubernetes DaemonSet][falco_installation] -- [Falco Helm Chart][falco_helm_chart] - - -安装完成 Falco 后，请确保将其配置为公开 Audit Webhook。为此，请使用以下配置： - -```yaml -webserver: - enabled: true - listen_port: 8765 - k8s_audit_endpoint: /k8s_audit - ssl_enabled: false - ssl_certificate: /etc/falco/falco.pem -``` - - -此配置通常位于 `/etc/falco/falco.yaml` 文件中。如果 Falco 作为 Kubernetes DaemonSet 安装，请编辑 `falco-config` ConfigMap 并添加此配置。 - -#### 配置 Kubernetes 审计 - - -1. 为 [kube-apiserver][kube-apiserver] webhook 审计后端创建一个[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)文件。 - - cat < /etc/kubernetes/audit-webhook-kubeconfig - apiVersion: v1 - kind: Config - clusters: - - cluster: - server: http://:8765/k8s_audit - name: falco - contexts: - - context: - cluster: falco - user: "" - name: default-context - current-context: default-context - preferences: {} - users: [] - EOF - -2. 使用以下选项启动 [kube-apiserver][kube-apiserver]： - - ```shell - --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig - ``` - -#### 审计规则 - - - -专门用于 Kubernetes 审计事件的规则可以在 [k8s_audit_rules.yaml][falco_k8s_audit_rules] 中找到。如果审计规则是作为本机软件包安装或使用官方 Docker 镜像安装的，则 Falco 会将规则文件复制到 `/etc/falco/` 中以便使用。 - -共有三类规则。 - -第一类规则用于查找可疑或异常活动，例如： - - --未经授权或匿名用户的任何活动。 --创建使用未知或不允许的镜像的 pod。 --创建特权 Pod，从主机安装敏感文件系统的 Pod 或使用主机网络的 Pod。 --创建 NodePort 服务。 --创建包含私有证书（例如密码和云提供商 secrets ）的 ConfigMap。 --在正在运行的 Pod 上附加或执行命令。 --在一组允许的名称空间之外创建一个名称空间。 --在 kube-system 或 kube-public 命名空间中创建 pod 或服务帐户。 --尝试修改或删除系统 ClusterRole。 --创建一个 ClusterRoleBinding 到 cluster-admin 角色。 --创建 ClusterRole 时在动词或资源中使用通配符。 例如，过度赋权。 --创建具有写权限的 ClusterRole 或可以在 Pod 上执行命令的 ClusterRole。 - - -第二类规则跟踪正在创建或销毁的资源，包括： - -- Deployments -- Services -- ConfigMaps -- Namespaces -- Service accounts -- Role/ClusterRoles -- Role/ClusterRoleBindings - - - -最后一类规则仅负责显示 Falco 收到的所有审核事件。默认情况下，此规则是禁用的，因为它可能会很吵。 - -有关更多详细信息，请参阅 Falco 文档中的[Kubernetes审计事件][falco_ka_docs]。 - - -[kube-apiserver]: /docs/admin/kube-apiserver -[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md -[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go -[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 -[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ -[fluentd]: http://www.fluentd.org/ -[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd -[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management -[logstash]: https://www.elastic.co/products/logstash -[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html -[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation -[falco_website]: https://www.falco.org -[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml -[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit -[falco_installation]: https://falco.org/docs/installation -[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco - - diff --git a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md index 396e7ffc59..4b7ff235ff 100644 --- a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md +++ b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md @@ -7,13 +7,11 @@ title: 排错 --- @@ -22,26 +20,21 @@ title: Troubleshooting Sometimes things go wrong. This guide is aimed at making them right. It has two sections: --> - -有时候事情会出错。本指南旨在正确解决这些问题。它包含两个部分： +有时候事情会出错。本指南旨在解决这些问题。它包含两个部分： - * [应用排错](/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。 - * [集群排错](/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。 +* [应用排错](/zh/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。 +* [集群排错](/zh/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。 - -您也应该查看所用[版本](https://github.com/kubernetes/kubernetes/releases)的已知问题。 - - - +你也应该查看所用[发行版本](https://github.com/kubernetes/kubernetes/releases)的已知问题。 @@ -51,10 +44,9 @@ you're using. If your problem isn't answered by any of the guides above, there are variety of ways for you to get help from the Kubernetes team. --> +## 获取帮助 {#getting-help} -## 获取帮助 - -如果您的问题在上述指南中没有得到答案，您还有另外几种方式从 Kubernetes 团队获得帮助。 +如果你的问题在上述指南中没有得到答案，你还有另外几种方式从 Kubernetes 团队获得帮助。 - ### 提问 -网站上的文档针对回答各类问题进行了结构化组织和分类。 -[概念](/docs/concepts/)部分解释了 Kubernetes 体系结构以及每个组件的工作方式，[安装](/docs/setup/)部分提供了入门的实用说明。 -[任务](/docs/tasks/)部分展示了如何完成常用任务，[入门](/docs/tutorials/)部分则是对现实世界、特定行业或端到端开发场景的更全面的演练。 -[参考](/docs/reference/)部分提供了详细的 [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档和命令行 (CLI) 接口，例如[`kubectl`](/docs/user-guide/kubectl-overview/)。 +本网站上的文档针对回答各类问题进行了结构化组织和分类。 +[概念](/zh/docs/concepts/)部分解释 Kubernetes 体系结构以及每个组件的工作方式， +[安装](/zh/docs/setup/)部分提供了安装的实用说明。 +[任务](/zh/docs/tasks/)部分展示了如何完成常用任务， +[教程](/zh/docs/tutorials/)部分则提供对现实世界、特定行业或端到端开发场景的更全面的演练。 +[参考](/zh/docs/reference/)部分提供了详细的 +[Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档 +和命令行 (CLI) 接口的文档，例如[`kubectl`](/zh/docs/reference/kubectl/overview/)。 +你还在 StackOverflow 上查找相关主题： -您还可以找到堆栈溢出相关的主题： - - * [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes) - * [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine) +* [Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes) +* [Google Kubernetes Engine](https://stackoverflow.com/questions/tagged/google-container-engine) - ## 求救！我的问题还没有解决！我需要立即得到帮助！ -### 堆栈溢出 - - +### StackOverflow {#stack-overflow} -社区中的其他人可能已经问过和您类似的问题，这或许能帮助解决您的问题。 -Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](http://stackoverflow.com/questions/tagged/kubernetes)。 -如果现有的问题对您没有帮助，请[问一个新问题](http://stackoverflow.com/questions/ask?tags=kubernetes)! +社区中的其他人可能已经问过和你类似的问题，也可能能够帮助解决你的问题。 +Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](https://stackoverflow.com/questions/tagged/kubernetes)。 +如果现有的问题对你没有帮助，请[问一个新问题](https://stackoverflow.com/questions/ask?tags=kubernetes)! - ### Slack Kubernetes 团队在 Slack 中建有 `#kubernetes-users` 频道。 -您可以[在这里](https://kubernetes.slack.com)参加与 Kubernetes 团队的讨论。 -Slack 需要注册，但 Kubernetes 团队公开邀请任何人[在这里](http://slack.kubernetes.io)注册。 -欢迎您随时来问任何问题。 +你可以[在这里](https://kubernetes.slack.com)参与 Kubernetes 团队的讨论。 +Slack 需要注册，但 Kubernetes 团队公开邀请任何人[在这里](https://slack.kubernetes.io)注册。 +欢迎你随时来问任何问题。 - -一旦注册完成，您就可以浏览各种感兴趣的频道列表。 -例如，Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。作为另一个例子，开发人员应该加入 `#kubernetes-dev` 频道。 +一旦注册完成，你就可以浏览各种感兴趣的频道列表。 +例如，Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。 +又比如，开发人员应该加入 `#kubernetes-dev` 频道。 - 还有许多国家/地区语言频道。请随时加入这些频道以获得本地化支持和信息： - - 中国： `#cn-users`, `#cn-events` - 法国： `#fr-users`, `#fr-events` - 德国： `#de-users`, `#de-events` @@ -179,21 +167,20 @@ these channels for localized support and info: The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io) --> - -### 论坛 +### 论坛 {#forum} Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io) - +### Bugs 和功能请求（Feature Request） -如果你发现一个看起来像 bug 的东西，或者你想提出一个功能请求，请使用[Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。 - +如果你发现一个看起来像 Bug 的问题，或者你想提出一个功能请求，请使用 +[Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。 +在提交问题之前，请搜索现有问题以查看是否其中已涵盖你的问题。 -在提交问题之前，请搜索现有问题以查看是否已涵盖您的问题。 - -如果提交 bug，请提供如何重现问题的详细信息，例如： +如果提交 Bug，请提供如何重现问题的详细信息，例如： - * Kubernetes 版本：获取版本的命令为 `kubectl version` -* 云提供商，OS 发行版、网络配置和 Docker 版本 +* 云提供商、OS 发行版、网络配置和 Docker 版本 * 重现问题的步骤 diff --git a/content/zh/docs/tasks/example-task-template.md b/content/zh/docs/tasks/example-task-template.md deleted file mode 100644 index e3cf46734f..0000000000 --- a/content/zh/docs/tasks/example-task-template.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: 示例任务的模板 -reviewers: -- chenopis -content_type: task -toc_hide: true ---- - - - - - - - -{{< note >}} -还要确保为新文档[在目录中创建一个条目](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents)。 -{{< /note >}} - - -这个页面展示了如何... - - - -## {{% heading "prerequisites" %}} - - - - - -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* 做这个。 -* 也做这个。 - - - - - - - -## 做... - - - -1. 做这个。 -1. 接下来做这个。可能需要阅读一下这个[相关解释](...). - - - - - - - -## 理解 ... - -**[可选部分]** - - -关于你刚才所做的过程，有一点是需要知道的。 - - - -## {{% heading "whatsnext" %}} - - - - -**[可选部分]** - - - -* 了解更多关于[撰写新主题](/docs/home/contribute/write-new-topic/). -* 查看[使用页面模板-任务模板](/docs/home/contribute/page-templates/#task_template) for how to use this template. - - - -