ZH-trans: Fix invalid format (#11739)
This commit is contained in:
committed by
Kubernetes Prow Robot
parent
96d2816484
commit
b74bcf4d58
@@ -40,7 +40,7 @@ Master 组件通过非安全(没有加密或认证)端口和集群的 apiser
|
||||
从 master(apiserver)到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。
|
||||
|
||||
|
||||
### apiserver -> kubelet
|
||||
## apiserver -> kubelet
|
||||
|
||||
|
||||
从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接(通过 kubectl)运行中的 pods,以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。
|
||||
@@ -58,13 +58,13 @@ Master 组件通过非安全(没有加密或认证)端口和集群的 apiser
|
||||
最后,应该启用[Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。
|
||||
|
||||
|
||||
### apiserver -> nodes, pods, and services
|
||||
## apiserver -> nodes, pods, and services
|
||||
|
||||
|
||||
从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式,因此既没有认证,也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书,也不会提供客户端证书。这样虽然连接是加密的,但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。
|
||||
|
||||
|
||||
### SSH 隧道
|
||||
## SSH 隧道
|
||||
|
||||
|
||||
[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下,apiserver 发起一个到集群中每个节点的 SSH 隧道(连接到在 22 端口监听的 ssh 服务)并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。
|
||||
|
||||
@@ -60,43 +60,52 @@ Annotations, like labels, are key/value maps:
|
||||
<!--
|
||||
Here are some examples of information that could be recorded in annotations:
|
||||
-->
|
||||
|
||||
* 由声明性配置所管理的字段。
|
||||
将这些字段附加为注解,能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
|
||||
|
||||
<!--
|
||||
* Fields managed by a declarative configuration layer. Attaching these fields
|
||||
as annotations distinguishes them from default values set by clients or
|
||||
servers, and from auto-generated fields and fields set by
|
||||
auto-sizing or auto-scaling systems.
|
||||
-->
|
||||
|
||||
* 构建、发布或镜像信息(如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址)。
|
||||
|
||||
<!--
|
||||
* Build, release, or image information like timestamps, release IDs, git branch,
|
||||
PR numbers, image hashes, and registry address.
|
||||
-->
|
||||
|
||||
* 指向日志记录、监控、分析或审计仓库的指针。
|
||||
|
||||
<!--
|
||||
* Pointers to logging, monitoring, analytics, or audit repositories.
|
||||
-->
|
||||
|
||||
* 可用于调试目的的客户端库或工具信息:例如,名称、版本和构建信息。
|
||||
|
||||
<!--
|
||||
* Client library or tool information that can be used for debugging purposes:
|
||||
for example, name, version, and build information.
|
||||
-->
|
||||
|
||||
* 用户或者工具/系统的来源信息,例如来自其他生态系统组件的相关对象的 URL。
|
||||
|
||||
<!--
|
||||
* User or tool/system provenance information, such as URLs of related objects
|
||||
from other ecosystem components.
|
||||
-->
|
||||
|
||||
* 推出的轻量级工具的元数据信息:例如,配置或检查点。
|
||||
|
||||
<!--
|
||||
* Lightweight rollout tool metadata: for example, config or checkpoints.
|
||||
-->
|
||||
|
||||
* 负责人员的电话或呼机号码,或指定在何处可以找到该信息的目录条目,如团队网站。
|
||||
|
||||
<!--
|
||||
* Phone or pager numbers of persons responsible, or directory entries that
|
||||
specify where that information can be found, such as a team web site.
|
||||
|
||||
@@ -287,12 +287,15 @@ To update pods to a new spec in a controlled way, use a [rolling update](#rollin
|
||||
但是,它不会努力使现有的 Pod 与新的、不同的 Pod 模板匹配。
|
||||
若想要以可控的方式将 Pod 更新到新的 spec,就要使用 [滚动更新](#rolling-updates)的方式。
|
||||
|
||||
<!--
|
||||
|
||||
<!--
|
||||
|
||||
### Isolating pods from a ReplicaSet
|
||||
|
||||
Pods may be removed from a ReplicaSet's target set by changing their labels. This technique may be used to remove pods
|
||||
from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (
|
||||
assuming that the number of replicas is not also changed).
|
||||
|
||||
-->
|
||||
|
||||
### 将 Pod 从 ReplicaSet 中隔离
|
||||
|
||||
Reference in New Issue
Block a user