Merge remote-tracking branch 'upstream/master' into dev-1.19
This commit is contained in:
Savitha Raghunathan
@@ -0,0 +1,190 @@
|
||||
<!--
|
||||
---
|
||||
title: " Weekly Kubernetes Community Hangout Notes - July 31 2015 "
|
||||
date: 2015-08-04
|
||||
slug: weekly-kubernetes-community-hangout
|
||||
url: /blog/2015/08/Weekly-Kubernetes-Community-Hangout
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
title: " Kubernetes社区每周环聊笔记-2015年7月31日 "
|
||||
date: 2015-08-04
|
||||
slug: weekly-kubernetes-community-hangout
|
||||
url: /blog/2015/08/Weekly-Kubernetes-Community-Hangout
|
||||
---
|
||||
|
||||
<!--
|
||||
Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.
|
||||
|
||||
Here are the notes from today's meeting:
|
||||
-->
|
||||
|
||||
每周，Kubernetes 贡献社区都会通过Google 环聊虚拟开会。我们希望任何有兴趣的人都知道本论坛讨论的内容。
|
||||
|
||||
这是今天会议的笔记：
|
||||
|
||||
<!--
|
||||
* Private Registry Demo - Muhammed
|
||||
|
||||
* Run docker-registry as an RC/Pod/Service
|
||||
|
||||
* Run a proxy on every node
|
||||
|
||||
* Access as localhost:5000
|
||||
|
||||
* Discussion:
|
||||
|
||||
* Should we back it by GCS or S3 when possible?
|
||||
|
||||
* Run real registry backed by $object_store on each node
|
||||
|
||||
* DNS instead of localhost?
|
||||
|
||||
* disassemble image strings?
|
||||
|
||||
* more like DNS policy?
|
||||
-->
|
||||
* 私有镜像仓库演示 - Muhammed
|
||||
|
||||
* 将 docker-registry 作为 RC/Pod/Service 运行
|
||||
|
||||
* 在每个节点上运行代理
|
||||
|
||||
* 以 localhost:5000 访问
|
||||
|
||||
* 讨论：
|
||||
|
||||
* 我们应该在可能的情况下通过 GCS 或 S3 支持它吗？
|
||||
|
||||
* 在每个节点上运行由 $object_store 支持的真实镜像仓库
|
||||
|
||||
* DNS 代替 localhost？
|
||||
|
||||
* 分解 docker 镜像字符串？
|
||||
|
||||
* 更像 DNS 策略吗？
|
||||
<!--
|
||||
* Running Large Clusters - Joe
|
||||
|
||||
* Samsung keen to see large scale O(1000)
|
||||
|
||||
* Starting on AWS
|
||||
|
||||
* RH also interested - test plan needed
|
||||
|
||||
* Plan for next week: discuss working-groups
|
||||
|
||||
* If you are interested in joining conversation on cluster scalability send mail to [joe@0xBEDA.com][4]
|
||||
-->
|
||||
|
||||
* 运行大型集群 - Joe
|
||||
|
||||
* 三星渴望看到大规模 O(1000)
|
||||
|
||||
* 从 AWS 开始
|
||||
|
||||
* RH 也有兴趣 - 需要测试计划
|
||||
|
||||
* 计划下周：讨论工作组
|
||||
|
||||
* 如果您有兴趣加入有关集群可扩展性的对话，请发送邮件至[joe@0xBEDA.com][4]
|
||||
|
||||
<!--
|
||||
* Resource API Proposal - Clayton
|
||||
|
||||
* New stuff wants more info on resources
|
||||
|
||||
* Proposal for resources API - ask apiserver for info on pods
|
||||
|
||||
* Send feedback to: #11951
|
||||
|
||||
* Discussion on snapshot vs time-series vs aggregates
|
||||
-->
|
||||
|
||||
* 资源 API 提案 - Clayton
|
||||
|
||||
* 新东西需要更多资源信息
|
||||
|
||||
* 关于资源 API 的提案 - 向 apiserver 询问有关pod的信息
|
||||
|
||||
* 发送反馈至：#11951
|
||||
|
||||
* 关于快照，时间序列和聚合的讨论
|
||||
|
||||
<!--
|
||||
* Containerized kubelet - Clayton
|
||||
|
||||
* Open pull
|
||||
|
||||
* Docker mount propagation - RH carries patches
|
||||
|
||||
* Big issues around whole bootstrap of the system
|
||||
|
||||
* dual: boot-docker/system-docker
|
||||
|
||||
* Kube-in-docker is really nice, but maybe not critical
|
||||
|
||||
* Do the small stuff to make progress
|
||||
|
||||
* Keep pressure on docker
|
||||
-->
|
||||
* 容器化 kubelet - Clayton
|
||||
|
||||
* 打开 pull
|
||||
|
||||
* Docker挂载传播 - RH 带有补丁
|
||||
|
||||
* 有关整个系统引导程序的大问题
|
||||
|
||||
* 双：引导docker /系统docker
|
||||
|
||||
* Kube-in-docker非常好，但可能并不关键
|
||||
|
||||
* 做些小事以取得进步
|
||||
|
||||
* 对 docker 施加压力
|
||||
<!--
|
||||
* Web UI (preilly)
|
||||
|
||||
* Where does web UI stand?
|
||||
|
||||
* OK to split it back out
|
||||
|
||||
* Use it as a container image
|
||||
|
||||
* Build image as part of kube release process
|
||||
|
||||
* Vendor it back in? Maybe, maybe not.
|
||||
|
||||
* Will DNS be split out?
|
||||
|
||||
* Probably more tightly integrated, instead
|
||||
|
||||
* Other potential spin-outs:
|
||||
|
||||
* apiserver
|
||||
|
||||
* clients
|
||||
-->
|
||||
* Web UI（preilly）
|
||||
|
||||
* Web UI 放在哪里？
|
||||
|
||||
* 确定将其拆分出去
|
||||
|
||||
* 将其用作容器镜像
|
||||
|
||||
* 作为 kube 发布过程的一部分构建映像
|
||||
|
||||
* vendor回来了吗？也许吧，也许不是。
|
||||
|
||||
* DNS将被拆分吗？
|
||||
|
||||
* 可能更紧密地集成在一起，而不是
|
||||
|
||||
* 其他潜在的衍生产品：
|
||||
|
||||
* apiserver
|
||||
|
||||
* clients
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: " Kubernetes 社区指导委员会选举结果 "
|
||||
date: 2017-10-05
|
||||
slug: kubernetes-community-steering-committee-election-results
|
||||
url: /blog/2017/10/Kubernetes-Community-Steering-Committee-Election-Results
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: " Kubernetes Community Steering Committee Election Results "
|
||||
date: 2017-10-05
|
||||
slug: kubernetes-community-steering-committee-election-results
|
||||
url: /blog/2017/10/Kubernetes-Community-Steering-Committee-Election-Results
|
||||
---
|
||||
-->
|
||||
<!--
|
||||
Beginning with the announcement of Kubernetes 1.0 at OSCON in 2015, there has been a concerted effort to share the power and burden of leadership across the Kubernetes community.
|
||||
-->
|
||||
自 2015 年 OSCON 发布 Kubernetes 1.0 以来，大家一直在共同努力，在 Kubernetes 社区中共同分享领导力和责任。
|
||||
|
||||
<!--
|
||||
With the work of the Bootstrap Governance Committee, consisting of Brandon Philips, Brendan Burns, Brian Grant, Clayton Coleman, Joe Beda, Sarah Novotny and Tim Hockin - a cross section of long-time leaders representing 5 different companies with major investments of talent and effort in the Kubernetes Ecosystem - we wrote an initial [Steering Committee Charter](https://github.com/kubernetes/steering/blob/master/charter.md) and launched a community wide election to seat a Kubernetes Steering Committee.
|
||||
-->
|
||||
在 Brandon Philips、Brendan Burns、Brian Grant、Clayton Coleman、Joe Beda、Sarah Novotny 和 Tim Hockin 组成的自举治理委员会的工作下 - 代表 5 家不同公司的长期领导者，他们对 Kubernetes 生态系统进行了大量的人才投资和努力 - 编写了初始的[指导委员会章程](https://github.com/kubernetes/steering/blob/master/charter.md)，并发起了一次社区选举，以选举 Kubernetes 指导委员会成员。
|
||||
|
||||
<!--
|
||||
To quote from the Charter -
|
||||
-->
|
||||
引用章程 -
|
||||
|
||||
<!--
|
||||
_The initial role of the steering committee is to **instantiate the formal process for Kubernetes governance**. In addition to defining the initial governance process, the bootstrap committee strongly believes that **it is important to provide a means for iterating** the processes defined by the steering committee. We do not believe that we will get it right the first time, or possibly ever, and won’t even complete the governance development in a single shot. The role of the steering committee is to be a live, responsive body that can refactor and reform as necessary to adapt to a changing project and community._
|
||||
-->
|
||||
_指导委员会的最初职责是**实例化 Kubernetes 治理的正式过程**。除定义初始治理过程外，指导委员会还坚信**提供一种方法来迭代指导委员会定义的方法很重要**。我们不相信我们会在第一次或以后把这些做好，也不会一口气完成治理开发工作。指导委员会的作用是成为一个积极响应的机构，可以根据需要进行重构和改造，以适应不断变化的项目和社区。
|
||||
|
||||
<!--
|
||||
This is our largest step yet toward making an implicit governance structure explicit. Kubernetes vision has been one of an inclusive and broad community seeking to build software which empowers our users with the portability of containers. The Steering Committee will be a strong leadership voice guiding the project toward success.
|
||||
-->
|
||||
这是将我们隐式治理结构明确化的最大一步。Kubernetes 的愿景一直是成为一个包容而广泛的社区，用我们的软件带给用户容器的便利性。指导委员会将是一个强有力的引领声音，指导该项目取得成功。
|
||||
|
||||
<!--
|
||||
The Kubernetes Community is pleased to announce the results of the 2017 Steering Committee Elections. **Please congratulate Aaron Crickenberger, Derek Carr, Michelle Noorali, Phillip Wittrock, Quinton Hoole and Timothy St. Clair** , who will be joining the members of the Bootstrap Governance committee on the newly formed Kubernetes Steering Committee. Derek, Michelle, and Phillip will serve for 2 years. Aaron, Quinton, and Timothy will serve for 1 year.
|
||||
-->
|
||||
Kubernetes 社区很高兴地宣布 2017 年指导委员会选举的结果。 **请祝贺 Aaron Crickenberger、Derek Carr、Michelle Noorali、Phillip Wittrock、Quinton Hoole 和 Timothy St. Clair**，他们将成为新成立的 Kubernetes 指导委员会的自举治理委员会成员。Derek、Michelle 和 Phillip 将任职 2 年。Aaron、Quinton、和 Timothy 将任职 1 年。
|
||||
|
||||
<!--
|
||||
This group will meet regularly in order to clarify and streamline the structure and operation of the project. Early work will include electing a representative to the CNCF Governing Board, evolving project processes, refining and documenting the vision and scope of the project, and chartering and delegating to more topical community groups.
|
||||
-->
|
||||
该小组将定期开会，以阐明和简化项目的结构和运行。早期的工作将包括选举 CNCF 理事会的代表，发展项目流程，完善和记录项目的愿景和范围，以及授权和委派更多主题社区团体。
|
||||
|
||||
<!--
|
||||
Please see [the full Steering Committee backlog](https://github.com/kubernetes/steering/blob/master/backlog.md) for more details.
|
||||
-->
|
||||
请参阅[完整的指导委员会待办事项列表](https://github.com/kubernetes/steering/blob/master/backlog.md)以获取更多详细信息。
|
||||
@@ -226,14 +226,14 @@ There are two supported paths to extending the API with [custom resources](/docs
|
||||
为客户提供无缝的服务。
|
||||
|
||||
<!--
|
||||
## Enabling API groups
|
||||
## Enabling or disabling API groups
|
||||
|
||||
Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `--runtime-config`
|
||||
on apiserver. `--runtime-config` accepts comma separated values. For ex: to disable batch/v1, set
|
||||
on apiserver. `--runtime-config` accepts comma separated values. For example: to disable batch/v1, set
|
||||
`--runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`.
|
||||
The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
|
||||
|
||||
IMPORTANT: Enabling or disabling groups or resources requires restarting apiserver and controller-manager
|
||||
Enabling or disabling groups or resources requires restarting apiserver and controller-manager
|
||||
to pick up the `--runtime-config` changes.
|
||||
-->
|
||||
|
||||
@@ -244,22 +244,31 @@ to pick up the `--runtime-config` changes.
|
||||
例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。
|
||||
该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。
|
||||
|
||||
重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。
|
||||
{{< note >}}
|
||||
|
||||
启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Enabling resources in the groups
|
||||
## Enabling specific resources in the extensions/v1beta1 group
|
||||
|
||||
DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs and ReplicaSets are enabled by default.
|
||||
Other extensions resources can be enabled by setting `--runtime-config` on
|
||||
apiserver. `--runtime-config` accepts comma separated values. For example: to disable deployments and ingress, set
|
||||
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`
|
||||
DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
|
||||
For example: to enable deployments and daemonsets, set
|
||||
`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
|
||||
|
||||
Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.
|
||||
-->
|
||||
|
||||
## 启用组中资源
|
||||
## 启用 extensions/v1beta1 组中资源
|
||||
|
||||
DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。
|
||||
其他扩展资源可以通过在apiserver上设置 `--runtime-config` 来启用。
|
||||
`--runtime-config` 接受逗号分隔的值。 例如：要禁用 Deployment 和 Ingress，
|
||||
请设置 `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`
|
||||
在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。
|
||||
例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。
|
||||
|
||||
{{< note >}}
|
||||
|
||||
出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
approvers:
|
||||
- derekwaynecarr
|
||||
title: 资源配额
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
@@ -412,7 +412,7 @@ By default, kube-proxy in userspace mode chooses a backend via a round-robin alg
|
||||
任何连接到“代理端口”的请求，都会被代理到 `Service` 的backend `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。
|
||||
使用哪个 backend `Pod`，是 kube-proxy 基于 `SessionAffinity` 来确定的。
|
||||
|
||||
最后，它安装 iptables 规则，捕获到达该 `Service` 的 `clusterIP`（是虚拟 IP）和 `Port` 的请求，并重定向到代理端口，代理端口再代理请求到 backend `Pod`。
|
||||
最后，它配置 iptables 规则，捕获到达该 `Service` 的 `clusterIP`（是虚拟 IP）和 `Port` 的请求，并重定向到代理端口，代理端口再代理请求到 backend `Pod`。
|
||||
|
||||
默认情况下，用户空间模式下的kube-proxy通过循环算法选择后端。
|
||||
|
||||
@@ -451,8 +451,8 @@ having traffic sent via kube-proxy to a Pod that's known to have failed.
|
||||
### iptables 代理模式 {#proxy-mode-iptables}
|
||||
|
||||
这种模式，kube-proxy 会监视 Kubernetes 控制节点对 `Service` 对象和 `Endpoints` 对象的添加和移除。
|
||||
对每个 `Service`，它会安装 iptables 规则，从而捕获到达该 `Service` 的 `clusterIP` 和端口的请求，进而将请求重定向到 `Service` 的一组 backend 中的某个上面。
|
||||
对于每个 `Endpoints` 对象，它也会安装 iptables 规则，这个规则会选择一个 backend 组合。
|
||||
对每个 `Service`，它会配置 iptables 规则，从而捕获到达该 `Service` 的 `clusterIP` 和端口的请求，进而将请求重定向到 `Service` 的一组 backend 中的某个上面。
|
||||
对于每个 `Endpoints` 对象，它也会配置 iptables 规则，这个规则会选择一个 backend 组合。
|
||||
|
||||
默认的策略是，kube-proxy 在 iptables 模式下随机选择一个 backend。
|
||||
|
||||
@@ -1679,7 +1679,7 @@ through a load-balancer, though in those cases the client IP does get altered.
|
||||
再次考虑前面提到的图片处理应用程序。
|
||||
当创建 backend `Service` 时，Kubernetes 控制面板会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
|
||||
假设 `Service` 的端口是 1234，该 `Service` 会被集群中所有的 `kube-proxy` 实例观察到。
|
||||
当代理看到一个新的 `Service`， 它会安装一系列的 iptables 规则，从 VIP 重定向到 per-`Service` 规则。
|
||||
当代理看到一个新的 `Service`， 它会配置一系列的 iptables 规则，从 VIP 重定向到 per-`Service` 规则。
|
||||
该 per-`Service` 规则连接到 per-`Endpoint` 规则，该 per-`Endpoint` 规则会重定向（目标 NAT）到 backend。
|
||||
|
||||
当一个客户端连接到一个 VIP，iptables 规则开始起作用。一个 backend 会被选择（或者根据会话亲和性，或者随机），数据包被重定向到这个 backend。
|
||||
|
||||
@@ -69,7 +69,7 @@ parameters:
|
||||
Volume snapshot classes have a driver that determines what CSI volume plugin is
|
||||
used for provisioning VolumeSnapshots. This field must be specified.
|
||||
-->
|
||||
### 驱动程序（#driver）
|
||||
### 驱动程序 {#driver}
|
||||
|
||||
卷快照类有一个驱动程序，用于确定配置 VolumeSnapshot 的 CSI 卷插件。 必须指定此字段。
|
||||
|
||||
|
||||
@@ -1771,10 +1771,6 @@ Choose one of the following methods to create a VMDK.
|
||||
|
||||
{{< tabs name="tabs_volumes" >}}
|
||||
{{% tab name="使用 vmkfstools 创建" %}}
|
||||
<!--
|
||||
{{% tab name="Create using vmkfstools" %}}
|
||||
First ssh into ESX, then use the following command to create a VMDK:
|
||||
-->
|
||||
|
||||
首先 ssh 到 ESX，然后使用下面的命令来创建 VMDK：
|
||||
|
||||
@@ -1783,10 +1779,6 @@ vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="使用 vmware-vdiskmanager 创建" %}}
|
||||
<!--
|
||||
{{% tab name="Create using vmware-vdiskmanager" %}}
|
||||
Use the following command to create a VMDK:
|
||||
-->
|
||||
|
||||
使用下面的命令创建 VMDK：
|
||||
|
||||
@@ -2409,7 +2401,7 @@ sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -2418,4 +2410,5 @@ sudo systemctl restart docker
|
||||
-->
|
||||
|
||||
* 参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -696,14 +696,15 @@ most up-to-date version of that branch.
|
||||
git commit -m "Your commit message"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Do not reference a GitHub issue or pull request by ID or URL in the
|
||||
commit message. If you do, it will cause that issue or pull request to get
|
||||
a notification every time the commit shows up in a new Git branch. You can
|
||||
link issues and pull requests together later, in the GitHub UI.
|
||||
-->不要在提交消息中引用 GitHub issue 或 PR(通过 ID 或 URL)。如果您这样做了，那么每当提交出现在新的Git 分支中时，就会导致该 issue 或 PR 获得通知。稍后，您可以在 GitHub UI 中链接 issues 并将请求拉到一起。
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
<!--
|
||||
Do not reference a GitHub issue or pull request by ID or URL in the
|
||||
commit message. If you do, it will cause that issue or pull request to get
|
||||
a notification every time the commit shows up in a new Git branch. You can
|
||||
link issues and pull requests together later, in the GitHub UI.
|
||||
-->
|
||||
不要在提交消息中引用 GitHub issue 或 PR(通过 ID 或 URL)。如果您这样做了，那么每当提交出现在新的 Git 分支中时，就会导致该 issue 或 PR 获得通知。稍后，您可以在 GitHub UI 中链接 issues 并将请求拉到一起。
|
||||
{{< /note >}}
|
||||
|
||||
5. <!--
|
||||
Optionally, you can test your change by staging the site locally using the
|
||||
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user