From 0b995e7778f3cd497e74a4fbdaea6b4ec582439d Mon Sep 17 00:00:00 2001 From: simplytunde Date: Sun, 22 Sep 2019 17:49:37 -0500 Subject: [PATCH 1/4] initial commit From 32b0e539aedc0889c1cc99247f12cbfab403d50b Mon Sep 17 00:00:00 2001 From: M00nF1sh Date: Sun, 22 Sep 2019 20:23:22 -0700 Subject: [PATCH 2/4] promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484) From ac9473818c60529c203887d401024edb511a74ff Mon Sep 17 00:00:00 2001 From: chenghen Date: Mon, 23 Sep 2019 19:11:25 +0900 Subject: [PATCH 3/4] 1. Sync release-1.15 into master 2. Sync with en version --- .../zh/docs/concepts/architecture/_index.md | 4 + .../concepts/architecture/cloud-controller.md | 383 +++++++++++++++--- content/zh/docs/concepts/containers/_index.md | 4 + .../containers/container-lifecycle-hooks.md | 217 ++++++++++ .../docs/concepts/extend-kubernetes/_index.md | 4 + .../extend-kubernetes/api-extension/_index.md | 4 + .../api-extension/apiserver-aggregation.md | 68 ++++ .../compute-storage-net/_index.md | 4 + .../compute-storage-net/network-plugins.md | 269 ++++++++++++ content/zh/docs/concepts/overview/_index.md | 2 +- .../docs/concepts/overview/kubernetes-api.md | 244 +++++++++-- .../overview/working-with-objects/_index.md | 0 .../working-with-objects/annotations.md | 173 ++++++++ .../working-with-objects/common-labels.md | 262 ++++++++++++ .../working-with-objects/field-selectors.md | 108 +++++ .../kubernetes-objects.md | 91 ++++- .../working-with-objects/namespaces.md | 209 ++++++++++ content/zh/docs/concepts/policy/_index.md | 11 + 18 files changed, 1935 insertions(+), 122 deletions(-) create mode 100755 content/zh/docs/concepts/architecture/_index.md create mode 100644 content/zh/docs/concepts/containers/_index.md create mode 100644 content/zh/docs/concepts/containers/container-lifecycle-hooks.md create mode 100644 content/zh/docs/concepts/extend-kubernetes/_index.md create mode 100644 content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md create mode 100644 content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md create mode 100644 content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md create mode 100644 content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md mode change 100755 => 100644 content/zh/docs/concepts/overview/_index.md mode change 100755 => 100644 content/zh/docs/concepts/overview/working-with-objects/_index.md create mode 100644 content/zh/docs/concepts/overview/working-with-objects/annotations.md create mode 100644 content/zh/docs/concepts/overview/working-with-objects/common-labels.md create mode 100644 content/zh/docs/concepts/overview/working-with-objects/field-selectors.md create mode 100644 content/zh/docs/concepts/overview/working-with-objects/namespaces.md create mode 100644 content/zh/docs/concepts/policy/_index.md diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000000..5c12c896ab034 --- /dev/null +++ b/content/zh/docs/concepts/architecture/_index.md @@ -0,0 +1,4 @@ +--- +title: "Kubernetes 架构" +weight: 30 +--- \ No newline at end of file diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index efa9ee49db05c..fca183107db1d 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -1,175 +1,395 @@ -title: 云控制器管理器的基本概念 +--- +title: 云控制器管理器的基础概念 +content_template: templates/concept +weight: 30 +--- -## 云控制器管理器 + -云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器，API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动，这种情况下，CCM运行在Kubernetes系统之上。 -云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。 +{{% capture overview %}} + + + +云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。 + + + +云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。 + + 本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。 -下面这张图描述了没有云控制器管理器的Kubernetes集群架构： + + +这是没有云控制器管理器的 Kubernetes 集群的架构： + + + +![没有云控制器管理器的 Kubernetes 架构](/images/docs/pre-ccm-arch.png) + +{{% /capture %}} + + +{{% capture body %}} + + -![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png) ## 设计 -在上图中，Kubernetes和云服务供应商通过几个不同的组件进行了集成，分别是： + + +在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是： + + * Kubelet * Kubernetes 控制管理器 -* Kubernetes API服务器 +* Kubernetes API 服务器 + + -而CCM整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示： +CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示： -![有云控制器管理器的 K8s 集群架构](/images/docs/post-ccm-arch.png) + -## CCM的组件 +![含有云控制器管理器的 Kubernetes 架构](/images/docs/post-ccm-arch.png) -CCM突破了Kubernetes控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎： + +## CCM 的组成部分 + + + +CCM 打破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个单独的进程运行。具体来说，它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器： + + * 节点控制器 * 卷控制器 * 路由控制器 * 服务控制器 + -在1.8版本中，当前运行中的CCM从上面的列表中运行以下控制器： +在 1.9 版本中，CCM 运行前述列表中的以下控制器： + + * 节点控制器 * 路由控制器 * 服务控制器 -另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域（Zone）和区（Region）标签进行设置。 +{{< note >}} + + +注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。 -**注意**：卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到CCM之中。 +{{< /note >}} -原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。 + -考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至CSI准备就绪。 +使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。 -云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。 + -## CCM功能 +考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。 -CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。 + + +## CCM 的功能 + + + +CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。 + + ### 1. Kubernetes 控制器管理器 -CCM的大部分功能都来自KCM。 如上一节所述，CCM运行以下控制引擎： + + +CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。 + + * 节点控制器 * 路由控制器 * 服务控制器 -* PersistentVolumeLabels控制器 + + #### 节点控制器 -节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能： + -1.使用云特定域（Zone）/区（Region）标签初始化节点。 +节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点，节点控制器执行以下功能： -1.使用特定于云的实例详细信息初始化节点，例如类型和大小。 + -1.获取节点的网络地址和主机名。 +1. 使用特定于云的域（zone）/区（region）标签初始化节点； +2. 使用特定于云的实例详细信息初始化节点，例如，类型和大小； +3. 获取节点的网络地址和主机名； +4. 如果节点无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，请删除 Kubernetes 节点对象。 -1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除Kubernetes节点对象。 + #### 路由控制器 -路由控制器负责为云配置正确的路由，以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。 + -#### 服务控制器 +Route 控制器负责适当地配置云中的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。 -服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如ELB或Google LB）以反映Kubernetes中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。 + -#### PersistentVolumeLabels 控制器 +#### 服务控制器 -PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。 + -这些标签对于pod的调度工作是非常重要的，因为这些卷只能在它们所在的域（Zone）/区（Region）内工作，因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。 +服务控制器负责监听服务的创建、更新和删除事件。根据 Kubernetes 中各个服务的当前状态，它配置云负载均衡器（如 ELB, Google LB 或者 Oracle Cloud Infrastructure LB）以反映 Kubernetes 中的服务状态。此外，它还确保云负载均衡器的服务后端是最新的。 -PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说，在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器（它是一个许可控制器）中的PV标签逻辑移动到CCM。 它不在KCM上运行。 + ### 2. Kubelet -Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前，是由kubelet采用包含云特定信息的方式对节点进行初始化，如IP地址、区（Region）/域（Zone）标签和实例类型信息；引入CCM之后，这部分的初始化操作就从kubelet转移到了CCM中。 + + +节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 -在引入CCM后的新的模型中，kubelet采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到CCM使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。 + -### 3. Kubernetes API服务器 +在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 -PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM，如前面部分所述。 + ## 插件机制 -云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。 + -上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。 +云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说，它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。 -有关开发插件的更多信息，请参阅 -[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。 + + +上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。 + + + +有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。 + + ## 授权 -本节分解了CCM对各种API对象的访问，以执行其操作。 + + +本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。 + + ### 节点控制器 -节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。 + + +Node 控制器仅适用于 Node 对象，它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。 + + + +v1/Node: + +- Get +- List +- Create +- Update +- Patch +- Watch +- Delete + + ### 路由控制器 -路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。 + + +路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。 + +v1/Node: -v1/Node: - Get + + ### 服务控制器 -服务控制器侦听服务对象创建、更新和删除事件，然后对这些服务的端点进行恰当的配置。 + + +服务控制器侦听 Service 对象创建、更新和删除事件，然后适当地为这些服务配置端点。 -要访问服务，它需要罗列和监控权限。要更新服务，它需要修补和更新权限。 + -要为服务设置端点，需要访问创建、列表、获取、监视和更新。 +要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。 + + + +要为服务设置端点，需要访问 create、list、get、watch 和 update。 v1/Service: + - List - Get - Watch - Patch - Update -### PersistentVolumeLabels 控制器 - -PersistentVolumeLabels控制器监听PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。 - -v1/PersistentVolume: -- Get -- List -- Watch -- Update + ### 其它 -CCM核心的实现需要创建事件的权限，为了确保安全操作，需要创建ServiceAccounts的权限。 + + +CCM 核心的实现需要访问权限以创建事件，并且为了确保安全操作，它需要访问权限以创建服务账户。 v1/Event: + - Create - Patch - Update v1/ServiceAccount: + - Create -针对CCM的RBAC ClusterRole如下所示： + + +针对 CCM 的 RBAC ClusterRole 看起来像这样： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -233,17 +453,50 @@ rules: - update ``` + + ## 供应商实施 -以下云服务供应商为自己的云部署了CCM。 + -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +以下云服务提供商已实现了 CCM： + + + * [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Linode](https://github.com/linode/linode-cloud-controller-manager) +* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) + + ## 群集管理 -[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。 + + +[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。 + +{{% /capture %}} + diff --git a/content/zh/docs/concepts/containers/_index.md b/content/zh/docs/concepts/containers/_index.md new file mode 100644 index 0000000000000..bd322c2129ca0 --- /dev/null +++ b/content/zh/docs/concepts/containers/_index.md @@ -0,0 +1,4 @@ +--- +title: "容器" +weight: 50 +--- \ No newline at end of file diff --git a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000000..9c85be9626a5d --- /dev/null +++ b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,217 @@ +--- +title: 容器生命周期钩子 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + + +这个页面描述了 kubelet 管理的容器如何使用容器生命周期钩子框架来运行在其管理生命周期中由事件触发的代码。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 概述 + + +类似于许多具有生命周期钩子组件的编程语言框架，例如Angular，Kubernetes为容器提供了生命周期钩子。 +钩子使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期钩子时运行在处理程序中实现的代码。 + + + +## 容器钩子 + + +有两个钩子暴露在容器中: + +`PostStart` + + +这个钩子在创建容器之后立即执行。 +但是，不能保证钩子会在容器入口点之前执行。 +没有参数传递给处理程序。 + +`PreStop` + + + +在容器终止之前是否立即调用此钩子，取决于 API 的请求或者管理事件，类似活动探针故障、资源抢占、资源竞争等等。 如果容器已经完全处于终止或者完成状态，则对 preStop 钩子的调用将失败。 +它是阻塞的，同时也是同步的，因此它必须在删除容器的调用之前完成。 +没有参数传递给处理程序。 + + +有关终止行为的更详细描述，请参见[终止 Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)。 + + + +### 钩子处理程序的实现 + + +容器可以通过实现和注册该钩子的处理程序来访问该钩子。 +针对容器，有两种类型的钩子处理程序可供实现： + + + +* Exec - 执行一个特定的命令，例如 `pre-stop.sh`，在容器的 cgroups 和名称空间中。 +命令所消耗的资源根据容器进行计算。 +* HTTP - 对容器上的特定端点执行 HTTP 请求。 + + + +### 钩子处理程序执行 + + +当调用容器生命周期管理钩子时，Kubernetes 管理系统在为该钩子注册的容器中执行处理程序。 + + +钩子处理程序调用在包含容器的 Pod 上下文中是同步的。 +这意味着对于 `PostStart` 钩子，容器入口点和钩子异步触发。 +但是，如果钩子运行或挂起的时间太长，则容器无法达到 `running` 状态。 + + +行为与 `PreStop` 钩子的行为类似。 +如果钩子在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。 +如果 `PostStart` 或 `PreStop` 钩子失败，它会杀死容器。 + + +用户应该使他们的钩子处理程序尽可能的轻量级。 +但也需要考虑长时间运行的命令也很有用的情况，比如在停止容器之前保存状态。 + + + +### 钩子寄送保证 + + +钩子的寄送应该是*至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，钩子可以被调用多次。 +如何正确处理，是钩子实现所要考虑的问题。 + + +通常情况下，只会进行单次寄送。 +例如，如果 HTTP 钩子接收器宕机，无法接收流量，则不会尝试重新发送。 +然而，偶尔也会发生重复寄送的可能。 +例如，如果 kubelet 在发送钩子的过程中重新启动，钩子可能会在 kubelet 恢复后重新发送。 + + + +### 调试钩子处理程序 + + +钩子处理程序的日志不会在 Pod 事件中公开。 +如果处理程序由于某种原因失败，它将播放一个事件。 +对于 `PostStart`，这是 `FailedPostStartHook` 事件，对于 `PreStop`，这是 `FailedPreStopHook` 事件。 +您可以通过运行 `kubectl describe pod ` 命令来查看这些事件。 +下面是运行这个命令的一些事件输出示例: + +``` +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 了解更多关于[容器环境](/docs/concepts/containers/container-environment-variables/)。 +* 获取实践经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000000..44a8ee8361831 --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,4 @@ +--- +title: 扩展 Kubernetes +weight: 40 +--- \ No newline at end of file diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md new file mode 100644 index 0000000000000..206de59684dbd --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -0,0 +1,4 @@ +--- +title: 扩展 Kubernetes API +weight: 20 +--- \ No newline at end of file diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md new file mode 100644 index 0000000000000..9817d114c839a --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -0,0 +1,68 @@ +--- +title: 通过聚合层扩展 Kubernetes API +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + + + +聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。 + +{{% /capture %}} + +{{% capture body %}} + + +## 概述 + +聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。 + + + +聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来申领 Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）代理到已注册的 APIService。 + + + +正常情况下，APIService 会实现为运行于集群中某 Pod 内的 extension-apiserver。如果需要对增加的资源进行动态管理，extension-apiserver 经常需要和一个或多个控制器一起使用。因此，apiserver-builder 同时提供用来管理新资源的 API 框架和控制器框架。另外一个例子，当安装了 service-catalog 时，它会为自己提供的服务提供 extension-apiserver 和控制器。 + + + +扩展 api 服务与 kube-apiserver 之间的连接应该具有低延迟的特性。 +特别是，发现请求和 kube-apiserver 的请求响应时间需要在五秒钟或更短的时间内。 +如果您的部署无法实现此目的，则应考虑如何进行改进。 +现在，利用 kube-apiserver 上的`EnableAggregatedDiscoveryTimeout = false`功能可以禁用超时限制。但是，它将在将来的版本中删除。 +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 阅读[配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 文档，了解如何在自己的环境中启用聚合器（aggregator）。 +* 然后[安装扩展的 api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 来开始使用聚合层。 +* 也可以学习怎样 [使用客户资源定义扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。 + +{{% /capture %}} + + diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md new file mode 100644 index 0000000000000..f442ce7fafdc0 --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md @@ -0,0 +1,4 @@ +--- +title: 计算、存储和网络扩展 +weight: 30 +--- \ No newline at end of file diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md new file mode 100644 index 0000000000000..bbf72b68c26b0 --- /dev/null +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -0,0 +1,269 @@ +--- +title: 网络插件 +content_template: templates/concept +weight: 10 +--- + + +{{% capture overview %}} + +{{< feature-state state="alpha" >}} + +{{< warning >}}Alpha 特性迅速变化。{{< /warning >}} + + +Kubernetes中的网络插件有几种类型： + +* CNI 插件： 遵守 appc/CNI 规约，为互操作性设计。 +* Kubenet 插件：使用 `bridge` 和 `host-local` CNI 插件实现了基本的 `cbr0`。 + +{{% /capture %}} + +{{% capture body %}} + + +## 安装 + +kubelet 有一个单独的默认网络插件，以及一个对整个集群通用的默认网络。 +它在启动时探测插件，记住找到的内容，并在 pod 生命周期的适当时间执行所选插件（这仅适用于 Docker，因为 rkt 管理自己的 CNI 插件）。 +在使用插件时，需要记住两个 Kubelet 命令行参数： + +* `cni-bin-dir`： Kubelet 在启动时探测这个目录中的插件 +* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。它必须与从插件目录探测到的插件报告的名称匹配。对于 CNI 插件，其值为 "cni"。 + + +## 网络插件要求 + +除了提供[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)来配置和清理 pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。 +iptables 代理显然依赖于 iptables，插件可能需要确保 iptables 能够监控容器的网络通信。 +例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables` 系统参数设置为`1`，以确保 iptables 代理正常工作。 +如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制），它应该确保为代理对容器通信执行正确的路由。 + +默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件，该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置（如带网桥的 Docker ）与 iptables 代理正常工作。 + + +### CNI + +通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项来选择 CNI 插件。 +Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用该文件中的 CNI 配置来设置每个 pod 的网络。 +CNI 配置文件必须与 [CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)匹配，并且配置引用的任何所需的 CNI 插件都必须存在于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）。 + +如果这个目录中有多个 CNI 配置文件，则使用按文件名的字典顺序排列的第一个配置文件。 + +除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 插件，最低版本是0.2.0。 + + +#### 支持 hostPort + +CNI 网络插件支持 `hostPort`。 您可以使用官方 [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) +插件，它由 CNI 插件团队提供，或者使用您自己的带有 portMapping 功能的插件。 + +如果你想要启动 `hostPort` 支持，则必须在 `cni-conf-dir` 指定 `portMappings capability`。 +例如： + +```json +{ + "name": "k8s-pod-network", + "cniVersion": "0.3.0", + "plugins": [ + { + "type": "calico", + "log_level": "info", + "datastore_type": "kubernetes", + "nodename": "127.0.0.1", + "ipam": { + "type": "host-local", + "subnet": "usePodCidr" + }, + "policy": { + "type": "k8s" + }, + "kubernetes": { + "kubeconfig": "/etc/cni/net.d/calico-kubeconfig" + } + }, + { + "type": "portmap", + "capabilities": {"portMappings": true} + } + ] +} +``` + + +#### 支持流量整形 + +CNI 网络插件还支持 pod 入口和出口流量整形。 +您可以使用 CNI 插件团队提供的 [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 插件， +也可以使用您自己的具有带宽控制功能的插件。 + +如果您想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件 +（默认是 `/etc/cni/net.d`）。 + +```json +{ + "name": "k8s-pod-network", + "cniVersion": "0.3.0", + "plugins": [ + { + "type": "calico", + "log_level": "info", + "datastore_type": "kubernetes", + "nodename": "127.0.0.1", + "ipam": { + "type": "host-local", + "subnet": "usePodCidr" + }, + "policy": { + "type": "k8s" + }, + "kubernetes": { + "kubeconfig": "/etc/cni/net.d/calico-kubeconfig" + } + }, + { + "type": "bandwidth", + "capabilities": {"bandwidth": true} + } + ] +} +``` + + +现在，您可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth` 注解添加到 pod 中。 +例如： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + annotations: + kubernetes.io/ingress-bandwidth: 1M + kubernetes.io/egress-bandwidth: 1M +... +``` + + +### kubenet + +Kubenet 是一个非常基本的、简单的网络插件，仅适用于 Linux。 +它本身并不实现更高级的功能，如跨节点网络或网络策略。 +它通常与云驱动一起使用，云驱动为节点间或单节点环境中的通信设置路由规则。 + +Kubenet 创建名为 `cbr0` 的网桥，并为每个 pod 创建了一个 veth 对，每个 pod 的主机端都连接到 `cbr0`。 +这个 veth 对的 pod 端会被分配一个 IP 地址，该 IP 地址隶属于节点所被分配的 IP 地址范围内。节点的 IP 地址范围则通过配置或控制器管理器来设置。 +`cbr0` 被分配一个 MTU，该 MTU 匹配主机上已启用的正常接口的最小 MTU。 + +使用此插件还需要一些其他条件： + +* 需要标准的 CNI `bridge`、`lo` 以及 `host-local` 插件，最低版本是0.2.0。Kubenet 首先在 `/opt/cni/bin` 中搜索它们。 指定 `cni-bin-dir` 以提供其它的搜索路径。首次找到的匹配将生效。 +* Kubelet 必须和 `--network-plugin=kubenet` 参数一起运行，才能启用该插件。 +* Kubelet 还应该和 `--non-masquerade-cidr=` 参数一起运行，以确保超出此范围的 IP 流量将使用 IP 伪装。 +* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=` 来设置。 + + +### 自定义 MTU（使用 kubenet） + +要获得最佳的网络性能，必须确保 MTU 的取值配置正确。 +网络插件通常会尝试推断出一个合理的 MTU，但有时候这个逻辑不会产生一个最优的 MTU。 +例如，如果 Docker 网桥或其他接口有一个小的 MTU, kubenet 当前将选择该 MTU。 +或者如果您正在使用 IPSEC 封装，则必须减少 MTU，并且这种计算超出了大多数网络插件的能力范围。 + +如果需要，您可以使用 `network-plugin-mtu` kubelet 选项显式的指定 MTU。 +例如：在 AWS 上 `eth0` MTU 通常是 9001，因此您可以指定 `--network-plugin-mtu=9001`。 +如果您正在使用 IPSEC ，您可以减少它以允许封装开销，例如 `--network-plugin-mtu=8873`。 + +此选项会传递给网络插件； 当前 **仅 kubenet 支持 `network-plugin-mtu`**。 + + +## 使用总结 + +* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于 `--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。 +* `--network-plugin=kubenet` 用来表明我们要使用 `kubenet` 网络插件，CNI `bridge` 和 `host-local` 插件位于 `/opt/cni/bin` 或 `cni-bin-dir` 中。 +* `--network-plugin-mtu=9001` 指定了我们使用的 MTU，当前仅被 `kubenet` 网络插件使用。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/_index.md b/content/zh/docs/concepts/overview/_index.md old mode 100755 new mode 100644 index 9ab3e94ae4062..dd4f784acd93b --- a/content/zh/docs/concepts/overview/_index.md +++ b/content/zh/docs/concepts/overview/_index.md @@ -1,4 +1,4 @@ --- -title: "概述" +title: 概述 weight: 20 --- \ No newline at end of file diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md index 9a920f043fbac..ffd10f75b5844 100644 --- a/content/zh/docs/concepts/overview/kubernetes-api.md +++ b/content/zh/docs/concepts/overview/kubernetes-api.md @@ -1,103 +1,265 @@ --- title: Kubernetes API +content_template: templates/concept weight: 30 +card: + name: concepts + weight: 30 --- -# Kubernetes API 概述 +{{% capture overview %}} + [API协议文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)描述了主系统和API概念。 -[API参考文档](https://kubernetes.io/docs/reference)描述了API整体规范。 +[API参考文档](/docs/reference)描述了API整体规范。 -[访问文档](https://kubernetes.io/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。 +[访问文档](/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。 -Kubernetes API是系统描述性配置的基础。 [Kubectl](https://kubernetes.io/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。 +Kubernetes API是系统描述性配置的基础。 [Kubectl](/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。 Kubernetes 通过API资源存储自己序列化状态(现在存储在[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/))。 Kubernetes 被分成多个组件，各部分通过API相互交互。 +{{% /capture %}} + + +{{% capture body %}} + + ## API 变更 根据经验，任何成功的系统都需要随着新的用例出现或现有用例发生变化的情况下，进行相应的进化与调整。因此，我们希望Kubernetes API也可以保持持续的进化和调整。同时，在较长一段时间内，我们也希望与现有客户端版本保持良好的向下兼容性。一般情况下，增加新的API资源和资源字段不会导致向下兼容性问题发生；但如果是需要删除一个已有的资源或者字段，那么必须通过[API废弃流程](/docs/reference/deprecation-policy/)来进行。 -参考[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md)，了解兼容性变更的要素以及如何变更API的流程。 +参考[API变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)，了解兼容性变更的要素以及如何变更API的流程。 -## API Swagger 定义 + -Kubernetes从1.4版本开始，也支持通过 [**`/swagger.json`**](https://git.k8s.io/kubernetes/api/openapi-spec/swagger.json) 来访问 OpenAPI 形式给出的API文档。在我们将 Swagger v1.2 切换到 OpenAPI (aka Swagger v2.0) 期间，一部分工具(如 kubectl 与 swagger-ui )会继续使用 1.2 版本规范。Kubernetes 1.5 版本中的 OpenAPI 规范是 Beta 版本。 +## OpenAPI 和 API Swagger 定义 -Kubernetes实现了另一种基于Protobuf的序列化格式，该格式主要用于集群内通信，并在[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)中进行了说明，每个模式的IDL文件位于定义API对象的Go软件包中。 +完整的 API 细节被记录在 [OpenAPI](https://www.openapis.org/). -## API 版本 +随着 Kubernetes 1.10 版本的正式启用，Kubernetes API 服务通过 `/openapi/v2` 接口提供 OpenAPI 规范。 +通过设置 HTTP 标头的规定了请求的结构。 -为了使删除字段或者重构资源表示更加容易，Kubernetes 支持多个API版本。每一个版本都在不同API路径下，例如 **`/api/v1`** 或者 **`/apis/extensions/v1beta1`**。 +Header | Possible Values +------ | --------------- +Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (the default content-type is `application/json` for `*/*` or not passing this header) +Accept-Encoding | `gzip` (not passing this header is acceptable) -我们选择在API级别进行版本化，而不是在资源或字段级别进行版本化，以确保API提供清晰，一致的系统资源和行为视图，并控制对已废止的API和/或实验性API的访问。 JSON和Protobuf序列化模式遵循架构更改的相同准则 - 下面的所有描述都同时适用于这两种格式。 + -* Alpha 测试版本： +在1.14版本之前，区分结构的接口通过(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) +提供不同格式的 OpenAPI 规范。但是这些接口已经被废弃，并且已经在 Kubernetes 1.14 中被删除。 - * 版本名称包含了 **`alpha`** (例如：**`v1alpha1`**)。 +**获取 OpenAPI 规范的例子**: - * 可能是有缺陷的。启用该功能可能会带来隐含的问题，默认情况是关闭的。 +1.10 之前 | 从 1.10 开始 +----------- | ----------------------------- +GET /swagger.json | GET /openapi/v2 **Accept**: application/json +GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf +GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip - * 支持的功能可能在没有通知的情况下随时删除。 + - * 由于bugs风险的增加和缺乏长期的支持，推荐在短暂的集群测试中使用。 +Kubernetes实现了另一种基于Protobuf的序列化格式，该格式主要用于集群内通信，并在[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)中进行了说明，每个模式的IDL文件位于定义API对象的Go软件包中。 +在 1.14 版本之前， Kubernetes apiserver 也提供 API 服务用于返回 +[Swagger v1.2](http://swagger.io/) Kubernetes API 规范通过 `/swaggerapi` 接口. +但是这个接口已经被废弃，并且在 Kubernetes 1.14 中已经被移除。 -* Beta 测试版本： + - * 代码已经测试过。启用该功能被认为是安全的，功能默认已启用。 +## API 版本 - * 所有已支持的功能不会被删除，细节可能会发生变化。 +为了使删除字段或者重构资源表示更加容易，Kubernetes 支持 +多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者 +`/apis/extensions/v1beta1`。 - * 对象的模式和/或语义可能会在后续的beta测试版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供迁移到下一个版本的说明。 这可能需要删除、编辑和重新创建API对象。执行编辑操作时需要谨慎行事，这可能需要停用依赖该功能的应用程序。 + - * **请尝试我们的 beta 版本功能并且给出反馈！一旦他们退出 beta 测试版，我们可能不会做出更多的改变。** +我们选择在API级别进行版本化，而不是在资源或字段级别进行版本化，以确保API提供清晰，一致的系统资源和行为视图，并控制对已废止的API和/或实验性API的访问。 JSON和Protobuf序列化模式遵循架构更改的相同准则 - 下面的所有描述都同时适用于这两种格式。 -* 稳定版本： +请注意，API版本控制和软件版本控制只有间接相关性。 + [API和发行版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) 描述了API版本与软件版本之间的关系。 + + + +不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下： + + +- Alpha 测试版本： + - 版本名称包含了 **`alpha`** (例如：**`v1alpha1`**)。 + - 可能是有缺陷的。启用该功能可能会带来隐含的问题，默认情况是关闭的。 + - 支持的功能可能在没有通知的情况下随时删除。 + - API的更改可能会带来兼容性问题，但是在后续的软件发布中不会有任何通知。 + - 由于bugs风险的增加和缺乏长期的支持，推荐在短暂的集群测试中使用。 +- Beta 测试版本： + - 版本名称包含了 **`beta`** (例如: **`v2beta3`**)。 + - 代码已经测试过。启用该功能被认为是安全的，功能默认已启用。 + - 所有已支持的功能不会被删除，细节可能会发生变化。 + - 对象的模式和/或语义可能会在后续的beta测试版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供迁移到下一个版本的说明。 这可能需要删除、编辑和重新创建API对象。执行编辑操作时需要谨慎行事，这可能需要停用依赖该功能的应用程序。 + - 建议仅用于非业务关键型用途，因为后续版本中可能存在不兼容的更改。 如果您有多个可以独立升级的集群，则可以放宽此限制。 + - **请尝试我们的 beta 版本功能并且给出反馈！一旦他们退出 beta 测试版，我们可能不会做出更多的改变。** +- 稳定版本： + - 版本名称是 **`vX`**，其中 **`X`** 是整数。 + - 功能的稳定版本将出现在许多后续版本的发行软件中。 + + - * 版本名称是 **`vX`**，其中 **`X`** 是整数。 +## API 组 - * 功能的稳定版本将出现在许多后续版本的发行软件中。 +为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 +API组在REST路径和序列化对象的 **`apiVersion`** 字段中指定。 -## API 组 + 目前有几个API组正在使用中： -1. 核心组（通常被称为遗留组）位于REST路径 **`/api/v1`** 并使用 **`apiVersion：v1`**。 +1. 核心组（通常被称为遗留组）位于REST路径 `/api/v1` 并使用 `apiVersion：v1`。 + +1. 指定的组位于REST路径 `/apis/$GROUP_NAME/$VERSION`，并使用 `apiVersion：$GROUP_NAME/$VERSION` + （例如 `apiVersion：batch/v1`）。 在[Kubernetes API参考](/docs/reference/)中可以看到支持的API组的完整列表。 -1. 指定的组位于REST路径 **`/apis/$GROUP_NAME/$VERSION`**，并使用 **`apiVersion：$GROUP_NAME/$VERSION`**（例如 **`apiVersion：batch/v1`**）。 在[Kubernetes API参考](https://kubernetes.io/docs/reference/)中可以看到支持的API组的完整列表。 + -1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)适用于具有非常基本的CRUD需求的用户。 +社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](/docs/concepts/api-extension/custom-resources/)： -1. 即将推出：需要全套Kubernetes API语义的用户可以实现自己的apiserver，并使用[聚合器](https://git.k8s.io/community/contributors/design-proposals/api-machinery/aggregated-api-servers.md)为客户提供无缝的服务。 +1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) + 适用于具有非常基本的CRUD需求的用户。 + +1. 需要全套Kubernetes API语义的用户可以实现自己的apiserver， + 并使用[聚合器](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) + 为客户提供无缝的服务。 + + ## 启用 API 组 -某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 **`--runtime-config`** 来启用或禁用它们。 **`--runtime-config`** 接受逗号分隔的值。 例如：要禁用batch/v1，请设置**`--runtime-config=batch/v1=false`**，以启用batch/v2alpha1，请设置**`--runtime-config=batch/v2alpha1`**。 该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。 +某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 `--runtime-config` 来启用或禁用它们。 +`--runtime-config` 接受逗号分隔的值。 +例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。 +该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。 + +重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。 + + ## 启用组中资源 -DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs和ReplicaSets是默认启用的。 其他扩展资源可以通过在apiserver上设置 **`--runtime-config`** 来启用。**`--runtime-config`** 接受逗号分隔的值。 +DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。 +其他扩展资源可以通过在apiserver上设置 `--runtime-config` 来启用。 +`--runtime-config` 接受逗号分隔的值。 例如：要禁用 Deployment 和 Ingress， +请设置 `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false` -例如：要禁用 Deployment 和 Ingress，请设置 **`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`** +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/_index.md b/content/zh/docs/concepts/overview/working-with-objects/_index.md old mode 100755 new mode 100644 diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000000..f57dbd5ec0f31 --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,173 @@ +--- +title: 注解 +content_template: templates/concept +weight: 50 +--- + + + +{{% capture overview %}} + +你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。 + +{{% /capture %}} + +{{% capture body %}} +## 为对象附加元数据 + + +您可以使用标签或注解将元数据附加到 Kubernetes 对象。 +标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。 +注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。 + + + + +注解和标签一样，是键/值对: + + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +以下是一些例子，用来说明哪些信息可以使用注解来记录: + + +* 由声明性配置所管理的字段。 + 将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。 + + + +* 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。 + + + +* 指向日志记录、监控、分析或审计仓库的指针。 + + + +* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。 + + + +* 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。 + + + +* 推出的轻量级工具的元数据信息：例如，配置或检查点。 + + + +* 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。 + + + + +从用户到最终运行的指令，以修改行为或使用非标准功能。 + + +您可以将这类信息存储在外部数据库或目录中而不使用注解，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。 + + + + +## 语法和字符集 +_注解_ 存储的形式是键/值对。有效的注解键分为两部分：可选的前缀和名称，以斜杠（`/`）分隔。 名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 前缀是可选的。 如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，总计不超过253个字符，后跟斜杠（`/`）。 +如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` 或其他第三方组件），必须为终端用户添加注释前缀。 + + + +`kubernetes.io /` 和 `k8s.io /` 前缀是为Kubernetes核心组件保留的。 + +例如，这是Pod的配置文件，其注释为 `imageregistry：https：// hub.docker.com /` ： +```yaml + +apiVersion: v1 +kind: Pod +metadata: + name: annotations-demo + annotations: + imageregistry: "https://hub.docker.com/" +spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +``` + +{{% /capture %}} + +{{% capture whatsnext %}} +进一步了解[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000000..2a33f64fcb8ec --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,262 @@ +--- +title: 推荐使用的标签 +content_template: templates/concept +--- + + +{{% capture overview %}} + +除了 kubectl 和 dashboard 之外，您可以其他工具来可视化和管理 Kubernetes 对象。 +一组通用的标签可以让多个工具之间互操作，用所有工具都能理解的通用方式描述对象。 + + +除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。 + +{{% /capture %}} + +{{% capture body %}} + +元数据围绕 _应用（application）_ 的概念进行组织。Kubernetes 不是 +平台即服务（PaaS），没有或强制执行正式的应用程序概念。 +相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。 + +{{< note >}} + +这些是推荐的标签。它们使管理应用程序变得更容易但不是任何核心工具所必需的。 +{{< /note >}} + + +共享标签和注解都使用同一个前缀：`app.kubernetes.io`。没有前缀的标签是用户私有的。共享前缀可以确保共享标签不会干扰用户自定义的标签。 + + +## 标签 +为了充分利用这些标签，应该在每个资源对象上都使用它们。 + + +| 键 | 描述 | 示例 | 类型 | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | 应用程序的名称 | `mysql` | 字符串 | +| `app.kubernetes.io/instance` | 用于唯一确定应用实例的名称 | `wordpress-abcxzy` | 字符串 | +| `app.kubernetes.io/version` | 应用程序的当前版本（例如，语义版本，修订版哈希等） | `5.7.21` | 字符串 | +| `app.kubernetes.io/component` | 架构中的组件 | `database` | 字符串 | +| `app.kubernetes.io/part-of` | 此级别的更高级别应用程序的名称 | `wordpress` | 字符串 | +| `app.kubernetes.io/managed-by` | 用于管理应用程序的工具 | `helm` | 字符串 | + +为说明这些标签的实际使用情况，请看下面的 StatefulSet 对象： + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: helm +``` + + +## 应用和应用实例 + +应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 wordpress。 + +应用的名称和实例的名称是分别记录的。例如，某 WordPress 实例的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称表现为 `app.kubernetes.io/instance` 的属性值 `wordpress-abcxzy`。这使应用程序和应用程序的实例成为可能是可识别的。应用程序的每个实例都必须具有唯一的名称。 + + +## 示例 + + +为了说明使用这些标签的不同方式，以下示例具有不同的复杂性。 + + +### 一个简单的无状态服务 + + +考虑使用 `Deployment` 和 `Service` 对象部署的简单无状态服务的情况。以下两个代码段表示如何以最简单的形式使用标签。 + + +下面的 `Deployment` 用于监督运行应用本身的 pods。 +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + + +下面的 `Service` 用于暴露应用。 +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + + +### 带有一个数据库的 Web 应用程序 + + +考虑一个稍微复杂的应用：一个使用 Helm 安装的 Web 应用（WordPress），其中 +使用了数据库（MySQL）。以下代码片段说明用于部署此应用程序的对象的开始。 + +以下 `Deployment` 的开头用于 WordPress： + + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + + +这个 `Service` 用于暴露 WordPress： + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + + + +MySQL 作为一个 `StatefulSet` 暴露，包含它和它所属的较大应用程序的元数据： +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/version: "5.7.21" +... +``` + + + +`Service` 用于将 MySQL 作为 WordPress 的一部分暴露： +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/version: "5.7.21" +... +``` + + +使用 MySQL `StatefulSet` 和 `Service`，您会注意到有关 MySQL 和 Wordpress 的信息，包括更广泛的应用程序。 + +{{% /capture %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000000..07c7a76301b2f --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,108 @@ +--- +title: 字段选择器 +weight: 60 +--- + + + +字段选择器允许您根据一个或多个资源字段的值[筛选 Kubernetes 资源](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +下面是一些使用字段选择器查询的例子： + + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +下面这个 `kubectl` 命令将筛选出[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)字段值为 `Running` 的所有 Pod： + + +```shell +kubectl get pods --field-selector status.phase=Running +``` + +{{< note >}} + +字段选择器本质上是资源*过滤器*。默认情况下，字段选择器/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。 +这使得以下的两个 `kubectl` 查询是等价的： + + +```shell +kubectl get pods +kubectl get pods --field-selector "" +``` +{{< /note >}} + +## 支持的字段 + + +不同的 Kubernetes 资源类型支持不同的字段选择器。 +所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。 +使用不被支持的字段选择器会产生错误，例如： + + +```shell +kubectl get ingress --field-selector foo.bar=baz +``` +``` +Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" +``` + +## 支持的运算符 + + +您可以使用 `=`、`==`和 `!=` 对字段选择器进行运算（`=` 和 `==` 的意义是相同的）。 +例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 名称空间的 Kubernetes Service： + + +```shell +kubectl get services --all-namespaces --field-selector metadata.namespace!=default +``` + +## 链式选择器 + + +同[标签](/docs/concepts/overview/working-with-objects/labels)和其他选择器一样，字段选择器可以通过使用逗号分隔的列表组成一个选择链。 +下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod： + + +```shell +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## 多种资源类型 + + +您能够跨多种资源类型来使用字段选择器。 +下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service： + + +```shell +kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default +``` diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 14c85b08629f1..1ca927dc5841a 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -5,18 +5,25 @@ redirect_from: - "/docs/concepts/abstractions/overview/" - "/docs/concepts/abstractions/overview.html" content_template: templates/concept -weight: 10 --- {{% capture overview %}} - + 本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 `.yaml` 格式的文件中表示。 {{% /capture %}} {{% capture body %}} + ## 理解 Kubernetes 对象 @@ -26,14 +33,21 @@ weight: 10 * 可以被应用使用的资源 * 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略 + Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。 -操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go) -，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。 +操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中使用 [客户端库](/docs/reference/using-api/client-libraries/) 直接调用 Kubernetes API。 + ### 对象规约（Spec）与状态（Status） @@ -41,16 +55,28 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete *spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。 *status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。 - + 例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。 当创建 Deployment 时，可能需要设置 Deployment 的规约，以指定该应用需要有 3 个副本在运行。 Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用的 3 个实例 —— 更新状态以与规约相匹配。 如果那些实例中有失败的（一种状态变更），Kubernetes 系统通过修正来响应规约和状态之间的不一致 —— 这种情况，会启动一个新的实例来替换。 + + 关于对象 spec、status 和 metadata 的更多信息，查看 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。 + ### 描述 Kubernetes 对象 @@ -61,22 +87,41 @@ Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用 这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约： -{{< code file="nginx-deployment.yaml" >}} +{{< codenew file="application/deployment.yaml" >}} + + -使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create) 命令，将 `.yaml` 文件作为参数。下面是一个示例： +使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令， +将 `.yaml` 文件作为参数。下面是一个示例： ```shell -$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record +kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record ``` + 输出类似如下这样： ```shell -deployment "nginx-deployment" created +deployment.apps/nginx-deployment created ``` + ### 必需字段 @@ -86,13 +131,29 @@ deployment "nginx-deployment" created * `kind` - 想要创建的对象的类型 * `metadata` - 帮助识别对象唯一性的数据，包括一个 `name` 字符串、UID 和可选的 `namespace` - - -也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/api/)能够帮助我们找到任何我们想创建的对象的 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` 格式， +并且可以从 +[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps) +查看 `Deployment` 的 `spec` 格式。 {{% /capture %}} {{% capture whatsnext %}} + -* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。 +* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。 {{% /capture %}} + + diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000000..93586739a3f8a --- /dev/null +++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,209 @@ +--- +title: 命名空间 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。 +这些虚拟集群被称为命名空间。 + + +{{% /capture %}} + + +{{% capture body %}} + +## 何时使用多个命名空间 + + +命名空间适用于存在很多跨多个团队或项目的用户的场景。 +对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当您需要命名空间提供的特性时，请开始使用它们。 + + +命名空间为名称提供了一个范围。 +资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes +资源只能属于一个命名空间。 + + + +命名空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/docs/concepts/policy/resource-quotas/)）。 + + +在 Kubernetes 未来版本中，相同命名空间中的对象默认将具有相同的访问控制策略。 + + +不需要使用多个命名空间来分隔轻微不同的资源，例如同一软件的不同版本： +使用[标签](/docs/user-guide/labels)来区分同一命名空间中的不同资源。 + + +## 使用命名空间 + + +命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。 + + +### 查看命名空间 + + +您可以使用以下命令列出集群中现存的命名空间： + + +```shell +kubectl get namespace +``` +``` +NAME STATUS AGE +default Active 1d +kube-system Active 1d +kube-public Active 1d +``` + +Kubernetes 会创建三个初始命名空间： + + + * `default` 没有指明使用其它命名空间的对象所使用的默认命名空间 + * `kube-system` Kubernetes 系统创建对象所使用的命名空间 + * `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。 + +### 为请求设置命名空间 + + +要为当前的请求设定一个命名空间，请使用 `--namespace` 参数。 + + +例如： + + +```shell +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= +``` + +### 设置命名空间首选项 + + +您可以永久保存该上下文中所有后续 kubectl 命令使用的命名空间。 + + +```shell +kubectl config set-context --current --namespace= +# Validate it +kubectl config view | grep namespace: +``` + +## 命名空间和 DNS + + +当您创建一个[服务](/docs/user-guide/services)时，Kubernetes 会创建一个相应的[DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。 + + +该条目的形式是 `..svc.cluster.local`， +这意味着如果容器只使用 ``，它将被解析到本地命名空间的服务。 +这对于跨多个命名空间（如开发、分级和生产）使用相同的配置非常有用。 +如果您希望跨命名空间访问，则需要使用完全限定域名（FQDN）。 + + +## 并非所有对象都在命名空间中 + + +大多数 kubernetes 资源（例如 Pod、服务、副本控制器等）都位于某些命名空间中。 +但是命名空间资源本身并不在命名空间中。 + + +而且底层资源，例如[节点](/docs/admin/node)和持久化卷不属于任何命名空间。 + + +查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中： + + +```shell +# In a namespace +kubectl api-resources --namespaced=true + +# Not in a namespace +kubectl api-resources --namespaced=false +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + +* 了解相关内容 [创建一个新的命名空间](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). +* 了解相关内容 [删除一个命名空间](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). +{{% /capture %}} + diff --git a/content/zh/docs/concepts/policy/_index.md b/content/zh/docs/concepts/policy/_index.md new file mode 100644 index 0000000000000..a724a7dd475c2 --- /dev/null +++ b/content/zh/docs/concepts/policy/_index.md @@ -0,0 +1,11 @@ +--- +title: "策略" +weight: 160 +--- + + From 8203544ac2d76334b811fb78f7938f514add4094 Mon Sep 17 00:00:00 2001 From: chenghen Date: Mon, 23 Sep 2019 19:25:27 +0900 Subject: [PATCH 4/4] 1. Add the lost yaml file. --- .../zh/examples/application/deployment.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 content/zh/examples/application/deployment.yaml diff --git a/content/zh/examples/application/deployment.yaml b/content/zh/examples/application/deployment.yaml new file mode 100644 index 0000000000000..0f526b16c0ad2 --- /dev/null +++ b/content/zh/examples/application/deployment.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 # tells deployment to run 2 pods matching the template + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80