[zh] Fix links in zh localization (3)

This commit is contained in:
Qiming Teng
2020-12-04 16:05:40 +08:00
parent 9c696a5883
commit b9e8fb699e
22 changed files with 514 additions and 352 deletions
@@ -23,9 +23,9 @@ This page shows how to debug Pods and ReplicationControllers.
<!--
* You should be familiar with the basics of
[Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
[Pods](/docs/concepts/workloads/pods/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
-->
* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/pod/) 和
* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/) 和
[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。
<!-- steps -->
@@ -20,7 +20,8 @@ This page explains how to debug Pods running (or crashing) on a Node.
need that access to run the standard debug steps that use `kubectl`.
-->
* 你的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 应该已经被调度并正在运行中,
如果你的 Pod 还没有运行,请参阅[应用问题排查](/docs/tasks/debug-application-cluster/debug-application/)。
如果你的 Pod 还没有运行,请参阅
[应用问题排查](/zh/docs/tasks/debug-application-cluster/debug-application/)。
* 对于一些高级调试步骤,你应该知道 Pod 具体运行在哪个节点上,在该节点上有权限去运行一些命令。
你不需要任何访问权限就可以使用 `kubectl` 去运行一些标准调试步骤。
@@ -147,7 +148,8 @@ images.
## 使用临时容器来调试的例子 {#ephemeral-container-example}
{{< note >}}
本示例需要你的集群已经开启 `EphemeralContainers` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
本示例需要你的集群已经开启 `EphemeralContainers`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
`kubectl` 版本为 v1.18 或者更高。
{{< /note >}}
@@ -20,7 +20,7 @@ in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
-->
在 Google Compute Engine (GCE) 平台上,默认的日志管理支持目标是
[Stackdriver Logging](https://cloud.google.com/logging/)
在[使用 Stackdriver Logging 管理日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
中详细描述了这一点。
<!--
@@ -49,7 +49,8 @@ To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
kube-up.sh:
-->
要使用 Elasticsearch 和 Kibana 处理集群日志,你应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量:
要使用 Elasticsearch 和 Kibana 处理集群日志,你应该在使用 kube-up.sh
脚本创建集群时设置下面所示的环境变量:
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
@@ -96,7 +97,7 @@ all be running in the kube-system namespace soon after the cluster comes to
life.
-->
每个节点的 Fluentd Pod、Elasticsearch Pod 和 Kibana Pod 都应该在集群启动后不久运行在
kube-system 名空间中。
kube-system 名空间中。
```shell
kubectl get pods --namespace=kube-system
@@ -137,8 +138,8 @@ and are not directly exposed via a publicly reachable IP address. To reach them,
follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
-->
Elasticsearch 和 Kibana 服务都位于 `kube-system` 名空间中,并且没有通过可公开访问的 IP 地址直接暴露。
要访问它们,请参照
Elasticsearch 和 Kibana 服务都位于 `kube-system`空间中,并且没有通过
可公开访问的 IP 地址直接暴露。要访问它们,请参照
[访问集群中运行的服务](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)
的说明进行操作。
@@ -156,7 +157,8 @@ like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasti
for more details on how to do so.
-->
现在你可以直接在浏览器中输入 Elasticsearch 查询,如果你愿意的话。
请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。
请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
以了解这样做的更多细节。
<!--
Alternatively, you can view your cluster's logs using Kibana (again using the
@@ -192,3 +194,4 @@ ideas on how to dig into it, check out [Kibana's documentation](https://www.elas
-->
Kibana 为浏览你的日志提供了各种强大的选项!有关如何深入研究它的一些想法,
请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
@@ -367,7 +367,8 @@ log names:
<!--
You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
-->
你可以在[专用 Stackdriver 页面](https://cloud.google.com/logging/docs/view/overview)上了解有关查看日志的更多信息。
你可以在[Stackdriver 专用页面](https://cloud.google.com/logging/docs/view/overview)
上了解有关查看日志的更多信息。
<!--
One of the possible ways to view logs is using the
@@ -376,8 +377,11 @@ command line interface from the [Google Cloud SDK].
It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
to query specific logs. For example, you can run the following command:
-->
查看日志的一种可能方法是使用 [Google Cloud SDK]((https://cloud.google.com/sdk/)) 中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) 命令行接口。
它使用 Stackdriver 日志机制的[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
查看日志的一种可能方法是使用 [Google Cloud SDK](https://cloud.google.com/sdk/)
中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging)
命令行接口。
它使用 Stackdriver 日志机制的
[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
例如,你可以运行以下命令:
```none
@@ -399,7 +403,8 @@ As you can see, it outputs messages for the count container from both
the first and second runs, despite the fact that the kubelet already deleted
the logs for the first container.
-->
如你所见,尽管 kubelet 已经删除了第一个容器的日志,日志中仍会包含 counter 容器第一次和第二次运行时输出的消息。
如你所见,尽管 kubelet 已经删除了第一个容器的日志,日志中仍会包含 counter
容器第一次和第二次运行时输出的消息。
<!--
### Exporting logs
@@ -416,7 +421,8 @@ the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/expo
你可以将日志导出到 [Google Cloud Storage](https://cloud.google.com/storage/) 或
[BigQuery](https://cloud.google.com/bigquery/) 进行进一步的分析。
Stackdriver 日志机制提供了接收器(Sink)的概念,你可以在其中指定日志项的存放地。
可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)上获得更多信息。
可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)
上获得更多信息。
<!--
## Configuring Stackdriver Logging Agents
@@ -453,14 +459,14 @@ If you're using GKE and Stackdriver Logging is enabled in your cluster, you
cannot change its configuration, because it's managed and supported by GKE.
However, you can disable the default integration and deploy your own.
-->
如果使用的是 GKE,并且集群中启用了 Stackdriver 日志机制,则无法更改其配置,因为它是由 GKE 管理和支持的。
如果使用的是 GKE,并且集群中启用了 Stackdriver 日志机制,则无法更改其配置,
因为它是由 GKE 管理和支持的。
但是,你可以禁用默认集成的日志机制并部署自己的。
<!--
You will have to support and maintain a newly deployed configuration
yourself: update the image and configuration, adjust the resources and so on.
-->
{{< note >}}
你将需要自己支持和维护新部署的配置了:更新映像和配置、调整资源等等。
{{< /note >}}
@@ -478,7 +484,8 @@ gcloud beta container clusters update --logging-service=none CLUSTER
You can find notes on how to then install Stackdriver Logging agents into
a running cluster in the [Deploying section](#deploying).
-->
你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到正在运行的集群中的说明​​。
你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到
正在运行的集群中的说明。
<!--
### Changing `DaemonSet` parameters
@@ -491,7 +498,8 @@ When you have the Stackdriver Logging `DaemonSet` in your cluster, you can just
let's assume you've just installed the Stackdriver Logging as described above. Now you want to
change the memory limit to give fluentd more memory to safely process more logs.
-->
当集群中有 Stackdriver 日志机制的 `DaemonSet` 时,你只需修改其 spec 中的 `template` 字段,daemonset 控制器将为你更新 pod。
当集群中有 Stackdriver 日志机制的 `DaemonSet` 时,你只需修改其 spec 中的
`template` 字段,daemonset 控制器将为你更新 Pod。
例如,假设你按照上面的描述已经安装了 Stackdriver 日志机制。
现在,你想更改内存限制,来给 fluentd 提供的更多内存,从而安全地处理更多日志。
@@ -616,4 +624,6 @@ Fluentd 用 Ruby 编写,并允许使用 [plugins](https://www.fluentd.org/plug
Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
new image, you can use the plugin you installed in the fluentd configuration.
-->
然后在该目录运行 `make build push`。在更新 `DaemonSet` 以使用新镜像后,你就可以使用在 fluentd 配置中安装的插件了。
然后在该目录运行 `make build push`。
在更新 `DaemonSet` 以使用新镜像后,你就可以使用在 fluentd 配置中安装的插件了。