Merge pull request #33721 from Sea-n/fix-typo-k8s-zh-docs
[zh] Fix `Kubernetes` typo for docspull/33598/head
Kubernetes Prow Robot
GitHub
commit
6f0ac0cf7d
|
|
@ -109,7 +109,7 @@ Network access to API Server (Control plane) | All access to the Kubernetes cont
|
|||
Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists) from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
|
||||
Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
|
||||
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
|
||||
etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, and since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
|
||||
etcd Encryption | Wherever possible it's a good practice to encrypt all storage at rest, and since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
|
||||
|
||||
{{< /table >}}
|
||||
-->
|
||||
|
|
@ -119,13 +119,13 @@ etcd Encryption | Wherever possible it's a good practice to encrypt all drives a
|
|||
|
||||
{{< table caption="基础设施安全" >}}
|
||||
|
||||
Kubetnetes 基础架构关注领域 | 建议 |
|
||||
Kubernetes 基础架构关注领域 | 建议 |
|
||||
--------------------------------------------- | -------------- |
|
||||
通过网络访问 API 服务（控制平面）|所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。|
|
||||
通过网络访问 Node（节点）| 节点应配置为 _仅能_ 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。|
|
||||
Kubernetes 访问云提供商的 API | 每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege)。[Kops 文档](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)提供有关 IAM 策略和角色的信息。|
|
||||
访问 etcd | 对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 [etcd 文档](https://github.com/etcd-io/etcd/tree/master/Documentation)中找到。|
|
||||
etcd 加密 | 在所有可能的情况下，最好对所有驱动器进行静态数据加密，并且由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。|
|
||||
etcd 加密 | 在所有可能的情况下，最好对所有存储进行静态数据加密，并且由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。|
|
||||
|
||||
{{< /table >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ weight: 21 # just after persistent volumes
|
|||
<!--
|
||||
This document describes _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
-->
|
||||
本文档描述 Kubernet 中的*投射卷（Projected Volumes）*。
|
||||
本文档描述 Kubernetes 中的*投射卷（Projected Volumes）*。
|
||||
建议先熟悉[卷](/zh/docs/concepts/storage/volumes/)概念。
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -49,10 +49,10 @@ Currently, the following types of volume sources can be projected:
|
|||
|
||||
<!--
|
||||
All sources are required to be in the same namespace as the Pod. For more details,
|
||||
see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
|
||||
see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md) design document.
|
||||
-->
|
||||
所有的卷源都要求处于 Pod 所在的同一个名字空间内。进一步的详细信息，可参考
|
||||
[一体化卷设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)。
|
||||
[一体化卷](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md)设计文档。
|
||||
|
||||
<!--
|
||||
### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
|
||||
|
|
@ -140,11 +140,9 @@ volume mount will not receive updates for those volume sources.
|
|||
## 与 SecurityContext 间的关系 {#securitycontext-interactions}
|
||||
|
||||
<!--
|
||||
The [proposal for file permission handling in projected service account volume](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#token-volume-projection)
|
||||
enhancement introduced the projected files having the the correct owner
|
||||
permissions set.
|
||||
The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set.
|
||||
-->
|
||||
[关于在投射的服务账号卷中处理文件访问权限的提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#token-volume-projection)
|
||||
关于在投射的服务账号卷中处理文件访问权限的[提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal)
|
||||
介绍了如何使得所投射的文件具有合适的属主访问权限。
|
||||
|
||||
### Linux
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ tags:
|
|||
-->
|
||||
|
||||
<!--
|
||||
May refer to: code in the Kubernetes ecosystem that depends upon the core Kubernetes codebase or a forked repo.
|
||||
May refer to: code in the Kubernetes ecosystem that depends upon the core Kubernetes codebase or a forked repo.
|
||||
-->
|
||||
|
||||
可以指：Kubernetes 生态系统中依赖于核心 Kubernetes 代码库或分支代码库的代码。
|
||||
|
|
@ -39,6 +39,6 @@ May refer to: code in the Kubernetes ecosystem that depends upon the core Kubern
|
|||
* In **GitHub** or **git**: The convention is to refer to a forked repo as *downstream*, whereas the source repo is considered *upstream*.
|
||||
-->
|
||||
|
||||
* 在 **Kubernetes 社区**中：*下游(downstream)* 在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如，Kubernete 的一个新特性可以被*下游(downstream)* 应用采用，以提升它们的功能性。
|
||||
* 在 **Kubernetes 社区**中：*下游(downstream)* 在人们交流中常用来表示那些依赖核心 Kubernetes 代码库的生态系统、代码或者第三方工具。例如，Kubernetes 的一个新特性可以被*下游(downstream)* 应用采用，以提升它们的功能性。
|
||||
* 在 **GitHub** 或 **git** 中：约定用*下游(downstream)* 表示分支代码库，源代码库被认为是*上游(upstream)*。
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ This page shows how to connect to services running on the Kubernetes cluster.
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
|
@ -141,7 +142,7 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l
|
|||
See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.
|
||||
-->
|
||||
{{< note >}}
|
||||
请参阅[使用 Kubernets API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)
|
||||
请参阅[使用 Kubernetes API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)
|
||||
了解如何传递凭据或如何使用 `kubectl proxy`。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -189,47 +190,47 @@ URL 的 `<service_name>` 段支持的格式为：
|
|||
|
||||
* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`，你可以使用：
|
||||
|
||||
```
|
||||
http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
```
|
||||
```
|
||||
http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
```
|
||||
|
||||
<!--
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:
|
||||
-->
|
||||
* 如要访问 Elasticsearch 集群健康信息`_cluster/health?pretty=true`，你会使用：
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
```
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
```
|
||||
|
||||
<!--
|
||||
The health information is similar to this:
|
||||
-->
|
||||
健康信息与下面的例子类似：
|
||||
<!--
|
||||
The health information is similar to this:
|
||||
-->
|
||||
健康信息与下面的例子类似：
|
||||
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
"timed_out" : false,
|
||||
"number_of_nodes" : 1,
|
||||
"number_of_data_nodes" : 1,
|
||||
"active_primary_shards" : 5,
|
||||
"active_shards" : 5,
|
||||
"relocating_shards" : 0,
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
"timed_out" : false,
|
||||
"number_of_nodes" : 1,
|
||||
"number_of_data_nodes" : 1,
|
||||
"active_primary_shards" : 5,
|
||||
"active_shards" : 5,
|
||||
"relocating_shards" : 0,
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
* To access the *https* Elasticsearch service health information `_cluster/health?pretty=true`, you would use:
|
||||
-->
|
||||
* 要访问 *https* Elasticsearch 服务健康信息 `_cluster/health?pretty=true`，你会使用：
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Using web browsers to access services running on the cluster
|
||||
|
|
@ -241,12 +242,12 @@ You may be able to put an apiserver proxy URL into the address bar of a browser.
|
|||
你或许能够将 API 服务器代理的 URL 放入浏览器的地址栏，然而：
|
||||
|
||||
<!--
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct URLs in a
|
||||
- Some web apps may not work, particularly those with client side javascript that construct URLs in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
-->
|
||||
- Web 服务器通常不能传递令牌，所以你可能需要使用基本（密码）认证。
|
||||
API 服务器可以配置为接受基本认证，但你的集群可能并没有这样配置。
|
||||
- 某些 Web 应用可能无法工作，特别是那些使用客户端 Javascript 构造 URL 的
|
||||
应用，所构造的 URL 可能并不支持代理路径前缀。
|
||||
- Web 服务器通常不能传递令牌，所以你可能需要使用基本（密码）认证。
|
||||
API 服务器可以配置为接受基本认证，但你的集群可能并没有这样配置。
|
||||
- 某些 Web 应用可能无法工作，特别是那些使用客户端 Javascript 构造 URL 的
|
||||
应用，所构造的 URL 可能并不支持代理路径前缀。
|
||||
|
|
|
|||
Loading…
Reference in New Issue