Merge pull request #27783 from tengqm/zh-sync-concepts-11
[zh] Resync concepts section (11)pull/27922/head
Kubernetes Prow Robot
GitHub
commit
5015aa2cea
|
|
@ -2,6 +2,10 @@
|
|||
title: 扩展 Kubernetes
|
||||
weight: 110
|
||||
description: 改变你的 Kubernetes 集群的行为的若干方法。
|
||||
feature:
|
||||
title: 为扩展性设计
|
||||
description: >
|
||||
无需更改上游源码即可扩展你的 Kubernetes 集群。
|
||||
content_type: concept
|
||||
no_list: true
|
||||
---
|
||||
|
|
@ -14,6 +18,10 @@ reviewers:
|
|||
- lavalamp
|
||||
- cheftako
|
||||
- chenopis
|
||||
feature:
|
||||
title: Designed for extensibility
|
||||
description: >
|
||||
Add features to your Kubernetes cluster without changing upstream source code.
|
||||
content_type: concept
|
||||
no_list: true
|
||||
-->
|
||||
|
|
@ -176,9 +184,11 @@ Kubernetes control plane.
|
|||
|
||||
下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
|
||||
|
||||
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
## Extension Points
|
||||
|
|
@ -189,9 +199,11 @@ This diagram shows the extension points in a Kubernetes system.
|
|||
|
||||
此示意图显示的是 Kubernetes 系统中的扩展点。
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
|
||||
|
||||
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
|
||||
|
|
@ -236,12 +248,15 @@ If you are unsure where to start, this flowchart can help. Note that some soluti
|
|||
如果你无法确定从何处入手，下面的流程图可能对你有些帮助。
|
||||
注意，某些方案可能需要同时采用几种类型的扩展。
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
|
||||
|
||||
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
||||
<!--
|
||||
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
## API Extensions
|
||||
|
||||
### User-Defined Types
|
||||
|
||||
Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
|
||||
|
|
@ -329,7 +344,7 @@ Kubernetes 提供若干种内置的认证方法，以及
|
|||
<!--
|
||||
### Authorization
|
||||
|
||||
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources - it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
|
||||
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources - it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
|
||||
-->
|
||||
### 鉴权 {#authorization}
|
||||
|
||||
|
|
|
|||
|
|
@ -64,9 +64,7 @@ apiserver-builder 库同时提供构造扩展 API 服务器和控制器框架代
|
|||
Extension API servers should have low latency networking to and from the kube-apiserver.
|
||||
Discovery requests are required to round-trip from the kube-apiserver in five seconds or less.
|
||||
|
||||
If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it. You can also set the
|
||||
`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver
|
||||
to disable the timeout restriction. This deprecated feature gate will be removed in a future release.
|
||||
If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it.
|
||||
-->
|
||||
### 反应延迟 {#response-latency}
|
||||
|
||||
|
|
@ -74,9 +72,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
|
|||
发现请求需要在五秒钟或更短的时间内完成到 kube-apiserver 的往返。
|
||||
|
||||
如果你的扩展 API 服务器无法满足这一延迟要求，应考虑如何更改配置已满足需要。
|
||||
你也可以为 kube-apiserver 设置 `EnableAggregatedDiscoveryTimeout=false`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
来禁用超时限制。此特性门控已经废弃，将在未来版本中被删除。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ Kubernetes 安装中就可用。定制资源所代表的是对特定 Kubernetes
|
|||
<!--
|
||||
## Custom controllers
|
||||
|
||||
On their own, custom resources simply let you store and retrieve structured data.
|
||||
On their own, custom resources let you store and retrieve structured data.
|
||||
When you combine a custom resource with a *custom controller*, custom resources
|
||||
provide a true _declarative API_.
|
||||
-->
|
||||
|
|
@ -93,13 +93,13 @@ desired state, and continually maintains this state.
|
|||
You can deploy and update a custom controller on a running cluster, independently
|
||||
of the cluster's lifecycle. Custom controllers can work with any kind of resource,
|
||||
but they are especially effective when combined with custom resources. The
|
||||
[Operator pattern](https://coreos.com/blog/introducing-operators.html) combines custom
|
||||
[Operator pattern](/docs/concepts/extend-kubernetes/operator/) combines custom
|
||||
resources and custom controllers. You can use custom controllers to encode domain knowledge
|
||||
for specific applications into an extension of the Kubernetes API.
|
||||
-->
|
||||
你可以在一个运行中的集群上部署和更新定制控制器，这类操作与集群的生命周期无关。
|
||||
定制控制器可以用于任何类别的资源，不过它们与定制资源结合起来时最为有效。
|
||||
[Operator 模式](https://coreos.com/blog/introducing-operators.html)就是将定制资源
|
||||
[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)就是将定制资源
|
||||
与定制控制器相结合的。你可以使用定制控制器来将特定于某应用的领域知识组织
|
||||
起来，以编码的形式构造对 Kubernetes API 的扩展。
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ Kubernetes 提供了两种方式供你向集群中添加定制资源：
|
|||
<!--
|
||||
Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility is compromised.
|
||||
|
||||
Aggregated APIs are subordinate API servers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
|
||||
Aggregated APIs are subordinate API servers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). To users, the Kubernetes API is extended.
|
||||
|
||||
CRDs allow users to create new types of resources without adding another API server. You do not need to understand API Aggregation to use CRDs.
|
||||
|
||||
|
|
|
|||
|
|
@ -323,13 +323,87 @@ for these devices:
|
|||
kubelet 提供了 gRPC 服务来使得正在使用中的设备被发现，并且还未这些设备提供了元数据：
|
||||
|
||||
```gRPC
|
||||
// PodResourcesLister is a service provided by the kubelet that provides information about the
|
||||
// node resources consumed by pods and containers on the node
|
||||
// PodResourcesLister 是一个由 kubelet 提供的服务，用来提供供节点上
|
||||
// Pods 和容器使用的节点资源的信息
|
||||
service PodResourcesLister {
|
||||
rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
|
||||
rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The `List` endpoint provides information on resources of running pods, with details such as the
|
||||
id of exclusively allocated CPUs, device id as it was reported by device plugins and id of
|
||||
the NUMA node where these devices are allocated.
|
||||
-->
|
||||
这一 `List` 端点提供运行中 Pods 的资源信息，包括类似独占式分配的
|
||||
CPU ID、设备插件所报告的设备 ID 以及这些设备分配所处的 NUMA 节点 ID。
|
||||
|
||||
```gRPC
|
||||
// ListPodResourcesResponse 是 List 函数的响应
|
||||
message ListPodResourcesResponse {
|
||||
repeated PodResources pod_resources = 1;
|
||||
}
|
||||
|
||||
// PodResources 包含关于分配给 Pod 的节点资源的信息
|
||||
message PodResources {
|
||||
string name = 1;
|
||||
string namespace = 2;
|
||||
repeated ContainerResources containers = 3;
|
||||
}
|
||||
|
||||
// ContainerResources 包含分配给容器的资源的信息
|
||||
message ContainerResources {
|
||||
string name = 1;
|
||||
repeated ContainerDevices devices = 2;
|
||||
repeated int64 cpu_ids = 3;
|
||||
}
|
||||
|
||||
// Topology 描述资源的硬件拓扑结构
|
||||
message TopologyInfo {
|
||||
repeated NUMANode nodes = 1;
|
||||
}
|
||||
|
||||
// NUMA 代表的是 NUMA 节点
|
||||
message NUMANode {
|
||||
int64 ID = 1;
|
||||
}
|
||||
|
||||
// ContainerDevices 包含分配给容器的设备信息
|
||||
message ContainerDevices {
|
||||
string resource_name = 1;
|
||||
repeated string device_ids = 2;
|
||||
TopologyInfo topology = 3;
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
GetAllocatableResources provides information on resources initially available on the worker node.
|
||||
It provides more information than kubelet exports to APIServer.
|
||||
-->
|
||||
端点 `GetAllocatableResources` 提供最初在工作节点上可用的资源的信息。
|
||||
此端点所提供的信息比导出给 API 服务器的信息更丰富。
|
||||
|
||||
|
||||
```gRPC
|
||||
// AllocatableResourcesResponses 包含 kubelet 所了解到的所有设备的信息
|
||||
message AllocatableResourcesResponse {
|
||||
repeated ContainerDevices devices = 1;
|
||||
repeated int64 cpu_ids = 2;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
`ContainerDevices` do expose the topology information declaring to which NUMA cells the device is affine.
|
||||
The NUMA cells are identified using a opaque integer ID, which value is consistent to what device
|
||||
plugins report [when they register themselves to the kubelet](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager).
|
||||
-->
|
||||
`ContainerDevices` 会向外提供各个设备所隶属的 NUMA 单元这类拓扑信息。
|
||||
NUMA 单元通过一个整数 ID 来标识，其取值与设备插件所报告的一致。
|
||||
[设备插件注册到 kubelet 时](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
||||
会报告这类信息。
|
||||
|
||||
<!--
|
||||
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
|
||||
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
|
||||
|
|
@ -338,7 +412,8 @@ agents must run in a privileged security context. If a device monitoring agent
|
|||
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
|
||||
{{< glossary_tooltip term_id="volume" >}} in the device monitoring agent's
|
||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
|
||||
|
||||
Support for the "PodResourcesLister service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
|
||||
It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
|
||||
-->
|
||||
gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接字来提供服务。
|
||||
|
|
@ -350,9 +425,9 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接
|
|||
中声明将 `/var/lib/kubelet/pod-resources` 目录以
|
||||
{{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到设备监控代理中。
|
||||
|
||||
对“PodResources 服务”的支持要求启用 `KubeletPodResources`
|
||||
对“PodResourcesLister 服务”的支持要求启用 `KubeletPodResources`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
从 Kubernetes 1.15 开始默认启用，自从 Kubernetes 1.20开始为 v1。
|
||||
从 Kubernetes 1.15 开始默认启用，自从 Kubernetes 1.20 开始为 v1。
|
||||
|
||||
<!--
|
||||
## Device Plugin integration with the Topology Manager
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Kubernetes中的网络插件有几种类型：
|
|||
The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as CRI manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
|
||||
|
||||
* `cni-bin-dir`: Kubelet probes this directory for plugins on startup
|
||||
* `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is simply "cni".
|
||||
* `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is "cni".
|
||||
-->
|
||||
## 安装
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue