whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into HEAD

Browse Source
This commit is contained in:
vineeth
2020-03-23 01:02:58 +05:30
parent d16f5b60aa 3cd0b29301
commit f1d9ebc578
298 changed files with 10720 additions and 4146 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/architecture/controller.md
+1 -1
View File
@@ -51,7 +51,7 @@ detail.
-->
## 控制器模式 {#controller-pattern}
一个控制器至少追踪一种类型的 Kubernetes 资源。这些[对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)有一个代表期望状态的指定字段。正对这种资源的控制器就是要使他的当前状态接近与期望状态。
一个控制器至少追踪一种类型的 Kubernetes 资源。这些[对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)有一个代表期望状态的指定字段。控制器负责确保其追踪的资源对象的当前状态接近期望状态。
控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。看下面这个例子。
content/zh/docs/concepts/configuration/manage-compute-resources-container.md
+2 -2
View File
@@ -275,7 +275,7 @@ resource limits, see the
The resource usage of a Pod is reported as part of the Pod status.
If [optional monitoring](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)
If [optional monitoring](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
is configured for your cluster, then Pod resource usage can be retrieved from
the monitoring system.
-->
@@ -284,7 +284,7 @@ the monitoring system.
Pod 的资源使用情况被报告为 Pod 状态的一部分。
如果为集群配置了 [可选监控](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)，则可以从监控系统检索 Pod 资源的使用情况。
如果为集群配置了 [可选监控](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)，则可以从监控系统检索 Pod 资源的使用情况。
<!--
## Troubleshooting
content/zh/docs/concepts/extend-kubernetes/operator.md
+232
View File
@@ -0,0 +1,232 @@
---
title: Operator 模式
content_template: templates/concept
weight: 30
---
<!--
---
title: Operator pattern
content_template: templates/concept
weight: 30
---
-->
{{% capture overview %}}
<!--
Operators are software extensions to Kubernetes that make use of [custom
resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
to manage applications and their components. Operators follow
Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
-->
Operator 是 Kubernetes 的扩展软件，它利用[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
Operator 遵循 Kubernetes 的理念，特别是在[控制环](/docs/concepts/#kubernetes-control-plane)方面。
{{% /capture %}}
{{% capture body %}}
<!--
## Motivation
The Operator pattern aims to capture the key aim of a human operator who
is managing a service or set of services. Human operators who look after
specific applications and services have deep knowledge of how the system
ought to behave, how to deploy it, and how to react if there are problems.
People who run workloads on Kubernetes often like to use automation to take
care of repeatable tasks. The Operator pattern captures how you can write
code to automate a task beyond what Kubernetes itself provides.
-->
## 初衷
Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。
负责特定应用和 service 的运维人员，在系统应该如何运行、如何部署以及出现问题时如何处理等方面有深入的了解。
在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。Operator 模式会封装您编写的（Kubernetes 本身提供功能以外的）任务自动化代码。
<!--
## Operators in Kubernetes
Kubernetes is designed for automation. Out of the box, you get lots of
built-in automation from the core of Kubernetes. You can use Kubernetes
to automate deploying and running workloads, *and* you can automate how
Kubernetes does that.
Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
concept lets you extend the cluster's behaviour without modifying the code
of Kubernetes itself.
Operators are clients of the Kubernetes API that act as controllers for
a [Custom Resource](/docs/concepts/api-extension/custom-resources/).
-->
## Kubernetes 上的 Operator
Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes 核心中获得许多内置的自动化功能。
您可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。
Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
Operator 是 Kubernetes API 的客户端，充当[自定义资源](/docs/concepts/api-extension/custom-resources/)的控制器。
<!--
## An example Operator {#example}
Some of the things that you can use an operator to automate include:
* deploying an application on demand
* taking and restoring backups of that application's state
* handling upgrades of the application code alongside related changes such
as database schemas or extra configuration settings
* publishing a Service to applications that don't support Kubernetes APIs to
discover them
* simulating failure in all or part of your cluster to test its resilience
* choosing a leader for a distributed application without an internal
member election process
-->
## Operator 示例 {#example}
使用 Operator 可以自动化的事情包括：
* 按需部署应用
* 获取/还原应用状态的备份
* 处理应用代码的升级以及相关改动。例如，数据库 schema 或额外的配置设置
* 发布一个 service，要求不支持 Kubernetes API 的应用也能发现它
* 模拟整个或部分集群中的故障以测试其稳定性
* 在没有内部成员选举程序的情况下，为分布式应用选择首领角色
<!--
What might an Operator look like in more detail? Here's an example in more
detail:
1. A custom resource named SampleDB, that you can configure into the cluster.
2. A Deployment that makes sure a Pod is running that contains the
controller part of the operator.
3. A container image of the operator code.
4. Controller code that queries the control plane to find out what SampleDB
resources are configured.
5. The core of the Operator is code to tell the API server how to make
reality match the configured resources.
* If you add a new SampleDB, the operator sets up PersistentVolumeClaims
to provide durable database storage, a StatefulSet to run SampleDB and
a Job to handle initial configuration.
* If you delete it, the Operator takes a snapshot, then makes sure that
the StatefulSet and Volumes are also removed.
6. The operator also manages regular database backups. For each SampleDB
resource, the operator determines when to create a Pod that can connect
to the database and take backups. These Pods would rely on a ConfigMap
and / or a Secret that has database connection details and credentials.
7. Because the Operator aims to provide robust automation for the resource
it manages, there would be additional supporting code. For this example,
code checks to see if the database is running an old version and, if so,
creates Job objects that upgrade it for you.
-->
想要更详细的了解 Operator？这儿有一个详细的示例：
1. 有一个名为 SampleDB 的自定义资源，您可以将其配置到集群中。
2. 一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
3. Operator 代码的容器镜像。
4. 控制器代码，负责查询控制平面以找出已配置的 SampleDB 资源。
5. Operator 的核心是告诉 API 服务器，如何使现实与代码里配置的资源匹配。
* 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job 来处理初始配置。
* 如果您删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
6. Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator 会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于 ConfigMap 和/或 具有数据库连接详细信息和凭据的 Secret。
7. 由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，如果是，则创建 Job 对象为您升级数据库。
<!--
## Deploying Operators
The most common way to deploy an Operator is to add the
Custom Resource Definition and its associated Controller to your cluster.
The Controller will normally run outside of the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}},
much as you would run any containerized application.
For example, you can run the controller in your cluster as a Deployment.
-->
## 部署 Operator
部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到您的集群中。跟运行容器化应用一样，Controller 通常会运行在 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。例如，您可以在集群中将控制器作为 Deployment 运行。
<!--
## Using an Operator {#using-operators}
Once you have an Operator deployed, you'd use it by adding, modifying or
deleting the kind of resource that the Operator uses. Following the above
example, you would set up a Deployment for the Operator itself, and then:
```shell
kubectl get SampleDB # find configured databases
kubectl edit SampleDB/example-database # manually change some settings
```
-->
## 使用 Operator {#using-operators}
部署 Operator 后，您可以对 Operator 所使用的资源执行添加、修改或删除操作。按照上面的示例，您将为 Operator 本身建立一个 Deployment，然后：
```shell
kubectl get SampleDB # 查找所配置的数据库
kubectl edit SampleDB/example-database # 手动修改某些配置
```
<!--
&hellip;and that's it! The Operator will take care of applying the changes as well as keeping the existing service in good shape.
## Writing your own Operator {#writing-operator}
-->
可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态
## 编写你自己的 Operator {#writing-operator}
<!--
If there isn't an Operator in the ecosystem that implements the behavior you
want, you can code your own. In [What's next](#what-s-next) you'll find a few
links to libraries and tools you can use to write your own cloud native
Operator.
You also implement an Operator (that is, a Controller) using any language / runtime
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
-->
如果生态系统中没可以实现您目标的 Operator，您可以自己编写代码。在[接下来](#what-s-next)一节中，您会找到编写自己的云原生 Operator 需要的库和工具的链接。
您还可以使用任何支持 [Kubernetes API 客户端](/docs/reference/using-api/client-libraries/)的语言或运行时来实现 Operator（即控制器）。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
* Use existing tools to write your own operator, eg:
* using [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
* using [kubebuilder](https://book.kubebuilder.io/)
* using [Metacontroller](https://metacontroller.app/) along with WebHooks that
you implement yourself
* using the [Operator Framework](https://github.com/operator-framework/getting-started)
* [Publish](https://operatorhub.io/) your operator for other people to use
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
-->
* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
* 借助已有的工具来编写您自己的 Operator，例如：
* [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
* [kubebuilder](https://book.kubebuilder.io/)
* [Metacontroller](https://metacontroller.app/)，可与 Webhook 结合使用，以实现自己的功能。
* [Operator 框架](https://github.com/operator-framework/getting-started)
* [发布](https://operatorhub.io/)您的 Operator，让别人也可以使用
* 阅读 [CoreOS 原文](https://coreos.com/blog/introducing-operators.html)，其介绍了 Operator 介绍
* 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的[文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
{{% /capture %}}
content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+19 -7
View File
@@ -1,12 +1,21 @@
---
title: 理解 Kubernetes 对象
redirect_from:
- "/docs/concepts/abstractions/overview/"
- "/docs/concepts/abstractions/overview.html"
content_template: templates/concept
weight: 10
card:
name: 概念
weight: 40
---
<!---
title: Understanding Kubernetes Objects
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 40
-->
{{% capture overview %}}
<!--
This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
@@ -139,7 +148,7 @@ and the `spec` format for a `Deployment` can be found
[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
-->
也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
您也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
例如，可以从
[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
查看 `Pod` 的 `spec` 格式，
@@ -150,10 +159,13 @@ and the `spec` format for a `Deployment` can be found
{{% capture whatsnext %}}
<!--
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
-->
* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。
* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述
* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。
* 了解 Kubernetes 中的[控制器](/docs/concepts/architecture/controller/)。
{{% /capture %}}
content/zh/docs/concepts/policy/pod-security-policy.md
-3
View File
@@ -2,9 +2,6 @@
approvers:
- pweil-
title: Pod 安全策略
redirect_from:
- "/docs/user-guide/pod-security-policy/"
- "/docs/user-guide/pod-security-policy/index.html"
---
content/zh/docs/concepts/services-networking/service.md
+3 -2
View File
@@ -169,7 +169,7 @@ also named “my-service”.
上述配置创建一个名称为 "my-service" 的 `Service` 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 `Pod` 上。
Kubernetes 为该服务分配一个 IP 地址（有时称为 "集群IP" ），该 IP 地址由服务代理使用。
(请参见下面的 [虚拟 IP 和服务代理](#virtual-ips-and-service-proxies)).
(请参见下面的 [VIP 和 Service 代理](#virtual-ips-and-service-proxies)).
服务选择器的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为 “my-service” 的Endpoint对象。
{{< note >}}
@@ -336,7 +336,7 @@ responsible for implementing a form of virtual IP for `Services` of type other
than [`ExternalName`](#externalname).
-->
## VIP 和 Service 代理
## VIP 和 Service 代理 {#virtual-ips-and-service-proxies}
在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 [`ExternalName`](#externalname) 的形式。
@@ -828,6 +828,7 @@ You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expos
Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。
`Type` 的取值以及行为如下：
* `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。
* [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。`NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。
* [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。
content/zh/docs/concepts/storage/volumes.md
+33
View File
@@ -988,6 +988,39 @@ spec:
type: Directory
```
{{< caution >}}
<!-- It should be noted that the `FileOrCreate` mode does not create the parent directory of the file. If the parent directory of the mounted file does not exist, the pod fails to start. To ensure that this mode works, you can try to mount directories and files separately, as shown below. -->
应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。如果挂载挂载文件的父目录不存在，pod 启动会失败。为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示：
{{< /caution >}}
#### FileOrCreate pod 示例
```yaml
apiVersion: v1
kind: Pod
metadata:
name: test-webserver
spec:
containers:
- name: test-webserver
image: k8s.gcr.io/test-webserver:latest
volumeMounts:
- mountPath: /var/local/aaa
name: mydir
- mountPath: /var/local/aaa/1.txt
name: myfile
volumes:
- name: mydir
hostPath:
# 确保文件所在目录成功创建。
path: /var/local/aaa
type: DirectoryOrCreate
- name: myfile
hostPath:
path: /var/local/aaa/1.txt
type: FileOrCreate
```
### iscsi {#iscsi}
<!--
content/zh/docs/concepts/workloads/pods/init-containers.md
+2 -7
View File
@@ -2,11 +2,6 @@
approvers:
- erictune
title: Init 容器
redirect_from:
- "/docs/concepts/abstractions/init-containers/"
- "/docs/concepts/abstractions/init-containers.html"
- "/docs/user-guide/pods/init-container/"
- "/docs/user-guide/pods/init-container.html"
content_template: templates/concept
---
@@ -186,10 +181,10 @@ spec:
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
```
下面的 yaml 文件展示了 `mydb` 和 `myservice` 两个 Service：
content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
-3
View File
@@ -1,8 +1,5 @@
---
title: Pod 的生命周期
redirect_from:
- "/docs/user-guide/pod-states/"
- "/docs/user-guide/pod-states.html"
content_template: templates/concept
---