Merge branch 'kubernetes:main' into pod-configmap-env-var-valueFrom
This commit is contained in:
my-git9
@@ -0,0 +1,154 @@
|
||||
---
|
||||
layout: blog
|
||||
title: 'Kubernetes 1.23：IPv4/IPv6 双协议栈网络达到 GA'
|
||||
date: 2021-12-08
|
||||
slug: dual-stack-networking-ga
|
||||
---
|
||||
<!--
|
||||
layout: blog
|
||||
title: 'Kubernetes 1.23: Dual-stack IPv4/IPv6 Networking Reaches GA'
|
||||
date: 2021-12-08
|
||||
slug: dual-stack-networking-ga
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Author:** Bridget Kromhout (Microsoft)
|
||||
-->
|
||||
**作者:** Bridget Kromhout (微软)
|
||||
|
||||
<!--
|
||||
"When will Kubernetes have IPv6?" This question has been asked with increasing frequency ever since alpha support for IPv6 was first added in k8s v1.9. While Kubernetes has supported IPv6-only clusters since v1.18, migration from IPv4 to IPv6 was not yet possible at that point. At long last, [dual-stack IPv4/IPv6 networking](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/) has reached general availability (GA) in Kubernetes v1.23.
|
||||
|
||||
What does dual-stack networking mean for you? Let’s take a look…
|
||||
-->
|
||||
“Kubernetes 何时支持 IPv6？” 自从 k8s v1.9 版本中首次添加对 IPv6 的 alpha 支持以来，这个问题的讨论越来越频繁。
|
||||
虽然 Kubernetes 从 v1.18 版本开始就支持纯 IPv6 集群，但当时还无法支持 IPv4 迁移到 IPv6。
|
||||
[IPv4/IPv6 双协议栈网络](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/)
|
||||
在 Kubernetes v1.23 版本中进入正式发布（GA）阶段。
|
||||
|
||||
让我们来看看双协议栈网络对你来说意味着什么？
|
||||
|
||||
<!--
|
||||
## Service API updates
|
||||
-->
|
||||
## 更新 Service API
|
||||
|
||||
<!--
|
||||
[Services](/docs/concepts/services-networking/service/) were single-stack before 1.20, so using both IP families meant creating one Service per IP family. The user experience was simplified in 1.20, when Services were re-implemented to allow both IP families, meaning a single Service can handle both IPv4 and IPv6 workloads. Dual-stack load balancing is possible between services running any combination of IPv4 and IPv6.
|
||||
-->
|
||||
[Services](/zh/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的，
|
||||
因此，使用两个 IP 协议族意味着需为每个 IP 协议族创建一个 Service。在 1.20 版本中对用户体验进行简化，
|
||||
重新实现了 Service 以支持两个 IP 协议族，这意味着一个 Service 就可以处理 IPv4 和 IPv6 协议。
|
||||
对于 Service 而言，任意的 IPv4 和 IPv6 协议组合都可以实现负载均衡。
|
||||
|
||||
<!--
|
||||
The Service API now has new fields to support dual-stack, replacing the single ipFamily field.
|
||||
* You can select your choice of IP family by setting `ipFamilyPolicy` to one of three options: SingleStack, PreferDualStack, or RequireDualStack. A service can be changed between single-stack and dual-stack (within some limits).
|
||||
* Setting `ipFamilies` to a list of families assigned allows you to set the order of families used.
|
||||
* `clusterIPs` is inclusive of the previous `clusterIP` but allows for multiple entries, so it’s no longer necessary to run duplicate services, one in each of the two IP families. Instead, you can assign cluster IP addresses in both IP families.
|
||||
-->
|
||||
Service API 现在有了支持双协议栈的新字段，取代了单一的 ipFamily 字段。
|
||||
* 你可以通过将 `ipFamilyPolicy` 字段设置为 `SingleStack`、`PreferDualStack` 或
|
||||
`RequireDualStack` 来设置 IP 协议族。Service 可以在单协议栈和双协议栈之间进行转换(在某些限制内)。
|
||||
* 设置 `ipFamilies` 为指定的协议族列表，可用来设置使用协议族的顺序。
|
||||
* 'clusterIPs' 的能力在涵盖了之前的 'clusterIP'的情况下，还允许设置多个 IP 地址。
|
||||
所以不再需要运行重复的 Service，在两个 IP 协议族中各运行一个。你可以在两个 IP 协议族中分配集群 IP 地址。
|
||||
|
||||
<!--
|
||||
Note that Pods are also dual-stack. For a given pod, there is no possibility of setting multiple IP addresses in the same family.
|
||||
-->
|
||||
请注意，Pods 也是双协议栈的。对于一个给定的 Pod，不可能在同一协议族中设置多个 IP 地址。
|
||||
|
||||
<!--
|
||||
## Default behavior remains single-stack
|
||||
-->
|
||||
## 默认行为仍然是单协议栈
|
||||
|
||||
<!--
|
||||
Starting in 1.20 with the re-implementation of dual-stack services as alpha, the underlying networking for Kubernetes has included dual-stack whether or not a cluster was configured with the feature flag to enable dual-stack.
|
||||
-->
|
||||
从 1.20 版本开始，重新实现的双协议栈服务处于 Alpha 阶段，无论集群是否配置了启用双协议栈的特性标志，
|
||||
Kubernetes 的底层网络都已经包括了双协议栈。
|
||||
|
||||
<!--
|
||||
Kubernetes 1.23 removed that feature flag as part of graduating the feature to stable. Dual-stack networking is always available if you want to configure it. You can set your cluster network to operate as single-stack IPv4, as single-stack IPv6, or as dual-stack IPv4/IPv6.
|
||||
-->
|
||||
Kubernetes 1.23 删除了这个特性标志，说明该特性已经稳定。
|
||||
如果你想要配置双协议栈网络，这一能力总是存在的。
|
||||
你可以将集群网络设置为 IPv4 单协议栈 、IPv6 单协议栈或 IPV4/IPV6 双协议栈 。
|
||||
|
||||
<!--
|
||||
While Services are set according to what you configure, Pods default to whatever the CNI plugin sets. If your CNI plugin assigns single-stack IPs, you will have single-stack unless `ipFamilyPolicy` specifies PreferDualStack or RequireDualStack. If your CNI plugin assigns dual-stack IPs, `pod.status.PodIPs` defaults to dual-stack.
|
||||
-->
|
||||
虽然 Service 是根据你的配置设置的，但 Pod 默认是由 CNI 插件设置的。
|
||||
如果你的 CNI 插件分配单协议栈 IP，那么就是单协议栈，除非 `ipFamilyPolicy` 设置为 `PreferDualStack` 或 `RequireDualStack`。
|
||||
如果你的 CNI 插件分配双协议栈 IP，则 `pod.status.PodIPs` 默认为双协议栈。
|
||||
|
||||
<!--
|
||||
Even though dual-stack is possible, it is not mandatory to use it. Examples in the documentation show the variety possible in [dual-stack service configurations](/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios).
|
||||
-->
|
||||
尽管双协议栈是可用的，但并不强制你使用它。
|
||||
在[双协议栈服务配置](/zh/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios)
|
||||
文档中的示例列出了可能出现的各种场景.
|
||||
|
||||
<!--
|
||||
## Try dual-stack right now
|
||||
-->
|
||||
## 现在尝试双协议栈
|
||||
|
||||
<!--
|
||||
While upstream Kubernetes now supports [dual-stack networking](/docs/concepts/services-networking/dual-stack/) as a GA or stable feature, each provider’s support of dual-stack Kubernetes may vary. Nodes need to be provisioned with routable IPv4/IPv6 network interfaces. Pods need to be dual-stack. The [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) is what assigns the IP addresses to the Pods, so it's the network plugin being used for the cluster that needs to support dual-stack. Some Container Network Interface (CNI) plugins support dual-stack, as does kubenet.
|
||||
-->
|
||||
虽然现在上游 Kubernetes 支持[双协议栈网络](/zh/docs/concepts/services-networking/dual-stack/)
|
||||
作为 GA 或稳定特性，但每个提供商对双协议栈 Kubernetes 的支持可能会有所不同。节点需要提供可路由的 IPv4/IPv6 网络接口。
|
||||
Pod 需要是双协议栈的。[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
是用来为 Pod 分配 IP 地址的，所以集群需要支持双协议栈的网络插件。一些容器网络接口（CNI）插件支持双协议栈，例如 kubenet。
|
||||
|
||||
<!--
|
||||
Ecosystem support of dual-stack is increasing; you can create [dual-stack clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), try a [dual-stack cluster locally with KIND](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family), and deploy dual-stack clusters in cloud providers (after checking docs for CNI or kubenet availability).
|
||||
-->
|
||||
支持双协议栈的生态系统在不断壮大；你可以使用
|
||||
[kubeadm 创建双协议栈集群](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/),
|
||||
在本地尝试用 [KIND 创建双协议栈集群](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family)，
|
||||
还可以将双协议栈集群部署到云上（在查阅 CNI 或 kubenet 可用性的文档之后）
|
||||
|
||||
<!--
|
||||
## Get involved with SIG Network
|
||||
-->
|
||||
## 加入 Network SIG
|
||||
|
||||
<!--
|
||||
SIG-Network wants to learn from community experiences with dual-stack networking to find out more about evolving needs and your use cases. The [SIG-network update video from KubeCon NA 2021](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4) summarizes the SIG’s recent updates, including dual-stack going to stable in 1.23.
|
||||
-->
|
||||
SIG-Network 希望从双协议栈网络的社区体验中学习，以了解更多不断变化的需求和你的用例信息。
|
||||
[SIG-network 更新了来自 KubeCon 2021 北美大会的视频](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4)
|
||||
总结了 SIG 最近的更新，包括双协议栈将在 1.23 版本中稳定。
|
||||
|
||||
<!--
|
||||
The current SIG-Network [KEPs](https://github.com/orgs/kubernetes/projects/10) and [issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) on GitHub illustrate the SIG’s areas of emphasis. The [dual-stack API server](https://github.com/kubernetes/enhancements/issues/2438) is one place to consider contributing.
|
||||
-->
|
||||
当前 SIG-Network 在 GitHub 上的 [KEPs](https://github.com/orgs/kubernetes/projects/10) 和
|
||||
[issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork)
|
||||
说明了该 SIG 的重点领域。[双协议栈 API 服务器](https://github.com/kubernetes/enhancements/issues/2438)
|
||||
是一个考虑贡献的方向。
|
||||
|
||||
<!--
|
||||
[SIG-Network meetings](https://github.com/kubernetes/community/tree/master/sig-network#meetings) are a friendly, welcoming venue for you to connect with the community and share your ideas. Looking forward to hearing from you!
|
||||
-->
|
||||
[SIG-Network 会议](https://github.com/kubernetes/community/tree/master/sig-network#meetings)
|
||||
是一个友好、热情的场所，你可以与社区联系并分享你的想法。期待你的加入！
|
||||
|
||||
<!--
|
||||
## Acknowledgments
|
||||
-->
|
||||
## 致谢
|
||||
|
||||
<!--
|
||||
The dual-stack networking feature represents the work of many Kubernetes contributors. Thanks to all who contributed code, experience reports, documentation, code reviews, and everything in between. Bridget Kromhout details this community effort in [Dual-Stack Networking in Kubernetes](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/). KubeCon keynotes by Tim Hockin & Khaled (Kal) Henidak in 2019 ([The Long Road to IPv4/IPv6 Dual-stack Kubernetes](https://www.youtube.com/watch?v=o-oMegdZcg4)) and by Lachlan Evenson in 2021 ([And Here We Go: Dual-stack Networking in Kubernetes](https://www.youtube.com/watch?v=lVrt8F2B9CM)) talk about the dual-stack journey, spanning five years and a great many lines of code.
|
||||
-->
|
||||
许多 Kubernetes 贡献者为双协议栈网络做出了贡献。感谢所有贡献了代码、经验报告、文档、代码审查以及其他工作的人。
|
||||
Bridget Kromhout 在 [Kubernetes的双协议栈网络](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/)
|
||||
中详细介绍了这项社区工作。Tim Hockin 和 Khaled (Kal) Henidak 在 2019 年的 KubeCon 大会演讲
|
||||
（[Kubernetes 通往 IPv4/IPv6 双协议栈的漫漫长路](https://www.youtube.com/watch?v=o-oMegdZcg4)）
|
||||
和 Lachlan Evenson 在 2021 年演讲（[我们来啦，Kubernetes 双协议栈网络](https://www.youtube.com/watch?v=o-oMegdZcg4)）
|
||||
中讨论了双协议栈的发展旅程，耗时 5 年和海量代码。
|
||||
@@ -3,7 +3,6 @@ layout: blog
|
||||
title: "更新：弃用 Dockershim 的常见问题"
|
||||
date: 2022-02-17
|
||||
slug: dockershim-faq
|
||||
aliases: [ '/dockershim' ]
|
||||
---
|
||||
<!--
|
||||
layout: blog
|
||||
|
||||
@@ -0,0 +1,180 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "认识我们的贡献者 - 亚太地区（澳大利亚-新西兰地区）"
|
||||
date: 2022-03-16T12:00:00+0000
|
||||
slug: meet-our-contributors-au-nz-ep-02
|
||||
canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
|
||||
---
|
||||
<!--
|
||||
layout: blog
|
||||
title: "Meet Our Contributors - APAC (Aus-NZ region)"
|
||||
date: 2022-03-16T12:00:00+0000
|
||||
slug: meet-our-contributors-au-nz-ep-02
|
||||
canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Brad McCoy](https://github.com/bradmccoydev), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Priyanka Saggu](github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
|
||||
-->
|
||||
**作者和采访者：**
|
||||
[Anubhav Vardhan](https://github.com/anubha-v-ardhan),
|
||||
[Atharva Shinde](https://github.com/Atharva-Shinde),
|
||||
[Avinesh Tripathi](https://github.com/AvineshTripathi),
|
||||
[Brad McCoy](https://github.com/bradmccoydev),
|
||||
[Debabrata Panigrahi](https://github.com/Debanitrkl),
|
||||
[Jayesh Srivastava](https://github.com/jayesh-srivastava),
|
||||
[Kunal Verma](https://github.com/verma-kunal),
|
||||
[Pranshu Srivastava](https://github.com/PranshuSrivastava),
|
||||
[Priyanka Saggu](github.com/Priyankasaggu11929/),
|
||||
[Purneswar Prasad](https://github.com/PurneswarPrasad),
|
||||
[Vedant Kakde](https://github.com/vedant-kakde)
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
Good day, everyone 👋
|
||||
-->
|
||||
大家好👋
|
||||
|
||||
<!--
|
||||
Welcome back to the second episode of the "Meet Our Contributors" blog post series for APAC.
|
||||
-->
|
||||
欢迎来到亚太地区的”认识我们的贡献者”博文系列第二期。
|
||||
|
||||
<!--
|
||||
This post will feature four outstanding contributors from the Australia and New Zealand regions, who have played diverse leadership and community roles in the Upstream Kubernetes project.
|
||||
-->
|
||||
这篇文章将介绍来自澳大利亚和新西兰地区的四位杰出贡献者，
|
||||
他们在上游 Kubernetes 项目中承担着不同子项目的领导者和社区贡献者的角色。
|
||||
|
||||
<!--
|
||||
So, without further ado, let's get straight to the blog.
|
||||
-->
|
||||
闲话少说，让我们直接进入主题。
|
||||
|
||||
## [Caleb Woodbine](https://github.com/BobyMCbobs)
|
||||
|
||||
<!--
|
||||
Caleb Woodbine is currently a member of the ii.nz organisation.
|
||||
-->
|
||||
Caleb Woodbine 目前是 ii.nz 组织的成员。
|
||||
|
||||
<!--
|
||||
He began contributing to the Kubernetes project in 2018 as a member of the Kubernetes Conformance working group. His experience was positive, and he benefited from early guidance from [Hippie Hacker](https://github.com/hh), a fellow contributor from New Zealand.
|
||||
-->
|
||||
他于 2018 年作为 Kubernetes Conformance 工作组的成员开始为 Kubernetes 项目做贡献。
|
||||
他积极向上，他从一位来自新西兰的贡献者 [Hippie Hacker](https://github.com/hh) 的早期指导中受益匪浅。
|
||||
|
||||
<!--
|
||||
He has made major contributions to Kubernetes project since then through `SIG k8s-infra` and `k8s-conformance` working group.
|
||||
-->
|
||||
他在 `SIG k8s-infra` 和 `k8s-conformance` 工作组为 Kubernetes 项目做出了重大贡献。
|
||||
|
||||
<!--
|
||||
Caleb is also a co-organizer of the [CloudNative NZ](https://www.meetup.com/cloudnative-nz/) community events, which aim to expand the reach of Kubernetes project throughout New Zealand in order to encourage technical education and improved employment opportunities.
|
||||
-->
|
||||
Caleb 也是 [CloudNative NZ](https://www.meetup.com/cloudnative-nz/)
|
||||
社区活动的联合组织者，该活动旨在扩大 Kubernetes 项目在整个新西兰的影响力，以鼓励科技教育和改善就业机会。
|
||||
|
||||
<!--
|
||||
> _There need to be more outreach in APAC and the educators and universities must pick up Kubernetes, as they are very slow and about 8+ years out of date. NZ tends to rather pay overseas than educate locals on the latest cloud tech Locally._
|
||||
-->
|
||||
> _亚太地区需要更多的外联活动，教育工作者和大学必须学习 Kubernetes，因为他们非常缓慢，
|
||||
而且已经落后了8年多。新西兰倾向于在海外付费，而不是教育当地人最新的云技术。_
|
||||
|
||||
## [Dylan Graham](https://github.com/DylanGraham)
|
||||
|
||||
<!--
|
||||
Dylan Graham is a cloud engineer from Adeliade, Australia. He has been contributing to the upstream Kubernetes project since 2018.
|
||||
-->
|
||||
Dylan Graham 是来自澳大利亚 Adeliade 的云计算工程师。自 2018 年以来，他一直在为上游 Kubernetes 项目做出贡献。
|
||||
|
||||
<!--
|
||||
He stated that being a part of such a large-scale project was initially overwhelming, but that the community's friendliness and openness assisted him in getting through it.
|
||||
-->
|
||||
他表示，成为如此大项目的一份子，最初压力是比较大的，但社区的友好和开放帮助他度过了难关。
|
||||
|
||||
<!--
|
||||
He began by contributing to the project documentation and is now mostly focused on the community support for the APAC region.
|
||||
-->
|
||||
开始在项目文档方面做贡献，现在主要致力于为亚太地区提供社区支持。
|
||||
|
||||
<!--
|
||||
He believes that consistent attendance at community/project meetings, taking on project tasks, and seeking community guidance as needed can help new aspiring developers become effective contributors.
|
||||
-->
|
||||
他相信，持续参加社区/项目会议，承担项目任务，并在需要时寻求社区指导，可以帮助有抱负的新开发人员成为有效的贡献者。
|
||||
|
||||
<!--
|
||||
> _The feeling of being a part of a large community is really special. I've met some amazing people, even some before the pandemic in real life :)_
|
||||
-->
|
||||
> _成为大社区的一份子感觉真的很特别。我遇到了一些了不起的人，甚至是在现实生活中疫情发生之前。_
|
||||
|
||||
## [Hippie Hacker](https://github.com/hh)
|
||||
|
||||
<!--
|
||||
Hippie has worked for the CNCF.io as a Strategic Initiatives contractor from New Zealand for almost 5+ years. He is an active contributor to k8s-infra, API conformance testing, Cloud provider conformance submissions, and apisnoop.cncf.io domains of the upstream Kubernetes & CNCF projects.
|
||||
-->
|
||||
Hippie 来自新西兰，曾在 CNCF.io 作为战略计划承包商工作 5 年多。他是 k8s-infra、
|
||||
API 一致性测试、云提供商一致性提交以及上游 Kubernetes 和 CNCF 项目 apisnoop.cncf.io 域的积极贡献者。
|
||||
|
||||
<!--
|
||||
He recounts their early involvement with the Kubernetes project, which began roughly 5 years ago when their firm, ii.nz, demonstrated [network booting from a Raspberry Pi using PXE and running Gitlab in-cluster to install Kubernetes on servers](https://ii.nz/post/bringing-the-cloud-to-your-community/).
|
||||
-->
|
||||
他讲述了他们早期参与 Kubernetes 项目的情况，该项目始于大约 5 年前，当时他们的公司 ii.nz
|
||||
演示了[使用 PXE 从 Raspberry Pi 启动网络，并在集群中运行Gitlab，以便在服务器上安装 Kubernetes ](https://ii.nz/post/bringing-the-cloud-to-your-community/)
|
||||
|
||||
<!--
|
||||
He describes their own contributing experience as someone who, at first, tried to do all of the hard lifting on their own, but eventually saw the benefit of group contributions which reduced burnout and task division which allowed folks to keep moving forward on their own momentum.
|
||||
-->
|
||||
他描述了自己的贡献经历：一开始，他试图独自完成所有艰巨的任务，但最终看到了团队协作贡献的好处，
|
||||
分工合作减少了过度疲劳，这让人们能够凭借自己的动力继续前进。
|
||||
|
||||
<!--
|
||||
He recommends that new contributors use pair programming.
|
||||
-->
|
||||
他建议新的贡献者结对编程。
|
||||
|
||||
<!--
|
||||
> _The cross pollination of approaches and two pairs of eyes on the same work can often yield a much more amplified effect than a PR comment / approval alone can afford._
|
||||
-->
|
||||
> _针对一个项目，多人关注和交叉交流往往比单独的评审、批准 PR 能产生更大的效果。_
|
||||
|
||||
## [Nick Young](https://github.com/youngnick)
|
||||
|
||||
<!--
|
||||
Nick Young works at VMware as a technical lead for Contour, a CNCF ingress controller. He was active with the upstream Kubernetes project from the beginning, and eventually became the chair of the LTS working group, where he advocated user concerns. He is currently the SIG Network Gateway API subproject's maintainer.
|
||||
-->
|
||||
Nick Young 在 VMware 工作，是 CNCF 入口控制器 Contour 的技术负责人。
|
||||
他从一开始就积极参与上游 Kubernetes 项目，最终成为 LTS 工作组的主席，
|
||||
他提倡关注用户。他目前是 SIG Network Gateway API 子项目的维护者。
|
||||
|
||||
<!--
|
||||
His contribution path was notable in that he began working on major areas of the Kubernetes project early on, skewing his trajectory.
|
||||
-->
|
||||
他的贡献之路是引人注目的，因为他很早就在 Kubernetes 项目的主要领域工作，这改变了他的轨迹。
|
||||
|
||||
<!--
|
||||
He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions.
|
||||
-->
|
||||
他断言，一个新贡献者能做的最好的事情就是“开始贡献”。当然，如果与他的工作息息相关，那好极了;
|
||||
然而，把非工作时间投入到贡献中去，从长远来看可以在工作上获得回报。
|
||||
他认为，应该鼓励新的贡献者，特别是那些目前是 Kubernetes 用户的人，参与到更高层次的项目讨论中来。
|
||||
|
||||
<!--
|
||||
> _Just being active and contributing will get you a long way. Once you've been active for a while, you'll find that you're able to answer questions, which will mean you're asked questions, and before you know it you are an expert._
|
||||
-->
|
||||
> _只要积极主动，做出贡献，你就可以走很远。一旦你活跃了一段时间，你会发现你能够解答别人的问题，
|
||||
这意味着会有人请教你或和你讨论，在你意识到这一点之前，你就已经是专家了。_
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.
|
||||
-->
|
||||
如果你对我们接下来应该采访的人有任何意见/建议，请在 #sig-contribex 中告知我们。
|
||||
非常感谢你的建议。我们很高兴有更多的人帮助我们接触到社区中更优秀的人。
|
||||
|
||||
<!--
|
||||
We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
|
||||
-->
|
||||
我们下期再见。祝你有个愉快的贡献之旅!👋
|
||||
File diff suppressed because it is too large
Load Diff
@@ -75,7 +75,7 @@ node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
|
||||
<!--
|
||||
Then the cluster is logically viewed as below:
|
||||
-->
|
||||
然后从逻辑上看集群如下：
|
||||
那么，从逻辑上看集群如下：
|
||||
|
||||
{{<mermaid>}}
|
||||
graph TB
|
||||
@@ -96,11 +96,9 @@ graph TB
|
||||
{{< /mermaid >}}
|
||||
|
||||
<!--
|
||||
|
||||
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
|
||||
-->
|
||||
你可以复用在大多数集群上自动创建和填充的
|
||||
[常用标签](/zh/docs/reference/labels-annotations-taints/)，
|
||||
你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)，
|
||||
而不是手动添加标签。
|
||||
|
||||
<!--
|
||||
@@ -169,6 +167,12 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
|
||||
拓扑域中 Pod 的数量。
|
||||
有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
|
||||
|
||||
<!--
|
||||
When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
|
||||
-->
|
||||
当 Pod 定义了不止一个 `topologySpreadConstraint`，这些约束之间是逻辑与的关系。
|
||||
kube-scheduler 会为新的 Pod 寻找一个能够满足所有约束的节点。
|
||||
|
||||
<!--
|
||||
You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
|
||||
-->
|
||||
@@ -353,7 +357,6 @@ graph BT
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
|
||||
<!--
|
||||
If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing.
|
||||
-->
|
||||
@@ -374,54 +377,59 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
|
||||
-->
|
||||
### 节点亲和性与节点选择器的相互作用 {#interaction-with-node-affinity-and-node-selectors}
|
||||
|
||||
如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，调度器将从倾斜计算中跳过不匹配的节点。
|
||||
如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，
|
||||
调度器将在偏差计算中跳过不匹配的节点。
|
||||
|
||||
<!--
|
||||
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
|
||||
### Example: TopologySpreadConstraints with NodeAffinity
|
||||
|
||||
and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
|
||||
-->
|
||||
假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
|
||||
### 示例：TopologySpreadConstraints 与 NodeAffinity
|
||||
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneC"
|
||||
n5(Node5)
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n5 k8s;
|
||||
class zoneC cluster;
|
||||
{{< /mermaid >}}
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneC"
|
||||
n5(Node5)
|
||||
end
|
||||
|
||||
而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml，
|
||||
以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
|
||||
也要一样处理。
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n5 k8s;
|
||||
class zoneC cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
|
||||
<!--
|
||||
and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
|
||||
-->
|
||||
而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 YAML，
|
||||
以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
|
||||
也要一样处理。
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
|
||||
<!--
|
||||
The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them.
|
||||
@@ -503,7 +511,7 @@ An example configuration might look like follows:
|
||||
配置的示例可能看起来像下面这个样子：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta1
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
|
||||
profiles:
|
||||
@@ -565,20 +573,24 @@ is disabled.
|
||||
-->
|
||||
此外，原来用于提供等同行为的 `SelectorSpread` 插件也会被禁用。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `PodTopologySpread` plugin does not score the nodes that don't have
|
||||
the topology keys specified in the spreading constraints. This might result
|
||||
in a different default behavior compared to the legacy `SelectorSpread` plugin when
|
||||
using the default topology constraints.
|
||||
-->
|
||||
对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些主键的节点评分。
|
||||
这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同，
|
||||
|
||||
<!--
|
||||
If your nodes are not expected to have **both** `kubernetes.io/hostname` and
|
||||
`topology.kubernetes.io/zone` labels set, define your own constraints
|
||||
instead of using the Kubernetes defaults.
|
||||
|
||||
The `PodTopologySpread` plugin does not score the nodes that don't have
|
||||
the topology keys specified in the spreading constraints.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和
|
||||
`topology.kubernetes.io/zone` 标签，你应该定义自己的约束而不是使用
|
||||
Kubernetes 的默认约束。
|
||||
|
||||
插件 `PodTopologySpread` 不会为未设置分布约束中所给拓扑键的节点评分。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
@@ -586,11 +598,11 @@ If you don't want to use the default Pod spreading constraints for your cluster,
|
||||
you can disable those defaults by setting `defaultingType` to `List` and leaving
|
||||
empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
|
||||
-->
|
||||
如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List` 和
|
||||
将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
|
||||
如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List`
|
||||
并将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta1
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
|
||||
profiles:
|
||||
@@ -613,9 +625,9 @@ scheduled - more packed or more scattered.
|
||||
|
||||
<!--
|
||||
- For `PodAffinity`, you can try to pack any number of Pods into qualifying
|
||||
topology domain(s)
|
||||
topology domain(s)
|
||||
- For `PodAntiAffinity`, only one Pod can be scheduled into a
|
||||
single topology domain.
|
||||
single topology domain.
|
||||
-->
|
||||
- 对于 `PodAffinity`，你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
|
||||
- 对于 `PodAntiAffinity`，只能将一个 Pod 调度到某个拓扑域中。
|
||||
@@ -627,12 +639,6 @@ cost-saving. This can also help on rolling update workloads and scaling out
|
||||
replicas smoothly. See
|
||||
[Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
|
||||
for more details.
|
||||
|
||||
|
||||
The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
|
||||
topology domains - to achieve high availability or cost-saving. This can also help on rolling update
|
||||
workloads and scaling out replicas smoothly.
|
||||
See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
|
||||
-->
|
||||
要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，
|
||||
从而实现高可用性或节省成本。这也有助于工作负载的滚动更新和平稳地扩展副本规模。
|
||||
@@ -642,13 +648,19 @@ See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig
|
||||
<!--
|
||||
## Known Limitations
|
||||
|
||||
- Scaling down a Deployment may result in imbalanced Pods distribution.
|
||||
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
|
||||
You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
|
||||
|
||||
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
|
||||
-->
|
||||
## 已知局限性
|
||||
|
||||
- Deployment 缩容操作可能导致 Pod 分布不平衡。
|
||||
- 具有污点的节点上的 Pods 也会被统计。
|
||||
- 当 Pod 被移除时，无法保证约束仍被满足。例如，缩减某 Deployment 的规模时，
|
||||
Pod 的分布可能不再均衡。
|
||||
你可以使用 [Descheduler](https://github.com/kubernetes-sigs/descheduler)
|
||||
来重新实现 Pod 分布的均衡。
|
||||
|
||||
- 具有污点的节点上匹配的 Pods 也会被统计。
|
||||
参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
api_metadata:
|
||||
apiVersion: ""
|
||||
import: "k8s.io/apimachinery/pkg/api/resource"
|
||||
kind: "Quantity"
|
||||
content_type: "api_reference"
|
||||
description: "数量（Quantity）是数字的定点表示。"
|
||||
title: "Quantity"
|
||||
weight: 10
|
||||
auto_generated: true
|
||||
---
|
||||
|
||||
<!--
|
||||
api_metadata:
|
||||
apiVersion: ""
|
||||
import: "k8s.io/apimachinery/pkg/api/resource"
|
||||
kind: "Quantity"
|
||||
content_type: "api_reference"
|
||||
description: "Quantity is a fixed-point representation of a number."
|
||||
title: "Quantity"
|
||||
weight: 10
|
||||
auto_generated: true
|
||||
-->
|
||||
|
||||
<!--
|
||||
The file is auto-generated from the Go source code of the component using a generic
|
||||
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
|
||||
to generate the reference documentation, please read
|
||||
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
|
||||
To update the reference content, please follow the
|
||||
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
|
||||
guide. You can file document formatting bugs against the
|
||||
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
|
||||
-->
|
||||
|
||||
|
||||
|
||||
`import "k8s.io/apimachinery/pkg/api/resource"`
|
||||
|
||||
|
||||
<!--
|
||||
Quantity is a fixed-point representation of a number.
|
||||
It provides convenient marshaling/unmarshaling in JSON and YAML,
|
||||
in addition to String() and AsInt64() accessors.
|
||||
|
||||
The serialization format is:
|
||||
-->
|
||||
数量（Quantity）是数字的定点表示。
|
||||
除了 String() 和 AsInt64() 的访问接口之外，
|
||||
它以 JSON 和 YAML形式提供方便的打包和解包方法。
|
||||
|
||||
序列化格式如下：
|
||||
|
||||
<!--
|
||||
\<quantity> ::= \<signedNumber>\<suffix>
|
||||
(Note that \<suffix> may be empty, from the "" case in \<decimalSI>.)
|
||||
\<digit> ::= 0 | 1 | ... | 9
|
||||
\<digits> ::= \<digit> | \<digit>\<digits>
|
||||
\<number> ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits>
|
||||
\<sign> ::= "+" | "-"
|
||||
\<signedNumber> ::= \<number> | \<sign>\<number>
|
||||
\<suffix> ::= \<binarySI> | \<decimalExponent> | \<decimalSI>
|
||||
\<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
|
||||
(International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)
|
||||
\<decimalSI> ::= m | "" | k | M | G | T | P | E
|
||||
(Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
|
||||
\<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber>
|
||||
-->
|
||||
```
|
||||
<quantity> ::= <signedNumber><suffix>
|
||||
(注意 <suffix> 可能为空, 例如 <decimalSI> 的 "" 情形。) </br>
|
||||
<digit> ::= 0 | 1 | ... | 9 </br>
|
||||
<digits> ::= <digit> | <digit><digits> </br>
|
||||
<number> ::= <digits> | <digits>.<digits> | <digits>. | .<digits> </br>
|
||||
<sign> ::= "+" | "-" </br>
|
||||
<signedNumber> ::= <number> | <sign><number> </br>
|
||||
<suffix> ::= <binarySI> | <decimalExponent> | <decimalSI> </br>
|
||||
<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
|
||||
(国际单位制度；查阅：http://physics.nist.gov/cuu/Units/binary.html) </br>
|
||||
<decimalSI> ::= m | "" | k | M | G | T | P | E
|
||||
(注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。) </br>
|
||||
<decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber> </br>
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
No matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.
|
||||
|
||||
When a Quantity is parsed from a string, it will remember the type of suffix it had, and will use the same type again when it is serialized.
|
||||
-->
|
||||
无论使用三种指数形式中哪一种，没有数量可以表示大于 2<sup>63</sup>-1 的数，也不可能超过 3 个小数位。
|
||||
更大或更精确的数字将被截断或向上取整。（例如：0.1m 将向上取整为 1m。）
|
||||
如果将来我们需要更大或更小的数量，可能会扩展。
|
||||
|
||||
当从字符串解析数量时，它将记住它具有的后缀类型，并且在序列化时将再次使用相同类型。
|
||||
|
||||
<!--
|
||||
Before serializing, Quantity will be put in "canonical form".
|
||||
This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that:
|
||||
a. No precision is lost
|
||||
b. No fractional digits will be emitted
|
||||
c. The exponent (or suffix) is as large as possible.
|
||||
The sign will be omitted unless the number is negative.
|
||||
-->
|
||||
在序列化之前，数量将以“规范形式”放置。这意味着指数或者后缀将被向上或向下调整（尾数相应增加或减少），并确保：
|
||||
1. 没有精度丢失
|
||||
2. 不会输出小数数字
|
||||
3. 指数（或后缀）尽可能大。
|
||||
除非数量是负数，否则将省略正负号。
|
||||
|
||||
<!--
|
||||
Examples:
|
||||
1.5 will be serialized as "1500m"
|
||||
1.5Gi will be serialized as "1536Mi"
|
||||
-->
|
||||
例如：
|
||||
- 1.5 将会被序列化成 “1500m”
|
||||
- 1.5Gi 将会被序列化成 “1536Mi”
|
||||
|
||||
<!--
|
||||
Note that the quantity will NEVER be internally represented by a floating point number.
|
||||
That is the whole point of this exercise.
|
||||
|
||||
Non-canonical values will still parse as long as they are well formed,
|
||||
but will be re-emitted in their canonical form. (So always use canonical form, or don't diff.)
|
||||
|
||||
This format is intended to make it difficult to use these numbers without writing some sort of special handling code in the hopes that that will cause implementors to also use a fixed point implementation.
|
||||
-->
|
||||
请注意，数量永远**不会**在内部以浮点数表示。这是本设计的重中之重。
|
||||
|
||||
只要它们格式正确，非规范值仍将解析，但将以其规范形式重新输出。（所以应该总是使用规范形式，否则不要执行 diff 比较。）
|
||||
|
||||
这种格式旨在使得很难在不撰写某种特殊处理代码的情况下使用这些数字，进而希望实现者也使用定点实现。
|
||||
|
||||
<hr>
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
api_metadata:
|
||||
apiVersion: ""
|
||||
import: "k8s.io/api/core/v1"
|
||||
kind: "ResourceFieldSelector"
|
||||
content_type: "api_reference"
|
||||
description: "ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。"
|
||||
title: "ResourceFieldSelector"
|
||||
weight: 11
|
||||
auto_generated: true
|
||||
---
|
||||
|
||||
<!--
|
||||
api_metadata:
|
||||
apiVersion: ""
|
||||
import: "k8s.io/api/core/v1"
|
||||
kind: "ResourceFieldSelector"
|
||||
content_type: "api_reference"
|
||||
description: "ResourceFieldSelector represents container resources (cpu, memory) and their output format."
|
||||
title: "ResourceFieldSelector"
|
||||
weight: 11
|
||||
auto_generated: true
|
||||
-->
|
||||
|
||||
<!--
|
||||
The file is auto-generated from the Go source code of the component using a generic
|
||||
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
|
||||
to generate the reference documentation, please read
|
||||
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
|
||||
To update the reference content, please follow the
|
||||
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
|
||||
guide. You can file document formatting bugs against the
|
||||
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
|
||||
-->
|
||||
|
||||
|
||||
|
||||
`import "k8s.io/api/core/v1"`
|
||||
|
||||
|
||||
<!-- ResourceFieldSelector represents container resources (cpu, memory) and their output format -->
|
||||
ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。
|
||||
|
||||
<hr>
|
||||
|
||||
- **resource** (string), 必选
|
||||
|
||||
<!-- Required: resource to select -->
|
||||
必选：选择的资源
|
||||
|
||||
- **containerName** (string)
|
||||
|
||||
<!-- Container name: required for volumes, optional for env vars -->
|
||||
容器名称：对卷必选，对环境变量可选
|
||||
|
||||
- **divisor** (<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity</a>)
|
||||
|
||||
<!-- Specifies the output format of the exposed resources, defaults to "1" -->
|
||||
指定所曝光资源的输出格式，默认值为“1”
|
||||
|
||||
|
||||
|
||||
@@ -26,24 +26,19 @@ source <(kubectl completion zsh)
|
||||
```
|
||||
|
||||
<!--
|
||||
If you have an alias for kubectl, you can extend shell completion to work with that alias:
|
||||
If you have an alias for kubectl, kubectl autocompletion will automatically work with it.
|
||||
-->
|
||||
如果你为 kubectl 定义了别名，可以扩展脚本补全，以兼容该别名。
|
||||
|
||||
```zsh
|
||||
echo 'alias k=kubectl' >>~/.zshrc
|
||||
echo 'compdef __start_kubectl k' >>~/.zshrc
|
||||
```
|
||||
如果你为 kubectl 定义了别名，kubectl 自动补全将自动使用它。
|
||||
|
||||
<!--
|
||||
After reloading your shell, kubectl autocompletion should be working.
|
||||
|
||||
If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
|
||||
If you get an error like `2: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
|
||||
-->
|
||||
重新加载 shell 后，kubectl 自动补全功能将立即生效。
|
||||
|
||||
如果你收到 `complete:13: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头：
|
||||
|
||||
如果你收到 `2: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头：
|
||||
```zsh
|
||||
autoload -Uz compinit
|
||||
compinit
|
||||
|
||||
@@ -71,20 +71,20 @@ The following methods exist for installing kubectl on Windows:
|
||||
<!--
|
||||
1. Validate the binary (optional)
|
||||
|
||||
Download the kubectl checksum file:
|
||||
Download the `kubectl` checksum file:
|
||||
-->
|
||||
1. 验证该可执行文件（可选步骤）
|
||||
|
||||
下载 kubectl 校验和文件：
|
||||
下载 `kubectl` 校验和文件：
|
||||
|
||||
```powershell
|
||||
curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256"
|
||||
```
|
||||
|
||||
<!--
|
||||
Validate the kubectl binary against the checksum file:
|
||||
Validate the `kubectl` binary against the checksum file:
|
||||
-->
|
||||
基于校验和文件，验证 kubectl 的可执行文件：
|
||||
基于校验和文件，验证 `kubectl` 的可执行文件：
|
||||
|
||||
<!--
|
||||
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
|
||||
@@ -106,12 +106,12 @@ The following methods exist for installing kubectl on Windows:
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Append or prepend the kubectl binary folder to your `PATH` environment variable.
|
||||
1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable.
|
||||
|
||||
1. Test to ensure the version of `kubectl` is the same as downloaded:
|
||||
Or use this for detailed view of version:
|
||||
-->
|
||||
1. 将 kubectl 二进制文件夹附加或添加到你的 `PATH` 环境变量中。
|
||||
1. 将 `kubectl` 二进制文件夹追加或插入到你的 `PATH` 环境变量中。
|
||||
|
||||
1. 测试一下，确保此 `kubectl` 的版本和期望版本一致：
|
||||
|
||||
@@ -261,22 +261,22 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以
|
||||
<!--
|
||||
1. Validate the binary (optional)
|
||||
|
||||
Download the kubectl-convert checksum file:
|
||||
Download the `kubectl-convert` checksum file:
|
||||
-->
|
||||
1. 验证该可执行文件（可选步骤）
|
||||
|
||||
下载 kubectl-convert 校验和文件：
|
||||
下载 `kubectl-convert` 校验和文件：
|
||||
|
||||
```powershell
|
||||
curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
|
||||
```
|
||||
|
||||
<!--
|
||||
Validate the kubectl-convert binary against the checksum file:
|
||||
Validate the `kubectl-convert` binary against the checksum file:
|
||||
|
||||
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
|
||||
-->
|
||||
基于校验和，验证 kubectl-convert 的可执行文件：
|
||||
基于校验和，验证 `kubectl-convert` 的可执行文件：
|
||||
|
||||
- 用提示的命令对 `CertUtil` 的输出和下载的校验和文件进行手动比较。
|
||||
|
||||
@@ -295,11 +295,11 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Append or prepend the kubectl binary folder to your `PATH` environment variable.
|
||||
1. Append or prepend the `kubectl-convert` binary folder to your `PATH` environment variable.
|
||||
|
||||
1. Verify plugin is successfully installed
|
||||
-->
|
||||
1. 将 kubectl 二进制文件夹附加或添加到你的 `PATH` 环境变量中。
|
||||
1. 将 `kubectl-convert` 二进制文件夹附加或添加到你的 `PATH` 环境变量中。
|
||||
|
||||
1. 验证插件是否安装成功
|
||||
|
||||
|
||||
@@ -2,3 +2,9 @@
|
||||
title: 创建集群
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
Learn about Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}} and create a simple cluster using Minikube.
|
||||
-->
|
||||
了解 Kubernetes {{<glossary_tooltip text="集群" term_id="cluster" length="all" >}}并使用 Minikube
|
||||
创建一个简单的集群。
|
||||
|
||||
@@ -72,7 +72,7 @@ weight: 10
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p><b> Master 负责管理整个集群。</b> Master 协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。</p>
|
||||
<p><b> Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色</b> 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node 。</p>
|
||||
<p><b> Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色</b> 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node，因为如果一个 Node 出现故障其对应的 etcd 成员和控制平面实例都会丢失，并且冗余会受到影响。 你可以通过添加更多控制平面节点来降低这种风险 。</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
|
||||
@@ -19,7 +19,7 @@ Pod Security admission (PSA) is enabled by default in v1.23 and later, as it has
|
||||
[graduated to beta](/blog/2021/12/09/pod-security-admission-beta/).
|
||||
Pod Security
|
||||
is an admission controller that carries out checks against the Kubernetes
|
||||
[Pod Security Standards](docs/concepts/security/pod-security-standards/) when new pods are
|
||||
[Pod Security Standards](/docs/concepts/security/pod-security-standards/) when new pods are
|
||||
created. This tutorial shows you how to enforce the `baseline` Pod Security
|
||||
Standard at the cluster level which applies a standard configuration
|
||||
to all namespaces in a cluster.
|
||||
@@ -406,14 +406,14 @@ following:
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
Run `kind delete cluster -name psa-with-cluster-pss` and
|
||||
`kind delete cluster -name psa-wo-cluster-pss` to delete the clusters you
|
||||
Run `kind delete cluster --name psa-with-cluster-pss` and
|
||||
`kind delete cluster --name psa-wo-cluster-pss` to delete the clusters you
|
||||
created.
|
||||
-->
|
||||
## 清理 {#clean-up}
|
||||
|
||||
运行 `kind delete cluster -name psa-with-cluster-pss` 和
|
||||
`kind delete cluster -name psa-wo-cluster-pss` 来删除你创建的集群。
|
||||
运行 `kind delete cluster --name psa-with-cluster-pss` 和
|
||||
`kind delete cluster --name psa-wo-cluster-pss` 来删除你创建的集群。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user