Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
0268ed0c18
commit
b05129acc3
@@ -229,19 +229,19 @@ An example request body:
|
||||
请求载荷例子：
|
||||
|
||||
```
|
||||
{
|
||||
{
|
||||
"apiVersion":"imagepolicy.k8s.io/v1alpha1",
|
||||
"kind":"ImageReview",
|
||||
"spec":{
|
||||
"containers":[
|
||||
{
|
||||
"spec":{
|
||||
"containers":[
|
||||
{
|
||||
"image":"myrepo/myimage:v1"
|
||||
},
|
||||
{
|
||||
{
|
||||
"image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
|
||||
}
|
||||
],
|
||||
"annotations":[
|
||||
"annotations":[
|
||||
"mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
|
||||
],
|
||||
"namespace":"mynamespace"
|
||||
@@ -510,7 +510,7 @@ for more information.
|
||||
|
||||
<!--
|
||||
This plug-in limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission plugin,
|
||||
kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:<nodeName>`.
|
||||
kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:<nodeName>`.
|
||||
Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node.
|
||||
-->
|
||||
这个插件限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 为了受到这个入场插件的限制，kubelet 必须在 `system：nodes` 组中使用凭证，并使用 `system：node：<nodeName>` 形式的用户名。这样的 kubelet 只允许修改自己的 `Node` API 对象，只能修改绑定到节点本身的 `Pod` 对象。
|
||||
|
||||
@@ -109,7 +109,7 @@ DELETE | delete (for individual resources), deletecollection (for collections
|
||||
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
|
||||
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group.
|
||||
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
|
||||
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
|
||||
of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
|
||||
* [Authentication](/docs/reference/access-authn-authz/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
|
||||
-->
|
||||
@@ -141,7 +141,7 @@ Kubernetes有时使用专门的动词检查授权以获得额外的权限。例
|
||||
* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
|
||||
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/reference/access-authn-authz/webhook/).
|
||||
-->
|
||||
|
||||
|
||||
## 授权模块
|
||||
* **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/).
|
||||
* **ABAC** - 基于属性的访问控制（ABAC) 定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅[ABAC 模式](/docs/reference/access-authn-authz/abac/)。
|
||||
@@ -169,7 +169,7 @@ yes
|
||||
$ kubectl auth can-i create deployments --namespace prod
|
||||
no
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
|
||||
to determine what action other users can perform.
|
||||
-->
|
||||
|
||||
@@ -73,7 +73,7 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。
|
||||
}
|
||||
}
|
||||
```
|
||||
如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。
|
||||
如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。
|
||||
|
||||
Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的，因为除Kubernetes外，这些访问控制系统还可能与其他的API进行交互。
|
||||
|
||||
@@ -103,7 +103,7 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook
|
||||
|
||||
## API的端口和IP
|
||||
|
||||
上述讨论适用于发送请求到API服务器的安全端口(典型情况)。
|
||||
上述讨论适用于发送请求到API服务器的安全端口(典型情况)。
|
||||
实际上API服务器可以通过两个端口提供服务：
|
||||
|
||||
默认情况下，API服务器在2个端口上提供HTTP服务：
|
||||
|
||||
@@ -7,7 +7,7 @@ approvers:
|
||||
title: 管理Service Accounts
|
||||
---
|
||||
|
||||
*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。*
|
||||
*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。*
|
||||
|
||||
*对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述service accounts，有时这些不完善的特性也会被提及。*
|
||||
|
||||
|
||||
@@ -49,15 +49,15 @@ kube-apiserver
|
||||
--authentication-token-webhook-config-file string 包含webhook配置的文件，用于令牌认证，具有kubeconfig格式。API server将查询远程服务来决定对bearer令牌的认证。
|
||||
|
||||
--authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表，包括：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.（默认值"AlwaysAllow"）
|
||||
|
||||
|
||||
--authorization-policy-file string 包含权限验证策略的csv文件，和--authorization-mode=ABAC一起使用，作用在安全端口上。
|
||||
|
||||
--authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。（默认值5m0s）
|
||||
|
||||
|
||||
--authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。（默认值5m0s）
|
||||
|
||||
--authorization-webhook-cache-unauthorized-ttl duration 从webhook授权者获得的'unauthorized'响应的缓存时长。（默认值30s）
|
||||
|
||||
|
||||
--authorization-webhook-config-file string 包含webhook配置的kubeconfig格式文件，和--authorization-mode=Webhook一起使用。API server将查询远程服务来决定对API server安全端口的访问。
|
||||
|
||||
|
||||
--azure-container-registry-config string 包含Azure容器注册表配置信息的文件的路径。
|
||||
|
||||
--basic-auth-file string 如果设置该值，这个文件将会被用于准许通过http基本认证到API server安全端口的请求。
|
||||
@@ -67,11 +67,11 @@ kube-apiserver
|
||||
--cert-dir string 存放TLS证书的目录。如果提供了--tls-cert-file和--tls-private-key-file选项，该标志将被忽略。（默认值 "/var/run/kubernetes"）
|
||||
|
||||
--client-ca-file string 如果设置此标志，对于任何请求，如果存包含client-ca-file中的authorities签名的客户端证书，将会使用客户端证书中的CommonName对应的身份进行认证。
|
||||
|
||||
|
||||
--cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件.
|
||||
|
||||
|
||||
--cloud-provider string 云服务提供商，空字符串表示无提供商。
|
||||
|
||||
|
||||
--contention-profiling 如果已经启用profiling，则启用锁竞争profiling。
|
||||
|
||||
--cors-allowed-origins stringSlice CORS的域列表，以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用CORS.
|
||||
@@ -148,12 +148,12 @@ TaintBasedEvictions=true|false (ALPHA - default=false)
|
||||
|
||||
--kubelet-read-only-port uint 已废弃: kubelet端口. （默认值10255）
|
||||
|
||||
--kubelet-timeout duration kubelet操作超时时间。（默认值
|
||||
--kubelet-timeout duration kubelet操作超时时间。（默认值
|
||||
5s）
|
||||
|
||||
--kubernetes-service-node-port int 如果不为0，Kubernetes master服务（用于创建/管理apiserver）将会使用NodePort类型，并将这个值作为端口号。如果为0，Kubernetes master服务将会使用ClusterIP类型。
|
||||
|
||||
--master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。（默认值"default"）
|
||||
--master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。（默认值"default"）
|
||||
|
||||
--max-connection-bytes-per-sec int 如果不为0，每个用户连接将会被限速为该值（bytes/sec）。当前只应用于长时间运行的请求。
|
||||
|
||||
@@ -162,67 +162,67 @@ TaintBasedEvictions=true|false (ALPHA - default=false)
|
||||
--max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0值表示没有限制。（默认值400）
|
||||
|
||||
--min-request-timeout int 一个可选字段，表示一个handler在一个请求超时前，必须保持它处于打开状态的最小秒数。当前只对监听请求handler有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的（默认值1800）。
|
||||
|
||||
|
||||
--oidc-ca-file string 如果设置该值，将会使用oidc-ca-file中的任意一个authority对OpenID服务的证书进行验证，否则将会使用主机的根CA对其进行验证。
|
||||
|
||||
|
||||
--oidc-client-id string 使用OpenID连接的客户端的ID，如果设置了oidc-issuer-url，则必须设置这个值。
|
||||
|
||||
|
||||
--oidc-groups-claim string 如果提供该值，这个自定义OpenID连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
|
||||
|
||||
--oidc-issuer-url string OpenID颁发者URL，只接受HTTPS方案。如果设置该值，它将被用于验证OIDC JSON Web Token(JWT)。
|
||||
|
||||
|
||||
--oidc-username-claim string 用作用户名的OpenID声明值。注意，不保证除默认 ('sub')外的其他声明值的唯一性和不变性。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
|
||||
|
||||
|
||||
--profiling 在web接口host:port/debug/pprof/上启用profiling。（默认值true）
|
||||
|
||||
|
||||
--proxy-client-cert-file string 当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。它期望这个证书包含一个来自于CA中的--requestheader-client-ca-file标记的签名。该CA在kube-system命名空间的'extension-apiserver-authentication' configmap中发布。从Kube-aggregator收到调用的组件应该使用该CA进行他们部分的双向TLS验证。
|
||||
|
||||
|
||||
--proxy-client-key-file string 当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书密钥。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。
|
||||
|
||||
|
||||
--repair-malformed-updates 如果为true，服务将会尽力修复更新请求以通过验证，例如：将更新请求UID的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后，可以关闭这个标志。
|
||||
|
||||
--requestheader-allowed-names stringSlice 使用--requestheader-username-headers指定的，允许在头部提供用户名的客户端证书通用名称列表。如果为空，任何通过--requestheader-client-ca-file中authorities验证的客户端证书都是被允许的。
|
||||
|
||||
|
||||
--requestheader-client-ca-file string 在信任请求头中以--requestheader-username-headers指示的用户名之前，用于验证接入请求中客户端证书的根证书捆绑。
|
||||
|
||||
|
||||
--requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用X-Remote-Extra-。
|
||||
|
||||
--requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用X-Remote-Group.
|
||||
|
||||
|
||||
--requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用X-Remote-User。
|
||||
|
||||
|
||||
--runtime-config mapStringString 传递给apiserver用于描述运行时配置的键值对集合。 apis/<groupVersion>键可以被用来打开/关闭特定的api版本。apis/<groupVersion>/<resource>键被用来打开/关闭特定的资源. api/all和api/legacy键分别用于控制所有的和遗留的api版本.
|
||||
|
||||
|
||||
--secure-port int 用于监听具有认证授权功能的HTTPS协议的端口。如果为0，则不会监听HTTPS协议。 （默认值6443)
|
||||
|
||||
|
||||
--service-account-key-file stringArray 包含PEM加密的x509 RSA或ECDSA私钥或公钥的文件，用于验证ServiceAccount令牌。如果设置该值，--tls-private-key-file将会被使用。指定的文件可以包含多个密钥，并且这个标志可以和不同的文件一起多次使用。
|
||||
|
||||
|
||||
--service-cluster-ip-range ipNet CIDR表示的IP范围，服务的cluster ip将从中分配。 一定不要和分配给nodes和pods的IP范围产生重叠。
|
||||
|
||||
|
||||
--ssh-keyfile string 如果不为空，在使用安全的SSH代理访问节点时，将这个文件作为用户密钥文件。
|
||||
|
||||
|
||||
--storage-backend string 持久化存储后端。 选项为: 'etcd3' (默认), 'etcd2'.
|
||||
|
||||
|
||||
--storage-media-type string 在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型，并且忽略该配置项。（默认值 "application/vnd.kubernetes.protobuf")
|
||||
|
||||
|
||||
--storage-versions string 按组划分资源存储的版本。 以"group1/version1,group2/version2,..."的格式指定。当对象从一组移动到另一组时, 你可以指定"group1=group2/v1beta1,group3/v1beta1,..."的格式。你只需要传入你希望从结果中改变的组的列表。默认为从KUBE_API_VERSIONS环境变量集成而来，所有注册组的首选版本列表。 （默认值"admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
|
||||
|
||||
|
||||
--target-ram-mb int apiserver内存限制，单位为MB(用于配置缓存大小等)。
|
||||
|
||||
|
||||
--tls-ca-file string 如果设置该值，这个证书authority将会被用于从Admission Controllers过来的安全访问。它必须是一个PEM加密的合法CA捆绑包。此外, 该证书authority可以被添加到以--tls-cert-file提供的证书文件中.
|
||||
|
||||
|
||||
--tls-cert-file string 包含用于HTTPS的默认x509证书的文件。（如果有CA证书，则附加于server证书之后）。如果启用了HTTPS服务，并且没有提供--tls-cert-file和--tls-private-key-file，则将为公共地址生成一个自签名的证书和密钥并保存于/var/run/kubernetes目录。
|
||||
|
||||
|
||||
--tls-private-key-file string 包含匹配--tls-cert-file的x509证书私钥的文件。
|
||||
|
||||
|
||||
--tls-sni-cert-key namedCertKey 一对x509证书和私钥的文件路径, 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀, 则将提取证书名。 非通配符版本优先于通配符版本, 显示的域形式优先于证书中提取的名字。 对于多个密钥/证书对, 请多次使用--tls-sni-cert-key。例如: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". （默认值[])
|
||||
|
||||
|
||||
--token-auth-file string 如果设置该值，这个文件将被用于通过令牌认证来保护API服务的安全端口。
|
||||
|
||||
|
||||
--version version[=true] 打印版本信息并退出。
|
||||
|
||||
|
||||
--watch-cache 启用apiserver的监视缓存。（默认值true）
|
||||
|
||||
|
||||
--watch-cache-sizes stringSlice 每种资源（pods, nodes等）的监视缓存大小列表，以逗号分隔。每个缓存配置的形式为：resource#size，size是一个数字。在watch-cache启用时生效。
|
||||
```
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ While any authentication strategy can be used for the kubelet's initial bootstra
|
||||
1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__
|
||||
2. [Token authentication file](###token-authentication-file)
|
||||
|
||||
Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario.
|
||||
Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario.
|
||||
|
||||
### Token authentication file
|
||||
Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number
|
||||
|
||||
@@ -6,7 +6,7 @@ full_link: /docs/concepts/services-networking/ingress/
|
||||
short_description: >
|
||||
An API object that manages external access to the services in a cluster, typically HTTP.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
- architecture
|
||||
@@ -17,7 +17,7 @@ tags:
|
||||
-->
|
||||
一个 API 对象，用于管理对集群中服务的外部访问，通常是 HTTP。
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
<!--
|
||||
Ingress can provide load balancing, SSL termination and name-based virtual hosting.
|
||||
-->
|
||||
|
||||
@@ -20,7 +20,7 @@ $ docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 ngi
|
||||
a9ec34d9878748d2f33dc20cb25c714ff21da8d40558b45bfaec9955859075d0
|
||||
$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx-app
|
||||
a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx-app
|
||||
```
|
||||
|
||||
使用 kubectl 命令：
|
||||
@@ -141,7 +141,7 @@ $ docker exec -ti a9ec34d98787 /bin/sh
|
||||
使用 kubectl 命令：
|
||||
|
||||
```shell
|
||||
$ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
|
||||
$ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
|
||||
# exit
|
||||
```
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ kubectl 可以操控 Kubernetes 集群。
|
||||
<!--
|
||||
### Synopsis
|
||||
|
||||
kubectl controls the Kubernetes cluster manager.
|
||||
kubectl controls the Kubernetes cluster manager.
|
||||
|
||||
Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
|
||||
-->
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: Kubernetes API
|
||||
title: Kubernetes API
|
||||
weight: 30
|
||||
---
|
||||
|
||||
@@ -70,25 +70,25 @@ Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。 未使
|
||||
|
||||
用于：节点、PersistentVolume
|
||||
|
||||
用于节点： Kubelet 用 `cloudprovider` 中定义的区域（zone）信息来填充该标签。 未使用 `cloudprovider`
|
||||
用于节点： Kubelet 用 `cloudprovider` 中定义的区域（zone）信息来填充该标签。 未使用 `cloudprovider`
|
||||
时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。
|
||||
|
||||
用于 PersistentVolume：在 GCE 和 AWS 中，`PersistentVolumeLabel` 准入控制器会自动添加区域标签。
|
||||
|
||||
在单区的集群中，Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。
|
||||
在多区的集群中，这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。 跨区分散通过 SelectorSpreadPriority
|
||||
在单区的集群中，Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。
|
||||
在多区的集群中，这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。 跨区分散通过 SelectorSpreadPriority
|
||||
来实现。
|
||||
|
||||
这是一种尽力而为（best-effort）的处置方式， 如果集群中的区域是异构的 (例如：不同区域之间的节点数量、
|
||||
节点类型或 pod 资源需求不同），可能使得 pod 在各区域间无法均匀分布。 如有需要，用户可以使用同质的区域
|
||||
节点类型或 pod 资源需求不同），可能使得 pod 在各区域间无法均匀分布。 如有需要，用户可以使用同质的区域
|
||||
(节点数量和类型相同) 来减小 pod 分布不均的可能性。
|
||||
|
||||
由于卷不能跨区域挂载（attach），调度器 (通过 VolumeZonePredicate 断言) 也会保证需要特定卷的 pod
|
||||
由于卷不能跨区域挂载（attach），调度器 (通过 VolumeZonePredicate 断言) 也会保证需要特定卷的 pod
|
||||
被调度到卷所在的区域中。
|
||||
|
||||
|
||||
区域和地域（region）的实际值无关紧要，两者的层次含义也没有严格的定义。 最终期望是，除非整个地域故障，
|
||||
否则某一区域节点的故障不应该影响到其他区域的节点。 例如，通常区域间应该避免共用同一个网络交换机。
|
||||
否则某一区域节点的故障不应该影响到其他区域的节点。 例如，通常区域间应该避免共用同一个网络交换机。
|
||||
具体的规划取决于特定的基础设备—— three-rack 设备所选择的设置与多数据中心截然不同。
|
||||
|
||||
如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod
|
||||
|
||||
@@ -79,7 +79,7 @@ following steps: -->
|
||||
themselves with the master in the future. Optionally, the user can provide a
|
||||
token via `--token`, as described in the
|
||||
[kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) docs. -->
|
||||
3. 生成令牌以便其它节点以后可以使用这个令牌向 master 节点注册它们自己。 可选的，用户可以通过 `--token` 提供一个令牌, 正如文档[kubeadm 的令牌](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 描述的那样。
|
||||
3. 生成令牌以便其它节点以后可以使用这个令牌向 master 节点注册它们自己。 可选的，用户可以通过 `--token` 提供一个令牌, 正如文档[kubeadm 的令牌](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 描述的那样。
|
||||
|
||||
<!-- 4. Makes all the necessary configurations for allowing node joining with the
|
||||
[Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and
|
||||
|
||||
@@ -28,7 +28,7 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet
|
||||
-->
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。
|
||||
|
||||
## Kubeadm
|
||||
## Kubeadm
|
||||
|
||||
<!--
|
||||
[`kubeadm`](/docs/tasks/tools/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
|
||||
@@ -54,13 +54,13 @@ development and testing purposes.
|
||||
[`minikube`](/docs/tasks/tools/install-minikube/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。
|
||||
|
||||
|
||||
## Dashboard
|
||||
## Dashboard
|
||||
|
||||
<!--
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
|
||||
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
|
||||
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
|
||||
-->
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。
|
||||
|
||||
## Helm
|
||||
|
||||
|
||||
Reference in New Issue
Block a user