Update localization guidelines (#10485)

* Update localization guidelines for language labels

Continuing work

Continuing work

Continuing work

More work in progress

Add local OWNERS folders

Add an OWNERS file to Chinese

Remove shortcode for repos

Add Japanese

Alphabetize languages, change weights accordingly

More updates

Add Korean in Korean

Add English to languageName

Feedback from gochist

Move Chinese content from cn/ to zh/

Move OWNERS from cn/ to zh/

Resolve merge conflicts by updating from master

Add files back in to prep for resolution

After rebase on upstream/master, remove files

Review and update localization guidelines

Feedback from gochist, tnir, cstoku

Add a trailing newline to content/ja/OWNERS

Add a trailing newline to content/zh/OWNERS

Drop requirement for GH repo project

Clarify language about forks/branches

Edits and typos

Remove a shortcode specific to a multi-repo language setup

Update aliases and owners

Add explicit OWNERS for content/en

Migrate content from Chinese repo, update regex in config.toml

Remove untranslated strings

Add trailing newline to content/en/OWNERS

Add trailing newlines to OWNERS files

add Jaguar project description (#10433)

* add Jaguar project description

[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.

* Minor newline tweak

blog post for azure vmss (#10538)

Add microk8s to pick-right-solution.md (#10542)

* Add microk8s to pick-right-solution.md

Microk8s is a single-command installation of upstream Kubernetes on any Linux and should be included in the list of local-machine solutions.

* capitalized Istio

Add microk8s to foundational.md (#10543)

* Add microk8s to foundational.md

Adding microk8s as credible and stable alternative to get started with Kubernetes on a local machine. This is especially attractive for those not wanting to incur the overhead of running a VM for a local cluster.

* Update foundational.md

Thank you for your suggestions! LMK if this works now?

* Rewrote first paragraph

And included a bullet list of features of microk8s

* Copyedit

fix typo (#10545)

Fix the kubectl subcommands links. (#10550)

Signed-off-by: William Zhang <warmchang@outlook.com>

Fix command issue (#10515)

Signed-off-by: mooncake <xcoder@tenxcloud.com>

remove imported community files per issue 10184 (#10501)

networking.md: Markdown fix (#10498)

Fix front matter, federation command-line tools (#10500)

Clean up glossary entry (#10399)

update slack link (#10536)

typo in StatefulSet docs (#10558)

fix discription about horizontal pod autoscale (#10557)

Remove redundant symbols (#10556)

Fix issue #10520 (#10554)

Signed-off-by: William Zhang <warmchang@outlook.com>

Update api-concepts.md (#10534)

Revert "Fix command issue (#10515)"

This reverts commit c02a7fb9f9.

Update memory-constraint-namespace.md (#10530)

update memory request to 100MiB corresponding the yaml content

Blog: Introducing Volume Snapshot Alpha for Kubernetes (#10562)

* blog post for azure vmss

* snapshot blog post

Resolve merge conflicts in OWNERS*

Minor typo fix (#10567)

Not sure what's supposed to be here, proposing removing it.

* Feedback from gochist

Tweaks to feedback

* Feedback from ClaudiaJKang

content/zh/docs/tasks/debug-application-cluster/audit.md

@@ -0,0 +1,612 @@
+---
+reviewers:
+- soltysh
+- sttts
+- ericchiang
+content_template: templates/concept
+title: Auditing
+---
+
+{{% capture overview %}}
+
+{{< feature-state state="beta" >}}
+
+<!--
+Kubernetes auditing provides a security-relevant chronological set of records documenting
+the sequence of activities that have affected system by individual users, administrators
+or other components of the system. It allows cluster administrator to
+answer the following questions:
+-->
+Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。
+它能帮助集群管理员处理以下问题：
+
+<!--
+ - what happened?
+ - when did it happen?
+ - who initiated it?
+ - on what did it happen?
+ - where was it observed?
+ - from where was it initiated?
+ - to where was it going?
+-->
+ - 发生了什么？
+ - 什么时候发生的？
+ - 谁触发的？
+ - 活动发生在哪个（些）对象上？
+ - 在哪观察到的？
+ - 它从哪触发的？
+ - 活动的后续处理行为是什么？
+
+{{% /capture %}}
+
+{{< toc >}}
+
+{{% capture body %}}
+
+<!--
+[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage
+of its execution generates an event, which is then pre-processed according to
+a certain policy and written to a backend. The policy determines what's recorded
+and the backends persist the records. The current backend implementations
+include logs files and webhooks.
+-->
+[Kube-apiserver][kube-apiserver] 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。
+您可以在 [设计方案][auditing-proposal] 中找到更多详细信息。
+该策略确定记录的内容并且在后端存储记录。当前的后端支持日志文件和 webhook。
+
+<!--
+Each request can be recorded with an associated "stage". The known stages are:
+
+- `RequestReceived` - The stage for events generated as soon as the audit
+  handler receives the request, and before it is delegated down the handler
+  chain.
+- `ResponseStarted` - Once the response headers are sent, but before the
+  response body is sent. This stage is only generated for long-running requests
+  (e.g. watch).
+- `ResponseComplete` - The response body has been completed and no more bytes
+  will be sent.
+- `Panic` - Events generated when a panic occurred.
+-->
+
+每个请求都可以用相关的 "stage" 记录。已知的 stage 有：
+
+- `RequestReceived` - 事件的 stage 将在审计处理器接收到请求后，并且在委托给其余处理器之前生成。
+
+- `ResponseStarted` - 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时间运行的请求生成（例如 watch）。
+
+- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。
+- `Panic` - 当 panic 发生时生成。
+
+{{< note >}}
+<!--
+**Note** The audit logging feature increases the memory consumption of the API
+server because some context required for auditing is stored for each request.
+Additionally, memory consumption depends on the audit logging configuration.
+-->
+**注意** 审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。
+此外，内存消耗取决于审计日志记录的配置。
+{{< /note >}}
+
+<!--
+## Audit Policy
+
+Audit policy defines rules about what events should be recorded and what data
+they should include. The audit policy object structure is defined in the
+[`audit.k8s.io` API group][auditing-api]. When an event is processed, it's
+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.k8s.io` API 组][auditing-api] 中定义。
+处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 [审计级别][auditing-level]。已知的审计级别有：
+
+<!--
+- `None` - don't log events that match this rule.
+- `Metadata` - log request metadata (requesting user, timestamp, resource,
+  verb, etc.) but not request or response body.
+- `Request` - log event metadata and request body but not response body.
+  This does not apply for non-resource requests.
+- `RequestResponse` - log event metadata, request and response bodies.
+  This does not apply for non-resource requests.
+-->
+- `None` - 符合这条规则的日志将不会记录。
+- `Metadata` - 记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。
+- `Request` - 记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。
+- `RequestResponse` - 记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。
+
+<!--
+You can pass a file with the policy to [kube-apiserver][kube-apiserver]
+using the `--audit-policy-file` flag. If the flag is omitted, no events are logged.
+Note that the `rules` field __must__ be provided in the audit policy file.
+A policy with no (0) rules is treated as illegal.
+
+Below is an example audit policy file:
+-->
+您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。 
+注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。
+
+以下是一个审计策略文件的示例：
+
+{{< codenew file="audit/audit-policy.yaml" >}}
+
+<!--
+You can use a minimal audit policy file to log all requests at the `Metadata` level:
+-->
+您可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求：
+
+```yaml
+# Log all requests at the Metadata level.
+apiVersion: audit.k8s.io/v1beta1
+kind: Policy
+rules:
+- level: Metadata
+```
+
+<!--
+The [audit profile used by GCE][gce-audit-profile] should be used as reference by
+admins constructing their own audit profiles.
+-->
+管理员构建自己的审计配置文件时，应使用 [GCE 使用的审计配置文件][gce-audit-profile] 作为参考。
+
+<!--
+## Audit backends
+
+Audit backends persist audit events to an external storage.
+[Kube-apiserver][kube-apiserver] out of the box provides two backends:
+
+- Log backend, which writes events to a disk
+- Webhook backend, which sends events to an external API
+
+In both cases, audit events structure is defined by the API in the
+`audit.k8s.io` API group. The current version of the API is
+[`v1beta1`][auditing-api].
+-->
+## 审计后端
+
+审计后端实现将审计事件导出到外部存储。
+[Kube-apiserver][kube-apiserver] 提供两个后端：
+
+- Log 后端，将事件写入到磁盘
+- Webhook 后端，将事件发送到外部 API
+
+在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。当前版本的 API 是 [`v1beta1`][auditing-api]。
+
+{{< note >}}
+<!--
+**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
+with an appropriate Kubernetes API object. For example, the following request body is a valid patch
+request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
+-->
+**注意：** 在 patch 请求的情况下，请求的消息体需要是一个 JSON 串指定 patch 操作，而不是一个完整的 Kubernetes API 对象 JSON 串。
+例如，以下的示例是一个合法的 patch 请求消息体，该请求对应 `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。
+
+```json
+[
+  {
+    "op": "replace",
+    "path": "/spec/parallelism",
+    "value": 0
+  },
+  {
+    "op": "remove",
+    "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
+  }
+]
+```
+{{< /note >}}
+
+<!--
+### Log backend
+
+Log backend writes audit events to a file in JSON format. You can configure
+log audit backend using the following [kube-apiserver][kube-apiserver] flags:
+-->
+### Log 后端
+
+Log 后端将审计事件写入 JSON 格式的文件。您可以使用以下 [kube-apiserver][kube-apiserver] 标志配置 Log 审计后端：
+
+<!--
+- `--audit-log-path` specifies the log file path that log backend uses to write
+  audit events. Not specifying this flag disables log backend. `-` means standard out
+- `--audit-log-maxage` defined the maximum number of days to retain old audit log files
+- `--audit-log-maxbackup` defines the maximum number of audit log files to retain
+- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
+-->
+- `--audit-log-path` 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。`-` 意味着标准化
+- `--audit-log-maxage` 定义了保留旧审计日志文件的最大天数
+- `--audit-log-maxbackup` 定义了要保留的审计日志文件的最大数量
+- `--audit-log-maxsize` 定义审计日志文件的最大大小（兆字节）
+
+<!--
+### Webhook backend
+
+Webhook backend sends audit events to a remote API, which is assumed to be the
+same API as [kube-apiserver][kube-apiserver] exposes. You can configure webhook
+audit backend using the following kube-apiserver flags:
+-->
+### Webhook 后端
+
+Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 [kube-apiserver][kube-apiserver] 相同的API。
+您可以使用如下 kube-apiserver 标志来配置 webhook 审计后端：
+
+<!--
+- `--audit-webhook-config-file` specifies the path to a file with a webhook
+  configuration. Webhook configuration is effectively a [kubeconfig][kubeconfig].
+- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed
+  request before retrying. Subsequent requests are retried with exponential backoff.
+
+The webhook config file uses the kubeconfig format to specify the remote address of
+the service and credentials used to connect to it.
+-->
+- `--audit-webhook-config-file` webhook 配置文件的路径。Webhook 配置文件实际上是一个 [kubeconfig][kubeconfig]。
+- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。
+
+webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
+
+### Batching
+
+<!--
+Both log and webhook backends support batching. Using webhook as an example, here's the list of
+available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag
+name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default
+throttling is enabled in `webhook` and disabled in `log`.
+
+- `--audit-webhook-mode` defines the buffering strategy. One of the following:
+  - `batch` - buffer events and asynchronously process them in batches. This is the default.
+  - `blocking` - block API server responses on processing each individual event.
+-->
+
+log 和 webhook 后端都支持 batch。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数，请在参数名称中将 `webhook` 替换为 `log`。
+默认情况下，在 `webhook` 中启用 batch，在 `log` 中禁用 batch。同样，默认情况下，在 `webhook` 中启用限制，在 `log` 中禁用限制。
+
+- `--audit-webhook-mode` 定义缓存策略，可选值如下：
+  - `batch` - 以批处理缓存事件和异步的过程。这是默认值。
+  - `blocking` - 阻止 API server 处理每个单独事件的响应。
+
+<!--
+The following flags are used only in the `batch` mode.
+
+- `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching.
+  If the rate of incoming events overflows the buffer, events are dropped.
+- `--audit-webhook-batch-max-size` defines the maximum number of events in one batch.
+- `--audit-webhook-batch-max-wait` defines the maximum amount of time to wait before unconditionally
+  batching events in the queue.
+- `--audit-webhook-batch-throttle-qps` defines the maximum average number of batches generated
+  per second.
+- `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same
+  moment if the allowed QPS was underutilized previously.
+-->
+以下参数仅用于 `batch` 模式。
+
+- `--audit-webhook-batch-buffer-size` 定义 batch 之前要缓存的事件数。
+  如果传入事件的速率溢出缓存区，则会丢弃事件。
+- `--audit-webhook-batch-max-size` 定义一个 batch 中的最大事件数。
+- `--audit-webhook-batch-max-wait` 无条件 batch 队列中的事件前等待的最大事件。
+- `--audit-webhook-batch-throttle-qps` 每秒生成的最大 batch 平均值。
+- `--audit-webhook-batch-throttle-burst` 在达到允许的 QPS 前，同一时刻允许存在的最大 batch 生成数。
+
+<!--
+#### Parameter tuning
+
+Parameters should be set to accommodate the load on the apiserver.
+
+For example, if kube-apiserver receives 100 requests each second, and each request is audited only
+on `ResponseStarted` and `ResponseComplete` stages, you should account for ~200 audit
+events being generated each second. Assuming that there are up to 100 events in a batch,
+you should set throttling level at least 2 QPS. Assuming that the backend can take up to
+5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events, i.e.
+10 batches, i.e. 1000 events.
+-->
+#### 参数调整
+
+需要设置参数以适应 apiserver 上的负载。
+
+
+例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 `ResponseStarted` 和 `ResponseComplete` 阶段进行审计，则应该考虑每秒生成约 200 个审计事件。
+假设批处理中最多有 100 个事件，则应将限制级别设置为至少 2 个 QPS。
+假设后端最多需要 5 秒钟来写入事件，您应该设置缓冲区大小以容纳最多 5 秒的事件，即 10 个 batch，即 1000 个事件。
+
+<!--
+In most cases however, the default parameters should be sufficient and you don't have to worry about
+setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver
+and in the logs to monitor the state of the auditing subsystem.
+
+- `apiserver_audit_event_total` metric contains the total number of audit events exported.
+- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error
+  during exporting.
+-->
+但是，在大多数情况下，默认参数应该足够了，您不必手动设置它们。您可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。
+
+- `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。
+- `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。
+
+<!--
+## Multi-cluster setup
+
+If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also
+set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the
+same format as described above to the aggregated apiserver and set up the log ingesting pipeline
+to pick up audit logs. Different apiservers can have different audit configurations and different
+audit policies.
+-->
+## 多集群配置
+
+如果您通过 [aggregation layer][kube-aggregator] 对 Kubernetes API 进行扩展，那么您也可以为聚合的 apiserver 设置审计日志。
+想要这么做，您需要以上述的格式给聚合的 apiserver 配置参数，并且配置日志管道以采用审计日志。不同的 apiserver 可以配置不同的审计配置和策略。
+
+<!--
+## Log Collector Examples
+
+### Use fluentd to collect and distribute audit events from log file
+
+[Fluentd][fluentd] is an open source data collector for unified logging layer.
+In this example, we will use fluentd to split audit events by different namespaces.
+
+1. install [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc] in the kube-apiserver node
+1. create a config file for fluentd
+-->
+## 日志选择器示例
+
+### 使用 fluentd 从日志文件中选择并且分发审计日志
+
+[Fluentd][fluentd] 是一个开源的数据采集器，可以从统一的日志层中采集。
+在以下示例中，我们将使用 fluentd 来按照命名空间划分审计事件。
+
+1. 在 kube-apiserver node 节点上安装 [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc]
+1. 为 fluentd 创建一个配置文件
+
+    ```none
+    $ cat <<EOF > /etc/fluentd/config
+    # fluentd conf runs in the same host with kube-apiserver
+    <source>
+        @type tail
+        # audit log path of 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
+    </source>
+
+    <filter audit>
+        #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
+        type record_transformer
+        enable_ruby
+        <record>
+         namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ?  "none":record["objectRef"]["namespace"])}
+        </record>
+    </filter>
+
+    <match audit>
+        # route audit according to namespace element in context
+        @type rewrite_tag_filter
+        rewriterule1 namespace ^(.+) ${tag}.$1
+    </match>
+
+    <filter audit.**>
+       @type record_transformer
+       remove_keys namespace
+    </filter>
+
+    <match audit.**>
+        @type forest
+        subtype file
+        remove_prefix audit
+        <template>
+            time_slice_format %Y%m%d%H
+            compress gz
+            path /var/log/audit-${tag}.*.log
+            format json
+            include_time_key true
+        </template>
+    </match>
+    ```
+
+<!--
+1. start fluentd
+-->
+1. 启动 fluentd
+
+    ```shell
+    $ fluentd -c /etc/fluentd/config  -vv
+    ```
+
+<!--
+1. start kube-apiserver with the following options:
+-->
+1. 给 kube-apiserver 配置以下参数并启动：
+
+    ```shell
+    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
+    ```
+
+<!--
+1. check audits for different namespaces in `/var/log/audit-*.log`
+-->
+1. 在 `/var/log/audit-*.log` 文件中检查不同命名空间的审计事件
+
+<!--
+### Use logstash to collect and distribute audit events from webhook backend
+
+[Logstash][logstash] is an open source, server-side data processing tool. In this example,
+we will use logstash to collect audit events from webhook backend, and save events of
+different users into different files.
+
+1. install [logstash][logstash_install_doc]
+1. create config file for logstash
+-->
+### 使用 logstash 采集并分发 webhook 后端的审计事件
+
+[Logstash][logstash] 是一个开源的、服务器端的数据处理工具。在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。
+
+1. 安装 [logstash][logstash_install_doc]
+1. 为 logstash 创建配置文件
+
+    ```none
+    $ cat <<EOF > /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"
+        }
+    }
+    ```
+
+<!--
+1. start logstash
+-->
+1. 启动 logstash
+
+    ```shell
+    $ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
+    ```
+
+<!--
+1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
+-->
+1. 为 kube-apiserver webhook 审计后端创建一个 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
+
+    ```none
+    $ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
+    apiVersion: v1
+    clusters:
+    - cluster:
+        server: http://<ip_of_logstash>:8888
+      name: logstash
+    contexts:
+    - context:
+        cluster: logstash
+        user: ""
+      name: default-context
+    current-context: default-context
+    kind: Config
+    preferences: {}
+    users: []
+    EOF
+    ```
+
+<!--
+1. start kube-apiserver with the following options:
+-->
+1. 为 kube-apiserver 配置以下参数并启动：
+
+    ```shell
+    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
+    ```
+
+<!--
+1. check audits in logstash node's directories `/var/log/kube-audit-*/audit`
+
+Note that in addition to file output plugin, logstash has a variety of outputs that
+let users route data where they want. For example, users can emit audit events to elasticsearch
+plugin which supports full-text search and analytics.
+-->
+1. 在 logstash node 节点的 `/var/log/kube-audit-*/audit` 目录中检查审计事件
+
+注意到，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。
+
+<!--
+## Legacy Audit
+
+__Note:__ Legacy Audit is deprecated and is disabled by default since 1.8 and 
+will be removed in 1.12. To fallback to this legacy audit, disable the advanced
+auditing feature using the `AdvancedAuditing` feature gate in [kube-apiserver][kube-apiserver]:
+-->
+## 传统的审计
+
+__注意：__ 传统审计已被弃用，自 1.8 版本以后默认禁用，并且将会在 1.12 版本中彻底移除。
+如果想要回退到传统的审计功能，请使用 [kube-apiserver][kube-apiserver] 中 feature gate 的 `AdvancedAuditing` 功能来禁用高级审核功能：
+
+```
+--feature-gates=AdvancedAuditing=false
+```
+
+<!--
+In legacy format, each audit log entry contains two lines:
+
+1. The request line containing a unique ID to match the response and request
+   metadata, such as the source IP, requesting user, impersonation information,
+   resource being requested, etc.
+2. The response line containing a unique ID matching the request line and the response code.
+
+Example output for `admin` user listing pods in the `default` namespace:
+-->
+在传统格式中，每个审计文件条目包含两行：
+
+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="<self>" asgroups="<lookup>" 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"
+```
+
+<!--
+### Configuration
+
+[Kube-apiserver][kube-apiserver] provides the following options which are responsible
+for configuring where and how audit logs are handled:
+-->
+### 配置
+
+[Kube-apiserver][kube-apiserver] 提供以下选项，负责配置审核日志的位置和处理方式：
+
+<!--
+- `audit-log-path` - enables the audit log pointing to a file where the requests are being logged to, '-' means standard out.
+- `audit-log-maxage` - specifies maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
+- `audit-log-maxbackup` - specifies maximum number of old audit log files to retain.
+- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.
+-->
+- `audit-log-path` - 使审计日志指向请求被记录到的文件，'-' 表示标准输出。
+- `audit-log-maxage` - 根据文件名中编码的时间戳指定保留旧审计日志文件的最大天数。
+- `audit-log-maxbackup` - 指定要保留的旧审计日志文件的最大数量。
+- `audit-log-maxsize` - 指定审核日志文件的最大大小（兆字节）。默认为100MB。
+
+<!--
+If an audit log file already exists, Kubernetes appends new audit logs to that file.
+Otherwise, Kubernetes creates an audit log file at the location you specified in
+`audit-log-path`. If the audit log file exceeds the size you specify in `audit-log-maxsize`,
+Kubernetes will rename the current log file by appending the current timestamp on
+the file name (before the file extension) and create a new audit log file.
+Kubernetes may delete old log files when creating a new log file; you can configure
+how many files are retained and how old they can be by specifying the `audit-log-maxbackup`
+and `audit-log-maxage` options.
+-->
+如果审核日志文件已经存在，则 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]: https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
+[fluentd]: http://www.fluentd.org/
+[fluentd_install_doc]: http://docs.fluentd.org/v0.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
+
+{{% /capture %}}

content/zh/docs/tasks/debug-application-cluster/debug-application.md

@@ -0,0 +1,177 @@
+---
+title: 应用故障排查
+---
+
+本指南帮助用户来调试kubernetes上那些没有正常运行的应用。
+本指南*不能*调试集群。如果想调试集群的话，请参阅[这里](/docs/admin/cluster-troubleshooting)。
+
+{{< toc >}}
+
+## 诊断问题
+
+故障排查的第一步是先给问题分下类。这个问题是什么？Pods，Replication Controller或者Service？
+
+   * [Debugging Pods](#debugging-pods)
+   * [Debugging Replication Controllers](#debugging-replication-controllers)
+   * [Debugging Services](#debugging-services)
+
+### Debugging Pods
+
+调试pod的第一步是看一下这个pod的信息，用如下命令查看一下pod的当前状态和最近的事件：
+
+```shell
+$ kubectl describe pods ${POD_NAME}
+```
+
+查看一下pod中的容器所处的状态。这些容器的状态都是`Running`吗？最近有没有重启过？
+
+后面的调试都是要依靠pods的状态的。
+
+#### pod停留在pending状态
+
+如果一个pod卡在`Pending`状态，则表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。  
+敲一下`kubectl describe ...`这个命令，输出的信息里面应该有显示为什么没被调度的原因。  
+常见原因如下：
+
+* **资源不足**:  
+你可能耗尽了集群上所有的CPU和内存，此时，你需要删除pods，调整资源请求，或者增加节点。
+更多信息请参阅[Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling)
+
+* **使用了`hostPort`**:
+如果绑定一个pod到`hostPort`，那么能创建的pod个数就有限了。  
+多数情况下，`hostPort`是非必要的，而应该采用服务来暴露pod。  
+如果确实需要使用`hostPort`，那么能创建的pod的数量就是节点的个数。
+
+
+#### pod停留在waiting状态
+
+如果一个pod卡在`Waiting`状态，则表示这个pod已经调试到节点上，但是没有运行起来。  
+再次敲一下`kubectl describe ...`这个命令来查看相关信息。  
+最常见的原因是拉取镜像失败。可以通过以下三种方式来检查：
+
+* 使用的镜像名字正确吗？
+* 镜像仓库里有没有这个镜像？
+* 用`docker pull <image>`命令手动拉下镜像试试。
+
+#### pod处于crashing状态或者unhealthy
+
+首先，看一下容器的log:
+
+```shell
+$ kubectl logs ${POD_NAME} ${CONTAINER_NAME}
+```
+
+如果容器是crashed的，用如下命令可以看到crash的log:
+
+```shell
+$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
+```
+
+或者，用`exec`在容器内运行一些命令：
+
+```shell
+$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
+```
+
+注意：当一个pod内只有一个容器时，可以不带参数`-c ${CONTAINER_NAME}`。
+
+例如，名为Cassandra的pod，处于running态，要查看它的log，可运行如下命令：
+
+```shell
+$ kubectl exec cassandra -- cat /var/log/cassandra/system.log
+```
+
+如果以上方法都不起作用，找到这个pod所在的节点并用SSH登录进去做进一步的分析。  
+通常情况下，是不需要在Kubernetes API中再给出另外的工具的。  
+因此，如果你发现需要ssh进一个主机来分析问题时，请在GitHub上提一个特性请求，描述一个你的场景并说明为什么已经提供的工具不能满足需求。
+
+
+#### pod处于running态，但是没有正常工作
+
+如果创建的pod不符合预期，那么创建pod的描述文件应该是存在某种错误的，并且这个错误在创建pod时被忽略掉。  
+通常pod的定义中，章节被错误的嵌套，或者一个字段名字被写错，都可能会引起被忽略掉。  
+例如，希望在pod中用命令行执行某个命令，但是将`command`写成`commnd`，pod虽然可以创建，但命令并没有执行。  
+
+如何查出来哪里出错？  
+首先，删掉这个pod再重新创建一个，重创时，像下面这样带着`--validate`这个参数：  
+`kubectl create --validate -f mypod.yaml`，`command`写成`commnd`的拼写错误就会打印出来了。  
+
+```shell
+I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
+I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
+pods/mypod
+```
+
+<!-- TODO: Now that #11914 is merged, this advice may need to be updated -->
+
+如果上面方法没有看到相关异常的信息，那么接下来就要验证从apiserver获取到的pod是否与期望的一致，比如创建Pod的yaml文件是mypod.yaml。  
+
+运行如下命令来获取apiserver创建的pod信息并保存成一个文件：  
+`kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml`。
+
+然后手动对这两个文件进行比较:  
+apiserver获得的yaml文件中的一些行，不在创建pod的yaml文件内，这是正常的。  
+如果创建Pod的yaml文件内的一些行，在piserver获得的yaml文件中不存在，可以说明创建pod的yaml中的定义有问题。
+
+
+### Debugging Replication Controllers
+
+RC相当简单。他们要么能创建pod，要么不能。如果不能创建pod，请参阅上述[Debugging Pods](#debugging-pods)。
+
+也可以使用`kubectl describe rc ${CONTROLLER_NAME}`命令来监视RC相关的事件。
+
+### Debugging Services
+
+服务提供了多个Pod之间的负载均衡功能。  
+有一些常见的问题可以造成服务无法正常工作。以下说明将有助于调试服务的问题。
+
+首先，验证服务是否有端点。对于每一个Service对像，apiserver使`endpoints`资源可用。
+
+通过如下命令可以查看endpoints资源：
+
+```shell
+$ kubectl get endpoints ${SERVICE_NAME}
+```
+
+确保endpoints与服务内容器个数一致。  
+例如，如果你创建了一个nginx服务，它有3个副本，那么你就会在这个服务的endpoints中看到3个不同的IP地址。
+
+#### 服务缺少endpoints
+
+如果缺少endpoints，请尝试使用服务的labels列出所有的pod。  
+假如有一个服务，有如下的label：
+
+```yaml
+...
+spec:
+  - selector:
+     name: nginx
+     type: frontend
+```
+
+你可以使用如下命令列出与selector相匹配的pod，并验证这些pod是否归属于创建的服务：
+
+```shell
+$ kubectl get pods --selector=name=nginx,type=frontend
+```
+
+如果pod列表附合预期，但是endpoints仍然为空，那么可能没有暴露出正确的端口。  
+如果服务指定了`containerPort`，但是列表中的Pod没有列出该端口，则不会将其添加到端口列表。
+
+验证该pod的`containerPort`与服务的`containerPort`是否匹配。
+
+#### 网络业务不工作
+
+如果可以连接到服务上，但是连接立即被断开了，并且在endpoints列表中有endpoints，可能是代理和pods之间不通。
+
+确认以下3件事情：
+
+   * Pods工作是否正常？ 看一下重启计数，并参阅[Debugging Pods](#debugging-pods)；
+   * 可以直接连接到pod上吗？获取pod的IP地址，然后尝试直接连接到该IP上；
+   * 应用是否在配置的端口上进行服务？Kubernetes不进行端口重映射，所以如果应用在8080端口上服务，那么`containerPort`字段就需要设定为8080。
+
+#### 更多信息
+
+如果上述都不能解决你的问题，请按照[Debugging Service document](/docs/user-guide/debugging-services)中的介绍来确保你的`Service`处于running态，有`Endpoints`，`Pods`真正的在服务；你有DNS在工作，安装了iptables规则，kube-proxy也没有异常行为。
+
+你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多信息。

content/zh/docs/tasks/debug-application-cluster/debug-cluster.md

@@ -0,0 +1,114 @@
+---
+title: 集群故障排查
+---
+
+本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。  
+对于应用的调试，请参阅[应用故障排查指南](/cn/docs/tasks/debug-application-cluster/debug-application)。
+你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多的信息。
+
+## 显示出集群的节点列表
+
+调试的第一步是查看所有的节点是否都正确的注册。
+
+运行
+
+```shell
+kubectl get nodes
+```
+
+接下来，验证你的所有节点都能够显示出来，并且都处于`Ready`状态。
+
+## 查看logs
+
+现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。  
+(注意，对于基于systemd的系统，你可能需要使用`journalctl`)
+
+
+### Master
+
+   * /var/log/kube-apiserver.log - API Server, 提供API服务
+   * /var/log/kube-scheduler.log - Scheduler, 负责调度决策
+   * /var/log/kube-controller-manager.log - 管理replication controllers的控制器
+
+### Worker Nodes
+
+   * /var/log/kubelet.log - Kubelet, 管控节点上运行的容器
+   * /var/log/kube-proxy.log - Kube Proxy, 负责服务的负载均衡
+
+## 集群故障模式的概述
+
+下面是一个不完整的列表，列举了一些可能出错的场景，以及通过调整集群配置来解决相关问题的方法。
+
+根本原因：
+
+  - VM(s)关机
+  - 集群之间，或者集群和用户之间网络分裂
+  - Kubernetes软件本身崩溃了
+  - 数据丢失或者持久化存储不可用(如:GCE PD 或 AWS EBS卷)
+  - 操作错误，如：Kubernetes或者应用程序配置错误
+
+具体情况:
+
+  - Apiserver所在的VM关机或者apiserver崩溃
+    - 结果
+      - 不能停止，更新，或者启动新的pods，services，replication controller
+      - 现有的pods和services在不依赖Kubernetes API的情况下应该能继续正常工作
+  - Apiserver 后端存储丢失
+    - 结果
+      - apiserver应该不能起来
+      - kubelets将不能访问它，但是能够继续运行之前的Pods和提供相同的服务代理
+      - 在apiserver重启之前，需要手动恢复或者重创apiserver的状态
+	    
+  - Kubernetes服务组件(节点控制器，副本控制器，调度器等等)所在的VM关机或者崩溃
+    - 当前，这些控制器是和apiserver共存的，它们不可用的现象是与apiserver类似的
+    - 将来，这些控制器也会复制为多份，并且可能为非共存的
+    - 它们没有自己的持久状态
+  - 单个节点(VM或者物理机)关机
+    - 结果
+      - 此节点上的所有Pods都停止运行
+  - 网络分裂(Network partition)
+    - 结果
+      - partition A认为partition B中所有的节点都down掉了；partition B认为apiserver是down掉了(假定master所在的VM位于partition A内)。
+  - Kubelet软件故障
+    - 结果
+      - 崩溃的kubelet就不能在其所在的节点上启动新的pods
+      - kubelet可能删掉pods或者不删
+      - 节点被标识为非健康态
+      - 副本控制器会在其它的节点上启动新的pods
+  - 集群操作错误
+    - 结果
+      - 丢失pods，服务等等
+      - 丢失apiserver后端存储
+      - 用户无法读取API
+      - 等等
+
+缓解措施:
+
+- 措施：对于IaaS上的VMs，使用IaaS的自动VM重启功能
+  - 缓解：Apiserver VM关机或apiserver崩溃
+  - 缓解：Kubernetes服务组件所在的VM关机或崩溃
+
+- 措施: 对于具有apiserver+etcd的VM，使用IaaS提供的可靠的存储（例如GCE PD或者AWS EBS卷）
+  - 缓解：Apiserver后端存储的丢失
+
+- 措施：使用（实验）[高可用性](/docs/admin/high-availability)的配置
+  - 缓解：master VM关机或者master组件(scheduler, API server, controller-managing)崩馈
+    - 将容许一个或多个节点或组件同时出现故障
+  - 缓解：apiserver后端存储(例如etcd的数据目录)丢失
+    - 假定你使用了集群化的etcd。
+
+- 措施：定期的对apiserver的PDs/EBS卷进行快照
+  - 缓解：apiserver后端存储丢失
+  - 缓解：一些操作错误的场景
+  - 缓解：一些Kubernetes软件本身故障的场景
+
+- 措施：在pods的前面使用副本控制器或服务
+  - 缓解：节点关机
+  - 缓解：Kubelet软件故障
+
+- 措施：应用（容器）设计成容许异常重启
+  - 缓解：节点关机
+  - 缓解：Kubelet软件故障
+
+- 措施：[多个独立的集群](/docs/admin/multi-cluster)(并且避免一次性地对所有的集群进行有风险性的修改)
+  - 缓解：以上列出的所有情况

content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md

@@ -0,0 +1,86 @@
+---
+title: 调试Pods和Replication Controllers
+---
+
+{{< toc >}}
+
+## 调试Pods
+
+调试一个pod的第一步是观察它。使用下面的命令检查这个pod的当前状态和最近事件：
+
+    $ kubectl describe pods ${POD_NAME}
+
+看看pod中的容器的状态。他们都是`Running`吗？有最近重启了吗？
+
+根据pod的状态继续调试。
+
+### 我的Pod保持Pending
+
+如果一个pod被卡在`Pending`中，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足
+阻止调度。 看看上面的命令`kubectl describe ...`的输出。调度器的消息中应该会包含无法调度Pod的原因。
+理由包括：
+
+#### 资源不足
+
+您可能已经耗尽了集群中供应的CPU或内存。在这个情况下你可以尝试几件事情：
+
+* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。
+
+* [终止不需要的pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
+  为pending中的pods提供空间。
+
+* 检查该pod是否不大于您的节点。例如，如果全部节点具有`cpu:1`容量，那么具有`cpu: 1.1`请求的pod永远不会被调度。
+
+    您可以使用`kubectl get nodes -o <format>`命令来检查节点容量。
+    下面是一些能够提取必要信息的命令示例：
+
+      kubectl get nodes -o yaml | grep '\sname\|cpu\|memory'
+      kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
+
+  可以考虑配置[资源配额](/docs/concepts/policy/resource-quotas/)来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
+
+#### 使用hostPort
+
+当你将一个pod绑定到一个`hostPort`时，这个pod能被调度的位置数量有限。
+在大多数情况下，`hostPort`是不必要的; 尝试使用服务对象来暴露您的pod。
+如果你需要`hostPort`，那么你可以调度的Pod数量不能超过集群的节点个数。
+
+### 我的Pod一直在Waiting
+
+如果一个pod被卡在`Waiting`状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
+再次，来自`kubectl describe ...`的内容应该是可以提供信息的。
+最常见的原因`Waiting`的pod是无法拉取镜像。有三件事要检查：
+
+* 确保您的镜像的名称正确。
+* 您是否将镜像推送到存储库？
+* 在您的机器上手动运行`docker pull <image>`，看看是否可以拉取镜像。
+
+### 我的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}
+
+请注意，`-c ${CONTAINER_NAME}`是可选的，对于pod只包含一个容器可以省略。
+
+例如，要查看正在运行的Cassandra pod的日志，可以运行：
+
+    $ kubectl exec cassandra -- cat /var/log/cassandra/system.log
+
+如果这些方法都不起作用，您可以找到该运行pod所在的主机并SSH到该主机。
+
+## 调试Replication Controllers
+
+Replication Controllers相当简单。他们能或不能创建pod。如果他们无法创建pod，那么请参考
+[上面的说明](#debugging_pods)来调试你的pod。
+
+您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。
+

content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md

@@ -0,0 +1,78 @@
+---
+title: 调试StatefulSet
+content_template: templates/task
+---
+
+{{% capture overview %}}
+
+此任务展示如何调试StatefulSet。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+
+* 你需要有一个Kubernetes集群，通过必要的配置使kubectl命令行工具与您的集群进行通信。
+* 你应该有一个运行中的StatefulSet，以便用于调试。
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## 调试StatefulSet
+
+由于StatefulSet在创建时设置了`app=myapp`标签，列出仅属于该StatefulSet的所有pod时，可以使用以下命令：
+
+```shell
+kubectl get pods -l app=myapp
+```
+
+如果您发现列出的任何Pods长时间处于`Unknown` 或`Terminating`状态，关于如何处理它们的说明任务,请参阅[删除 StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/)。您可以参考[调试 Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods)指南来调试StatefulSet中的各个Pod。
+
+StatefulSets提供调试机制，可以使用注解来暂停所有控制器在Pod上的操作。在任何StatefulSet Pod上设置`pod.alpha.kubernetes.io/initialized`注解为`"false"`将*暂停* StatefulSet的所有操作。暂停时，StatefulSet将不执行任何伸缩操作。一旦调试钩子设置完成后，就可以在StatefulSet pod的容器内执行命令，而不会造成伸缩操作的干扰。您可以通过执行以下命令将注解设置为`"false"`：
+
+```shell
+kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --overwrite
+```
+
+当注解设置为`"false"`时，StatefulSet在其Pods变得不健康或不可用时将不会响应。StatefulSet不会创建副本Pod直到每个Pod上删除注解或将注解设置为`"true"`。
+
+### 逐步初始化
+
+创建StatefulSet之前，您可以通过使用和上文相同的注解，即将yaml文件中`.spec.template.metadata.annotations`里的`pod.alpha.kubernetes.io/initialized`字段设置为`"false"`，对竞态条件的StatefulSet进行调试。
+
+```yaml
+apiVersion: apps/v1beta1
+kind: StatefulSet
+metadata:
+  name: my-app
+spec:
+  serviceName: "my-app"
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: my-app
+      annotations:
+        pod.alpha.kubernetes.io/initialized: "false"
+...
+...
+...
+
+```
+
+设置注解后，如果创建了StatefulSet，您可以等待每个Pod来验证它是否正确初始化。StatefulSet将不会创建任何后续的Pods，直到在已经创建的每个Pod上将调试注解设置为`"true"` (或删除)。 您可以通过执行以下命令将注解设置为`"true"`：
+
+```shell
+kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="true" --overwrite
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+点击链接[调试init-container](/docs/tasks/troubleshoot/debug-init-containers/)，了解更多信息。
+
+{{% /capture %}}
+
+