Merge remote-tracking branch 'upstream/master' into dev-1.20
This commit is contained in:
Kristin Martin
commit
d2c63597e5
|
|
@ -157,7 +157,7 @@ github_repo = "https://github.com/kubernetes/website"
|
|||
# param for displaying an announcement block on every page.
|
||||
# See /i18n/en.toml for message text and title.
|
||||
announcement = true
|
||||
announcement_bg = "#000000" #choose a dark color – text is white
|
||||
announcement_bg = "#3f0374" # choose a dark color – text is white
|
||||
|
||||
#Searching
|
||||
k8s_search = true
|
||||
|
|
|
|||
|
|
@ -31,6 +31,8 @@ A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is simila
|
|||
|
||||
`VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attributes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
|
||||
|
||||
Volume snapshots provide Kubernetes users with a standardized way to copy a volume's contents at a particular point in time without creating an entirely new volume. This functionality enables, for example, database administrators to backup databases before performing edit or delete modifications.
|
||||
|
||||
Users need to be aware of the following when using this feature:
|
||||
|
||||
* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
|
||||
|
|
@ -152,6 +154,4 @@ You can provision a new volume, pre-populated with data from a snapshot, by usin
|
|||
the *dataSource* field in the `PersistentVolumeClaim` object.
|
||||
|
||||
For more details, see
|
||||
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
|
||||
|
||||
|
||||
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -4,11 +4,21 @@ content_type: concept
|
|||
weight: 40
|
||||
---
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
<!-- leave this shortcode in place until the note about EvenPodsSpread is
|
||||
obsolete -->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on
|
||||
the [API server](/docs/concepts/overview/components/#kube-apiserver) and the
|
||||
[scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod
|
||||
topology spread constraints.
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -295,13 +305,13 @@ apiVersion: kubescheduler.config.k8s.io/v1beta1
|
|||
kind: KubeSchedulerConfiguration
|
||||
|
||||
profiles:
|
||||
pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
- pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -189,13 +189,15 @@ Start-Service containerd
|
|||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### systemd
|
||||
#### systemd {#containerd-systemd}
|
||||
|
||||
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
|
||||
|
||||
```
|
||||
[plugins.cri]
|
||||
systemd_cgroup = true
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
|
||||
...
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
|
||||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
When using kubeadm, manually configure the
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa
|
|||
|
||||
{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0-beta.2+ can also be used as the container runtime for Windows Kubernetes nodes.
|
||||
|
||||
Initial support for ContainerD on Windows was added in Kubernetes v1.18. Progress for ContainerD on Windows can be tracked at [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001).
|
||||
Initial support for ContainerD on Windows was added in Kubernetes v1.18. Progress for ContainerD on Windows can be tracked at [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001).
|
||||
|
||||
Learn how to [install ContainerD on a Windows](/docs/setup/production-environment/container-runtimes/#install-containerd).
|
||||
|
||||
|
|
@ -603,7 +603,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
|
|||
|
||||
In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accommodate worker containers crashing or restarting without losing any of the networking configuration.
|
||||
|
||||
The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat).
|
||||
The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile).
|
||||
|
||||
### Further investigation
|
||||
|
||||
|
|
|
|||
|
|
@ -47,17 +47,10 @@ Pod:
|
|||
envar-demo 1/1 Running 0 9s
|
||||
```
|
||||
|
||||
1. Get a shell to the container running in your Pod:
|
||||
1. List the Pod's container environment variables:
|
||||
|
||||
```shell
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
```
|
||||
|
||||
1. In your shell, run the `printenv` command to list the environment variables.
|
||||
|
||||
```shell
|
||||
# Run this in the shell inside the container
|
||||
printenv
|
||||
kubectl exec envar-demo -- printenv
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
|
@ -71,8 +64,6 @@ Pod:
|
|||
DEMO_FAREWELL=Such a sweet sorrow
|
||||
```
|
||||
|
||||
1. To exit the shell, enter `exit`.
|
||||
|
||||
{{< note >}}
|
||||
The environment variables set using the `env` or `envFrom` field
|
||||
override any environment variables specified in the container image.
|
||||
|
|
@ -122,4 +113,3 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
|
|||
* Learn about [using secrets as environment variables](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables).
|
||||
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -61,9 +61,7 @@ Markdown doesn't have strict rules about how to process lists. When we moved
|
|||
from Jekyll to Hugo, we broke some lists. To fix them, keep the following in
|
||||
mind:
|
||||
|
||||
- Make sure you indent sub-list items **4 spaces** rather than the 2 that you
|
||||
may be used to. Counter-intuitively, you need to indent block-level content
|
||||
within a list item an extra 4 spaces too.
|
||||
- Make sure you indent sub-list items **2 spaces**.
|
||||
|
||||
- To end a list and start another, you need a HTML comment block on a new line
|
||||
between the lists, flush with the left-hand border. The first list won't end
|
||||
|
|
@ -74,10 +72,9 @@ mind:
|
|||
- This is a list item
|
||||
* This is another list item in the same list
|
||||
- You can mix `-` and `*`
|
||||
- To make a sub-item, indent two tabstops (4 spaces). **This is different
|
||||
from Jekyll and Kramdown.**
|
||||
- This is a sub-sub-item. Indent two more tabstops (4 more spaces).
|
||||
- Another sub-item.
|
||||
- To make a sub-item, indent two spaces.
|
||||
- This is a sub-sub-item. Indent two more spaces.
|
||||
- Another sub-item.
|
||||
|
||||
<!-- separate lists -->
|
||||
|
||||
|
|
@ -85,15 +82,15 @@ mind:
|
|||
consecutive lists. **The HTML comment needs to be at the left margin.**
|
||||
- Bullet lists can have paragraphs or block elements within them.
|
||||
|
||||
Indent the content to be one tab stop beyond the text of the bullet
|
||||
point. **This paragraph and the code block line up with the second `l` in
|
||||
`Bullet` above.**
|
||||
Indent the content to be the same as the first line of the bullet point.
|
||||
**This paragraph and the code block line up with the first `B` in `Bullet`
|
||||
above.**
|
||||
|
||||
```bash
|
||||
ls -l
|
||||
```
|
||||
```bash
|
||||
ls -l
|
||||
```
|
||||
|
||||
- And a sub-list after some block-level content
|
||||
- And a sub-list after some block-level content
|
||||
|
||||
- A bullet list item can contain a numbered list.
|
||||
1. Numbered sub-list item 1
|
||||
|
|
@ -116,13 +113,13 @@ mind:
|
|||
two consecutive lists. **The HTML comment needs to be at the left margin.**
|
||||
2. Numbered lists can have paragraphs or block elements within them.
|
||||
|
||||
Just indent the content to be one tab stop beyond the text of the bullet
|
||||
point. **This paragraph and the code block line up with the `m` in
|
||||
`Numbered` above.**
|
||||
Just indent the content to be the same as the first line of the bullet
|
||||
point. **This paragraph and the code block line up with the `N` in
|
||||
`Numbered` above.**
|
||||
|
||||
```bash
|
||||
ls -l
|
||||
```
|
||||
```bash
|
||||
ls -l
|
||||
```
|
||||
|
||||
- And a sub-list after some block-level content. This is at the same
|
||||
"level" as the paragraph and code block above, despite being indented
|
||||
|
|
@ -178,13 +175,6 @@ back-ticks (code fences) for code blocks.** This allows you to specify the
|
|||
language of the enclosed code, which enables syntax highlighting. It is also more
|
||||
predictable than using indentation.
|
||||
|
||||
{{< warning >}}
|
||||
There is one situation where you need to use indentation for code blocks: when
|
||||
the contents of the code block contain lines starting with `-` or `*` characters.
|
||||
This is due to
|
||||
[blackfriday issue #239](https://github.com/russross/blackfriday/issues/239).
|
||||
{{< /warning >}}
|
||||
|
||||
```
|
||||
this is a code block created by back-ticks
|
||||
```
|
||||
|
|
@ -241,7 +231,7 @@ character. The square brackets contain the image's alt text. Try to always use
|
|||
alt text so that people using screen readers can get some benefit from the
|
||||
image.
|
||||
|
||||
|
||||
|
||||
|
||||
To specify extended attributes, such as width, title, caption, etc, use the
|
||||
<a href="https://gohugo.io/content-management/shortcodes/#figure">figure shortcode</a>,
|
||||
|
|
@ -249,17 +239,17 @@ which is preferred to using a HTML `<img>` tag. Also, if you need the image to
|
|||
also be a hyperlink, use the `link` attribute, rather than wrapping the whole
|
||||
figure in Markdown link syntax as shown below.
|
||||
|
||||
{{< figure src="/static/images/pencil.png" title="Pencil icon" caption="Image used to illustrate the figure shortcode" width="200px" >}}
|
||||
{{< figure src="/images/pencil.png" title="Pencil icon" caption="Image used to illustrate the figure shortcode" width="200px" >}}
|
||||
|
||||
Even if you choose not to use the figure shortcode, an image can also be a link. This
|
||||
time the pencil icon links to the Kubernetes website. Outer square brackets enclose
|
||||
the entire image tag, and the link target is in the parentheses at the end.
|
||||
|
||||
[](https://kubernetes.io)
|
||||
[](https://kubernetes.io)
|
||||
|
||||
You can also use HTML for images, but it is not preferred.
|
||||
|
||||
<img src="/static/images/pencil.png" alt="pencil icon" />
|
||||
<img src="/images/pencil.png" alt="pencil icon" />
|
||||
|
||||
|
||||
## Tables
|
||||
|
|
|
|||
|
|
@ -205,13 +205,13 @@ apiVersion: kubescheduler.config.k8s.io/v1alpha2
|
|||
kind: KubeSchedulerConfiguration
|
||||
|
||||
profiles:
|
||||
pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: failure-domain.beta.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
- pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -249,13 +249,13 @@ apiVersion: kubescheduler.config.k8s.io/v1alpha2
|
|||
kind: KubeSchedulerConfiguration
|
||||
|
||||
profiles:
|
||||
pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: failure-domain.beta.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
- pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -295,13 +295,13 @@ apiVersion: kubescheduler.config.k8s.io/v1beta1
|
|||
kind: KubeSchedulerConfiguration
|
||||
|
||||
profiles:
|
||||
pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
- pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: topology.kubernetes.io/zone
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -862,7 +862,7 @@ to effectively limit access to the specified `pathPrefix`.
|
|||
|
||||
{{< warning >}}
|
||||
容器如果对宿主文件系统拥有不受限制的访问权限，就可以有很多种方式提升自己的特权，
|
||||
包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）`的凭据信息等。
|
||||
包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）的凭据信息等。
|
||||
|
||||
由可写入的目录所构造的 `hostPath` 卷能够允许容器写入数据到宿主文件系统，
|
||||
并且在写入时避开 `pathPrefix` 所设置的目录限制。
|
||||
|
|
|
|||
|
|
@ -455,7 +455,7 @@ Some language teams have their own language-specific style guide and glossary. F
|
|||
### 特定语言的样式指南和词汇表
|
||||
|
||||
一些语言团队有自己的特定语言样式指南和词汇表。
|
||||
例如，请参见[韩语本地化指南](/ko/docs/contribute/localization_ko/)。
|
||||
例如，请参见[中文本地化指南](/zh/docs/contribute/localization_zh/)。
|
||||
|
||||
<!--
|
||||
## Branching strategy
|
||||
|
|
|
|||
|
|
@ -0,0 +1,465 @@
|
|||
---
|
||||
title: 中文本地化样式指南
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
本节详述文档中文本地化过程中须注意的事项。
|
||||
这里列举的内容包含了*中文本地化小组*早期给出的指导性建议和后续实践过程中
|
||||
积累的经验。
|
||||
在阅读、贡献、评阅中文本地化文档的过程中，如果对本文的指南有任何改进建议，
|
||||
都请直接提出 PR。我们欢迎任何形式的补充和更正！
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 一般规定
|
||||
|
||||
本节列举一些译文中常见问题和约定。
|
||||
|
||||
### 英文原文的保留
|
||||
|
||||
为便于译文审查和变更追踪，所有中文本地化 Markdown 文件中都应使用 HTML 注释
|
||||
`<!--` 和 `-->` 将英文原文逐段注释起来，后跟对应中文译文。例如：
|
||||
|
||||
```
|
||||
<!--
|
||||
This is English text ...
|
||||
-->
|
||||
中文译文对应 ...
|
||||
```
|
||||
|
||||
不建议采用下面的方式注释英文段落，除非英文段落非常非常短：
|
||||
|
||||
```
|
||||
<!-- This is English text ... -->
|
||||
中文译文对应 ...
|
||||
|
||||
```
|
||||
|
||||
无论英文原文或者中文译文中，都不要保留过多的、不必要的空白行。
|
||||
|
||||
#### 段落划分
|
||||
|
||||
请避免大段大段地注释和翻译。一般而言，每段翻译可对应两三个自然段。
|
||||
段落过长会导致译文很难评阅。但也不必每个段落都单独翻译。例如：
|
||||
|
||||
```
|
||||
<!--
|
||||
## Overview
|
||||
|
||||
### Concept
|
||||
|
||||
First paragraph, not very long.
|
||||
-->
|
||||
## 概述 {#overview}
|
||||
|
||||
### 概念 {#concept}
|
||||
|
||||
第一段落，不太长。
|
||||
```
|
||||
|
||||
以下风格是不必要的：
|
||||
|
||||
```
|
||||
<!--
|
||||
## Overview
|
||||
-->
|
||||
## 概述 {#overview}
|
||||
|
||||
<!--
|
||||
### Concept
|
||||
-->
|
||||
### 概念 {#concept}
|
||||
|
||||
<!--
|
||||
First paragraph, not very long.
|
||||
-->
|
||||
第一段落，不太长。
|
||||
```
|
||||
|
||||
#### 编号列表的处理
|
||||
|
||||
编号列表需要编号的连续性，处理不好的话可能导致输出结果错误。
|
||||
由于有些列表可能很长，一次性等将整个列表注释掉再翻译也不现实。
|
||||
推荐采用下面的方式。
|
||||
|
||||
假定英文为：
|
||||
|
||||
```
|
||||
1. Prepare something
|
||||
1. Followed by a long step with code snippets and notes ...
|
||||
this is a really long item
|
||||
1. Another long item ...
|
||||
.. continues here
|
||||
1. Almost done ...
|
||||
```
|
||||
|
||||
本地化处理：
|
||||
|
||||
```
|
||||
<!--
|
||||
1. Prepare something
|
||||
-->
|
||||
1. 准备工作，...
|
||||
这里每行缩进 3 个空格
|
||||
|
||||
<!--
|
||||
1. Followed by a long step with code snippets and notes ...
|
||||
this is a really long item
|
||||
-->
|
||||
2. 这里是第二个编号，但需要显式给出数字，不能沿用英文编号。
|
||||
缩进内容同上，3 个空格。
|
||||
即使有三个反引号的代码段或者短代码，都按 3 个空格缩进。
|
||||
|
||||
<!--
|
||||
1. Another long item ...
|
||||
.. continues here
|
||||
1. Almost done ...
|
||||
-->
|
||||
3. 继续列表。
|
||||
|
||||
如果条目有多个段落，也要
|
||||
保持缩进对齐以确保排版正确。
|
||||
|
||||
4. 列表终于结束
|
||||
```
|
||||
|
||||
#### Frontmatter 的处理
|
||||
|
||||
页面中的 Frontmatter 指的是文件头的两个 `---` 中间的部分。
|
||||
对这一部分，解析器有特殊处理，因此不能将英文部分放在前面，中文跟在后面。
|
||||
需要将二者顺序颠倒。如下所示：
|
||||
|
||||
```
|
||||
---
|
||||
title: 译文标题
|
||||
type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
title: English title
|
||||
type: concept
|
||||
reviewers:
|
||||
- john
|
||||
- doe
|
||||
weight: 30
|
||||
-->
|
||||
```
|
||||
|
||||
这里要注意的是：
|
||||
|
||||
- `title`、`description` 的内容要翻译，其他字段一般不必（甚至不可）翻译。
|
||||
- `reviewers` 部分要删除，不然中文译文会转给英文作者来审阅。
|
||||
|
||||
|
||||
#### 短代码（shortcode）处理
|
||||
|
||||
通过 HTML 注释的短代码仍会被运行，因此需要额外小心。建议处理方式：
|
||||
|
||||
```
|
||||
<!--
|
||||
English text
|
||||
-->
|
||||
{{</* note */>}}
|
||||
中文译文
|
||||
{{</* /note */>}}
|
||||
```
|
||||
|
||||
评阅人应该不难理解中英文段落的对应关系。但是如果采用下面的方式，则会出现
|
||||
两个 `note`，因此需要避免。这是因为被注释起来的短代码仍会起作用！
|
||||
|
||||
```
|
||||
<!--
|
||||
{{</* note */>}}
|
||||
English text
|
||||
{{</* /note */>}}
|
||||
-->
|
||||
{{</* note */>}}
|
||||
中文译文
|
||||
{{</* /note */>}}
|
||||
```
|
||||
|
||||
### 译与不译
|
||||
|
||||
#### 资源名称或字段不译
|
||||
|
||||
根据英文原文写作风格约定【也在持续修订改进】，对 Kubernetes 中的 API
|
||||
资源均按其规范中所给的大小写形式书写，例如：英文中会使用 Deployment 而不是
|
||||
deployment 来表示名为 "Deployment" 的 API 资源类型和对象实例。
|
||||
|
||||
对这类词语，一般不应翻译。
|
||||
|
||||
{{< note >}}
|
||||
英文原文在这方面并不严谨，译者或中文译文的评阅者要非常留心。
|
||||
比如 Secret 资源，很多时候被误写为 secret。这时在本地化版本中一定
|
||||
不能译为“秘密”，以免与原文的语义不符。
|
||||
{{< /note >}}
|
||||
|
||||
#### 代码中的注释
|
||||
|
||||
一般而言，代码中的注释需要翻译，包括存放在 `content/zh/examples/` 目录下
|
||||
的清单文件中的注释。
|
||||
|
||||
|
||||
#### 出站链接
|
||||
|
||||
如果超级链接的目标是 Kubernetes 网站之外的纯英文网页，链接中的内容*可以*不翻译。
|
||||
例如：
|
||||
|
||||
```
|
||||
<!--
|
||||
Please check [installation caveats](https://acme.com/docs/v1/caveats) ...
|
||||
-->
|
||||
请参阅 [installation caveats](https://acme.com/docs/v1/caveats) ...
|
||||
```
|
||||
|
||||
注意，这里的 `installation` 与 `参阅` 之间留白，因为解析后属于中英文混排的情况。
|
||||
|
||||
### 标点符号
|
||||
|
||||
译文中标点符号要使用全角字符，除非以下两种情况：
|
||||
|
||||
- 标点符号是英文命令的一部分；
|
||||
- 标点符号是 Markdown 语法的一部分。
|
||||
|
||||
英文排比句式中采用的逗号，在译文中要使用顿号代替，复合中文书写习惯。
|
||||
|
||||
## 关于链接
|
||||
|
||||
### 链接锚点
|
||||
|
||||
英文 Markdown 中的各级标题会自动生成锚点，以便从其他页面中链接。
|
||||
在译为中文后，相应的链接必然会失效。为防止这类问题，建议在翻译
|
||||
各级标题时，使用英文方式显式给出链接锚点。例如：
|
||||
|
||||
```
|
||||
<!--
|
||||
### Create a Pod
|
||||
-->
|
||||
### 创建 Pod {#create-a-pod}
|
||||
```
|
||||
|
||||
此类问题对于概念部分的页面最为突出，需要格外注意。
|
||||
|
||||
|
||||
### 中文链接目标
|
||||
|
||||
由于大部分页面已经完成中文本地化，这意味着很多链接可以使用中文版本作为目标。
|
||||
例如：
|
||||
|
||||
```
|
||||
<!--
|
||||
For more information, please check [volumes](/docs/concepts/storage/)
|
||||
...
|
||||
-->
|
||||
更多的信息可参考[卷](/zh/docs/concepts/storage/)页面。
|
||||
```
|
||||
|
||||
如果对应目标页面尚未本地化，建议登记一个 Issue。
|
||||
|
||||
{{< note >}}
|
||||
Website 的仓库中 `scripts/linkchecker.py` 是一个工具，可用来检查页面中的链接。
|
||||
例如，下面的命令检查中文本地化目录 `/content/zh/docs/concepts/containers/`
|
||||
中所有 Markdown 文件中的链接合法性：
|
||||
|
||||
```
|
||||
./scripts/linkchecker.py -l zh -f /docs/concepts/containers/**/*.md
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
## 排版格式
|
||||
|
||||
以下为译文 Markdown 排版格式要求：
|
||||
|
||||
- 中英文之间留一个空格
|
||||
* 这里的“英文”包括以英文呈现的超级链接
|
||||
* 这里的中文、英文都不包括标点符号
|
||||
- 译文 Markdown 中不要使用长行，应适当断行。
|
||||
* 可根据需要在 80-120 列断行
|
||||
* 最好结合句子的边界断行，即一句话在一行，不必留几个字转到下一行
|
||||
* 超级链接文字一般较长，可独立成行
|
||||
|
||||
{{< warning >}}
|
||||
我们注意到有些贡献者可能使用了某种自动化工具，在 Markdown 英文原文中自动
|
||||
添加空格。虽然这些工具可一定程度提高效率，仍然需要提请作者注意，某些工具
|
||||
所作的转换可能是不对的，例如将 `foo=bar` 转换为 `foo = bar`、将
|
||||
`），另一些文字` 转换为 `） ，另一些文字` 等等，甚至将超级链接中的半角
|
||||
井号（`#`）转换为全角，导致链接失效。
|
||||
{{< /warning >}}
|
||||
|
||||
英文中 "you" 翻译成 "你" 不必是 “您"
|
||||
文章内的链接用英文例如 (#deploying )，在对应的标题上后面加上 {#deploying}
|
||||
|
||||
|
||||
## 术语
|
||||
|
||||
### 术语拼写
|
||||
|
||||
按中文译文习惯，尽量不要在中文译文中使用首字母小写的拼写。例如：
|
||||
|
||||
```
|
||||
列举所有 pods，查看其创建时间 ... [No]
|
||||
列举所有 Pod，查看其创建时间 ... [Yes]
|
||||
```
|
||||
|
||||
*第一次*使用首字母缩写时，应标注其全称和中文译文。例如：
|
||||
|
||||
```
|
||||
你可以创建一个 Pod 干扰预算（Pod Disruption Budget，PDB）来解决这一问题。
|
||||
所谓 PDB 实际上是 ...
|
||||
```
|
||||
|
||||
对于某些特定于 Kubernetes 语境的术语，也应在*第一次*出现在页面中时给出其英文原文，
|
||||
以便读者对照阅读。例如：
|
||||
|
||||
```
|
||||
镜像策略（Image Policy）用来控制集群可拉取的镜像仓库（Image Registry）源。
|
||||
```
|
||||
|
||||
### 术语对照
|
||||
|
||||
本节列举常见术语的统一译法。除极个别情况，对于专业术语应使用本节所列举的译法：
|
||||
|
||||
- API Server，API 服务器
|
||||
- GA (general availability)，正式发布
|
||||
- addons，插件
|
||||
- admission controller，准入控制器
|
||||
- affinity，亲和性
|
||||
- annotation，注解
|
||||
- anti-affinity，反亲和性
|
||||
- attach，挂接
|
||||
- autoscale，自动扩缩容
|
||||
- bearer token，持有者令牌
|
||||
- capabilities权能字
|
||||
* 当泛指某主体执行某操作的能力时，可直译为“能力”
|
||||
* 当特指 Linux 操作系统上的[权限控制](http://man7.org/linux/man-pages/man7/capabilities.7.html)机制时，译为“权能字”
|
||||
- certificate authority，证书机构
|
||||
- certificate，证书
|
||||
- claim，申领
|
||||
- cloud provider
|
||||
* 当用来指代下层云服务的提供厂商时，译为“云服务供应商”
|
||||
* 当特指 Kubernetes 中对不同云平台的支持时，可酌情译为“云驱动”
|
||||
- cluster，集群
|
||||
- condition
|
||||
* 大多数上下文中，可译为“条件”
|
||||
* 在讨论 Kubernetes 资源的 condition 时，应译为“状况”
|
||||
- control loop，控制回路
|
||||
- control plane，控制平面，或控制面
|
||||
- controller，控制器
|
||||
- controller manager，控制器管理器
|
||||
- credential，登录凭据，凭据
|
||||
- custom，定制，或自定义
|
||||
- daemon，守护进程
|
||||
- dashboard，仪表板
|
||||
- dependent，附属或附属者
|
||||
- deprecated，已弃用的
|
||||
- deprecation，弃用
|
||||
- desired，预期的
|
||||
- desired state，预期状态
|
||||
- detach，解除挂接
|
||||
- distribution，发行版本
|
||||
- disruption，干扰（请勿译为“中断”）
|
||||
- drain，腾空
|
||||
- endpoint，端点
|
||||
- egress，出站
|
||||
- evict，驱逐
|
||||
- eviction，驱逐
|
||||
- feature gate，特性门控
|
||||
- federation，联邦
|
||||
- flags，命令行参数，参数
|
||||
- grace period，宽限期限
|
||||
- graceful termination，体面终止
|
||||
- hairpin，发夹
|
||||
- hash，哈希
|
||||
- headless service，无头服务
|
||||
- healthcheck，健康检查
|
||||
- hook，回调
|
||||
- host，主机，宿主机
|
||||
- hosting，托管
|
||||
- idempotent，幂等的
|
||||
- image，镜像
|
||||
- image registry，镜像仓库
|
||||
- ingress，入站
|
||||
- init container，Init 容器
|
||||
- key
|
||||
* 在加密解密、安全认证上下文中，译为密钥
|
||||
* 在配置文件、数据结构上下文中，译为主键，或键
|
||||
- label，标签
|
||||
- label selector，标签选择算符
|
||||
- lifecycle，生命周期
|
||||
- limit，限制，限值
|
||||
- liveness probe，存活态探针
|
||||
- load balance，负载均衡
|
||||
- load balancer，负载均衡器
|
||||
- log flush，清刷日志数据
|
||||
- loopback，本地回路
|
||||
- manifest，清单，清单文件
|
||||
- master node，主控节点
|
||||
- metric
|
||||
* 用来指代被测量的数据源时，译为指标
|
||||
* 用来指代测量观测结果时，译为度量值
|
||||
- mount，挂载
|
||||
- namespace，名字空间，命名空间
|
||||
- orphans，孤立或孤立的
|
||||
- override，覆写
|
||||
- owner，所有者，属主
|
||||
- pending，悬决的
|
||||
- persistent volume，持久卷
|
||||
- persistent volume claim，持久卷申领
|
||||
- pipeline，流水线
|
||||
- prerequisites，依赖，前提条件（根据上下文判断）
|
||||
- priority class，优先级类
|
||||
- probe，探针
|
||||
- provision，供应
|
||||
- pull，拉取
|
||||
- push，推送
|
||||
- quota，配额
|
||||
- readiness probe，就绪态探针
|
||||
- replica，副本
|
||||
- repo，仓库
|
||||
- repository，仓库
|
||||
- revision，修订版本
|
||||
- role，角色
|
||||
- role binding，角色绑定
|
||||
- rolling update，滚动更新
|
||||
- rollout，上线
|
||||
- rotate，轮换
|
||||
- round robin，轮转
|
||||
- runtime，运行时
|
||||
- scale in/out，横向缩容/扩容
|
||||
- scale up/down，纵向扩容/缩容
|
||||
- scale
|
||||
* 做动词用时，译为“扩缩”，或者“改变...的规模”
|
||||
* 做名词用时，译为“规模”
|
||||
- scheduler，调度器
|
||||
- service，服务
|
||||
- service account，服务账号
|
||||
- service account token，服务账号令牌
|
||||
- service discovery，服务发现
|
||||
- service mesh，服务网格
|
||||
- session，会话
|
||||
- sidecar，挂斗
|
||||
- skew，偏移
|
||||
- spec，规约
|
||||
- specification，规约
|
||||
- startup probe，启动探针
|
||||
- stateless，无状态的
|
||||
- static pod，静态 Pod
|
||||
- stderr，标准错误输出
|
||||
- stdin，标准输入
|
||||
- stdout，标准输出
|
||||
- storage class，存储类
|
||||
- taint，污点
|
||||
- threshold，阈值
|
||||
- toleration，容忍度
|
||||
- topology，拓扑
|
||||
- topology spread constraint，拓扑分布约束
|
||||
- traffic，流量
|
||||
* 在某些上下文中，可以根据情况译为“服务请求”，“服务响应”
|
||||
- unmount，卸载
|
||||
- use case，用例，使用场景
|
||||
- volume，卷
|
||||
- worker node，工作节点
|
||||
- workload，工作负载
|
||||
|
|
@ -24,7 +24,7 @@ See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Gu
|
|||
|
||||
This page is an overview of the `kubectl` command.
|
||||
-->
|
||||
另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
|
||||
另见: [Kubectl 概述](/zh/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/zh/docs/reference/kubectl/jsonpath)。
|
||||
|
||||
本页面是 `kubectl` 命令的概述。
|
||||
|
||||
|
|
@ -85,15 +85,15 @@ detailed config file information.
|
|||
## Kubectl 上下文和配置
|
||||
|
||||
设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看
|
||||
[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
[使用 kubeconfig 跨集群授权访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
文档获取配置文件详细信息。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
``bash
|
||||
kubectl config view # Show Merged kubeconfig settings.
|
||||
|
||||
# use multiple kubeconfig files at the same time and view merged config
|
||||
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
|
||||
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
|
||||
|
||||
kubectl config view
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
|||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # display the first user
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # get a list of users
|
||||
kubectl config get-contexts # display list of contexts
|
||||
kubectl config get-contexts # display list of contexts
|
||||
kubectl config current-context # display the current-context
|
||||
kubectl config use-context my-cluster-name # set the default context to my-cluster-name
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ kubectl config set-context --current --namespace=ggckad-s2
|
|||
# set a context utilizing a specific username and namespace.
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
|
||||
kubectl config unset users.foo # delete user foo
|
||||
```
|
||||
-->
|
||||
|
|
@ -402,7 +402,7 @@ kubectl diff -f ./my-manifest.yaml
|
|||
<!--
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
|
||||
kubectl rollout history deployment/frontend # Check the history of deployments including the revision
|
||||
kubectl rollout history deployment/frontend # Check the history of deployments including the revision
|
||||
kubectl rollout undo deployment/frontend # Rollback to the previous deployment
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # Rollback to a specific revision
|
||||
kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion
|
||||
|
|
@ -426,7 +426,7 @@ kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a
|
|||
-->
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像
|
||||
kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本
|
||||
kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本
|
||||
kubectl rollout undo deployment/frontend # 回滚到上次部署版本
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本
|
||||
kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成
|
||||
|
|
@ -465,13 +465,13 @@ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/
|
|||
# Disable a deployment livenessProbe using a json patch with positional arrays
|
||||
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
|
||||
|
||||
# Add a new element to a positional array
|
||||
# Add a new element to a positional array
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
# 部分更新某节点
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
# 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
|
|
@ -482,7 +482,7 @@ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/
|
|||
# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe
|
||||
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
|
||||
|
||||
# 在带位置数组中添加元素
|
||||
# 在带位置数组中添加元素
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
```
|
||||
|
||||
|
|
@ -567,7 +567,7 @@ kubectl logs -f my-pod # stream pod logs (stdout)
|
|||
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
|
||||
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
|
||||
kubectl run nginx --image=nginx -n
|
||||
kubectl run nginx --image=nginx -n
|
||||
mynamespace # Run pod nginx in a specific namespace
|
||||
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
|
||||
--dry-run=client -o yaml > pod.yaml
|
||||
|
|
@ -641,7 +641,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
|
|||
<!--
|
||||
List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
|
||||
-->
|
||||
列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
列出所支持的全部资源类型和它们的简称、[API 组](/zh/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/zh/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
|
||||
```bash
|
||||
kubectl api-resources
|
||||
|
|
@ -697,8 +697,8 @@ utput format | Description
|
|||
`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列来打印表格
|
||||
`-o=custom-columns-file=<filename>` | 使用 `<filename>` 文件中的自定义列模板打印表格
|
||||
`-o=json` | 输出 JSON 格式的 API 对象
|
||||
`-o=jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式中定义的字段
|
||||
`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式所指定的字段。
|
||||
`-o=jsonpath=<template>` | 打印 [jsonpath](/zh/docs/reference/kubectl/jsonpath) 表达式中定义的字段
|
||||
`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/zh/docs/reference/kubectl/jsonpath) 表达式所指定的字段。
|
||||
`-o=name` | 仅打印资源名称而不打印其他内容
|
||||
`-o=wide` | 以纯文本格式输出额外信息，对于 Pod 来说，输出中包含了节点名称
|
||||
`-o=yaml` | 输出 YAML 格式的 API 对象
|
||||
|
|
@ -732,7 +732,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
|
|||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
```
|
||||
|
||||
有关更多示例，请参看 kubectl [参考文档](/docs/reference/kubectl/overview/#custom-columns)。
|
||||
有关更多示例，请参看 kubectl [参考文档](/zh/docs/reference/kubectl/overview/#custom-columns)。
|
||||
|
||||
<!--
|
||||
### Kubectl output verbosity and debugging
|
||||
|
|
@ -778,8 +778,7 @@ Verbosity | Description
|
|||
* Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
|
||||
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
|
||||
-->
|
||||
* 进一步了解 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
* 参阅 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
|
||||
* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。
|
||||
* 进一步了解 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。
|
||||
* 参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 选项.
|
||||
* 参阅 [kubectl 使用约定](/zh/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。
|
||||
* 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ For `kubectl run` to satisfy infrastructure as code:
|
|||
* Switch to configuration files checked into source control for features that are needed, but not expressible via `kubectl run` flags.
|
||||
-->
|
||||
|
||||
* 使用特定版本的标签标记镜像，不要将该标签移动到新版本。例如，使用 `:v1234`、`v1.2.3`、`r03062016-1-4`，而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/docs/concepts/configuration/overview/#container-images))。
|
||||
* 使用特定版本的标签标记镜像，不要将该标签移动到新版本。例如，使用 `:v1234`、`v1.2.3`、`r03062016-1-4`，而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/zh/docs/concepts/configuration/overview/#container-images))。
|
||||
* 固定到特定的[生成器](#生成器)版本，例如 `kubectl run --generator=run-pod/v1`。
|
||||
* 使用基于版本控制的脚本来记录所使用的参数，或者至少使用 `--record` 参数以便为所创建的对象添加注解，在使用轻度参数化的镜像时，记录下所使用的命令行。
|
||||
* 使用基于版本控制的脚本来运行包含大量参数的镜像。
|
||||
|
|
@ -156,5 +156,3 @@ You can use the `--dry-run` flag to preview the object that would be sent to you
|
|||
-->
|
||||
|
||||
* 您可以使用 `kubectl apply` 命令创建或更新资源。有关使用 kubectl apply 更新资源的详细信息，请参阅 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ kubectl 管理控制 Kubernetes 集群。
|
|||
<!--
|
||||
Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
|
||||
-->
|
||||
获取更多信息，请访问 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
获取更多信息，请访问 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。
|
||||
|
||||
```
|
||||
kubectl [flags]
|
||||
|
|
@ -581,6 +581,3 @@ kubectl [flags]
|
|||
* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - 标记节点为可调度的
|
||||
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - 打印客户端和服务器的版本信息
|
||||
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - 实验性：等待一个或多个资源达到某种状态
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -27,12 +27,12 @@ card:
|
|||
<!--
|
||||
Kubectl is a command line interface for running commands against Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
|
||||
-->
|
||||
Kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。`kubectl` 在 $HOME/.kube 目录中寻找一个名为 config 的文件。您可以通过设置环境变量 KUBECONFIG 或设置 [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数指定其它 [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。
|
||||
Kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。`kubectl` 在 $HOME/.kube 目录中寻找一个名为 config 的文件。您可以通过设置环境变量 KUBECONFIG 或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。
|
||||
|
||||
<!--
|
||||
This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
|
||||
-->
|
||||
本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。有关每个命令的详细信息，包括所有受支持的参数和子命令，请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。有关安装说明，请参见 [安装 kubectl](/docs/tasks/kubectl/install/) 。
|
||||
本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。有关每个命令的详细信息，包括所有受支持的参数和子命令，请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。有关安装说明，请参见 [安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 。
|
||||
|
||||
|
||||
|
||||
|
|
@ -79,22 +79,22 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
|
|||
|
||||
When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files:
|
||||
-->
|
||||
|
||||
* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
|
||||
|
||||
在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件：
|
||||
* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
|
||||
|
||||
在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件：
|
||||
|
||||
<!--
|
||||
* To specify resources by type and name:
|
||||
|
||||
|
||||
* To group resources if they are all the same type: `TYPE1 name1 name2 name<#>`.<br/>
|
||||
Example: `kubectl get pod example-pod1 example-pod2`
|
||||
|
||||
|
||||
* To specify multiple resource types individually: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
|
||||
Example: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
|
||||
|
||||
* To specify resources with one or more files: `-f file1 -f file2 -f file<#>`
|
||||
|
||||
|
||||
* [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-config-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
|
||||
Example: `kubectl get pod -f ./pod.yaml`
|
||||
|
||||
|
|
@ -102,16 +102,16 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
|
|||
-->
|
||||
|
||||
* 要按类型和名称指定资源：
|
||||
|
||||
|
||||
* 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。<br/>
|
||||
例子：`kubectl get pod example-pod1 example-pod2`
|
||||
|
||||
|
||||
* 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。<br/>
|
||||
例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
|
||||
|
||||
* 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>`
|
||||
|
||||
* [使用 YAML 而不是 JSON](/docs/concepts/configuration/overview/#general-config-tips) 因为 YAML 更容易使用，特别是用于配置文件时。<br/>
|
||||
|
||||
* [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-config-tips) 因为 YAML 更容易使用，特别是用于配置文件时。<br/>
|
||||
例子：`kubectl get pod -f ./pod.yaml`
|
||||
|
||||
* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 Kubernetes API 服务器的地址和端口。<br/>
|
||||
|
|
@ -206,7 +206,7 @@ Operation | Syntax | Description
|
|||
<!--
|
||||
Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
|
||||
-->
|
||||
记住：有关命令操作的更多信息，请参阅 [kubectl](/docs/user-guide/kubectl/) 参考文档。
|
||||
记住：有关命令操作的更多信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。
|
||||
|
||||
<!--
|
||||
## Resource types
|
||||
|
|
@ -353,7 +353,7 @@ The following table includes a list of all the supported resource types and thei
|
|||
<!--
|
||||
Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
|
||||
-->
|
||||
有关如何格式化或排序某些命令的输出的信息，请使用以下部分。有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/docs/user-guide/kubectl/) 参考文档。
|
||||
有关如何格式化或排序某些命令的输出的信息，请使用以下部分。有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。
|
||||
|
||||
<!--
|
||||
### Formatting output
|
||||
|
|
@ -396,8 +396,8 @@ Output format | Description
|
|||
`-o custom-columns=<spec>` | 使用逗号分隔的[自定义列](#custom-columns)列表打印表。
|
||||
`-o custom-columns-file=<filename>` | 使用 `<filename>` 文件中的[自定义列](#custom-columns)模板打印表。
|
||||
`-o json` | 输出 JSON 格式的 API 对象
|
||||
`-o jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath/) 表达式定义的字段
|
||||
`-o jsonpath-file=<filename>` | 打印 `<filename>` 文件中 [jsonpath](/docs/reference/kubectl/jsonpath/) 表达式定义的字段。
|
||||
`-o jsonpath=<template>` | 打印 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式定义的字段
|
||||
`-o jsonpath-file=<filename>` | 打印 `<filename>` 文件中 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式定义的字段。
|
||||
`-o name` | 仅打印资源名称而不打印任何其他内容。
|
||||
`-o wide` | 以纯文本格式输出，包含任何附加信息。对于 pod 包含节点名。
|
||||
`-o yaml` | 输出 YAML 格式的 API 对象。
|
||||
|
|
@ -421,7 +421,7 @@ kubectl get pod web-pod-13je7 -o yaml
|
|||
<!--
|
||||
Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command.
|
||||
-->
|
||||
请记住：有关每个命令支持哪种输出格式的详细信息，请参阅 [kubectl](/docs/user-guide/kubectl/) 参考文档。
|
||||
请记住：有关每个命令支持哪种输出格式的详细信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。
|
||||
|
||||
<!--
|
||||
#### Custom columns
|
||||
|
|
@ -528,7 +528,7 @@ pod-name 1/1 Running 0 1m
|
|||
<!--
|
||||
To output objects to a sorted list in your terminal window, you can add the `--sort-by` flag to a supported `kubectl` command. Sort your objects by specifying any numeric or string field with the `--sort-by` flag. To specify a field, use a [jsonpath](/docs/reference/kubectl/jsonpath/) expression.
|
||||
-->
|
||||
要将对象排序后输出到终端窗口，可以将 `--sort-by` 参数添加到支持的 `kubectl` 命令。通过使用 `--sort-by` 参数指定任何数字或字符串字段来对对象进行排序。要指定字段，请使用 [jsonpath](/docs/reference/kubectl/jsonpath/) 表达式。
|
||||
要将对象排序后输出到终端窗口，可以将 `--sort-by` 参数添加到支持的 `kubectl` 命令。通过使用 `--sort-by` 参数指定任何数字或字符串字段来对对象进行排序。要指定字段，请使用 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式。
|
||||
|
||||
<!--
|
||||
#### Syntax
|
||||
|
|
@ -714,7 +714,7 @@ kubectl delete pods --all
|
|||
```shell
|
||||
# 从 pod <pod-name> 中获取运行 'date' 的输出。默认情况下，输出来自第一个容器。
|
||||
kubectl exec <pod-name> date
|
||||
|
||||
|
||||
# 运行输出 'date' 获取在容器的 <container-name> 中 pod <pod-name> 的输出。
|
||||
kubectl exec <pod-name> -c <container-name> date
|
||||
|
||||
|
|
@ -938,5 +938,3 @@ To find out more about plugins, take a look at the [example cli plugin](https://
|
|||
Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
|
||||
-->
|
||||
开始使用 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 命令。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,398 @@
|
|||
---
|
||||
title: 在谷歌计算引擎上运行 Kubernetes
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- brendandburns
|
||||
- jbeda
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Running Kubernetes on Google Compute Engine
|
||||
content_type: task
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
|
||||
-->
|
||||
下面的示例创建了一个 Kubernetes 集群，其中包含 3 个工作节点虚拟机和 1 个主虚拟机（即集群中有 4 个虚拟机）。
|
||||
这个集群是在你的工作站（或你认为方便的任何地方）设置和控制的。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
|
||||
-->
|
||||
如果你想要一个简化的入门体验和 GUI 来管理集群，
|
||||
请考虑尝试[谷歌 Kubernetes 引擎](https://cloud.google.com/kubernetes-engine/)来安装和管理托管集群。
|
||||
|
||||
<!--
|
||||
For an easy way to experiment with the Kubernetes development environment, click the button below
|
||||
to open a Google Cloud Shell with an auto-cloned copy of the Kubernetes source repo.
|
||||
-->
|
||||
有一个简单的方式可以使用 Kubernetes 开发环境进行实验，
|
||||
就是点击下面的按钮，打开 Google Cloud Shell，其中包含了 Kubernetes 源仓库自动克隆的副本。
|
||||
|
||||
<!--
|
||||
[](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md)
|
||||
-->
|
||||
[](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md)
|
||||
|
||||
<!--
|
||||
If you want to use custom binaries or pure open source Kubernetes, please continue with the instructions below.
|
||||
-->
|
||||
如果你想要使用定制的二进制或者纯开源的 Kubernetes，请继续阅读下面的指导。
|
||||
|
||||
<!-- ### Prerequisites -->
|
||||
### 前提条件 {#prerequisites}
|
||||
|
||||
<!--
|
||||
1. You need a Google Cloud Platform account with billing enabled. Visit the [Google Developers Console](https://console.cloud.google.com) for more details.
|
||||
1. Install `gcloud` as necessary. `gcloud` can be installed as a part of the [Google Cloud SDK](https://cloud.google.com/sdk/).
|
||||
1. Enable the [Compute Engine Instance Group Manager API](https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview) in the [Google Cloud developers console](https://console.developers.google.com/apis/library).
|
||||
1. Make sure that gcloud is set to use the Google Cloud Platform project you want. You can check the current project using `gcloud config list project` and change it via `gcloud config set project <project-id>`.
|
||||
1. Make sure you have credentials for GCloud by running `gcloud auth login`.
|
||||
1. (Optional) In order to make API calls against GCE, you must also run `gcloud auth application-default login`.
|
||||
1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
|
||||
1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
|
||||
-->
|
||||
1. 你需要一个启用了计费的谷歌云平台账号。
|
||||
更多细节请访问[谷歌开发者控制台](https://console.cloud.google.com)。
|
||||
1. 根据需要安装 `gcloud`。
|
||||
`gcloud` 可作为[谷歌云 SDK](https://cloud.google.com/sdk/) 的一部分安装。
|
||||
1. 在[谷歌云开发者控制台](https://console.developers.google.com/apis/library)
|
||||
启用[计算引擎实例组管理器 API](https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview)
|
||||
1. 确保将 gcloud 设置成使用你想要的谷歌云平台项目。
|
||||
你可以使用 `gcloud config list project` 检查当前项目，
|
||||
并通过 `gcloud config set project <project-id>` 修改它。
|
||||
1. 通过运行 `gcloud auth login`，确保你拥有 GCloud 的凭据。
|
||||
1. （可选）如果需要调用 GCE 的 API，你也必须运行 `gcloud auth application-default login`。
|
||||
1. 确保你能通过命令行启动 GCE 虚拟机。
|
||||
至少确保你可以完成 GCE 快速入门的[创建实例](https://cloud.google.com/compute/docs/instances/#startinstancegcloud)部分。
|
||||
1. 确保你在没有交互式提示的情况下 SSH 到虚拟机。
|
||||
查看 GCE 快速入门的[登录实例](https://cloud.google.com/compute/docs/instances/#sshing)部分。
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!-- ## Starting a cluster -->
|
||||
## 启动集群
|
||||
|
||||
<!--
|
||||
You can install a client and start a cluster with either one of these commands (we list both in case only one is installed on your machine):
|
||||
-->
|
||||
你可以安装一个客户端，并使用这些命令的其中之一来启动集群（我们列出的两种情况，因为你的机器可能只安装了二者之一）：
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | bash
|
||||
```
|
||||
|
||||
或
|
||||
|
||||
```shell
|
||||
wget -q -O - https://get.k8s.io | bash
|
||||
```
|
||||
|
||||
<!--
|
||||
Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.
|
||||
-->
|
||||
这条命令结完成后，你将会有 1 个主虚拟机和 4 个工作虚拟机，它们一起作为 Kubernetes 集群运行。
|
||||
|
||||
<!--
|
||||
By default, some containers will already be running on your cluster. Containers like `fluentd` provide [logging](/docs/concepts/cluster-administration/logging/), while `heapster` provides [monitoring](https://releases.k8s.io/master/cluster/addons/cluster-monitoring/README.md) services.
|
||||
-->
|
||||
默认情况下，有一些容器已经在你的集群上运行。
|
||||
像 `fluentd` 这样的容器提供[日志记录](/zh/docs/concepts/cluster-administration/logging/)，
|
||||
而 `heapster` 提供[监控](https://releases.k8s.io/master/cluster/addons/cluster-monitoring/README.md)服务。
|
||||
|
||||
<!--
|
||||
The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once.
|
||||
-->
|
||||
由上述命令运行的脚本创建了一个名称/前缀为“kubernetes”的集群。
|
||||
它定义了一个特定的集群配置，所以此脚本只能运行一次。
|
||||
|
||||
<!--
|
||||
Alternately, you can download and install the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases), then run the `<kubernetes>/cluster/kube-up.sh` script to start the cluster:
|
||||
-->
|
||||
或者，你可以通过[这个页面](https://github.com/kubernetes/kubernetes/releases)下载和安装最新版本的 Kubernetes，
|
||||
然后运行 `<kubernetes>/cluster/kube-up.sh` 脚本启动集群：
|
||||
|
||||
```shell
|
||||
cd kubernetes
|
||||
cluster/kube-up.sh
|
||||
```
|
||||
|
||||
<!--
|
||||
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
|
||||
-->
|
||||
如果你希望在项目中运行多个集群，希望使用一个不同名称，或者不同数量工作节点的集群，
|
||||
请查看 `<kubernetes>/cluster/gce/config-default.sh` 文件，以便在启动集群之前进行更细粒度的配置。
|
||||
|
||||
|
||||
<!--
|
||||
If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
|
||||
[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
|
||||
-->
|
||||
如果你遇到了问题，请参阅[错误排查](#troubleshooting)一节，
|
||||
发布到 [Kubernetes 论坛](https://discuss.kubernetes.io)，或者来 `#gke` Slack 频道中提问。
|
||||
|
||||
<!-- The next few steps will show you: -->
|
||||
接下来的几个步骤会告诉你:
|
||||
|
||||
<!--
|
||||
1. How to set up the command line client on your workstation to manage the cluster
|
||||
2. Examples of how to use the cluster
|
||||
3. How to delete the cluster
|
||||
4. How to start clusters with non-default options (like larger clusters)
|
||||
-->
|
||||
1. 如何在你的工作站设置命令行客户端来管理集群
|
||||
2. 如何使用集群的示例
|
||||
3. 如何删除集群
|
||||
4. 如果以非默认选项启动集群（如规模较大的集群）
|
||||
|
||||
<!-- ## Installing the Kubernetes command line tools on your workstation -->
|
||||
## 在你的工作站安装 Kubernetes 命令行工具
|
||||
|
||||
<!--
|
||||
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
|
||||
-->
|
||||
集群启动脚本将在你的工作站上留下一个正在运行的集群和一个 `kubernetes` 目录。
|
||||
|
||||
<!--
|
||||
The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
|
||||
manager. It lets you inspect your cluster resources, create, delete, and update
|
||||
components, and much more. You will use it to look at your new cluster and bring
|
||||
up example apps.
|
||||
-->
|
||||
[kubectl](/zh/docs/reference/kubectl/kubectl/) 工具控制 Kubernetes 集群管理器。
|
||||
它允许你检查集群资源，创建、删除和更新组件等等。
|
||||
你将使用它来查看新集群并启动示例应用程序。
|
||||
|
||||
<!--
|
||||
You can use `gcloud` to install the `kubectl` command-line tool on your workstation:
|
||||
-->
|
||||
你可以使用 `gcloud` 在工作站上安装 `kubectl` 命令行工具:
|
||||
|
||||
```shell
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The kubectl version bundled with `gcloud` may be older than the one
|
||||
downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
|
||||
document to see how you can set up the latest `kubectl` on your workstation.
|
||||
-->
|
||||
与 `gcloud` 绑定的 kubectl 版本可能比 get.k8s.io 安装脚本所下载的更老。。
|
||||
查看[安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 文档，了解如何在工作站上设置最新的 `kubectl`。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- ## Getting started with your cluster -->
|
||||
## 开始使用你的集群
|
||||
|
||||
<!-- ### Inspect your cluster -->
|
||||
### 检查你的集群
|
||||
|
||||
<!--
|
||||
Once `kubectl` is in your path, you can use it to look at your cluster. E.g., running:
|
||||
-->
|
||||
一旦 `kubectl` 存在于你的路径中，你就可以使用它来查看集群，例如，运行：
|
||||
|
||||
```
|
||||
kubectl get --all-namespaces services
|
||||
```
|
||||
|
||||
<!--
|
||||
should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
|
||||
-->
|
||||
应该显示 [services](/zh/docs/concepts/services-networking/service/) 集合，看起来像这样：
|
||||
|
||||
```
|
||||
NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE
|
||||
default kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1d
|
||||
kube-system kube-dns ClusterIP 10.0.0.2 <none> 53/TCP,53/UDP 1d
|
||||
kube-system kube-ui ClusterIP 10.0.0.3 <none> 80/TCP 1d
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/) that were created during cluster startup.
|
||||
You can do this via the
|
||||
-->
|
||||
类似的，你可以查看在集群启动时创建的 [pods](/zh/docs/concepts/workloads/pods/) 的集合。
|
||||
你可以通过命令：
|
||||
|
||||
```
|
||||
kubectl get --all-namespaces pods
|
||||
```
|
||||
|
||||
<!--
|
||||
You'll see a list of pods that looks something like this (the name specifics will be different):
|
||||
-->
|
||||
你将会看到 Pod 的列表，看起来像这样（名称和细节会有所不同）：
|
||||
|
||||
```
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
kube-system coredns-5f4fbb68df-mc8z8 1/1 Running 0 15m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-63uo 1/1 Running 0 14m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-c1n9 1/1 Running 0 14m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-c4og 1/1 Running 0 14m
|
||||
kube-system fluentd-cloud-logging-kubernetes-minion-ngua 1/1 Running 0 14m
|
||||
kube-system kube-ui-v1-curt1 1/1 Running 0 15m
|
||||
kube-system monitoring-heapster-v5-ex4u3 1/1 Running 1 15m
|
||||
kube-system monitoring-influx-grafana-v1-piled 2/2 Running 0 15m
|
||||
```
|
||||
|
||||
<!--
|
||||
Some of the pods may take a few seconds to start up (during this time they'll show `Pending`), but check that they all show as `Running` after a short period.
|
||||
-->
|
||||
一些 Pod 启动可能需要几秒钟（在此期间它们会显示 `Pending`），
|
||||
但是在短时间后请检查它们是否都显示为 `Running`。
|
||||
|
||||
<!-- ### Run some examples -->
|
||||
### 运行示例
|
||||
|
||||
<!--
|
||||
Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
|
||||
-->
|
||||
那么，看[一个简单的 nginx 示例](/zh/docs/tasks/run-application/run-stateless-application-deployment/)来试试你的新集群。
|
||||
|
||||
<!--
|
||||
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
|
||||
-->
|
||||
要获得完整的应用，请查看 [examples 目录](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)。
|
||||
[guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
|
||||
是一个很好的“入门”演练。
|
||||
|
||||
<!-- ## Tearing down the cluster -->
|
||||
## 拆除集群
|
||||
|
||||
<!-- To remove/delete/teardown the cluster, use the `kube-down.sh` script. -->
|
||||
要移除/删除/拆除集群，请使用 `kube-down.sh` 脚本。
|
||||
|
||||
```shell
|
||||
cd kubernetes
|
||||
cluster/kube-down.sh
|
||||
```
|
||||
|
||||
<!--
|
||||
Likewise, the `kube-up.sh` in the same directory will bring it back up. You do not need to rerun the `curl` or `wget` command: everything needed to setup the Kubernetes cluster is now on your workstation.
|
||||
-->
|
||||
同样地，同一目录下的 `kube-up.sh` 脚本会让集群重新运行起来。
|
||||
你不需要再次运行 `curl` 或 `wget` 命令：现在 Kubernetes 集群所需的一切都在你的工作站上。
|
||||
|
||||
<!-- ## Customizing -->
|
||||
## 定制
|
||||
|
||||
<!--
|
||||
The script above relies on Google Storage to stage the Kubernetes release. It
|
||||
then will start (by default) a single master VM along with 3 worker VMs. You
|
||||
can tweak some of these parameters by editing `kubernetes/cluster/gce/config-default.sh`
|
||||
You can view a transcript of a successful cluster creation
|
||||
[here](https://gist.github.com/satnam6502/fc689d1b46db9772adea).
|
||||
-->
|
||||
上面的脚本依赖于谷歌存储来保存 Kubernetes 发行版本。
|
||||
该脚本然后（默认情况下）会启动 1 个主虚拟机和 3 个工作虚拟机。
|
||||
你可以通过编辑 `kubernetes/cluster/gce/config-default.sh` 来调整这些参数。
|
||||
你可以在[这里](https://gist.github.com/satnam6502/fc689d1b46db9772adea)查看成功创建集群的记录。
|
||||
|
||||
<!-- ## Troubleshooting -->
|
||||
## 故障排除 {#troubleshooting}
|
||||
|
||||
<!-- ### Project settings -->
|
||||
### 项目设置
|
||||
|
||||
<!--
|
||||
You need to have the Google Cloud Storage API, and the Google Cloud Storage
|
||||
JSON API enabled. It is activated by default for new projects. Otherwise, it
|
||||
can be done in the Google Cloud Console. See the [Google Cloud Storage JSON
|
||||
API Overview](https://cloud.google.com/storage/docs/json_api/) for more
|
||||
details.
|
||||
-->
|
||||
你需要启用 Google Cloud Storage API 和 Google Cloud Storage JSON API。
|
||||
默认情况下，对新项目都是激活的。
|
||||
如果未激活，可以在谷歌云控制台设置。
|
||||
更多细节，请查看[谷歌云存储 JSON API 概览](https://cloud.google.com/storage/docs/json_api/)。
|
||||
|
||||
<!--
|
||||
Also ensure that-- as listed in the [Prerequisites section](#prerequisites)-- you've enabled the `Compute Engine Instance Group Manager API`, and can start up a GCE VM from the command line as in the [GCE Quickstart](https://cloud.google.com/compute/docs/quickstart) instructions.
|
||||
-->
|
||||
也要确保——正如在[前提条件](#prerequisites)中列出的那样——
|
||||
你已经启用了 `Compute Engine Instance Group Manager API`，
|
||||
并且可以像 [GCE 快速入门](https://cloud.google.com/compute/docs/quickstart)指导那样从命令行启动 GCE 虚拟机。
|
||||
|
||||
<!-- ### Cluster initialization hang -->
|
||||
### 集群初始化过程停滞
|
||||
|
||||
<!--
|
||||
If the Kubernetes startup script hangs waiting for the API to be reachable, you can troubleshoot by SSHing into the master and node VMs and looking at logs such as `/var/log/startupscript.log`.
|
||||
-->
|
||||
如果 Kubernetes 启动脚本停滞，等待 API 可达，
|
||||
你可以 SSH 登录到主虚拟机和工作虚拟机，
|
||||
通过查看 `/var/log/startupscript.log` 日志来排除故障。
|
||||
|
||||
<!--
|
||||
**Once you fix the issue, you should run `kube-down.sh` to cleanup** after the partial cluster creation, before running `kube-up.sh` to try again.
|
||||
-->
|
||||
**一旦解决了这个问题，你应该在部分集群创建之后运行 `kube-down.sh` 来进行清理**，然后再运行 `kube-up.sh` 重试。
|
||||
|
||||
### SSH
|
||||
|
||||
<!--
|
||||
If you're having trouble SSHing into your instances, ensure the GCE firewall
|
||||
isn't blocking port 22 to your VMs. By default, this should work but if you
|
||||
have edited firewall rules or created a new non-default network, you'll need to
|
||||
expose it: `gcloud compute firewall-rules create default-ssh --network=<network-name>
|
||||
--description "SSH allowed from anywhere" --allow tcp:22`
|
||||
-->
|
||||
如果在 SSH 登录实例时遇到困难，确保 GCE 防火墙没有阻塞你虚拟机的 22 端口。
|
||||
默认情况下应该可用，但是如果你编辑了防火墙规则或者创建了一个新的非默认网络，
|
||||
你需要公开它：`gcloud compute firewall-rules create default-ssh --network=<network-name> --description "SSH allowed from anywhere" --allow tcp:22`
|
||||
|
||||
<!--
|
||||
Additionally, your GCE SSH key must either have no passcode or you need to be
|
||||
using `ssh-agent`.
|
||||
-->
|
||||
此外，你的 GCE SSH 密钥不能有密码，否则你需要使用 `ssh-agent`。
|
||||
|
||||
<!-- ### Networking -->
|
||||
### 网络
|
||||
|
||||
<!--
|
||||
The instances must be able to connect to each other using their private IP. The
|
||||
script uses the "default" network which should have a firewall rule called
|
||||
"default-allow-internal" which allows traffic on any port on the private IPs.
|
||||
If this rule is missing from the default network or if you change the network
|
||||
being used in `cluster/config-default.sh` create a new rule with the following
|
||||
field values:
|
||||
-->
|
||||
虚拟机实例必须能够使用它们的私有 IP 彼此连接。
|
||||
该脚本使用 "default" 网络，此网络应该有一个名为 "default-allow-internal" 的防火墙规则，
|
||||
此规则允许通过私有 IP 上的任何端口进行通信。
|
||||
如果默认网络中缺少此规则，或者更改了 `cluster/config-default.sh` 中使用的网络，
|
||||
用以下字段值创建一个新规则:
|
||||
|
||||
<!--
|
||||
* Source Ranges: `10.0.0.0/8`
|
||||
* Allowed Protocols and Port: `tcp:1-65535;udp:1-65535;icmp`
|
||||
-->
|
||||
* 源范围：`10.0.0.0/8`
|
||||
* 允许的协议和端口：`tcp:1-65535;udp:1-65535;icmp`
|
||||
|
||||
<!-- ## Support Level -->
|
||||
## 支持等级
|
||||
|
||||
<!--
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project
|
||||
-->
|
||||
IaaS 提供商 | 配置管理 | 操作系统 | 网络 | 文档 | 符合率 | 支持等级
|
||||
---------- | --------- | ------ | ---- | --------------------------------------------------------- | ----- | -------
|
||||
GCE | Saltstack | Debian | GCE | [docs](/zh/docs/setup/production-environment/turnkey/gce/) | | Project
|
||||
|
|
@ -250,7 +250,7 @@ To explicitly force all non-cluster DNS lookups to go through a specific nameser
|
|||
指向该域名服务器，而不是 `/etc/resolv.conf`。
|
||||
|
||||
```
|
||||
proxy . 172.16.0.1
|
||||
forward . 172.16.0.1
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ In your shell, create an `index.html` file in the `/usr/share/nginx/html`
|
|||
directory:
|
||||
-->
|
||||
|
||||
在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html 文件：
|
||||
在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html` 文件：
|
||||
|
||||
```shell
|
||||
root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
|
||||
|
|
|
|||
|
|
@ -245,7 +245,7 @@ See [using the command line runtime package](#using-the-command-line-runtime-pac
|
|||
|
||||
Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.
|
||||
-->
|
||||
kubeclt 插件必须解析并检查传递给它们的所有参数。
|
||||
kubectl 插件必须解析并检查传递给它们的所有参数。
|
||||
参阅[使用命令行运行时包](#using-the-command-line-runtime-package)了解针对
|
||||
插件开发人员的 Go 库的细节。
|
||||
|
||||
|
|
@ -261,7 +261,7 @@ would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, kubectl then
|
|||
Upon having found a plugin with this name, kubectl then invokes that plugin, passing all args and flags after the plugin's name as arguments to the plugin process.
|
||||
-->
|
||||
|
||||
如果你运行 `kubectl foo bar baz arg1 --flag=value arg2`，kubeclt 的插件机制将首先尝试找到
|
||||
如果你运行 `kubectl foo bar baz arg1 --flag=value arg2`，kubectl 的插件机制将首先尝试找到
|
||||
最长可能名称的插件，在本例中是 `kubectl-foo-bar-baz-arg1`。
|
||||
当没有找到这个插件时，kubectl 就会将最后一个以破折号分隔的值视为参数（在本例中为 `arg1`），
|
||||
并尝试找到下一个最长的名称 `kubectl-foo-bar-baz`。
|
||||
|
|
|
|||
|
|
@ -1069,7 +1069,7 @@ Kubernetes 源代码中为每个字段定义了 `patchMergeKey`：
|
|||
- name: nginx-helper-d # 键 nginx-helper-d 会被保留
|
||||
image: helper:1.3
|
||||
|
||||
# result after merge
|
||||
# 合并结果
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.16
|
||||
|
|
|
|||
|
|
@ -538,7 +538,7 @@ The patch you did in the preceding exercise is called a *strategic merge patch w
|
|||
-->
|
||||
### 关于使用 retainKeys 策略的策略合并 patch 操作的说明
|
||||
|
||||
在前文练习中所执行的称作 *带 retainKeys` 策略的策略合并 patch（Strategic Merge
|
||||
在前文练习中所执行的称作 *带 `retainKeys` 策略的策略合并 patch（Strategic Merge
|
||||
Patch with retainKeys Strategy）*。
|
||||
这种方法引入了一种新的 `$retainKey` 指令，具有如下策略：
|
||||
|
||||
|
|
@ -651,7 +651,7 @@ and
|
|||
你没有更改最初用于创建 Deployment 对象的配置文件。
|
||||
用于更新 API 对象的其他命令包括
|
||||
[`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate)，
|
||||
[`kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit)，
|
||||
[`kubectl edit`](/docs/reference/generated/kubectl/kubectl-commands/#edit)，
|
||||
[`kubectl replace`](/docs/reference/generated/kubectl/kubectl-commands/#replace)，
|
||||
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)，
|
||||
和
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
|
|||
* Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md).
|
||||
* If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
|
||||
-->
|
||||
* 理解[服务目录](/zh/docs/concepts/service-catalog/) 的关键概念。
|
||||
* 理解[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) 的关键概念。
|
||||
* Service Catalog 需要 Kubernetes 集群版本在 1.7 或更高版本。
|
||||
* 你必须启用 Kubernetes 集群的 DNS 功能。
|
||||
* 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}}，则可能已经启用了集群 DNS。
|
||||
|
|
@ -156,4 +156,3 @@ helm install svc-cat/catalog --name catalog --namespace catalog
|
|||
-->
|
||||
* 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。
|
||||
* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ weight: 10
|
|||
<div class="col-md-8">
|
||||
<h3> Kubernetes 集群</h3>
|
||||
<p>
|
||||
<b> Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。</b> Kubernetes 中的抽象允许您将容器化的应用部署到群集，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。<b> Kubernetes 以更高效的方式跨群集自动分发和调度应用容器。</b> Kubernetes 是一个开源平台，并且可应用于生产环境。
|
||||
<b> Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。</b> Kubernetes 中的抽象允许您将容器化的应用部署到集群，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。<b> Kubernetes 以更高效的方式跨集群自动分发和调度应用容器。</b> Kubernetes 是一个开源平台，并且可应用于生产环境。
|
||||
</p>
|
||||
<p>一个 Kubernetes 集群包含两种类型的资源:
|
||||
<ul>
|
||||
|
|
@ -84,9 +84,9 @@ weight: 10
|
|||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p>在 Kubernetes 上部署应用时，您告诉 Master 启动应用容器。 Master 就编排容器在群集的 Node 上运行。<b> Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。</b>终端用户也可以使用 Kubernetes API 与集群交互。</p>
|
||||
<p>在 Kubernetes 上部署应用时，您告诉 Master 启动应用容器。 Master 就编排容器在集群的 Node 上运行。<b> Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。</b>终端用户也可以使用 Kubernetes API 与集群交互。</p>
|
||||
|
||||
<p> Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。您可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux ， macOS 和 Windows 系统。Minikube CLI 提供了用于引导群集工作的多种操作，包括启动、停止、查看状态和删除。在本教程里，您可以使用预装有 Minikube 的在线终端进行体验。</p>
|
||||
<p> Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。您可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux ， macOS 和 Windows 系统。Minikube CLI 提供了用于引导集群工作的多种操作，包括启动、停止、查看状态和删除。在本教程里，您可以使用预装有 Minikube 的在线终端进行体验。</p>
|
||||
|
||||
<p>既然您已经知道 Kubernetes 是什么，让我们转到在线教程并启动我们的第一个 Kubernetes 集群！</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,722 @@
|
|||
---
|
||||
title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例"
|
||||
content_type: tutorial
|
||||
weight: 21
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 31
|
||||
title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例"
|
||||
---
|
||||
<!--
|
||||
title: "Example: Add logging and metrics to the PHP / Redis Guestbook example"
|
||||
reviewers:
|
||||
- sftim
|
||||
content_type: tutorial
|
||||
weight: 21
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 31
|
||||
title: "Example: Add logging and metrics to the PHP / Redis Guestbook example"
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. Lightweight log, metric, and network data open source shippers, or *Beats*, from Elastic are deployed in the same Kubernetes cluster as the guestbook. The Beats collect, parse, and index the data into Elasticsearch so that you can view and analyze the resulting operational information in Kibana. This example consists of the following components:
|
||||
|
||||
* A running instance of the [PHP Guestbook with Redis tutorial](/docs/tutorials/stateless-application/guestbook)
|
||||
* Elasticsearch and Kibana
|
||||
* Filebeat
|
||||
* Metricbeat
|
||||
* Packetbeat
|
||||
-->
|
||||
本教程建立在
|
||||
[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 教程之上。
|
||||
*Beats*，是 Elastic 出品的开源的轻量级日志、指标和网络数据采集器，
|
||||
将和 Guestbook 一同部署在 Kubernetes 集群中。
|
||||
Beats 收集、分析、索引数据到 Elasticsearch，使你可以用 Kibana 查看并分析得到的运营信息。
|
||||
本示例由以下内容组成：
|
||||
|
||||
* Elasticsearch 和 Kibana
|
||||
* Filebeat
|
||||
* Metricbeat
|
||||
* Packetbeat
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
<!--
|
||||
* Start up the PHP Guestbook with Redis.
|
||||
* Install kube-state-metrics.
|
||||
* Create a Kubernetes Secret.
|
||||
* Deploy the Beats.
|
||||
* View dashboards of your logs and metrics.
|
||||
-->
|
||||
* 启动用 Redis 部署的 PHP Guestbook。
|
||||
* 安装 kube-state-metrics。
|
||||
* 创建 Kubernetes secret。
|
||||
* 部署 Beats。
|
||||
* 用仪表板查看日志和指标。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
{{< version-check >}}
|
||||
|
||||
<!--
|
||||
Additionally you need:
|
||||
|
||||
* A running deployment of the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.
|
||||
|
||||
* A running Elasticsearch and Kibana deployment. You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co),
|
||||
run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)
|
||||
on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
|
||||
-->
|
||||
此外，你还需要:
|
||||
|
||||
* 依照教程[使用 Redis 的 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook)得到的一套运行中的部署环境。
|
||||
* 一套运行中的 Elasticsearch 和 Kibana 部署环境。你可以使用 [Elastic 云中的Elasticsearch 服务](https://cloud.elastic.co)、在工作站或者服务器上运行此[下载文件](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)、或运行 [Elastic Helm Charts](https://github.com/elastic/helm-charts)。
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!--
|
||||
## Start up the PHP Guestbook with Redis
|
||||
|
||||
This tutorial builds on the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. If you have the guestbook application running, then you can monitor that. If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps. Come back to this page when you have the guestbook running.
|
||||
-->
|
||||
## 启动用 Redis 部署的 PHP Guestbook {#start-up-the-php-guestbook-with-redis}
|
||||
|
||||
本教程建立在
|
||||
[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 之上。
|
||||
如果你已经有一个运行的 Guestbook 应用程序，那就监控它。
|
||||
如果还没有，那就按照说明先部署 Guestbook ，但不要执行**清理**的步骤。
|
||||
当 Guestbook 运行起来后，再返回本页。
|
||||
|
||||
<!--
|
||||
## Add a Cluster role binding
|
||||
|
||||
Create a [cluster level role binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) so that you can deploy kube-state-metrics and the Beats at the cluster level (in kube-system).
|
||||
-->
|
||||
## 添加一个集群角色绑定 {#add-a-cluster-role-binding}
|
||||
|
||||
创建一个[集群范围的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#rolebinding-和-clusterrolebinding)，
|
||||
以便你可以在集群范围（在 kube-system 中）部署 kube-state-metrics 和 Beats。
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding cluster-admin-binding \
|
||||
--clusterrole=cluster-admin --user=<your email associated with the k8s provider account>
|
||||
```
|
||||
|
||||
<!--
|
||||
## Install kube-state-metrics
|
||||
|
||||
Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics) is a simple service that listens to the Kubernetes API server and generates metrics about the state of the objects. Metricbeat reports these metrics. Add kube-state-metrics to the Kubernetes cluster that the guestbook is running in.
|
||||
-->
|
||||
### 安装 kube-state-metrics {#install-kube-state-metrics}
|
||||
|
||||
Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)
|
||||
是一个简单的服务，它侦听 Kubernetes API 服务器并生成对象状态的指标。
|
||||
Metricbeat 报告这些指标。
|
||||
添加 kube-state-metrics 到运行 Guestbook 的 Kubernetes 集群。
|
||||
|
||||
```shell
|
||||
git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
|
||||
kubectl apply -f kube-state-metrics/examples/standard
|
||||
```
|
||||
|
||||
<!--
|
||||
### Check to see if kube-state-metrics is running
|
||||
-->
|
||||
### 检查 kube-state-metrics 是否正在运行 {#check-to-see-if-kube-state-metrics-is-running}
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
|
||||
```
|
||||
|
||||
<!--
|
||||
Output:
|
||||
-->
|
||||
输出：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clone the Elastic examples GitHub repo
|
||||
-->
|
||||
## 从 GitHub 克隆 Elastic examples 库 {#clone-the-elastic-examples-github-repo}
|
||||
|
||||
```shell
|
||||
git clone https://github.com/elastic/examples.git
|
||||
```
|
||||
|
||||
<!--
|
||||
The rest of the commands will reference files in the `examples/beats-k8s-send-anywhere` directory, so change dir there:
|
||||
-->
|
||||
后续命令将引用目录 `examples/beats-k8s-send-anywhere` 中的文件，
|
||||
所以把目录切换过去。
|
||||
|
||||
```shell
|
||||
cd examples/beats-k8s-send-anywhere
|
||||
```
|
||||
|
||||
<!--
|
||||
## Create a Kubernetes Secret
|
||||
A Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}} is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image; putting it in a Secret object allows for more control over how it is used, and reduces the risk of accidental exposure.
|
||||
|
||||
There are two sets of steps here, one for *self managed* Elasticsearch and Kibana (running on your servers or using the Elastic Helm Charts), and a second separate set for the *managed service* Elasticsearch Service in Elastic Cloud. Only create the secret for the type of Elasticsearch and Kibana system that you will use for this tutorial.
|
||||
-->
|
||||
## 创建 Kubernetes Secret {#create-a-kubernetes-secret}
|
||||
|
||||
Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}}
|
||||
是包含少量敏感数据（类似密码、令牌、秘钥等）的对象。
|
||||
这类信息也可以放在 Pod 规格定义或者镜像中；
|
||||
但放在 Secret 对象中，能更好的控制它的使用方式，也能减少意外泄露的风险。
|
||||
|
||||
{{< note >}}
|
||||
这里有两套步骤，一套用于*自管理*的 Elasticsearch 和 Kibana（运行在你的服务器上或使用 Helm Charts），
|
||||
另一套用于在 Elastic 云服务中 *Managed service* 的 Elasticsearch 服务。
|
||||
在本教程中，只需要为 Elasticsearch 和 Kibana 系统创建 secret。
|
||||
{{< /note >}}
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="自管理" %}}
|
||||
|
||||
<!--
|
||||
### Self managed
|
||||
Switch to the **Managed service** tab if you are connecting to Elasticsearch Service in Elastic Cloud.
|
||||
|
||||
### Set the credentials
|
||||
There are four files to edit to create a k8s secret when you are connecting to self managed Elasticsearch and Kibana (self managed is effectively anything other than the managed Elasticsearch Service in Elastic Cloud). The files are:
|
||||
-->
|
||||
### 自管理系统 {#self-managed}
|
||||
|
||||
如果你使用 Elastic 云中的 Elasticsearch 服务，切换到 **Managed service** 标签页。
|
||||
|
||||
### 设置凭据 {#set-the-credentials}
|
||||
|
||||
当你使用自管理的 Elasticsearch 和 Kibana （对比托管于 Elastic 云中的 Elasticsearch 服务，自管理更有效率），
|
||||
创建 k8s secret 需要准备四个文件。这些文件是：
|
||||
|
||||
1. `ELASTICSEARCH_HOSTS`
|
||||
1. `ELASTICSEARCH_PASSWORD`
|
||||
1. `ELASTICSEARCH_USERNAME`
|
||||
1. `KIBANA_HOST`
|
||||
|
||||
<!--
|
||||
Set these with the information for your Elasticsearch cluster and your Kibana host. Here are some examples (also see [*this configuration*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897))
|
||||
-->
|
||||
为你的 Elasticsearch 集群和 Kibana 主机设置这些信息。这里是一些例子
|
||||
（另见[*此配置*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)）
|
||||
|
||||
#### `ELASTICSEARCH_HOSTS` {#elasticsearch-hosts}
|
||||
|
||||
<!--
|
||||
1. A nodeGroup from the Elastic Elasticsearch Helm Chart:
|
||||
-->
|
||||
1. 来自于 Elastic Elasticsearch Helm Chart 的节点组：
|
||||
|
||||
```
|
||||
["http://elasticsearch-master.default.svc.cluster.local:9200"]
|
||||
```
|
||||
|
||||
<!--
|
||||
1. A single Elasticsearch node running on a Mac where your Beats are running in Docker for Mac:
|
||||
-->
|
||||
1. Mac 上的单节点的 Elasticsearch，Beats 运行在 Mac 的容器中：
|
||||
|
||||
```
|
||||
["http://host.docker.internal:9200"]
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Two Elasticsearch nodes running in VMs or on physical hardware:
|
||||
-->
|
||||
1. 运行在虚拟机或物理机上的两个 Elasticsearch 节点
|
||||
|
||||
```
|
||||
["http://host1.example.com:9200", "http://host2.example.com:9200"]
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `ELASTICSEARCH_HOSTS`
|
||||
-->
|
||||
编辑 `ELASTICSEARCH_HOSTS`
|
||||
```shell
|
||||
vi ELASTICSEARCH_HOSTS
|
||||
```
|
||||
|
||||
#### `ELASTICSEARCH_PASSWORD` {#elasticsearch-password}
|
||||
|
||||
<!--
|
||||
Just the password; no whitespace, quotes, or <>:
|
||||
-->
|
||||
只有密码；没有空格、引号、< 和 >：
|
||||
|
||||
```
|
||||
<yoursecretpassword>
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `ELASTICSEARCH_PASSWORD`
|
||||
-->
|
||||
编辑 `ELASTICSEARCH_PASSWORD`：
|
||||
|
||||
```shell
|
||||
vi ELASTICSEARCH_PASSWORD
|
||||
```
|
||||
|
||||
#### `ELASTICSEARCH_USERNAME` {#elasticsearch-username}
|
||||
|
||||
<!--
|
||||
Just the username; no whitespace, quotes, or <>:
|
||||
-->
|
||||
只有用名；没有空格、引号、< 和 >：
|
||||
|
||||
<!--
|
||||
your ingest username for Elasticsearch
|
||||
-->
|
||||
```
|
||||
<为 Elasticsearch 注入的用户名>
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `ELASTICSEARCH_USERNAME`
|
||||
-->
|
||||
编辑 `ELASTICSEARCH_USERNAME`：
|
||||
|
||||
```shell
|
||||
vi ELASTICSEARCH_USERNAME
|
||||
```
|
||||
|
||||
#### `KIBANA_HOST` {#kibana-host}
|
||||
|
||||
<!--
|
||||
1. The Kibana instance from the Elastic Kibana Helm Chart. The subdomain `default` refers to the default namespace. If you have deployed the Helm Chart using a different namespace, then your subdomain will be different:
|
||||
-->
|
||||
1. 从 Elastic Kibana Helm Chart 安装的 Kibana 实例。子域 `default` 指默认的命名空间。如果你把 Helm Chart 指定部署到不同的命名空间，那子域会不同：
|
||||
|
||||
```
|
||||
"kibana-kibana.default.svc.cluster.local:5601"
|
||||
```
|
||||
|
||||
<!--
|
||||
1. A Kibana instance running on a Mac where your Beats are running in Docker for Mac:
|
||||
-->
|
||||
1. Mac 上的 Kibana 实例，Beats 运行于 Mac 的容器：
|
||||
|
||||
```
|
||||
"host.docker.internal:5601"
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Two Elasticsearch nodes running in VMs or on physical hardware:
|
||||
-->
|
||||
1. 运行于虚拟机或物理机上的两个 Elasticsearch 节点：
|
||||
|
||||
```
|
||||
"host1.example.com:5601"
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `KIBANA_HOST`
|
||||
-->
|
||||
编辑 `KIBANA_HOST`：
|
||||
|
||||
```shell
|
||||
vi KIBANA_HOST
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a Kubernetes secret
|
||||
This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
|
||||
-->
|
||||
### 创建 Kubernetes secret {#create-a-kubernetes-secret}
|
||||
|
||||
在上面编辑完的文件的基础上，本命令在 Kubernetes 系统范围的命名空间（kube-system）创建一个 secret。
|
||||
|
||||
```
|
||||
kubectl create secret generic dynamic-logging \
|
||||
--from-file=./ELASTICSEARCH_HOSTS \
|
||||
--from-file=./ELASTICSEARCH_PASSWORD \
|
||||
--from-file=./ELASTICSEARCH_USERNAME \
|
||||
--from-file=./KIBANA_HOST \
|
||||
--namespace=kube-system
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Managed service" %}}
|
||||
|
||||
<!--
|
||||
## Managed service
|
||||
This tab is for Elasticsearch Service in Elastic Cloud only, if you have already created a secret for a self managed Elasticsearch and Kibana deployment, then continue with [Deploy the Beats](#deploy-the-beats).
|
||||
### Set the credentials
|
||||
There are two files to edit to create a k8s secret when you are connecting to the managed Elasticsearch Service in Elastic Cloud. The files are:
|
||||
-->
|
||||
## Managed service {#managed-service}
|
||||
|
||||
本标签页只用于 Elastic 云 的 Elasticsearch 服务，如果你已经为自管理的 Elasticsearch 和 Kibana 创建了secret，请继续[部署 Beats](#deploy-the-beats)并继续。
|
||||
|
||||
### 设置凭据 {#set-the-credentials}
|
||||
|
||||
在 Elastic 云中的托管 Elasticsearch 服务中，为了创建 k8s secret，你需要先编辑两个文件。它们是：
|
||||
|
||||
1. `ELASTIC_CLOUD_AUTH`
|
||||
1. `ELASTIC_CLOUD_ID`
|
||||
|
||||
<!--
|
||||
Set these with the information provided to you from the Elasticsearch Service console when you created the deployment. Here are some examples:
|
||||
-->
|
||||
当你完成部署的时候，Elasticsearch 服务控制台会提供给你一些信息，用这些信息完成设置。
|
||||
这里是一些示例：
|
||||
|
||||
#### ELASTIC_CLOUD_ID {#elastic-cloud-id}
|
||||
|
||||
```
|
||||
devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
|
||||
```
|
||||
|
||||
#### ELASTIC_CLOUD_AUTH {#elastic-cloud-auth}
|
||||
|
||||
<!--
|
||||
Just the username, a colon (`:`), and the password, no whitespace or quotes:
|
||||
-->
|
||||
只要用户名；没有空格、引号、< 和 >：
|
||||
|
||||
```
|
||||
elastic:VFxJJf9Tjwer90wnfTghsn8w
|
||||
```
|
||||
|
||||
<!--
|
||||
### Edit the required files:
|
||||
-->
|
||||
### 编辑要求的文件 {#edit-the-required-files}
|
||||
```shell
|
||||
vi ELASTIC_CLOUD_ID
|
||||
vi ELASTIC_CLOUD_AUTH
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a Kubernetes secret
|
||||
This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
|
||||
-->
|
||||
### 创建 Kubernetes secret {#create-a-kubernetes-secret}
|
||||
|
||||
基于上面刚编辑过的文件，在 Kubernetes 系统范围命名空间（kube-system）中，用下面命令创建一个的secret：
|
||||
|
||||
kubectl create secret generic dynamic-logging \
|
||||
--from-file=./ELASTIC_CLOUD_ID \
|
||||
--from-file=./ELASTIC_CLOUD_AUTH \
|
||||
--namespace=kube-system
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## Deploy the Beats
|
||||
Manifest files are provided for each Beat. These manifest files use the secret created earlier to configure the Beats to connect to your Elasticsearch and Kibana servers.
|
||||
|
||||
### About Filebeat
|
||||
Filebeat will collect logs from the Kubernetes nodes and the containers running in each pod running on those nodes. Filebeat is deployed as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}. Filebeat can autodiscover applications running in your Kubernetes cluster. At startup Filebeat scans existing containers and launches the proper configurations for them, then it will watch for new start/stop events.
|
||||
|
||||
Here is the autodiscover configuration that enables Filebeat to locate and parse Redis logs from the Redis containers deployed with the guestbook application. This configuration is in the file `filebeat-kubernetes.yaml`:
|
||||
-->
|
||||
## 部署 Beats {#deploy-the-beats}
|
||||
|
||||
为每一个 Beat 提供 清单文件。清单文件使用已创建的 secret 接入 Elasticsearch 和 Kibana 服务器。
|
||||
|
||||
### 关于 Filebeat {#about-filebeat}
|
||||
|
||||
Filebeat 收集日志，日志来源于 Kubernetes 节点以及这些节点上每一个 Pod 中的容器。Filebeat 部署为
|
||||
{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。
|
||||
Filebeat 支持自动发现 Kubernetes 集群中的应用。
|
||||
在启动时，Filebeat 扫描存量的容器，并为它们提供适当的配置，
|
||||
然后开始监听新的启动/中止信号。
|
||||
|
||||
下面是一个自动发现的配置，它支持 Filebeat 定位并分析来自于 Guestbook 应用部署的 Redis 容器的日志文件。
|
||||
下面的配置片段来自文件 `filebeat-kubernetes.yaml`：
|
||||
|
||||
```yaml
|
||||
- condition.contains:
|
||||
kubernetes.labels.app: redis
|
||||
config:
|
||||
- module: redis
|
||||
log:
|
||||
input:
|
||||
type: docker
|
||||
containers.ids:
|
||||
- ${data.kubernetes.container.id}
|
||||
slowlog:
|
||||
enabled: true
|
||||
var.hosts: ["${data.host}:${data.port}"]
|
||||
```
|
||||
|
||||
<!--
|
||||
This configures Filebeat to apply the Filebeat module `redis` when a container is detected with a label `app` containing the string `redis`. The redis module has the ability to collect the `log` stream from the container by using the docker input type (reading the file on the Kubernetes node associated with the STDOUT stream from this Redis container). Additionally, the module has the ability to collect Redis `slowlog` entries by connecting to the proper pod host and port, which is provided in the container metadata.
|
||||
|
||||
### Deploy Filebeat:
|
||||
-->
|
||||
|
||||
这样配置 Filebeat，当探测到容器拥有 `app` 标签，且值为 `redis`，那就启用 Filebeat 的 `redis` 模块。
|
||||
`redis` 模块可以根据 docker 的输入类型（在 Kubernetes 节点上读取和 Redis 容器的标准输出流关联的文件） ，从容器收集 `log` 流。
|
||||
另外，此模块还可以使用容器元数据中提供的配置信息，连到 Pod 适当的主机和端口，收集 Redis 的 `slowlog` 。
|
||||
|
||||
### 部署 Filebeat {#deploy-filebeat}
|
||||
|
||||
```shell
|
||||
kubectl create -f filebeat-kubernetes.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Verify
|
||||
-->
|
||||
#### 验证 {#verify}
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
|
||||
```
|
||||
|
||||
<!--
|
||||
### About Metricbeat
|
||||
Metricbeat autodiscover is configured in the same way as Filebeat. Here is the Metricbeat autodiscover configuration for the Redis containers. This configuration is in the file `metricbeat-kubernetes.yaml`:
|
||||
-->
|
||||
### 关于 Metricbeat {#about-metricbeat}
|
||||
|
||||
Metricbeat 自动发现的配置方式与 Filebeat 完全相同。
|
||||
这里是针对 Redis 容器的 Metricbeat 自动发现配置。
|
||||
此配置片段来自于文件 `metricbeat-kubernetes.yaml`：
|
||||
|
||||
```yaml
|
||||
- condition.equals:
|
||||
kubernetes.labels.tier: backend
|
||||
config:
|
||||
- module: redis
|
||||
metricsets: ["info", "keyspace"]
|
||||
period: 10s
|
||||
|
||||
# Redis hosts
|
||||
hosts: ["${data.host}:${data.port}"]
|
||||
```
|
||||
<!--
|
||||
This configures Metricbeat to apply the Metricbeat module `redis` when a container is detected with a label `tier` equal to the string `backend`. The `redis` module has the ability to collect the `info` and `keyspace` metrics from the container by connecting to the proper pod host and port, which is provided in the container metadata.
|
||||
|
||||
### Deploy Metricbeat
|
||||
-->
|
||||
配置 Metricbeat，在探测到标签 `tier` 的值等于 `backend` 时，应用 Metricbeat 模块 `redis`。
|
||||
`redis` 模块可以获取容器元数据，连接到 Pod 适当的主机和端口，从 Pod 中收集指标 `info` 和 `keyspace`。
|
||||
|
||||
### 部署 Metricbeat {#deploy-metricbeat}
|
||||
|
||||
```shell
|
||||
kubectl create -f metricbeat-kubernetes.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Verify
|
||||
-->
|
||||
#### 验证 {#verify2}
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l k8s-app=metricbeat
|
||||
```
|
||||
|
||||
<!--
|
||||
### About Packetbeat
|
||||
Packetbeat configuration is different than Filebeat and Metricbeat. Rather than specify patterns to match against container labels the configuration is based on the protocols and port numbers involved. Shown below is a subset of the port numbers.
|
||||
|
||||
If you are running a service on a non-standard port add that port number to the appropriate type in `filebeat.yaml` and delete / create the Packetbeat DaemonSet.
|
||||
-->
|
||||
### 关于 Packetbeat {#about-packetbeat}
|
||||
|
||||
Packetbeat 的配置方式不同于 Filebeat 和 Metricbeat。
|
||||
相比于匹配容器标签的模式，它的配置基于相关协议和端口号。
|
||||
下面展示的是端口号的一个子集：
|
||||
|
||||
{{< note >}}
|
||||
如果你的服务运行在非标准的端口上，那就打开文件 `filebeat.yaml`，把这个端口号添加到合适的类型中，然后删除/启动 Packetbeat 的守护进程。
|
||||
{{< /note >}}
|
||||
|
||||
```yaml
|
||||
packetbeat.interfaces.device: any
|
||||
|
||||
packetbeat.protocols:
|
||||
- type: dns
|
||||
ports: [53]
|
||||
include_authorities: true
|
||||
include_additionals: true
|
||||
|
||||
- type: http
|
||||
ports: [80, 8000, 8080, 9200]
|
||||
|
||||
- type: mysql
|
||||
ports: [3306]
|
||||
|
||||
- type: redis
|
||||
ports: [6379]
|
||||
|
||||
packetbeat.flows:
|
||||
timeout: 30s
|
||||
period: 10s
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Deploy Packetbeat
|
||||
-->
|
||||
### 部署 Packetbeat {#deploy-packetbeat}
|
||||
|
||||
```shell
|
||||
kubectl create -f packetbeat-kubernetes.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Verify
|
||||
-->
|
||||
#### 验证 {#verify3}
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
|
||||
```
|
||||
|
||||
<!--
|
||||
## View in Kibana
|
||||
|
||||
Open Kibana in your browser and then open the **Dashboard** application. In the search bar type Kubernetes and click on the Metricbeat dashboard for Kubernetes. This dashboard reports on the state of your Nodes, deployments, etc.
|
||||
|
||||
Search for Packetbeat on the Dashboard page, and view the Packetbeat overview.
|
||||
|
||||
Similarly, view dashboards for Apache and Redis. You will see dashboards for logs and metrics for each. The Apache Metricbeat dashboard will be blank. Look at the Apache Filebeat dashboard and scroll to the bottom to view the Apache error logs. This will tell you why there are no metrics available for Apache.
|
||||
|
||||
To enable Metricbeat to retrieve the Apache metrics, enable server-status by adding a ConfigMap including a mod-status configuration file and re-deploy the guestbook.
|
||||
|
||||
|
||||
## Scale your deployments and see new pods being monitored
|
||||
List the existing deployments:
|
||||
-->
|
||||
## 在 kibana 中浏览 {#view-in-kibana}
|
||||
|
||||
在浏览器中打开 kibana，再打开 **Dashboard**。
|
||||
在搜索栏中键入 Kubernetes，再点击 Metricbeat 的 Kubernetes Dashboard。
|
||||
此 Dashboard 展示节点状态、应用部署等。
|
||||
|
||||
在 Dashboard 页面，搜索 Packetbeat，并浏览 Packetbeat 概览信息。
|
||||
|
||||
同样地，浏览 Apache 和 Redis 的 Dashboard。
|
||||
可以看到日志和指标各自独立 Dashboard。
|
||||
Apache Metricbeat Dashboard 是空的。
|
||||
找到 Apache Filebeat Dashboard，拉到最下面，查看 Apache 的错误日志。
|
||||
日志会揭示出没有 Apache 指标的原因。
|
||||
|
||||
要让 metricbeat 得到 Apache 的指标，需要添加一个包含模块状态配置文件的 ConfigMap，并重新部署 Guestbook。
|
||||
|
||||
## 缩放部署规模，查看新 Pod 已被监控 {#scale-your-deployments-and-see-new-pods-being-monitored}
|
||||
|
||||
列出现有的 deployments：
|
||||
|
||||
```shell
|
||||
kubectl get deployments
|
||||
```
|
||||
|
||||
<!--
|
||||
The output:
|
||||
-->
|
||||
输出：
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
frontend 3/3 3 3 3h27m
|
||||
redis-master 1/1 1 1 3h27m
|
||||
redis-slave 2/2 2 2 3h27m
|
||||
```
|
||||
|
||||
<!--
|
||||
Scale the frontend down to two pods:
|
||||
-->
|
||||
缩放前端到两个 Pod：
|
||||
|
||||
```shell
|
||||
kubectl scale --replicas=2 deployment/frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
The output:
|
||||
-->
|
||||
输出：
|
||||
|
||||
```
|
||||
deployment.extensions/frontend scaled
|
||||
```
|
||||
|
||||
<!--
|
||||
Scale the frontend back up to three pods:
|
||||
-->
|
||||
将前端应用缩放回三个 Pod：
|
||||
|
||||
```shell
|
||||
kubectl scale --replicas=3 deployment/frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
## View the changes in Kibana
|
||||
See the screenshot, add the indicated filters and then add the columns to the view. You can see the ScalingReplicaSet entry that is marked, following from there to the top of the list of events shows the image being pulled, the volumes mounted, the pod starting, etc.
|
||||
|
||||
-->
|
||||
## 在 Kibana 中查看变化 {#view-the-chagnes-in-kibana}
|
||||
|
||||
参见屏幕截图，添加指定的过滤器，然后将列添加到视图。
|
||||
你可以看到，ScalingReplicaSet 被做了标记，从标记的点开始，到消息列表的顶部，展示了拉取的镜像、挂载的卷、启动的 Pod 等。
|
||||
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
<!--
|
||||
Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command.
|
||||
|
||||
1. Run the following commands to delete all Pods, Deployments, and Services.
|
||||
-->
|
||||
删除 Deployments 和 Services， 删除运行的 Pod。
|
||||
用标签功能在一个命令中删除多个资源。
|
||||
|
||||
1. 执行下列命令，删除所有的 Pod、Deployment 和 Services。
|
||||
|
||||
```shell
|
||||
kubectl delete deployment -l app=redis
|
||||
kubectl delete service -l app=redis
|
||||
kubectl delete deployment -l app=guestbook
|
||||
kubectl delete service -l app=guestbook
|
||||
kubectl delete -f filebeat-kubernetes.yaml
|
||||
kubectl delete -f metricbeat-kubernetes.yaml
|
||||
kubectl delete -f packetbeat-kubernetes.yaml
|
||||
kubectl delete secret dynamic-logging -n kube-system
|
||||
```
|
||||
<!--
|
||||
1. Query the list of Pods to verify that no Pods are running:
|
||||
-->
|
||||
2. 查询 Pod，以核实没有 Pod 还在运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The response should be this:
|
||||
-->
|
||||
响应应该是这样：
|
||||
|
||||
```
|
||||
No resources found.
|
||||
```
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn about [tools for monitoring resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* Read more about [logging architecture](/docs/concepts/cluster-administration/logging/)
|
||||
* Read more about [application introspection and debugging](/docs/tasks/debug-application-cluster/)
|
||||
* Read more about [troubleshoot applications](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
-->
|
||||
* 了解[监控资源的工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* 进一步阅读[日志体系架构](/zh/docs/concepts/cluster-administration/logging/)
|
||||
* 进一步阅读[应用内省和调试](/zh/docs/tasks/debug-application-cluster/)
|
||||
* 进一步阅读[应用程序的故障排除](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
# i18n strings for the English (main) site.
|
||||
# NOTE: Please keep the entries in alphabetical order when editing
|
||||
[announcement_title]
|
||||
other = "Black lives matter."
|
||||
other = "<img src=\"images/kccnc-na-virtual-2020-white.svg\" style=\"float: right; height: 80px;\" /><a href=\"https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kuberntes.io&utm_medium=search&utm_campaign=KC_CNC_Virtual\">KubeCon + CloudNativeCon NA 2020</a> <em>virtual</em>."
|
||||
|
||||
[announcement_message]
|
||||
other = "We stand in solidarity with the Black community.<br/>Racism is unacceptable.<br/> It conflicts with the [core values of the Kubernetes project](https://git.k8s.io/community/values.md) and our community does not tolerate it."
|
||||
other = "4 days of incredible opportunities to collaborate, learn, and share with the entire community!<br />November 17 – 20 2020"
|
||||
|
||||
[caution]
|
||||
other = "Caution:"
|
||||
|
|
|
|||
|
|
@ -3,27 +3,37 @@
|
|||
# This script checks if the English version of a page has changed since a localized
|
||||
# page has been committed.
|
||||
|
||||
if [ "$#" -ne 1 ] || ! [ -f "$1" ]; then
|
||||
echo -e "\nThis script checks if the English version of a page has changed since a "
|
||||
echo -e "localized page has been committed.\n"
|
||||
if [ "$#" -ne 1 ] ; then
|
||||
echo -e "\nThis script checks if the English version of a page has changed since a " >&2
|
||||
echo -e "localized page has been committed.\n" >&2
|
||||
echo -e "Usage:\n\t$0 <PATH>\n" >&2
|
||||
echo -e "Example:\n\t$0 content/zh/docs/concepts/_index.md\n" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check if path exists, and whether it is a directory or a file
|
||||
if [ ! -e "$1" ] ; then
|
||||
echo "Path not found: '$1'" >&2
|
||||
exit 2
|
||||
elif [ -d "$1" ] ; then
|
||||
IS_DIR=1
|
||||
EXTRA_FLAGS="--stat"
|
||||
else
|
||||
IS_DIR=0
|
||||
fi
|
||||
LOCALIZED="$1"
|
||||
|
||||
# Try get the English version
|
||||
EN_VERSION=`echo $LOCALIZED | sed "s/content\/..\//content\/en\//g"`
|
||||
if ! [ -f $EN_VERSION ]; then
|
||||
if [ $IS_DIR -eq 1 -a ! -e $EN_VERSION ]; then
|
||||
echo "$EN_VERSION has been removed."
|
||||
exit 2
|
||||
exit 3
|
||||
fi
|
||||
|
||||
# Last commit for the localized file
|
||||
# Last commit for the localized path
|
||||
LASTCOMMIT=`git log -n 1 --pretty=format:%h -- $LOCALIZED`
|
||||
|
||||
git diff --exit-code $LASTCOMMIT...HEAD $EN_VERSION
|
||||
git diff --exit-code $EXTRA_FLAGS $LASTCOMMIT...HEAD $EN_VERSION
|
||||
|
||||
if [ "$?" -eq 0 ]; then
|
||||
echo "$LOCALIZED is still in sync"
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 700 B After Width: | Height: | Size: 1.4 KiB |
Loading…
Reference in New Issue