Skip to content

Commit 3e54ef1

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #24485 from tengqm/zh-add-glossary
[zh] Add missing glossary for Chinese
2 parents 504ca45 + 16ab759 commit 3e54ef1

File tree

3 files changed

+179
-0
lines changed

3 files changed

+179
-0
lines changed

‎content/zh/docs/reference/glossary/cloud-provider.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
---
2+
title: 云供应商（Cloud Provider）
3+
id: cloud-provider
4+
date: 2018-04-12
5+
short_description: >
6+
一个提供云计算平台的组织。
7+
8+
aka:
9+
- 云服务供应商（Cloud Service Provider）
10+
tags:
11+
- community
12+
---
13+
一个提供云计算平台的商业机构或其他组织。
14+
15+
<!--
16+
Cloud Provider）
17+
id: cloud-provider
18+
date: 2018-04-12
19+
short_description: >
20+
An organization that offers a cloud computing platform.
21+
22+
aka:
23+
- Cloud Service Provider
24+
tags:
25+
- community
26+
27+
A business or other organization that offers a cloud computing platform.
28+
-->
29+
30+
<!--more-->
31+
32+
<!--
33+
Cloud providers, sometimes called Cloud Service Providers (CSPs), offer
34+
cloud computing platforms or services.
35+
36+
Many cloud providers offer managed infrastructure (also called
37+
Infrastructure as a Service or IaaS).
38+
With managed infrastructure the cloud provider is responsible for
39+
servers, storage, and networking while you manage layers on top of that
40+
such as running a Kubernetes cluster.
41+
42+
You can also find Kubernetes as a managed service; sometimes called
43+
Platform as a Service, or PaaS. With managed Kubernetes, your
44+
cloud provider is responsible for the Kubernetes control plane as well
45+
as the glossary_tooltip term_id="node" text="nodes" and the
46+
infrastructure they rely on: networking, storage, and possibly other
47+
elements such as load balancers.
48+
-->
49+
云供应商，有时也称作云服务供应商（CSPs）提供云计算平台或服务。
50+
51+
很多云供应商提供托管的基础设施（也称作基础设施即服务或 IaaS）。
52+
针对托管的基础设施，云供应商负责服务器、存储和网络，而用户（你）
53+
负责管理其上运行的各层软件，例如运行一个 Kubernetes 集群。
54+
55+
你也会看到 Kubernetes 被作为托管服务提供；有时也称作平台即服务或 PaaS。
56+
针对托管的 Kubernetes，你的云供应商负责 Kubernetes 的控制面以及
57+
{{< glossary_tooltip term_id="node" text="节点" >}}及他们所依赖的基础设施：
58+
网络、存储以及其他一些诸如负载均衡器之类的元素。
59+

‎content/zh/docs/reference/glossary/endpoint.md

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
---
2+
title: 端点（Endpoints）
3+
id: endpoints
4+
date: 2020-04-23
5+
full_link:
6+
short_description: >
7+
端点负责记录与服务（Service）的选择器相匹配的 Pods 的 IP 地址。
8+
9+
aka:
10+
tags:
11+
- networking
12+
---
13+
端点负责记录与服务的{{< glossary_tooltip text="选择器" term_id="selector" >}}相匹配的 Pods 的 IP 地址。
14+
15+
<!--
16+
title: Endpoints
17+
id: endpoints
18+
date: 2020-04-23
19+
full_link:
20+
short_description: >
21+
Endpoints track the IP addresses of Pods with matching Service selectors.
22+
23+
aka:
24+
tags:
25+
- networking
26+
Endpoints track the IP addresses of Pods with matching {{< glossary_tooltip text="selectors" term_id="selector" >}}.
27+
-->
28+
29+
<!--more-->
30+
<!--
31+
Endpoints can be configured manually for Services without selectors specified.
32+
The EndpointSlice resource provides a scalable and extensible alternative to Endpoints.
33+
-->
34+
端点可以手动配置到{{< glossary_tooltip text="服务（Service）" term_id="service" >}}上，而不必设置选择算符。
35+
{{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} 资源为 Endpoints
36+
提供了一种可伸缩、可扩展的替代方案。

‎content/zh/docs/reference/glossary/shuffle-sharding.md

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
---
2+
title: 混排切片（Shuffle Sharding）
3+
id: shuffle-sharding
4+
date: 2020-03-04
5+
full_link:
6+
short_description: >
7+
一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。
8+
9+
aka:
10+
tags:
11+
- fundamental
12+
---
13+
一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。
14+
15+
<!--
16+
title: shuffle sharding
17+
id: shuffle-sharding
18+
date: 2020-03-04
19+
full_link:
20+
short_description: >
21+
A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.
22+
23+
aka:
24+
tags:
25+
- fundamental
26+
A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.
27+
-->
28+
29+
<!--more-->
30+
31+
<!--
32+
We are often concerned with insulating different flows of requests
33+
from each other, so that a high-intensity flow does not crowd out low-intensity flows.
34+
A simple way to put requests into queues is to hash some
35+
characteristics of the request, modulo the number of queues, to get
36+
the index of the queue to use. The hash function uses as input
37+
characteristics of the request that align with flows. For example, in
38+
the Internet this is often the 5-tuple of source and destination
39+
address, protocol, and source and destination port.
40+
-->
41+
我们通常会关心不同的请求序列间的相互隔离问题，目的是为了确保密度较高的
42+
请求序列不会湮没密度较低的序列。
43+
将请求放入不同队列的一种简单方法是对请求的某些特征值执行哈希函数，
44+
将结果对队列的个数取模，从而得到要使用的队列的索引。
45+
这一哈希函数使用请求的与其序列相对应的特征作为其输入。例如，在因特网上，
46+
这一特征通常指的是由源地址、目标地址、协议、源端口和目标端口所组成的
47+
五元组。
48+
49+
<!--
50+
That simple hash-based scheme has the property that any high-intensity flow
51+
will crowd out all the low-intensity flows that hash to the same queue.
52+
Providing good insulation for a large number of flows requires a large
53+
number of queues, which is problematic. Shuffle sharding is a more
54+
nimble technique that can do a better job of insulating the low-intensity
55+
flows from the high-intensity flows. The terminology of shuffle sharding uses
56+
the metaphor of dealing a hand from a deck of cards; each queue is a
57+
metaphorical card. The shuffle sharding technique starts with hashing
58+
the flow-identifying characteristics of the request, to produce a hash
59+
value with dozens or more of bits. Then the hash value is used as a
60+
source of entropy to shuffle the deck and deal a hand of cards
61+
(queues). All the dealt queues are examined, and the request is put
62+
into one of the examined queues with the shortest length. With a
63+
modest hand size, it does not cost much to examine all the dealt cards
64+
and a given low-intensity flow has a good chance to dodge the effects of a
65+
given high-intensity flow. With a large hand size it is expensive to examine
66+
the dealt queues and more difficult for the low-intensity flows to dodge the
67+
collective effects of a set of high-intensity flows. Thus, the hand size
68+
should be chosen judiciously.
69+
-->
70+
这种简单的基于哈希的模式有一种特性，高密度的请求序列（流）会湮没那些被
71+
哈希到同一队列的其他低密度请求序列（流）。
72+
为大量的序列提供较好的隔离性需要提供大量的队列，因此是有问题的。
73+
混排切片是一种更为灵活的机制，能够更好地将低密度序列与高密度序列隔离。
74+
混排切片的术语采用了对一叠扑克牌进行洗牌的类比，每个队列可类比成一张牌。
75+
混排切片技术首先对请求的特定于所在序列的特征执行哈希计算，生成一个长度
76+
为十几个二进制位或更长的哈希值。
77+
接下来，用该哈希值作为信息熵的来源，对一叠牌来混排，并对整个一手牌（队列）来洗牌。
78+
最后，对所有处理过的队列进行检查，选择长度最短的已检查队列作为请求的目标队列。
79+
在队列数量适中的时候，检查所有已处理的牌的计算量并不大，对于任一给定的
80+
低密度的请求序列而言，有相当的概率能够消除给定高密度序列的湮没效应。
81+
当队列数量较大时，检查所有已处理队列的操作会比较耗时，低密度请求序列
82+
消除一组高密度请求序列的湮没效应的机会也随之降低。因此，选择队列数目
83+
时要颇为谨慎。
84+

0 commit comments

Comments
 (0)