From 9365a26dbd06a63fed0a347252609b01beefc224 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 11 Oct 2020 20:04:36 +0800 Subject: [PATCH 01/66] [zh] Translate cloud-controller-manager reference --- .../cloud-controller-manager.md | 892 ++++++++++++++++++ 1 file changed, 892 insertions(+) create mode 100644 content/zh/docs/reference/command-line-tools-reference/cloud-controller-manager.md diff --git a/content/zh/docs/reference/command-line-tools-reference/cloud-controller-manager.md b/content/zh/docs/reference/command-line-tools-reference/cloud-controller-manager.md new file mode 100644 index 0000000000..7dc7a128ee --- /dev/null +++ b/content/zh/docs/reference/command-line-tools-reference/cloud-controller-manager.md @@ -0,0 +1,892 @@ +--- +title: cloud-controller-manager +content_type: tool-reference +weight: 30 +--- + +## {{% heading "synopsis" %}} + + +云控制器管理器是一个守护进程，其中包含与 Kubernetes 一起发布的特定于云平台的控制回路。 + +``` +cloud-controller-manager [flags] +``` + +## {{% heading "options" %}} + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +对来自 Webhook 鉴权组件的“authorized”响应的缓存时长。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header
+ +若为 true，则将文件目录名添加到日志消息头部。 +
--allocate-node-cidrs
+ +是否基于云供应商来为 Pods 分配 CIDR 并进行设置。 +
--alsologtostderr
+ +在将日志输出到文件的同时也输出到标准错误输出。 +
--authentication-kubeconfig string
+ +指向“核心”Kubernetes 服务器的 kubeconfig 文件，其中包含创建 +tokenreviews.authentication.k8s.io 的足够权限。此标志为可选。 +如果取值为空，则所有令牌请求都被视为匿名请求，并且不会在集群中寻找客户端的证书机构。 +
--authentication-skip-lookup
+ +如果为 false，则 authentication-kubeconfig 所指的 kubeconfig +文件会被用来寻找集群中缺失的身份认证配置信息。 +
--authentication-token-webhook-cache-ttl duration     默认值：10s
+ +对来自 Webhook 令牌身份认证组件的响应的缓存时长。 +
--authentication-tolerate-lookup-failure
+ +如果为 true，则在集群中未找到缺失的认证配置信息也不会被认为是致命错误。 +注意，这一设置可能导致身份认证组件将所有请求都视为匿名请求。 +
--authorization-always-allow-paths stringSlice     默认值：[/healthz]
+ +在鉴权期间会忽略的一组 HTTP 路径。这些路径在不与 “核心” Kubernetes +服务器沟通的前提下就会被授权。 +
--authorization-kubeconfig string
+ +指向“核心” Kubernetes 服务器的 kubeconfig 文件，其中包含创建 +subjectaccessreviews.authorization.k8s.io 的足够权限。此标志为可选。 +如果取值为空，则所有未被鉴权组件忽略的请求都会被拒绝。 +
--authorization-webhook-cache-authorized-ttl duration     默认值：10s
+
--authorization-webhook-cache-unauthorized-ttl duration     默认值：10s
+ +对来自 Webhook 鉴权组件的“Unauthorized”响应的缓存时长。 +
--azure-container-registry-config string
+ +包含 Azure 容器仓库配置信息的文件路径。 +
--bind-address ip     默认值：0.0.0.0
+ +在 --secure-port 所给端口上监听时所使用 IP 地址。所关联的网络接口必须从集群中其他部分可达， +且可被命令行和 Web 客户端访问。如果此值为空或者为未设定地址（0.0.0.0 或 ::）， +则所有接口都会被使用。 +
--cert-dir string
+ +TLS 证书所在的目录。如果 --tls-cert-file 和 --tls-private-key-file +都已指定，则此标志值被忽略。 +
--cidr-allocator-type string     默认值："RangeAllocator"
+ +要使用的 CIDR 分配器类型。 +
--client-ca-file string
+ +若此标志被设置，所有能够提供由 client-ca-file 文件中所包含的机构之一签名的 +客户端证书的请求都会通过身份认证，且其身份标识对应客户证书中的 CommonName。 +
--cloud-config string
+ +云供应商配置文件的路径。空字符串表示没有配置文件。 +
--cloud-provider string
+ +云服务的供应商。空字符串表示没有供应商。 +
--cloud-provider-gce-l7lb-src-cidrs cidrs     默认值：130.211.0.0/22,35.191.0.0/16
+ +在 GCE 防火墙上为第七层负载均衡器流量代理和健康检查所打开的 CIDR。 +
--cloud-provider-gce-lb-src-cidrs cidrs     默认值：130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16
+ +在 GCE 防火墙上为第四层负载均衡器流量代理和健康检查所打开的 CIDR。 +
--cluster-cidr string
+ +集群中 Pod 的 CIDR 范围。要求 --allocate-node-cidrs 为 true。 +
--cluster-name string     默认值： "kubernetes"
+ +集群的实例前缀。 +
--concurrent-service-syncs int32     默认值： 1
+ +可并发同步的服务个数。较大数值意味着服务管理的响应能力更高，不过也意味着更多的 +CPU （和网络）压力。 +
--configure-cloud-routes     默认值： true
+ +是否要在云供应商平台上配置由 allocate-node-cidrs 所分配的 CIDRs。 +
--contention-profiling
+ +启用锁竞争分析，前提是 profiling 被弃用。 +
--controller-start-interval duration
+ +启动控制器管理器之间的时间间隔。 +
--controllers stringSlice     默认值：[*]
+ +一组要启用的控制器列表。'*' 意味着要启用所有默认打开的控制器，'foo' +意味着要启用名为 'foo' 的控制器；'-foo' 意味着要禁用名为 'foo' 的控制器。
+控制器全集：cloud-node、cloud-node-lifecycle、 +route、service。 +默认禁用的控制器：<无>。 +
--external-cloud-volume-plugin string
+ +当云驱动被设置为 external 时要使用的插件。可以为空，只有当 cloud-provider 为 +external 时才应设置。当前用来保证内置的云驱动的节点控制器和卷控制器能够正常工作。 +
--feature-gates mapStringBool
+一组 key=value 偶对，描述 alpha/试验性功能的特性门控。可选项包括：
+APIListChunking=true|false (BETA - 默认值=true)
+APIPriorityAndFairness=true|false (ALPHA - 默认值=false)
+APIResponseCompression=true|false (BETA - 默认值=true)
+AllAlpha=true|false (ALPHA - 默认值=false)
+AllBeta=true|false (BETA - 默认值=false)
+AllowInsecureBackendProxy=true|false (BETA - 默认值=true)
+AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
+AppArmor=true|false (BETA - 默认值=true)
+BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
+BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
+CPUManager=true|false (BETA - 默认值=true)
+CRIContainerLogRotation=true|false (BETA - 默认值=true)
+CSIInlineVolume=true|false (BETA - 默认值=true)
+CSIMigration=true|false (BETA - 默认值=true)
+CSIMigrationAWS=true|false (BETA - 默认值=false)
+CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
+CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
+CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationGCE=true|false (BETA - 默认值=false)
+CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationOpenStack=true|false (BETA - 默认值=false)
+CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationvSphere=true|false (BETA - 默认值=false)
+CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
+CSIStorageCapacity=true|false (ALPHA - 默认值=false)
+CSIVolumeFSGroupPolicy=true|false (ALPHA - 默认值=false)
+ConfigurableFSGroupPolicy=true|false (ALPHA - 默认值=false)
+CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
+DefaultPodTopologySpread=true|false (ALPHA - 默认值=false)
+DevicePlugins=true|false (BETA - 默认值=true)
+DisableAcceleratorUsageMetrics=true|false (ALPHA - 默认值=false)
+DynamicKubeletConfig=true|false (BETA - 默认值=true)
+EndpointSlice=true|false (BETA - 默认值=true)
+EndpointSliceProxying=true|false (BETA - 默认值=true)
+EphemeralContainers=true|false (ALPHA - 默认值=false)
+ExpandCSIVolumes=true|false (BETA - 默认值=true)
+ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
+ExpandPersistentVolumes=true|false (BETA - 默认值=true)
+ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
+GenericEphemeralVolume=true|false (ALPHA - 默认值=false)
+HPAScaleToZero=true|false (ALPHA - 默认值=false)
+HugePageStorageMediumSize=true|false (BETA - 默认值=true)
+HyperVContainer=true|false (ALPHA - 默认值=false)
+IPv6DualStack=true|false (ALPHA - 默认值=false)
+ImmutableEphemeralVolumes=true|false (BETA - 默认值=true)
+KubeletPodResources=true|false (BETA - 默认值=true)
+LegacyNodeRoleBehavior=true|false (BETA - 默认值=true)
+LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
+LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
+NodeDisruptionExclusion=true|false (BETA - 默认值=true)
+NonPreemptingPriority=true|false (BETA - 默认值=true)
+PodDisruptionBudget=true|false (BETA - 默认值=true)
+PodOverhead=true|false (BETA - 默认值=true)
+ProcMountType=true|false (ALPHA - 默认值=false)
+QOSReserved=true|false (ALPHA - 默认值=false)
+RemainingItemCount=true|false (BETA - 默认值=true)
+RemoveSelfLink=true|false (ALPHA - 默认值=false)
+RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
+RunAsGroup=true|false (BETA - 默认值=true)
+RuntimeClass=true|false (BETA - 默认值=true)
+SCTPSupport=true|false (BETA - 默认值=true)
+SelectorIndex=true|false (BETA - 默认值=true)
+ServerSideApply=true|false (BETA - 默认值=true)
+ServiceAccountIssuerDiscovery=true|false (ALPHA - 默认值=false)
+ServiceAppProtocol=true|false (BETA - 默认值=true)
+ServiceNodeExclusion=true|false (BETA - 默认值=true)
+ServiceTopology=true|false (ALPHA - 默认值=false)
+SetHostnameAsFQDN=true|false (ALPHA - 默认值=false)
+StartupProbe=true|false (BETA - 默认值=true)
+StorageVersionHash=true|false (BETA - 默认值=true)
+SupportNodePidsLimit=true|false (BETA - 默认值=true)
+SupportPodPidsLimit=true|false (BETA - 默认值=true)
+Sysctls=true|false (BETA - 默认值=true)
+TTLAfterFinished=true|false (ALPHA - 默认值=false)
+TokenRequest=true|false (BETA - 默认值=true)
+TokenRequestProjection=true|false (BETA - 默认值=true)
+TopologyManager=true|false (BETA - 默认值=true)
+ValidateProxyRedirects=true|false (BETA - 默认值=true)
+VolumeSnapshotDataSource=true|false (BETA - 默认值=true)
+WarningHeaders=true|false (BETA - 默认值=true)
+WinDSR=true|false (ALPHA - 默认值=false)
+WinOverlay=true|false (ALPHA - 默认值=false)
+WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) +
-h, --help
+ +cloud-controller-manager 的帮助信息。 +
--http2-max-streams-per-connection int
+ +在 HTTP/2 连接中，服务器为客户端提供的最大流式连接个数。0 意味着使用 Go +语言库中的默认值。 +
--kube-api-burst int32     默认值：30
+ +在与 Kubernetes API 服务器通信时可使用的突发性请求速率。 +
--kube-api-content-type string     默认值："application/vnd.kubernetes.protobuf"
+ +向 API 服务器发送请求时使用的内容类型（Content-Type）。 +
--kube-api-qps float32     默认值：20
+ +与 Kubernetes API 服务器通信时要遵循的 QPS（每秒查询数）约束。 +
--kubeconfig string
+ +指向 kubeconfig 文件的路径；该文件中包含鉴权信息以及主控节点位置信息。 +
--leader-elect     默认值：true
+ +启动领导者选举客户端，并在开始执行主循环之前尝试获得领导者角色。 +在运行多副本组件时启用此标志以达到高可用性。 +
--leader-elect-lease-duration duration     默认值：15s
+ +当观察到领导者需要续约时，当前处于非领导者角色的候选组件要等待这里设置的时长， +之后才能尝试去获得曾经处于领导者角色但未能成功续约的席位。 +此标志值本质上是当前领导者在被其他候选者替代之前可以停止的最长时长。 +只有启用了领导者选举时此标志值才有意义。 +
--leader-elect-renew-deadline duration     默认值： 10s
+ +当前领导者身份的组件在停止领导角色前需要对领导者席位续约，此标志值设置续约操作时间间隔。 +此值必须小于等于租期时长。只有启用了领导者选举时此标志值才有意义。 +
--leader-elect-resource-lock string     默认值："endpointsleases"
+ +在领导者选举期间用来锁定的资源对象类型。支持的选项包括 +'endpoints'、'configmaps'、'leases'、 +'endpointsleases' 和 'configmapsleases'。 +
--leader-elect-resource-name string     默认值："cloud-controller-manager"
+ +在领导者选举期间用来锁定的资源对象名称。 +
--leader-elect-resource-namespace string     默认值："kube-system"
+ +在领导者选举期间用来锁定的资源对象的名字空间。 +
--leader-elect-retry-period duration     默认值：2s
+ +客户端在尝试抢占或者续约领导者席位时连续两次尝试之间的时间间隔。 +仅在启用了领导者选举时可用。 +
--log-backtrace-at traceLocation     默认值：:0
+ +当日志机制执行到文件行 file:N 时打印调用堆栈。 +
--log-dir string
+ +若此标志值非空，则将日志写入到所指定的目录中。 +
--log-file string
+ +当此标志值非空时，表示使用该字符串值作为日志文件名。 +
--log-file-max-size uint     默认值：1800
+ +定义日志文件可增长到的最大尺寸。单位为 MB 字节。如果此值为 +0，则不限制文件的最大尺寸。 +
--log-flush-frequency duration     默认值：5s
+ +相邻两次日志清洗操作之间的最大间隔秒数。 +
--logtostderr     默认值：true
+ +将日支输出到标准错误输出而不是日志文件中。 +
--master string
+ +Kubernetes API 服务器的地址（覆盖 kubeconfig 文件中的设置值。 +
--min-resync-period duration     默认值：12h0m0s
+ +反射器（Reflectors）的再同步周期将介于 min-resync-period 和 +2*min-resync-period 之间。 +
--node-monitor-period duration     默认值：5s
+ +在节点控制器中对节点状态进行同步的周期。 +
--node-status-update-frequency duration     默认值：5m0s
+ +设置控制器更新节点状态的频率。 +
--permit-port-sharing
+ +此标志值为 true 时，在绑定端口时将使用 SO_REUSEPORT +标志，允许多个实例绑定到同一地址和端口。默认值为 false。 +
--profiling     默认值：true
+ +通过 Web 接口 host:port/debug/pprof/ 提供性能观测。 +
--requestheader-allowed-names stringSlice
+ +客户证书中 CommonName 的列表，用于允许通过 --requestheader-allowed-names +标识所设置的头部中提供用户名。此标志值为空时，通过 +--requestheader-client-ca-file 中的机构验证的所有客户端证书都可使用。 +
--requestheader-client-ca-file string
+ +用来对所收到的请求中客户端证书进行验证的根证书包。在此验证之前，不能信任 +--requestheader-username-headers 所指定的头部中的用户名。 +警告：此操作一般不会理会是否已经对所收到的请求执行了鉴权。 +
--requestheader-extra-headers-prefix stringSlice     默认值：[x-remote-extra-]
+ +要检查的请求头部前缀列表。建议使用 X-Remote-Extra-。 +
--requestheader-group-headers stringSlice     默认值：[x-remote-group]
+ +为获取组名而要检查的请求头部列表。建议使用 X-Remote-Group。 +
--requestheader-username-headers stringSlice     默认值：[x-remote-user]
+ +为获取用户名而要检查的请求头部列表。常用的是 X-Remote-User。 +
--route-reconciliation-period duration     默认值：10s
+ +对云供应商为节点所创建的路由进行协商的周期。 +
--secure-port int     默认值：10258
+ +此标志值给出的是一个端口号，云控制器管理器在此端口上提供 HTTPS 服务以供身份认证和鉴权。 +如果此值为 0，则云控制器管理器不提供 HTTPS 服务。 +
--skip-headers
+ +此值为 true 时，不在日志消息中添加头部前缀。 +
--skip-log-headers
+ +此标志值为 true 时，不在打开日志文件时使用头部。 +
--stderrthreshold severity     默认值：2
+ +处于或者高于此阈值的日志消息会被输出到标准错误输出。 +
--tls-cert-file string
+ +为 HTTPS 通信所给出的默认 x509 证书文件。如果有机构证书，要串接在服务器证书之后。 +当启用 HTTPS 服务时，如果 --tls-cert-file 和 --tls-private-key-file 未设置， +则组件会自动生成一个自签名的证书和密钥，用于公开的网络地址，并将其保存在 +--cert-dir 所指定的目录下。 +
--tls-cipher-suites stringSlice
+ +为服务器设定的逗号分隔的加密包列表。如果忽略此标志，则使用默认的 Go 语言加密包。
+优选的设置：TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
+不安全的配置值：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA. +
--tls-min-version string
+ +所支持的 TLS 最低版本。可选值为：VersionTLS10、VersionTLS11、 +VersionTLS12、VersionTLS13。 +
--tls-private-key-file string
+ +包含与 --tls-cert-file 所设定证书匹配的默认 x509 私钥文件。 +
--tls-sni-cert-key namedCertKey     默认值：[]
+ +一组 x509 证书和私钥文件路径偶对。可选地，可以在路径名之后添加域名模式的后缀， +每个后缀都是一个全限定的域名，也可带有前置的通配符部分。 +域名模式也允许使用 IP 地址，不过只有 API 服务器可以在客户请求的 IP 地址上访问 +时才可使用 IP 地址。如果未指定域名模式，则从证书中抽取名字。 +非通配符的匹配要优先于通配符匹配；显式的域名模式匹配也优先于抽取名字匹配。 +对于多个密钥/证书偶对，可多次使用 --tls-sni-cert-key 标志。 +例如："example.crt,example.key" 或 +"foo.crt,foo.key:*.foo.com,foo.com"。 +
--use-service-account-credentials
+ +此标志值为 true 时，为每个控制器使用独立的服务账号凭据。 +
-v, --v Level
+ +日志级别详细程度值。 +
--version version[=true]
+ +打印版本信息并退出。 +
--vmodule moduleSpec
+ +逗号分隔的 pattern=N 字符串列表，用来基于文件来执行日志操作。 +
+ + + From 92f837d4b2428052121e1b01cf498778a8069491 Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Wed, 7 Oct 2020 17:16:56 -0400 Subject: [PATCH 02/66] Clarify external kubelet server approver requirements --- .../kubelet-tls-bootstrapping.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index 0daa490276..04aae60fa3 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -415,6 +415,17 @@ approve node _serving_ certificates for [security reasons](https://github.com/kubernetes/community/pull/1982). To use `RotateKubeletServerCertificate` operators need to run a custom approving controller, or manually approve the serving certificate requests. + +A deployment-specific approval process for kubelet serving certificates should typically only approve CSRs which: + +1. are requested by nodes (ensure the `spec.username` field is of the form + `system:node:` and `spec.groups` contains `system:nodes`) +2. request usages for a serving certificate (ensure `spec.usages` contains `server auth`, + optionally contains `digital signature` and `key encipherment`, and contains no other usages) +3. only have IP and DNS subjectAltNames that belong to the requesting node, + and have no URI and Email subjectAltNames (parse the x509 Certificate Signing Request + in `spec.request` to verify `subjectAltNames`) + {{< /note >}} ## Other authenticating components From 4683be51f3c8948f68cd5f5f42df2518580a6496 Mon Sep 17 00:00:00 2001 From: colin Date: Fri, 23 Oct 2020 10:24:28 +0800 Subject: [PATCH 03/66] Update certificates.md --- content/zh/docs/setup/best-practices/certificates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/setup/best-practices/certificates.md b/content/zh/docs/setup/best-practices/certificates.md index cead60c2a0..dcb331fa93 100644 --- a/content/zh/docs/setup/best-practices/certificates.md +++ b/content/zh/docs/setup/best-practices/certificates.md @@ -54,8 +54,8 @@ Kubernetes 需要 PKI 才能执行以下操作： * 集群管理员的客户端证书，用于 API 服务器身份认证 * API 服务器的客户端证书，用于和 Kubelet 的会话 * API 服务器的客户端证书，用于和 etcd 的会话 -* 控制器管理器的客户端证书/kubeconfig，用于和 API server 的会话 -* 调度器的客户端证书/kubeconfig，用于和 API server 的会话 +* 控制器管理器的客户端证书/kubeconfig，用于和 API 服务器的会话 +* 调度器的客户端证书/kubeconfig，用于和 API 服务器的会话 * [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书 -### Static Password File - -通过向 API 服务器传递 `--basic-auth-file=SOMEFILE` 选项可以启用基本的 -身份认证。目前，基本身份认证所涉及的凭据信息会长期有效，并且在不重启 API -服务器的情况下无法改变用户的密码。 -要注意的是，对基本身份认证的支持目前仅是出于方便性考虑。 -与此同时我们正在增强前述的、更为安全的模式的易用性。 - - -基本身份认证数据文件是一个 CSV 文件，包含至少 3 列：密码、用户名和用户 ID。 -在 Kuernetes 1.6 及后续版本中，你可以指定一个可选的第 4 列，在其中给出用逗号 -分隔的用户组名。如果用户组名不止一个，你必须将第 4 列的值用双引号括起来。 -参见下面的例子： - -```conf -password,user,uid,"group1,group2,group3" -``` - - -当在 HTTP 客户端使用基本身份认证机制时，API 服务器会期望看到名为 -`Authorization` 的 HTTP 头部，其值形如 `Basic USER:PASSWORD的Base64编码字符串` - ### 服务账号令牌 {#service-account-tokens} @@ -555,7 +516,33 @@ is included in a request. 中的 `id_token`（而非 `access_token`）作为持有者令牌。 关于如何在请求中设置令牌，可参见[前文](#putting-a-bearer-token-in-a-request)。 -![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg) +{{< mermaid >}} +sequenceDiagram + participant user as 用户 + participant idp as 身份提供者 + participant kube as Kubectl + participant api as API 服务器 + + user ->> idp: 1. 登录到 IdP + activate idp + idp -->> user: 2. 提供 access_token,
id_token, 和 refresh_token + deactivate idp + activate user + user ->> kube: 3. 调用 Kubectl 并
设置 --token 为 id_token
或者将令牌添加到 .kube/config + deactivate user + activate kube + kube ->> api: 4. Authorization: Bearer... + deactivate kube + activate api + api ->> api: 5. JWT 签名合法么？ + api ->> api: 6. JWT 是否已过期？(iat+exp) + api ->> api: 7. 用户被授权了么？ + api -->> kube: 8. 已授权：执行
操作并返回结果 + deactivate api + activate kube + kube --x user: 9. 返回结果 + deactivate kube +{{< /mermaid >}} 关于上述第三条需求，即要求具备 CA 签名的证书，有一些额外的注意事项。 @@ -691,8 +678,11 @@ Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSe 你必须对身份服务的 Web 服务器证书进行签名，签名所用证书的 `CA` 标志要设置为 `TRUE`，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证 标准方面有非常严格的要求。如果你手头没有现成的 CA 证书，可以使用 CoreOS -团队所开发的[这个脚本](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)来创建一个简单的 CA 和被签了名的证书与密钥对。 -或者你也可以使用[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)，生成一个合法期更长、密钥尺寸更大的 SHA256 证书。 +团队所开发的[这个脚本](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) +来创建一个简单的 CA 和被签了名的证书与密钥对。 +或者你也可以使用 +[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)， +生成一个合法期更长、密钥尺寸更大的 SHA256 证书。 -title: 授权概述 +title: Authorization Overview content_type: concept weight: 60 ---- +--> - -了解有关 Kubernetes 授权的更多信息，包括使用支持的授权模块创建策略的详细信息。 + +了解有关 Kubernetes 鉴权的更多信息，包括使用支持的鉴权模块创建策略的详细信息。 - +the Kubernetes API. +--> +在 Kubernetes 中，你必须在鉴权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息， +请参阅[访问控制概述](/zh/docs/concepts/security/controlling-access/). -在 Kubernetes 中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息， -请参阅 [访问控制概述](/zh/docs/reference/access-authn-authz/controlling-access/). - -Kubernetes 期望 REST API 请求中常见的属性。 -这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统， +Kubernetes 期望请求中存在 REST API 常见的属性。 +这意味着 Kubernetes 鉴权适用于现有的组织范围或云提供商范围的访问控制系统， 除了 Kubernetes API 之外，它还可以处理其他 API。 - - +the request, then the request is denied. A deny returns an HTTP status code 403. +--> ## 确定是允许还是拒绝请求 -Kubernetes 使用 API ​​服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。 -一个 API 请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。 -（尽管 Kubernetes 使用 API ​​服务器，但是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。） +Kubernetes 使用 API 服务器对 API 请求进行鉴权。 +它根据所有策略评估所有请求属性来决定允许或拒绝请求。 +一个 API 请求的所有部分都必须被某些策略允许才能继续。 +这意味着默认情况下拒绝权限。 -配置多个授权模块时，将按顺序检查每个模块。 -如果任何授权模块批准或拒绝请求，则立即返回该决定，并且不会与其他授权模块协商。 -如果所有模块对请求没有意见，则拒绝该请求。一个拒绝响应返回 HTTP 状态代码 403 。 +（尽管 Kubernetes 使用 API 服务器，但是依赖于特定对象种类的特定字段的访问控制 +和策略由准入控制器处理。） + +当系统配置了多个鉴权模块时，Kubernetes 将按顺序使用每个模块。 +如果任何鉴权模块批准或拒绝请求，则立即返回该决定，并且不会与其他鉴权模块协商。 +如果所有模块对请求没有意见，则拒绝该请求。 +被拒绝响应返回 HTTP 状态代码 403。 +## 审查你的请求属性 -## 审查您的请求属性 Kubernetes 仅审查以下 API 请求属性： - * **user** - 身份验证期间提供的 `user` 字符串。 - * **group** - 经过身份验证的用户所属的组名列表。 - * **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。 - * **API** - 指示请求是否针对 API 资源。 - * **Request path** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。 - * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/zh/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。 - * **HTTP request verb** - HTTP 动词 `get`，`post`，`put` 和 `delete` 用于非资源请求。 - * **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用 `get`，`update`，`patch` 和 `delete` 动词的资源请求，您必须提供资源名称。 - * **Subresource** - 正在访问的子资源（仅限资源请求）。 - * **Namespace** - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。 - * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/concepts/overview/kubernetes-api/)。 +* **用户** - 身份验证期间提供的 `user` 字符串。 +* **组** - 经过身份验证的用户所属的组名列表。 +* **额外信息** - 由身份验证层提供的任意字符串键到字符串值的映射。 +* **API** - 指示请求是否针对 API 资源。 +* **请求路径** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。 +* **API 请求动词** - API 动词 `get`、`list`、`create`、`update`、`patch`、`watch`、 + `proxy`、`redirect`、`delete` 和 `deletecollection` 用于资源请求。 + 要确定资源 API 端点的请求动词，请参阅 + [确定请求动词](#determine-the-request-verb)。 +* **HTTP 请求动词** - HTTP 动词 `get`、`post`、`put` 和 `delete` 用于非资源请求。 +* **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求）- + 对于使用 `get`、`update`、`patch` 和 `delete` 动词的资源请求，你必须提供资源名称。 +* **子资源** - 正在访问的子资源（仅限资源请求）。 +* **名字空间** - 正在访问的对象的名称空间（仅适用于名字空间资源请求）。 +* **API 组** - 正在访问的 {{< glossary_tooltip text="API 组" term_id="api-group" >}} + （仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/reference/using-api/#api-groups)。 +## 确定请求动词 {#determine-the-request-verb} + +**非资源请求** + +对于 `/api/v1/...` 或 `/apis///...` 之外的端点的请求被 +视为“非资源请求（Non-Resource Requests）”，并使用该请求的 HTTP 方法的 +小写形式作为其请求动词。 +例如，对 `/api` 或 `/healthz` 这类端点的 `GET` 请求将使用 `get` 作为其动词。 + + +**资源请求** +要确定对资源 API 端点的请求动词，需要查看所使用的 HTTP 动词以及该请求是针对 +单个资源还是一组资源： + + - -## 确定请求动词 - -要确定资源 API 端点的请求谓词，请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用： - -HTTP 动词 | request 动词 +HTTP 动词 | 请求动词 ----------|--------------- POST | create -GET, HEAD | get (单个资源)，list (资源集合) +GET, HEAD | get （针对单个资源）、list（针对集合） PUT | update PATCH | patch -DELETE | delete (单个资源)，deletecollection (资源集合) - -Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如： - -* [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。 -* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。 -* [认证](/zh/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。 +DELETE | delete（针对单个资源）、deletecollection（针对集合） +Kubernetes 有时使用专门的动词以对额外的权限进行鉴权。例如： + +* [PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/) + * `policy` API 组中 `podsecuritypolicies` 资源使用 `use` 动词 +* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) + * 对 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` + 和 `escalate` 动词 +* [身份认证](/zh/docs/reference/access-authn-authz/authentication/) + * 对核心 API 组中 `users`、`groups` 和 `serviceaccounts` 以及 `authentication.k8s.io` + API 组中的 `userextras` 所使用的 `impersonate` 动词。 + + +--> +## 鉴权模块 {#authorization-modules} -## 授权模块 - * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/zh/docs/reference/access-authn-authz/node/). - * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。 - * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。 - * 当指定的 RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。 - * 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 apiserver 。 - * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。 +* **Node** - 一个专用鉴权组件，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。 + 了解有关使用节点鉴权模式的更多信息，请参阅[节点鉴权](/zh/docs/reference/access-authn-authz/node/)。 +* **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合 + 在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、 + 对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 + [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。 +* **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对 + 计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力， + 例如查看、创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 + [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。 + * 被启用之后，RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来 + 驱动鉴权决策，从而允许管理员通过 Kubernetes API 动态配置权限策略。 + * 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 API 服务器。 +* **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST； + 通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时 + 将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 + [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。 +#### 检查 API 访问 {#checking-api-access} -#### 检查 API 访问 +`kubectl` 提供 `auth can-i` 子命令，用于快速查询 API 鉴权。 +该命令使用 `SelfSubjectAccessReview` API 来确定当前用户是否可以执行给定操作， +无论使用何种鉴权模式该命令都可以工作。 -`kubectl` 提供 `auth can-i` 子命令，用于快速查询 API 授权层。 -该命令使用 `SelfSubjectAccessReview` API 来确定当前用户是否可以执行给定操作，并且无论使用何种授权模式都可以工作。 - -```bash -$ kubectl auth can-i create deployments --namespace dev +```shell +kubectl auth can-i create deployments --namespace dev +``` +``` yes -$ kubectl auth can-i create deployments --namespace prod +``` + +```shell +kubectl auth can-i create deployments --namespace prod +``` +``` no ``` + -管理员可以将此与[用户模拟](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。 +管理员可以将此与 +[用户扮演](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation) +结合使用，以确定其他用户可以执行的操作。 ```bash -$ kubectl auth can-i list secrets --namespace dev --as dave +kubectl auth can-i list secrets --namespace dev --as dave +``` +``` no ``` + +`SelfSubjectAccessReview` 是 `authorization.k8s.io` API 组的一部分，它将 API +服务器鉴权公开给外部服务。该组中的其他资源包括： -`SelfSubjectAccessReview` 是 `authorization.k8s.io` API 组的一部分，它将 API 服务器授权公开给外部服务。 -该组中的其他资源包括： +* `SubjectAccessReview` - 对任意用户的访问进行评估，而不仅仅是当前用户。 + 当鉴权决策被委派给 API 服务器时很有用。例如，kubelet 和扩展 API 服务器使用 + 它来确定用户对自己的 API 的访问权限。 +* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的 + 名字空间。 +* `SelfSubjectRulesReview` - 返回用户可在名字空间内执行的操作集的审阅。 + 用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。 -* `SubjectAccessReview` - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给 API 服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。 -* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的命名空间。 -* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。 - -可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应 “status” 字段是查询的结果。 +可以通过创建普通的 Kubernetes 资源来查询这些 API，其中返回对象的响应 "status" +字段是查询的结果。 ```bash -$ kubectl create -f - -o yaml << EOF +kubectl create -f - -o yaml << EOF apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview spec: @@ -212,7 +287,14 @@ spec: verb: create namespace: dev EOF +``` + +生成的 `SelfSubjectAccessReview` 为： + +```yaml apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview metadata: @@ -235,32 +317,39 @@ You must include a flag in your policy to indicate which authorization module your policies include: The following flags can be used: +--> +## 为你的鉴权模块设置参数 +你必须在策略中包含一个参数标志，以指明你的策略包含哪个鉴权模块： + +可以使用的参数有： + + +* `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许你 + 使用本地文件配置策略。 +* `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许你使用 + Kubernetes API 创建和存储策略。 +* `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许你使用远程 + REST 端点管理鉴权。 +* `--authorization-mode=Node` 节点鉴权是一种特殊用途的鉴权模式，专门对 + kubelet 发出的 API 请求执行鉴权。 +* `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。 +* `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在你不需要 API 请求 + 的鉴权时才使用此标志。 + - -## 为您的授权模块应用参数 - -您必须在策略中包含一个参数标志，以指明您的策略包含哪个授权模块： - -可以使用以下参数： - - * `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许您使用本地文件配置策略。 - * `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许您使用 Kubernetes API 创建和存储策略。 - * `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许您使用远程 REST 端点管理授权。 - * `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的 API 请求。 - * `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。 - * `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在您不需要 API 请求的授权时才使用此标志。 - -您可以选择多个授权模块。模块按顺序检查，以便较早的模块具有更高的优先级来允许或拒绝请求。 +你可以选择多个鉴权模块。模块按顺序检查，以便较靠前的模块具有更高的优先级来允许 +或拒绝请求。 -## 通过 Pod 创建升级权限 +## 通过创建 Pod 提升权限 -能够在命名空间中创建 Pod 的用户可能会升级其在该命名空间内的权限。 -他们可以创建在该命名空间内访问其权限的 Pod 。 -他们可以创建用户无法自己读取 secret 的 Pod ，或者在具有不同/更高权限的服务帐户下运行的 Pod 。 +能够在名字空间中创建 Pod 的用户可能会提升其在该名字空间内的权限。 +他们可以创建在该名字空间内访问其权限的 Pod。 +他们可以创建 Pod 访问用户自己无法读取的 Secret，或者在具有不同/更高权限的 +服务帐户下运行的 Pod 。 {{< caution >}} -**注意：** 系统管理员在授予对 Pod 创建的访问权限时要小心。 -授予在命名空间中创建 Pod（或创建 Pod 的控制器）的权限的用户可以： -读取命名空间中的所有 secret；读取命名空间中的所有 ConfigMap； -并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。 -无论采用何种授权方式，这都适用。 +系统管理员在授予对 Pod 创建的访问权限时要小心。 +被授予在名字空间中创建 Pod（或创建 Pod 的控制器）的权限的用户可以： +读取名字空间中的所有 Secret；读取名字空间中的所有 ConfigMap； +并模拟名字空间中的任意服务账号并执行账号可以执行的任何操作。 +无论采用何种鉴权方式，这都适用。 {{< /caution >}} - ## {{% heading "whatsnext" %}} -* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)。 -* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 +* 要了解有关身份验证的更多信息，请参阅 + [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) + 中的 **身份验证** 部分。 +* 要了解有关准入控制的更多信息，请参阅 + [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 + diff --git a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md index c36f1f9bba..23538c8787 100644 --- a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -1,107 +1,238 @@ --- -approvers: -- jbeda title: 使用启动引导令牌（Bootstrap Tokens）认证 +weight: 20 --- -{{< toc >}} + -## 概述 + -启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。 -它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)，但是也可以被用在其他的案例中以便用户在 -不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 [Kubelet TLS -Bootstrapping](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统进行工作。 +{{< feature-state for_k8s_version="v1.18" state="stable" >}} -启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于 -`kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。 -控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。在节点发现的过程中 Kubernetes 会使用特殊的 ConfigMap 对象。 -控制器管理器中的 BootstrapSigner 控制器也会使用启动引导令牌为这类对象生成签名信息。 + +启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群 +或者在现有集群中添加新节点时使用的。 +它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)， +但是也可以被用在其他的案例中以便用户在不使用 `kubeadm` 的情况下启动集群。 +它也被设计成可以通过 RBAC 策略，结合 +[Kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +系统进行工作。 -目前，启动引导令牌处于 **alpha** 阶段，但是预期也不会有大的突破性变化。 + + +启动引导令牌被定义成一个特定类型的 Secret （`bootstrap.kubernetes.io/token`）， +并存在于 `kube-system` 名字空间中。 +这些 Secret 会被 API 服务器上的启动引导认证组件（Bootstrap Authenticator）读取。 +控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。 +这些令牌也被用来在节点发现的过程中会使用的一个特殊的 ConfigMap 对象。 +BootstrapSigner 控制器也会使用这一 ConfigMap。 + + ## 令牌格式 启动引导令牌使用 `abcdef.0123456789abcdef` 的形式。 更加规范地说，它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。 -令牌的第一部分是 "Token ID" ，它是公共信息。用于引用某个令牌，并确保不会泄露认证所使用的秘密信息。 -第二部分是“令牌秘密（Token Secret）”，它应该被共享给收信的第三方。 +令牌的第一部分是 "Token ID"，它是一种公开信息，用于引用令牌并确保不会 +泄露认证所使用的秘密信息。 +第二部分是"令牌秘密（Token Secret）"，它应该被共享给受信的第三方。 ## 启用启动引导令牌 -所有与启动引导令牌相关的特性在 Kubernetes v1.6 版本中默认都是禁用的。 + +## 启用启动引导令牌身份认证 {#enabling-bootstrap-token-authentication} -HTTPS 调用中的令牌是这样使用的： +启动引导令牌认证组件可以通过 API 服务器上的如下标志启用： + +``` +--enable-bootstrap-token-auth +``` + + +启动引导令牌被启用后，可以作为持有者令牌的凭据，用于 API 服务器请求的身份认证。 ```http Authorization: Bearer 07401b.f395accd246ae52d ``` + +令牌认证为用户名 `system:bootstrap:` 并且是组 `system:bootstrappers` +的成员。额外的组信息可以通过令牌的 Secret 来设置。 -每个合法的令牌背后对应着 `kube-system` 命名空间中的某个 Secret 对象。 -你可以从 [这里](https://git.k8s.io/community/contributors/design-proposals/bootstrap-discovery.md) 找到完整设计文档。 +过期的令牌可以通过启用控制器管理器中的 `tokencleaner` 控制器来删除。 -这是 secret 看起来的样子。注意，`base64(string)` 表示应该通过 base64 对值进行编码。 -这里使用的是未解码的版本以便于阅读。 + +## 启动引导令牌的 Secret 格式 {#bootstrap-token-secret-format} + +每个合法的令牌背后对应着 `kube-system` 名字空间中的某个 Secret 对象。 +你可以从 +[这里](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md). +找到完整设计文档。 + +这是 Secret 看起来的样子。 ```yaml apiVersion: v1 kind: Secret metadata: + # name 必须是 "bootstrap-token-" 格式的 name: bootstrap-token-07401b namespace: kube-system + +# type 必须是 'bootstrap.kubernetes.io/token' type: bootstrap.kubernetes.io/token -data: - description: base64(The default bootstrap token generated by 'kubeadm init'.) - token-id: base64(07401b) +stringData: + # 供人阅读的描述，可选。 + description: "The default bootstrap token generated by 'kubeadm init'." + + # 令牌 ID 和秘密信息，必需。 + token-id: 07401b token-secret: base64(f395accd246ae52d) - expiration: base64(2017-03-10T03:22:11Z) - usage-bootstrap-authentication: base64(true) - usage-bootstrap-signing: base64(true) + + # 可选的过期时间字段 + expiration: "2017-03-10T03:22:11Z" + # 允许的用法 + usage-bootstrap-authentication: "true" + usage-bootstrap-signing: "true" + + # 令牌要认证为的额外组，必须以 "system:bootstrappers:" 开头 + auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress ``` -secret 的类型必须是 `bootstrap.kubernetes.io/token` ，而且名字必须是 `bootstrap-token-`。 -`description` 是人类可读的描述，而不应该是机器可读的信息。令牌 ID 和 Secret 是包含在数据字典中的。 + +Secret 的类型必须是 `bootstrap.kubernetes.io/token`，而且名字必须是 `bootstrap-token-`。 +令牌必须存在于 `kube-system` 名字空间中。 -`usage-bootstrap-authentication` 表示令牌可以用于 API 服务器的认证。认证器会以 -`system:bootstrap:` 认证。它被包含在 `system:bootstrappers` 组中。 -命名和组是故意受限制的，以防止用户在启动引导后再使用这些令牌。 +`usage-bootstrap-*` 成员表明这个 Secret 的用途。启用时，值必须设置为 `true`。 -`usage-bootstrap-signing` 表示令牌应该被用于 `cluster-info` ConfigMap 的签名，就像下面描述的那样。 + +* `usage-bootstrap-authentication` 表示令牌可以作为持有者令牌用于 API 服务器的身份认证。 +* `usage-bootstrap-signing` 表示令牌可被用于 `cluster-info` ConfigMap 的签名， + 就像下面描述的那样。 -`expiration` 数据成员显示了令牌在失效后到现在的时间。这是遵循 RFC3339 进行编码的 UTC 时间。 -TokenCleaner 控制器会删除过期的令牌。 + +`expiration` 字段控制令牌的失效期。过期的令牌在用于身份认证时会被拒绝，在用于 +ConfigMap 签名时会被忽略。 +过期时间值是遵循 RFC3339 进行编码的 UTC 时间。 +启用 TokenCleaner 控制器会自动删除过期的令牌。 -## 使用 `kubeadm` 管理令牌 + +## 使用 `kubeadm` 管理令牌 {#token-management-with-kubeadm} -* `kubeadm token list` 列举了令牌，同时显示了它们的过期时间和用途。 -* `kubeadm token create` 创建一个新令牌。 - * `--description` 设置新令牌的描述。 - * `--ttl duration` 设置令牌从“现在”起到过期时间的差值。 - 默认是 0 ，也就是不过期。 - * `--usages` 设置令牌被使用的方式。默认是 `signing,authentication`。用途在上面已经描述。 -* `kubeadm token delete |.` 删除令牌。 - 令牌可以只用 ID 来确认，也可以用整个令牌的值。如果只用 ID 的情况下，密文不匹配的令牌也会被删除。 +你可以使用 `kubeadm` 工具管理运行中集群上的令牌。 +参见 [kubeadm token 文档](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) +以了解详细信息。 -### ConfigMap 签名 + +### ConfigMap 签名 {#configmap-signing} + +除了身份认证，令牌还可以用于签名 ConfigMap。 +这一用法发生在集群启动过程的早期，在客户端信任 API 服务器之前。 +被签名的 ConfigMap 可以被共享令牌完成身份认证。 + +通过在控制器管理器上启用 `bootstrapsigner` 控制器可以启用 ConfigMap 签名特性。 + +``` +--controllers=*,bootstrapsigner +``` + + +被签名的 ConfigMap 是 `kube-public` 名字空间中的 `cluster-info`。 典型的工作流中，客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。 -通过 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。 +通过检查 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。 ConfigMap 会是这个样子的： @@ -117,7 +248,7 @@ data: apiVersion: v1 clusters: - cluster: - certificate-authority-data: + certificate-authority-data: <非常长的证书数据> server: https://10.138.0.2:6443 name: "" contexts: [] @@ -127,10 +258,46 @@ data: users: [] ``` + ConfigMap 的 `kubeconfig` 成员是一个填好了集群信息的配置文件。 这里主要交换的信息是 `certificate-authority-data`。在将来可能会有扩展。 -签名是一个 JWS 签名，使用了 "detached" 模式。为了检验签名，用户应该按照 JWS 规则 -（base64 编码而忽略结尾的 `=`）对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间 -，用于形成一个完整的 JWS。可以使用令牌的完整信息（比如 `07401b.f395accd246ae52d`）作为共享密钥， -通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 _必须_ 确保使用了 HS256。 + +签名是一个使用 "detached" 模式生成的 JWS 签名。 +为了检验签名，用户应该按照 JWS 规则（base64 编码且丢掉结尾的 `=`）对 +`kubeconfig` 的载荷进行编码。完成编码的载荷会被插入到两个句点中间，形成完整的 +JWS。你可以使用完整的令牌（比如 `07401b.f395accd246ae52d`）作为共享密钥， +通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 +用户 _必须_ 确保使用了 HS256。 + +{{< warning >}} + +任何拥有了启动引导令牌的主体都可以为该令牌生成一个合法的签名。 +当使用 ConfigMap 签名时，非常不建议针对很多客户使用相同的令牌，因为某个被攻击的 +客户可能对另一个一来签名来开启 TLS 信任的客户发起中间人攻击。 +{{< /warning >}} + + +参考 [kubeadm 实现细节](/zh/docs/reference/setup-tools/kubeadm/implementation-details/) +了解更多信息。 + diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md index cb559d0505..82b37c9043 100644 --- a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md @@ -1,76 +1,209 @@ --- -approvers: +title: 管理 Service Accounts +content_type: concept +weight: 50 +--- + + -*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/zh/docs/tasks/configure-pod-container/configure-service-account/)中的信息。* + + +这是一篇针对服务账号的集群管理员指南。你应该熟悉 +[配置 Kubernetes 服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)。 -## 用户账户与服务账户 +对鉴权和用户账号的支持已在规划中，当前并不完备。 +为了更好地描述服务账号，有时这些不完善的特性也会被提及。 -Kubernetes 区分用户账户和服务账户的概念主要基于以下原因： + - - 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。 - - 用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离， - 服务账户是 namespace 隔离的。 - - 通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。 - - 对人员和服务账户审计所考虑的因素可能不同。 - - 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建，并且有 namespace 级别的名称，这种配置是很轻量的。 + +## 用户账号与服务账号 {#user-accounts-versus-service-accounts} -三个独立组件协作完成服务账户相关的自动化 : +Kubernetes 区分用户账号和服务账号的概念，主要基于以下原因： - - 服务账户准入控制器（Service account admission controller） - - Token 控制器（Token controller） - - 服务账户控制器（Service account controller） + +- 用户账号是针对人而言的。 服务账号是针对运行在 Pod 中的进程而言的。 +- 用户账号是全局性的。其名称跨集群中名字空间唯一的。服务账号是名字空间作用域的。 +- 通常情况下，集群的用户账号可能会从企业数据库进行同步，其创建需要特殊权限， + 并且涉及到复杂的业务流程。 + 服务账号创建有意做得更轻量，允许集群用户为了具体的任务创建服务账号 + 以遵从权限最小化原则。 +- 对人员和服务账号审计所考虑的因素可能不同。 +- 针对复杂系统的配置包可能包含系统组件相关的各种服务账号的定义。因为服务账号 + 的创建约束不多并且有名字空间域的名称，这种配置是很轻量的。 -### 服务账户准入控制器 + +## 服务账号的自动化 {#service-account-automation} -### Token 管理器 +三个独立组件协作完成服务账号相关的自动化： -Token 管理器是 controller-manager 的一部分。 以异步的形式工作： +- `ServiceAccount` 准入控制器 +- Token 控制器 +- `ServiceAccount` 控制器 -- 检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。 -- 检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。 -- 检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。 -- 检测 Secret 的删除，如有需要，从相应的服务账户中移除引用。 + +### ServiceAccount 准入控制器 {#serviceaccount-admission-controller} -#### 创建额外的 API tokens +对 Pod 的改动通过一个被称为 +[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +的插件来实现。它是 API 服务器的一部分。 +当 Pod 被创建或更新时，它会同步地修改 Pod。 +如果该插件处于激活状态（在大多数发行版中都是默认激活的），当 Pod 被创建 +或更新时它会进行以下操作： -控制器中有专门的循环来保证每个服务账户中都存在 API token 对应的 Secret。 当需要为服务账户创建额外的 API token 时，创建一个类型为 `ServiceAccountToken` 的 Secret，并在 annotation 中引用服务账户，控制器会生成 token 并更新 : + +1. 如果该 Pod 没有设置 `serviceAccountName`，将其 `serviceAccountName` 设为 + `default`。 +1. 保证 Pod 所引用的 `serviceAccountName` 确实存在，否则拒绝该 Pod。 +1. 如果 Pod 不包含 `imagePullSecrets` 设置，将 `serviceAccountName` 所引用 + 的服务账号中的 `imagePullSecrets` 信息添加到 Pod 中。 +1. 如果服务账号的 `automountServiceAccountToken` 或 Pod 的 + `automountServiceAccountToken` 都为设置为 `false`，则为 Pod 创建一个 + `volume`，在其中包含用来访问 API 的令牌。 +1. 如果前一步中为服务账号令牌创建了卷，则为 Pod 中的每个容器添加一个 + `volumeSource`，挂载在其 `/var/run/secrets/kubernetes.io/serviceaccount` + 目录下。 -secret.json: + +当 `BoundServiceAccountTokenVolume` 特性门控被启用时，你可以将服务账号卷迁移到投射卷。 +服务账号令牌会在 1 小时后或者 Pod 被删除之后过期。 +更多信息可参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/)。 -```json -{ - "kind": "Secret", - "apiVersion": "v1", - "metadata": { - "name": "mysecretname", - "annotations": { - "kubernetes.io/service-account.name": "myserviceaccount" - } - }, - "type": "kubernetes.io/service-account-token" -} + +### Token 控制器 {#token-controller} + +TokenController 作为 `kube-controller-manager` 的一部分运行，以异步的形式工作。 +其职责包括： + +- 监测 ServiceAccount 的创建并创建相应的服务账号令牌 Secret 以允许访问 API。 +- 监测 ServiceAccount 的删除并删除所有相应的服务账号令牌 Secret。 +- 监测服务账号令牌 Secret 的添加，保证相应的 ServiceAccount 存在，如有需要， + 向 Secret 中添加令牌。 +- 监测服务账号令牌 Secret 的删除，如有需要，从相应的 ServiceAccount 中移除引用。 + + +你必须通过 `--service-account-private-key-file` 标志为 `kube-controller-manager` +的令牌控制器传入一个服务账号私钥文件。该私钥用于为所生成的服务账号令牌签名。 +同样地，你需要通过 `--service-account-key-file` 标志将对应的公钥通知给 +kube-apiserver。公钥用于在身份认证过程中校验令牌。 + + +#### 创建额外的 API 令牌 {#to-create-additional-api-tokens} + +控制器中有专门的循环来保证每个 ServiceAccount 都存在对应的包含 API 令牌的 Secret。 +当需要为 ServiceAccount 创建额外的 API 令牌时，可以创建一个类型为 +`kubernetes.io/service-account-token` 的 Secret，并在其注解中引用对应的 +ServiceAccount。控制器会生成令牌并更新该 Secret： + +下面是这种 Secret 的一个示例配置： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecretname + annotations: + kubernetes.io/service-account.name: myserviceaccount +type: kubernetes.io/service-account-token ``` ```shell @@ -78,12 +211,23 @@ kubectl create -f ./secret.json kubectl describe secret mysecretname ``` -#### 删除 / 失效 服务账户 token + +#### 删除/废止服务账号令牌 Secret ```shell kubectl delete secret mysecretname ``` -### 服务账户管理器 + +### 服务账号控制器 {#serviceaccount-controller} + +服务账号控制器管理各名字空间下的 ServiceAccount 对象，并且保证每个活跃的 +名字空间下存在一个名为 "default" 的 ServiceAccount。 -服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 "default" 的服务账户 From f3107d250b0a51a45bc3af5964afbd61643e442d Mon Sep 17 00:00:00 2001 From: keshy Date: Sun, 29 Nov 2020 23:37:13 -0800 Subject: [PATCH 09/66] Update content/en/docs/reference/kubectl/cheatsheet.md Ack on recommended change. Co-authored-by: Tim Bannister --- content/en/docs/reference/kubectl/cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index d0d1ad81ee..ab4fde5469 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -311,7 +311,7 @@ kubectl run nginx --image=nginx # Run pod nginx and write it kubectl attach my-pod -i # Attach to Running Container kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod kubectl exec my-pod -- ls / # Run command in existing pod (1 container case) -kubectl exec --stdin --tty my-pod -- /bin/bash # Get active shell access to a running pod (1 container case) +kubectl exec --stdin --tty my-pod -- /bin/sh # Interactive shell access to a running pod (1 container case) kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case) kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers ``` From 36b010c1dccb24e57072f7cc82d10f662aff5c0e Mon Sep 17 00:00:00 2001 From: Ray Wang Date: Mon, 30 Nov 2020 19:12:07 +0800 Subject: [PATCH 10/66] Replace English CNCF code of conduct into Chinese one --- content/zh/community/code-of-conduct.md | 2 +- .../community/static/cncf-code-of-conduct.md | 50 +++++++------------ 2 files changed, 18 insertions(+), 34 deletions(-) diff --git a/content/zh/community/code-of-conduct.md b/content/zh/community/code-of-conduct.md index 848c58832e..42450d7e86 100644 --- a/content/zh/community/code-of-conduct.md +++ b/content/zh/community/code-of-conduct.md @@ -24,7 +24,7 @@ If you notice that this is out of date, please file an issue. --> Kubernetes 遵循 -CNCF 行为规范。 +CNCF 行为规范。 CNCF 社区规范文本如下链接 commit 0ce4694。 如果您发现这个 CNCF 社区规范文本已经过时，请 diff --git a/content/zh/community/static/cncf-code-of-conduct.md b/content/zh/community/static/cncf-code-of-conduct.md index 3ee025ba34..f3a0ffbef9 100644 --- a/content/zh/community/static/cncf-code-of-conduct.md +++ b/content/zh/community/static/cncf-code-of-conduct.md @@ -1,46 +1,30 @@ -## CNCF Community Code of Conduct v1.0 +## 云原生计算基金会（CNCF）社区行为准则 1.0 版本 -### Contributor Code of Conduct +### 贡献者行为准则 -As contributors and maintainers of this project, and in the interest of fostering -an open and welcoming community, we pledge to respect all people who contribute -through reporting issues, posting feature requests, updating documentation, -submitting pull requests or patches, and other activities. +作为这个项目的贡献者和维护者，为了建立一个开放和受欢迎的社区，我们保证尊重所有通过报告问题、发布功能请求、更新文档、提交拉取请求或补丁以及其他活动做出贡献的人员。 -We are committed to making participation in this project a harassment-free experience for -everyone, regardless of level of experience, gender, gender identity and expression, -sexual orientation, disability, personal appearance, body size, race, ethnicity, age, -religion, or nationality. +我们致力于让参与此项目的每个人都不受骚扰，无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。 -Examples of unacceptable behavior by participants include: +不可接受的参与者行为包括： -* The use of sexualized language or imagery -* Personal attacks -* Trolling or insulting/derogatory comments -* Public or private harassment -* Publishing other's private information, such as physical or electronic addresses, - without explicit permission -* Other unethical or unprofessional conduct. +- 使用性语言或图像 +- 人身攻击 +- 挑衅、侮辱或贬低性评论 +- 公开或私下骚扰 +- 未经明确许可，发布他人的私人信息，比如地址或电子邮箱 +- 其他不道德或不专业的行为 -Project maintainers have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are not -aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers -commit themselves to fairly and consistently applying these principles to every aspect -of managing this project. Project maintainers who do not follow or enforce the Code of -Conduct may be permanently removed from the project team. +项目维护者有权利和责任删除、编辑或拒绝评论、提交、代码、维基编辑、问题和其他不符合本行为准则的贡献。通过采用本行为准则，项目维护者承诺将这些原则公平且一致地应用到这个项目管理的各个方面。不遵守或不执行行为准则的项目维护者可能被永久地从项目团队中移除。 -This code of conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. +当个人代表项目或其社区时，本行为准则适用于项目空间和公共空间。 -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting -the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) . +如需举报侮辱、骚扰或其他不可接受的行为，您可发送邮件至 联系 [Kubernetes行为守则委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。其他事务请联系CNCF项目维护专员，或发送邮件至 联系我们的调解员Mishi Choudhary。 -This Code of Conduct is adapted from the Contributor Covenant -(http://contributor-covenant.org), version 1.2.0, available at -http://contributor-covenant.org/version/1/2/0/ +本行为准则改编自《贡献者契约》（ http://contributor-covenant.org ）1.2.0 版本，可在 http://contributor-covenant.org/version/1/2/0/ 查看。 -### CNCF Events Code of Conduct +### CNCF 活动行为准则 -CNCF events are governed by the Linux Foundation [Code of Conduct](http://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents. +云原生计算基金会（CNCF）活动受 Linux 基金会《[行为准则](https://events.linuxfoundation.org/code-of-conduct/)》管辖，该行为准则可在活动页面获得。其旨在与上述政策兼容，且包括更多关于事件回应的细节。 \ No newline at end of file From 20fdd094e6742fd54643c7844da1aeffda0a2ef0 Mon Sep 17 00:00:00 2001 From: Ray Wang Date: Mon, 30 Nov 2020 19:24:12 +0800 Subject: [PATCH 11/66] Change URL which suggests where to get the latest code of conduct --- content/zh/community/static/cncf-code-of-conduct.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/community/static/cncf-code-of-conduct.md b/content/zh/community/static/cncf-code-of-conduct.md index f3a0ffbef9..189675848a 100644 --- a/content/zh/community/static/cncf-code-of-conduct.md +++ b/content/zh/community/static/cncf-code-of-conduct.md @@ -1,5 +1,5 @@ + https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/zh.md --> ## 云原生计算基金会（CNCF）社区行为准则 1.0 版本 ### 贡献者行为准则 From 43d071e8eba3989304d1cc05ea16a7af78aa0472 Mon Sep 17 00:00:00 2001 From: Hrishikesh Barua Date: Wed, 2 Dec 2020 14:25:30 +0530 Subject: [PATCH 12/66] Corrected the field names in the secret --- .../tasks/configmap-secret/managing-secret-using-kubectl.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index f370e24281..1e6d88ede4 100644 --- a/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -105,8 +105,8 @@ Type: Opaque Data ==== -password.txt: 12 bytes -username.txt: 5 bytes +password: 12 bytes +username: 5 bytes ``` The commands `kubectl get` and `kubectl describe` avoid showing the contents From 2e470d20e868d6b02e11c7e3121284f5d2ff7d14 Mon Sep 17 00:00:00 2001 From: RA489 Date: Thu, 3 Dec 2020 11:49:23 +0530 Subject: [PATCH 13/66] Update install minikube page --- content/de/docs/tasks/tools/install-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/tasks/tools/install-minikube.md b/content/de/docs/tasks/tools/install-minikube.md index 318fcf25aa..3d32f7be4a 100644 --- a/content/de/docs/tasks/tools/install-minikube.md +++ b/content/de/docs/tasks/tools/install-minikube.md @@ -69,7 +69,7 @@ sudo mv minikube /usr/local/bin ### Linux {{< note >}} -Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://github.com/kubernetes/minikube#other-ways-to-install) im offiziellen Minikube-GitHub-Repository. +Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://minikube.sigs.k8s.io/docs/start/) im offiziellen Minikube-GitHub-Repository. {{< /note >}} Sie können Minikube unter Linux installieren, indem Sie eine statische Binärdatei herunterladen: From bab256b78897771405d5c2a9d4afb79208605035 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 28 Nov 2020 17:07:36 +0800 Subject: [PATCH 14/66] [zh] Sync changes from English (auth references) --- .../reference/access-authn-authz/_index.md | 52 + .../admission-controllers.md | 536 ++-- .../certificate-signing-requests.md | 426 +-- .../docs/reference/access-authn-authz/rbac.md | 2471 ++++++++--------- 4 files changed, 1732 insertions(+), 1753 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/_index.md b/content/zh/docs/reference/access-authn-authz/_index.md index 7c1caa8f24..4a67bd9440 100644 --- a/content/zh/docs/reference/access-authn-authz/_index.md +++ b/content/zh/docs/reference/access-authn-authz/_index.md @@ -1,4 +1,56 @@ --- title: 访问 API weight: 20 +no_list: true --- + + + + +关于 Kubernetes 如何实现和控制 API 访问的介绍性材料，可阅读 +[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)。 + +参考文档： + + +- [身份认证](/zh/docs/reference/access-authn-authz/authentication/) + - [使用启动引导令牌来执行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) + - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [鉴权与授权](/zh/docs/reference/access-authn-authz/authorization/) + - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/) + - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/) + - [节点鉴权](/zh/docs/reference/access-authn-authz/node/) + - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/) +- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + - 包含 [CSR 的批复](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + 和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- 服务账号 + - [开发者指南](/zh/docs/tasks/configure-pod-container/configure-service-account/) + - [管理文档](/zh/docs/reference/access-authn-authz/service-accounts-admin/) + diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index 893d1891d5..d5c847ab5f 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -32,7 +32,6 @@ This page provides an overview of Admission Controllers. - ## 什么是准入控制插件？ - -准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 - +准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API +服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成， +并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。 +在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 +它们根据 API 中的配置，分别执行变更和验证 +[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 - -准入控制器可以执行 “验证” 和/或 “变更” 操作。变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。 +准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 +变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。 准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 再次提醒，某些控制器既是变更准入控制器又是验证准入控制器。 @@ -80,7 +82,6 @@ corresponding reclamation or reconciliation process, as a given admission controller does not know for sure that a given request will pass all of the other admission controllers. --> - 最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 增加使用配额就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。 @@ -96,7 +97,8 @@ to properly support the feature. As a result, a Kubernetes API server that is n configured with the right set of admission controllers is an incomplete server and will not support all the features you expect. --> -Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持您期望的所有特性。 +Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 +因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你期望的所有特性。 -Kubernetes API 服务器的 `enable-admission-plugins` 标志，它指定了一个用于在集群修改对象之前调用的（以逗号分隔的）准入控制插件顺序列表。 +Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个用于在集群修改对象之前 +调用的（以逗号分隔的）准入控制插件顺序列表。 例如，下面的命令就启用了 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件： @@ -125,7 +128,7 @@ have to modify the systemd unit file if the API server is deployed as a systemd service, you may modify the manifest file for the API server if Kubernetes is deployed in a self-hosted way. --> -根据您 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，您可能需要以不同的方式应用设置。 +根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，你可能需要以不同的方式应用设置。 例如，如果将 API 服务器部署为 systemd 服务，你可能需要修改 systemd 单元文件； 如果以自托管方式部署 Kubernetes，你可能需要修改 API 服务器的清单文件。 {{< /note >}} @@ -135,10 +138,10 @@ in a self-hosted way. The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimited list of admission control plugins to be disabled, even if they are in the list of plugins enabled by default. --> - ## 怎么关闭准入控制器？ -Kubernetes API 服务器的 `disable-admission-plugins` 标志，会将传入的（以逗号分隔的）准入控制插件列表禁用，即使是默认启用的插件也会被禁用。 +Kubernetes API 服务器的 `disable-admission-plugins` 标志，会将传入的（以逗号分隔的） +准入控制插件列表禁用，即使是默认启用的插件也会被禁用。 ```shell kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... @@ -149,7 +152,6 @@ kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... To see which admission plugins are enabled: --> - ## 哪些插件是默认启用的？ 下面的命令可以查看哪些插件是默认启用的： @@ -159,13 +161,13 @@ kube-apiserver -h | grep enable-admission-plugins ``` -在 1.16 中，它们是： +在目前版本中，它们是： ```shell -NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, RuntimeClass, ResourceQuota +NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota ``` - ## 每个准入控制器的作用是什么？ ### AlwaysAdmit {#alwaysadmit} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} 该准入控制器会允许所有的 pod 接入集群。已废弃，因为它的行为根本就和没有准入控制器一样。 @@ -196,10 +198,12 @@ required. --> 该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always 。 这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。 -如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 pod 都可以通过已了解到的镜像的名称（假设 pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 +如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像 +的名称（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。 ### AlwaysDeny {#alwaysdeny} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - 此准入控制器获取 CertificateSigningRequest 资源的 `status.certificate` 字段更新请求并执行额外的授权检查， 以确保签发证书的用户有权限为 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求`签发`证书。 @@ -241,9 +244,8 @@ to sign certificate requests with the spec.signerName requested on the Certifica See Certificate Signing Requests for more information on the permissions required to perform different actions on CertificateSigningRequest resources. --> - 有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/) +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) ### CertificateSubjectRestrictions @@ -252,8 +254,8 @@ This admission controller observes creation of CertificateSigningRequest resourc that have a spec.signerName of kubernetes.io/kube-apiserver-client. It rejects any request that specifies a 'group' (or 'organization attribute') of system:masters. --> - -此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 CertificateSigningRequest 资源创建请求， +此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 +CertificateSigningRequest 资源创建请求， 它拒绝任何包含了 `system:masters` 一个“组”（或者“组织”）的请求。 ### DefaultStorageClass {#defaultstorageclass} @@ -264,8 +266,8 @@ and automatically adds a default storage class to them. This way, users that do not request any special storage class do not need to care about them at all and they will get the default one. --> - -该准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建，并自动向其添加默认存储类。 +该准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建， +并自动向其添加默认存储类。 这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将获得默认存储类。 - -当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类，它将拒绝任何创建 `PersistentVolumeClaim` 的操作，并显示错误。此时准入控制器会忽略任何 `PersistentVolumeClaim` 更新操作，仅响应创建操作。要修复此错误，管理员必须重新访问其 `StorageClass` 对象，并仅将其中一个标记为默认。 +当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类， +它将拒绝任何创建 `PersistentVolumeClaim` 的操作，并显示错误。 +此时准入控制器会忽略任何 `PersistentVolumeClaim` 更新操作，仅响应创建操作。 +要修复此错误，管理员必须重新访问其 `StorageClass` 对象，并仅将其中一个标记为默认。 - -关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 +关于持久化卷和存储类，以及如何将存储类标记为默认，请参见 +[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 ### DefaultTolerationSeconds {#defaulttolerationseconds} @@ -293,10 +297,13 @@ if the pods don't already have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.kubernetes.io/unreachable:NoExecute`. --> - -该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 污点。（如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 `node.kubernetes.io/unreachable：NoExecute` 污点的话） +该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 `notready:NoExecute` 和 +`unreachable:NoExecute` 污点。 +（如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 +`node.kubernetes.io/unreachable：NoExecute` 污点的话） ### DenyExecOnPrivileged {#denyexeconprivileged} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - 此功能已合并至 [DenyEscalatingExec](#denyescalatingexec)。 而 DenyExecOnPrivileged 准入插件已被废弃，并将在 v1.18 被移除。 @@ -317,11 +323,11 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. --> - 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。 +该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 ### DenyEscalatingExec {#denyescalatingexec} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - -该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 pod 中执行 exec 和 attach 命令。这包括在特权模式运行的 pod ，可以访问主机 IPC 命名空间的 pod ，和访问主机 PID 命名空间的 pod 。 +该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 Pod 中执行 exec 和 +attach 命令。这包括在特权模式运行的 Pod，可以访问主机 IPC 名字空间的 Pod， +和访问主机 PID 名字空间的 Pod 。 - DenyExecOnPrivileged 准入插件已被废弃，并将在 v1.18 被移除。 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。 +该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 ### EventRateLimit {#eventratelimit} + {{< feature-state for_k8s_version="v1.13" state="alpha" >}} - 该准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： - - * 确保 API 服务器的 `--runtime-config` 标志中包含了 `eventratelimit.admission.k8s.io/v1alpha1=true`； - * 启用 `EventRateLimit` 准入控制器； - * 从文件中引用 `EventRateLimit` 配置文件，并提供给 API 服务器命令的 `--admission-control-config-file` 标志： +* 启用 `EventRateLimit` 准入控制器； +* 从文件中引用 `EventRateLimit` 配置文件，并提供给 API 服务器命令的 + `--admission-control-config-file` 标志： {{< tabs name="eventratelimit_example" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -394,7 +397,6 @@ plugins: - 可以在配置中指定四种类型的限制： - - * `Server`: API 服务器收到的所有事件请求共享一个桶。 - * `Namespace`: 每个命名空间都有一个专用的桶。 - * `User`: 给每个用户都分配一个桶。 - * `SourceAndObject`: 根据事件的源和涉及对象的每种组合分配桶。 +* `Server`: API 服务器收到的所有事件请求共享一个桶。 +* `Namespace`: 每个名字空间都有一个专用的桶。 +* `User`: 给每个用户都分配一个桶。 +* `SourceAndObject`: 根据事件的源和涉及对象的每种组合分配桶。 - 下面是一个配置示例 `eventconfig.yaml`： ```yaml @@ -433,8 +433,8 @@ limits: See the [EventRateLimit proposal](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md) for more details. --> - -详情请参见[事件速率限制提案](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)。 +详情请参见 +[事件速率限制提案](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)。 ### ExtendedResourceToleration {#extendedresourcetoleration} @@ -446,50 +446,50 @@ name as the key. This admission controller, if enabled, automatically adds tolerations for such taints to pods requesting extended resources, so users don't have to manually add these tolerations. --> - 该插件有助于创建可扩展资源的专用节点。 如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等）， -那他们应该以扩展资源名称作为键名，[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 -如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中，用户不必再手动添加这些容忍。 +那他们应该以扩展资源名称作为键名， +[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中， +用户不必再手动添加这些容忍。 ### ImagePolicyWebhook {#imagepolicywebhook} - ImagePolicyWebhook 准入控制器允许使用一个后端的 webhook 做出准入决策。 - #### 配置文件格式 - -ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 json 或 yaml ，并具有以下格式: +ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 JSON 或 YAML， +并具有以下格式: ```yaml imagePolicy: kubeConfigFile: /path/to/kubeconfig/for/backend - # time in s to cache approval + # 以秒计的时长，控制批准请求的缓存时间 allowTTL: 50 - # time in s to cache denial + # 以秒计的时长，控制批准请求的缓存时间 denyTTL: 50 - # time in ms to wait between retries + # 以毫秒计的时长，控制重试间隔 retryBackoff: 500 - # determines behavior if the webhook backend fails + # 确定 Webhook 后端失效时的行为 defaultAllow: true ``` -从文件中引用 ImagePolicyWebhook 的配置文件，并将其提供给 API 服务器命令 `--admission-control-config-file` 标志： +从文件中引用 ImagePolicyWebhook 的配置文件，并将其提供给 API 服务器命令标志 +`--admission-control-config-file`： {{< tabs name="imagepolicywebhook_example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -504,7 +504,7 @@ plugins: {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: @@ -518,8 +518,7 @@ plugins: - -或者，您也可以直接将配置嵌入到文件中： +或者，你也可以直接将配置嵌入到文件中： {{< tabs name="imagepolicywebhook_example2" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -530,7 +529,7 @@ plugins: - name: ImagePolicyWebhook configuration: imagePolicy: - kubeConfigFile: + kubeConfigFile: allowTTL: 50 denyTTL: 50 retryBackoff: 500 @@ -539,14 +538,14 @@ plugins: {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: - name: ImagePolicyWebhook configuration: imagePolicy: - kubeConfigFile: + kubeConfigFile: allowTTL: 50 denyTTL: 50 retryBackoff: 500 @@ -556,10 +555,15 @@ plugins: {{< /tabs >}} - -ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。 +ImagePolicyWebhook 的配置文件必须引用 +[kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +格式的文件；该文件设置了到后端的连接参数。 +要求后端使用 TLS 进行通信。 - -HTTP 更多的配置，请参阅 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。 +关于 HTTP 配置的更多信息，请参阅 +[kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +文档。 -当面对一个准入决策时，API server 发送一个描述操作的 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 pod 注释。 +当面对一个准入决策时，API 服务器发送一个描述操作的 JSON 序列化的 +`imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。 +该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 +Pod 注解。 -注意，webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段，以确保正确的反序列化。此外，API server 必须启用 imagepolicy.k8s.io/v1alpha1 API 扩展组 (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`)。 +注意，Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。 +实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段， +以确保正确的反序列化。 +此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组 +（`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`）。 -远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。响应体的 "spec" 字段会被忽略，并且可以省略。一个允许访问应答会返回： +远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。 +响应体的 "spec" 字段会被忽略，并且可以省略。一个允许访问应答会返回： ```json { @@ -665,7 +679,7 @@ The remote service is expected to fill the `ImageReviewStatus` field of the requ -不允许访问，服务将返回： +若不允许访问，服务将返回： ```json { @@ -681,7 +695,8 @@ To disallow access, the service would return: -更多的文档，请参阅 `imagepolicy.v1alpha1` API 对象 和 `plugin/pkg/admission/imagepolicy/admission.go`。 +更多的文档，请参阅 `imagepolicy.v1alpha1` API 对象和 +`plugin/pkg/admission/imagepolicy/admission.go`。 -一个 pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 webhook。这允许了解后端镜像策略的用户向它发送额外的信息，并为不同的后端实现接收不同的信息。 +一个 Pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 Webhook。 +这样做使得了解后端镜像策略的用户可以向它发送额外的信息，并为不同的后端实现 +接收不同的信息。 -您可以在这里输入的信息有： +你可以在这里输入的信息有： - - * 在紧急情况下，请求 "break glass" 覆盖一个策略。 - * 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号号码。 - * 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。 +* 在紧急情况下，请求 "break glass" 覆盖一个策略。 +* 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号码。 +* 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。 -在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。在将来，如果一个注解确定将被广泛使用，它可能会被提升为 ImageReviewSpec 的一个命名字段。 +在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。 +在将来，如果一个注解确定将被广泛使用，它可能会被提升为 ImageReviewSpec 的一个命名字段。 ### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} @@ -719,7 +736,9 @@ In any case, the annotations are provided by the user and are not validated by K This admission controller denies any pod that defines `AntiAffinity` topology key other than `kubernetes.io/hostname` in `requiredDuringSchedulingRequiredDuringExecution`. --> -该准入控制器拒绝（定义了 `Anti Affinity` 拓扑键的）任何 Pod（`requiredDuringSchedulingRequiredDuringExecution` 中的 `kubernetes.io/hostname` 除外） +该准入控制器拒绝（定义了 `AntiAffinity` 拓扑键的）任何 Pod +（`requiredDuringSchedulingRequiredDuringExecution` 中的 +`kubernetes.io/hostname` 除外）。 ### LimitRanger {#limitranger} @@ -730,16 +749,25 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger applies a 0.1 CPU requirement to all Pods in the `default` namespace. --> - -该准入控制器会观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` 对象枚举的任何约束。如果您在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来执行这些约束。LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod；当前，默认的 LimitRanger 对 `default` 命名空间中的所有 pod 都应用了 0.1 CPU 的需求。 +该准入控制器会观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` +对象枚举的任何约束。 +如果你在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来 +执行这些约束。 +LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod； +当前，默认的 LimitRanger 对 `default` 名字空间中的所有 Pod 都应用了 +0.1 CPU 的需求。 - -请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)了解更多细节。 +请查看 +[limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) +和 [LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) +以了解更多细节。 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} + {{< feature-state for_k8s_version="v1.13" state="beta" >}} -该准入控制器调用任何与请求匹配的变更 webhook。匹配的 webhook 将被串行调用。每一个 webhook 都可以根据需要修改对象。 +该准入控制器调用任何与请求匹配的变更 Webhook。匹配的 Webhook 将被串行调用。 +每一个 Webhook 都可以根据需要修改对象。 -`MutatingAdmissionWebhook` ，顾名思义，仅在变更阶段运行。 +`MutatingAdmissionWebhook`，顾名思义，仅在变更阶段运行。 -如果你禁用了 MutatingAdmissionWebhook，那么还必须使用 `--runtime-config` 标志禁止 `admissionregistration.k8s.io/v1beta1` 组/版本中的 `MutatingWebhookConfiguration` 对象（版本 >=1.9 时，这两个对象都是默认启用的）。 +如果你禁用了 MutatingAdmissionWebhook，那么还必须使用 `--runtime-config` 标志禁止 +`admissionregistration.k8s.io/v1beta1` 组/版本中的 `MutatingWebhookConfiguration` +对象（版本 >=1.9 时，这两个对象都是默认启用的）。 - - * 当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。 - * 当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。 - * 与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。应尽量避免前面那种方式。 - * 这是一个 beta 特性。Kubernetes 未来的版本可能会限制这些 webhook 可以进行的变更类型。 - * 内建资源和第三方资源的控制环，未来可能会受到破坏性的更改，使现在运行良好的 Webhook 无法再正常运行。即使完成了 webhook API 安装，也不代表会为该 webhook 提供无限期的支持。 +* 当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。 +* 当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。 + * 与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。 + 应尽量避免前面那种方式。 +* 这是一个 beta 特性。Kubernetes 未来的版本可能会限制这些 Webhook 可以进行的变更类型。 +* 内建资源和第三方资源的控制回路未来可能会受到破坏性的更改，使现在运行良好的 Webhook + 无法再正常运行。即使完成了 Webhook API 安装，也不代表会为该 webhook 提供无限期的支持。 ### NamespaceAutoProvision {#namespaceautoprovision} @@ -803,8 +835,9 @@ It creates a namespace if it cannot be found. This admission controller is useful in deployments that do not want to restrict creation of a namespace prior to its usage. --> -该准入控制器会检查命名空间资源上的所有传入请求，并检查所引用的命名空间是否确实存在。如果找不到，它将创建一个命名空间。 -此准入控制器对于不想要求命名空间必须先创建后使用的集群部署中很有用。 +该准入控制器会检查名字空间资源上的所有传入请求，并检查所引用的名字空间是否确实存在。 +如果找不到，它将创建一个名字空间。 +此准入控制器对于不想要求名字空间必须先创建后使用的集群部署中很有用。 ### NamespaceExists {#namespaceexists} @@ -812,7 +845,8 @@ a namespace prior to its usage. This admission controller checks all requests on namespaced resources other than `Namespace` itself. If the namespace referenced from a request doesn't exist, the request is rejected. --> -该准入控制器检查除自身 `Namespace` 以外的命名空间资源上的所有请求。如果请求引用的命名空间不存在，则拒绝该请求。 +该准入控制器检查除 `Namespace` 以外的名字空间作用域资源上的所有请求。 +如果请求引用的名字空间不存在，则拒绝该请求。 ### NamespaceLifecycle {#namespacelifecycle} @@ -821,14 +855,17 @@ This admission controller enforces that a `Namespace` that is undergoing termina and ensures that requests in a non-existent `Namespace` are rejected. This admission controller also prevents deletion of three system reserved namespaces `default`, `kube-system`, `kube-public`. --> -该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保使用不存在的 `Namespace` 的请求被拒绝。 -该准入控制器还会禁止删除三个系统保留的命名空间，即 `default`、`kube-system` 和 `kube-public`。 +该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保 +使用不存在的 `Namespace` 的请求被拒绝。 +该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、 +`kube-system` 和 `kube-public`。 -删除 `Namespace` 会触发删除该命名空间中所有对象（pod、services 等）的一系列操作。为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。 +删除 `Namespace` 会触发删除该名字空间中所有对象（Pod、Service 等）的一系列操作。 +为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。 ### NodeRestriction {#noderestriction} @@ -837,7 +874,10 @@ This admission controller limits the `Node` and `Pod` objects a kubelet can modi kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:`. 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:` 形式的用户名。这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到节点本身的 `Pod` 对象。 +该准入控制器限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 +为了受到这个准入控制器的限制，kubelet 必须使用在 `system:nodes` 组中的凭证， +并使用 `system:node:` 形式的用户名。 +这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到节点本身的 Pod 对象。 在 Kubernetes 1.11+ 的版本中，不允许 kubelet 从 `Node` API 对象中更新或删除污点。 -在 Kubernetes 1.13+ 的版本中，`NodeRestriction` 准入插件可防止 kubelet 删除 `Node` API 对象，并对 `kubernetes.io/` 或 `k8s.io/` 前缀标签的 kubelet 强制进行如下修改： +在 Kubernetes 1.13+ 的版本中，`NodeRestriction` 准入插件可防止 kubelet 删除 +`Node` API 对象，并对 `kubernetes.io/` 或 `k8s.io/` 前缀标签的 kubelet +强制进行如下修改： - -* **防止** kubelets 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。保留此前缀的标签，供管理员用来标记 `Node` 对象以隔离工作负载，并且不允许 kubelet 修改带有该前缀的标签。 +* **防止** kubelet 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。 + 保留此前缀的标签，供管理员用来标记 Node 对象以隔离工作负载，并且不允许 kubelet + 修改带有该前缀的标签。 * **允许** kubelet 添加/删除/更新这些和这些前缀的标签： * `kubernetes.io/hostname` * `kubernetes.io/arch` * `kubernetes.io/os` * `beta.kubernetes.io/instance-type` * `node.kubernetes.io/instance-type` - * `failure-domain.beta.kubernetes.io/region` - * `failure-domain.beta.kubernetes.io/zone` + * `failure-domain.beta.kubernetes.io/region` （已弃用） + * `failure-domain.beta.kubernetes.io/zone` (已弃用） * `topology.kubernetes.io/region` * `topology.kubernetes.io/zone` * `kubelet.kubernetes.io/`-prefixed labels @@ -875,7 +918,8 @@ Use of any other labels under the `kubernetes.io` or `k8s.io` prefixes by kubele Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly. --> -kubelet 保留 `kubernetes.io` 或 `k8s.io` 前缀的所有标签，并且将来可能会被 `NodeRestriction` 准入插件允许或禁止。 +kubelet 保留 `kubernetes.io` 或 `k8s.io` 前缀的所有标签，并且将来可能会被 +`NodeRestriction` 准入插件允许或禁止。 将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集。 @@ -888,10 +932,14 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. --> - -该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 “删除” 权限的用户才能对其进行更改。该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问，以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” 权限的用户才能对其进行更改。 +该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 +“删除” 权限的用户才能对其进行更改。 +该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问， +以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” +权限的用户才能对其进行更改。 ### PersistentVolumeLabel {#persistentvolumelabel} + {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS）定义的 PersistentVolumes 中。 -这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 -如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，以防止 Pod 挂载其他区域的卷。 -PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。 +该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS） +定义的 PersistentVolume。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 +如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签， +以防止 Pod 挂载其他区域的卷。 +PersistentVolumeLabel 已被废弃，标记持久卷已由 +[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。 从 1.11 开始，默认情况下禁用此准入控制器。 ### PodNodeSelector {#podnodeselector} @@ -916,7 +966,8 @@ PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/ -该准入控制器通过读取命名空间注解和全局配置，来为命名空间中可以可以使用的节点选择器设置默认值并实施限制。 +该准入控制器通过读取名字空间注解和全局配置，来为名字空间中可以可以使用的节点选择器 +设置默认值并实施限制。 - #### 配置文件格式 `PodNodeSelector` 使用配置文件来设置后端行为的选项。 -请注意，配置文件格式将在将来某个版本中迁移为版本化文件。 -该文件可以是 json 或 yaml，格式如下： +请注意，配置文件格式将在将来某个版本中改为版本化文件。 +该文件可以是 JSON 或 YAML，格式如下： ```yaml podNodeSelectorPluginConfig: @@ -942,7 +992,8 @@ podNodeSelectorPluginConfig: -从文件中引用 `PodNodeSelector` 配置文件，提供给 API 服务器命令行标志 `--admission-control-config-file`： +基于提供给 API 服务器命令行标志 `--admission-control-config-file` 的文件名， +从文件中引用 `PodNodeSelector` 配置文件： {{< tabs name="podnodeselector_example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -957,7 +1008,7 @@ plugins: {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +# 在 v1.17 中废弃，以鼓励使用 apiserver.config.k8s.io/v1 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: @@ -975,7 +1026,8 @@ plugins: --> #### 配置注解格式 -`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解将节点选择器分配给命名空间。 +`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解 +为名字空间设置节点选择算符。 ```yaml apiVersion: v1 @@ -990,7 +1042,6 @@ metadata: #### Internal Behavior This admission controller has the following behavior: --> - #### 内部行为 该准入控制器行为如下： @@ -1004,17 +1055,21 @@ plugin configuration file as the node selector. 4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file. Conflicts result in rejection. --> -1. 如果 `Namespace` 的注解带有键 `scheduler.alpha.kubernetes.io/node-selector` ，则将其值用作节点选择器。 -2. 如果命名空间缺少此类注解，则使用 `PodNodeSelector` 插件配置文件中定义的 `clusterDefaultNodeSelector` 作为节点选择器。 -3. 评估 pod 节点选择器和命名空间节点选择器是否存在冲突。存在冲突将导致拒绝。 -4. 评估 pod 节点选择器和命名空间的白名单定义的插件配置文件是否存在冲突。存在冲突将导致拒绝。 +1. 如果 `Namespace` 的注解带有键 `scheduler.alpha.kubernetes.io/node-selector`， + 则将其值用作节点选择算符。 +2. 如果名字空间缺少此类注解，则使用 `PodNodeSelector` 插件配置文件中定义的 + `clusterDefaultNodeSelector` 作为节点选择算符。 +3. 评估 Pod 节点选择算符和名字空间节点选择算符是否存在冲突。存在冲突将导致拒绝。 +4. 评估 pod 节点选择算符和名字空间的白名单定义的插件配置文件是否存在冲突。 + 存在冲突将导致拒绝。 {{< note >}} -PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。另请参阅 PodTolerationRestriction 准入插件，该插件可防止 Pod 在特定污点的节点上运行。 +PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。 +另请参阅 PodTolerationRestriction 准入插件，该插件可防止 Pod 在特定污点的节点上运行。 {{< /note >}} ### PersistentVolumeClaimResize {#persistentvolumeclaimresize} @@ -1029,7 +1084,8 @@ This admission controller implements additional validations for checking incomin Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes` to `true` to enable resizing. --> -对调整卷大小的支持是一种 Alpha 特性。管理员必须将特性门控 `ExpandPersistentVolumes` 设置为 `true` 才能启用调整大小。 +对调整卷大小的支持是一种 Alpha 特性。管理员必须将特性门控 `ExpandPersistentVolumes` +设置为 `true` 才能启用调整大小。 {{< /note >}} -启用 `ExpandPersistentVolumes` 特性门控之后，建议将 `PersistentVolumeClaimResize` 准入控制器也启用。除非 PVC 的 `StorageClass` 明确地将 `allowVolumeExpansion` 设置为 `true` 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 +启用 `ExpandPersistentVolumes` 特性门控之后，建议将 `PersistentVolumeClaimResize` +准入控制器也启用。除非 PVC 的 `StorageClass` 明确地将 `allowVolumeExpansion` 设置为 +`true` 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 例如：由以下 `StorageClass` 创建的所有 `PersistentVolumeClaim` 都支持卷容量扩充： @@ -1060,8 +1118,8 @@ allowVolumeExpansion: true - -关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +关于持久化卷申领的更多信息，请参见 +[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ### PodPreset {#podpreset} @@ -1071,9 +1129,10 @@ See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and [Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset) for more information. --> - -该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 pod。 -另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) 获取详情。 +该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 Pod。 +另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和 +[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) +了解更多信息。 ### PodSecurityPolicy {#podsecuritypolicy} @@ -1081,61 +1140,70 @@ for more information. This admission controller acts on creation and modification of the pod and determines if it should be admitted based on the requested security context and the available Pod Security Policies. --> -此准入控制器负责在创建和修改 pod 时根据请求的安全上下文和可用的 pod 安全策略确定是否可以执行请求。 - - -对于 Kubernetes < 1.6.0 的版本，API Server 必须启用 extensions/v1beta1/podsecuritypolicy API 扩展组 (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`)。 +此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和可用的 Pod +安全策略确定是否可以执行请求。 -查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/)了解更多细节。 +查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/) +了解更多细节。 ### PodTolerationRestriction {#podtolerationrestriction} - -该准入控制器首先验证 Pod 的容忍度与其命名空间的容忍度之间的冲突。如果存在冲突，则拒绝 Pod 请求。 -然后，它将命名空间的容忍度合并到 pod 的容忍度中，之后根据命名空间的容忍度白名单检查所得到的容忍度结果。 -如果检查成功，则将接受 pod 请求，否则拒绝该请求。 +准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间 +是否存在冲突。如果存在冲突，则拒绝 Pod 请求。 +然后，它将名字空间的容忍度合并到 Pod 的容忍度中，之后根据名字空间的容忍度 +白名单检查所得到的容忍度结果。如果检查成功，则将接受 Pod 请求，否则拒绝该请求。 - -如果 pod 的命名空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的默认容忍度或容忍度白名单（如果有的话）。 +如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的 +默认容忍度或容忍度白名单（如果有的话）。 -命名空间的容忍度通过注解健 `scheduler.alpha.kubernetes.io/defaultTolerations` 和 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` 设置。 +Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key. +The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key. +Example for namespace annotations: +--> +名字空间的容忍度通过注解健 `scheduler.alpha.kubernetes.io/defaultTolerations` +来设置。可接受的容忍度可以通过 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` +注解键来添加。 + +名字空间注解的示例： + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: apps-that-need-nodes-exclusively + annotations: + scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]' + scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]' +``` - ### 优先级 {#priority} -优先级准入控制器使用 `priorityClassName` 字段并用整型值填充优先级。如果找不到优先级，则拒绝 Pod。 +优先级准入控制器使用 `priorityClassName` 字段并用整型值填充优先级。 +如果找不到优先级，则拒绝 Pod。 ### ResourceQuota {#resourcequota} @@ -1144,66 +1212,98 @@ This admission controller will observe the incoming request and ensure that it d enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota` objects in your Kubernetes deployment, you MUST use this admission controller to enforce quota constraints. --> -该准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` 对象中枚举出来的约束。 -如果您在 Kubernetes 部署中使用了 `ResourceQuota` ，您必须使用这个准入控制器来强制执行配额限制。 +该准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` +对象中枚举出来的约束。 +如果你在 Kubernetes 部署中使用了 `ResourceQuota`，你必须使用这个准入控制器来强制 +执行配额限制。 -请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。 +请查看 +[resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/) +了解更多细节。 - ### 容器运行时类 {#runtimeclass} + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} -[容器运行时类](/zh/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。 +[RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 定义描述了与运行 Pod +相关的开销。此准入控制器将相应地设置 `pod.spec.overhead` 字段。 -详情请参见 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/)。 +详情请参见 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)。 ### SecurityContextDeny {#securitycontextdeny} -该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 字段的 pod。 -如果集群没有使用 [pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)来限制安全上下文所能获取的值集，那么应该启用这个功能。 +该准入控制器将拒绝任何试图设置特定提升 +[SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) +字段的 Pod，正如任务 +[为 Pod 或 Container 配置安全上下文](/zh/docs/tasks/configure-pod-container/security-context/) +中所展示的那样。 +如果集群没有使用 [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) +来限制安全上下文所能获取的值集，那么应该启用这个功能。 ### ServiceAccount {#serviceaccount} -该准入控制器实现了 [serviceAccounts](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。 -如果您打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议您使用这个准入控制器。 +此准入控制器实现了 +[ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +的自动化。 +如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。 ### StorageObjectInUseProtection -`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 +`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 +`kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC） +或持久化卷（PV）中。 +如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 +PVC/PV 不会被删除。 +有关更多详细信息，请参考 +[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 ### TaintNodesByCondition {#taintnodesbycondition} + {{< feature-state for_k8s_version="v1.12" state="beta" >}} -该准入控制器 {{< glossary_tooltip text="污点" term_id="taint" >}} 新创建的 `NotReady` 和 `NoSchedule` 节点。 -避免了可能导致 Pod 在更新其污点以准确反映其所报告状况之前，就安排了在新节点上的竞争条件的情况。 +该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` +{{< glossary_tooltip text="污点" term_id="taint" >}}。 +这些污点能够避免一些竞态条件的发生，这类静态条件可能导致 Pod 在更新节点污点以准确 +反映其所报告状况之前，就被调度到新节点上。 ### ValidatingAdmissionWebhook {#validatingadmissionwebhook} + {{< feature-state for_k8s_version="v1.13" state="beta" >}} -该准入控制器调用与请求匹配的所有验证 webhook。匹配的 webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 -该准入控制器仅在验证阶段运行；与 `MutatingAdmissionWebhook` 准入控制器所调用的 webhook 相反，它调用的 webhook 应该不会使对象出现变更。 +该准入控制器调用与请求匹配的所有验证 Webhook。 +匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 +该准入控制器仅在验证（Validating）阶段运行；与 `MutatingAdmissionWebhook` 准入控制器 +所调用的 Webhook 相反，它调用的 Webhook 应该不会使对象出现变更。 -如果以此方式调用的 webhook 有其它作用（如，配额递减），则它必须具有协调系统，因为不能保证后续的 webhook 或其他有效的准入控制器都允许请求完成。 +如果以此方式调用的 Webhook 有其它作用（如，降低配额），则它必须具有协调机制。 +这是因为无法保证后续的 Webhook 或其他有效的准入控制器都允许请求完成。 - -如果您禁用了 ValidatingAdmissionWebhook，还必须在 `admissionregistration.k8s.io/v1beta1` 组/版本中使用 `--runtime-config` 标志来禁用 `ValidatingWebhookConfiguration` 对象（默认情况下在 1.9 版和更高版本中均处于启用状态）。 +如果你禁用了 ValidatingAdmissionWebhook，还必须通过 `--runtime-config` 标志来禁用 +`admissionregistration.k8s.io/v1beta1` 组/版本中的 `ValidatingWebhookConfiguration` +对象（默认情况下在 1.9 版和更高版本中均处于启用状态）。 ## 有推荐的准入控制器吗？ -有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 -因此您无需显式指定它们。您可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。 +有。对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态 +（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 +因此，你无需显式指定它们。 +你可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。 {{< note >}} -`--admission-control` 在 1.10 中已废弃，已由 `--enable-admission-plugins` 取代。 +`--admission-control` 在 1.10 中已废弃，由 `--enable-admission-plugins` 取代。 {{< /note >}} - -对于 Kubernetes 1.9 及更早版本，我们建议使用 `--admission-control` 标志（**顺序很重要**）运行下面的一组准入控制器。 +对于 Kubernetes 1.9 及更早版本，我们建议使用 `--admission-control` 标志 +（**顺序很重要**）运行下面的一组准入控制器。 * v1.9 @@ -1260,19 +1367,20 @@ For Kubernetes 1.9 and earlier, we recommend running the following set of admiss --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota ``` - + and a validating phase, and that for example `ResourceQuota` runs in the validating + phase, and therefore is the last admission controller to run. + `MutatingAdmissionWebhook` appears before it in this list, because it runs + in the mutating phase. + --> + * 需要重申的是，在 1.9 中，它们都发生在变更阶段和验证阶段，例如 `ResourceQuota` + 在验证阶段运行，因此是最后一个运行的准入控制器。 + `MutatingAdmissionWebhook` 出现在此列表的前面，因为它在变更阶段运行。 -* 需要重申的是，在 1.9 中，它们都发生在变更阶段和验证阶段，例如 `ResourceQuota` 在验证阶段运行，因此是最后一个运行的准入控制器。 - `MutatingAdmissionWebhook` 出现在此列表的前面，因为它在变更阶段运行。 - - + admission controllers ran in the exact order specified. + --> 对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。 + diff --git a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md index ab0854a207..2663bf357a 100644 --- a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -43,20 +43,19 @@ CertificateSigningRequest（CSR）资源用来向指定的签名者申请证书 ## 请求签名流程 {#request-signing-process} -_CertificateSigningRequest_ 资源类型允许客户使用它申请签名 X.509 证书。 -CertificateSigningRequest 对象 在 `spec.request` 中 包括一个 PEM 编码的 PKCS#10 签名请求。 -CertificateSigningRequest 使用 `spec.signerName` 字段表示 _签名者_（请求的接收方）。 +CertificateSigningRequest 资源类型允许客户使用它申请发放 X.509 证书。 +CertificateSigningRequest 对象 在 `spec.request` 中包含一个 PEM 编码的 PKCS#10 签名请求。 +CertificateSigningRequest 使用 `spec.signerName` 字段标示 _签名者_（请求的接收方）。 注意，`spec.signerName` 在 `certificates.k8s.io/v1` 之后的 API 版本是必填项。 -一般来说，当 CSR 被批准通过，且证书被签名后，`status.certificate` 字段将包含一个 PEM 编码的 X.509 证书。 +一般来说，当 CSR 被批准通过，且证书被签名后，`status.certificate` 字段 +将包含一个 PEM 编码的 X.509 证书。 有些签名者在 `status.certificate` 字段中存储多个证书。 在这种情况下，签名者的说明文档应当指明附加证书的含义。 例如，这是要在 TLS 握手时提供的证书和中继证书。 + +PKCS#10 签名请求格式不允许设置证书的过期时间或者生命期。因此，证书的过期 +时间或者生命期必须通过类似 CSR 对象的注解字段这种形式来设置。 +尽管让签名者使用过期日期从理论上来讲也是可行的，目前还不存在哪个实现这样做了。 +（内置的签名者都是用相同的 `ClusterSigningDuration` 配置选项，而该选项 +中将生命期的默认值设为 1 年，且可通过 kube-controller-manager 的命令行选项 +`--cluster-signing-duration` 来更改。） + - -1. `kubernetes.io/kube-apiserver-client`: 签名的证书将被 kube-apiserver 视为客户证书。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 - 1. 信任分发：签名的证书将被 kube-apiserver 视为客户端证书。CA 证书包不通过任何其他方式分发。 - 1. 许可的主体 — 没有主体限制，但审核人和签名者可以选择不批准或不签署。 - 某些主体，比如集群管理员级别的用户或组，因部署和安装方式不同而不同， +1. `kubernetes.io/kube-apiserver-client`：签名的证书将被 API 服务器视为客户证书。 + {{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 + 1. 信任分发：签名的证书将被 API 服务器视为客户端证书。CA 证书包不通过任何其他方式分发。 + 1. 许可的主体：没有主体限制，但审核人和签名者可以选择不批准或不签署。 + 某些主体，比如集群管理员级别的用户或组因部署和安装方式不同而不同， 所以批准和签署之前需要进行额外仔细审查。 用来限制 `system:masters` 的 CertificateSubjectRestriction 准入插件默认处于启用状态， - 但它通常不是集群中唯一的 cluster-admin 主体。 - 1. 许可的 x509 扩展 - 允许 subjectAltName 和 key usage 扩展，弃用其他扩展。 - 1. 许可的密钥用途 - 必须包含 `[]string{"client auth"}`，但不能包含 `[]string{"digital signature", "key encipherment", "client auth"}` 之外的键。 - 1. 过期时间/证书有效期 - CSR 签名者和请求中的较小者。签名者负责检查证书的有效期正常且可接受。 - 1. 允许/不允许 CA 位 - 不允许。 - - -1. `kubernetes.io/kube-apiserver-client-kubelet`: 签名的证书将被 kube-apiserver 视为客户证书。{{< glossary_tooltip term_id="kube-controller-manager" >}} 可以自动批准它。 - 1. 信任分发： 签名的证书将被 kube-apiserver 视为客户端证书。CA 证书包不通过任何其他方式分发。 - 2. 许可的主体 - 组织名必须是 `[]string{"system:nodes"}`，用户名以 `"system:node:"` 开头 - 3. 许可的 x509 扩展 — 允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。 - 4. 许可的密钥用途 - 必须是 `[]string{"key encipherment", "digital signature", "client auth"}` - 5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。签名者负责检查证书的有效期正常且可接受。 - 6. 允许/不允许 CA 位 - 不允许。 - - -2. `kubernetes.io/kubelet-serving`: 签名服务证书，该服务证书被 kube-apiserver 视为有效的 kubelet 服务证书，但没有其他保证。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 - 1. 信任分发 ：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。 - 2. 许可的主体 - 组织名必须是 `[]string{"system:nodes"}`，用户名以`"system:node:"`开头 - 3. 许可的 x509 扩展 — 允许 key usage、DNSName/IPAddress subjectAltName 等扩展， - 禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。 - 至少有一个 DNS 或 IP 的 SubjectAltName 存在。 - 4. 许可的密钥用途 - 必须是 `[]string{"key encipherment", "digital signature", "client auth"}` - 5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。 - 6. 允许/不允许 CA 位 - 不允许。 - - -3. `kubernetes.io/legacy-unknown`: 根本不能保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。稳定版的 CertificateSigningRequest API（`certificates.k8s.io/v1` 以及之后的版本） 不允许将 `signerName` 设置为 `kubernetes.io/legacy-unknown`。{{< glossary_tooltip term_id="kube-controller-manager" >}} 将不会自动批准它。 - 1. 信任分发：没有。有这个签名者在 Kubernetes 集群中没有标准的信任或分发。 - 2. 许可的主体 - 全部 - 3. 许可的 x509 扩展 — 允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。 - 4. 许可的密钥用途 - 全部 - 5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。签名者负责检查证书的有效期正常且可接受。 - 6. 允许/不允许 CA 位 - 不允许。 - + 但它通常不是集群中唯一的集群管理员主体。 + 1. 许可的 x509 扩展：允许 subjectAltName 和 key usage 扩展，弃用其他扩展。 + 1. 许可的密钥用途：必须包含 `["client auth"]`，但不能包含 + `["digital signature", "key encipherment", "client auth"]` 之外的键。 + 1. 过期时间/证书有效期：通过 kube-controller-manager 中 `--cluster-signing-duration` + 标志来设置，由其中的签名者实施。 + 1. 允许/不允许 CA 位：不允许。 +2. `kubernetes.io/kube-apiserver-client-kubelet`: 签名的证书将被 kube-apiserver 视为客户证书。 + {{< glossary_tooltip term_id="kube-controller-manager" >}} 可以自动批准它。 + 1. 信任分发：签名的证书将被 API 服务器视为客户端证书。CA 证书包不通过任何其他方式分发。 + 1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头 + 1. 许可的 x509 扩展：允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。 + 1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "client auth"]` + 1. 过期时间/证书有效期：通过 kube-controller-manager 中签名者的实现所对应的标志 + `--cluster-signing-duration` 来设置。 + 1. 允许/不允许 CA 位：不允许。 + + +3. `kubernetes.io/kubelet-serving`: 签名服务证书，该服务证书被 API 服务器视为有效的 kubelet 服务证书， + 但没有其他保证。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。 + 1. 信任分发：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。 + 1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头 + 1. 许可的 x509 扩展：允许 key usage、DNSName/IPAddress subjectAltName 等扩展， + 禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。 + 至少有一个 DNS 或 IP 的 SubjectAltName 存在。 + 1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "client auth"]` + 1. 过期日期/证书生命期：通过 kube-controller-manager 中签名者的实现所对应的标志 + `--cluster-signing-duration` 来设置。 + 1. 允许/不允许 CA 位：不允许。 + + +4. `kubernetes.io/legacy-unknown`: 不保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。 + 稳定版的 CertificateSigningRequest API（`certificates.k8s.io/v1` 以及之后的版本）不允许将 + `signerName` 设置为 `kubernetes.io/legacy-unknown`。 + {{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准这类请求。 + 1. 信任分发：没有。这个签名者在 Kubernetes 集群中没有标准的信任或分发。 + 1. 许可的主体：全部。 + 1. 许可的 x509 扩展：允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。 + 1. 许可的密钥用途：全部。 + 1. 过期日期/证书生命期：通过 kube-controller-manager 中签名者的实现所对应的标志 + `--cluster-signing-duration` 来设置。 + 1. 允许/不允许 CA 位 - 不允许。 + +{{< note >}} + +注意：所有这些故障仅在 kube-controller-manager 日志中报告。 +{{< /note >}} + -{{< note >}} -注意：所有这些故障仅在 kube-controller-manager 日志中报告。 -{{< /note >}} - -对于这些签名者，信任的分发发生在带外（out of band）。 -上述信任之外的任何信任都是完全巧合的。 +对于这些签名者，信任的分发发生在带外（out of band）。上述信任之外的任何信任都是完全巧合的。 例如，一些发行版可能会将 `kubernetes.io/legacy-unknown` 作为 kube-apiserver 的客户端证书， 但这个做法并不标准。 这些用途都没有以任何方式涉及到 ServiceAccount 中的 Secrets `.data[ca.crt]`。 -此 CA 证书包只保证使用默认的服务（`kubernetes.default.svc`）来验证到 kube-apiserver 的连接。 +此 CA 证书包只保证使用默认的服务（`kubernetes.default.svc`）来验证到 API 服务器的连接。 授权批准 CertificateSigningRequest： -* verbs（动词）: `get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests` -* verbs（动词）: `update`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests/approval` -* verbs（动词）: `approve`, group（组）： `certificates.k8s.io`, resources（资源）：`signers`, resourceName: `/` 或 `/*` +* verbs（动词）: `get`、`list`、`watch`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests` +* verbs（动词）: `update`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests/approval` +* verbs（动词）：`approve`， + group（组）：`certificates.k8s.io`， + resources（资源）：`signers`， + resourceName：`/` 或 `/*` 例如： @@ -336,58 +379,66 @@ To allow signing a CertificateSigningRequest: * Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/status` * Verbs: `sign`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `/` or `/*` --> -授权签名 CertificateSigningRequest ： +授权签名 CertificateSigningRequest： -* verbs（动词）：`get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests` -* verbs（动词）：`update`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests/status` -* verbs（动词）：`sign`, group（组）： `certificates.k8s.io`, resources（资源）：`signers`, resourceName: `/` or `/*` +* verbs（动词）：`get`、`list`、`watch`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests` +* verbs（动词）：`update`， + group（组）：`certificates.k8s.io`， + resources（资源）：`certificatesigningrequests/status` +* verbs（动词）：`sign`， + group（组）：`certificates.k8s.io`， + resources（资源）：`signers`， + resourceName：`/` 或 `/*` {{< codenew file="access/certificate-signing-request/clusterrole-sign.yaml" >}} -## 普通用户 {#nornal-user} +## 普通用户 {#normal-user} 为了让普通用户能够通过认证并调用 API，需要执行几个步骤。 -首先，该用户必须拥有 Kubernetes 集群签名的证书， -然后将该证书作为 API 调用的证书头或通过 kubectl 提供出来。 +首先，该用户必须拥有 Kubernetes 集群签发的证书， +然后将该证书作为 API 调用的 Certificate 头或通过 kubectl 提供。 ### 创建私钥 {#create-private-key} 下面的脚本展示了如何生成 PKI 私钥和 CSR。 -设置 CSR 的 CN 和 O 字段很重要。CN 是用户名，O 是该用户归属的组。 -你可以参考 [RBAC](/docs/reference/access-authn-authz/rbac/) 获取标准组的信息。 +设置 CSR 的 CN 和 O 属性很重要。CN 是用户名，O 是该用户归属的组。 +你可以参考 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。 -``` +```shell openssl genrsa -out john.key 2048 openssl req -new -key john.key -out john.csr ``` -### 创建申请证书的 Kubernetes 对象 {#create-certificate-request-kubernetes-object} +### 创建 CertificateSigningRequest {#create-certificatesigningrequest} 创建一个 CertificateSigningRequest，并通过 kubectl 将其提交到 Kubernetes 集群。 下面是生成 CertificateSigningRequest 的脚本。 -``` +```shell cat < 需要注意的几点: -- usage 字段必须是 'client auth' -- request 字段是 CSR 文件内容的 base64 编码值。 - 要得到该值，可以执行命令 ```cat john.csr | base64 | tr -d "\n"``` 。 +- `usage` 字段必须是 '`client auth`' +- `request` 字段是 CSR 文件内容的 base64 编码值。 + 要得到该值，可以执行命令 `cat john.csr | base64 | tr -d "\n"`。 -### 批准证书请求 {#approve-certificate-request} +### 批准证书签名请求 {#approve-certificate-signing-request} 使用 kubectl 创建 CSR 并批准。 -获取 CSR 列表 -``` +获取 CSR 列表： + +```shell kubectl get csr ``` -批准 CRS -``` +批准 CSR： + +```shell kubectl certificate approve john ``` ### 取得证书 {#get-the-certificate} -从 CSR 取得证书。 +从 CSR 取得证书： -``` +```shell kubectl get csr/john -o yaml ``` +证书的内容使用 base64 编码，存放在字段 `status.certificate`。 + -证书的内容使用 base64 编码，存放在字段 status.certificate。 - ### 创建角色和角色绑定 {#create-role-and-role-binding} -你已经拿到证书了。为了让这个用户能访问 Kubernetes 集群资源，现在就要创建 Role 和 Role Binding 了。 +创建了证书之后，为了让这个用户能访问 Kubernetes 集群资源，现在就要创建 +Role 和 RoleBinding 了。 -这是为这个新用户创建角色的示例脚本 +下面是为这个新用户创建 Role 的示例脚本： -``` +```shell kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods ``` -这是为这个新用户创建角色绑定的示例脚本 -``` +下面是为这个新用户创建 RoleBinding 的示例命令： + +```shell kubectl create rolebinding developer-binding-john --role=developer --user=john ``` -### 添加到 KubeConfig +### 添加到 kubeconfig {#add-to-kubeconfig} -最后一步是将这个用户添加到 KubeConfig。 +最后一步是将这个用户添加到 kubeconfig 文件。 我们假设私钥和证书文件存放在 “/home/vagrant/work/” 目录中。 -首先，我们需要添加新的凭据 +首先，我们需要添加新的凭据： -``` +```shell kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true ``` -然后，我们需要添加上下文 -``` +然后，你需要添加上下文： + +```shell kubectl config set-context john --cluster=kubernetes --user=john ``` -来测试一下，把 kubecontext 切换为 john -``` +来测试一下，把上下文切换为 `john`： + +```shell kubectl config use-context john ``` -### 使用 `kubectl` 批准和驳回 +### 使用 `kubectl` 批准或驳回 {#approval-rejection-kubectl} Kubernetes 管理员（拥有足够的权限）可以手工批准（或驳回）CertificateSigningRequests， 此操作使用 `kubectl certificate approve` 和 `kubectl certificate deny` 命令实现。 使用 kubectl 批准一个 CSR： -```bash +```shell kubectl certificate approve ``` + 同样地，驳回一个 CSR： -```bash +```shell kubectl certificate deny ``` -### 使用 Kubernetes API 批准和驳回 {#approval-rejection-api-client} +### 使用 Kubernetes API 批准或驳回 {#approval-rejection-api-client} REST API 的用户可以通过向待批准的 CSR 的 `approval` 子资源提交更新请求来批准 CSR。 例如，你可以编写一个 @@ -638,15 +696,16 @@ you like. If you want to add a note just for human consumption, use the ### Control plane signer {#signer-control-plane} -The Kubernetes control plane implements each of the [Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers), +The Kubernetes control plane implements each of the +[Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers), as part of the kube-controller-manager. Prior to Kubernetes v1.18, the kube-controller-manager would sign any CSRs that were marked as approved. --> -## 签名 +## 签名 {#signing} -### 控制平面签名者 +### 控制平面签名者 {#signer-control-plane} Kubernetes 控制平面实现了每一个 [Kubernetes 签名者](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)， @@ -672,7 +731,7 @@ as described in [section 4 of RFC5280](https://tools.ietf.org/html/rfc5280#secti Example certificate content: --> -### 基于 API 的签名者 +### 基于 API 的签名者 {#signer-api} REST API 的用户可以通过向待签名的 CSR 的 `status` 子资源提交更新请求来对 CSR 进行签名。 @@ -728,11 +787,8 @@ status: certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..." ``` - - ## {{% heading "whatsnext" %}} - -基于角色（Role）的访问控制（RBAC）是一种基于企业中用户的角色来调节控制对计算机或网络资源的访问方法。 - +基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对 +计算机或网络资源的访问的方法。 -`RBAC` 使用 `rbac.authorization.k8s.io` {{< glossary_tooltip text="API 组" term_id="api-group" >}} -来驱动鉴权操作，允许管理员通过 Kubernetes API 动态配置策略。 - -在 1.8 版本中，RBAC 模式是稳定的并通过 rbac.authorization.k8s.io/v1 API 提供支持。 - -要启用 RBAC，在启动 API 服务器时添加 `--authorization-mode=RBAC` 参数。 +RBAC 鉴权机制使用 `rbac.authorization.k8s.io` +{{< glossary_tooltip text="API 组" term_id="api-group" >}} +来驱动鉴权决定，允许你通过 Kubernetes API 动态配置策略。 +要启用 RBAC，在启动 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} +时将 `--authorization-mode` 参数设置为一个逗号分隔的列表并确保其中包含 `RBAC`。 -## API 概述 +```shell +kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选项> +``` -本节介绍 RBAC API 所声明的四种顶级类型。用户可以像与其他 API 资源交互一样， -（通过 `kubectl`、API 调用等方式）与这些资源交互。例如， -命令 `kubectl apply -f (resource).yml` 可以用在这里的任何一个例子之上。 -尽管如此，建议读者循序渐进阅读下面的章节，由浅入深。 + +## API 对象 {#api-overview} + +RBAC API 声明了四种 Kubernetes 对象：_Role_、_ClusterRole_、_RoleBinding_ 和 +_ClusterRoleBinding_。你可以像使用其他 Kubernetes 对象一样， +通过类似 `kubectl` 这类工具 +[描述对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), +或修补对象。 + +{{< caution >}} + +这些对象在设计时即实施了一些访问限制。如果你在学习过程中对集群做了更改，请参考 +[避免特权提升和引导](#privilege-escalation-prevention-and-bootstrapping) +一节，以了解这些限制会以怎样的方式阻止你做出修改。 +{{< /caution >}} -### Role 和 ClusterRole +### Role 和 ClusterRole {#role-and-clusterole} -在 RBAC API 中，一个角色包含一组相关权限的规则。权限是纯粹累加的（不存在拒绝某操作的规则）。 -角色可以用 `Role` 来定义到某个命名空间上， -或者用 `ClusterRole` 来定义到整个集群作用域。 +RBAC 的 _Role_ 或 _ClusterRole_ 中包含一组代表相关权限的规则。 +这些权限是纯粹累加的（不存在拒绝某操作的规则）。 -一个 `Role` 只可以用来对某一命名空间中的资源赋予访问权限。 -下面的 `Role` 示例定义到名称为 "default" 的命名空间，可以用来授予对该命名空间中的 Pods 的读取权限： +Role 总是用来在某个{{< glossary_tooltip text="名字空间" term_id="namespace" >}} +内设置访问权限；在你创建 Role 时，你必须指定该 Role 所属的名字空间。 + +与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 +ClusterRole）是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的， +不可两者兼具。 + + +ClusterRole 有若干用法。你可以用它来： + +1. 定义对某名字空间域对象的访问权限，并将在各个名字空间内完成授权； +1. 为名字空间作用域的对象设置访问权限，并跨所有名字空间执行授权； +1. 为集群作用域的资源定义访问权限。 + +如果你希望在名字空间内定义角色，应该使用 Role； +如果你希望定义集群范围的角色，应该使用 ClusterRole。 + + +#### Role 示例 + +下面是一个位于 "default" 名字空间的 Role 的示例，可用来授予对 +{{< glossary_tooltip text="pods" term_id="pod" >}} 的读访问权限： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -117,141 +135,155 @@ metadata: namespace: default name: pod-reader rules: -- apiGroups: [""] # "" 指定核心 API 组 +- apiGroups: [""] # "" 标明 core API 组 resources: ["pods"] verbs: ["get", "watch", "list"] ``` -`ClusterRole` 可以授予的权限和 `Role` 相同， -但是因为 `ClusterRole` 属于集群范围，所以它也可以授予以下访问权限： + +### ClusterRole 示例 + +ClusterRole 可以和 Role 相同完成授权。 +因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限： + +* 集群范围资源（比如 {{< glossary_tooltip text="节点（Node）" term_id="node" >}}） +* 非资源端点（比如 `/healthz`） +* 跨名字空间访问的名字空间作用域的资源（如 Pods），比如，你可以使用 + ClusterRole 来允许某特定用户执行 `kubectl get pods --all-namespaces` + + +下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 +{{< glossary_tooltip text="Secret" term_id="secret" >}} 授予读访问权限， +或者跨名字空间的访问权限（取决于该角色是如何[绑定](#rolebinding-and-clusterrolebinding)的）： ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: - # 此处的 "namespace" 被省略掉是因为 ClusterRoles 是没有命名空间的。 + # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制 name: secret-reader rules: - apiGroups: [""] + # 在 HTTP 层面，用来访问 Secret 对象的资源的名称为 "secrets" resources: ["secrets"] verbs: ["get", "watch", "list"] ``` + +Role 或 ClusterRole 对象的名称必须是合法的 +[路径区段名称](/zh/docs/concepts/overview/working-with-objects/names#path-segment-names)。 + +### RoleBinding 和 ClusterRoleBinding {#rolebinding-and-clusterrolebinding} + +角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 +它包含若干 **主体**（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 +RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。 + +一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 +或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 +RoleBinding 所在的名字空间。 +如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。 + +RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的 +[路径区段名称](/zh/docs/concepts/overview/working-with-objects/names#path-segment-names)。 + + -### RoleBinding 和 ClusterRoleBinding +#### RoleBinding 示例 {#rolebinding-example} -角色绑定（RoleBinding）是将角色中定义的权限赋予一个或者一组用户。 -它包含若干主体（用户，组和服务账户）的列表和对这些主体所获得的角色的引用。 -可以使用 `RoleBinding` 在指定的命名空间中执行授权， -或者在集群范围的命名空间使用 `ClusterRoleBinding` 来执行授权。 - -一个 `RoleBinding` 可以引用同一的命名空间中的 `Role` 。 -下面的例子 `RoleBinding` 将 "pod-reader" 角色授予在 "default" 命名空间中的用户 "jane"； -这样，用户 "jane" 就具有了读取 "default" 命名空间中 pods 的权限。 - -`roleRef` 里的内容决定了实际创建绑定的方法。`kind` 可以是 `Role` 或 `ClusterRole`， -`name` 将引用你要指定的 `Role` 或 `ClusterRole` 的名称。在下面的例子中，角色绑定使用 -`roleRef` 将用户 "jane" 绑定到前文创建的角色 `Role`，其名称是 `pod-reader`。 +下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 +这样，用户 "jane" 就具有了读取 "default" 名字空间中 pods 的权限。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# 此角色绑定使得用户 "jane" 能够读取 "default" 命名空间中的 Pods +# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods kind: RoleBinding metadata: name: read-pods namespace: default subjects: +# 你可以指定不止一个“subject（主体）” - kind: User - name: jane # Name is case sensitive + name: jane # "name" 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: - kind: Role #this must be Role or ClusterRole - name: pod-reader # 这里的名称必须与你想要绑定的 Role 或 ClusterRole 名称一致 + # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系 + kind: Role # 此字段必须是 Role 或 ClusterRole + name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 apiGroup: rbac.authorization.k8s.io ``` -`RoleBinding` 也可以引用 `ClusterRole`，对 `ClusterRole` 所定义的、位于 `RoleBinding` 命名空间内的资源授权。 -这可以允许管理者在 -整个集群中定义一组通用的角色，然后在多个命名空间中重用它们。 - -例如下面的例子，`RoleBinding` 指定的是 `ClusterRole`， -"dave" （主体，区分大小写）将只可以读取在"development" -命名空间（ `RoleBinding` 的命名空间）中的"secrets"。 +RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 +RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， +之后在多个名字空间中复用。 +例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，"dave"（这里的主体， +不区分大小写）只能访问 "development" 名字空间中的 Secrets 对象，因为 RoleBinding +所在的名字空间（由其 metadata 决定）是 "development"。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。 +# 此角色绑定使得用户 "dave" 能够读取 "default" 名字空间中的 Secrets +# 你需要一个名为 "secret-reader" 的 ClusterRole kind: RoleBinding metadata: name: read-secrets - namespace: development # 这里只授予 "development" 命名空间的权限。 + # RoleBinding 的名字空间决定了访问权限的授予范围。 + # 这里仅授权在 "development" 名字空间内的访问权限。 + namespace: development subjects: - kind: User - name: dave # 名称区分大小写 + name: dave # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole @@ -260,19 +292,27 @@ roleRef: ``` +#### ClusterRoleBinding 示例 {#clusterrolebinding-example} + +要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。 +下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 +Secrets。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. +# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group - name: manager # Name is case sensitive + name: manager # 'name' 是不区分大小写的 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole @@ -280,11 +320,21 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -You cannot modify which `Role` or `ClusterRole` a binding object refers to. -Attempts to change the `roleRef` field of a binding object will result in a validation error. -To change the `roleRef` field on an existing binding object, the binding object must be deleted and recreated. -There are two primary reasons for this restriction: + +创建了绑定之后，你不能再修改绑定对象所引用的 Role 或 ClusterRole。 +试图改变绑定对象的 `roleRef` 将导致合法性检查错误。 +如果你想要改变现有绑定对象中 `roleRef` 字段的内容，必须删除重新创建绑定对象。 + +这种限制有两个主要原因： + + +1. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 `roleRef`, + 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许修改 + `roleRef` 的情况下导致所有现有主体胃镜验证即被授予新角色对应的权限）。 +1. 将 `roleRef` 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 `update` 权限， + 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。 + - -最后，`ClusterRoleBinding` 可用来在集群级别或对所有命名空间执行授权。 -下面的例子允许 "manager" 组中的任何用户读取任意命名空间中 "secrets"。 - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -# 这个集群角色绑定允许 "manager" 组中的任何用户读取任意命名空间中 "secrets"。 -kind: ClusterRoleBinding -metadata: - name: read-secrets-global -subjects: -- kind: Group - name: manager # 名称区分大小写 - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: secret-reader - apiGroup: rbac.authorization.k8s.io -``` - -你不能修改绑定对象所引用的 `Role` 或 `ClusterRole` 。 -试图改变绑定对象的 `roleRef` 将导致验证错误。想要 -改变现有绑定对象中 `roleRef` 字段的内容，必须删除并 -重新创建绑定对象。这种限制有两个主要原因： - -1.关于不同角色的绑定是完全不一样的。更改 `roleRef` - 需要删除/重建绑定，确保要赋予绑定的完整主体列表是新 -的角色（而不是只是启用修改 `roleRef` 在不验证所有现有 -主体的情况下的，应该授予新角色对应的权限）。 - -2.使得 `roleRef` 不可以改变现有绑定主体用户的 `update` 权限， -这样可以让它们能够管理主体列表，而不能更改授予这些主体相关 -的角色。 - 命令 `kubectl auth reconcile` 可以创建或者更新包含 RBAC 对象的清单文件， 并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。 更多相关信息请参照[命令用法和示例](#kubectl-auth-reconcile) @@ -339,42 +362,33 @@ roleRef: -### 对资源的引用 +### 对资源的引用 {#referring-to-resources} -大多数资源都是使用名称的字符串表示，例如在相关的 API 端点的 URL 之中出现的 "pods" 。 -然而有一些 Kubernetes API 涉及 "子资源（subresources）"，例如 pod 的日志。Pod 日志相关的端点 URL 如下： +在 Kubernetes API 中，大多数资源都是使用对象名称的字符串表示来呈现与访问的。 +例如，对于 Pod 应使用 "pods"。 +RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 +有一些 Kubernetes API 涉及 **子资源（subresource）**，例如 Pod 的日志。 +对 Pod 日志的请求看起来像这样： ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -在这种情况下，"pods" 是有命名空间的资源，而 "log" 是 pods 的子资源。在 RBAC 角色中， -使用"/"分隔资源和子资源。允许一个主体要同时读取 pods 和 pod logs，你可以这么写： - + +在这里，`pods` 对应名字空间作用域的 Pod 资源，而 `log` 是 `pods` 的子资源。 +在 RBAC 角色表达子资源时，使用斜线（`/`）来分隔资源和子资源。 +要允许某主体读取 `pods` 同时访问这些 Pod 的 `log` 子资源，你可以这么写： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -389,29 +403,15 @@ rules: ``` 对于某些请求，也可以通过 `resourceNames` 列表按名称引用资源。 -在指定时，可以将请求类型限制资源的单个实例。限制只可以 "get" 和 "update" -的单一configmap，你可以这么写： +在指定时，可以将请求限定为资源的单个实例。 +下面的例子中限制可以 "get" 和 "update" 一个名为 `my-configmap` 的 +{{< glossary_tooltip term_id="ConfigMap" >}}： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -421,56 +421,42 @@ metadata: name: configmap-updater rules: - apiGroups: [""] + # 在 HTTP 层面，用来访问 ConfigMap 的资源的名称为 "configmaps" resources: ["configmaps"] resourceNames: ["my-configmap"] verbs: ["update", "get"] ``` -需要注意的是，`create` 请求不能被 resourceName 限制，因为在鉴权时还不知道对象名称。 -另一个例外是 `deletecollection`。 - +{{< note >}} +你不能针对 `create` 或者 `deletecollection` 请求来实施 resourceName 限制。 +对于 `create` 操作而言，这是因为在鉴权时还不知道对象名称。 +{{< /note >}} + + +### 聚合的 ClusterRole {#aggregated-clusterroles} + +你可以将若干 ClusterRole **聚合（Aggregate）** 起来，形成一个复合的 ClusterRole。 +某个控制器作为集群控制面的一部分会监视带有 `aggregationRule` 的 ClusterRole +对象集合。`aggregationRule` 为控制器定义一个标签 +{{< glossary_tooltip text="选择算符" term_id="selector" >}}供后者匹配 +应该组合到当前 ClusterRole 的 `roles` 字段中的 ClusterRole 对象。 + +下面是一个聚合 ClusterRole 的示例： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -481,12 +467,19 @@ aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-monitoring: "true" -rules: [] # 具体规则由控制器管理器自动填写。 +rules: [] # 控制面自动填充这里的规则 ``` -创建一个与标签选择器匹配的 ClusterRole 之后，其上定义的规则将成为聚合集群角色的一部分。在下面的例子中， -通过创建一个新的、标签同样为 `rbac.example.com/aggregate-to-monitoring: true` 的 -ClusterRole，新的规则可被添加到 "monitoring" 集群角色中。 + +如果你创建一个与某现有聚合 ClusterRole 的标签选择算符匹配的 ClusterRole， +这一变化会触发新的规则被添加到聚合 ClusterRole 的操作。 +下面的例子中，通过创建一个标签同样为 `rbac.example.com/aggregate-to-monitoring: true` +的 ClusterRole，新的规则可被添加到 "monitoring" ClusterRole 中。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -495,7 +488,8 @@ metadata: name: monitoring-endpoints labels: rbac.example.com/aggregate-to-monitoring: "true" -# 这些规则将被添加到 "monitoring" 角色中。 +# 当你创建 "monitoring-endpoints" ClusterRole 时， +# 下面的规则会被添加到 "monitoring" ClusterRole 中 rules: - apiGroups: [""] resources: ["services", "endpoints", "pods"] @@ -503,12 +497,22 @@ rules: ``` +默认的[面向用户的角色](#default-roles-and-role-bindings) 使用 ClusterRole 聚合。 +这使得作为集群管理员的你可以为扩展默认规则，包括为定制资源设置规则， +比如通过 CustomResourceDefinitions 或聚合 API 服务器提供的定制资源。 + +例如，下面的 ClusterRoles 让默认角色 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， + "view" 角色对 CronTab 资源拥有读操作权限。 +你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 `"crontabs"`。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -516,7 +520,7 @@ kind: ClusterRole metadata: name: aggregate-cron-tabs-edit labels: - # Add these permissions to the "admin" and "edit" default roles. + # 添加以下权限到默认角色 "admin" 和 "edit" 中 rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rules: @@ -529,41 +533,7 @@ apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view labels: - # Add these permissions to the "view" default role. - rbac.authorization.k8s.io/aggregate-to-view: "true" -rules: -- apiGroups: ["stable.example.com"] - resources: ["crontabs"] - verbs: ["get", "list", "watch"] -``` ---> - -默认的面向用户的角色（如下所述）使用 ClusterRole 聚合。这使得管理者可以为自定义资源设置使用规则属性， -比如通过 CustomResourceDefinitions 或聚合 API 服务器为默认角色提供的服务。 - -例如，在以下 ClusterRoles 中让 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， - "view" 角色对资源有只读操作权限。 - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: aggregate-cron-tabs-edit - labels: - # 将这些权限添加到默认角色 "admin" 和 "edit" 中。 - rbac.authorization.k8s.io/aggregate-to-admin: "true" - rbac.authorization.k8s.io/aggregate-to-edit: "true" -rules: -- apiGroups: ["stable.example.com"] - resources: ["crontabs"] - verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ---- -kind: ClusterRole -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: aggregate-cron-tabs-view - labels: - # 将这些权限添加到默认角色 "view" 中。 + # 添加以下权限到 "view" 默认角色中 rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: ["stable.example.com"] @@ -574,50 +544,33 @@ rules: -#### 角色示例 +#### Role 示例 {#role-examples} -在以下示例中，我们仅截取展示了 `rules` 对应部分， -允许读取在核心 {{< glossary_tooltip text="API 组" term_id="api-group" >}}下的 Pods: +以下示例均为从 Role 或 CLusterRole 对象中截取出来，我们仅展示其 `rules` 部分。 + +允许读取在核心 {{< glossary_tooltip text="API 组" term_id="api-group" >}}下的 +`"Pods"`： ```yaml rules: - apiGroups: [""] + # 在 HTTP 层面，用来访问 Pod 的资源的名称为 "pods" resources: ["pods"] verbs: ["get", "list", "watch"] ``` -允许读/写在 "extensions" 和 "apps" API 组中的 "deployments" 资源： + +允许读/写在 "extensions" 和 "apps" API 组中的 Deployment（在 HTTP 层面，对应 +URL 中资源部分为 "deployments"）： ```yaml rules: @@ -626,7 +579,12 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -允许读取 "pods" 和读/写 "jobs" : + +允许读取核心 API 组中的 "pods" 和读/写 `"batch"` 或 `"extensions"` API 组中的 +"jobs"： ```yaml rules: @@ -639,34 +597,11 @@ rules: ``` -允许读取名称为 "my-config"的 `ConfigMap` （需要通过 `RoleBinding` 绑定带某名字空间中特定的 `ConfigMap`）： +允许读取名称为 "my-config" 的 ConfigMap（需要通过 RoleBinding 绑定以 +限制为某名字空间中特定的 ConfigMap）： ```yaml rules: @@ -676,7 +611,13 @@ rules: verbs: ["get"] ``` -允许读取在核心组中的 "nodes" 资源（因为 `Node` 是集群范围的，所以需要 `ClusterRole` 绑定到 `ClusterRoleBinding` 才生效） + +允许读取在核心组中的 "nodes" 资源（因为 `Node` 是集群作用域的，所以需要 +ClusterRole 绑定到 ClusterRoleBinding 才生效）： ```yaml rules: @@ -685,89 +626,98 @@ rules: verbs: ["get", "list", "watch"] ``` -允许在非资源端点 "/healthz" 和其子路径上发起 "GET" 和 "POST" 请求（必须在 `ClusterRole` 绑定 `ClusterRoleBinding` 才生效） + +允许针对非资源端点 `/healthz` 和其子路径上发起 GET 和 POST 请求 +（必须在 ClusterRole 绑定 ClusterRoleBinding 才生效）： ```yaml rules: -- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' 在 nonResourceURL 中的意思是后缀全局匹配。 - verbs: ["get", "post"] + - nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符 + verbs: ["get", "post"] ``` +### 对主体的引用 {#referring-to-subjects} -Group information in Kubernetes is currently provided by the Authenticator -modules. Groups, like users, are represented as strings, and that string -has no format requirements, other than that the prefix `system:` is reserved. +RoleBinding 或者 ClusterRoleBinding 可绑定角色到某 *主体（Subject）*上。 +主体可以是组，用户或者 +{{< glossary_tooltip text="服务账号" term_id="service-account" >}}。 + +Kubernetes 用字符串来表示用户名。 +用户名可以是普通的用户名，像 "alice"；或者是邮件风格的名称，如 "bob@example.com"， +或者是以字符串形式表达的数字 ID。 +你作为 Kubernetes 管理员负责配置 +[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/) +以便后者能够生成你所期望的格式的用户名。 + + +{{< caution >}} + +前缀 `system:` 是 Kubernetes 系统保留的，所以你要确保 +所配置的用户名或者组名不能出现上述 `system:` 前缀。 +除了对前缀的限制之外，RBAC 鉴权系统不对用户名格式作任何要求。 +{{< /caution >}} + + -### 对主体的引用 +在 Kubernetes 中，鉴权模块提供用户组信息。 +与用户名一样，用户组名也用字符串来表示，而且对该字符串没有格式要求， +只是不能使用保留的前缀 `system:`。 -`RoleBinding` 或者 `ClusterRoleBinding` 需要绑定角色到 *主体*。 -主体可以是组，用户或者服务账户。 +[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +的用户名前缀为 `system:serviceaccount:`，属于前缀为 `system:serviceaccounts:` +的用户组。 -用户是由字符串表示，它们可以是普通的用户名，像 "alice"，或者是 -邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/) -需要的格式。RBAC 鉴权系统不对格式作任何要求，但是前缀 `system:` 是 Kubernetes 系统保留的， -所以管理员要确保配置的用户名不能出现上述前缀格式。 - -用户组信息是 Kubernetes 现在提供的一种身份验证模块，与用户一样，对组的字符串没有格式要求， -只是不能使用保留的前缀 `system:` 。 - -[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`， -属于前缀为 `system:serviceaccounts:` 的用户组。 +{{< note >}} + +- `system:serviceaccount:` （单数）是用于服务账号用户名的前缀； +- `system:serviceaccounts:` （复数）是用于服务账号组名的前缀。 +{{< /note >}} -#### RoleBinding的示例 +#### RoleBinding 示例 {#role-binding-examples} -下面的示例只是展示 `RoleBinding` 中 `subjects` 的部分。 +下面示例是 `RoleBinding` 中的片段，仅展示其 `subjects` 的部分。 -用户的名称为 "alice@example.com": +对于名称为 `alice@example.com` 的用户： ```yaml subjects: @@ -776,7 +726,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -组的名称为 "frontend-admins": + +对于名称为 `frontend-admins` 的用户组： ```yaml subjects: @@ -785,7 +738,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -服务账号在 kube-system 命名空间中: + +对于 `kube-system` 名字空间中的默认服务账号： ```yaml subjects: @@ -794,17 +750,10 @@ subjects: namespace: kube-system ``` -在名称为 "qa" 命名空间中所有的服务账号: - -```yaml -subjects: -- kind: Group - name: system:serviceaccounts:qa - apiGroup: rbac.authorization.k8s.io -``` - +对于 "qa" 名字空间中所有的服务账号： ```yaml subjects: @@ -813,47 +762,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all service accounts everywhere: - -```yaml -subjects: -- kind: Group - name: system:serviceaccounts - apiGroup: rbac.authorization.k8s.io -``` - -For all authenticated users (version 1.5+): - -```yaml -subjects: -- kind: Group - name: system:authenticated - apiGroup: rbac.authorization.k8s.io -``` - -For all unauthenticated users (version 1.5+): - -```yaml -subjects: -- kind: Group - name: system:unauthenticated - apiGroup: rbac.authorization.k8s.io -``` - -For all users (version 1.5+): - -```yaml -subjects: -- kind: Group - name: system:authenticated - apiGroup: rbac.authorization.k8s.io -- kind: Group - name: system:unauthenticated - apiGroup: rbac.authorization.k8s.io -``` + - -所有的服务账号: +对于在任何名字空间中的服务账号： ```yaml subjects: @@ -862,7 +774,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -所有认证过的用户 （版本 1.5+）: + +对于所有已经过认证的用户： ```yaml subjects: @@ -871,7 +786,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -所有未认证的用户 （版本 1.5+）: + +对于所有未通过认证的用户： ```yaml subjects: @@ -880,7 +798,10 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -所有用户 （版本 1.5+）: + +对于所有用户： ```yaml subjects: @@ -893,64 +814,95 @@ subjects: ``` ## 默认 Roles 和 Role Bindings -API servers创建一组默认为 `ClusterRole` 和 `ClusterRoleBinding` 的对象。 -其中许多是以 `system:` 为前缀的，它表示资源是基础设施 "owned" 的。对于这些资源的修改可能导致集群功能失效。 -例如，`system:node` 是集群角色，它是定义 kubelets 相关的权限，如果这个角色被修改，它将导致 kubelets 无法正常工作。 +API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 +这其中许多是以 `system:` 为前缀的，用以标识对应资源是直接由集群控制面管理的。 +所有的默认 ClusterRole 和 ClusterRoleBinding 都有 +`kubernetes.io/bootstrapping=rbac-defaults` +标签。 -所有默认的 ClusterRole 和 ClusterRoleBinding 对象都会被标记为 `kubernetes.io/bootstrapping=rbac-defaults`。 +{{< caution >}} + +在修改名称包含 `system:` 前缀的 ClusterRole 和 ClusterRoleBinding +时要格外小心。 +对这些资源的更改可能导致集群无法继续工作。 +{{< /caution >}} -### 自动更新 +### 自动协商 {#auto-reconciliation} -在每次启动时，API Server 都会更新默认 ClusterRole 所缺少的各种权限，并更新默认 ClusterRoleBinding 所缺少的各个角色绑定主体。 -这种自动更新机制允许集群去修复一些特殊的修改。 -由于权限和角色绑定主体在新的 Kubernetes 版本中可能发生变化，所以这样的话也能够保证角色和角色绑定始终保持是最新的。 +在每次启动时，API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限，并更新 +默认的 ClusterRoleBinding 以增加缺失的的各类主体。 +这种自动协商机制允许集群去修复一些不小心发生的修改，并且有助于保证角色和角色绑定 +在新的发行版本中有权限或主体变更时仍然保持最新。 -如果要禁止此功能,请将默认ClusterRole以及ClusterRoleBinding的`rbac.authorization.kubernetes.io/autoupdate`设置成`false`。 +如果要禁止此功能，请将默认 ClusterRole 以及 ClusterRoleBinding 的 +`rbac.authorization.kubernetes.io/autoupdate` 注解设置成 `false`。 +注意，缺少默认权限和角色绑定主体可能会导致集群无法正常工作。 -注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。 - -自动更新功能在 Kubernetes 版本1.6+ 的 RBAC 认证是默认开启的。 +如果基于 RBAC 的鉴权机制被启用，则自动协商功能默认是被启用的。 +### API 发现角色 {#discovery-roles} -``` +无论是经过身份验证的还是未经过身份验证的用户，默认的角色绑定都授权他们读取被认为 +是可安全地公开访问的 API（ 包括 CustomResourceDefinitions）。 +如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中中添加 +`--anonymous-auth=false` 的配置选项。 + +通过运行命令 `kubectl` 可以查看这些角色的配置信息: + +```shell kubectl get clusterroles system:discovery -o yaml ``` -NOTE: editing the role is not recommended as changes will be overwritten on API server restart via auto-reconciliation (see above). +{{< note >}} + +如果你编辑该 ClusterRole，你所作的变更会被 API 服务器在重启时自动覆盖，这是通过 +[自动协商](#auto-reconciliation)机制完成的。要避免这类覆盖操作， +要么不要手动编辑这些角色，要么禁止自动协商机制。 +{{< /note >}} + + + -### Discovery Roles - -无论是经过身份验证的还是未经过身份验证的用户，默认角色的用户读取API被认为是安全的，可以公开访问（包括CustomResourceDefinitions）， -如果要禁用匿名未经过身份验证的用户访问，请在 API server 中添加 `--anonymous-auth=false` 的配置选项。 - -通过运行命令 `kubectl` 可以查看这些角色的配置信息: - -``` -kubectl get clusterroles system:discovery -o yaml -``` - -注意：不建议编辑这个角色，因为更改将在 API server 重启时自动更新时覆盖（见上文） - -
Kubernetes RBAC API 发现角色
- - @@ -996,31 +930,44 @@ kubectl get clusterroles system:discovery -o yaml - + - + - +
默认 ClusterRole 默认 ClusterRoleBinding 描述
system:basic-user system:authenticated 组允许用户以只读的方式去访问他们自己的基本信息。在1.14版本之前，这个角色在默认情况下也绑定在 `system:unauthenticated` 上。允许用户以只读的方式去访问他们自己的基本信息。在 1.14 版本之前，这个角色在 +默认情况下也绑定在 system:unauthenticated 上。
system:discovery system:authenticated 组允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。在1.14版本之前，这个角色在默认情况下绑定在 `system:unauthenticated` 上。允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。 +在 1.14 版本之前，这个角色在默认情况下绑定在 system:unauthenticated 上。
system:public-info-viewer system:authenticated 和 system:unauthenticated 组允许对集群的非敏感信息进行只读访问，它是在1.14版本中引入的。允许对集群的非敏感信息进行只读访问，它是在 1.14 版本中引入的。
+### 面向用户的角色 {#user-facing-roles} + +一些默认的 ClusterRole 不是以前缀 `system:` 开头的。这些是面向用户的角色。 +它们包括超级用户（Super-User）角色（`cluster-admin`）、 +使用 ClusterRoleBinding 在集群范围内完成授权的角色（`cluster-status`）、 +以及使用 RoleBinding 在特定名字空间中授予的角色（`admin`、`edit`、`view`）。 + +面向用户的 ClusterRole 使用 [ClusterRole 聚合](#aggregated-clusterroles)以允许管理员在 +这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 `admin`、`edit` 或者 `view`， +可以创建带有以下一个或多个标签的 ClusterRole： ```yaml metadata: @@ -1033,425 +980,352 @@ metadata: + -### 面向用户的角色 - -一些默认的角色不是前缀 `system:` 开头的。这些是面向用户的角色。它们包括 super-user 角色（`cluster-admin`）， -使用 ClusterRoleBindings （`cluster-status`）在集群范围内授予角色， -以及使用 RoleBindings （`admin`, `edit`, `view`）在特定命名空间中授予的角色。 - -在 1.9 开始，面向用户的角色使用[ClusterRole Aggregation](#aggregated-clusterroles)允许管理员在包含这些角色上的 -自定义资源上添加规则。如果想要添加 "admin" "edit" 或者 "view" ，需要先创建使用以下一个或多个的 ClusterRole 的标签： - -```yaml -metadata: - labels: - rbac.authorization.k8s.io/aggregate-to-admin: "true" - rbac.authorization.k8s.io/aggregate-to-edit: "true" - rbac.authorization.k8s.io/aggregate-to-view: "true" -``` - -
- - - + - + + + - + + + - + + + + - + +
默认 ClusterRole 默认 ClusterRoleBinding 描述
cluster-admin system:masters 组允许超级用户在平台上的任何资源的所有操作。 -当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有命名空间中的全部资源进行完全控制。 -当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在命名空间中的所有资源，包括命名空间本身。允许超级用户在平台上的任何资源上执行所有操作。 +当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有名字空间中的全部资源进行完全控制。 +当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在名字空间中的所有资源，包括名字空间本身。
admin 无允许管理员访问权限，旨在使用 RoleBinding 在命名空间内执行授权。 -如果在 RoleBinding 中使用，则可授予对命名空间中的大多数资源的读/写权限， -包括创建角色和绑定角色（RoleBinding）的能力。 -但是它不允许对资源配额或者命名空间本身进行写操作。允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。 +如果在 RoleBinding 中使用，则可授予对名字空间中的大多数资源的读/写权限， +包括创建角色和角色绑定的能力。 +但是它不允许对资源配额或者名字空间本身进行写操作。
edit 无允许对命名空间的大多数对象进行读/写操作。 -它不允许查看或者修改角色（Roles）或者角色绑定（RoleBindings）。允许对名字空间的大多数对象进行读/写操作。 +它不允许查看或者修改角色或者角色绑定。 +不过，此角色可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pods， +所以可以用来了解名字空间内所有服务账号的 API 访问级别。 +
view 无允许对命名空间的大多数对象有只读权限。 -它不允许查看角色（Roles）或角色绑定（RoleBindings）。 -它不允许查看 Secrets，因为这类操作属于越权。允许对名字空间的大多数对象有只读权限。 +它不允许查看角色或角色绑定。 + +此角色不允许查看 Secrets，因为读取 Secret 的内容意味着可以访问名字空间中 +ServiceAccount 的凭据信息，进而允许利用名字空间中任何 ServiceAccount 的 +身份访问 API（这是一种特权提升）。
+### 核心组件角色 {#core-component-roles} + - + + - + + - + + - - -As of 1.7, use of the Node authorizer and NodeRestriction admission plugin is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them. -Prior to 1.7, this role was automatically bound to the `system:nodes` group. -In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled. -In 1.8+, no binding is automatically created. + + - - -
system:kube-scheduler system:kube-scheduler userAllows access to the resources required by the kube-scheduler component.允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} +组件所需要的资源。
system:volume-scheduler system:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.允许访问 kube-scheduler 组件所需要的卷资源。
system:kube-controller-manager system:kube-controller-manager userAllows access to the resources required by the kube-controller-manager component. -The permissions required by individual control loops are contained in the controller roles.允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}} +组件所需要的资源。 +各个控制回路所需要的权限在控制器角色 详述。
system:nodeNone in 1.8+Allows access to resources required by the kubelet component, including read access to all secrets, and write access to all pod status objects. + +无允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。 + +你应该使用 Node 鉴权组件 和 +NodeRestriction 准入插件 +而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 +kubelet 对 API 的访问。 +system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。
system:node-proxier system:kube-proxy userAllows access to the resources required by the kube-proxy component.
---> -### 核心组件角色 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
默认 ClusterRole默认 ClusterRoleBinding描述
system:kube-schedulersystem:kube-scheduler 用户允许访问 kube-scheduler 组件所需要的资源。
system:volume-schedulersystem:kube-scheduler 用户允许访问 kube-scheduler 组件所需要的的卷资源。
system:kube-controller-managersystem:kube-controller-manager 用户允许访问 kube-controller-manager 组件所需要的资源。 -各个控制环所需要的权限包含在 controller roles 之中。
system:node在版本1.8之后无允许访问 kubelet 组件所需要的资源，它包括读取所有的 Secrets 和对所有 Pod 状态对象的写操作。 - -从版本 1.7 开始，推荐使用 Node authorizer 和 NodeRestriction 准入插件 来代替这个角色，它允许基于 kubelet 上调度执行的 Pods 来授权对 kubelet API 的访问。 -在版本 1.7 之前，这个角色会自动绑定到 `system:nodes` 组。 -在版本 1.7中，如果未启用`Node` 鉴权模式，这个角色将自动绑定到 `system:nodes` 组 -在版本 1.8+ 之后，不再自动创建绑定。 -
system:node-proxiersystem:kube-proxy 用户允许访问 kube-proxy 组件所需要的资源。允许访问 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +组件所需要的资源。
-### 其他组件角色 +### 其他组件角色 {#other-component-roles} + + - + + + - + + + + - + + + + - + + + + +kubelet TLS 启动引导 +所需要的资源。 + + + - + +
默认 ClusterRole 默认 ClusterRoleBinding 描述
system:auth-delegator 无允许代理身份认证和鉴权， -它通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。允许将身份认证和鉴权检查操作外包出去。 +这种角色通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。
system:heapster 无为 Heapster 组件定义的角色。为 Heapster 组件（已弃用）定义的角色。
system:kube-aggregator 无 为 kube-aggregator 组件定义的角色。
system:kube-dns在kube-system命名空间中的kube-dns服务账号在 kube-system 名字空间中的 kube-dns 服务账号 为 kube-dns 组件定义的角色。
system:kubelet-api-admin 无允许完全访问 kubelet API 。允许 kubelet API 的完全访问权限。
system:node-bootstrapper 无 允许访问执行 -Kubelet TLS 启动引导 所需要的资源。
system:node-problem-detector 无 为 node-problem-detector 组件定义的角色。
system:persistent-volume-provisioner 无允许访问大部分的 动态卷驱动 所需要的资源。允许访问大部分 +动态卷驱动 +所需要的资源。
-### 控制器角色 {#controller-roles} +### 内置控制器的角色 {#controller-roles} -[Kubernetes 控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 运行核心控制环。 -当使用 `--use-service-account-credentials` 参数时, 每个控制环使用一个单独的服务账号启动。 -每个控制环都有相应的、前缀为 `system:controller:` 的角色。 +Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}} +运行内建于 Kubernetes 控制面的{{< glossary_tooltip term_id="controller" text="控制器" >}}。 +当使用 `--use-service-account-credentials` 参数启动时, kube-controller-manager +使用单独的服务账号来启动每个控制器。 +每个内置控制器都有相应的、前缀为 `system:controller:` 的角色。 如果控制管理器启动时未设置 `--use-service-account-credentials`， -它使用自己的身份信息来运行所有的控制环，该身份必须被授予所有相关的角色。 +它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。 这些角色包括: -* system:controller:attachdetach-controller -* system:controller:certificate-controller -* system:controller:clusterrole-aggregation-controller -* system:controller:cronjob-controller -* system:controller:daemon-set-controller -* system:controller:deployment-controller -* system:controller:disruption-controller -* system:controller:endpoint-controller -* system:controller:expand-controller -* system:controller:generic-garbage-collector -* system:controller:horizontal-pod-autoscaler -* system:controller:job-controller -* system:controller:namespace-controller -* system:controller:node-controller -* system:controller:persistent-volume-binder -* system:controller:pod-garbage-collector -* system:controller:pv-protection-controller -* system:controller:pvc-protection-controller -* system:controller:replicaset-controller -* system:controller:replication-controller -* system:controller:resourcequota-controller -* system:controller:root-ca-cert-publisher -* system:controller:route-controller -* system:controller:service-account-controller -* system:controller:service-controller -* system:controller:statefulset-controller -* system:controller:ttl-controller +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` -## 初始化与预防权限升级 +## 初始化与预防权限提升 -RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 -由于这一点是在 API 级别实现的，所以在 RBAC 鉴权器（RBAC authorizer）未启用的状态下依然可以正常工作。 - -用户只有在符合下列条件之一的情况下，才能创建/更新角色: - - -1. 他们已经拥有角色中包含的所有权限，且其作用域与正被修改的对象相同。 -（对 `ClusterRole` 而言意味着集群范围，对 `Role` 而言意味着相同命名空间或者集群范围） -2. 他们被明确允许在 `rbac.authorization.k8s.io` API 组中的 `roles` 或者 `clusterroles` 资源上使用 `escalate` 动词（Kubernetes 版本 1.12 及以上） - -例如，如果 "user-1" 没有列举集群范围所有 Secrets 的权限，他将不能创建包含对应权限的 `ClusterRole`。 -若要允许用户创建/更新角色： - -根据需要授予他们一个角色，允许他们根据需要创建/更新 `Role` 或者 `ClusterRole` 对象。 -2. 授予他们在所创建/更新角色中包含特殊权限的权限: - * 隐式的，通过给他们权限（如果它们试图创建或者更改 `Role` 或 `ClusterRole` 的权限，但自身没有被授权，API 请求将被禁止） - * 或通过允许他们在 `Role` 或 `ClusterRole` 资源上执行 `escalate` 动作的权限，它包含在 `rbac.authorization.k8s.io` API 组中 （Kubernetes 1.12 及以上版本） - -如果用户已经拥有引用角色中包含的权限，那他则只能创建/更新角色绑定。 -（在角色绑定相同的作用域内）*或* 如果他们被授予对所引用角色执行 `bind` 操作的显式权限。 -例如，如果 "user-1" 没有集群范围内 Secret 的列表权限，他就不能创建可以授予角色权限的 `ClusterRoleBinding`。 -通过以下方法可以允许用户创建/更新角色绑定： - -授予他们一个角色，允许他们根据需要创建/更新 `RoleBinding` 或者`ClusterRoleBinding` 对象。 -2. 授予他们绑定特定角色所需的权限: - * 隐式地，通过给他们授予角色中包含的权限。 - * 显式地，通过允许他们对特定角色（或集群角色）执行`bind` 操作的权限。 +RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。 +由于这一点是在 API 级别实现的，所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。 +### 对角色创建或更新的限制 + +只有在符合下列条件之一的情况下，你才能创建/更新角色: + +1. 你已经拥有角色中包含的所有权限，且其作用域与正被修改的对象作用域相同。 + （对 ClusterRole 而言意味着集群范围，对 Role 而言意味着相同名字空间或者集群范围）。 +2. 你被显式授权在 `rbac.authorization.k8s.io` API 组中的 `roles` 或 `clusterroles` 资源 + 使用 `escalate` 动词。 + + +例如，如果 `user-1` 没有列举集群范围所有 Secret 的权限，他将不能创建包含该权限的 ClusterRole。 +若要允许用户创建/更新角色： + +1. 根据需要赋予他们一个角色，允许他们根据需要创建/更新 Role 或者 ClusterRole 对象。 +2. 授予他们在所创建/更新角色中包含特殊权限的权限: + * 隐式地为他们授权（如果它们试图创建或者更改 Role 或 ClusterRole 的权限， + 但自身没有被授予相应权限，API 请求将被禁止）。 + * 通过允许他们在 Role 或 ClusterRole 资源上执行 `escalate` 动作显式完成授权。 + 这里的 `roles` 和 `clusterroles` 资源包含在 `rbac.authorization.k8s.io` API 组中。 + + +### 对角色绑定创建或更新的限制 + +只有你已经具有了所引用的角色中包含的全部权限时，或者你被授权在所引用的角色上执行 `bind` +动词时，你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。 +例如，如果用户 `user-1` 没有列举集群范围所有 Secret 的能力，则他不可以创建 +ClusterRoleBinding 引用授予该许可权限的角色。 +如要允许用户创建或更新角色绑定： + + +1. 赋予他们一个角色，使得他们能够根据需要创建或更新 RoleBinding 或 ClusterRoleBinding + 对象。 +2. 授予他们绑定某特定角色所需要的许可权限： + * 隐式授权下，可以将角色中包含的许可权限授予他们； + * 显式授权下，可以授权他们在特定 Role （或 ClusterRole）上执行 `bind` 动词的权限。 + +例如，下面的 ClusterRole 和 RoleBinding 将允许用户 `user-1` 把名字空间 `user-1-namespace` +中的 `admin`、`edit` 和 `view` 角色赋予其他用户： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -1465,7 +1339,7 @@ rules: - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["bind"] - # omit resourceNames to allow binding any ClusterRole + # 忽略 resourceNames 意味着允许绑定任何 ClusterRole resourceNames: ["admin","edit","view"] --- apiVersion: rbac.authorization.k8s.io/v1 @@ -1483,48 +1357,20 @@ subjects: name: user-1 ``` + -例如，这个集群角色和角色绑定将允许 "user-1" 有对"user-1-namespace" 命名空间中的角色执行 `admin`、`edit` 和 `view` 操作权限： +当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 +对初始角色和角色绑定进行初始化时需要： -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: role-grantor -rules: -- apiGroups: ["rbac.authorization.k8s.io"] - resources: ["rolebindings"] - verbs: ["create"] -- apiGroups: ["rbac.authorization.k8s.io"] - resources: ["clusterroles"] - verbs: ["bind"] - # 省略 resourceNames 则允许绑定任何 ClusterRole - resourceNames: ["admin","edit","view"] ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: RoleBinding -metadata: - name: role-grantor-binding - namespace: user-1-namespace -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: role-grantor -subjects: -- apiGroup: rbac.authorization.k8s.io - kind: User - name: user-1 -``` - -当初始化第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要： - -* 使用用户组为 `system:masters` 的凭据，该用户组由默认绑定关联到 `cluster-admin` 这个超级用户角色。 -* 如果你的 API server 启动时启用了不安全端口（使用`--insecure-port`）, 你也可以通过该端口调用 API ，这样操作会绕过身份验证或鉴权。 +* 使用用户组为 `system:masters` 的凭据，该用户组由默认绑定关联到 `cluster-admin` + 这个超级用户角色。 +* 如果你的 API 服务器启动时启用了不安全端口（使用 `--insecure-port`）, 你也可以通过 + 该端口调用 API ，这样的操作会绕过身份验证或鉴权。 ## 一些命令行工具 ### `kubectl create role` -创建 `Role` 对象，定义在某命名空间中的权限。例如: +创建 Role 对象，定义在某一名字空间中的权限。例如: -* 创建名称为 "pod-reader" 的 `Role` 对象，允许用户对 pods 执行 "get"、"watch" 和 "list" 操作： +* 创建名称为 "pod-reader" 的 Role 对象，允许用户对 Pods 执行 `get`、`watch` 和 `list` 操作： - ``` - kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods - ``` - -* 创建名称为 "pod-reader" 的 `Role` 对象并指定 resourceNames： - - ``` - kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod - ``` - -* 创建名为 "foo" 的 `Role` 对象并指定 apiGroups: - - ``` - kubectl create role foo --verb=get,list,watch --resource=replicasets.apps - ``` - -* 创建名为 "foo" 的 `Role` 对象并指定子资源权限: - - ``` - kubectl create role foo --verb=get,list,watch --resource=pods,pods/status - ``` - -* 创建名为 "my-component-lease-holder" 的 `Role` 对象，使其具有对特定名称资源执行 get/update 的权限： - - ``` - kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component - ``` + ```shell + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` +* 创建名称为 "pod-reader" 的 Role 对象并指定 `resourceNames`： + + ```shell + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + + +* 创建名为 "foo" 的 Role 对象并指定 `apiGroups`： + + ```shell + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + + +* 创建名为 "foo" 的 Role 对象并指定子资源权限: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + + +* 创建名为 "my-component-lease-holder" 的 Role 对象，使其具有对特定名称的 + 资源执行 get/update 的权限： + + ```shell + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + ### `kubectl create clusterrole` -Creates a `ClusterRole` object. Examples: + -### `kubectl create clusterrole` +创建 ClusterRole 对象。例如： -创建 `ClusterRole` 对象。例如： +* 创建名称为 "pod-reader" 的 ClusterRole`对象，允许用户对 Pods 对象执行 `get`、 + `watch` 和 `list` 操作： -* 创建名称为 "pod-reader" 的 `ClusterRole` 对象，允许用户对 pods 对象执行 "get"、"watch" 和 "list" 操作： - - ``` - kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods - ``` - -* 创建名为 "pod-reader" 的 `ClusterRole` 对象并指定资源名称： - - ``` - kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod - ``` - -* 创建名为 "foo" 的 `ClusterRole` 对象并指定 apiGroups： - - ``` - kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps - ``` - -* 创建名为 "foo" 的`ClusterRole` 对象并指定子资源: - - ``` - kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status - ``` - -* 创建名为 "foo" 的 `ClusterRole` 对象并指定非资源路径： - - ``` - kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* - ``` - -* 创建名为 "monitoring" 的 `ClusterRole` 对象并指定聚合规则： - - ``` - kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" - ``` + ```shell + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` +* 创建名为 "pod-reader" 的 ClusterRole 对象并指定 `resourceNames`： + + ```shell + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + + +* 创建名为 "foo" 的 ClusterRole 对象并指定 `apiGroups`： + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + + +* 创建名为 "foo" 的 ClusterRole 对象并指定子资源: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + + +* 创建名为 "foo" 的 ClusterRole 对象并指定 `nonResourceURL`： + + ```shell + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + + +* 创建名为 "monitoring" 的 ClusterRole 对象并指定 `aggregationRule`： + + ```shell + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + ### `kubectl create rolebinding` -Grants a `Role` or `ClusterRole` within a specific namespace. Examples: + -### `kubectl create rolebinding` +在特定的名字空间中对 `Role` 或 `ClusterRole` 授权。例如： -在特定的命名空间中对 `Role` 或 `ClusterRole` 授权。例如： +* 在名字空间 "acme" 中，将名为 `admin` 的 ClusterRole 中的权限授予名称 "bob" 的用户: -* 在命名空间 "acme" 中，将名为 `admin` 的 `ClusterRole` 中的权限授予名称 "bob" 的用户: - - ``` - kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme - ``` - -* 在命名空间 "acme"中，将名为 `view` 的 `ClusterRole` 中的权限授予该命名空间 "acme" 中名为 "myapp" 的服务账号： - - ``` - kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme - ``` - -* 在命名空间 "acme" 中，将名为 `view` 的 `ClusterRole` 对象中的权限授予命名空间 "myappnamespace" 中名称为 "myapp" 的服务账号： - - ``` - kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme - ``` + ```shell + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` -### `kubectl create clusterrolebinding` +* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 中的权限授予名字空间 "acme" + 中名为 `myapp` 的服务账号： -在整个集群、包括所有的命名空间中对 `ClusterRole` 授权。例如： - -* 在整个集群范围，将名为 `cluster-admin` 的 `ClusterRole` 中定义的权限授予名为 "root" 用户： - - ``` - kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root - ``` - -* 在整个集群范围，将名为 `system:node-proxier` 的 `ClusterRole` 的权限授予名为 "system:kube-proxy" 的用户： - - ``` - kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy - ``` - -* 在整个集群范围，将名为 `view` 的 `ClusterRole` 对象中定义的权限授予 "acme" 命名空间中名为 "myapp" 的服务账号： - - ``` - kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp - ``` + ```shell + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` +* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 对象中的权限授予名字空间 + "myappnamespace" 中名称为 `myapp` 的服务账号： + + ```shell + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + +### `kubectl create clusterrolebinding` + + +在整个集群（所有名字空间）中用 ClusterRole 授权。例如： + +* 在整个集群范围，将名为 `cluster-admin` 的 ClusterRole 中定义的权限授予名为 + "root" 用户： + + ```shell + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + + +* 在整个集群范围内，将名为 `system:node-proxier` 的 ClusterRole 的权限授予名为 + "system:kube-proxy" 的用户： + + ```shell + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + + +* 在整个集群范围内，将名为 `view` 的 ClusterRole 中定义的权限授予 "acme" 名字空间中 + 名为 "myapp" 的服务账号： + + ```shell + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + ### `kubectl auth reconcile` {#kubectl-auth-reconcile} + -### `kubectl auth reconcile` {#kubectl-auth-reconcile} - 使用清单文件来创建或者更新 `rbac.authorization.k8s.io/v1` API 对象。 -尚不存在的对象会被创建，如果对应的命名空间也不存在，必要的话也会被创建。 -已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 `--remove-extra-permissions`，可以删除其余权限。 +尚不存在的对象会被创建，如果对应的名字空间也不存在，必要的话也会被创建。 +已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 +`--remove-extra-permissions`，可以删除额外的权限。 -已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 `--remove-extra-permissions`，则可以删除其余主体。 +已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 +`--remove-extra-permissions`，则可以删除多余的主体。 例如: + * 测试应用 RBAC 对象的清单文件，显示将要进行的更改： - ``` - kubectl auth reconcile -f my-rbac-rules.yaml --dry-run - ``` + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run + ``` -* 应用 RBAC 对象的清单文件， 保留角色中的其余权限和绑定中的其他主体： + +* 应用 RBAC 对象的清单文件，保留角色中的额外权限和绑定中的其他主体： - ``` - kubectl auth reconcile -f my-rbac-rules.yaml - ``` + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml + ``` -* 应用 RBAC 对象的清单文件, 删除角色中的其他权限和绑定中的其他主体： + +* 应用 RBAC 对象的清单文件, 删除角色中的额外权限和绑定中的其他主体： - ``` - kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions - ``` + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + 查看 CLI 帮助获取详细的用法。 +## 服务账号权限 {#service-account-permissions} +默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 +但是不会对 `kube-system` 名字空间之外的服务账号授予权限。 +（除了授予所有已认证用户的发现权限） + +这使得你可以根据需要向特定服务账号授予特定权限。 +细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 +粗粒度的授权可能导致服务账号被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， +但更易于管理。 + + -## 服务账号权限 - -默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 -但是不会对 `kube-system` 命名空间之外的服务账号授予权限。 -（除了授予所有已认证用户的 discovery 权限） - -这使得您可以根据需要向特定服务账号授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 -更粗粒度的授权可能导致服务账号被授予不必要的 API 访问权限（甚至导致潜在的权限升级），但更易于管理。 - 按从最安全到最不安全的顺序，存在以下方法： 1. 为特定应用的服务账户授予角色（最佳实践） - 这要求应用在其 pod 规范中指定 `serviceAccountName` ， - 并额外创建服务账号（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 + + 这要求应用在其 Pod 规约中指定 `serviceAccountName`， + 并额外创建服务账号（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 - ```shell - kubectl create rolebinding my-sa-view \ - --clusterrole=view \ - --serviceaccount=my-namespace:my-sa \ - --namespace=my-namespace - ``` + 例如，在名字空间 "my-namespace" 中授予服务账号 "my-sa" 只读权限： -2. 将角色授予某命名空间中的 ”default” 服务账号 + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` - 如果一个应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账号。 + +2. 将角色授予某名字空间中的 "default" 服务账号 - {{< note >}}不指定 `serviceAccountName` 的话， - "default" 服务账号的权限会授予给命名空间中所有未指定 `serviceAccountName` 的 Pods。{{< /note >}} + + 如果某应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账号。 - ```shell - kubectl create rolebinding default-view \ - --clusterrole=view \ - --serviceaccount=my-namespace:default \ - --namespace=my-namespace - ``` + {{< note >}} + "default" 服务账号所具有的权限会被授予给名字空间中所有未指定 + `serviceAccountName` 的 Pod。 + {{< /note >}} - 许多附加组件 [add-ons](/docs/concepts/cluster-administration/addons/) 目前在 `kube-system` 命名空间以 "default" 服务账号运行。 - 要允许这些附加组件以超级用户权限运行，需要将集群的 cluster-admin 权限授予 `kube-system` 命名空间中的 "default" 服务账号。 + 例如，在名字空间 "my-namespace" 中授予服务账号 "default" 只读权限： - {{< note >}}启用这一配置意味着在 `kube-system` 命名空间中包含以超级用户账号来访问 API 的 Secrets。{{< /note >}} + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` - ```shell - kubectl create clusterrolebinding add-on-cluster-admin \ - --clusterrole=cluster-admin \ - --serviceaccount=kube-system:default - ``` + + 许多[插件组件](/zh/docs/concepts/cluster-administration/addons/) 在 `kube-system` + 名字空间以 "default" 服务账号运行。 + 要允许这些插件组件以超级用户权限运行，需要将集群的 `cluster-admin` 权限授予 + `kube-system` 名字空间中的 "default" 服务账号。 + + {{< note >}} + 启用这一配置意味着在 `kube-system` 名字空间中包含以超级用户账号来访问 API + 的 Secrets。 + {{< /note >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` +3. 将角色授予名字空间中所有服务账号 -3. 将角色授予命名空间中所有的服务账号 + 如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账号， + 可以将角色授予该名字空间的服务账号组。 - 如果你想要在命名空间中所有的应用都具有某角色，无论它们使用的什么服务账号， - 你可以将角色授予该命名空间的服务账号组。 + 例如，在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账号： - 例如，在命名空间 "my-namespace" 中的只读权限授予该命名空间中的所有服务账号： - - ```shell - kubectl create rolebinding serviceaccounts-view \ - --clusterrole=view \ - --group=system:serviceaccounts:my-namespace \ - --namespace=my-namespace - ``` - -4. 对集群范围内的所有服务账户授予一个受限角色（不鼓励） - - 如果你不想管理每一个命名空间的权限，你可以向所有的服务账号授予集群范围的角色。 - - 例如，为集群范围的所有服务账号授予跨所有命名空间的只读权限： - - ```shell - kubectl create clusterrolebinding serviceaccounts-view \ - --clusterrole=view \ - --group=system:serviceaccounts - ``` - -5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励） - - 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账号。 - - {{< warning >}} - 这将允许所有能够读取 Secrets 和创建 Pods 的用户访问超级用户的私密信息。 - {{< /warning >}} - - ```shell - kubectl create clusterrolebinding serviceaccounts-cluster-admin \ - --clusterrole=cluster-admin \ - --group=system:serviceaccounts - ``` + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` +4. 在集群范围内为所有服务账户授予一个受限角色（不鼓励） + + 如果你不想管理每一个名字空间的权限，你可以向所有的服务账号授予集群范围的角色。 + + 例如，为集群范围的所有服务账号授予跨所有名字空间的只读权限： + + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + + +5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励） + + 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账号。 + + {{< warning >}} + 这样做会允许所有应用都对你的集群拥有完全的访问权限，并将允许所有能够读取 + Secret（或创建 Pod）的用户对你的集群有完全的访问权限。 + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + + -# 从版本1.5升级 +## 从 ABAC 升级 -在Kubernetes 1.6版本之前，许多部署可以使用非常宽松的 ABAC 策略， +原来运行较老版本 Kubernetes 的集群通常会使用限制宽松的 ABAC 策略， 包括授予所有服务帐户全权访问 API 的能力。 -默认的 RBAC 策略被授予控制面组件、节点和控制器。 -`kube-system` 命名空间外的服务账号将没有权限 -（除了授予所有认证用户的发现权限之外） +默认的 RBAC 策略为控制面组件、节点和控制器等授予有限的权限，但不会为 +`kube-system` 名字空间外的服务账号授权 +（除了授予所有认证用户的发现权限之外）。 这样做虽然安全得多，但可能会干扰期望自动获得 API 权限的现有工作负载。 -这里有两种方法来完成这种转变: +这里有两种方法来完成这种转换: -### 平行鉴权 +### 并行鉴权 {#parallel-authorizers} 同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含 -[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件： +[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) +的策略文件： -``` +```shell --authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -RBAC 鉴权器将首先尝试对请求进行鉴权。如果它拒绝 API 请求， -则 ABAC 鉴权器运行。这意味着被 RBAC 或 ABAC 策略所允许的任何请求 -都是被允许的请求。 + +关于命令行中的第一个选项：如果早期的鉴权组件，例如 Node，拒绝了某个请求，则 +RBAC 鉴权组件尝试对该 API 请求鉴权。如果 RBAC 也拒绝了该 API 请求，则运行 ABAC +鉴权组件。这意味着被 RBAC 或 ABAC 策略所允许的任何请求都是被允许的请求。 -如果 API 服务器启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` or `--v=5`）， -你可以在 API 服务器的日志中看到 RBAC 的细节 （前缀 `RBAC DENY:`） -您可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。 -一旦你将 [角色授予服务账号](#服务账号权限) ，工作负载运行时在服务器日志中 -没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 + +如果 API 服务器启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` 或 `--v=5`）， +你可以在 API 服务器的日志中看到 RBAC 的细节 （前缀 `RBAC:`） +你可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。 + + +一旦你[将角色授予服务账号](#service-account-permissions) ，工作负载运行时 +在服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 +## 宽松的 RBAC 权限 {#permissive-rbac-permissions} + +你可以使用 RBAC 角色绑定在多个场合使用宽松的策略。 {{< warning >}} + - -## 宽松的 RBAC 权限 - -可以使用 RBAC 角色绑定在多个场合使用宽松的策略。 - -{{< warning >}} 下面的策略允许 **所有** 服务帐户充当集群管理员。 -容器中运行的所有应用程序都会自动收到服务帐户的凭据， -可以对 API 执行任何操作，包括查看 Secrets 和修改权限。 -这个策略是不被推荐的。 +容器中运行的所有应用程序都会自动收到服务帐户的凭据，可以对 API 执行任何操作， +包括查看 Secrets 和修改权限。这一策略是不被推荐的。 -``` +```shell kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ @@ -2136,3 +1891,11 @@ kubectl create clusterrolebinding permissive-binding \ --group=system:serviceaccounts ``` {{< /warning >}} + + +在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的 +信息安全需求。 + From 54ab3dafffa949b2ef79c63ee6d595dd7c532a9b Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 23 Nov 2020 16:19:56 +0800 Subject: [PATCH 15/66] [zh] Resync tasks/.../custom-resource-definition-versioning.md --- .../custom-resource-definition-versioning.md | 972 +++++++++++------- 1 file changed, 574 insertions(+), 398 deletions(-) diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index c479dce83f..9a03e0f89e 100644 --- a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -1,5 +1,5 @@ --- -title: 用户自定义资源的版本 +title: CustomResourceDefinition 的版本 content_type: task weight: 30 min-kubernetes-server-version: v1.16 @@ -21,8 +21,9 @@ This page explains how to add versioning information to level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another. --> 本页介绍如何添加版本信息到 -[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions)， -如何表示 CustomResourceDefinitions 的稳定水平或者用 API 之间的表征的转换提高您的 API 到一个新的版本。 +[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions)。 +目的是标明 CustomResourceDefinitions 的稳定级别或者服务于 API 升级。 +API 升级时需要在不同 API 表示形式之间进行转换。 本页还描述如何将对象从一个版本升级到另一个版本。 ## {{% heading "prerequisites" %}} @@ -32,7 +33,7 @@ level of your CustomResourceDefinitions or advance your API to a new version wit -你应该对[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +你应该对[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 有一些初步了解。 {{< version-check >}} @@ -41,10 +42,7 @@ You should have a initial understanding of [custom resources](/docs/concepts/ext -## 概览 - -CustomResourceDefinition API 提供了用于引入和升级的工作流程到 CustomResourceDefinition 的新版本。 +## 概览 -创建 CustomResourceDefinition 时，会在 CustomResourceDefinition `spec.versions` 列表设置适当的稳定级和版本号。例如`v1beta1`表示第一个版本尚未稳定。所有自定义资源对象将首先存储在这个版本 +CustomResourceDefinition API 提供了用于引入和升级的工作流程到 CustomResourceDefinition +的新版本。 -创建 CustomResourceDefinition 后，客户端可以开始使用 v1beta1 API。 +创建 CustomResourceDefinition 时，会在 CustomResourceDefinition `spec.versions` +列表设置适当的稳定级别和版本号。例如，`v1beta1` 表示第一个版本尚未稳定。 +所有定制资源对象将首先用这个版本保存。 -稍后可能需要添加新版本，例如 v1。 +创建 CustomResourceDefinition 后，客户端可以开始使用 `v1beta1` API。 + +稍后可能需要添加新版本，例如 `v1`。 -增加一个新版本： +添加新版本： -1. 选择一种转化策略。由于自定义资源对象需要能够两种版本都可用，这意味着它们有时会以与存储版本不同的版本。为了能够做到这一点， - 有时必须在它们存储的版本和提供的版本。如果转换涉及结构变更，并且需要自定义逻辑，转换应该使用 webhook。如果没有结构变更， - 则使用 None 默认转换策略，不同版本时只有`apiVersion`字段有变更。 -2. 如果使用转换 Webhook，请创建并部署转换 Webhook。希望看到更多详细信息，请参见 [Webhook conversion](#webhook转换)。 -3. 更新 CustomResourceDefinition，来将新版本包含在具有`served：true`的 spec.versions 列表。另外，设置`spec.conversion`字段 - 到所选的转换策略。如果使用转换 Webhook，请配置`spec.conversion.webhookClientConfig`来调用 webhook。 +1. 选择一种转化策略。由于定制资源对象需要能够两种版本都可用， + 这意味着它们有时会以与存储版本不同的版本来提供服务。为了能够做到这一点， + 有时必须在它们存储的版本和提供的版本之间进行转换。如果转换涉及模式变更， + 并且需要自定义逻辑，则应该使用 Webhook 来完成。如果没有模式变更， + 则可使用默认的 `None` 转换策略，为不同版本提供服务时只有 `apiVersion` 字段 + 会被改变。 +2. 如果使用转换 Webhook，请创建并部署转换 Webhook。更多详细信息请参见 + [Webhook conversion](#webhook-conversion)。 +3. 更新 CustomResourceDefinition，将新版本设置为 `served：true`，加入到 + `spec.versions` 列表。另外，还要设置 `spec.conversion` 字段 + 为所选的转换策略。如果使用转换 Webhook，请配置 + `spec.conversion.webhookClientConfig` 来调用 Webhook。 +添加新版本后，客户端可以逐步迁移到新版本。让某些客户使用旧版本的同时 +支持其他人使用新版本是相当安全的。 +将存储的对象迁移到新版本： + + -添加新版本后，客户端可以逐步迁移到新版本。对于某些客户而言，在使用旧版本的同时支持其他人使用新版本。 -将存储的对象迁移到新版本： +1. 请参阅[将现有对象升级到新的存储版本](#upgrade-existing-objects-to-a-new-stored-version)节。 -1. 请参阅 [将现有对象升级到新的存储版本](#将现有对象升级到新的存储版本) 章节。 - -对于客户来说，在将对象升级到新的存储版本之前，期间和之后使用旧版本和新版本都是安全的。 +对于客户来说，在将对象升级到新的存储版本之前、期间和之后使用旧版本和新版本都是安全的。 删除旧版本： -1. 确保所有客户端都已完全迁移到新版本。kube-apiserver 可以查看日志以帮助识别仍通过进行访问的所有客户端旧版本。 -2. 在`spec.versions`列表中将旧版本的 served 设置为 false。如果任何客户端仍然意外地使用他们可能开始报告的旧版本尝试访问旧版本的自定义资源对象时出错。 - 如果发生这种情况，请切换回在旧版本上使用`served：true`，然后迁移其他客户使用新版本，然后重复此步骤。 -3. 确保已完成 [将现有对象升级到新存储版本](#将现有对象升级到新的存储版本) 的步骤。 - 1. 在 CustomResourceDefinition 的`spec.versions`列表中，确认新版本的`stored`已设置为`true`。 - 2. 确认旧版本不再列在 CustomResourceDefinition `status.storedVersions`。 -4. 从 CustomResourceDefinition`spec.versions` 列表中删除旧版本。 -5. 在转换 webhooks 中放弃对旧版本的转换支持。 +1. 确保所有客户端都已完全迁移到新版本。 + 可以查看 kube-apiserver 的日志以识别仍通过旧版本进行访问的所有客户端。 +1. 在 `spec.versions` 列表中将旧版本的 `served` 设置为 `false`。 + 如果仍有客户端意外地使用旧版本，他们可能开始会报告采用旧版本尝试访 + 定制资源的错误消息。 + 如果发生这种情况，请将旧版本的`served：true` 恢复，然后迁移余下的客户端 + 使用新版本，然后重复此步骤。 +1. 确保已完成[将现有对象升级到新存储版本](#upgrade-existing-objects-to-a-new-stored-version) + 的步骤。 + 1. 在 CustomResourceDefinition 的 `spec.versions` 列表中，确认新版本的 + `stored` 已被设置为 `true`。 + 2. 确认旧版本不在 CustomResourceDefinition `status.storedVersions` 中。 +1. 从 CustomResourceDefinition `spec.versions` 列表中删除旧版本。 +1. 在转换 Webhooks 中放弃对旧版本的转换支持。 ## 指定多个版本 {#specify-multiple-versions} -CustomResourceDefinition API 的`versions`字段可用于支持您自定义资源的多个版本已经开发的。版本可以具有不同的架构，并且转换 Webhooks 可以在版本之间转换自定义资源。 -在适用的情况下，Webhook 转换应遵循 [Kubernetes API](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md)。 +CustomResourceDefinition API 的 `versions` 字段可用于支持你所开发的 +定制资源的多个版本。版本可以具有不同的模式，并且转换 Webhooks +可以在多个版本之间转换定制资源。 +在适当的情况下，Webhook 转换应遵循 +[Kubernetes API 约定](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md)。 +尤其是，请查阅 +[API 变更文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) +以了解一些有用的常见错误和建议。 {{< note >}} -在 `apiextensions.k8s.io/v1beta1` 版本中，有一个 `version` 字段，名字不叫做 `versions`。 -`version` 字段已经被废弃，成为可选项。不过如果该字段不是空，则必须与 -`versions` 字段中的第一个条目匹配。 +在 `apiextensions.k8s.io/v1beta1` 版本中曾经有一个 `version` 字段， +名字不叫做 `versions`。该 `version` 字段已经被废弃，成为可选项。 +不过如果该字段不是空，则必须与 `versions` 字段中的第一个条目匹配。 {{< /note >}} -此示例显示了两个版本的 CustomResourceDefinition。第一个例子，假设所有的版本共享相同的模式而它们之间没有转换。YAML 中的评论提供了更多背景信息。 +下面的示例显示了两个版本的 CustomResourceDefinition。 +第一个例子中假设所有的版本使用相同的模式而它们之间没有转换。 +YAML 中的注释提供了更多背景信息。 {{< tabs name="CustomResourceDefinition_versioning_example_1" >}} {{% tab name="apiextensions.k8s.io/v1" %}} @@ -181,19 +207,19 @@ between them. The comments in the YAML provide more context. apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: - # name must match the spec fields below, and be in the form: . + # name 必须匹配后面 spec 中的字段，且使用格式 . name: crontabs.example.com spec: - # group name to use for REST API: /apis// + # 组名，用于 REST API: /apis// group: example.com - # list of versions supported by this CustomResourceDefinition + # 此 CustomResourceDefinition 所支持的版本列表 versions: - name: v1beta1 - # Each version can be enabled/disabled by Served flag. + # 每个 version 可以通过 served 标志启用或禁止 served: true - # One and only one version must be marked as the storage version. + # 有且只能有一个 version 必须被标记为存储版本 storage: true - # A schema is required + # schema 是必需字段 schema: openAPIV3Schema: type: object @@ -213,43 +239,44 @@ spec: type: string port: type: string - # The conversion section is introduced in Kubernetes 1.13+ with a default value of - # None conversion (strategy sub-field set to None). + # conversion 节是 Kubernetes 1.13+ 版本引入的，其默认值为无转换，即 + # strategy 子字段设置为 None。 conversion: - # None conversion assumes the same schema for all versions and only sets the apiVersion - # field of custom resources to the proper value + # None 转换假定所有版本采用相同的模式定义，仅仅将定制资源的 apiVersion + # 设置为合适的值. strategy: None - # either Namespaced or Cluster + # 可以是 Namespaced 或 Cluster scope: Namespaced names: - # plural name to be used in the URL: /apis/// + # 名称的复数形式，用于 URL: /apis/// plural: crontabs - # singular name to be used as an alias on the CLI and for display + # 名称的单数形式，用于在命令行接口和显示时作为其别名 singular: crontab - # kind is normally the CamelCased singular type. Your resource manifests use this. + # kind 通常是驼峰编码（CamelCased）的单数形式，用于资源清单中 kind: CronTab - # shortNames allow shorter string to match your resource on the CLI + # shortNames 允许你在命令行接口中使用更短的字符串来匹配你的资源 shortNames: - ct ``` {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml -# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 +# 在 v1.16 中被弃用以推荐使用 apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: - # name must match the spec fields below, and be in the form: . + # name 必须匹配后面 spec 中的字段，且使用格式 . name: crontabs.example.com spec: - # group name to use for REST API: /apis// + # 组名，用于 REST API: /apis// group: example.com - # list of versions supported by this CustomResourceDefinition + # 此 CustomResourceDefinition 所支持的版本列表 versions: - name: v1beta1 - # Each version can be enabled/disabled by Served flag. + # 每个 version 可以通过 served 标志启用或禁止 served: true - # One and only one version must be marked as the storage version. + # 有且只能有一个 version 必须被标记为存储版本 storage: true - name: v1 served: true @@ -262,22 +289,22 @@ spec: type: string port: type: string - # The conversion section is introduced in Kubernetes 1.13+ with a default value of - # None conversion (strategy sub-field set to None). + # conversion 节是 Kubernetes 1.13+ 版本引入的，其默认值为无转换，即 + # strategy 子字段设置为 None。 conversion: - # None conversion assumes the same schema for all versions and only sets the apiVersion - # field of custom resources to the proper value + # None 转换假定所有版本采用相同的模式定义，仅仅将定制资源的 apiVersion + # 设置为合适的值. strategy: None - # either Namespaced or Cluster + # 可以是 Namespaced 或 Cluster scope: Namespaced names: - # plural name to be used in the URL: /apis/// + # 名称的复数形式，用于 URL: /apis/// plural: crontabs - # singular name to be used as an alias on the CLI and for display + # 名称的单数形式，用于在命令行接口和显示时作为其别名 singular: crontab - # kind is normally the CamelCased singular type. Your resource manifests use this. + # kind 通常是驼峰编码（CamelCased）的单数形式，用于资源清单中 kind: CronTab - # shortNames allow shorter string to match your resource on the CLI + # shortNames 允许你在命令行接口中使用更短的字符串来匹配你的资源 shortNames: - ct ``` @@ -288,7 +315,8 @@ spec: You can save the CustomResourceDefinition in a YAML file, then use `kubectl apply` to create it. --> -你可以将 CustomResourceDefinition 存储在 YAML 文件中，然后使用`kubectl apply`来创建它。 +你可以将 CustomResourceDefinition 存储在 YAML 文件中，然后使用 +`kubectl apply` 来创建它。 ```shell kubectl apply -f my-versioned-crontab.yaml @@ -299,8 +327,9 @@ After creation, the API server starts to serve each enabled version at an HTTP REST endpoint. In the above example, the API versions are available at `/apis/example.com/v1beta1` and `/apis/example.com/v1`. --> -在创建之后，apiserver 开始在 HTTP REST 端点上为每个启用的版本提供服务。 -在上面的示例中，API 版本可以在`/apis/example.com/v1beta1` 和 `/apis/example.com/v1`中获得。 +在创建之后，API 服务器开始在 HTTP REST 端点上为每个已启用的版本提供服务。 +在上面的示例中，API 版本可以在 `/apis/example.com/v1beta1` 和 +`/apis/example.com/v1` 处获得。 ### 版本优先级 -不考虑 CustomResourceDefinition 中版本被定义的顺序，kubectl 使用具有最高优先级的版本作为访问对象的默认版本。 -通过解析 _name_ 字段确定优先级来决定版本号，稳定性（GA，Beta，或者 Alpha），以及该稳定性水平内的序列。 +不考虑 CustomResourceDefinition 中版本被定义的顺序，kubectl 使用 +具有最高优先级的版本作为访问对象的默认版本。 +通过解析 _name_ 字段确定优先级来决定版本号，稳定性（GA、Beta 或 Alpha） +级别及该稳定性级别内的序列。 -用于对版本进行排序的算法被设计成与 Kubernetes 项目对 Kubernetes 版本进行排序的方式相同。 -版本以`v`开头跟一个数字，一个可选的`beta` 或者 `alpha`命名，和一个可选的附加的数字型的版本信息。 -从广义上讲，版本字符串可能看起来像`v2`或者`v2beta1`。 +用于对版本进行排序的算法在设计上与 Kubernetes 项目对 Kubernetes 版本进行排序的方式相同。 +版本以 `v` 开头跟一个数字，一个可选的 `beta` 或者 `alpha` 和一个可选的附加数字 +作为版本信息。 +从广义上讲，版本字符串可能看起来像 `v2` 或者 `v2beta1`。 使用以下算法对版本进行排序： - 遵循 Kubernetes 版本模式的条目在不符合条件的条目之前进行排序。 - 对于遵循 Kubernetes 版本模式的条目，版本字符串的数字部分从最大到最小排序。 -- 如果字符串 `beta` 或 `alpha` 跟随第一数字部分，它们按顺序排序，在没有 `beta` 或 `alpha` - 后缀（假定为 GA 版本）的等效字符串后面。 -- 如果另一个数字跟在`beta`或`alpha`之后，那么这些数字也是从最大到最小排序。 +- 如果第一个数字后面有字符串 `beta` 或 `alpha`，它们首先按去掉 `beta` 或 + `alpha` 之后的版本号排序（相当于 GA 版本），之后按 `beta` 先、`alpha` 后的顺序排序， +- 如果 `beta` 或 `alpha` 之后还有另一个数字，那么也会针对这些数字 + 从大到小排序。 - 不符合上述格式的字符串按字母顺序排序，数字部分不经过特殊处理。 - 请注意，在下面的示例中，`foo1`在 `foo10`上方排序。这与遵循 Kubernetes 版本模式的条目的数字部分排序不同。 + 请注意，在下面的示例中，`foo1` 排在 `foo10` 之前。 + 这与遵循 Kubernetes 版本模式的条目的数字部分排序不同。 -如果查看以下排序版本列表可以明白： +如果查看以下版本排序列表，这些规则就容易懂了： ```none - v10 @@ -375,8 +409,106 @@ version sort order is `v1`, followed by `v1beta1`. This causes the kubectl command to use `v1` as the default version unless the provided object specifies the version. --> -对于 [指定多个版本](#specify-multiple-versions) 中的示例，版本排序顺序为 `v1`，后跟着 `v1beta1`。 -这导致了 kubectl 命令使用 `v1` 作为默认版本，除非提供对象指定版本。 +对于[指定多个版本](#specify-multiple-versions)中的示例，版本排序顺序为 +`v1`，后跟着 `v1beta1`。 +这导致了 kubectl 命令使用 `v1` 作为默认版本，除非所提供的对象指定了版本。 + + +### 版本废弃 + +{{< feature-state state="stable" for_k8s_version="v1.19" >}} + + +从 v1.19 开始，CustomResourceDefinition 可用来标明所定义的资源的特定版本 +被废弃。当发起对已废弃的版本的 API 请求时，会在 API 响应中以 HTTP 头部 +的形式返回警告消息。 +如果需要，可以对资源的每个废弃版本定制该警告消息。 + + +定制的警告消息应该标明废弃的 API 组、版本和类别（kind），并且应该标明 +应该使用（如果有的话）哪个 API 组、版本和类别作为替代。 + +{{< tabs name="CustomResourceDefinition_versioning_deprecated" >}} +{{% tab name="apiextensions.k8s.io/v1" %}} + +```yaml +apiVersion: apiextensions.k8s.io/v1 +kind: CustomResourceDefinition + name: crontabs.example.com +spec: + group: example.com + names: + plural: crontabs + singular: crontab + kind: CronTab + scope: Namespaced + versions: + - name: v1alpha1 + served: true + # 此属性标明此定制资源的 v1alpha1 版本已被弃用。 + # 发给此版本的 API 请求会在服务器响应中收到警告消息头。 + deprecated: true + # 此属性设置用来覆盖返回给发送 v1alpha1 API 请求的客户端的默认警告信息。 + deprecationWarning: "example.com/v1alpha1 CronTab is deprecated; see http://example.com/v1alpha1-v1 for instructions to migrate to example.com/v1 CronTab" + schema: ... + - name: v1beta1 + served: true + # 此属性标明该定制资源的 v1beta1 版本已被弃用。 + # 发给此版本的 API 请求会在服务器响应中收到警告消息头。 + # 针对此版本的请求所返回的是默认的警告消息。 + deprecated: true + schema: ... + - name: v1 + served: true + storage: true + schema: ... +``` +{{% /tab %}} +{{% tab name="apiextensions.k8s.io/v1beta1" %}} +```yaml +# 在 v1.16 中弃用以推荐使用 apiextensions.k8s.io/v1 +apiVersion: apiextensions.k8s.io/v1beta1 +kind: CustomResourceDefinition +metadata: + name: crontabs.example.com +spec: + group: example.com + names: + plural: crontabs + singular: crontab + kind: CronTab + scope: Namespaced + validation: ... + versions: + - name: v1alpha1 + served: true + # 此属性标明此定制资源的 v1alpha1 版本已被弃用。 + # 发给此版本的 API 请求会在服务器响应中收到警告消息头。 + deprecated: true + # 此属性设置用来覆盖返回给发送 v1alpha1 API 请求的客户端的默认警告信息。 + deprecationWarning: "example.com/v1alpha1 CronTab is deprecated; see http://example.com/v1alpha1-v1 for instructions to migrate to example.com/v1 CronTab" + - name: v1beta1 + served: true + # 此属性标明该定制资源的 v1beta1 版本已被弃用。 + # 发给此版本的 API 请求会在服务器响应中收到警告消息头。 + # 针对此版本的请求所返回的是默认的警告消息。 + deprecated: true + - name: v1 + served: true + storage: true +``` +{{% /tab %}} +{{< /tabs >}} + -## Webhook转换 +## Webhook 转换 {#webhook-conversion} {{< feature-state state="stable" for_k8s_version="v1.16" >}} {{< note >}} -Webhook 转换在 Kubernetes 1.15 中作为 beta 功能。 -要使用它，应启用`CustomResourceWebhookConversion`功能。 -在大多数集群上，这类 beta 特性应该时自动启用的。 -请参阅[特行门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 文档以获得更多信息。 +Webhook 转换在 Kubernetes 1.13 版本引入，在 Kubernetes 1.15 中成为 Beta 功能。 +要使用此功能，应启用 `CustomResourceWebhookConversion` 特性。 +在大多数集群上，这类 Beta 特性应该是自动启用的。 +请参阅[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +文档以获得更多信息。 {{< /note >}} -上面的例子在版本之间有一个 None 转换，它只在转换时设置`apiVersion`字段而不改变对象的其余部分。apiserver 还支持在需要转换时调用外部服务的 webhook 转换。例如： +上面的例子在版本之间有一个 None 转换，它只在转换时设置 `apiVersion` 字段 +而不改变对象的其余部分。API 服务器还支持在需要转换时调用外部服务的 webhook 转换。 +例如： -* 自定义资源被要求在一个不同的版本里而不是一个存储的版本里。 -* Watch 在一个版本中创建，但更改对象存储在另一个版本中。 -* 自定义资源 PUT 请求在一个不同的版本里而不是一个存储的版本。 +* 定制资源的请求版本与其存储版本不同。 +* 使用某版本创建了 Watch 请求，但所更改对象以另一版本存储。 +* 定制资源的 PUT 请求所针对版本与存储版本不同。 -为了涵盖所有这些情况并通过 API 服务优化转换，转换对象可能包含多个对象，以便最大限度地减少外部调用。webhook 应该独立执行这些转换。 +为了涵盖所有这些情况并优化 API 服务器所作的转换，转换请求可以包含多个对象， +以便减少外部调用。Webhook 应该独立执行各个转换。 ### 编写一个转换 Webhook 服务器 -请参考[自定义资源转换 webhook 服务](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/main.go) 的实施，这在 Kubernetes e2e 测试中得到验证。webhook 处理由 apiserver 发送的`ConversionReview`请求，并发送回包含在`ConversionResponse`中的转换结果。请注意，请求包含需要独立转换不改变对象顺序的自定义资源列表。示例服务器的组织方式使其可以重用于其他转换。大多数常见代码都位于 [框架文件](https://github.com/kubernetes/kubernetes/tree/v1.14.0/test/images/crd-conversion-webhook/converter/framework.go) 中，只留下 [示例](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) 用于实施不同的转换。 +请参考[定制资源转换 Webhook 服务器](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/main.go) +的实现；该实现在 Kubernetes e2e 测试中得到验证。 +Webhook 处理由 API 服务器发送的 `ConversionReview` 请求，并在 +`ConversionResponse` 中封装发回转换结果。 +请注意，请求包含需要独立转换的定制资源列表，这些对象在被转换之后不能改变其 +在列表中的顺序。该示例服务器的组织方式使其可以复用于其他转换。 +大多数常见代码都位于 +[framework 文件](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) +中，只留下 +[一个函数](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) +用于实现不同的转换。 {{< note >}} -示例转换 webhook 服务器留下`ClientAuth`字段为 +转换 Webhook 服务器示例中将 `ClientAuth` 字段设置为 [空](https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/images/crd-conversion-webhook/config.go#L47-L48)， -默认为`NoClientCert`。 - -这意味着 webhook 服务器没有验证客户端的身份，据称是 apiserver。 - -如果您需要相互 TLS 或者其他方式来验证客户端，请参阅如何 +默认为 `NoClientCert`。 +这意味着 webhook 服务器没有验证客户端（也就是 API 服务器）的身份。 +如果你需要双向 TLS 或者其他方式来验证客户端，请参阅如何 [验证 API 服务](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers)。 {{< /note >}} + +#### 被允许的变更 + +转换 Webhook 不可以更改被转换对象的 `metadata` 中除 `labels` 和 `annotations` +之外的任何属性。 +尝试更改 `name`、`UID` 和 `namespace` 时都会导致引起转换的请求失败。 +所有其他变更只是被忽略而已。 + {{< note >}} -当 webhook 服务器作为一个部署到 Kubernetes 集群中的服务器时，它必须通过端口443上的服务器公开(服务器本身可以有一个任意端口，但是服务器对象应该将它映射到端口443)。 -如果为服务器使用不同的端口，则 apiserver 和 webhook 服务器之间的通信可能会失败。 +当 Webhook 服务器作为一个服务被部署到 Kubernetes 集群中时，它必须 +通过端口 443 公开其服务（服务器本身可以使用任意端口，但是服务对象 +应该将它映射到端口 443）。 +如果为服务器使用不同的端口，则 API 服务器和 Webhook 服务器之间的通信 +可能会失败。 {{< /note >}} ### 配置 CustomResourceDefinition 以使用转换 Webhook -通过修改 `spec` 中的 `conversion` 部分，可以扩展 `None` 转换示例来使用转换 webhook。 +通过修改 `spec` 中的 `conversion` 部分，可以扩展 `None` 转换示例来 +使用转换 Webhook。 {{< tabs name="CustomResourceDefinition_versioning_example_2" >}} {{% tab name="apiextensions.k8s.io/v1" %}} @@ -491,20 +663,19 @@ section of the `spec`: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: - # name must match the spec fields below, and be in the form: . + # name 必须匹配后面 spec 中的字段，且使用格式 . name: crontabs.example.com spec: - # group name to use for REST API: /apis// + # 组名，用于 REST API: /apis// group: example.com - # list of versions supported by this CustomResourceDefinition + # 此 CustomResourceDefinition 所支持的版本列表 versions: - name: v1beta1 - # Each version can be enabled/disabled by Served flag. + # 每个 version 可以通过 served 标志启用或禁止 served: true - # One and only one version must be marked as the storage version. + # 有且只能有一个 version 必须被标记为存储版本 storage: true - # Each version can define it's own schema when there is no top-level - # schema is defined. + # 当不存在顶级模式定义时，每个版本（version）可以定义其自身的模式 schema: openAPIV3Schema: type: object @@ -523,13 +694,16 @@ spec: port: type: string conversion: - # a Webhook strategy instruct API server to call an external webhook for any conversion between custom resources. + # Webhook strategy 告诉 API 服务器调用外部 Webhook 来完成定制资源 + # 之间的转换 strategy: Webhook - # webhook is required when strategy is `Webhook` and it configures the webhook endpoint to be called by API server. + # 当 strategy 为 "Webhook" 时，webhook 属性是必需的 + # 该属性配置将被 API 服务器调用的 Webhook 端点 webhook: - # conversionReviewVersions indicates what ConversionReview versions are understood/preferred by the webhook. - # The first version in the list understood by the API server is sent to the webhook. - # The webhook must respond with a ConversionReview object in the same version it received. + # conversionReviewVersions 标明 Webhook 所能理解或偏好使用的 + # ConversionReview 对象版本。 + # API 服务器所能理解的列表中的第一个版本会被发送到 Webhook + # Webhook 必须按所接收到的版本响应一个 ConversionReview 对象 conversionReviewVersions: ["v1","v1beta1"] clientConfig: service: @@ -537,42 +711,41 @@ spec: name: example-conversion-webhook-server path: /crdconvert caBundle: "Ci0tLS0tQk......tLS0K" - # either Namespaced or Cluster + # 可以是 Namespaced 或 Cluster scope: Namespaced names: - # plural name to be used in the URL: /apis/// + # 名称的复数形式，用于 URL: /apis/// plural: crontabs - # singular name to be used as an alias on the CLI and for display + # 名称的单数形式，用于在命令行接口和显示时作为其别名 singular: crontab - # kind is normally the CamelCased singular type. Your resource manifests use this. + # kind 通常是驼峰编码（CamelCased）的单数形式，用于资源清单中 kind: CronTab - # shortNames allow shorter string to match your resource on the CLI + # shortNames 允许你在命令行接口中使用更短的字符串来匹配你的资源 shortNames: - ct ``` {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} ```yaml -# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 +# 在 v1.16 中被弃用以推荐使用 apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: - # name must match the spec fields below, and be in the form: . + # name 必须匹配后面 spec 中的字段，且使用格式 . name: crontabs.example.com spec: - # group name to use for REST API: /apis// + # 组名，用于 REST API: /apis// group: example.com - # prunes object fields that are not specified in OpenAPI schemas below. + # 裁剪掉下面的 OpenAPI 模式中未曾定义的对象字段 preserveUnknownFields: false - # list of versions supported by this CustomResourceDefinition + # 此 CustomResourceDefinition 所支持的版本列表 versions: - name: v1beta1 - # Each version can be enabled/disabled by Served flag. + # 每个 version 可以通过 served 标志启用或禁止 served: true - # One and only one version must be marked as the storage version. + # 有且只能有一个 version 必须被标记为存储版本 storage: true - # Each version can define it's own schema when there is no top-level - # schema is defined. + # 当不存在顶级模式定义时，每个版本（version）可以定义其自身的模式 schema: openAPIV3Schema: type: object @@ -591,25 +764,26 @@ spec: port: type: string conversion: - # a Webhook strategy instruct API server to call an external webhook for any conversion between custom resources. + # Webhook strategy 告诉 API 服务器调用外部 Webhook 来完成定制资源 strategy: Webhook - # webhookClientConfig is required when strategy is `Webhook` and it configures the webhook endpoint to be called by API server. + # 当 strategy 为 "Webhook" 时，webhookClientConfig 属性是必需的 + # 该属性配置将被 API 服务器调用的 Webhook 端点 webhookClientConfig: service: namespace: default name: example-conversion-webhook-server path: /crdconvert caBundle: "Ci0tLS0tQk......tLS0K" - # either Namespaced or Cluster + # 可以是 Namespaced 或 Cluster scope: Namespaced names: - # plural name to be used in the URL: /apis/// + # 名称的复数形式，用于 URL: /apis/// plural: crontabs - # singular name to be used as an alias on the CLI and for display + # 名称的单数形式，用于在命令行接口和显示时作为其别名 singular: crontab - # kind is normally the CamelCased singular type. Your resource manifests use this. + # kind 通常是驼峰编码（CamelCased）的单数形式，用于资源清单中 kind: CronTab - # shortNames allow shorter string to match your resource on the CLI + # shortNames 允许你在命令行接口中使用更短的字符串来匹配你的资源 shortNames: - ct ``` @@ -620,7 +794,8 @@ spec: You can save the CustomResourceDefinition in a YAML file, then use `kubectl apply` to apply it. --> -您可以将 CustomResourceDefinition 保存在 YAML 文件中，然后使用`kubectl apply`来应用它。 +你可以将 CustomResourceDefinition 保存在 YAML 文件中，然后使用 +`kubectl apply` 来应用它。 ```shell kubectl apply -f my-versioned-crontab-with-conversion.yaml @@ -643,9 +818,11 @@ and can optionally include a custom CA bundle to use to verify the TLS connectio --> ### 调用 Webhook -apiserver 一旦确定请求应发送到转换 webhook，它需要知道如何调用 webhook。这是在`webhookClientConfig`中指定的 webhook 配置。 +API 服务器一旦确定请求应发送到转换 Webhook，它需要知道如何调用 Webhook。 +这是在 `webhookClientConfig` 中指定的 Webhook 配置。 -转换 webhook 可以通过调用 URL 或服务，并且可以选择包含自定义 CA 包，以用于验证 TLS 连接。 +转换 Webhook 可以通过 URL 或服务引用来调用，并且可以选择包含自定义 CA 包， +以用于验证 TLS 连接。 ### URL @@ -665,13 +842,16 @@ which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. --> +url 以标准 URL 形式给出 Webhook 的位置（`scheme://host:port/path`）。 +`host` 不应引用集群中运行的服务，而应通过指定 `service` 字段来提供 +服务引用。 +在某些 API 服务器中，`host` 可以通过外部 DNS 进行解析（即 +`kube-apiserver` 无法解析集群内 DNS，那样会违反分层规则）。 +`host` 也可以是 IP 地址。 -url 以标准 URL 形式给出 webhook 的位置（`scheme://host:port/path`）。 -`host`不应引用集群中运行的服务；采用通过指定`service`字段来提供服务引用。 -`host`可以通过某些 apiserver 中的外部 DNS 进行解析（即`kube-apiserver`无法解析集群内 DNS 违反分层规则）。主机也可以是 IP 地址。 - -请注意，除非您非常小心在所有主机上运行此 Webhook，否则 localhost 或 127.0.0.1 用作主机是风险很大的，运行一个 apiserver 可能需要对此进行调用 - webhook。这样的安装很可能是不可移植的，即不容易出现在新集群中。 +请注意，除非你非常小心地在所有运行着可能调用 Webhook 的 API 服务器的 +主机上运行此 Webhook，否则将 `localhost` 或 `127.0.0.1` 用作 `host` +是风险很大的。这样的安装很可能是不可移植的，即很难在新集群中启用。 +HTTP 协议必须为 `https`；URL 必须以 `https://` 开头。 -方案必须为`https`：URL 必须以`https://`开头。 +尝试使用用户或基本身份验证（例如，使用`user:password@`）是不允许的。 +URL 片段（`#...`）和查询参数（`?...`）也是不允许的。 -尝试使用用户或基本身份验证，例如不允许使用`user:password@`。片段（`#...`）和查询参数（`?...`）也不允许。 - -这是配置为调用 URL 的转换 Webhook 的示例（并且期望使用系统信任根来验证 TLS 证书，因此不指定 caBundle）： +下面是为调用 URL 来执行转换 Webhook 的示例，其中期望使用系统信任根 +来验证 TLS 证书，因此未指定 caBundle： {{< tabs name="CustomResourceDefinition_versioning_example_3" >}} {{% tab name="apiextensions.k8s.io/v1" %}} @@ -707,7 +888,7 @@ spec: {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} ```yaml -# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 +# 在 v1.16 中已弃用以推荐使用 apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition ... @@ -736,16 +917,19 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa --> ### 服务引用 -`webhookClientConfig`内部的`service`段是对转换 webhook 服务的引用。如果 Webhook 在集群中运行，则应使用`service`而不是`url`。 -服务名称空间和名称是必需的。端口是可选的，默认为 443。该路径是可选的，默认为`/`。 +`webhookClientConfig` 内部的 `service` 段是对转换 Webhook 服务的引用。 +如果 Webhook 在集群中运行，则应使用 `service` 而不是 `url`。 +服务的名字空间和名称是必需的。端口是可选的，默认为 443。 +路径是可选的，默认为`/`。 -这是一个配置为在端口`1234`上调用服务的 Webhook 的示例在子路径`/my-path`下，并针对 ServerName 验证 TLS 连接 -使用自定义 CA 捆绑包的`my-service-name.my-service-namespace.svc`。 +下面配置中，服务配置为在端口 `1234`、子路径 `/my-path` 上被调用。 +例子中针对 ServerName `my-service-name.my-service-namespace.svc`， +使用自定义 CA 包验证 TLS 连接。 {{< tabs name="CustomResourceDefinition_versioning_example_4" >}} {{% tab name="apiextensions.k8s.io/v1" %}} ```yaml -apiVersion: apiextensions.k8s.io/v1b +apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition ... spec: @@ -765,7 +949,7 @@ spec: {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} ```yaml -# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 +# v1.16 中被弃用以推荐使用 apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition ... @@ -801,9 +985,12 @@ with the `conversionReviewVersions` field in their CustomResourceDefinition: ### 请求 -向 Webhooks 发送 POST 请求，请求的内容类型为：application/json，与 APIapitensions.k8s.io API 组中的 ConversionReview API 对象一起使用序列化为 JSON 作为主体。 +向 Webhooks 发起请求的动词是 POST，请求的 `Content-Type` 为 `application/json`。 +请求的主题为 JSON 序列化形式的 +apiextensions.k8s.io API 组的 ConversionReview API 对象。 -Webhooks 可以指定他们接受的`ConversionReview`对象的版本在其 CustomResourceDefinition 中使用`conversionReviewVersions`字段： +Webhooks 可以在其 CustomResourceDefinition 中使用`conversionReviewVersions` 字段 +设置它们接受的 `ConversionReview` 对象的版本： {{< tabs name="conversionReviewVersions" >}} {{% tab name="apiextensions.k8s.io/v1" %}} @@ -826,14 +1013,15 @@ spec: Webhooks are required to support at least one `ConversionReview` version understood by the current and previous API server. --> - -创建时，`conversionReviewVersions`是必填字段`apiextensions.k8s.io/v1`自定义资源定义。 -需要 Webhooks 支持至少一个`ConversionReview`当前和以前的 apiserver 可以理解的版本。 +创建 `apiextensions.k8s.io/v1` 版本的自定义资源定义时， +`conversionReviewVersions`是必填字段。 +Webhooks 要求支持至少一个 `ConversionReview` 当前和以前的 API 服务器 +可以理解的版本。 {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} ```yaml -# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 +# v1.16 已弃用以推荐使用 apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition ... @@ -848,112 +1036,102 @@ spec: If no `conversionReviewVersions` are specified, the default when creating `apiextensions.k8s.io/v1beta1` custom resource definitions is `v1beta1`. --> +创建 apiextensions.k8s.io/v1beta1 定制资源定义时若未指定 +`conversionReviewVersions`，则默认值为 v1beta1。 -如果未指定`conversionReviewVersions`，则创建时的默认值 apiextensions.k8s.io/v1beta1 自定义资源定义为 v1beta1。 {{% /tab %}} {{< /tabs >}} + +API 服务器将 `conversionReviewVersions` 列表中他们所支持的第一个 +`ConversionReview` 资源版本发送给 Webhook。 +如果列表中的版本都不被 API 服务器支持，则无法创建自定义资源定义。 +如果某 API 服务器遇到之前创建的转换 Webhook 配置，并且该配置不支持 +API 服务器知道如何发送的任何 `ConversionReview` 版本，调用 Webhook +的尝试会失败。 - -此示例显示了包含在`ConversionReview`对象中的数据请求将`CronTab`对象转换为`example.com/v1`： +下面的示例显示了包含在 `ConversionReview` 对象中的数据， +该请求意在将 `CronTab` 对象转换为 `example.com/v1`： {{< tabs name="ConversionReview_request" >}} {{% tab name="apiextensions.k8s.io/v1" %}} ```yaml -{ - "apiVersion": "apiextensions.k8s.io/v1", - "kind": "ConversionReview", - "request": { - # Random uid uniquely identifying this conversion call - "uid": "705ab4f5-6393-11e8-b7cc-42010a800002", - - # The API group and version the objects should be converted to - "desiredAPIVersion": "example.com/v1", - - # The list of objects to convert. - # May contain one or more objects, in one or more versions. - "objects": [ - { - "kind": "CronTab", - "apiVersion": "example.com/v1beta1", - "metadata": { - "creationTimestamp": "2019-09-04T14:03:02Z", - "name": "local-crontab", - "namespace": "default", - "resourceVersion": "143", - "uid": "3415a7fc-162b-4300-b5da-fd6083580d66" - }, - "hostPort": "localhost:1234" - }, - { - "kind": "CronTab", - "apiVersion": "example.com/v1beta1", - "metadata": { - "creationTimestamp": "2019-09-03T13:02:01Z", - "name": "remote-crontab", - "resourceVersion": "12893", - "uid": "359a83ec-b575-460d-b553-d859cedde8a0" - }, - "hostPort": "example.com:2345" - } - ] - } -} +apiVersion: apiextensions.k8s.io/v1 +kind: ConversionReview +request: + # 用来唯一标识此转换调用的随机 UID + uid: 705ab4f5-6393-11e8-b7cc-42010a800002 + + # 对象要转换到的目标 API 组和版本 + desiredAPIVersion: example.com/v1 + + # 要转换的对象列表 + # 其中可能包含一个或多个对象，版本可能相同也可能不同 + objects: + - kind: CronTab + apiVersion: example.com/v1beta1 + metadata: + creationTimestamp: "2019-09-04T14:03:02Z" + name: local-crontab + namespace: default + resourceVersion: "143" + uid: "3415a7fc-162b-4300-b5da-fd6083580d66" + hostPort: "localhost:1234" + - kind: CronTab + apiVersion: example.com/v1beta1 + metadata: + creationTimestamp: "2019-09-03T13:02:01Z" + name: remote-crontab + resourceVersion: "12893", + uid: "359a83ec-b575-460d-b553-d859cedde8a0" + hostPort: example.com:2345 ``` {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} ```yaml -{ - # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 - "apiVersion": "apiextensions.k8s.io/v1beta1", - "kind": "ConversionReview", - "request": { - # Random uid uniquely identifying this conversion call - "uid": "705ab4f5-6393-11e8-b7cc-42010a800002", - - # The API group and version the objects should be converted to - "desiredAPIVersion": "example.com/v1", - - # The list of objects to convert. - # May contain one or more objects, in one or more versions. - "objects": [ - { - "kind": "CronTab", - "apiVersion": "example.com/v1beta1", - "metadata": { - "creationTimestamp": "2019-09-04T14:03:02Z", - "name": "local-crontab", - "namespace": "default", - "resourceVersion": "143", - "uid": "3415a7fc-162b-4300-b5da-fd6083580d66" - }, - "hostPort": "localhost:1234" - }, - { - "kind": "CronTab", - "apiVersion": "example.com/v1beta1", - "metadata": { - "creationTimestamp": "2019-09-03T13:02:01Z", - "name": "remote-crontab", - "resourceVersion": "12893", - "uid": "359a83ec-b575-460d-b553-d859cedde8a0" - }, - "hostPort": "example.com:2345" - } - ] - } -} +# v1.16 中已废弃以推荐使用 apiextensions.k8s.io/v1 +apiVersion: apiextensions.k8s.io/v1beta1 +kind: ConversionReview +request: + # 用来唯一标识此转换调用的随机 UID + uid: 705ab4f5-6393-11e8-b7cc-42010a800002 + + # 对象要转换到的目标 API 组和版本 + desiredAPIVersion: example.com/v1 + + # 要转换的对象列表 + # 其中可能包含一个或多个对象，版本可能相同也可能不同 + objects: + - kind: CronTab + apiVersion: example.com/v1beta1 + metadata: + creationTimestamp: "2019-09-04T14:03:02Z" + name: local-crontab + namespace: default + resourceVersion: "143" + uid: "3415a7fc-162b-4300-b5da-fd6083580d66" + hostPort: "localhost:1234" + - kind: CronTab + apiVersion: example.com/v1beta1 + metadata: + creationTimestamp: "2019-09-03T13:02:01Z" + name: remote-crontab + resourceVersion: "12893", + uid: "359a83ec-b575-460d-b553-d859cedde8a0" + hostPort: example.com:2345 ``` {{% /tab %}} {{< /tabs >}} + ### 响应 -Webhooks 响应是以 200 HTTP 状态代码，`Content-Type:application/json`，和包含 ConversionReview 对象的主体（与发送的版本相同）， -带有`response`节的序列，并序列化为 JSON。 +Webhooks 响应包含 200 HTTP 状态代码、`Content-Type: application/json`， +在主体中包含 JSON 序列化形式的数据，在 `response` 节中给出 + ConversionReview 对象（与发送的版本相同）。 -如果转换成功，则 Webhook 应该返回包含以下字段的`response`节： -* `uid`，从发送到 webhook 的`request.uid`复制而来 -* `result`，设置为`{"status":"Success"}}` -* `convertedObjects`，包含来自`request.objects`的所有对象，转换为`request.desiredVersion` +如果转换成功，则 Webhook 应该返回包含以下字段的 `response` 节： + +* `uid`，从发送到 webhook 的 `request.uid` 复制而来 +* `result`，设置为 `{"status":"Success"}}` +* `convertedObjects`，包含来自 `request.objects` 的所有对象，均已转换为 + `request.desiredVersion` Webhook 的最简单成功响应示例： {{< tabs name="ConversionReview_response_success" >}} {{% tab name="apiextensions.k8s.io/v1" %}} ```yaml -{ - "apiVersion": "apiextensions.k8s.io/v1", - "kind": "ConversionReview", - "response": { - # must match - "uid": "705ab4f5-6393-11e8-b7cc-42010a800002", - "result": { - "status": "Success" - }, - # Objects must match the order of request.objects, and have apiVersion set to . - # kind, metadata.uid, metadata.name, and metadata.namespace fields must not be changed by the webhook. - # metadata.labels and metadata.annotations fields may be changed by the webhook. - # All other changes to metadata fields by the webhook are ignored. - "convertedObjects": [ - { - "kind": "CronTab", - "apiVersion": "example.com/v1", - "metadata": { - "creationTimestamp": "2019-09-04T14:03:02Z", - "name": "local-crontab", - "namespace": "default", - "resourceVersion": "143", - "uid": "3415a7fc-162b-4300-b5da-fd6083580d66" - }, - "host": "localhost", - "port": "1234" - }, - { - "kind": "CronTab", - "apiVersion": "example.com/v1", - "metadata": { - "creationTimestamp": "2019-09-03T13:02:01Z", - "name": "remote-crontab", - "resourceVersion": "12893", - "uid": "359a83ec-b575-460d-b553-d859cedde8a0" - }, - "host": "example.com", - "port": "2345" - } - ] - } -} +apiVersion: apiextensions.k8s.io/v1 +kind: ConversionReview +response: + # 必须与 匹配 + uid: "705ab4f5-6393-11e8-b7cc-42010a800002" + result: + status: Success + # 这里的对象必须与 request.objects 中的对象顺序相同并且其 apiVersion + # 被设置为 。 + # kind、metadata.uid、metadata.name 和 metadata.namespace 等字段都不可 + # 被 Webhook 修改。 + # Webhook 可以更改 metadata.labels 和 metadata.annotations 字段值 + # Webhook 对 metadata 中其他字段的更改都会被忽略 + convertedObjects: + - kind: CronTab + apiVersion: example.com/v1 + metadata: + creationTimestamp: "2019-09-04T14:03:02Z" + name: local-crontab + namespace: default + resourceVersion: "143", + uid: "3415a7fc-162b-4300-b5da-fd6083580d66" + host: localhost + port: "1234" + - kind: CronTab + apiVersion: example.com/v1 + metadata: + creationTimestamp: "2019-09-03T13:02:01Z", + name: remote-crontab + resourceVersion: "12893", + uid: "359a83ec-b575-460d-b553-d859cedde8a0" + host: example.com + port: "2345" ``` {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} ```yaml -{ - # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 - "apiVersion": "apiextensions.k8s.io/v1beta1", - "kind": "ConversionReview", - "response": { - # must match - "uid": "705ab4f5-6393-11e8-b7cc-42010a800002", - "result": { - "status": "Failed" - }, - # Objects must match the order of request.objects, and have apiVersion set to . - # kind, metadata.uid, metadata.name, and metadata.namespace fields must not be changed by the webhook. - # metadata.labels and metadata.annotations fields may be changed by the webhook. - # All other changes to metadata fields by the webhook are ignored. - "convertedObjects": [ - { - "kind": "CronTab", - "apiVersion": "example.com/v1", - "metadata": { - "creationTimestamp": "2019-09-04T14:03:02Z", - "name": "local-crontab", - "namespace": "default", - "resourceVersion": "143", - "uid": "3415a7fc-162b-4300-b5da-fd6083580d66" - }, - "host": "localhost", - "port": "1234" - }, - { - "kind": "CronTab", - "apiVersion": "example.com/v1", - "metadata": { - "creationTimestamp": "2019-09-03T13:02:01Z", - "name": "remote-crontab", - "resourceVersion": "12893", - "uid": "359a83ec-b575-460d-b553-d859cedde8a0" - }, - "host": "example.com", - "port": "2345" - } - ] - } -} +# v1.16 中已弃用以推荐使用 apiextensions.k8s.io/v1 +apiVersion: apiextensions.k8s.io/v1beta1 +kind: ConversionReview +response: + # 必须与 匹配 + uid: "705ab4f5-6393-11e8-b7cc-42010a800002" + result: + status: Failed + # 这里的对象必须与 request.objects 中的对象顺序相同并且其 apiVersion + # 被设置为 。 + # kind、metadata.uid、metadata.name 和 metadata.namespace 等字段都不可 + # 被 Webhook 修改。 + # Webhook 可以更改 metadata.labels 和 metadata.annotations 字段值 + # Webhook 对 metadata 中其他字段的更改都会被忽略 + convertedObjects: + - kind: CronTab + apiVersion: example.com/v1 + metadata: + creationTimestamp: "2019-09-04T14:03:02Z" + name: local-crontab + namespace: default + resourceVersion: "143", + uid: "3415a7fc-162b-4300-b5da-fd6083580d66" + host: localhost + port: "1234" + - kind: CronTab + apiVersion: example.com/v1 + metadata: + creationTimestamp: "2019-09-03T13:02:01Z", + name: remote-crontab + resourceVersion: "12893", + uid: "359a83ec-b575-460d-b553-d859cedde8a0" + host: example.com + port: "2345" ``` {{% /tab %}} {{< /tabs >}} + +如果转换失败，则 Webhook 应该返回包含以下字段的 `response` 节： -如果转换失败，则 Webhook 应该返回包含以下字段的`response`节： -*`uid`，从发送到 webhook 的`request.uid`复制而来 -*`result`，设置为`{"status":"Failed"}` +*`uid`，从发送到 Webhook 的 `request.uid` 复制而来 +*`result`，设置为 `{"status": "Failed"}` {{< warning >}} - -转换失败会破坏对自定义资源的读写访问，包括更新或删除资源的能力。转换失败应尽可能避免使用，并且不应用于强制验证 - 约束（改用验证模式 或 Webhook admission）。 +转换失败会破坏对定制资源的读写访问，包括更新或删除资源的能力。 +转换失败应尽可能避免，并且不可用于实施合法性检查约束 +（应改用验证模式或 Webhook 准入插件）。 {{< /warning >}} - -写入对象时，它将保留在写入时指定为存储版本的版本中。如果存储版本发生变化，现有对象永远不会自动转换。然而，新创建或更新的对象将在新的存储版本中编写。对象可能已在不再被服务的版本中编写。 +写入对象时，将使用写入时指定的存储版本来存储。如果存储版本发生变化， +现有对象永远不会被自动转换。然而，新创建或被更新的对象将以新的存储版本写入。 +对象写入的版本不再被支持是有可能的。 - -当读取对象时，将版本指定为路径的一部分。 -如果指定的版本与对象的持久版本不同，Kubernetes 会在您请求的版本里将对象返还给您，但是在提供请求时，持久化对象既不会在磁盘上更改，也不会以任何方式进行转换（除了更改`apiVersion`字符串）。您可以在当前提供的任何版本中请求对象。 +当读取对象时，作为路径的一部分，你需要指定版本。 +如果所指定的版本与对象的持久版本不同，Kubernetes 会按所请求的版本将对象返回， +但是在满足服务请求时，被持久化的对象既不会在磁盘上更改，也不会以任何方式进行 +转换（除了 `apiVersion` 字符串被更改之外）。你可以以当前提供的任何版本 +来请求对象。 -如果您更新了一个现有对象，它将在现在的存储版本中被重写。 -这是对象可以从一个版本改到另一个版本的唯一办法。 +如果你更新一个现有对象，它将以当前的存储版本被重写。 +这是可以将对象从一个版本改到另一个版本的唯一办法。 -1. 存储版本是`v1beta1`。 - 它保存在版本`v1beta1`的存储中。 -2. 您将版本`v1`添加到 CustomResourceDefinition 中，并将其指定为存储版本。 -3. 您在版本`v1beta1`中读取您的对象，然后您再次在版本`v1`中读取对象。 - 除了 apiVersion 字段之外，两个返回的对象都是相同的。 -4. 您创建一个新对象。 - 它存储在版本`v1`的存储中。 - 您现在有两个对象，其中一个位于`v1beta1`，另一个位于`v1`。 -5. 您更新第一个对象。 - 它现在保存在版本`v1`中，因为那是当前的存储版本。 +1. 存储版本是 `v1beta1`。你创建一个对象。该对象以版本 `v1beta1` 存储。 +2. 你将为 CustomResourceDefinition 添加版本 `v1`，并将其指定为存储版本。 +3. 你使用版本 `v1beta1` 来读取你的对象，然后你再次用版本 `v1` 读取对象。 + 除了 apiVersion 字段之外，返回的两个对象是完全相同的。 +4. 你创建一个新对象。对象以版本 `v1` 保存在存储中。 + 你现在有两个对象，其中一个是 `v1beta1`，另一个是 `v1`。 +5. 你更新第一个对象。该对象现在以版本 `v1` 保存，因为 `v1` 是当前的存储版本。 -API 服务在状态字段`storedVersions`中记录曾被标记为存储版本的每个版本。 -对象可能已被保留在任何曾被指定为存储版本的版本中。 -从未成为存储版本的版本的存储中不能存在任何对象。 +API 服务器在状态字段 `storedVersions` 中记录曾被标记为存储版本的每个版本。 +对象可能以任何曾被指定为存储版本的版本保存。 +存储中不会出现从未成为存储版本的版本的对象。 -## 将现有对象升级到新的存储版本 +## 将现有对象升级到新的存储版本 {#upgrade-existing-objects-to-a-new-stored-version} -弃用版本并删除支持时，请设计存储升级过程。 -以下是从`v1beta1`升级到`v1`的示例过程。 +弃用版本并删除其支持时，请设计存储升级过程。 + + + +*选项 1：* 使用存储版本迁移程序（Storage Version Migrator） + +1. 运行[存储版本迁移程序](https://github.com/kubernetes-sigs/kube-storage-version-migrator) +2. 从 CustomResourceDefinition 的 `status.storedVersions` 字段中去掉 + 老的版本。 + + +*选项 2：* 手动将现有对象升级到新的存储版本 + +以下是从 `v1beta1` 升级到 `v1` 的示例过程。 -1. 将`v1`设置为 CustomResourceDefinition 文件中的存储，并使用 kubectl 应用它。 - `storedVersions`现在是`v1beta1、 v1`。 -2. 编写升级过程以列出所有现有对象并使用相同内容编写它们。 - 这会强制后端在当前存储版本中写入对象，即`v1`。 -3. 通过从`storedVersions`字段中删除`v1beta1`来更新 CustomResourceDefinition`Status`。 - +1. 在 CustomResourceDefinition 文件中将 `v1` 设置为存储版本，并使用 kubectl 应用它。 + `storedVersions`现在是`v1beta1, v1`。 +2. 编写升级过程以列出所有现有对象并使用相同内容将其写回存储。 + 这会强制后端使用当前存储版本（即 `v1`）写入对象。 +3. 通过从 `storedVersions` 字段中删除 `v1beta1` 来更新 CustomResourceDefinition + 的`Status`。 From 30badbc6ec93dc8daf1398eadc18b3962d4a0471 Mon Sep 17 00:00:00 2001 From: guzj11 <67083623+guzj11@users.noreply.github.com> Date: Thu, 3 Dec 2020 16:10:13 +0800 Subject: [PATCH 16/66] Update managing-secret-using-kubectl.md --- .../tasks/configmap-secret/managing-secret-using-kubectl.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index 5105500f0e..fd19481f92 100644 --- a/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -141,8 +141,8 @@ Type: Opaque Data ==== -password.txt: 12 bytes -username.txt: 5 bytes +password: 12 bytes +username: 5 bytes ``` ## 禁用加速器指标 @@ -185,7 +185,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结 现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器， 并将其公开给指标服务（例如 Prometheus）。 -[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) +[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gate.md) 禁止由 kubelet 收集的指标。 关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。 From 9ddc0a3ad9e76286ecc7a316249d391930a54c6f Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 8 Sep 2020 16:06:42 +0800 Subject: [PATCH 20/66] Add links to volumes from persistent volumes When working with persistent volumes, I have to refer to the persitent volumes page now and then, only to find that the information I need is on a different page. The PR - adds some links to ease navigation and - currects the spelling of volume types, for example, `iscsi` is the type to specify rather than `iSCSI`, - sort the volume type list in alphabetic order. - added `photonPersistentDisk` as one of valid persistent volume type to use, though we don't have any documentation other than API spec for it. --- .../concepts/storage/persistent-volumes.md | 51 +++++++++++-------- 1 file changed, 30 insertions(+), 21 deletions(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index cf915bfa52..f510f16c10 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -308,28 +308,37 @@ If expanding underlying storage fails, the cluster administrator can manually re ## Types of Persistent Volumes -PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins: +PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins: -* GCEPersistentDisk -* AWSElasticBlockStore -* AzureFile -* AzureDisk -* CSI -* FC (Fibre Channel) -* FlexVolume -* Flocker -* NFS -* iSCSI -* RBD (Ceph Block Device) -* CephFS -* Cinder (OpenStack block storage) -* Glusterfs -* VsphereVolume -* Quobyte Volumes -* HostPath (Single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster) -* Portworx Volumes -* ScaleIO Volumes -* StorageOS +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) +* [`azureDisk`](/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**deprecated**) +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume +* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk +* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (for single node testing only; WILL NOT WORK in a multi-node cluster; + consider using `local` volume instead) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - local storage devices + mounted on nodes. +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage +* `photonPersistentDisk` - Photon controller persistent disk. + (This volume type no longer works since the removal of the corresponding + cloud provider.) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume +* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume +* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume + (**deprecated**) +* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume ## Persistent Volumes From e837312f1fb63baddbf1500af92ab811fa07f776 Mon Sep 17 00:00:00 2001 From: Janet Kuo Date: Thu, 3 Dec 2020 17:20:22 -0800 Subject: [PATCH 21/66] Remove problems in DaemonSet fixed by controllerRef The sentence describes a problem that's solved by the introduction of controllerRef (ownerRef with controller==true) feature. Removing it. --- content/en/docs/concepts/workloads/controllers/daemonset.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index ecf884884a..4dd784d905 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -87,12 +87,6 @@ When the two are specified the result is ANDed. If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API. -Also you should not normally create any Pods whose labels match this selector, either directly, via -another DaemonSet, or via another workload resource such as ReplicaSet. Otherwise, the DaemonSet -{{< glossary_tooltip term_id="controller" >}} will think that those Pods were created by it. -Kubernetes will not stop you from doing this. One case where you might want to do this is manually -create a Pod with a different value on a node for testing. - ### Running Pods on select Nodes If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will From 482351ef2a268de28f435d96d35dd5dfdb671793 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 4 Dec 2020 14:10:01 +0800 Subject: [PATCH 22/66] [zh] Fix links in zh localization (1) --- .../control-plane-node-communication.md | 14 +-- .../docs/concepts/architecture/controller.md | 25 ++-- .../zh/docs/concepts/architecture/nodes.md | 2 - .../configuration/pod-priority-preemption.md | 13 +-- .../zh/docs/concepts/configuration/secret.md | 2 +- .../scheduling-eviction/kube-scheduler.md | 60 ++++++---- .../scheduling-framework.md | 8 +- .../taint-and-toleration.md | 2 +- .../services-networking/service-topology.md | 107 +++++++----------- .../concepts/storage/persistent-volumes.md | 7 +- .../docs/concepts/storage/storage-capacity.md | 26 +++-- content/zh/docs/concepts/storage/volumes.md | 15 ++- content/zh/docs/concepts/workloads/_index.md | 2 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/replicaset.md | 2 +- .../workloads/controllers/statefulset.md | 101 +++++++++++------ .../zh/docs/concepts/workloads/pods/_index.md | 2 +- .../concepts/workloads/pods/disruptions.md | 10 +- .../workloads/pods/ephemeral-containers.md | 2 +- .../pods/pod-topology-spread-constraints.md | 7 +- 20 files changed, 229 insertions(+), 180 deletions(-) diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md index 182aaf5162..dc31269f47 100644 --- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md @@ -32,10 +32,10 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。 apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求， -并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。 +并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， -特别是在允许使用[匿名请求](/docs/reference/access-authn-authz/authentication/#anonymous-requests) -或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 +特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests) +或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 -这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。 +这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的， +能够在不可信的网络或公网上运行。 - ### SSH 隧道 {#ssh-tunnels} Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver @@ -158,7 +158,6 @@ After enabling the Konnectivity service, all control plane to nodes traffic goes Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster. --> - ### Konnectivity 服务 {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -168,5 +167,6 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。 -请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/) +请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/) 在你的集群中配置 Konnectivity 服务。 + diff --git a/content/zh/docs/concepts/architecture/controller.md b/content/zh/docs/concepts/architecture/controller.md index 6178bd68f0..fc82c14ee7 100644 --- a/content/zh/docs/concepts/architecture/controller.md +++ b/content/zh/docs/concepts/architecture/controller.md @@ -139,21 +139,23 @@ Controllers that interact with external state find their desired state from the API server, then communicate directly with an external system to bring the current state closer in line. -(There actually is a controller that horizontally scales the -nodes in your cluster. See -[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). +(There actually is a [controller](https://github.com/kubernetes/autoscaler/) +that horizontally scales the nodes in your cluster.) --> ### 直接控制 {#direct-control} 相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。 -例如，如果你使用一个控制环来保证集群中有足够的{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制就需要当前集群外的一些服务在需要时创建新节点。 +例如，如果你使用一个控制回路来保证集群中有足够的 +{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制器就需要当前集群外的 +一些服务在需要时创建新节点。 -和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。 +和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信 +并使当前状态更接近期望状态。 -（实际上有一个控制器可以水平地扩展集群中的节点。请参阅 -[集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。 +（实际上有一个[控制器](https://github.com/kubernetes/autoscaler/) +可以水平地扩展集群中的节点。请参阅 * 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components) -* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一些基本知识 +* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) + 的一些基本知识 * 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) -* 如果你想编写自己的控制器，请看 Kubernetes 的[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 +* 如果你想编写自己的控制器，请看 Kubernetes 的 + [扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 3e2ec24243..490599289d 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -627,11 +627,9 @@ for more information. * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). -* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). --> * 了解有关节点[组件](/zh/docs/concepts/overview/components/#node-components) * 阅读[节点的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core) * 阅读架构设计文档中有关[节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)的章节 * 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) -* 了解[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) diff --git a/content/zh/docs/concepts/configuration/pod-priority-preemption.md b/content/zh/docs/concepts/configuration/pod-priority-preemption.md index 8b601a292a..4af00bd2f1 100644 --- a/content/zh/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/zh/docs/concepts/configuration/pod-priority-preemption.md @@ -17,12 +17,12 @@ weight: 70 {{< feature-state for_k8s_version="v1.14" state="stable" >}} -[Pods](/zh/docs/concepts/workloads/pods/pod/) 可以有*优先级（Priority）*。 +[Pods](/zh/docs/concepts/workloads/pods/) 可以有*优先级（Priority）*。 优先级体现的是当前 Pod 与其他 Pod 相比的重要程度。如果 Pod 无法被调度，则 调度器会尝试抢占（逐出）低优先级的 Pod，从而使得悬决的 Pod 可被调度。 @@ -460,7 +460,7 @@ despite their PDBs being violated. --> #### PodDisruptionBudget 是被支持的，但不提供保证 -[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB) +[PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) (PDB) 的存在使得应用的属主能够限制多副本应用因主动干扰而同时离线的 Pod 的个数。 Kubernetes 在抢占 Pod 时是可以支持 PDB 的，但对 PDB 的约束也仅限于尽力而为。 调度器会尝试寻找不会因为抢占而违反其 PDB 约束的 Pod 作为牺牲品，不过如果 @@ -628,17 +628,12 @@ Pod may be created that fits on the same Node. In this case, the scheduler will schedule the higher priority Pod instead of the preemptor. This is expected behavior: the Pod with the higher priority should take the place -of a Pod with a lower priority. Other controller actions, such as -[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling), -may eventually provide capacity to schedule the pending Pods. +of a Pod with a lower priority. --> 在抢占者 Pod 等待被牺牲的 Pod 消失期间，可能有更高优先级的 Pod 被创建，且适合 调度到同一节点。如果是这种情况，调度器会调度优先级更高的 Pod 而不是抢占者。 这是期望发生的行为：优先级更高的 Pod 应该取代优先级较低的 Pod。 -其他控制器行为，例如 -[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) -可能会最终为集群添加容量，以调度悬决 Pod。 在 Kubernetes 中，_调度_ 是指将 {{< glossary_tooltip text="Pod" term_id="pod" >}} 放置到合适的 -{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的 {{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。 - - +{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的 +{{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。 -调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来做出调度选择。 +调度器通过 kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。 +调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。 +调度器会依据下文的调度原则来做出调度选择。 -如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现一个自定义的调度器，这篇文章将帮助你了解调度。 +如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现 +一个自定义的调度器，这篇文章将帮助你了解调度。 -[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。 +[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) +是 Kubernetes 集群的默认调度器，并且是集群 +{{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。 +如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许 +你自己写一个调度组件并替换原有的 kube-scheduler。 -对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。 +对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 +Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 +Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前， +根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。 -在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。 +在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。 +如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在 +未调度状态直到调度器能够找到合适的 Node。 -调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做 _绑定_。 +调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分， +选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 +kube-apiserver，这个过程叫做 _绑定_。 -在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。 +在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 +亲和以及反亲和要求、数据局域性、负载间的干扰等等。 -过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。 +过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。 +例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。 +在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下， +这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。 -在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。 +在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。 +根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。 -最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。 +最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。 +如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。 -1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。 -2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。 - +1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ + 和打分的 _优先级(Priorities)_ 。 +2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， + 包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。 + 你也可以配置 kube-scheduler 运行不同的配置文件。 ## {{% heading "whatsnext" %}} - - - * 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) -* 了解关于 [配置多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式 +* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式 * 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) * 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md index 4e85bb9a38..d757a654be 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -448,12 +448,12 @@ type PreFilterPlugin interface { 你可以在调度器配置中启用或禁用插件。 如果你在使用 Kubernetes v1.18 或更高版本，大部分调度 -[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins) +[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins) 都在使用中且默认启用。 如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为 一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。 -了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。 +了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。 diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md index c98f159554..c2631fb958 100644 --- a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -516,6 +516,6 @@ arbitrary tolerations to DaemonSets. * Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/) --> * 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为 -* 阅读 [Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/) +* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) diff --git a/content/zh/docs/concepts/services-networking/service-topology.md b/content/zh/docs/concepts/services-networking/service-topology.md index 95459727a0..ea84fddfab 100644 --- a/content/zh/docs/concepts/services-networking/service-topology.md +++ b/content/zh/docs/concepts/services-networking/service-topology.md @@ -23,10 +23,8 @@ topology of the cluster. For example, a service can specify that traffic be preferentially routed to endpoints that are on the same Node as the client, or in the same availability zone. --> - -`Service` 拓扑可以让一个服务基于集群的 `Node` 拓扑进行流量路由。例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 `Node` 或者在同一可用区域的端点。 - - +服务拓扑（Service Topology）可以让一个服务基于集群的 Node 拓扑进行流量路由。 +例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。 @@ -51,50 +49,20 @@ with it, while intrazonal traffic does not. Other common needs include being abl to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to Nodes connected to the same top-of-rack switch for the lowest latency. --> - ## 介绍 {#introduction} -默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。从 Kubernetes 1.7 开始，可以将“外部”流量路由到节点上运行的 pod 上，但不支持 `ClusterIP` 服务，更复杂的拓扑 — 比如分区路由 — 也还不支持。通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略，`Service` 拓扑特性实现了服务流量的路由。 +默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。 +从 Kubernetes 1.7 开始，可以将“外部”流量路由到节点上运行的 Pod 上，但不支持 `ClusterIP` 服务， +更复杂的拓扑 — 比如分区路由 — 也还不支持。 +通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略， +服务拓扑特性实现了服务流量的路由。 -通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值来指定彼此“较近”和“较远”的节点组。例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内，因为区域间的流量是有费用成本的，而区域内的流量没有。其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。 - - - -## 前提条件 {#prerequisites} - -为了启用拓扑感知服务路由功能，必须要满足以下一些前提条件： - - * Kubernetes 的版本不低于 1.17 - * Kube-proxy 运行在 iptables 模式或者 IPVS 模式 - * 启用 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)功能 - - - -## 启用 `Service` 拓扑 {#enable-service-topology} - -要启用 `Service` 拓扑，就要给 kube-apiserver 和 kube-proxy 启用 `ServiceTopology` 功能： - -``` ---feature-gates="ServiceTopology=true" -``` +通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值 +来指定彼此“较近”和“较远”的节点组。 +例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内， +因为区域间的流量是有费用成本的，而区域内的流量没有。 +其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者 +把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。 -## 使用 `Service` 拓扑 {#using-service-topology} +## 使用服务拓扑 {#using-service-topology} -如果集群启用了 `Service` 拓扑功能后，就可以在 `Service` 配置中指定 `topologyKeys` 字段，从而控制 `Service` 的流量路由。此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。如果这个 `Service` 没有匹配的后端 `Node`，那么第二个标签会被使用做匹配，以此类推，直到没有标签。 +如果集群启用了服务拓扑功能后，就可以在 `Service` 配置中指定 `topologyKeys` 字段， +从而控制 `Service` 的流量路由。 +此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。 +流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。 +如果这个 `Service` 没有匹配的后端 `Node`，那么第二个标签会被使用做匹配， +以此类推，直到没有标签。 -如果没有匹配到，流量会被拒绝，就如同这个 `Service` 根本没有后端。这是根据有可用后端的第一个拓扑键来选择端点的。如果这个字段被配置了而没有后端可以匹配客户端拓扑，那么这个 `Service` 对那个客户端是没有后端的，链接应该是失败的。这个字段配置为 `"*"` 意味着任意拓扑。这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。 +如果没有匹配到，流量会被拒绝，就如同这个 `Service` 根本没有后端。 +换言之，系统根据可用后端的第一个拓扑键来选择端点。 +如果这个字段被配置了而没有后端可以匹配客户端拓扑，那么这个 `Service` +对那个客户端是没有后端的，链接应该是失败的。 +这个字段配置为 `"*"` 意味着任意拓扑。 +这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。 +如果 `topologyKeys` 没有指定或者为空，就没有启用这个拓扑约束。 -如果 `topologyKeys` 没有指定或者为空，就没有启用这个拓扑功能。 +一个集群中，其 `Node` 的标签被打为其主机名，区域名和地区名。 +那么就可以设置 `Service` 的 `topologyKeys` 的值，像下面的做法一样定向流量了。 -一个集群中，其 `Node` 的标签被打为其主机名，区域名和地区名。那么就可以设置 `Service` 的 `topologyKeys` 的值，像下面的做法一样定向流量了。 - -* 只定向到同一个 `Node` 上的端点，`Node` 上没有端点存在时就失败：配置 `["kubernetes.io/hostname"]`。 -* 偏向定向到同一个 `Node` 上的端点，回退同一区域的端点上，然后是同一地区，其它情况下就失败：配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。这或许很有用，例如，数据局部性很重要的情况下。 -* 偏向于同一区域，但如果此区域中没有可用的终结点，则回退到任何可用的终结点：配置 `["topology.kubernetes.io/zone", "*"]`。 +* 只定向到同一个 `Node` 上的端点，`Node` 上没有端点存在时就失败： + 配置 `["kubernetes.io/hostname"]`。 +* 偏向定向到同一个 `Node` 上的端点，回退同一区域的端点上，然后是同一地区， + 其它情况下就失败：配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。 + 这或许很有用，例如，数据局部性很重要的情况下。 +* 偏向于同一区域，但如果此区域中没有可用的终结点，则回退到任何可用的终结点： + 配置 `["topology.kubernetes.io/zone", "*"]`。 - -* 阅读关于[启用服务拓扑](/docs/tasks/administer-cluster/enabling-service-topology) -* 阅读[用 `Services` 连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) - +* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/) +* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh/docs/concepts/storage/persistent-volumes.md index 48fbce7566..7c58f225d5 100644 --- a/content/zh/docs/concepts/storage/persistent-volumes.md +++ b/content/zh/docs/concepts/storage/persistent-volumes.md @@ -3,7 +3,10 @@ title: 持久卷 feature: title: 存储编排 description: > - 自动挂载所选存储系统，包括本地存储、诸如 GCP 或 AWS 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder 或 Flocker 这类网络存储系统。 + 自动挂载所选存储系统，包括本地存储、诸如 GCP + 或 AWS + 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder + 或 Flocker 这类网络存储系统。 content_type: concept weight: 20 @@ -1053,7 +1056,7 @@ be bound to the PVC. ### 类 {#class} 申领可以通过为 `storageClassName` 属性设置 -[StorageClass](/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。 +[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。 只有所请求的类的 PV 卷，即 `storageClassName` 值与 PVC 设置相同的 PV 卷， 才能绑定到 PVC 申领。 diff --git a/content/zh/docs/concepts/storage/storage-capacity.md b/content/zh/docs/concepts/storage/storage-capacity.md index 24c86537b8..c5911f0154 100644 --- a/content/zh/docs/concepts/storage/storage-capacity.md +++ b/content/zh/docs/concepts/storage/storage-capacity.md @@ -23,11 +23,13 @@ Tracking storage capacity is supported for {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) drivers and [needs to be enabled](#enabling-storage-capacity-tracking) when installing a CSI driver. --> -存储容量是有限的，并且会因为运行 pod 的节点不同而变化：网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。 +存储容量是有限的，并且会因为运行 Pod 的节点不同而变化： +网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。 {{< feature-state for_k8s_version="v1.19" state="alpha" >}} -本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 Pod 调度到能够访问到足够存储容量的节点上。 +本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 +Pod 调度到能够访问到足够存储容量的节点上。 如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。 {{< glossary_tooltip text="容器存储接口" term_id="csi" >}}（CSI）驱动程序支持跟踪存储容量， @@ -51,9 +53,10 @@ There are two API extensions for this feature: 这个特性有两个 API 扩展接口： - [CSIStorageCapacity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csistoragecapacity-v1alpha1-storage-k8s-io) -对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。 + 对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。 + 每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。 - [`CSIDriverSpec.StorageCapacity` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io)： -设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。 + 设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。 ## 开启存储容量跟踪 -存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/) +存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 和 `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API 组" term_id="api-group" >}}启用时才能启用。 -更多详细信息，可以查看`--feature-gates` 和 `--runtime-config` [kube-apiserver 参数](/docs/reference/command-line-tools-reference/kube-apiserver/)。 +更多详细信息，可以查看`--feature-gates` 和 `--runtime-config` +[kube-apiserver 参数](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。 如果不支持，下面这个错误就会被打印出来： + ``` error: the server doesn't have a resource type "csistoragecapacities" ``` @@ -218,6 +224,8 @@ error: the server doesn't have a resource type "csistoragecapacities" - For more information on further development of this feature, see the [enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472). - Learn about [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) --> -- 想要获得更多该设计的信息，查看 [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。 -- 有关此功能的进一步开发信息，查看[enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。 -- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。 \ No newline at end of file +- 想要获得更多该设计的信息，查看 + [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。 +- 有关此功能的进一步开发信息，查看 + [enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。 +- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。 diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index cd16a93a54..71139871bc 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -1190,7 +1190,7 @@ iSCSI volume) without knowing the details of the particular cloud environment. See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more details. --> -更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)。 +更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)。 ### portworxVolume {#portworxvolume} @@ -1371,7 +1371,9 @@ for the current [service account](/docs/reference/access-authn-authz/authenticat into a Pod at a specified path. Below is an example: --> -当开启 `TokenRequestProjection` 功能时，可以将当前 [服务帐户](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的令牌注入 Pod 中的指定路径。 +当开启 `TokenRequestProjection` 功能时，可以将当前 +[服务帐号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) +的令牌注入 Pod 中的指定路径。 下面是一个例子： ```yaml @@ -1455,7 +1457,8 @@ GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte --> Quobyte 支持{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}。 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 -Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi) +Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的 +[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi) 及使用示例。 ### rbd @@ -1748,7 +1751,8 @@ spec: -进一步信息可参考[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。 +进一步信息可参考 +[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。 当 `vsphereVolume` 的 `CSIMigration` 特性被启用时，所有插件操作都被从树内插件重定向到 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。 -为了使用此功能特性，必须在集群中安装[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)， +为了使用此功能特性，必须在集群中安装 +[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)， 并启用 `CSIMigration` 和 `CSIMigrationvSphere` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 diff --git a/content/zh/docs/concepts/workloads/_index.md b/content/zh/docs/concepts/workloads/_index.md index 911e8e0343..a6594a7018 100644 --- a/content/zh/docs/concepts/workloads/_index.md +++ b/content/zh/docs/concepts/workloads/_index.md @@ -114,5 +114,5 @@ mechanisms for separating code from configuration. 一旦你的应用处于运行状态，你就可能想要 以[服务](/zh/docs/concepts/services-networking/service/) 使之在互联网上可访问；或者对于 Web 应用而言，使用 -[Ingress](/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 +[Ingress](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md index ece35c15cf..5ad4bf617a 100644 --- a/content/zh/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md @@ -236,7 +236,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。 * Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态， DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。 -* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/) +* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/) 由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占 的情况下制定调度决策。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md index 4446ad496b..96ad968542 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -405,7 +405,7 @@ be rejected by the API. ### Pod 选择算符 {#pod-selector} `.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 -如前文中[所讨论的](how-a-replicaset-works)，这些是用来标识要被获取的 Pods +如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pods 的标签。在签名的 `frontend.yaml` 示例中，选择算符为： ```yaml diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md index 100343be99..cdc0383316 100644 --- a/content/zh/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md @@ -50,7 +50,12 @@ that provides a set of stateless replicas. [Deployment](/docs/concepts/workloads/controllers/deployment/) or [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs. --> -在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态应用部署需要。 +在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。 +如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用 +由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 +[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +可能更适用于你的无状态应用部署需要。 -* 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供，或者由管理员预先提供。 -* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。 -* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) 来负责 Pod 的网络标识。您需要负责创建此服务。 -* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为 0。 -* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates)，可能进入需要 [人工干预](#forced-rollback) 才能修复的损坏状态。 +* 给定 Pod 的存储必须由 + [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) + 基于所请求的 `storage class` 来提供，或者由管理员预先提供。 +* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。 + 这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。 +* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + 来负责 Pod 的网络标识。你需要负责创建此服务。 +* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。 + 为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet + 缩放为 0。 +* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 + [滚动更新](#rolling-updates)，可能进入需要[人工干预](#forced-rollback) + 才能修复的损坏状态。 -您必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 `.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前，被忽略 `.spec.selector` 字段会获得默认设置值。在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。 +你必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 +`.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前， +被忽略 `.spec.selector` 字段会获得默认设置值。 +在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。 ## Pod 标识 {#pod-identity} -StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。 +StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。 +该标识和 Pod 是绑定的，不管它被调度在哪个节点上。 ### 有序索引 {#ordinal-index} -对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。 +对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号， +从 0 到 N-1，该序号在 StatefulSet 上是唯一的。 ### 稳定的存储 {#stable-storage} -Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。 +Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。 在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。 当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 @@ -250,7 +269,9 @@ the StatefulSet. --> ### Pod 名称标签 {#pod-name-label} -当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时，它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。 +当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时， +它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签值设置为 Pod 名称。 +这个标签允许你给 StatefulSet 中的特定 Pod 绑定一个 Service。 - -如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。 +如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。 +在 web-2 没有被完全停止和删除前，web-1 不会被终止。 +当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败， +那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。 ### Pod 管理策略 {#pod-management-policies} -在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您不要求其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 -在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放宽其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 +在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许你放宽其排序保证， +同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 #### OrderedReady Pod 管理 -`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。 +`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了 +[上面](#deployment-and-scaling-guarantees)描述的功能。 ## 更新策略 {#update-strategies} -在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。 +在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让 +你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。 ### 关于删除策略 {#on-delete} -`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。 - +`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 +`.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 +StatefulSet 中的 Pod。 +用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 +`.spec.template` 的变动作出反应。 ### 滚动更新 {#rolling-updates} -`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。 -当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。 -它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。 +`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。 +在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。 +当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时， +StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。 +它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。 +它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。 #### 分区 {#partitions} -通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。 -在大多数情况下，您不需要使用分区，但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开，则这些分区会非常有用。 +通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` +更新策略可以实现分区。 +如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时， +所有序号大于等于该分区序号的 Pod 都会被更新。 +所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。 +如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 +`.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。 +在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行 +分阶段上线，则这些分区会非常有用。 #### 强制回滚 {#forced-rollback} -在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。 +在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用 +[滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。 -如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。 +如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件 +或应用程序级配置错误），StatefulSet 将停止回滚并等待。 - * 示例一：[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。 * 示例二：[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。 * 示例三：[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。 - - diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index dba92eebcf..1d5d40393b 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -431,7 +431,7 @@ Processes within a privileged container get almost the same privileges that are ## 容器的特权模式 {#rivileged-mode-for-containers} Pod 中的任何容器都可以使用容器规约中的 -[安全性上下文](/docs/tasks/configure-pod-container/security-context/)中的 +[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的 `privileged` 参数启用特权模式。 这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备） 的容器很有用。 diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index 3c70c6ca68..1eb8fdad1e 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -16,7 +16,7 @@ This guide is for application owners who want to build highly available applications, and thus need to understand what types of Disruptions can happen to Pods. --> -本指南针对的是希望构建高可用性应用程序的应用所有者，他们有必要了解可能发生在 pod 上的干扰类型。 +本指南针对的是希望构建高可用性应用程序的应用所有者，他们有必要了解可能发生在 Pod 上的干扰类型。 集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口 -（通过调用[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， +（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， 而不是直接删除 Pod 或 Deployment。 * 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。 -* 进一步了解[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。 +* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。 * 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 的过程，包括如何在其进程中维持应用的可用性 diff --git a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md index 0667aa206a..430a1d3c55 100644 --- a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md @@ -34,7 +34,7 @@ feature could change significantly in the future or be removed entirely. {{< warning >}} 临时容器处于早期的 alpha 阶段，不适用于生产环境集群。 应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。 -根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)， +根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)， 此 alpha 功能将来可能发生重大变化或被完全删除。 {{< /warning >}} diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index efa2621f06..1a71ad62a3 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -11,8 +11,9 @@ weight: 40 --> {{< feature-state for_k8s_version="v1.19" state="stable" >}} - + @@ -36,7 +37,7 @@ topology spread constraints. {{< note >}} 在 v1.19 之前的 Kubernetes 版本中，如果要使用 Pod 拓扑扩展约束，你必须在 [API 服务器](/zh/docs/concepts/overview/components/#kube-apiserver) -和[调度器](/zh/docs/reference/command-line-tools-referene/kube-scheduler/) +和[调度器](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 中启用 `EvenPodsSpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}} From 35b63271595553cc2e2073ab2d1ab4b37ceae539 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 4 Dec 2020 14:50:48 +0800 Subject: [PATCH 23/66] [zh] Fix links in zh localization (2) --- .../concepts/cluster-administration/_index.md | 67 +++++++++++-------- .../cluster-administration/flow-control.md | 2 +- .../cluster-administration/logging.md | 4 +- .../manage-deployment.md | 63 +++++++++++------ .../cluster-administration/system-metrics.md | 4 +- .../docs/concepts/extend-kubernetes/_index.md | 16 ++--- .../api-extension/apiserver-aggregation.md | 7 +- .../extend-kubernetes/extend-cluster.md | 8 +-- .../concepts/extend-kubernetes/operator.md | 12 ++-- .../docs/concepts/overview/kubernetes-api.md | 2 +- .../concepts/policy/pod-security-policy.md | 6 +- .../docs/concepts/policy/resource-quotas.md | 25 ++++--- .../feature-gates.md | 4 +- 13 files changed, 131 insertions(+), 89 deletions(-) diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md index 91ef1b5cc8..d1fde6c86c 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -25,7 +25,7 @@ The cluster administration overview is for anyone creating or administering a Ku It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). --> 集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你对一些核心的 Kubernetes [概念](/zh/docs/concepts/)大概了解。 +我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。 @@ -38,9 +38,10 @@ Not all distros are actively maintained. Choose distros which have been tested w Before choosing a guide, here are some considerations: --> -## 规划集群 +## 规划集群 {#planning-a-cluster} -查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 +查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes +集群的示例。本文所列的文章称为*发行版* 。 {{< note >}} 并非所有发行版都是被积极维护的。 @@ -60,27 +61,28 @@ Before choosing a guide, here are some considerations: offer a greater variety of choices. - Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster. --> -- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 -- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？ -- 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 -- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 +- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？ + 请选择最适合你需求的发行版。 +- 你正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) + 这样的**被托管的 Kubernetes 集群**, 还是**管理你自己的集群**？ +- 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。 + 作为代替，你可以建立多个集群。 +- **如果你在本地配置 Kubernetes**，需要考虑哪种 + [网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 - 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？ -- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 +- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？ + 如果是后者，请选择一个处于开发状态的发行版。 + 某些发行版只提供二进制发布版，但提供更多的选择。 - 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。 -## 管理集群 - -* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题： -创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。 +## 管理集群 {#managing-a-cluster} * 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。 @@ -98,16 +100,24 @@ Before choosing a guide, here are some considerations: * [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . * [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. --> -## 保护集群 +## 保护集群 {#securing-a-cluster} -* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。 -* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 -* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 -* [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 -* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。 -* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 -* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 -* [审计](/zh/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 +* [证书](/zh/docs/concepts/cluster-administration/certificates/) + 节描述了使用不同的工具链生成证书的步骤。 +* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/) + 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 +* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) + 描述了如何为用户和 service accounts 建立权限许可。 +* [身份认证](/zh/docs/reference/access-authn-authz/authentication/) + 节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 +* [鉴权](/zh/docs/reference/access-authn-authz/authorization/) + 与身份认证不同，用于控制如何处理 HTTP 请求。 +* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) + 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 +* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) + 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 +* [审计](/zh/docs/tasks/debug-application-cluster/audit/) + 描述了如何与 Kubernetes 的审计日志交互。 -### 保护 kubelet +### 保护 kubelet {#securing-the-kubelet} * [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/) * [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) @@ -128,9 +138,10 @@ Before choosing a guide, here are some considerations: * [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. * [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. --> +## 可选集群服务 {#optional-cluster-services} -## 可选集群服务 - -* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 -* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 +* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/) + 描述了如何将一个 DNS 名解析到一个 Kubernetes service。 +* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/) + 阐述了 Kubernetes 的日志如何工作以及怎样实现。 diff --git a/content/zh/docs/concepts/cluster-administration/flow-control.md b/content/zh/docs/concepts/cluster-administration/flow-control.md index 2738b47fc9..8ed87422ed 100644 --- a/content/zh/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh/docs/concepts/cluster-administration/flow-control.md @@ -72,7 +72,7 @@ things by adding the following command-line flags to your `kube-apiserver` invocation: --> APF 特性由特性门控控制，默认情况下不启用。有关如何启用和禁用特性门控的描述， -请参见[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。 +请参见[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 APF 的特性门控叫做 `APIPriorityAndFairness` 。 此特性要求必须启用某个 {{< glossary_tooltip term_id="api-group" text="API Group" >}}。 你可以在启动 `kube-apiserver` 时，添加以下命令行标志来完成这些操作： diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md index 762fc1c050..e858fc57a8 100644 --- a/content/zh/docs/concepts/cluster-administration/logging.md +++ b/content/zh/docs/concepts/cluster-administration/logging.md @@ -273,7 +273,7 @@ Using a node-level logging agent is the most common and encouraged approach for Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node. --> Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。 -[Stackdriver 日志](/docs/tasks/debug-application-cluster/logging-stackdriver/) +[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/) 适用于 Google Cloud Platform，和 [Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。 你可以在专门的文档中找到更多的信息和说明。 @@ -446,7 +446,7 @@ which uses fluentd as a logging agent. Here are two configuration files that you can use to implement this approach. The first file contains a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd. --> -例如，你可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)， +例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)， 它使用 fluentd 作为日志记录代理。 以下是两个可用于实现此方法的配置文件。 第一个文件包含配置 fluentd 的 diff --git a/content/zh/docs/concepts/cluster-administration/manage-deployment.md b/content/zh/docs/concepts/cluster-administration/manage-deployment.md index 55038e290d..71ece48b8a 100644 --- a/content/zh/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh/docs/concepts/cluster-administration/manage-deployment.md @@ -115,7 +115,8 @@ service "my-nginx-svc" deleted -在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中同时指定这两个资源： +在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中 +同时指定这两个资源： ```shell kubectl delete deployments/my-nginx services/my-nginx-svc @@ -184,7 +185,8 @@ project/k8s/development -默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级，而不是处理所有子目录。 +默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级， +而不是处理所有子目录。 如果我们试图使用以下命令在此目录中创建资源，则会遇到一个错误： ```shell @@ -252,7 +254,8 @@ The examples we've used so far apply at most a single label to any resource. The For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels: --> 例如，不同的应用可能会为 `app` 标签设置不同的值。 -但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 这样的多层应用，还需要区分每一层。前端可以带以下标签： +但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) +这样的多层应用，还需要区分每一层。前端可以带以下标签： ```yaml labels: @@ -368,7 +371,8 @@ and then you can create a new release of the guestbook frontend that carries the -前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本，以便流量可以转发到两个应用： +前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本， +以便流量可以转发到两个应用： ```yaml selector: @@ -380,12 +384,16 @@ The frontend service would span both sets of replicas by selecting the common su You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1). Once you're confident, you can update the stable track to the new application release and remove the canary one. --> -你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收实时生产流量的比例(在本例中为 3:1)。一旦有信心，你就可以将新版本应用的 `track` 标签的值从 `canary` 替换为 `stable`，并且将老版本应用删除。 +你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收 +实时生产流量的比例（在本例中为 3:1）。 +一旦有信心，你就可以将新版本应用的 `track` 标签的值从 +`canary` 替换为 `stable`，并且将老版本应用删除。 -想要了解更具体的示例，请查看 [Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。 +想要了解更具体的示例，请查看 +[Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。 ## 更新注解 {#updating-annotations} -有时，你可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如： +有时，你可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等） +用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如： ```shell kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' @@ -545,12 +554,14 @@ Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-co 建议在源代码管理中维护一组配置文件 （参见[配置即代码](https://martinfowler.com/bliki/InfrastructureAsCode.html)）， 这样，它们就可以和应用代码一样进行维护和版本管理。 -然后，你可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 将配置变更应用到集群中。 +然后，你可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) +将配置变更应用到集群中。 -这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改，但是不会自动覆盖任何你没有指定更改的属性。 +这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改， +但是不会自动覆盖任何你没有指定更改的属性。 ```shell kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml @@ -560,17 +571,24 @@ deployment.apps/my-nginx configured -注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。当调用它时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间找出三方差异，以确定如何修改资源。 +注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。 +执行时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间 +找出三方差异，以确定如何修改资源。 -目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 将使用提供的输入和资源的当前配置双方之间差异进行比较。在第一次调用期间，它无法检测资源创建时属性集的删除情况。因此，不会删除它们。 +目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 时 +将使用提供的输入和资源的当前配置双方之间差异进行比较。 +在第一次调用期间，它无法检测资源创建时属性集的删除情况。 +因此，kubectl 不会删除它们。 -所有后续调用 `kubectl apply` 以及其它修改配置的命令，如 `kubectl replace` 和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply` 使用三方差异进行检查和执行删除。 +所有后续的 `kubectl apply` 操作以及其他修改配置的命令，如 `kubectl replace` +和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply` +使用三方差异进行检查和执行删除。 -这使你可以更加容易地进行更重大的更改。请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。 +这使你可以更加容易地进行更重大的更改。 +请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。 -想要了解更多信息，请参考 [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。 +想要了解更多信息，请参考 +[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。 ### kubectl patch -你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch，JSON merge patch，以及 strategic merge patch。 请参考 -[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/run-application/update-api-object-kubectl-patch/) +你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、 +JSON merge patch、以及 strategic merge patch。 请参考 +[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) 和 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). @@ -636,7 +657,9 @@ In some cases, you may need to update resource fields that cannot be updated onc --> ## 破坏性的更新 {#disruptive-updates} -在某些情况下，你可能需要更新某些初始化后无法更新的资源字段，或者你可能只想立即进行递归更改，例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，它将删除并重新创建资源。在这种情况下，你可以简单地修改原始配置文件： +在某些情况下，你可能需要更新某些初始化后无法更新的资源字段，或者你可能只想立即进行递归更改， +例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`， +它将删除并重新创建资源。在这种情况下，你可以简单地修改原始配置文件： ```shell kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force @@ -655,7 +678,9 @@ deployment.apps/my-nginx replaced -在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，每种更新操作都适用于不同的场景。 +在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签， +如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作， +每种更新操作都适用于不同的场景。 * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) * 查看 [Kubernetes 稳定指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)的列表 -* 阅读有关 [Kubernetes 弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) +* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md index 9721e674cd..2d48a28e24 100644 --- a/content/zh/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh/docs/concepts/extend-kubernetes/_index.md @@ -307,8 +307,8 @@ Kubernetes has several built-in authentication methods that it supports. It can Kubernetes 提供若干内置的身份认证方法。 它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到 某个远程服务（Webhook）来执行验证操作。 -所有这些方法都在[身份认证文档](/docs/reference/access-authn-authz/authentication/) -中详细论述。 +所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/) +中有详细论述。 @@ -32,7 +31,7 @@ The aggregation layer is different from [Custom Resources](/docs/concepts/extend 这类已经成熟的解决方案，也可以是你自己开发的 API。 聚合层不同于 -[自定义资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 能够认识新的对象类别（Kind）。 @@ -91,6 +90,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed 了解如何在自己的环境中启用聚合器。 * 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， 开始使用聚合层。 -* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 * 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范 diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md index 68b52333db..f70f5df34e 100644 --- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md @@ -384,8 +384,8 @@ Different networking fabrics can be supported via node-level [Network Plugins](/ The scheduler is a special type of controller that watches pods, and assigns pods to nodes. The default scheduler can be replaced entirely, while -continuing to use other Kubernetes components, or [multiple -schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) +continuing to use other Kubernetes components, or +[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) can run at the same time. This is a significant undertaking, and almost all Kubernetes users find they @@ -400,7 +400,7 @@ the nodes chosen for a pod. 调度器是一种特殊类型的控制器，用于监视 pod 并将其分配到节点。 默认的调度器可以完全被替换，而继续使用其他 Kubernetes 组件，或者可以同时运行 -[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。 +[多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。 这是一个不太轻松的任务，几乎所有的 Kubernetes 用户都会意识到他们并不需要修改调度器。 @@ -419,7 +419,7 @@ the nodes chosen for a pod. * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) --> -* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) * 详细了解基础设施扩展 * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md index af62e4c767..da6382e4c5 100644 --- a/content/zh/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh/docs/concepts/extend-kubernetes/operator.md @@ -18,13 +18,12 @@ resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/). --> - Operator 是 Kubernetes 的扩展软件，它利用 -[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。 -Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/architecture/controller/) +[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +管理应用及其组件。 +Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh/docs/concepts/architecture/controller/) 方面。 - -* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator * 借助已有的工具来编写你自己的 Operator，例如： * [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator) diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md index d44504680e..bd97b47361 100644 --- a/content/zh/docs/concepts/overview/kubernetes-api.md +++ b/content/zh/docs/concepts/overview/kubernetes-api.md @@ -196,7 +196,7 @@ To make it easier to evolve and to extend its API, Kubernetes implements --> 为了便于演化和扩展其 API，Kubernetes 实现了 可被[启用或禁用](/zh/docs/reference/using-api/#enabling-or-disabling)的 -[API 组](/docs/reference/using-api/#api-groups)。 +[API 组](/zh/docs/reference/using-api/#api-groups)。 更多的示例可参考 -[Pod 安全标准](/docs/concepts/security/pod-security-standards/#policy-instantiation)。 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 -- 参阅[Pod 安全标准](/docs/concepts/security/pod-security-standards/) +- 参阅[Pod 安全标准](zh/docs/concepts/security/pod-security-standards/) 了解策略建议。 - 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。 diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index be1cf5765d..e15aaccc21 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -178,7 +178,8 @@ with prefix `requests.` is allowed for now. Take the GPU resource as an example, if the resource name is `nvidia.com/gpu`, and you want to limit the total number of GPUs requested in a namespace to 4, you can define a quota as follows: --> -以 GPU 拓展资源为例，如果资源名称为 `nvidia.com/gpu`，并且要将命名空间中请求的 GPU 资源总数限制为 4，则可以如下定义配额： +以 GPU 拓展资源为例，如果资源名称为 `nvidia.com/gpu`，并且要将命名空间中请求的 GPU +资源总数限制为 4，则可以如下定义配额： * `requests.nvidia.com/gpu: 4` @@ -196,7 +197,8 @@ In addition, you can limit consumption of storage resources based on associated --> ## 存储资源配额 -用户可以对给定命名空间下的[存储资源](/docs/concepts/storage/persistent-volumes/)总量进行限制。 +用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/) +总量进行限制。 此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。 @@ -219,7 +221,8 @@ In addition, you can limit consumption of storage resources based on associated For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can define a quota as follows: --> -例如，如果一个操作人员针对 `gold` 存储类型与 `bronze` 存储类型设置配额，操作人员可以定义如下配额： +例如，如果一个操作人员针对 `gold` 存储类型与 `bronze` 存储类型设置配额， +操作人员可以定义如下配额： * `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` * `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` @@ -279,7 +282,8 @@ The same syntax can be used for custom resources. For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`. --> 相同语法也可用于自定义资源。 -例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 `count/widgets.example.com`。 +例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 +`count/widgets.example.com`。 例如，`pods` 配额统计某个命名空间中所创建的、非终止状态的 `Pod` 个数并确保其不超过某上限值。 -用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod，从而耗尽集群所能提供的 Pod IP 地址。 +用户可能希望在某命名空间中设置 `pods` 配额，以避免有用户创建很多小的 Pod， +从而耗尽集群所能提供的 Pod IP 地址。 -Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。 +Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。 通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。 -要实现此目的，应使用 kube-apiserver 标志 `--admission-control-config-file` 传递如下配置文件的路径： +要实现此目的，应设置 kube-apiserver 的标志 `--admission-control-config-file` +指向如下配置文件： ```yaml apiVersion: apiserver.config.k8s.io/v1 @@ -938,5 +945,5 @@ For example: - 查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。 - 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。 了解更多信息。 -- 参阅[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) +- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md index 202b798491..c9f656e162 100644 --- a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md @@ -93,7 +93,7 @@ different Kubernetes components. {{< /table >}} --> -### Alpha 和 Beta 的特性门控 +### Alpha 和 Beta 的特性门控 {#feature-gates-for-alpha-or-beta-features} {{< table caption="处于 Alpha 或 Beta 状态的特性门控" >}} @@ -233,7 +233,7 @@ different Kubernetes components. {{< /table >}} --> -### 已毕业和不推荐使用的特性门控 +### 已毕业和不推荐使用的特性门控 {#feature-gates-for-graduated-or-deprecated-features} {{< table caption="已毕业或不推荐使用的特性门控" >}} From b9e8fb699ec8f127e0290ef023690d8f909a2f8a Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 4 Dec 2020 16:05:40 +0800 Subject: [PATCH 24/66] [zh] Fix links in zh localization (3) --- .../access-cluster.md | 335 +++++++++++------- .../configure-access-multiple-clusters.md | 21 +- .../access-cluster-services.md | 14 +- .../change-default-storage-class.md | 7 +- .../change-pv-reclaim-policy.md | 6 +- .../highly-available-master.md | 133 +++---- .../limit-storage-consumption.md | 35 +- .../weave-network-policy.md | 2 +- .../administer-cluster/safely-drain-node.md | 25 +- .../managing-secret-using-config-file.md | 2 +- .../debug-pod-replication-controller.md | 4 +- .../debug-running-pod.md | 6 +- .../logging-elasticsearch-kibana.md | 15 +- .../logging-stackdriver.md | 30 +- .../configure-aggregation-layer.md | 206 +++++++---- .../custom-resource-definitions.md | 2 +- .../setup-extension-api-server.md | 5 +- ...nward-api-volume-expose-pod-information.md | 3 +- .../tasks/manage-daemon/update-daemon-set.md | 4 +- .../tasks/run-application/configure-pdb.md | 2 +- .../horizontal-pod-autoscale-walkthrough.md | 4 +- .../install-service-catalog-using-sc.md | 5 +- 22 files changed, 514 insertions(+), 352 deletions(-) diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md index 7708022f31..626b9f8422 100644 --- a/content/zh/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md @@ -5,11 +5,9 @@ content_type: concept --- @@ -19,8 +17,6 @@ This topic discusses multiple ways to interact with clusters. --> 本文阐述多种与集群交互的方法。 - - {{< toc >}} @@ -40,20 +36,26 @@ Check the location and credentials that kubectl knows about with this command: --> ## 使用 kubectl 完成集群的第一次访问 -当您第一次访问 Kubernetes API 的时候，我们建议您使用 Kubernetes CLI，`kubectl`。 +当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI，`kubectl`。 -访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/zh/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。 +访问集群时，你需要知道集群的地址并且拥有访问的凭证。通常，这些在你通过 +[启动安装](/zh/docs/setup/)安装集群时都是自动安装好的，或者其他人安装时 +也应该提供了凭证和集群地址。 通过以下命令检查 kubectl 是否知道集群地址及凭证： ```shell -$ kubectl config view +kubectl config view ``` +有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl， +可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。 + -有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。 - ## 直接访问 REST API + Kubectl 处理 apiserver 的定位和身份验证。 -如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过多种方式查找和验证： +如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过 +多种方式查找和验证： - - - 以代理模式运行 kubectl。 - - 推荐此方式。 - - 使用已存储的 apiserver 地址。 - - 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。 - - 对 apiserver 进行身份验证。 - - 未来可能会实现智能化的客户端负载均衡和故障恢复。 - - 直接向 http 客户端提供位置和凭据。 - - 可选的方案。 - - 适用于代理可能引起混淆的某些客户端类型。 - - 需要引入根证书到您的浏览器以防止 MITM 攻击。 +- 以代理模式运行 kubectl。 + - 推荐此方式。 + - 使用已存储的 apiserver 地址。 + - 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。 + - 对 apiserver 进行身份验证。 + - 未来可能会实现智能化的客户端负载均衡和故障恢复。 +- 直接向 http 客户端提供位置和凭据。 + - 可选的方案。 + - 适用于代理可能引起混淆的某些客户端类型。 + - 需要引入根证书到你的浏览器以防止 MITM 攻击。 -### 使用 kubectl 代理 +### 使用 kubectl proxy -以下命令以反向代理的模式运行kubectl。它处理 apiserver 的定位和验证。 +以下命令以反向代理的模式运行 kubectl。它处理 apiserver 的定位和验证。 像这样运行： ```shell -$ kubectl proxy --port=8080 & +kubectl proxy --port=8080 & ``` -参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) 获取更多详细信息。 +参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) +获取更多详细信息。 -然后，您可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，如下所示： +然后，你可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost， +如下所示： ```shell -$ curl http://localhost:8080/api/ +curl http://localhost:8080/api/ +``` +```json { "kind": "APIVersions", "versions": [ @@ -131,22 +136,24 @@ $ curl http://localhost:8080/api/ } ``` - -### 不使用 kubectl 代理 +### 不使用 kubectl proxy -在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示： +在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。 +使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示： `grep/cut` 方法实现： ```shell -$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ") -$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ') -$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ") +TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d ' ') +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` +```json { "kind": "APIVersions", "versions": [ @@ -164,9 +171,12 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure `jsonpath` 方法实现： ```shell -$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') -$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode ) -$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') +TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode ) +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +```json { "kind": "APIVersions", "versions": [ @@ -195,9 +205,15 @@ for this. [Configuring Access to the API](/docs/admin/accessing-the-api) describes how a cluster admin can configure this. Such approaches may conflict with future high-availability support. --> -上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器（这些安装在 `~/.kube` 目录中）。由于集群证书通常是自签名的，因此可能需要特殊配置才能让您的 http 客户端使用根证书。 +上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。 +当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器 +（它们安装在 `~/.kube` 目录中）。 +由于集群证书通常是自签名的，因此可能需要特殊配置才能让你的 http 客户端使用根证书。 -在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。 +在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护， +这个没有一定的标准。 +[配置对 API 的访问](/zh/docs/concepts/security/controlling-access/) +描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。 ### Python 客户端 -如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，请运行命令：`pip install kubernetes`。参阅 [Python Client Library page](https://github.com/kubernetes-client/python) 以获得更详细的安装参数。 +如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)， +请运行命令：`pip install kubernetes`。参阅 +[Python Client Library page](https://github.com/kubernetes-client/python) +以获得更详细的安装参数。 -Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples)。 +Python 客户端可以像 kubectl CLI 一样使用相同的 +[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +来定位和验证 apiserver，可参阅 +[示例](https://github.com/kubernetes-client/python/tree/master/examples)。 ### 其它语言 -目前有多个 [客户端库](/zh/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。 +目前有多个[客户端库](/zh/docs/reference/using-api/client-libraries/) +为其它语言提供访问 API 的方法。 参阅其它库的相关文档以获取他们是如何验证的。 +如果可用，则将证书放入每个容器的文件系统中的 +`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`， +并且应该用于验证 apiserver 的服务证书。 +最后，名字空间作用域的 API 操作所使用的 default 名字空间将被放置在 +每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` +文件中。 + + -如果可用，则将证书放入每个容器的文件系统中的 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，并且应该用于验证 apiserver 的服务证书。 +在 Pod 中，建议连接 API 的方法是： -最后，命名空间化的 API 操作所使用的默认命名空间将被放置在每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。 +- 在 Pod 的边车容器中运行 `kubectl proxy`，或者以后台进程的形式运行。 + 这将把 Kubernetes API 代理到当前 Pod 的 localhost 接口， + 所以 Pod 中的所有容器中的进程都能访问它。 +- 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 + `kubernetes.NewForConfig()` 函数创建一个客户端。 + 他们处理 apiserver 的定位和身份验证。 + [示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) -在 pod 中，建议连接 API 的方法是： - - - 在 pod 的 sidecar 容器中运行 `kubectl proxy`，或者以后台进程的形式运行。 - 这将把 Kubernetes API 代理到当前 pod 的 localhost interface，所以 pod 中的所有容器中的进程都能访问它。 - - 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 `kubernetes.NewForConfig()` 函数创建一个客户端。 - 他们处理 apiserver 的定位和身份验证。[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) - -在每种情况下，pod 的凭证都是为了与 apiserver 安全地通信。 +在每种情况下，Pod 的凭证都是为了与 apiserver 安全地通信。 ## 访问集群中正在运行的服务 {#accessing-services-running-on-the-cluster} -上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。 -在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)，[pods](/zh/docs/concepts/workloads/pods/) 和 [服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。 -在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。 +上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes +集群上运行的其他服务。 +在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)、 +[pods](/zh/docs/concepts/workloads/pods/) 和 +[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。 +在许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 将无法路由， +因此无法从集群外部的计算机（例如桌面计算机）访问它们。 +### 连接的方法 {#ways-to-connect} + +有多种方式可以从集群外部连接节点、Pod 和服务： + +- 通过公共 IP 访问服务。 + + - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。 + 请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和 + [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。 + - 取决于你的集群环境，该服务可能仅暴露给你的公司网络，或者也可能暴露给 + 整个互联网。 + 请考虑公开该服务是否安全。它是否进行自己的身份验证？ + - 在服务后端放置 Pod。要从一组副本中访问一个特定的 Pod，例如进行调试， + 请在 Pod 上设置一个唯一的标签，然后创建一个选择此标签的新服务。 + - 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。 + + +- 使用 proxy 动词访问服务、节点或者 Pod。 + - 在访问远程服务之前进行 apiserver 身份验证和授权。 + 如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的 + 访问权限，或者是为了调试，那么请使用此选项。 + - 代理可能会给一些 web 应用带来问题。 + - 只适用于 HTTP/HTTPS。 + - 更多详细信息在[这里](#manually-constructing-apiserver-proxy-urls)。 + + -### 连接的方法 +- 从集群中的节点或者 Pod 中访问。 -有多种方式可以从集群外部连接节点、pod 和服务： - - - 通过公共 IP 访问服务。 - - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。 - 请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。 - - 取决于您的集群环境，该服务可能仅暴露给您的公司网络，或者也可能暴露给整个互联网。 - 请考虑公开该服务是否安全。它是否进行自己的身份验证？ - - 在服务后端放置 pod。要从一组副本中访问一个特定的 pod，例如进行调试，请在 pod 上放置一个唯一的标签，然后创建一个选择此标签的新服务。 - - 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。 - - 使用 Proxy Verb 访问服务、node 或者 pod。 - - 在访问远程服务之前进行 apiserver 身份验证和授权。 - 如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的访问权限，或者是为了 debug，那么请使用此选项。 - - 代理可能会给一些 web 应用带来问题。 - - 只适用于 HTTP/HTTPS。 - - 更多详细信息在 [这里](#manually-constructing-apiserver-proxy-urls)。 - - 从集群中的 node 或者 pod 中访问。 - - 运行一个 pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) 来连接 pod 里的 shell。 - 然后从 shell 中连接其它的节点、pod 和服务。 - - 有些集群可能允许您通过 ssh 连接到 node，从那您可能可以访问集群的服务。 - 这是一个非正式的方式，可能可以运行在个别的集群上。 - 浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。 + - 运行一个 Pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) + 来连接 Pod 里的 Shell。 + 然后从 Shell 中连接其它的节点、Pod 和服务。 + - 有些集群可能允许你通过 SSH 连接到节点，从那你可能可以访问集群的服务。 + 这是一个非正式的方式，可能可以运行在个别的集群上。 + 浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。 这展示了访问每个服务的 proxy-verb URL。 -例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证，那么可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 进行访问。日志也能通过 kubectl 代理获取，例如： +例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证， +那么可以通过 +`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` +进行访问。日志也能通过 kubectl 代理获取，例如： `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。 （参阅 [上面的内容](#accessing-the-cluster-api) 来获取如何使用 kubectl 代理来传递凭证） @@ -434,12 +499,14 @@ The supported formats for the name segment of the URL are: --> #### 手动构建 apiserver 代理 URL {#manually-constructing-apiserver-proxy-urls} -如上所述，您可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL： +如上所述，你可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。 +要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL： `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 如果尚未为端口指定名称，则不必在 URL 中指定 *port_name*。 -默认情况下，API server 使用 http 代理您的服务。要使用 https，请在服务名称前加上 `https:`： +默认情况下，API server 使用 HTTP 代理你的服务。 +要使用 HTTPS，请在服务名称前加上 `https:`： `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` URL 名称段支持的格式为： @@ -457,8 +524,10 @@ URL 名称段支持的格式为： --> ##### 示例 - * 要访问 Elasticsearch 服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy` - * 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true` +* 要访问 Elasticsearch 服务端点 `_search?q=user:kimchy`，你需要使用： + `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy` +* 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，你需要使用： + `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true` ```json { @@ -487,10 +556,12 @@ You may be able to put an apiserver proxy url into the address bar of a browser. --> ### 使用 web 浏览器访问运行在集群上的服务 -您可以在浏览器地址栏中输入 apiserver 代理 URL。但是： +你可以在浏览器地址栏中输入 apiserver 代理 URL。但是： - - Web 浏览器通常不能传递 token，因此您可能需要使用基本（密码）身份验证。Apiserver 可以配置为接受基本身份验证，但您的集群可能未进行配置。 - - 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 以不知道代理路径前缀的方式构建 URL 的应用程序。 +- Web 浏览器通常不能传递令牌，因此你可能需要使用基本（密码）身份验证。 + Apiserver 可以配置为接受基本身份验证，但你的集群可能未进行配置。 +- 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript + 以不知道代理路径前缀的方式构建 URL 的应用程序。 ## 请求重定向 -已弃用并删除了重定向功能。请改用代理（见下文）。 +重定向功能已弃用并被删除。请改用代理（见下文）。 -2. [apiserver 代理](#discovering-builtin-services)： +2. [apiserver 代理](#discovering-builtin-services)： - - 内置于 apiserver 中 - - 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问 - - 运行在 apiserver 进程中 - - 客户端代理使用 HTTPS（也可配置为 http） - - 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标 - - 可用于访问节点、Pod 或服务 - - 在访问服务时进行负载平衡 + - 内置于 apiserver 中 + - 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问 + - 运行在 apiserver 进程中 + - 客户端代理使用 HTTPS（也可配置为 http） + - 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标 + - 可用于访问节点、Pod 或服务 + - 在访问服务时进行负载平衡 -3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)： +3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)： - - 运行在每个节点上 - - 代理 UDP 和 TCP - - 不能代理 HTTP - - 提供负载均衡 - - 只能用来访问服务 + - 运行在每个节点上 + - 代理 UDP 和 TCP + - 不能代理 HTTP + - 提供负载均衡 + - 只能用来访问服务 -4. 位于 apiserver 之前的 Proxy/Load-balancer： +4. 位于 apiserver 之前的 Proxy/Load-balancer： - - 存在和实现因集群而异（例如 nginx） - - 位于所有客户和一个或多个 apiserver 之间 - - 如果有多个 apiserver，则充当负载均衡器 + - 存在和实现因集群而异（例如 nginx） + - 位于所有客户和一个或多个 apiserver 之间 + - 如果有多个 apiserver，则充当负载均衡器 -5. 外部服务上的云负载均衡器： +5. 外部服务上的云负载均衡器： - - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer） - - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建 - - 只使用 UDP/TCP - - 具体实现因云提供商而异。 + - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer） + - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建 + - 只使用 UDP/TCP + - 具体实现因云提供商而异。 + +除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。 +集群管理员通常会确保后者的正确配置。 -除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。集群管理员通常会确保后者的正确配置。 diff --git a/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index f8399bf098..56fde5ff39 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -5,6 +5,7 @@ card: name: tasks weight: 40 --- + +配置文件描述了集群、用户名和上下文。`config-demo` 文件中含有描述两个集群、 +两个用户和三个上下文的框架。 -配置文件描述了集群、用户名和上下文。 `config-demo` 文件中含有描述两个集群、两个用户和三个上下文的框架。 - -进入 `config-exercise` 目录。 输入以下命令，将群集详细信息添加到配置文件中： +进入 `config-exercise` 目录。输入以下命令，将群集详细信息添加到配置文件中： ```shell kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file @@ -149,7 +152,8 @@ kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratc Open your `config-demo` file to see the added details. As an alternative to opening the `config-demo` file, you can use the `config view` command. --> -打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` 命令进行查看： +打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` +命令进行查看： ```shell kubectl config --kubeconfig=config-demo view @@ -369,7 +373,8 @@ For example: --> ## 设置 KUBECONFIG 环境变量 -查看是否有名为 `KUBECONFIG` 的环境变量。 如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。 +查看是否有名为 `KUBECONFIG` 的环境变量。 +如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。 例如： ### Linux @@ -522,11 +527,13 @@ Return your `KUBECONFIG` environment variable to its original value. For example 将 `KUBECONFIG` 环境变量还原为原始值。 例如： ### Linux + ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` ### Windows PowerShell + ```shell $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` diff --git a/content/zh/docs/tasks/administer-cluster/access-cluster-services.md b/content/zh/docs/tasks/administer-cluster/access-cluster-services.md index 32912771ab..ee817c141f 100644 --- a/content/zh/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/zh/docs/tasks/administer-cluster/access-cluster-services.md @@ -26,10 +26,9 @@ such as your desktop machine. --> ## 访问集群上运行的服务 - -在 Kubernetes 里，[Node](/zh/docs/concepts/architecture/nodes/)、 +在 Kubernetes 里，[节点](/zh/docs/concepts/architecture/nodes/)、 [Pod](/zh/docs/concepts/workloads/pods/) 和 -[Service](/zh/docs/concepts/services-networking/services/) 都有自己的 IP。 +[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。 许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 是路由不可达的， 所以不能从集群之外访问它们，例如从你自己的台式机。 @@ -57,7 +56,7 @@ You have several options for connecting to nodes, pods and services from outside --> - 通过公网 IP 访问服务 - 使用类型为 `NodePort` 或 `LoadBalancer` 的服务，可以从外部访问它们。 - 请查阅[服务](/zh/docs/concepts/services-networking/services/) 和 + 请查阅[服务](/zh/docs/concepts/services-networking/service/) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。 - 取决于你的集群环境，你可以仅把服务暴露在你的企业网络环境中，也可以将其暴露在 因特网上。需要考虑暴露的服务是否安全，它是否有自己的用户认证？ @@ -134,13 +133,16 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l --> 这一输出显示了用 proxy 动词访问每个服务时可用的 URL。例如，此集群 （使用 Elasticsearch）启用了集群层面的日志。如果提供合适的凭据，可以通过 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 访问，或通过一个 `kubectl proxy` 来访问：`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。 +`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` +访问，或通过一个 `kubectl proxy` 来访问： +`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。 {{< note >}} -请参阅[使用 Kubernets API 访问集群](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)了解如何传递凭据或如何使用 `kubectl proxy`。 +请参阅[使用 Kubernets API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) +了解如何传递凭据或如何使用 `kubectl proxy`。 {{< /note >}} 输出类似这样： - ```bash + ``` NAME PROVISIONER AGE standard kubernetes.io/gce-pd 1d gold (default) kubernetes.io/gce-pd 1d @@ -149,5 +150,5 @@ for details about addon manager and how to disable individual addons. -* 进一步了解 [StorageClasses](/docs/concepts/storage/persistent-volumes/) +* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) diff --git a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index d02b8d2435..1499ecfc1b 100644 --- a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -2,7 +2,9 @@ title: 更改 PersistentVolume 的回收策略 content_type: task --- + + -* 进一步了解 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) -* 进一步了解 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) +* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) +* 进一步了解 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) ### 参考 diff --git a/content/zh/docs/tasks/administer-cluster/highly-available-master.md b/content/zh/docs/tasks/administer-cluster/highly-available-master.md index 2c8e9f2dc6..be4797477d 100644 --- a/content/zh/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/zh/docs/tasks/administer-cluster/highly-available-master.md @@ -1,53 +1,40 @@ --- -reviewers: -- jszczepkowski -translaters: -- Coffey Gao title: 搭建高可用的 Kubernetes Masters content_type: task --- - {{< feature-state for_k8s_version="1.5" state="alpha" >}} + - -您可以在谷歌计算引擎（GCE）的 `kubeup` 或 `kube-down` 脚本中复制 Kubernetes Master。 -本文描述了如何使用 kube-up/down 脚本来管理高可用（HA）的 Master，以及如何使用 GCE 实现高可用 Master。 - - - +你可以在谷歌计算引擎（GCE）的 `kubeup` 或 `kube-down` 脚本中复制 Kubernetes Master。 +本文描述了如何使用 kube-up/down 脚本来管理高可用（HA）的 Master， +以及如何使用 GCE 实现高可用控制节点。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - ## 启动一个兼容高可用的集群 -要创建一个新的兼容高可用的集群，您必须在 `kubeup` 脚本中设置以下标志: +要创建一个新的兼容高可用的集群，你必须在 `kubeup` 脚本中设置以下标志: -* `MULTIZONE=true` - 为了防止从不同于 Master 默认区域的区域中删除 kubelets 副本。如果您希望在不同的区域运行 Master 副本，那么这一项是必需并且推荐的。 +* `MULTIZONE=true` - 为了防止从不同于服务器的默认区域的区域中删除 kubelets 副本。 + 如果你希望在不同的区域运行副本，那么这一项是必需并且推荐的。 -* `ENABLE_ETCD_QUORUM_READ=true` - 确保从所有 API 服务器读取数据时将返回最新的数据。如果为 true，读操作将被定向到 leader etcd 副本。可以选择将这个值设置为 true，那么读取将更可靠，但也会更慢。 +* `ENABLE_ETCD_QUORUM_READ=true` - 确保从所有 API 服务器读取数据时将返回最新的数据。 + 如果为 true，读操作将被定向到主 etcd 副本。可以选择将这个值设置为 true， + 那么读取将更可靠，但也会更慢。 -您还可以指定一个 GCE 区域，在这里创建第一个 Master 副本。设置以下标志: +你还可以指定一个 GCE 区域，在这里创建第一个主节点副本。设置以下标志: -* `KUBE_GCE_ZONE=zone` - 将运行第一个 Master 副本的区域。 +* `KUBE_GCE_ZONE=zone` - 将运行第一个主节点副本的区域。 下面的命令演示在 GCE europe-west1-b 区域中设置一个兼容高可用的集群: @@ -85,8 +75,8 @@ however, you can add new master replicas to the cluster with subsequent commands MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh ``` -注意，上面的命令创建一个只有单一 Master 的集群; -但是，您可以使用后续命令将新的 Master 副本添加到集群中。 +注意，上面的命令创建一个只有单一主节点的集群; +但是，你可以使用后续命令将新的主节点副本添加到集群中。 +## 增加一个新的主节点副本 -## 增加一个新的 Master 副本 +在创建了兼容高可用的集群之后，可以向其中添加主节点副本。 +你可以使用带有如下标记的 `kubeup` 脚本添加主节点副本: -在创建了兼容高可用的集群之后，可以向其中添加 Master 副本。 -您可以使用带有如下标记的 `kubeup` 脚本添加 Master 副本: +* `KUBE_REPLICATE_EXISTING_MASTER=true` - 创建一个已经存在的主节点的副本。 -* `KUBE_REPLICATE_EXISTING_MASTER=true` - 创建一个已经存在的 Master 的副本。 +* `KUBE_GCE_ZONE=zone` -主节点副本将运行的区域。必须与其他副本位于同一区域。 -* `KUBE_GCE_ZONE=zone` - Master 副本将运行的区域。必须与其他副本位于同一区域。 - -您无需设置 `MULTIZONE` 或 `ENABLE_ETCD_QUORUM_READS` 标志，因为他们可以从兼容高可用的集群中继承。 +你无需设置 `MULTIZONE` 或 `ENABLE_ETCD_QUORUM_READS` 标志，因为他们可以从兼容高可用的集群中继承。 使用下面的命令可以复制现有兼容高可用的集群上的 Master: @@ -144,16 +133,15 @@ The following sample command removes a master replica from an existing HA cluste KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh ``` --> +## 删除主节点副本 -## 删除一个 Master 副本 - -你可以使用一个 `kube-down` 脚本从高可用集群中删除一个 Master 副本，并可以使用以下标记: +你可以使用一个 `kube-down` 脚本从高可用集群中删除一个主节点副本，并可以使用以下标记: * `KUBE_DELETE_NODES=false` - 限制删除 kubelets。 -* `KUBE_GCE_ZONE=zone` - 将移除 Master 副本的区域。 +* `KUBE_GCE_ZONE=zone` - 将移除主节点副本的区域。 -* `KUBE_REPLICA_NAME=replica_name` - （可选）要删除的 Master 副本的名称。 +* `KUBE_REPLICA_NAME=replica_name` - （可选）要删除的主节点副本的名称。 如果为空：将删除给定区域中的所有副本。 使用下面的命令可以从一个现有的高可用集群中删除一个 Master副本: @@ -180,10 +168,10 @@ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_nam KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` --> +## 处理主节点副本失败 -## 处理 Master 副本失败 - -如果高可用集群中的一个 Master 副本失败，最佳实践是从集群中删除副本，并在相同的区域中添加一个新副本。 +如果高可用集群中的一个主节点副本失败，最佳实践是从集群中删除副本， +并在相同的区域中添加一个新副本。 下面的命令演示了这个过程: 1. 删除失败的副本: @@ -214,19 +202,22 @@ This operation may be sped up by migrating etcd data directory, as described [he (we are considering adding support for etcd data dir migration in future). --> -## 高可用集群复制 Master 的最佳实践 - -* 尝试将 Master 副本放置在不同的区域。在某区域故障时，放置在该区域内的所有主机都将失败。 -为了在区域故障中幸免，请同样将工作节点放置在多区域中（详情请见[多区域](/docs/setup/best-practices/multiple-zones/)）。 - -* 不要使用具有两个 Master 副本的集群。在双副本集群上达成一致需要在更改持久状态时两个副本都处于运行状态。因此，两个副本都是需要的，任一副本的失败都会将集群带入多数失败状态。因此，就高可用而言，双副本集群不如单个副本集群。 - -* 添加 Master 副本时，集群状态（etcd）会被复制到一个新实例。如果集群很大，可能需要很长时间才能复制它的状态。 -这个操作可以通过迁移 etcd 数据存储来加速, 详情参见 [这里](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) -（我们正在考虑在未来添加对迁移 etcd 数据存储的支持）。 +## 高可用集群复制主节点的最佳实践 +* 尝试将主节点副本放置在不同的区域。在某区域故障时，放置在该区域内的所有主机都将失败。 + 为了在区域故障中幸免，请同样将工作节点放置在多区域中 + （详情请见[多区域](/zh/docs/setup/best-practices/multiple-zones/)）。 +* 不要使用具有两个主节点副本的集群。在双副本集群上达成一致需要在更改持久状态时 + 两个副本都处于运行状态。 + 因此，两个副本都是需要的，任一副本的失败都会将集群带入多数失败状态。 + 因此，就高可用而言，双副本集群不如单个副本集群。 +* 添加主节点副本时，集群状态（etcd）会被复制到一个新实例。如果集群很大， + 可能需要很长时间才能复制它的状态。 + 这个操作可以通过迁移 etcd 数据存储来加速, 详情参见 + [这里](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) + （我们正在考虑在未来添加对迁移 etcd 数据存储的支持）。 - -## 实施注意事项 +## 实现说明 ![ha-master-gce](/images/docs/ha-master-gce.png) @@ -254,10 +244,9 @@ Each of master replicas will run the following components in the following mode: In addition, there will be a load balancer in front of API servers that will route external and internal traffic to them. --> - ### 概述 -每个 Master 副本将以以下模式运行以下组件: +每个主节点副本将以以下模式运行以下组件: * etcd 实例： 所有实例将会以共识方式组建集群； @@ -265,7 +254,7 @@ In addition, there will be a load balancer in front of API servers that will rou * 控制器、调度器和集群自动扩缩器：将使用租约机制 —— 每个集群中只有一个实例是可用的； -* add-on manager：每个管理器将独立工作，试图保持插件同步。 +* 插件管理器：每个管理器将独立工作，试图保持插件同步。 此外，在 API 服务器前面将有一个负载均衡器，用于将外部和内部通信路由到他们。 @@ -277,15 +266,16 @@ and the IP address of the first replica will be promoted to IP address of load b Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica. Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate. --> +### 负载均衡 -### 负载均衡器 - -启动第二个 Master 副本时，将创建一个包含两个副本的负载均衡器，并将第一个副本的 IP 地址提升为负载均衡器的 IP 地址。 -类似地，在删除倒数第二个 Master 副本之后，将删除负载均衡器，并将其 IP 地址分配给最后一个剩余的副本。 +启动第二个主节点副本时，将创建一个包含两个副本的负载均衡器， +并将第一个副本的 IP 地址提升为负载均衡器的 IP 地址。 +类似地，在删除倒数第二个主节点副本之后，将删除负载均衡器， +并将其 IP 地址分配给最后一个剩余的副本。 请注意，创建和删除负载均衡器是复杂的操作，可能需要一些时间（约20分钟）来同步。 +### 主节点服务 & kubelets -### Master 服务 & kubelets +Kubernetes 并不试图在其服务中保持 apiserver 的列表为最新， +相反，它将将所有访问请求指向外部 IP： -Kubernetes 并不试图在其服务中保持 apiserver 的列表为最新，相反，它将将所有访问请求指向外部 IP： +* 在拥有一个主节点的集群中，IP 指向单一的主节点， +* 在拥有多个主节点的集群中，IP 指向主节点前面的负载均衡器。 -* 在拥有一个 Master 的集群中，IP 指向单一的 Master， - -* 在拥有多个 Master 的集群中，IP 指向 Master 前面的负载均衡器。 - -类似地，kubelets 将使用外部 IP 与 Master 通信。 +类似地，kubelets 将使用外部 IP 与主节点通信。 +### 主节点证书 -### Master 证书 - -Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成 Master TLS 证书。 +Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成主节点 TLS 证书。 副本的临时公共 IP 没有证书； -要通过其临时公共 IP 访问副本，必须跳过TLS验证。 +要通过其临时公共 IP 访问副本，必须跳过 TLS 检查。 - ### etcd 集群 为了允许 etcd 组建集群，需开放 etcd 实例之间通信所需的端口（用于集群内部通信）。 @@ -338,9 +325,7 @@ To make such deployment secure, communication between etcd instances is authoriz [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) --> - ## 拓展阅读 [自动化高可用集群部署 - 设计文档](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) - diff --git a/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md b/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md index b3969099a1..3769538c67 100644 --- a/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md +++ b/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md @@ -12,7 +12,7 @@ content_type: task -此示例演示了一种限制命名空间中存储使用量的简便方法。 +此示例演示了一种限制名字空间中存储使用量的简便方法。 演示中用到了以下资源：[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)， [LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和 -[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。 - +[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/)。 ## {{% heading "prerequisites" %}} @@ -51,9 +50,9 @@ The admin would like to limit: 2. The amount of storage each claim can request 3. The amount of cumulative storage the namespace can have --> -1. 命名空间中持久卷申领（persistent volume claims）的数量 +1. 名字空间中持久卷申领（persistent volume claims）的数量 2. 每个申领（claim）可以请求的存储量 -3. 命名空间可以具有的累计存储量 +3. 名字空间可以具有的累计存储量 -将 `LimitRange` 添加到命名空间会为存储请求大小强制设置最小值和最大值。存储是通过 `PersistentVolumeClaim` 来发起请求的。执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。 +将 `LimitRange` 添加到名字空间会为存储请求大小强制设置最小值和最大值。 +存储是通过 `PersistentVolumeClaim` 来发起请求的。 +执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。 -当底层存储提供程序需要某些最小值时，将会用到所设置最小存储请求值。例如，AWS EBS volumes 的最低要求为 1Gi。 +当底层存储提供程序需要某些最小值时，将会用到所设置最小存储请求值。 +例如，AWS EBS volumes 的最低要求为 1Gi。 -管理员可以限制某个命名空间中的 PVCs 个数以及这些 PVCs 的累计容量。新 PVCs 请求如果超过任一上限值将被拒绝。 +管理员可以限制某个名字空间中的 PVCs 个数以及这些 PVCs 的累计容量。 +新 PVCs 请求如果超过任一上限值将被拒绝。 -在此示例中，命名空间中的第 6 个 PVC 将被拒绝，因为它超过了最大计数 5。或者，当与上面的 2Gi 最大容量限制结合在一起时，意味着 5Gi 的最大配额不能支持 3 个都是 2Gi 的 PVC。后者实际上是向命名空间请求 6Gi 容量，而该命令空间已经设置上限为 5Gi。 +在此示例中，名字空间中的第 6 个 PVC 将被拒绝，因为它超过了最大计数 5。 +或者，当与上面的 2Gi 最大容量限制结合在一起时，意味着 5Gi 的最大配额 +不能支持 3 个都是 2Gi 的 PVC。 +后者实际上是向名字空间请求 6Gi 容量，而该命令空间已经设置上限为 5Gi。 ``` apiVersion: v1 @@ -119,18 +125,17 @@ spec: requests.storage: "5Gi" ``` - - -## 小结 - -限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和累计存储容量有效地限制命名空间耗用的存储量。这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。 +## 小结 + +限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和 +累计存储容量有效地限制名字空间耗用的存储量。 +这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。 diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 02339cbc61..c1d08c31c8 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -92,7 +92,7 @@ Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` me Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help). --> 安装 Weave Net 插件后，你可以参考 -[声明网络策略](/zh/docs/tasks/administration-cluster/declare-network-policy/) +[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来试用 Kubernetes NetworkPolicy。 如果你有任何疑问，请通过 [Slack 上的 #weave-community 频道或者 Weave 用户组](https://github.com/weaveworks/weave#getting-help) diff --git a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md index 77bdc299fa..e4a93e99e5 100644 --- a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md @@ -16,11 +16,13 @@ content_type: task -本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个{{< glossary_tooltip text="节点" term_id="node" >}}。 +本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个 +{{< glossary_tooltip text="节点" term_id="node" >}}。 ## {{% heading "prerequisites" %}} {{% version-check %}} + @@ -144,7 +147,8 @@ replicas to fall below the specified budget are blocked. 并设置了一个 `PodDisruptionBudget`，指定 `minAvailable: 2`。 如果所有的三个 Pod 均就绪，并且你并行地发出多个 drain 命令， 那么 `kubectl drain` 只会从 StatefulSet 中逐出一个 Pod， -因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。 +因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用 +（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。 任何会导致就绪副本数量低于指定预算的清空操作都将被阻止。 ## 驱逐 API {#the-eviction-api} 如果你不喜欢使用 -[kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain) +[kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程）， 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。 @@ -172,7 +176,8 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。 Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。 -要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子： +要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST +发出所尝试的操作。这里有一个例子： ```json { @@ -254,7 +259,8 @@ application owners and cluster owners to establish an agreement on behavior in t ## 驱逐阻塞 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。 -例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。 +例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 +Pod 有很长的终止宽限期，就会发生这种情况。 在这种情况下，有两种可能的解决方案： @@ -266,12 +272,9 @@ Kubernetes 并没有具体说明在这种情况下应该采取什么行为， ## {{% heading "whatsnext" %}} - -* 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。 -* 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。 - +* 执行[配置 PDB](/zh/docs/tasks/run-application/configure-pdb/)中的各个步骤， + 保护你的应用 diff --git a/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md index 1c140cee4c..d020badb3e 100644 --- a/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md +++ b/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -150,7 +150,7 @@ stringData: ## 创建 Secret 对象 {#create-the-secret-object} -现在使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret： +现在使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret： ```shell kubectl apply -f ./secret.yaml diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 4610d254e5..195dabb43a 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -23,9 +23,9 @@ This page shows how to debug Pods and ReplicationControllers. -* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/pod/) 和 +* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/) 和 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。 diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md index 358ee111c3..32fe8d87c7 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -20,7 +20,8 @@ This page explains how to debug Pods running (or crashing) on a Node. need that access to run the standard debug steps that use `kubectl`. --> * 你的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 应该已经被调度并正在运行中， -如果你的 Pod 还没有运行，请参阅[应用问题排查](/docs/tasks/debug-application-cluster/debug-application/)。 + 如果你的 Pod 还没有运行，请参阅 + [应用问题排查](/zh/docs/tasks/debug-application-cluster/debug-application/)。 * 对于一些高级调试步骤，你应该知道 Pod 具体运行在哪个节点上，在该节点上有权限去运行一些命令。 你不需要任何访问权限就可以使用 `kubectl` 去运行一些标准调试步骤。 @@ -147,7 +148,8 @@ images. ## 使用临时容器来调试的例子 {#ephemeral-container-example} {{< note >}} -本示例需要你的集群已经开启 `EphemeralContainers` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +本示例需要你的集群已经开启 `EphemeralContainers` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， `kubectl` 版本为 v1.18 或者更高。 {{< /note >}} diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md index a667fa7f1b..2dbabad039 100644 --- a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md +++ b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md @@ -20,7 +20,7 @@ in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver). --> 在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是 [Stackdriver Logging](https://cloud.google.com/logging/)， -在[使用 Stackdriver Logging 管理日志](/docs/tasks/debug-application-cluster/logging-stackdriver/) +在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/) 中详细描述了这一点。 -要使用 Elasticsearch 和 Kibana 处理集群日志，你应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量： +要使用 Elasticsearch 和 Kibana 处理集群日志，你应该在使用 kube-up.sh +脚本创建集群时设置下面所示的环境变量： ```shell KUBE_LOGGING_DESTINATION=elasticsearch @@ -96,7 +97,7 @@ all be running in the kube-system namespace soon after the cluster comes to life. --> 每个节点的 Fluentd Pod、Elasticsearch Pod 和 Kibana Pod 都应该在集群启动后不久运行在 -kube-system 命名空间中。 +kube-system 名字空间中。 ```shell kubectl get pods --namespace=kube-system @@ -137,8 +138,8 @@ and are not directly exposed via a publicly reachable IP address. To reach them, follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster). --> -Elasticsearch 和 Kibana 服务都位于 `kube-system` 命名空间中，并且没有通过可公开访问的 IP 地址直接暴露。 -要访问它们，请参照 +Elasticsearch 和 Kibana 服务都位于 `kube-system` 名字空间中，并且没有通过 +可公开访问的 IP 地址直接暴露。要访问它们，请参照 [访问集群中运行的服务](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster) 的说明进行操作。 @@ -156,7 +157,8 @@ like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasti for more details on how to do so. --> 现在你可以直接在浏览器中输入 Elasticsearch 查询，如果你愿意的话。 -请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。 +请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) +以了解这样做的更多细节。 Kibana 为浏览你的日志提供了各种强大的选项！有关如何深入研究它的一些想法， 请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。 + diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md index 0623406b08..fbc87d25f1 100644 --- a/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ b/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -367,7 +367,8 @@ log names: -你可以在[专用 Stackdriver 页面](https://cloud.google.com/logging/docs/view/overview)上了解有关查看日志的更多信息。 +你可以在[Stackdriver 专用页面](https://cloud.google.com/logging/docs/view/overview) +上了解有关查看日志的更多信息。 -查看日志的一种可能方法是使用 [Google Cloud SDK]((https://cloud.google.com/sdk/)) 中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) 命令行接口。 -它使用 Stackdriver 日志机制的[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。 +查看日志的一种可能方法是使用 [Google Cloud SDK](https://cloud.google.com/sdk/) +中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) +命令行接口。 +它使用 Stackdriver 日志机制的 +[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。 例如，你可以运行以下命令： ```none @@ -399,7 +403,8 @@ As you can see, it outputs messages for the count container from both the first and second runs, despite the fact that the kubelet already deleted the logs for the first container. --> -如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter 容器第一次和第二次运行时输出的消息。 +如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter +容器第一次和第二次运行时输出的消息。 -如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，因为它是由 GKE 管理和支持的。 +如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置， +因为它是由 GKE 管理和支持的。 但是，你可以禁用默认集成的日志机制并部署自己的。 - {{< note >}} 你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。 {{< /note >}} @@ -478,7 +484,8 @@ gcloud beta container clusters update --logging-service=none CLUSTER You can find notes on how to then install Stackdriver Logging agents into a running cluster in the [Deploying section](#deploying). --> -你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到正在运行的集群中的说明​​。 +你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到 +正在运行的集群中的说明。 -当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 `template` 字段，daemonset 控制器将为你更新 pod。 +当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 +`template` 字段，daemonset 控制器将为你更新 Pod。 例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。 现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。 @@ -616,4 +624,6 @@ Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plug Then run `make build push` from this directory. After updating `DaemonSet` to pick up the new image, you can use the plugin you installed in the fluentd configuration. --> -然后在该目录运行 `make build push`。在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。 +然后在该目录运行 `make build push`。 +在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。 + diff --git a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md index 0db27194c6..6203bd5bee 100644 --- a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md +++ b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md @@ -18,8 +18,9 @@ weight: 10 -配置 [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 允许 -Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。 +配置[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +可以允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 +Kubernetes API 的一部分。 ## {{% heading "prerequisites" %}} @@ -29,7 +30,7 @@ Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernete There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. --> {{< note >}} -要使聚合层在您的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证， +要使聚合层在你的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证， 需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA， 因此请确保代理是由聚合层 CA 签名的，而不是由主 CA 签名的。 {{< /note >}} @@ -38,8 +39,8 @@ There are a few setup requirements for getting the aggregation layer working in Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts). --> {{< caution >}} -对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。有关更多信息，请参见 -[CA 重用和冲突](#ca-reusage-and-conflicts)。 +对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。 +有关更多信息，请参见 [CA 重用和冲突](#ca-reusage-and-conflicts)。 {{< /caution >}} @@ -53,7 +54,11 @@ This section describes how the authentication and authorization flows work, and --> ## 身份认证流程 -与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API 还涉及另一个服务器：扩展 apiserver。Kubernetes apiserver 将需要与您的扩展 apiserver 通信，并且您的扩展 apiserver 也需要与 Kubernetes apiserver 通信。为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。 +与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API +还涉及另一个服务器：扩展 apiserver。 +Kubernetes apiserver 将需要与你的扩展 apiserver 通信，并且你的扩展 apiserver +也需要与 Kubernetes apiserver 通信。 +为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。 本节介绍身份认证和鉴权流程的工作方式以及如何配置它们。 @@ -65,14 +70,6 @@ The high-level flow is as follows: 3. Extension apiserver: authenticate the request from the Kubernetes apiserver 4. Extension apiserver: authorize the request from the original user 5. Extension apiserver: execute - -The rest of this section describes these steps in detail. - -The flow can be seen in the following diagram. - -![aggregation auth flows](/images/docs/aggregation-api-auth-flow.png). - -The source for the above swimlanes can be found in the source of this document. --> 大致流程如下： @@ -82,11 +79,18 @@ The source for the above swimlanes can be found in the source of this document. 4. 扩展 apiserver：对来自原始用户的请求鉴权 5. 扩展 apiserver：执行 + 本节的其余部分详细描述了这些步骤。 该流程可以在下图中看到。 -![aggregation auth flows](/images/docs/aggregation-api-auth-flow.png). +![聚合层认证流程](/images/docs/aggregation-api-auth-flow.png). 以上泳道的来源可以在本文档的源码中找到。 @@ -167,9 +171,11 @@ note: kube-apiserver / aggregator -> 聚合的 apiserver: note: -4.aggregator 使用`--proxy-client-cert-file`，`--proxy-client-key-file`客户端证书/密钥打开与聚合 Apiserver 的连接以保护通道 +4.aggregator 使用 `--proxy-client-cert-file`，`--proxy-client-key-file` + 客户端证书/密钥打开与聚合 Apiserver 的连接以保护通道 -5.aggregator 将步骤 1 中的用户信息作为 http 标头发送到聚合的 Apiserver，如以下标志所定义： +5.aggregator 将步骤 1 中的用户信息作为 http 标头发送到聚合的 Apiserver， + 如以下标志所定义： * `--requestheader-username-headers` * `--requestheader-group-headers` @@ -183,7 +189,10 @@ note: * 验证请求是否具有公认的身份验证代理客户端证书 * 从传入请求的 HTTP 标头中提取用户信息 -默认情况下，它从 kube-apiserver 发布的 kube-system 命名空间中的 configmap 中获取配置信息，其中包含提供给 kube-apiserver 的`--requestheader-...`标志中的信息（要使用的 CA 包，要允许的身份验证代理客户端证书名称，要使用的 HTTP 标头名称等） +默认情况下，它从 kube-apiserver 发布的 kube-system 命名空间中的 configmap +中获取配置信息，其中包含提供给 kube-apiserver 的`--requestheader-...` +标志中的信息（要使用的 CA 包，要允许的身份验证代理客户端证书名称， +要使用的 HTTP 标头名称等） kube-apiserver / aggregator -> 聚合的 apiserver: 鉴权 @@ -193,7 +202,9 @@ note: kube-apiserver / aggregator -> 聚合的 apiserver: 准入 note: -8.对于可变请求，聚合的 apiserver 运行准入检查。默认情况下，namespace 生命周期准入插件可确保在 kube-apiserver 中存在的 namespace 中创建指定 namespace 下的资源 +8.对于可变请求，聚合的 apiserver 运行准入检查。 + 默认情况下，namespace 生命周期准入插件可确保在 kube-apiserver + 中存在的 namespace 中创建指定 namespace 下的资源 -----END----- --> @@ -213,11 +224,17 @@ The Kubernetes apiserver now is prepared to send the request to the extension ap --> ### Kubernetes Apiserver 认证和授权 -由扩展 apiserver 服务的对 API 路径的请求以与所有API请求相同的方式开始：与 Kubernetes apiserver 的通信。该路径已通过扩展 apiserver 在 Kubernetes apiserver 中注册。 +由扩展 apiserver 服务的对 API 路径的请求以与所有 API 请求相同的方式开始： +与 Kubernetes apiserver 的通信。该路径已通过扩展 apiserver 在 +Kubernetes apiserver 中注册。 -用户与 Kubernetes apiserver 通信，请求访问 path 。Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定 path 的鉴权。 +用户与 Kubernetes apiserver 通信，请求访问路径。 +Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定路径的鉴权。 -有关对 Kubernetes 集群认证的概述，请参见 [对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。有关对Kubernetes群集资源的访问鉴权的概述，请参见 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。 +有关对 Kubernetes 集群认证的概述，请参见 +[对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。 +有关对Kubernetes群集资源的访问鉴权的概述，请参见 +[鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。 到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。 @@ -235,13 +252,16 @@ In order to provide for these two, you must configure the Kubernetes apiserver u --> ### Kubernetes Apiserver 代理请求 -Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的扩展 apiserver。为此，它需要了解几件事： +Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的扩展 apiserver。 +为此，它需要了解几件事： -1. Kubernetes apiserver 应该如何向扩展 apiserver 认证，以通知扩展 apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？ +1. Kubernetes apiserver 应该如何向扩展 apiserver 认证，以通知扩展 + apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？ -2. Kubernetes apiserver 应该如何通知扩展 apiserver 原始请求已通过认证的用户名和组？ +2. Kubernetes apiserver 应该如何通知扩展 apiserver 原始请求 + 已通过认证的用户名和组？ -为提供这两条信息，您必须使用若干标志来配置 Kubernetes apiserver。 +为提供这两条信息，你必须使用若干标志来配置 Kubernetes apiserver。 #### Kubernetes Apiserver 客户端认证 -Kubernetes apiserver 通过 TLS 连接到扩展 apiserver，并使用客户端证书认证。您必须在启动时使用提供的标志向 Kubernetes apiserver 提供以下内容： +Kubernetes apiserver 通过 TLS 连接到扩展 apiserver，并使用客户端证书认证。 +你必须在启动时使用提供的标志向 Kubernetes apiserver 提供以下内容： * 通过 `--proxy-client-key-file` 指定私钥文件 * 通过 `--proxy-client-cert-file` 签名的客户端证书文件 @@ -268,13 +289,15 @@ The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` 1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`. 2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable. --> -Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来验证扩展 apiserver。为了使合规的扩展 apiserver 能够将该请求视为有效，必须满足以下条件： +Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来验证扩展 apiserver。 +为了使合规的扩展 apiserver 能够将该请求视为有效，必须满足以下条件： 1. 连接必须使用由 CA 签署的客户端证书，该证书的证书位于 `--requestheader-client-ca-file` 中。 2. 连接必须使用客户端证书，该客户端证书的 CN 是 `--requestheader-allowed-names` 中列出的证书之一。 {{< note >}} -您可以将此选项设置为空白，即为`--requestheader-allowed-names`。这将向扩展 apiserver 指示任何 CN 是可接受的。 +你可以将此选项设置为空白，即为`--requestheader-allowed-names`。 +这将向扩展 apiserver 指示任何 CN 是可接受的。 {{< /note >}} - #### 原始请求用户名和组 -当 Kubernetes apiserver 将请求代理到扩展 apiserver 时，它将向扩展 apiserver 通知原始请求已成功通过其验证的用户名和组。它在其代理请求的 http 标头中提供这些。您必须将要使用的标头名称告知 Kubernetes apiserver。 +当 Kubernetes apiserver 将请求代理到扩展 apiserver 时， +它将向扩展 apiserver 通知原始请求已成功通过其验证的用户名和组。 +它在其代理请求的 HTTP 头部中提供这些。你必须将要使用的标头名称告知 +Kubernetes apiserver。 * 通过`--requestheader-username-headers` 标明用来保存用户名的头部 * 通过`--requestheader-group-headers` 标明用来保存 group 的头部 * 通过`--requestheader-extra-headers-prefix` 标明用来保存拓展信息前缀的头部 -这些标头名称也放置在`extension-apiserver-authentication` 的 configmap 中，因此扩展 apiserver 可以检索和使用它们。 +这些头部名称也放置在 `extension-apiserver-authentication` ConfigMap 中， +因此扩展 apiserver 可以检索和使用它们。 ### 扩展 Apiserver 认证 -扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后，必须验证该请求确实确实来自有效的身份验证代理，该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证： +扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后， +必须验证该请求确实确实来自有效的身份验证代理， +该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证： -1.如上所述，从`kube-system`中的 configmap 中检索以下内容： - * 客户端 CA 证书 - * 允许名称（CN）列表 - * 用户名，组和其他信息的头部 +1. 如上所述，从`kube-system`中的 configmap 中检索以下内容： -2.使用以下证书检查 TLS 连接是否已通过认证： - * 由其证书与检索到的 CA 证书匹配的 CA 签名。 - * 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。 - * 从适当的头部中提取用户名和组 + * 客户端 CA 证书 + * 允许名称（CN）列表 + * 用户名，组和其他信息的头部 + +2. 使用以下证书检查 TLS 连接是否已通过认证： + + * 由其证书与检索到的 CA 证书匹配的 CA 签名。 + * 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。 + * 从适当的头部中提取用户名和组 -如果以上均通过，则该请求是来自合法认证代理（在本例中为 Kubernetes apiserver）的有效代理请求。 +如果以上均通过，则该请求是来自合法认证代理（在本例中为 Kubernetes apiserver） +的有效代理请求。 -请注意，扩展 apiserver 实现负责提供上述内容。默认情况下，许多扩展 apiserver 实现利用 `k8s.io/apiserver/` 软件包来做到这一点。也有一些实现可能支持使用命令行选项来覆盖这些配置。 +请注意，扩展 apiserver 实现负责提供上述内容。 +默认情况下，许多扩展 apiserver 实现利用 `k8s.io/apiserver/` 软件包来做到这一点。 +也有一些实现可能支持使用命令行选项来覆盖这些配置。 -为了具有检索 configmap 的权限，扩展 apiserver 需要适当的角色。在 `kube-system` 名字空间中有一个默认角色`extension-apiserver-authentication-reader` 可用于设置。 +为了具有检索 configmap 的权限，扩展 apiserver 需要适当的角色。 +在 `kube-system` 名字空间中有一个默认角色 +`extension-apiserver-authentication-reader` 可用于设置。 这些功能中的每个功能都是独立的；如果使用不正确，可能彼此冲突。 -* `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项，则 Kubernetes apiserver 会检查请求的证书。如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的，并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。请参阅 [关于 TLS 身份验证的文档](/docs/reference/access-authn-authz/authentication/#x509-client-certs)。 +* `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项， + 则 Kubernetes apiserver 会检查请求的证书。 + 如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的， + 并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。 + 请参阅[关于 TLS 身份验证的文档](/zh/docs/reference/access-authn-authz/authentication/#x509-client-certs)。 -* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用此选项，则 Kubernetes apiserver 会检查请求的证书。如果它是由文件引用中的 --requestheader-client-ca-file 所签署的 CA 证书之一签名的，则该请求将被视为潜在的合法请求。然后，Kubernetes apiserver 检查通用名称`CN=`是否是 --requestheader-allowed-names 提供的列表中的名称之一。如果名称允许，则请求被批准；如果不是，则请求被拒绝。 +* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时， + 如果启用此选项，则 Kubernetes apiserver 会检查请求的证书。 + 如果它是由文件引用中的 --requestheader-client-ca-file 所签署的 CA 证书之一签名的， + 则该请求将被视为潜在的合法请求。 + 然后，Kubernetes apiserver 检查通用名称 `CN=` 是否是 + `--requestheader-allowed-names` 提供的列表中的名称之一。 + 如果名称允许，则请求被批准；如果不是，则请求被拒绝。 -如果同时提供了 `--client-ca-file` 和`--requestheader-client-ca-file`，则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。常规客户端请求与 --client-ca-file 相匹配，而聚合请求与 `--requestheader-client-ca-file` 相匹配。但是，如果两者都使用同一个 CA，则通常会通过 `--client-ca-file` 传递的客户端请求将失败，因为 CA 将与 - `--requestheader-client-ca-file` 中的 CA 匹配，但是通用名称 `CN=` 将不匹配 `--requestheader-allowed-names` 中可接受的通用名称之一。这可能导致您的 kubelet 和其他控制平面组件以及最终用户无法向 Kubernetes apiserver 认证。 +如果同时提供了 `--client-ca-file` 和 `--requestheader-client-ca-file`， +则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。 +通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。 +常规客户端请求与 `--client-ca-file` 相匹配，而聚合请求要与 +`--requestheader-client-ca-file` 相匹配。 +但是，如果两者都使用同一个 CA，则通常会通过 `--client-ca-file` +传递的客户端请求将失败，因为 CA 将与 `--requestheader-client-ca-file` +中的 CA 匹配，但是通用名称 `CN=` 将不匹配 `--requestheader-allowed-names` +中可接受的通用名称之一。 +这可能导致你的 kubelet 和其他控制平面组件以及最终用户无法向 Kubernetes +apiserver 认证。 -因此，请对用于控制平面组件和最终用户鉴权的 `--client-ca-file` 选项和用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用不同的 CA 证书。 +因此，请对用于控制平面组件和最终用户鉴权的 `--client-ca-file` 选项和 +用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用 +不同的 CA 证书。 {{< warning >}} -除非您了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。 +除非你了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。 {{< /warning >}} -如果您未在运行 API 服务器的主机上运行 kube-proxy，则必须确保使用以下 `kube-apiserver` 标志启用系统： +如果你未在运行 API 服务器的主机上运行 kube-proxy，则必须确保使用以下 +`kube-apiserver` 标志启用系统： ``` --enable-aggregator-routing=true @@ -456,22 +522,22 @@ apiserver. The following is an example registration: --> ### 注册 APIService 对象 -您可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例： +你可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例： ```yaml apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: - name: < 注释对象名称 > + name: <注释对象名称> spec: - group: < 拓展 Apiserver 的 API group 名称 > - version: < 拓展 Apiserver 的 API version> - groupPriorityMinimum: < APIService 对对应 group 的优先级, 参考 API 文档 > - versionPriority: < 优先考虑 version 在 group 中的排序, 参考 API 文档 > + group: <扩展 Apiserver 的 API 组名> + version: <扩展 Apiserver 的 API 版本> + groupPriorityMinimum: + versionPriority: <版本在组中的优先排序, 参考 API 文档> service: - namespace: < 拓展 Apiserver 服务的 namespace > - name: < 拓展 Apiserver 服务的 name > - caBundle: < PEM 编码的 CA 证书，用于对 Webhook 服务器的证书签名 > + namespace: <拓展 Apiserver 服务的名字空间> + name: <拓展 Apiserver 服务的名称> + caBundle: ``` #### 调用扩展 apiserver -一旦 Kubernetes apiserver 确定应将请求发送到扩展 apiserver，它需要知道如何调用它。 +一旦 Kubernetes apiserver 确定应将请求发送到扩展 apiserver， +它需要知道如何调用它。 `service` 部分是对扩展 apiserver 的服务的引用。 -服务的 namespace 和 name 是必需的。port 是可选的，默认为 443。 -path 配置是可选的，默认为`/`。 +服务的名字空间和名字是必需的。端口是可选的，默认为 443。 +路径配置是可选的，默认为 `/`。 下面是为可在端口 `1234` 上调用的扩展 apiserver 的配置示例 -服务位于子路径 `/my-path` 下，并针对 ServerName `my-service-name.my-service-namespace.svc` +服务位于子路径 `/my-path` 下，并针对 ServerName +`my-service-name.my-service-namespace.svc` 使用自定义的 CA 包来验证 TLS 连接 使用自定义 CA 捆绑包的`my-service-name.my-service-namespace.svc`。 @@ -532,4 +600,4 @@ spec: * 使用聚合层[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)。 * 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。 -* 了解如何 [使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +* 了解如何[使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index aac5085ce7..7ecf926bf3 100644 --- a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -814,7 +814,7 @@ CustomResourceDefinition and migrating your objects from one version to another. 关于如何为你的 CustomResourceDefinition 提供多个版本的支持，以及如何将你的对象 从一个版本迁移到另一个版本， 详细信息可参阅 -[定制资源定义的版本](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。 +[定制资源定义的版本](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。 diff --git a/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md index 38aba0c76f..6071bf45fe 100644 --- a/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md +++ b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md @@ -19,7 +19,8 @@ weight: 15 -安装扩展的 API 服务器来使用聚合层以让 Kubernetes API 服务器使用其它 API 进行扩展， +安装扩展的 API 服务器来使用聚合层以让 Kubernetes API 服务器使用 +其它 API 进行扩展， 这些 API 不是核心 Kubernetes API 的一部分。 ## {{% heading "prerequisites" %}} @@ -112,5 +113,5 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu * 如果你还未配置，请[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 并启用 apiserver 的相关参数。 * 高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation)。 -* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 diff --git a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index 0bc46e4c07..fff6a8066a 100644 --- a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -32,7 +32,7 @@ There are two ways to expose Pod and Container fields to a running Container: 有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器： -* [环境变量](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/) +* [环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api) * 卷文件 这两种呈现 Pod 和 Container 字段的方式都称为 *Downward API*。 @@ -394,7 +394,6 @@ API 服务器来获得。 ## {{% heading "whatsnext" %}} - * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) * [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) * [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core) diff --git a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md index a501558cda..6d425f4d51 100644 --- a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md @@ -261,13 +261,13 @@ make room for new DaemonSet pods. {{< note >}} 当所删除的 Pod 不受任何控制器管理，也不是多副本的 Pod时，上述操作将导致服务中断。 同时，上述操作也不会考虑 -[PodDisruptionBudget](/zh/docs/tasks/configure-pod-container/configure-pod-disruption-budget/) +[PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 所施加的约束。 {{< /note >}} diff --git a/content/zh/docs/tasks/run-application/configure-pdb.md b/content/zh/docs/tasks/run-application/configure-pdb.md index 5fb983c4ee..60a870fa4e 100644 --- a/content/zh/docs/tasks/run-application/configure-pdb.md +++ b/content/zh/docs/tasks/run-application/configure-pdb.md @@ -34,7 +34,7 @@ nodes. Pod Disruption Budgets. --> * 你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。 -* 你应了解如何部署[无状态应用](.zh/docs/tasks/run-application/run-stateless-application-deployment/) +* 你应了解如何部署[无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) 和/或[有状态应用](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。 * 你应当已经阅读过关于 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 的文档。 * 用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。 diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 1d94fd247a..0e967bb46e 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -674,7 +674,8 @@ HorizontalPodAutoscaler. 首先，`AbleToScale` 表明 HPA 是否可以获取和更新扩缩信息，以及是否存在阻止扩缩的各种回退条件。 其次，`ScalingActive` 表明 HPA 是否被启用（即目标的副本数量不为零） 以及是否能够完成扩缩计算。 当这一状态为 `False` 时，通常表明获取度量指标存在问题。 -最后一个条件 `ScalingLimitted` 表明所需扩缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。 +最后一个条件 `ScalingLimitted` 表明所需扩缩的值被 HorizontalPodAutoscaler +所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。 这通常表明你可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。 -* 了解[服务目录](/zh/docs/concepts/service-catalog/)的主要概念。 +* 了解[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) + 的主要概念。 * 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。 * 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。 * 服务目录需要 Kubernetes 1.7+ 版本。 From eda601a4e257be86b3e0dfbd78fa5bccdfcda532 Mon Sep 17 00:00:00 2001 From: Philippe Martin Date: Thu, 3 Dec 2020 19:13:38 +0100 Subject: [PATCH 25/66] Report for my GSoD'20 project Update how the Kubernetes website serves API references --- ...2020-improving-api-reference-experience.md | 81 +++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 content/en/blog/_posts/2020-12-04-gsod-2020-improving-api-reference-experience.md diff --git a/content/en/blog/_posts/2020-12-04-gsod-2020-improving-api-reference-experience.md b/content/en/blog/_posts/2020-12-04-gsod-2020-improving-api-reference-experience.md new file mode 100644 index 0000000000..dc13b05926 --- /dev/null +++ b/content/en/blog/_posts/2020-12-04-gsod-2020-improving-api-reference-experience.md @@ -0,0 +1,81 @@ +--- +layout: blog +title: "GSoD 2020: Improving API Reference experience" +date: 2020-12-04 +slug: gsod-2020-improving-api-reference-experience +--- + +**Author**: Philippe Martin + +# Introduction + +[Google Season of Docs](https://developers.google.com/season-of-docs) brings open source organizations and technical writers together, to spend three months working closely during the autumn on a specific documentation project. + +I was selected by the CNCF organization to work on the Kubernetes documentation, specifically on the subject of making the API Reference documentation more accessible. + +I'm a software developer, with a great interest in documentation systems. At the end of the 90's, I wanted to invest my time in the Linux community and started translating Linux-HOWTO documents. From one thing to another, I learned about documentation systems and finally wrote a Linux-HOWTO, to help document writers learn the language used at this time for writing documents, LinuxDoc/SGML. + +Shortly after, the DocBook language was adopted to write the Linux Documentation. I helped some writers rewrite their documents in this format, for example the Advanced Bash-Scripting Guide. I also worked on the GNU `makeinfo` program to add the DocBook output, making possible to transform *GNU Info* documentation into Docbook. + +# Background + +The [Kubernetes documentation website](https://kubernetes.io/docs/home/) is built with Hugo from documentation written in Markdown format in the [website repository](https://github.com/kubernetes/website), using the [Docsy Hugo theme](https://www.docsy.dev/about/). + +The API reference documentation is a large HTML file generated from the Swagger specifications of the API, added to the content of the website. + +This API reference has some drawbacks: +- it is a single huge HTML page containing all the API reference +- its format is not adapted to mobile reading +- its design is not integrated with the kubernetes.io/docs website +- its content cannot be referenced by search engines + +On my side, I wanted for some time to make the API Reference more accessible. Around one year ago, I started to work on the generator building the current unique HTML page, to add a DocBook output, so the API Reference could be generated first in DocBook format, and after that in PDF or other formats supported by DocBook processors. The first result has been some [Ebook files for the API Reference](https://github.com/feloy/kubernetes-resources-reference/releases) and an auto-edited paper book. + +I decided later to add another output to this generator, to generate Markdown files and create [a website with the API Reference](https://web.archive.org/web/20201022201911/https://www.k8sref.io/docs/workloads/). + +When the CNCF proposed a project for the Google Season of Docs to work on the API Reference, I applied, and the match occurred. + +# The Project + +## swagger-ui + +The first idea of the CNCF members that proposed this project was to test the [`swagger-ui` tool](https://swagger.io/tools/swagger-ui/), to try and document the Kubernetes API Reference with this standard tool. + +Because the Kubernetes API is much larger than many other APIs, it has been necessary to write a tool to split the complete API Reference by API Groups, and insert in the Documentation website several `swagger-ui` components, one for each API Group. + +Generally, APIs are used by developers by calling endpoints with a specific HTTP verb, with specific parameters and waiting for a response. The `swagger-ui` interface is built for this usage: the interface displays a list of endpoints and their associated verbs, and for each the parameters and responses formats. + +The Kubernetes API is most of the time used differently: users create manifest files containing resources definitions in YAML format, and use the `kubectl` CLI to *apply* these manifests to the cluster. In this case, the most important information is the description of the structures used as parameters and responses (the Kubernetes Resources). + +Because of this specificity, we realized that it would be difficult to adapt the `swagger-ui` interface to satisfy the users of the Kubernetes API. + +## Markdown pages + +The second stage of the project has been to adapt the work I had done to create the k8sref.io website, to include it in the officiel documentation website. + +The main changes have been to: +- use go-templates to represent the output pages, so non-developers can adapt the generated pages without having to edit the generator code +- create a shortcode, to easily create links from inside the website to specific pages of the API reference +- improve the navigation between the sections of the API reference +- add the code of the generator to the Kubernetes GitHub repository containing the different reference generators + +All the discussions and work done can be found on [this Pull Request](https://github.com/kubernetes/website/pull/23294). + +The Pull request to add the code of the generator to the Kubernetes GitHub repository is [this Pull Request](https://github.com/kubernetes-sigs/reference-docs/pull/179). + +Here are the features of the API Reference included in the official documentation website: + +- the resources are categorized, in the categories Workloads, Services, Config & Storage, Authentication, Authorization, Policies, Extend, Cluster. This structure is configurable with a simple [`toc.yaml` file](https://github.com/kubernetes-sigs/reference-docs/blob/master/gen-resourcesdocs/config/v1.20/toc.yaml) +- each page displays at the first level the associated resources, for example Pod, PodSpec, PodStatus, PodList +- each resource inlines its definitions (except when definitions are common to several resources, or are too complex to be displayed inline) +- some widely used definitions are documented in a specific page (ex ObjectMeta) +- required fields are indicated, and placed first +- fields of a resource can be categorized and ordered, with the help of a [`fields.yaml` file](https://github.com/kubernetes-sigs/reference-docs/blob/master/gen-resourcesdocs/config/v1.20/fields.yaml) +- maps fields are indicated (ex pod.spec.nodeSelector is map[string]string, instead of object) using the value of `x-kubernetes-list-type` +- patch strategies are indicated +- `apiVersion` and `kind` display the value, not the `string` type +- on top of the page, the Go import necessary to use these resources from a Go program is displayed + +# Appreciation + +I would like to thank my mentor [Zach Corleissen](https://github.com/zacharysarah) and the lead writers [Karen Bradshaw](https://github.com/kbhawkey), [Tim Bannister](https://github.com/sftim) and [Qiming Teng](https://github.com/tengqm) who supervised me during all the season. They all have been very encouraging and gave me tons of great advices. From abab517ffc8ac705d21f7ca3e2a0c429465ef25b Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 4 Dec 2020 18:22:25 +0800 Subject: [PATCH 26/66] [zh] Fix links in zh localization (4) --- content/zh/docs/reference/_index.md | 8 +- .../admission-controllers.md | 6 +- .../extensible-admission-controllers.md | 387 +++++++++++------- .../feature-gates.md | 336 ++++++++++----- .../kubelet-authentication-authorization.md | 18 +- .../kubelet-tls-bootstrapping.md | 2 +- .../zh/docs/reference/glossary/extensions.md | 10 +- .../zh/docs/reference/glossary/flexvolume.md | 28 +- .../reference/glossary/managed-service.md | 8 +- .../reference/glossary/operator-pattern.md | 16 +- .../reference/glossary/platform-developer.md | 2 +- .../docs/reference/glossary/pod-lifecycle.md | 15 +- .../docs/reference/issues-security/issues.md | 12 +- content/zh/docs/reference/kubectl/overview.md | 68 +-- .../setup-tools/kubeadm/kubeadm-alpha.md | 14 +- .../setup-tools/kubeadm/kubeadm-join-phase.md | 22 +- .../kubeadm/kubeadm-reset-phase.md | 22 +- content/zh/docs/reference/tools.md | 30 +- 18 files changed, 628 insertions(+), 376 deletions(-) diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index 75000a7708..5f9c8b5433 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -70,7 +70,8 @@ client libraries: ## CLI 参考 * [kubectl](/zh/docs/reference/kubectl/overview/) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 - * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 + * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用 + [JSONPath 表达式](https://goessner.net/articles/JsonPath/) 的语法指南。 * [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 ## 设计文档 -Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 +Kubernetes 功能的设计文档归档，不妨考虑从 +[Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 +[Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals) +开始阅读。 diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index d5c847ab5f..2e0ad53a92 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -5,7 +5,6 @@ weight: 30 --- - 此页面概述了准入控制器。 - 有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/) +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) ### CertificateSigning diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md index 9e42aa7bdf..f41d34c8ee 100644 --- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -5,11 +5,9 @@ weight: 40 --- @@ -18,15 +16,15 @@ In addition to [compiled-in admission plugins](/docs/reference/access-authn-auth admission plugins can be developed as extensions and run as webhooks configured at runtime. This page describes how to build, configure, use, and monitor admission webhooks. --> -除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。 -此页面描述了如何构建、配置、使用和监视 admission webhook。 - +除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)， +准入插件可以作为扩展独立开发，并以运行时所配置的 Webhook 的形式运行。 +此页面描述了如何构建、配置、使用和监视准入 Webhook。 -## 什么是 admission webhook？ +## 什么是准入 Webhook？ -Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 -可以定义两种类型的 admission webhook，即 [validating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。 -Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。 +准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 +可以定义两种类型的准入 webhook，即 +[验证性质的准入 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 +[修改性质的准入 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。 +修改性质的准入 Webhook 会先被调用。它们可以更改发送到 API +服务器的对象以执行自定义的设置默认值操作。 -在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，validating admission webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。 +在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后， +验证性质的 Webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。 {{< note >}} -如果 admission webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。则应使用 validating admission webhook，因为对象被 mutating webhook 看到之后仍然可能被修改。 +如果准入 Webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。 +则应使用验证性质的准入 Webhook，因为对象被修改性质 Webhook 看到之后仍然可能被修改。 {{< /note >}} @@ -64,11 +67,11 @@ guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#wri instructions if you intend to write/deploy production-grade admission webhooks. In the following, we describe how to quickly experiment with admission webhooks. --> -### 尝试 admission webhook +### 尝试准入 Webhook -admission webhook 本质上是集群控制平面的一部分。您应该非常谨慎地编写和部署它们。 -如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。 -在下文中，我们将介绍如何快速试验 admission webhook。 +准入 Webhook 本质上是集群控制平面的一部分。你应该非常谨慎地编写和部署它们。 +如果你打算编写或者部署生产级准入 webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。 +在下文中，我们将介绍如何快速试验准入 Webhook。 -### 编写一个 admission webhook 服务器 +### 编写一个准入 Webhook 服务器 -示例 admission webhook 服务器置 `ClientAuth` 字段为[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)，默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。 -如果您需要双向 TLS 或其他方式来验证客户端，请参阅如何[对 apiservers 进行身份认证](#authenticate-apiservers)。 +示例准入 Webhook 服务器置 `ClientAuth` 字段为[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)，默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。 +如果你需要双向 TLS 或其他方式来验证客户端，请参阅如何[对 apiservers 进行身份认证](#authenticate-apiservers)。 -### 部署 admission webhook 服务 +### 部署准入 Webhook 服务 -您也可以在集群外部署 webhook。这样做需要相应地更新您的 webhook 配置。 +你也可以在集群外部署 webhook。这样做需要相应地更新你的 webhook 配置。 -### 即时配置 admission webhook +### 即时配置准入 Webhook -您可以通过 [ValidatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io) 或者 [MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) 动态配置哪些资源要被哪些 admission webhook 处理。 +你可以通过 [ValidatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io) 或者 [MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) 动态配置哪些资源要被哪些准入 Webhook 处理。 -scope 字段指定是仅集群范围的资源（Cluster）还是命名空间范围的资源资源（Namespaced）将与此规则匹配。`*` 表示没有范围限制。 +scope 字段指定是仅集群范围的资源（Cluster）还是名字空间范围的资源资源（Namespaced）将与此规则匹配。`*` 表示没有范围限制。 {{< note >}} -对于使用 `admissionregistration.k8s.io/v1` 创建的 webhook 而言，其 webhook 调用的默认超时是 10 秒；对于使用 `admissionregistration.k8s.io/v1beta1` 创建的 webhook 而言，其默认超时是 30 秒。从 kubernetes 1.14 开始，可以设置超时。建议对 webhooks 设置较短的超时时间。 +对于使用 `admissionregistration.k8s.io/v1` 创建的 webhook 而言，其 webhook 调用的默认超时是 10 秒； +对于使用 `admissionregistration.k8s.io/v1beta1` 创建的 webhook 而言，其默认超时是 30 秒。 +从 kubernetes 1.14 开始，可以设置超时。建议对 webhooks 设置较短的超时时间。 如果 webhook 调用超时，则根据 webhook 的失败策略处理请求。 {{< /note >}} @@ -266,7 +271,7 @@ If your admission webhooks require authentication, you can configure the apiservers to use basic auth, bearer token, or a cert to authenticate itself to the webhooks. There are three steps to complete the configuration. --> -如果您的 webhook 需要身份验证，则可以将 apiserver 配置为使用基本身份验证、持有者令牌或证书来向 webhook 提供身份证明。完成此配置需要三个步骤。 +如果你的 webhook 需要身份验证，则可以将 apiserver 配置为使用基本身份验证、持有者令牌或证书来向 webhook 提供身份证明。完成此配置需要三个步骤。 -当然，您需要设置 webhook 服务器来处理这些身份验证。 +当然，你需要设置 webhook 服务器来处理这些身份验证。 -当拒绝请求时，webhook 可以使用 `status` 字段自定义 http 响应码和返回给用户的消息。 -有关状态类型的详细信息，请参见 [API 文档](/docs/reference/generated/kubernetes-api/v1.14/#status-v1-meta)。 +当拒绝请求时，Webhook 可以使用 `status` 字段自定义 http 响应码和返回给用户的消息。 +有关状态类型的详细信息，请参见 +[API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#status-v1-meta)。 禁止请求的响应示例，它定制了向用户显示的 HTTP 状态码和消息： {{< tabs name="AdmissionReview_response_forbid_details" >}} @@ -745,7 +751,7 @@ The only currently supported `patchType` is `JSONPatch`. See [JSON patch](http://jsonpatch.com/) documentation for more details. For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations. --> -当允许请求时，mutating admission webhook 也可以选择修改传入的对象。 +当允许请求时，mutating准入 Webhook 也可以选择修改传入的对象。 这是通过在响应中使用 `patch` 和 `patchType` 字段来完成的。 当前唯一支持的 `patchType` 是 `JSONPatch`。 有关更多详细信息，请参见 [JSON patch](https://jsonpatch.com/)。 @@ -756,9 +762,11 @@ As an example, a single patch operation that would set `spec.replicas` would be Base64-encoded, this would be `W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=` --> -例如，设置 `spec.replicas` 的单个补丁操作将是 `[{"op": "add", "path": "/spec/replicas", "value": 3}]`。 +例如，设置 `spec.replicas` 的单个补丁操作将是 +`[{"op": "add", "path": "/spec/replicas", "value": 3}]`。 -如果以 Base64 形式编码，这将是 `W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=` +如果以 Base64 形式编码，结果将是 +`W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=` -## webhook 配置{#webhook-configuration} +## Webhook 配置{#webhook-configuration} -要注册 admssion webhook，请创建 `MutatingWebhookConfiguration` 或 `ValidatingWebhookConfiguration` API 对象。 +要注册准入 Webhook，请创建 `MutatingWebhookConfiguration` 或 +`ValidatingWebhookConfiguration` API 对象。 -每种配置可以包含一个或多个 webhook。如果在单个配置中指定了多个 webhook，则应为每个 webhook 赋予一个唯一的名称。 -这在 `admissionregistration.k8s.io/v1` 中是必需的，但是在使用 `admissionregistration.k8s.io/v1beta1` 时强烈建议使用，以使生成的审核日志和指标更易于与活动配置相匹配。 +每种配置可以包含一个或多个 Webhook。如果在单个配置中指定了多个 +Webhook，则应为每个 webhook 赋予一个唯一的名称。 +这在 `admissionregistration.k8s.io/v1` 中是必需的，但是在使用 +`admissionregistration.k8s.io/v1beta1` 时强烈建议使用， +以使生成的审核日志和指标更易于与活动配置相匹配。 -每个 webhook 定义以下内容。 +每个 Webhook 定义以下内容。 -* `operations` 列出一个或多个要匹配的操作。可以是 `CREATE`、`UPDATE`、`DELETE`、`CONNECT` 或 `*` 以匹配所有内容。 +* `operations` 列出一个或多个要匹配的操作。 + 可以是 `CREATE`、`UPDATE`、`DELETE`、`CONNECT` 或 `*` 以匹配所有内容。 * `apiGroups` 列出了一个或多个要匹配的 API 组。`""` 是核心 API 组。`"*"` 匹配所有 API 组。 * `apiVersions` 列出了一个或多个要匹配的 API 版本。`"*"` 匹配所有 API 版本。 * `resources` 列出了一个或多个要匹配的资源。 @@ -850,9 +863,11 @@ Each rule specifies one or more operations, apiGroups, apiVersions, and resource * `"*/*"` 匹配所有资源，包括子资源。 * `"pods/*"` 匹配 pod 的所有子资源。 * `"*/status"` 匹配所有 status 子资源。 -* `scope` 指定要匹配的范围。有效值为 `"Cluster"`、`"Namespaced"` 和 `"*"`。子资源匹配其父资源的范围。在 Kubernetes v1.14+ 版本中才被支持。默认值为 `"*"`，对应 1.14 版本之前的行为。 +* `scope` 指定要匹配的范围。有效值为 `"Cluster"`、`"Namespaced"` 和 `"*"`。 + 子资源匹配其父资源的范围。在 Kubernetes v1.14+ 版本中才被支持。 + 默认值为 `"*"`，对应 1.14 版本之前的行为。 * `"Cluster"` 表示只有集群作用域的资源才能匹配此规则（API 对象 Namespace 是集群作用域的）。 - * `"Namespaced"` 意味着仅具有命名空间的资源才符合此规则。 + * `"Namespaced"` 意味着仅具有名字空间的资源才符合此规则。 * `"*"` 表示没有范围限制。 -在版本 v1.15+ 中, 通过指定 `objectSelector`，webhook 能够根据可能发送的对象的标签来限制哪些请求被拦截。如果指定，则将对 `objectSelector` 和可能发送到 webhook 的 object 和 oldObject 进行评估。如果两个对象之一与选择器匹配，则认为该请求已匹配。 +在版本 v1.15+ 中, 通过指定 `objectSelector`，Webhook 能够根据 +可能发送的对象的标签来限制哪些请求被拦截。 +如果指定，则将对 `objectSelector` 和可能发送到 Webhook 的 object 和 oldObject +进行评估。如果两个对象之一与选择器匹配，则认为该请求已匹配。 -空对象（对于创建操作而言为 oldObject，对于删除操作而言为 newObject），或不能带标签的对象（例如 `DeploymentRollback` 或 `PodProxyOptions` 对象）被认为不匹配。 +空对象（对于创建操作而言为 oldObject，对于删除操作而言为 newObject）， +或不能带标签的对象（例如 `DeploymentRollback` 或 `PodProxyOptions` 对象） +被认为不匹配。 -仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来跳过 admission webhook。 +仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来 +跳过准入 Webhook。 -这个例子展示了一个 mutating webhook，它将匹配带有标签 `foo:bar` 的任何资源的 `CREATE` 的操作： +这个例子展示了一个 mutating webhook，它将匹配带有标签 `foo:bar` 的任何资源的 +`CREATE` 的操作： {{< tabs name="objectSelector_example" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} @@ -1071,7 +1094,8 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for Webhooks may optionally limit which requests for namespaced resources are intercepted, based on the labels of the containing namespace, by specifying a `namespaceSelector`. --> -通过指定 `namespaceSelector`，Webhook 可以根据具有命名空间的资源所处的命名空间的标签来选择拦截哪些资源的操作。 +通过指定 `namespaceSelector`，Webhook 可以根据具有名字空间的资源所处的 +名字空间的标签来选择拦截哪些资源的操作。 -`namespaceSelector` 根据命名空间的标签是否匹配选择器，决定是否针对具命名空间的资源（或 Namespace 对象）的请求运行 webhook。 +`namespaceSelector` 根据名字空间的标签是否匹配选择器，决定是否针对具名字空间的资源 +（或 Namespace 对象）的请求运行 webhook。 如果对象是除 Namespace 以外的集群范围的资源，则 `namespaceSelector` 标签无效。 -本例给出的 mutating webhook 将匹配到对命名空间中具命名空间的资源的 `CREATE` 请求，前提是这些资源不含值为 "0" 或 "1" 的 "runlevel" 标签： +本例给出的修改性质的 Webhook 将匹配到对名字空间中具名字空间的资源的 `CREATE` 请求， +前提是这些资源不含值为 "0" 或 "1" 的 "runlevel" 标签： {{< tabs name="MutatingWebhookConfiguration_namespaceSelector_1" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} @@ -1138,7 +1164,9 @@ webhooks: This example shows a validating webhook that matches a `CREATE` of any namespaced resource inside a namespace that is associated with the "environment" of "prod" or "staging": --> -此示例显示了一个 validating webhook，它将匹配到对某命名空间中的任何具命名空间的资源的 `CREATE` 请求，前提是该命名空间具有值为 "prod" 或 "staging" 的 "environment" 标签： +此示例显示了一个验证性质的 Webhook，它将匹配到对某名字空间中的任何具名字空间的资源的 +`CREATE` 请求，前提是该名字空间具有值为 "prod" 或 "staging" 的 "environment" 标签： + {{< tabs name="ValidatingWebhookConfiguration_namespaceSelector_2" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} ```yaml @@ -1187,7 +1215,8 @@ webhooks: -有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。 +有关标签选择器的更多示例，请参见 +[标签](/zh/docs/concepts/overview/working-with-objects/labels)。 API 服务器可以通过多个 API 组或版本来提供对象。 -例如，Kubernetes API 服务器允许通过 `extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2` 和 `apps/v1` API 创建和修改 `Deployment` 对象。 +例如，Kubernetes API 服务器允许通过 `extensions/v1beta1`、`apps/v1beta1`、 +`apps/v1beta2` 和 `apps/v1` API 创建和修改 `Deployment` 对象。 -例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如 `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求是通过另一个 API 组/版本（例如 `extensions/v1beta1`）发出的，该请求将不会被发送到 Webhook。 +例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如 +`apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求 +是通过另一个 API 组/版本（例如 `extensions/v1beta1`）发出的， +该请求将不会被发送到 Webhook。 * `Exact` 表示仅当请求与指定规则完全匹配时才应拦截该请求。 -* `Equivalent` 表示如果某个请求意在修改 `rules` 中列出的资源，即使该请求是通过其他 API 组或版本发起，也应拦截该请求。 +* `Equivalent` 表示如果某个请求意在修改 `rules` 中列出的资源， + 即使该请求是通过其他 API 组或版本发起，也应拦截该请求。 在上面给出的示例中，仅为 `apps/v1` 注册的 webhook 可以使用 `matchPolicy`： * `matchPolicy: Exact` 表示不会将 `extensions/v1beta1` 请求发送到 Webhook -* `matchPolicy:Equivalent` 表示将 `extensions/v1beta1` 请求发送到 webhook（将对象转换为 webhook 指定的版本：`apps/v1`） +* `matchPolicy:Equivalent` 表示将 `extensions/v1beta1` 请求发送到 webhook + （将对象转换为 webhook 指定的版本：`apps/v1`） -建议指定 `Equivalent`，确保升级后启用 API 服务器中资源的新版本时，webhook 继续拦截他们期望的资源。 +建议指定 `Equivalent`，确保升级后启用 API 服务器中资源的新版本时， +Webhook 继续拦截他们期望的资源。 当 API 服务器停止提供某资源时，该资源不再被视为等同于该资源的其他仍在提供服务的版本。 例如，`extensions/v1beta1` 中的 Deployment 已被废弃，计划在 v1.16 中默认停止使用。 -在这种情况下，带有 `apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]` 规则的 webhook 将不再拦截通过 `apps/v1` API 来创建 Deployment 的请求。 +在这种情况下，带有 `apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]` +规则的 Webhook 将不再拦截通过 `apps/v1` API 来创建 Deployment 的请求。 ["deployments"] 规则将不再拦截通过 `apps/v1` API 创建的部署。 + -此示例显示了一个 validating webhook，该 Webhook 拦截对 Deployment 的修改（无论 API 组或版本是什么）， +此示例显示了一个验证性质的 Webhook，该 Webhook 拦截对 Deployment 的修改（无论 API 组或版本是什么）， 始终会发送一个 `apps/v1` 版本的 Deployment 对象： {{< tabs name="ValidatingWebhookConfiguration_matchPolicy" >}} @@ -1300,7 +1338,7 @@ webhooks: -使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhhok 默认为 `Exact`。 +使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 默认为 `Exact`。 {{% /tab %}} {{< /tabs >}} @@ -1317,7 +1355,8 @@ stanza of the webhook configuration. Webhooks can either be called via a URL or a service reference, and can optionally include a custom CA bundle to use to verify the TLS connection. --> -API 服务器确定请求应发送到 webhook 后，它需要知道如何调用 webhook。此信息在 webhook 配置的 `clientConfig` 节中指定。 +API 服务器确定请求应发送到 webhook 后，它需要知道如何调用 webhook。 +此信息在 webhook 配置的 `clientConfig` 节中指定。 Webhook 可以通过 URL 或服务引用来调用，并且可以选择包含自定义 CA 包，以用于验证 TLS 连接。 @@ -1350,7 +1389,9 @@ which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. --> -请注意，将 `localhost` 或 `127.0.0.1` 用作 `host` 是有风险的，除非您非常小心地在所有运行 apiserver 的、可能需要对此 webhook 进行调用的主机上运行。这样的安装可能不具有可移植性，即很难在新集群中启用。 +请注意，将 `localhost` 或 `127.0.0.1` 用作 `host` 是有风险的， +除非你非常小心地在所有运行 apiserver 的、可能需要对此 webhook +进行调用的主机上运行。这样的安装可能不具有可移植性，即很难在新集群中启用。 -这是配置为调用 URL 的 mutating Webhook 的示例（并且期望使用系统信任根证书来验证 TLS 证书，因此不指定 caBundle）： +这是配置为调用 URL 的修改性质的 Webhook 的示例 +（并且期望使用系统信任根证书来验证 TLS 证书，因此不指定 caBundle）： {{< tabs name="MutatingWebhookConfiguration_url" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} @@ -1409,14 +1451,19 @@ If the webhook is running within the cluster, then you should use `service` inst The service namespace and name are required. The port is optional and defaults to 443. The path is optional and defaults to "/". --> -`clientConfig` 内部的 Service 是对该 Webhook 服务的引用。如果 Webhook 在集群中运行，则应使用 `service` 而不是 `url`。服务的 `namespace` 和 `name` 是必需的。`port` 是可选的，默认值为 443。`path` 是可选的，默认为 "/"。 +`clientConfig` 内部的 Service 是对该 Webhook 服务的引用。 +如果 Webhook 在集群中运行，则应使用 `service` 而不是 `url`。 +服务的 `namespace` 和 `name` 是必需的。 +`port` 是可选的，默认值为 443。`path` 是可选的，默认为 "/"。 -这是一个 mutating Webhook 的示例，该 mutating Webhook 配置为在子路径 "/my-path" 端口 "1234" 上调用服务，并使用自定义 CA 包针对 ServerName `my-service-name.my-service-namespace.svc` 验证 TLS 连接： +这是一个 mutating Webhook 的示例，该 mutating Webhook 配置为在子路径 "/my-path" 端口 +"1234" 上调用服务，并使用自定义 CA 包针对 ServerName +`my-service-name.my-service-namespace.svc` 验证 TLS 连接： {{< tabs name="MutatingWebhookConfiguration_service" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} @@ -1464,7 +1511,8 @@ webhooks: Webhooks typically operate only on the content of the `AdmissionReview` sent to them. Some webhooks, however, make out-of-band changes as part of processing admission requests. --> -Webhook 通常仅对发送给他们的 `AdmissionReview` 内容进行操作。但是，某些 Webhook 在处理 admission 请求时会进行带外更改。 +Webhook 通常仅对发送给他们的 `AdmissionReview` 内容进行操作。 +但是，某些 Webhook 在处理 admission 请求时会进行带外更改。 -进行带外更改的（产生“副作用”的） Webhook 必须具有协调机制（如控制器），该机制定期确定事物的实际状态，并调整由 admission Webhook 修改的带外数据以反映现实情况。 -这是因为对 admission Webhook 的调用不能保证所准入的对象将原样保留，或根本不保留。 -以后，webhook 可以修改对象的内容，在写入存储时可能会发生冲突，或者服务器可以在持久保存对象之前关闭电源。 +进行带外更改的（产生“副作用”的） Webhook 必须具有协调机制（如控制器）， +该机制定期确定事物的实际状态，并调整由准入 Webhook 修改的带外数据以反映现实情况。 +这是因为对准入 Webhook 的调用不能保证所准入的对象将原样保留，或根本不保留。 +以后，webhook 可以修改对象的内容，在写入存储时可能会发生冲突，或者 +服务器可以在持久保存对象之前关闭电源。 -此外，处理 `dryRun: true` admission 请求时，具有副作用的 webhook 必须避免产生副作用。 -一个 webhook 必须明确指出在使用 `dryRun` 运行时不会有副作用，否则 `dry-run` 请求将不会发送到该 webhook，而 API 请求将会失败。 +此外，处理 `dryRun: true` admission 请求时，具有副作用的 Webhook 必须避免产生副作用。 +一个 Webhook 必须明确指出在使用 `dryRun` 运行时不会有副作用， +否则 `dry-run` 请求将不会发送到该 Webhook，而 API 请求将会失败。 允许值： -* 在 `admissionregistration.k8s.io/v1beta1` 中，`sideEffects` 可以设置为 `Unknown`、`None`、`Some` 或者 `NoneOnDryRun`，并且默认值为 `Unknown`。 -* 在 `admissionregistration.k8s.io/v1` 中, `sideEffects` 必须设置为 `None` 或者 `NoneOnDryRun`。 +* 在 `admissionregistration.k8s.io/v1beta1` 中，`sideEffects` 可以设置为 + `Unknown`、`None`、`Some` 或者 `NoneOnDryRun`，并且默认值为 `Unknown`。 +* 在 `admissionregistration.k8s.io/v1` 中, `sideEffects` 必须设置为 + `None` 或者 `NoneOnDryRun`。 -如果超时在 Webhook 响应之前被触发，则基于[失败策略](#failure-policy)，将忽略 Webhook 调用或拒绝 API 调用。 +如果超时在 Webhook 响应之前被触发，则基于[失败策略](#failure-policy)，将忽略 +Webhook 调用或拒绝 API 调用。 超时值必须设置在 1 到 30 秒之间。 @@ -1586,7 +1642,7 @@ webhooks: -使用 `admissionregistration.k8s.io/v1` 创建的 admission webhook 默认超时为 10 秒。 +使用 `admissionregistration.k8s.io/v1` 创建的准入 Webhook 默认超时为 10 秒。 {{% /tab %}} {{% tab name="admissionregistration.k8s.io/v1beta1" %}} ```yaml @@ -1603,7 +1659,7 @@ webhooks: -使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhook 默认超时为 30 秒。 +使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 默认超时为 30 秒。 {{% /tab %}} {{< /tabs >}} @@ -1618,14 +1674,20 @@ A single ordering of mutating admissions plugins (including webhooks) does not w to the object (like adding a `container` to a `pod`), and other mutating plugins which have already run may have opinions on those new structures (like setting an `imagePullPolicy` on all containers). --> -mutating 准入插件（包括 Webhook）的任何一种排序方式都不会适用于所有情况。(参见 https://issue.k8s.io/64333 示例)。mutating Webhook 可以向对象中添加新的子结构（例如向 `pod` 中添加 `container`），已经运行的其他 mutating 插件可能会对这些新结构有影响（就像在所有容器上设置 `imagePullPolicy` 一样）。 +修改性质的准入插件（包括 Webhook）的任何一种排序方式都不会适用于所有情况。 +(参见 https://issue.k8s.io/64333 示例)。 +修改性质的 Webhook 可以向对象中添加新的子结构（例如向 `pod` 中添加 `container`）， +已经运行的其他修改插件可能会对这些新结构有影响 +（就像在所有容器上设置 `imagePullPolicy` 一样）。 -在 v1.15+ 中，允许 mutating 准入插件感应到其他插件所做的更改，如果 mutating webhook 修改了一个对象，则会重新运行内置的 mutating 准入插件，并且 mutating webhook 可以指定 `reinvocationPolicy` 来控制是否也重新调用它们。 +在 v1.15+ 中，允许修改性质的准入插件感应到其他插件所做的更改， +如果修改性质的 Webhook 修改了一个对象，则会重新运行内置的修改性质的准入插件， +并且修改性质的 Webhook 可以指定 `reinvocationPolicy` 来控制是否也重新调用它们。 * `Never`: 在一次准入测试中，不得多次调用 Webhook。 -* `IfNeeded`: 如果在最初的 webhook 调用之后被其他对象的插件修改了被接纳的对象，则可以作为准入测试的一部分再次调用该 webhook。 +* `IfNeeded`: 如果在最初的 Webhook 调用之后被其他对象的插件修改了被接纳的对象， + 则可以作为准入测试的一部分再次调用该 webhook。 * 不能保证附加调用的次数恰好是一。 -* 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 webhook。 +* 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 Webhook。 * 使用此选项的 Webhook 可能会重新排序，以最大程度地减少额外调用的次数。 -* 要在确保所有 mutation 都完成后验证对象，请改用 validating admission webhook（推荐用于有副作用的 webhook）。 +* 要在确保所有修改都完成后验证对象，请改用验证性质的 Webhook + （推荐用于有副作用的 Webhook）。 -这是一个 mutating webhook 的示例，该 Webhook 在以后的准入插件修改对象时被重新调用： +这是一个修改性质的 Webhook 的示例，该 Webhook 在以后的准入插件修改对象时被重新调用： {{< tabs name="MutatingWebhookConfiguration_reinvocationPolicy" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} @@ -1692,7 +1756,11 @@ Mutating webhooks must be [idempotent](#idempotence), able to successfully proce and potentially modified. This is true for all mutating admission webhooks, since any change they can make in an object could already exist in the user-provided object, but it is essential for webhooks that opt into reinvocation. --> -mutating webhook 必须具有 [幂等](#idempotence) 性，并且能够成功处理已被接纳并可能被修改的对象的 mutating Web 钩子。对于所有 mutating admission webhook 都是如此，因为它们可以在对象中进行的任何更改可能已经存在于用户提供的对象中，但是对于选择重新调用的 webhook 来说是必不可少的。 +修改性质的 Webhook 必须具有[幂等](#idempotence)性，并且能够成功处理 +已被接纳并可能被修改的对象的修改性质的 Webhook。 +对于所有修改性质的准入 Webhook 都是如此，因为它们可以在对象中进行的 +任何更改可能已经存在于用户提供的对象中，但是对于选择重新调用的 webhook +来说是必不可少的。 -`failurePolicy` 定义了如何处理 admission webhook 中无法识别的错误和超时错误。允许的值为 `Ignore` 或 `Fail`。 +`failurePolicy` 定义了如何处理准入 webhook 中无法识别的错误和超时错误。允许的值为 `Ignore` 或 `Fail`。 * `Ignore` 表示调用 webhook 的错误将被忽略并且允许 API 请求继续。 * `Fail` 表示调用 webhook 的错误导致准入失败并且 API 请求被拒绝。 -这是一个 mutating webhook，配置为在调用准入 Webhook 遇到错误时拒绝 API 请求： +这是一个修改性质的 webhook，配置为在调用准入 Webhook 遇到错误时拒绝 API 请求： {{< tabs name="MutatingWebhookConfiguration_failurePolicy" >}} {{% tab name="admissionregistration.k8s.io/v1" %}} @@ -1730,7 +1798,8 @@ webhooks: -使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhook 将 `failurePolicy` 默认设置为 `Ignore`。 +使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 将 +`failurePolicy` 默认设置为 `Ignore`。 {{% /tab %}} {{% tab name="admissionregistration.k8s.io/v1beta1" %}} @@ -1747,7 +1816,8 @@ webhooks: -使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhook 将 `failurePolicy` 默认设置为 `Ignore`。 +使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 将 +`failurePolicy` 默认设置为 `Ignore`。 {{% /tab %}} {{< /tabs >}} @@ -1767,12 +1837,11 @@ monitoring mechanisms help cluster admins to answer questions like: 3. Which webhooks are frequently rejecting API requests? What's the reason for a rejection? --> -API 服务器提供了监视 admission Webhook 行为的方法。这些监视机制可帮助集群管理员回答以下问题： - -1. 哪个 mutating webhook 改变了 API 请求中的对象？ - -2. mutating webhook 对对象做了哪些更改？ +API 服务器提供了监视准入 Webhook 行为的方法。这些监视机制可帮助集群管理员 +回答以下问题： +1. 哪个修改性质的 webhook 改变了 API 请求中的对象？ +2. 修改性质的 Webhook 对对象做了哪些更改？ 3. 哪些 webhook 经常拒绝 API 请求？是什么原因拒绝？ -有时，了解 API 请求中的哪个 mutating Webhook 使对象改变以及该 Webhook 应用了哪些更改很有用。 +有时，了解 API 请求中的哪个修改性质的 Webhook 使对象改变以及该 +Webhook 应用了哪些更改很有用。 -在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。 -每个调用都会生成一个审计注解，记述请求对象是否发生改变，可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。 -针对给定请求的给定执行阶段，注解被添加到审计事件中，然后根据特定策略进行预处理并写入后端。 +在 v1.16+ 中，kube-apiserver 针对每个修改性质的 Webhook 调用执行 +[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。 +每个调用都会生成一个审计注解，记述请求对象是否发生改变， +可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。 +针对给定请求的给定执行阶段，注解被添加到审计事件中， +然后根据特定策略进行预处理并写入后端。 -在 `Metadata` 或更高审计级别上，将使用 JSON 负载记录带有键名 `mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解， +在 `Metadata` 或更高审计级别上，将使用 JSON 负载记录带有键名 +`mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解， 该注解表示针对给定请求调用了 Webhook，以及该 Webhook 是否更改了对象。 -在 `Request` 或更高审计级别上，将使用 JSON 负载记录带有键名为 `patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解， +在 `Request` 或更高审计级别上，将使用 JSON 负载记录带有键名为 +`patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解， 该注解表明针对给定请求调用了 Webhook 以及应用于请求对象之上的修改。 例如，以下是针对正在被重新调用的某 Webhook 所记录的注解。 -Webhook 在 mutating Webhook 链中排在第四，并在其响应中包含一个 JSON 补丁，该补丁已被应用于请求对象。 +Webhook 在修改性质的 Webhook 链中排在第四，并在其响应中包含一个 JSON 补丁， +该补丁已被应用于请求对象。 ```yaml # 审计事件相关记录 @@ -1921,18 +1997,19 @@ Webhook 在 mutating Webhook 链中排在第四，并在其响应中包含一个 -### Amission webhook metrics +### 准入 Webhook 度量值 -Kube-apiserver 从 `/metrics` 端点公开 Prometheus 指标，这些指标可用于监控和诊断 apiserver 状态。以下指标记录了与 admission Webhook 相关的状态。 +Kube-apiserver 从 `/metrics` 端点公开 Prometheus 指标，这些指标可用于监控和诊断 +apiserver 状态。以下指标记录了与准入 Webhook 相关的状态。 -#### apiserver Admission Webhook rejection count +#### apiserver 准入 Webhook 拒绝次数 -有时，了解哪些 admission webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。 +有时，了解哪些准入 Webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。 -在 v1.16+ 中，kube-apiserver 提供了 Prometheus 计数器度量值，记录了 admission Webhook 的拒绝次数。 +在 v1.16+ 中，kube-apiserver 提供了 Prometheus 计数器度量值，记录 +准入 Webhook 的拒绝次数。 度量值的标签给出了 Webhook 拒绝该请求的原因： -幂等的 mutating admission Webhook 能够成功处理已经被它接纳甚或修改的对象。即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。 +幂等的修改性质的准入 Webhook 能够成功处理已经被它接纳甚或修改的对象。 +即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。 #### 幂等 mutating admission Webhook 的示例： -1. 对于 `CREATE` Pod 请求，将 Pod 的字段 `.spec.securityContext.runAsNonRoot` 设置为 true，以实施安全最佳实践。 - -2. 对于 `CREATE` Pod 请求，如果未设置容器的字段 `.spec.containers[].resources.limits`，设置默认资源限制值。 - -3. 对于 `CREATE` pod 请求，如果 Pod 中不存在名为 `foo-sidecar` 的 sidecar 容器，向 Pod 注入一个 `foo-sidecar` 容器。 +1. 对于 `CREATE` Pod 请求，将 Pod 的字段 `.spec.securityContext.runAsNonRoot` + 设置为 true，以实施安全最佳实践。 +2. 对于 `CREATE` Pod 请求，如果未设置容器的字段 + `.spec.containers[].resources.limits`，设置默认资源限制值。 +3. 对于 `CREATE` pod 请求，如果 Pod 中不存在名为 `foo-sidecar` 的边车容器， + 向 Pod 注入一个 `foo-sidecar` 容器。 在上述情况下，可以安全地重新调用 Webhook，或接受已经设置了字段的对象。 @@ -2038,11 +2120,12 @@ In the cases above, the webhook can be safely reinvoked, or admit an object that `foo-sidecar` without looking to see if there is already a `foo-sidecar` container in the pod. --> -1. 对于 `CREATE` pod 请求，注入名称为 `foo-sidecar` 并带有当前时间戳的 sidecar 容器（例如 `foo-sidecar-19700101-000000`）。 - -2. 对于 `CREATE/UPDATE` pod 请求，如果容器已设置标签 `"env"` 则拒绝，否则将 `"env": "prod"` 标签添加到容器。 - -3. 对于 `CREATE` pod 请求，盲目地添加一个名为 `foo-sidecar` 的 sidecar 容器，而未查看 Pod 中是否已经有 `foo-sidecar` 容器。 +1. 对于 `CREATE` pod 请求，注入名称为 `foo-sidecar` 并带有当前时间戳的 + 边车容器（例如 `foo-sidecar-19700101-000000`）。 +2. 对于 `CREATE/UPDATE` pod 请求，如果容器已设置标签 `"env"` 则拒绝， + 否则将 `"env": "prod"` 标签添加到容器。 +3. 对于 `CREATE` pod 请求，盲目地添加一个名为 `foo-sidecar` 的边车容器， + 而未查看 Pod 中是否已经有 `foo-sidecar` 容器。 -在上述第一种情况下，重新调用该 Webhook 可能导致同一个 Sidecar 容器多次注入到 Pod 中，而且每次使用不同的容器名称。 +在上述第一种情况下，重新调用该 Webhook 可能导致同一个 Sidecar 容器 +多次注入到 Pod 中，而且每次使用不同的容器名称。 类似地，如果 Sidecar 已存在于用户提供的 Pod 中，则 Webhook 可能注入重复的容器。 在上述第二种情况下，重新调用 Webhook 将导致 Webhook 自身输出失败。 -在上述第三种情况下，重新调用 Webhook 将导致 Pod 规范中的容器重复，从而使请求无效并被 API 服务器拒绝。 +在上述第三种情况下，重新调用 Webhook 将导致 Pod 规范中的容器重复， +从而使请求无效并被 API 服务器拒绝。 ### 拦截对象的所有版本 -建议通过将 `.webhooks[].matchPolicy` 设置为 `Equivalent`，以确保 admission webhooks 始终拦截对象的所有版本。 -建议 admission webhooks 应该更偏向注册资源的稳定版本。如果无法拦截对象的所有版本，可能会导致准入策略未再某些版本的请求上执行。 +建议通过将 `.webhooks[].matchPolicy` 设置为 `Equivalent`， +以确保准入 Webhooks 始终拦截对象的所有版本。 +建议准入 Webhooks 应该更偏向注册资源的稳定版本。 +如果无法拦截对象的所有版本，可能会导致准入策略未再某些版本的请求上执行。 有关示例，请参见[匹配请求：matchPolicy](#matching-requests-matchpolicy)。 ### 可用性 {#availability} -建议 admission webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。 +建议准入 webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。 建议对 Webhook 使用较小的超时值。有关更多详细信息，请参见[超时](#timeouts)。 建议 Admission Webhook 应该采用某种形式的负载均衡机制，以提供高可用性和高性能。 @@ -2106,13 +2193,16 @@ that a container with name "foo-sidecar" with the expected configuration exists ### 确保看到对象的最终状态 -如果某 Admission Webhook 需要保证自己能够看到对象的最终状态以实施策略，则应该使用一个 validating admission webhook， +如果某准入 Webhook 需要保证自己能够看到对象的最终状态以实施策略， +则应该使用一个验证性质的 webhook， 因为可以通过 mutating Webhook 看到对象后对其进行修改。 -例如，一个 mutating admission webhook 被配置为在每个 `CREATE` Pod 请求中注入一个名称为 "foo-sidecar" 的 sidecar 容器。 +例如，一个修改性质的准入Webhook 被配置为在每个 `CREATE` Pod 请求中 +注入一个名称为 "foo-sidecar" 的 sidecar 容器。 -例如，一个 mutating admission webhook 配置为在每个容器上注入一个名称为`foo-sidecar`的边车容器。如果*必须*存在边车容器， -则还应配置一个 validating admisson webhook 以拦截 `CREATE` Pod 请求，并验证要创建的对象中是否存在具有预期配置的名称为 "foo-sidecar" 的容器。 +如果*必须*存在边车容器，则还应配置一个验证性质的准入 Webhook 以拦截 +`CREATE` Pod 请求，并验证要创建的对象中是否存在具有预期配置的名称为 +"foo-sidecar" 的容器。 ### 避免自托管的 Webhooks 中出现死锁 -如果集群内的 Webhook 配置能够拦截启动其自己的 Pod 所需的资源，则该 Webhook 可能导致其自身部署时发生死锁。 +如果集群内的 Webhook 配置能够拦截启动其自己的 Pod 所需的资源， +则该 Webhook 可能导致其自身部署时发生死锁。 -例如，某 mutating admission webhook 配置为仅当 Pod 中设置了某个标签（例如 `"env": "prod"`）时，才接受 `CREATE` Pod 请求。 -Webhook 服务器在未设置 `"env"` 标签的 Deployment 中运行。当运行 Webhook 服务器的容器的节点运行不正常时，Webhook 部署尝试将容器重新调度到另一个节点。 -但是，由于未设置 `"env"` 标签，因此请求将被现有的 webhook 服务器拒绝，并且调度迁移不会发生。 +例如，某修改性质的准入 Webhook 配置为仅当 Pod 中设置了某个标签 +（例如 `"env": "prod"`）时，才接受 `CREATE` Pod 请求。 +Webhook 服务器在未设置 `"env"` 标签的 Deployment 中运行。当运行 Webhook 服务器的 +容器的节点运行不正常时，Webhook 部署尝试将容器重新调度到另一个节点。 +但是，由于未设置 `"env"` 标签，因此请求将被现有的 Webhook 服务器拒绝，并且调度迁移不会发生。 -建议使用 [namespaceSelector](#matching-requests-namespaceselector) 排除 Webhook 所在的命名空间。 +建议使用 [namespaceSelector](#matching-requests-namespaceselector) 排除 +Webhook 所在的名字空间。 -### Side Effects +### 副作用 {#side-effects} -建议 admission webhook 应尽可能避免副作用，这意味着该 admission webhook 仅对发送给他们的 `AdmissionReview` 的内容起作用，并且不要进行额外更改。 -如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为 `None`。 +建议准入 Webhook 应尽可能避免副作用，这意味着该准入 webhook 仅对发送给他们的 +`AdmissionReview` 的内容起作用，并且不要进行额外更改。 +如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为 +`None`。 -如果在 admission 执行期间存在副作用，则应在处理 `dryRun` 为 `true` 的 `AdmissionReview` 对象时避免产生副作用，并且其 `.webhooks[].sideEffects` 字段应设置为 `NoneOnDryRun`。 有关更多详细信息，请参见[副作用](#side-effects)。 +如果在准入执行期间存在副作用，则应在处理 `dryRun` 为 `true` 的 `AdmissionReview` +对象时避免产生副作用，并且其 `.webhooks[].sideEffects` 字段应设置为 +`NoneOnDryRun`。更多详细信息，请参见[副作用](#side-effects)。 -### 避免对 kube-system 命名空间进行操作 +### 避免对 kube-system 名字空间进行操作 -`kube-system` 命名空间包含由 Kubernetes 系统创建的对象，例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。 -意外更改或拒绝 `kube-system` 命名空间中的请求可能会导致控制平面组件停止运行或者导致未知行为发生。 -如果您的 admission webhook 不想修改 Kubernetes 控制平面的行为，请使用 [`namespaceSelector`](#matching-requests-namespaceselector) 避免拦截 `kube-system` 命名空间。 +`kube-system` 名字空间包含由 Kubernetes 系统创建的对象， +例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。 +意外更改或拒绝 `kube-system` 名字空间中的请求可能会导致控制平面组件 +停止运行或者导致未知行为发生。 +如果你的准入 Webhook 不想修改 Kubernetes 控制平面的行为，请使用 +[`namespaceSelector`](#matching-requests-namespaceselector) 避免 +拦截 `kube-system` 名字空间。 + diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md index 202b798491..7019f6cdc5 100644 --- a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md @@ -518,12 +518,20 @@ Each feature gate is designed for enabling/disabling a specific feature: - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). --> -- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参见[动态卷限制](/zh/docs/concepts/storage/storage-limits/#dynamic-volume-limits)。 -- `BalanceAttachedNodeVolumes`：包括要在调度时进行平衡资源分配的节点上的卷数。scheduler 在决策时会优先考虑 CPU、内存利用率和卷数更近的节点。 -- `BlockVolume`：在 Pod 中启用原始块设备的定义和使用。有关更多详细信息，请参见[原始块卷支持](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 -- `BoundServiceAccountTokenVolume`：迁移 ServiceAccount 卷以使用由 ServiceAccountTokenVolumeProjection 组成的预计卷。有关更多详细信息，请参见 [Service Account Token 卷](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)。 -- `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup 配置卷访问权限和属主变更策略。请参见 [为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。 -- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见 [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。 +- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参见 + [动态卷限制](/zh/docs/concepts/storage/storage-limits/#dynamic-volume-limits)。 +- `BalanceAttachedNodeVolumes`：包括要在调度时进行平衡资源分配的节点上的卷数。 + 调度器在决策时会优先考虑 CPU、内存利用率和卷数更近的节点。 +- `BlockVolume`：在 Pod 中启用原始块设备的定义和使用。有关更多详细信息，请参见 + [原始块卷支持](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 +- `BoundServiceAccountTokenVolume`：迁移 ServiceAccount 卷以使用由 + ServiceAccountTokenVolumeProjection 组成的预计卷。有关更多详细信息，请参见 + [服务账号令牌卷](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)。 +- `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup + 配置卷访问权限和属主变更策略。请参见 + [为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。 +- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见 + [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。 - - `CRIContainerLogRotation`：为 cri 容器运行时启用容器日志轮换。 -- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见 [`csi` 原始块卷支持](/zh/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。 +- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见 + [`csi` 原始块卷支持](/zh/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。 - `CSIDriverRegistry`：在 csi.storage.k8s.io 中启用与 CSIDriver API 对象有关的所有逻辑。 - `CSIInlineVolume`：为 Pod 启用 CSI 内联卷支持。 - `CSIMigration`：确保填充和转换逻辑能够将卷操作从内嵌插件路由到相应的预安装 CSI 插件。 -- `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。如果节点未安装和配置 EBS CSI 插件，则支持回退到内嵌 EBS 插件。这需要启用 CSIMigration 特性标志。 -- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置 EBS CSI 插件。 -- `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 Azure 磁盘内嵌插件路由到 Azure 磁盘 CSI 插件。如果节点未安装和配置 AzureDisk CSI 插件，支持回退到内建 AzureDisk 插件。这需要启用 CSIMigration 特性标志。 -- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志，并在集群中的所有节点上安装和配置 AzureDisk CSI 插件。 -- `CSIMigrationAzureFile`：确保填充和转换逻辑能够将卷操作从 Azure 文件内嵌插件路由到 Azure 文件 CSI 插件。如果节点未安装和配置 AzureFile CSI 插件，支持回退到内嵌 AzureFile 插件。这需要启用 CSIMigration 特性标志。 -- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志，并在集群中的所有节点上安装和配置 AzureFile CSI 插件。 +- `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。 + 如果节点未安装和配置 EBS CSI 插件，则支持回退到内嵌 EBS 插件。 + 这需要启用 CSIMigration 特性标志。 +- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件， + 并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。 + 这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置 + EBS CSI 插件。 +- `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 Azure 磁盘内嵌插件路由到 + Azure 磁盘 CSI 插件。如果节点未安装和配置 AzureDisk CSI 插件， + 支持回退到内建 AzureDisk 插件。这需要启用 CSIMigration 特性标志。 +- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件， + 并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。 + 这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志， + 并在集群中的所有节点上安装和配置 AzureDisk CSI 插件。 +- `CSIMigrationAzureFile`：确保填充和转换逻辑能够将卷操作从 Azure 文件内嵌插件路由到 + Azure 文件 CSI 插件。如果节点未安装和配置 AzureFile CSI 插件， + 支持回退到内嵌 AzureFile 插件。这需要启用 CSIMigration 特性标志。 +- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件， + 并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。 + 这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志， + 并在集群中的所有节点上安装和配置 AzureFile CSI 插件。 - -- `CSIMigrationGCE`：启用 shims 和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。这需要启用 CSIMigration 特性标志。 -- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在集群中的所有节点上安装和配置 PD CSI 插件。 -- `CSIMigrationOpenStack`：确保填充和转换逻辑能够将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。如果节点未安装和配置 Cinder CSI 插件，支持回退到内嵌 Cinder 插件。这需要启用 CSIMigration 特性标志。 -- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件，并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在集群中的所有节点上安装和配置 Cinder CSI 插件。 -- `CSIMigrationvSphere`: 启用 shims 和转换逻辑，将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。如果节点未安装和配置 vSphere CSI 插件，则支持回退到 vSphere 内嵌插件。这需要启用 CSIMigration 特性标志。 -- `CSIMigrationvSphereComplete`: 停止在 kubelet 和卷控制器中注册 vSphere 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。这需要启用 CSIMigration 和 CSIMigrationvSphere 特性标志，并在集群中的所有节点上安装和配置 vSphere CSI 插件。 +- `CSIMigrationGCE`：启用 shims 和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到 + PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。 + 这需要启用 CSIMigration 特性标志。 +- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件， + 并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。 + 这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在集群中的所有节点上 + 安装和配置 PD CSI 插件。 +- `CSIMigrationOpenStack`：确保填充和转换逻辑能够将卷操作从 Cinder 内嵌插件路由到 + Cinder CSI 插件。如果节点未安装和配置 Cinder CSI 插件，支持回退到内嵌 Cinder 插件。 + 这需要启用 CSIMigration 特性标志。 +- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件， + 并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。 + 这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在集群中的所有节点上 + 安装和配置 Cinder CSI 插件。 +- `CSIMigrationvSphere`: 启用 shims 和转换逻辑，将卷操作从 vSphere 内嵌插件路由到 + vSphere CSI 插件。 + 如果节点未安装和配置 vSphere CSI 插件，则支持回退到 vSphere 内嵌插件。 + 这需要启用 CSIMigration 特性标志。 +- `CSIMigrationvSphereComplete`: 停止在 kubelet 和卷控制器中注册 vSphere 内嵌插件， + 并启用 shims 和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。 + 这需要启用 CSIMigration 和 CSIMigrationvSphere 特性标志，并在集群中的所有节点上 + 安装和配置 vSphere CSI 插件。 - `CSINodeInfo`：在 csi.storage.k8s.io 中启用与 CSINodeInfo API 对象有关的所有逻辑。 -- `CSIPersistentVolume`：启用发现和挂载通过 [CSI（容器存储接口）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)兼容卷插件配置的卷。 -- `CSIStorageCapacity`: 使 CSI 驱动程序可以发布存储容量信息，并使 Kubernetes 调度程序在调度 Pod 时使用该信息。 参见 [存储容量](/zh/docs/concepts/storage/storage-capacity/)。 +- `CSIPersistentVolume`：启用发现和挂载通过 + [CSI（容器存储接口）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) + 兼容卷插件配置的卷。 +- `CSIStorageCapacity`: 使 CSI 驱动程序可以发布存储容量信息，并使 Kubernetes + 调度程序在调度 Pod 时使用该信息。参见 + [存储容量](/zh/docs/concepts/storage/storage-capacity/)。 详情请参见 [`csi` 卷类型](/zh/docs/concepts/storage/volumes/#csi)。 -- `CSIVolumeFSGroupPolicy`: 允许 CSIDrivers 使用 `fsGroupPolicy` 字段. 该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。 +- `CSIVolumeFSGroupPolicy`: 允许 CSIDrivers 使用 `fsGroupPolicy` 字段. + 该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。 - - `CustomCPUCFSQuotaPeriod`：使节点能够更改 CPUCFSQuotaPeriod。 -- `CustomPodDNS`：使用其 `dnsConfig` 属性启用 Pod 的自定义 DNS 设置。有关更多详细信息，请参见 [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。 +- `CustomPodDNS`：使用其 `dnsConfig` 属性启用 Pod 的自定义 DNS 设置。 + 更多详细信息，请参见 + [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。 - `CustomResourceDefaulting`：为 OpenAPI v3 验证架构中的默认值启用 CRD 支持。 - `CustomResourcePublishOpenAPI`：启用 CRD OpenAPI 规范的发布。 -- `CustomResourceSubresources`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用 `/status` 和 `/scale` 子资源。 -- `CustomResourceValidation`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用基于模式的验证。 -- `CustomResourceWebhookConversion`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用基于 Webhook 的转换。 +- `CustomResourceSubresources`：对于用 + [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + 创建的资源启用 `/status` 和 `/scale` 子资源。 +- `CustomResourceValidation`：对于用 + [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + 创建的资源启用基于模式的验证。 +- `CustomResourceWebhookConversion`：对于用 + [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + 创建的资源启用基于 Webhook 的转换。 对正在运行的 Pod 进行故障排除。 - -- `DisableAcceleratorUsageMetrics`: [禁用 kubelet 收集加速器指标](/zh/docs/concepts/cluster-administration/system-metrics/). -- `DevicePlugins`：在节点上启用基于 [device-plugins](/zh/docs/concepts/cluster-administration/device-plugins/) 的资源供应。 +- `DisableAcceleratorUsageMetrics`: + [禁用 kubelet 收集加速器指标](/zh/docs/concepts/cluster-administration/system-metrics/). +- `DevicePlugins`：在节点上启用基于 + [设备插件](/zh/docs/concepts/cluster-administration/device-plugins/) 资源供应。 - `DefaultPodTopologySpread`: 启用 `PodTopologySpread` 调度插件来做 [默认的调度传播](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints). -- `DryRun`：启用服务器端 [dry run](/zh/docs/reference/using-api/api-concepts/#dry-run) 请求，以便无需提交即可测试验证、合并和差异化。 +- `DryRun`：启用服务器端 + [dry run](/zh/docs/reference/using-api/api-concepts/#dry-run) 请求， + 以便无需提交即可测试验证、合并和差异化。 - `DynamicAuditing`（ *已弃用* ）：在 v1.19 版本前用于启用动态审计。 -- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅[重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。 -- `DynamicProvisioningScheduling`：扩展默认 scheduler 以了解卷拓扑并处理 PV 配置。此特性已在 v1.12 中完全被 `VolumeScheduling` 特性取代。 -- `DynamicVolumeProvisioning`（ *已弃用* ）：启用持久化卷到 Pod 的[动态预配置](/zh/docs/concepts/storage/dynamic-provisioning/)。 +- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅 + [重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。 +- `DynamicProvisioningScheduling`：扩展默认调度器以了解卷拓扑并处理 PV 配置。 + 此特性已在 v1.12 中完全被 `VolumeScheduling` 特性取代。 +- `DynamicVolumeProvisioning`（ *已弃用* ）：启用持久化卷到 Pod 的 + [动态预配置](/zh/docs/concepts/storage/dynamic-provisioning/)。 - -- `EnableAggregatedDiscoveryTimeout` （ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。 +- `EnableAggregatedDiscoveryTimeout`（ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。 - `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。 -- `EphemeralContainers`：启用添加 {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} 到正在运行的 Pod 的特性。 -- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 -- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅[调整使用中的 PersistentVolumeClaim 的大小](/zh/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。 -- `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅[扩展永久卷声明](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。 -- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。 +- `EphemeralContainers`：启用添加 + {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} + 到正在运行的 Pod 的特性。 +- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 + [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 +- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅 + [调整使用中的 PersistentVolumeClaim 的大小](/zh/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。 +- `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅 + [扩展永久卷声明](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。 +- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于 + [确保其调度](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。 + 从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。 - -- `ExperimentalHostUserNamespaceDefaultingGate`：启用主机默认的用户命名空间。这适用于使用其他主机命名空间、主机安装的容器，或具有特权或使用特定的非命名空间功能（例如MKNODE、SYS_MODULE等）的容器。如果在 Docker 守护程序中启用了用户命名空间重新映射，则启用此选项。 -- `EndpointSlice`：启用 EndpointSlice 以实现更多可扩展的网络端点。需要启用相应的 API 和控制器，请参阅[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。 -- `EndpointSliceProxying`：启用此特性门控后，Linux 上运行的 kube-proxy 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见 - [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。 -- `WindowsEndpointSliceProxying`：启用此特性门控后，Windows 上运行的 kube-proxy 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见 - [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。 +- `ExperimentalHostUserNamespaceDefaultingGate`：启用主机默认的用户名字空间。 + 这适用于使用其他主机名字空间、主机安装的容器，或具有特权或使用特定的非名字空间功能 + （例如 MKNODE、SYS_MODULE 等）的容器。 + 如果在 Docker 守护程序中启用了用户名字空间重新映射，则启用此选项。 +- `EndpointSlice`：启用 EndpointSlice 以实现更多可扩展的网络端点。 + 需要启用相应的 API 和控制器，请参阅 + [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。 +- `EndpointSliceProxying`：启用此特性门控后，Linux 上运行的 kube-proxy 将使用 + EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见 + [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。 +- `WindowsEndpointSliceProxying`：启用此特性门控后，Windows 上运行的 kube-proxy + 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见 + [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。 - `GCERegionalPersistentDisk`：在 GCE 上启用区域 PD 特性。 -- `GenericEphemeralVolume`：启用支持临时卷和内联卷的（可以由第三方存储供应商提供，存储容量跟踪，从快照还原，等等）所有功能。请参见[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。 -- `HugePages`：启用分配和使用预分配的[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。 -- `HugePageStorageMediumSize`：启用支持多种大小的预分配[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。 +- `GenericEphemeralVolume`：启用支持临时卷和内联卷的 + （可以由第三方存储供应商提供、存储容量跟踪、从快照还原等等）所有功能。请参见 + [临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。 +- `HugePages`：启用分配和使用预分配的 + [巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。 +- `HugePageStorageMediumSize`：启用支持多种大小的预分配 + [巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。 - -- `HyperVContainer`：为 Windows 容器启用[Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。 -- `HPAScaleToZero`：使用自定义指标或外部指标时，可将 `HorizontalPodAutoscaler` 资源的 `minReplicas` 设置为 0。 -- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的，以提高安全性和性能。 -- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。有关更多详细信息，请参见[通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。 -- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现插件，例如 [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)。 -- `KubeletPodResources`：启用 kubelet 的 pod 资源 grpc 端点。有关更多详细信息，请参见[支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。 -- `LegacyNodeRoleBehavior`：禁用此选项后，服务负载均衡中的传统行为和节点中断将忽略 `node-role.kubernetes.io/master` 标签，而使用 `NodeDisruptionExclusion` 和 `ServiceNodeExclusion` 提供的特性指定的标签。 +- `HyperVContainer`：为 Windows 容器启用 + [Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。 +- `HPAScaleToZero`：使用自定义指标或外部指标时，可将 `HorizontalPodAutoscaler` + 资源的 `minReplicas` 设置为 0。 +- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的， + 以提高安全性和性能。 +- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。 + 有关更多详细信息，请参见 + [通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。 +- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现插件， + 例如 [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)。 +- `KubeletPodResources`：启用 kubelet 的 pod 资源 grpc 端点。更多详细信息，请参见 + [支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。 +- `LegacyNodeRoleBehavior`：禁用此选项后，服务负载均衡中的传统行为和节点中断将忽略 + `node-role.kubernetes.io/master` 标签，而使用 `NodeDisruptionExclusion` 和 + `ServiceNodeExclusion` 提供的特性指定的标签。 - -- `LocalStorageCapacityIsolation`：允许使用[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)以及 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。 -- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)启用了 `LocalStorageCapacityIsolation`，并且 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的后备文件系统支持项目配额，并且启用了这些配额，请使用项目配额来监视 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗而不是遍历文件系统，以此获得更好的性能和准确性。 +- `LocalStorageCapacityIsolation`：允许使用 + [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)以及 + [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。 +- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果 + [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/) + 启用了 `LocalStorageCapacityIsolation`，并且 + [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) + 的后备文件系统支持项目配额，并且启用了这些配额，请使用项目配额来监视 + [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗 + 而不是遍历文件系统，以此获得更好的性能和准确性。 - `MountContainers`：在主机上启用将应用程序容器用作卷安装程序。 -- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。有关更多详细信息，请参见[挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。 -- `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`，以防止在区域故障期间驱逐节点。 +- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。 + 更多详细信息，请参见 + [挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。 +- `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`， + 以防止在区域故障期间驱逐节点。 - - `NodeLease`：启用新的租赁 API 以报告节点心跳，可用作节点运行状况信号。 - `NonPreemptingPriority`：为 PriorityClass 和 Pod 启用 NonPreempting 选项。 -- `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。如果请求 “本地” 卷，则必须指定 Pod 亲和力。 -- `PodDisruptionBudget`：启用 [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 特性。 -- `PodOverhead`：启用 [PodOverhead](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 特性以考虑 Pod 开销。 -- `PodPriority`：根据[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。 -- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。 +- `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。 + 如果请求 “本地” 卷，则必须指定 Pod 亲和力。 +- `PodDisruptionBudget`：启用 + [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 特性。 +- `PodOverhead`：启用 [PodOverhead](/zh/docs/concepts/scheduling-eviction/pod-overhead/) + 特性以考虑 Pod 开销。 +- `PodPriority`：根据[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) + 启用 Pod 的调度和抢占。 +- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。 + 有关更多详细信息，请参见 + [Pod 就绪状态判别](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。 - `PodShareProcessNamespace`：在 Pod 中启用 `shareProcessNamespace` 的设置， - 以便在 Pod 中运行的容器之间共享同一进程命名空间。更多详细信息，请参见[在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。 + 以便在 Pod 中运行的容器之间共享同一进程名字空间。更多详细信息，请参见 + [在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。 - `ProcMountType`：启用对容器的 ProcMountType 的控制。 -- `PVCProtection`：启用防止任何 Pod 仍使用 PersistentVolumeClaim(PVC) 删除的特性。可以在[此处](/zh/docs/tasks/administer-cluster/storage-object-in-use-protection/)中找到更多详细信息。 -- `QOSReserved`：允许在 QoS 级别进行资源预留，以防止处于较低 QoS 级别的 Pod 突发进入处于较高 QoS 级别的请求资源（仅适用于内存）。 -- `ResourceLimitsPriorityFunction` （ *已弃用* ）：启用某调度器优先级函数，该函数将最低得分 1 -指派给至少满足输入 Pod 的 cpu 和内存限制之一的节点，目的是打破得分相同的节点之间的关联。 +- `PVCProtection`：启用防止任何 Pod 仍使用 PersistentVolumeClaim(PVC) 删除的特性。 +- `QOSReserved`：允许在 QoS 级别进行资源预留，以防止处于较低 QoS 级别的 Pod + 突发进入处于较高 QoS 级别的请求资源（仅适用于内存）。 +- `ResourceLimitsPriorityFunction` （ *已弃用* ）：启用某调度器优先级函数， + 该函数将最低得分 1 指派给至少满足输入 Pod 的 CPU 和内存限制之一的节点， + 目的是打破得分相同的节点之间的关联。 + - - `ResourceQuotaScopeSelectors`：启用资源配额范围选择器。 -- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。 -- `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。 +- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。 + 更多详细信息，请参见 + [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。 +- `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。 + 更多详细信息，请参见 + [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。 - `RunAsGroup`：启用对容器初始化过程中设置的主要组 ID 的控制。 -- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 特性用于选择容器运行时配置。 -- `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是 DaemonSet 控制器进行调度。 +- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) + 特性用于选择容器运行时配置。 +- `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是 + DaemonSet 控制器进行调度。 - -- `SCTPSupport`：在 Service、Endpoints、NetworkPolicy 和 Pod 定义中，允许将 _SCTP_ 用作 `protocol` 值。 -- `ServerSideApply`：在 API 服务器上启用[服务器端应用（SSA）](/zh/docs/reference/using-api/server-side-apply/) 路径。 +- `SCTPSupport`：在 Service、Endpoints、NetworkPolicy 和 Pod 定义中， + 允许将 _SCTP_ 用作 `protocol` 值。 +- `ServerSideApply`：在 API 服务器上启用 + [服务器端应用（SSA）](/zh/docs/reference/using-api/server-side-apply/) 路径。 - `ServiceAccountIssuerDiscovery`：在 API 服务器中为服务帐户颁发者启用 OIDC 发现端点。 - 颁发者和 JWKS URL）。 详情请参见[为 Pod 配置服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) 。 + 颁发者和 JWKS URL）。详情请参见 + [为 Pod 配置服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) 。 - `ServiceAppProtocol`：为 Service 和 Endpoints 启用 `AppProtocol` 字段。 - `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器保护。 -- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，则可以排除节点。 -- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见 [Service 拓扑](/zh/docs/concepts/services-networking/service-topology/)。 -- `SetHostnameAsFQDN`：启用将全限定域名 （FQDN）设置为 Pod 主机名的功能。请参见[给 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。 -- `StartupProbe`：在 kubelet 中启用 [startup](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。 -- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 PersistentVolumeClaim 对象，则将其推迟。 +- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。 + 如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` + 键或 `node.kubernetes.io/exclude-from-external-load-balancers`， + 则可以排除节点。 +- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。 + 有关更多详细信息，请参见 + [服务拓扑](/zh/docs/concepts/services-networking/service-topology/)。 +- `SetHostnameAsFQDN`：启用将全限定域名（FQDN）设置为 Pod 主机名的功能。 + 请参见[给 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。 +- `StartupProbe`：在 kubelet 中启用 + [启动探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)。 +- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 + PersistentVolumeClaim 对象，则将其推迟。 - - `StorageVersionHash`：允许 apiserver 在发现中公开存储版本的哈希值。 -- `StreamingProxyRedirects`：指示 API 服务器拦截（并遵循）从后端（kubelet）进行重定向以处理流请求。流请求的例子包括 `exec`、`attach` 和 `port-forward` 请求。 -- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。有关更多详细信息，请参见[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。 +- `StreamingProxyRedirects`：指示 API 服务器拦截（并遵循）从后端（kubelet） + 进行重定向以处理流请求。 + 流请求的例子包括 `exec`、`attach` 和 `port-forward` 请求。 +- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。更多详细信息，请参见 + [服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。 - `SupportPodPidsLimit`：启用支持限制 Pod 中的进程 PID。 -- `Sysctls`：启用对可以为每个 Pod 设置的命名空间内核参数（sysctls）的支持。有关更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。 +- `Sysctls`：启用对可以为每个 Pod 设置的名字空间内核参数（sysctls）的支持。 + 更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。 - -- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。有关更多详细信息，请参见[污点和容忍度](/zh/docs/concepts/configuration/taint-and-toleration/)。 -- `TaintNodesByCondition`：根据[节点条件](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)启用自动在节点标记污点。 +- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。 + 有关更多详细信息，请参见[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +- `TaintNodesByCondition`：根据[节点状况](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) + 启用自动在节点标记污点。 - `TokenRequest`：在服务帐户资源上启用 `TokenRequest` 端点。 -- `TokenRequestProjection`：启用通过 [`projected` 卷](/zh/docs/concepts/storage/volumes/#projected) 将服务帐户令牌注入到 Pod 中的特性。 -- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。 -- `TTLAfterFinished`：完成执行后，允许 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。 +- `TokenRequestProjection`：启用通过 + [`projected` 卷](/zh/docs/concepts/storage/volumes/#projected) + 将服务帐号令牌注入到 Pod 中的特性。 +- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。 + 详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。 +- `TTLAfterFinished`：完成执行后，允许 + [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。 - - `VolumePVCDataSource`：启用对将现有 PVC 指定数据源的支持。 -- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）绑定调度决策；当与 PersistentLocalVolumes 特性门控一起使用时，还可以使用 `PersistentLocalVolumes` 卷类型。 +- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC） + 绑定调度决策；当与 PersistentLocalVolumes 特性门控一起使用时， + 还可以使用 `PersistentLocalVolumes` 卷类型。 - `VolumeSnapshotDataSource`：启用卷快照数据源支持。 - - `VolumeSubpathEnvExpansion`：启用 `subPathExpr` 字段用于将环境变量扩展为 `subPath`。 - `WatchBookmark`：启用对监测 bookmark 事件的支持。 - `WindowsGMSA`：允许将 GMSA 凭据规范从 Pod 传递到容器运行时。 @@ -870,15 +992,13 @@ Each feature gate is designed for enabling/disabling a specific feature: - `WinDSR`：允许 kube-proxy 为 Windows 创建 DSR 负载均衡。 - `WinOverlay`：允许 kube-proxy 在 Windows 的 overlay 模式下运行。 - ## {{% heading "whatsnext" %}} - -* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 介绍了项目已移除的特性部件和组件的方法。 - +* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/) + 介绍了项目已移除的特性部件和组件的方法。 diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md index 9e629ae6ef..4cd4dfb7c2 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md +++ b/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md @@ -28,7 +28,7 @@ This document describes how to authenticate and authorize access to the kubelet' -## Kubelet 认证 +## Kubelet 身份认证 * 带 `--client-ca-file` 标志启动 kubelet，提供一个 CA 证书包以供验证客户端证书 * 带 `--kubelet-client-certificate` 和 `--kubelet-client-key` 标志启动 apiserver -* 有关更多详细信息，请参见 [apiserver 身份验证文档](/zh/docs/admin/authentication/#x509-client-certs) +* 有关更多详细信息，请参见 + [apiserver 身份验证文档](/zh/docs/reference/access-authn-authz/authentication/#x509-client-certs) * 确保在 API 服务器中启用了 `authorization.k8s.io/v1beta1` API 组 * 带 `--authorization-mode=Webhook` 和 `--kubeconfig` 标志启动 kubelet -* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，以确定每个请求是否得到鉴权 +* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API， + 以确定每个请求是否得到鉴权 -kubelet 使用与 apiserver 相同的[请求属性](/zh/docs/admin/authorization/#request-attributes)方法对 API 请求执行鉴权。 +kubelet 使用与 apiserver 相同的 +[请求属性](/zh/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) +方法对 API 请求执行鉴权。 + + 扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。 @@ -36,5 +36,5 @@ Most cluster administrators will use a hosted or distribution instance of Kubern --> 大多数集群管理员会使用托管的 Kubernetes 或其某种发行包。因此，大多数 Kubernetes 用户将需要 -安装 [扩展组件](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， -较少用户会需要编写新的扩展组件。 \ No newline at end of file +安装[扩展组件](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， +较少用户会需要编写新的扩展组件。 diff --git a/content/zh/docs/reference/glossary/flexvolume.md b/content/zh/docs/reference/glossary/flexvolume.md index 51b0690392..df657c62ca 100644 --- a/content/zh/docs/reference/glossary/flexvolume.md +++ b/content/zh/docs/reference/glossary/flexvolume.md @@ -4,31 +4,32 @@ id: flexvolume date: 2018-06-25 full_link: /zh/docs/concepts/storage/volumes/#flexvolume short_description: > - Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolumes 的一些问题。 - + Flexvolume 是创建树外卷插件的一种接口。 + {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} + 是比 Flexvolume 更新的接口，它解决了 Flexvolumes 的一些问题。 aka: tags: - storage --- - - - Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。 +--> + +Flexvolume 是创建树外卷插件的一种接口。 +{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} +是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。 @@ -37,7 +38,8 @@ FlexVolumes enable users to write their own drivers and add support for their vo --> Flexvolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。 FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。 -这需要 root 权限。如果可能的话，SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序， +这需要 root 权限。如果可能的话，SIG Storage 建议实现 +{{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序， 因为它解决了 Flexvolumes 的限制。 -* [Kubernetes 文档中的 Flexvolume](/docs/concepts/storage/volumes/#flexvolume) +* [Kubernetes 文档中的 Flexvolume](/zh/docs/concepts/storage/volumes/#flexvolume) * [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) -* [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) \ No newline at end of file +* [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) diff --git a/content/zh/docs/reference/glossary/managed-service.md b/content/zh/docs/reference/glossary/managed-service.md index fb7d5440c9..3e04e50b60 100644 --- a/content/zh/docs/reference/glossary/managed-service.md +++ b/content/zh/docs/reference/glossary/managed-service.md @@ -27,7 +27,6 @@ tags: - 由第三方供应商负责维护的一种软件产品。 @@ -35,8 +34,9 @@ tags: - 托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等， 不过它们也可以是可以被某应用使用的任何软件交付件。 -[服务目录](/docs/concepts/service-catalog/)提供了一种方法用来列举、供应和绑定到 -{{< glossary_tooltip text="服务代理商" term_id="service-broker" >}}所提供的托管服务。 +[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) +提供了一种方法用来列举、制备和绑定到 +{{< glossary_tooltip text="服务代理商" term_id="service-broker" >}} +所提供的托管服务。 diff --git a/content/zh/docs/reference/glossary/operator-pattern.md b/content/zh/docs/reference/glossary/operator-pattern.md index e4b47f68c7..033383a111 100644 --- a/content/zh/docs/reference/glossary/operator-pattern.md +++ b/content/zh/docs/reference/glossary/operator-pattern.md @@ -10,10 +10,8 @@ aka: tags: - architecture --- - [operator 模式](/docs/concepts/extend-kubernetes/operator/) 是一个系统设计, 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 + - +[operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, +将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 +除了使用作为 Kubernetes 自身一部分的内置控制器之外，你还可以通过 +将控制器添加到集群中来扩展 Kubernetes。 -除了使用作为 Kubernetes 自身一部分的内置控制器之外，您还可以通过将控制器添加到集群中来扩展 Kubernetes。 +如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控 +那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。 -如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/platform-developer.md b/content/zh/docs/reference/glossary/platform-developer.md index d18ad680b7..0f533b170c 100644 --- a/content/zh/docs/reference/glossary/platform-developer.md +++ b/content/zh/docs/reference/glossary/platform-developer.md @@ -42,7 +42,7 @@ Others develop closed-source commercial or site-specific extensions. --> 平台开发人员可以使用[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/api-extension/apiserver-aggregation/) +或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。 一些平台开发人员也是 Kubrenetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}， 他们会开发贡献给 Kubernetes 社区的扩展。 diff --git a/content/zh/docs/reference/glossary/pod-lifecycle.md b/content/zh/docs/reference/glossary/pod-lifecycle.md index 8d313b7cf0..4d68d78030 100644 --- a/content/zh/docs/reference/glossary/pod-lifecycle.md +++ b/content/zh/docs/reference/glossary/pod-lifecycle.md @@ -2,7 +2,7 @@ title: Pod 生命周期 id: pod-lifecycle date: 2019-02-17 -full-link: /docs/concepts/workloads/pods/pod-lifecycle/ +full-link: /zh/docs/concepts/workloads/pods/pod-lifecycle/ related: - pod - container @@ -13,7 +13,6 @@ short_description: > --- - - 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 +关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 -[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。 +[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod +在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、 +Failed、Unknown、Completed 或 CrashLoopBackOff。 diff --git a/content/zh/docs/reference/issues-security/issues.md b/content/zh/docs/reference/issues-security/issues.md index e43fa3d0e6..d2ac9ae7be 100644 --- a/content/zh/docs/reference/issues-security/issues.md +++ b/content/zh/docs/reference/issues-security/issues.md @@ -5,22 +5,22 @@ aliases: [cve/,cves/] --- -要报告安全问题，请遵循 [Kubernetes 安全问题公开流程](/docs/reference/issues-security/security/#report-a-vulnerability)。 +要报告安全问题，请遵循 +[Kubernetes 安全问题公开流程](/zh/docs/reference/issues-security/security/#report-a-vulnerability)。 -使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 跟踪 Kubernetes 编码工作和公开问题。 +使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) +跟踪 Kubernetes 编码工作和公开问题。 -与安全性相关的公告请发送到 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 邮件列表。 +与安全性相关的公告请发送到 +[kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) +邮件列表。 diff --git a/content/zh/docs/reference/kubectl/overview.md b/content/zh/docs/reference/kubectl/overview.md index 4f4125e26a..aa3d13cdc6 100644 --- a/content/zh/docs/reference/kubectl/overview.md +++ b/content/zh/docs/reference/kubectl/overview.md @@ -9,7 +9,6 @@ card: weight: 20 --- @@ -33,7 +31,8 @@ files by setting the KUBECONFIG environment variable or by setting the --> 你可以使用 Kubectl 命令行工具管理 Kubernetes 集群。 `kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 -你可以通过设置 KUBECONFIG 环境变量或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +你可以通过设置 KUBECONFIG 环境变量或设置 +[`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 - ## 语法 - * `command`：指定要对一个或多个资源执行的操作，例如 `create`、`get`、`describe`、`delete`。 -* `TYPE`：指定[资源类型](#resource-types)。资源类型不区分大小写，可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果: +* `TYPE`：指定[资源类型](#resource-types)。资源类型不区分大小写， + 可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果: - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` -* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。 +* `NAME`：指定资源的名称。名称区分大小写。 + 如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。 在对多个资源执行操作时，你可以按类型和名称指定每个资源，或指定一个或多个文件： - + * 要按类型和名称指定资源： -* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
+ * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。 + + 例子：`kubectl get pod example-pod1 example-pod2` + + * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。 + + 例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1` + + * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` + + * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-configuration-tips) + 因为 YAML 更容易使用，特别是用于配置文件时。 + 例子：`kubectl get -f ./pod.yaml` + + - - * 要按类型和名称指定资源： - - * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。
- 例子：`kubectl get pod example-pod1 example-pod2` - - * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。
- 例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1` - - * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` - - * [使用 YAML 而不是 JSON](/docs/concepts/configuration/overview/#general-configuration-tips) 因为 YAML 更容易使用，特别是用于配置文件时。
- 例子：`kubectl get -f ./pod.yaml` - -* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 Kubernetes API 服务器的地址和端口。
+* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 + Kubernetes API 服务器的地址和端口。 {{< caution >}} - @@ -145,7 +146,6 @@ If you need help, just run `kubectl help` from the terminal window. - ## 操作 {{< caution >}} @@ -20,7 +19,8 @@ weight: 90 `kubeadm alpha` provides a preview of a set of features made available for gathering feedback from the community. Please try it out and give us feedback! --> - `kubeadm alpha` 提供了一组可用于收集社区反馈的功能的预览。请尝试一下这些功能并给我们反馈！ +`kubeadm alpha` 提供了一组可用于收集社区反馈的功能的预览。 +请尝试一下这些功能并给我们反馈！ {{< /caution >}} ## kubeadm alpha certs {#cmd-certs} @@ -32,7 +32,6 @@ Kubernetes 证书的操作集合。 {{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} {{< /tabs >}} - ## kubeadm alpha certs renew {#cmd-certs-renew} 此命令检查 kubeadm 管理的本地 PKI 中证书的到期时间。 -有关证书到期和续订的更多详细信息，请参见[证书管理文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 +有关证书到期和续订的更多详细信息，请参见 +[证书管理文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 {{< tabs name="tab-certs-check-expiration" >}} {{< tab name="check-expiration" include="generated/kubeadm_alpha_certs_check-expiration.md" />}} @@ -128,7 +128,9 @@ Use the following command to enable the DynamicKubeletConfiguration feature. -子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。有关 `pivot` 更多信息，请参见[文档](zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。 +子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。 +有关 `pivot` 更多信息，请参见 +[文档](/zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。 -`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 +`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。 +因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 -`kubeadm join phase` 与 [kubeadm join 工作流程](/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow) 一致，后台都使用相同的代码。 +`kubeadm join phase` 与 +[kubeadm join 工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow) +一致，后台都使用相同的代码。 ## kubeadm join phase {#cmd-join-phase} @@ -89,7 +91,11 @@ Using this phase you can join a node as a control-plane instance. * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality --> -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改 -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) + 引导 Kubernetes 控制平面节点 +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) + 将节点添加到集群 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) + 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改 +* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) + 尝试实验性功能 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md index 74a5118599..8d0f84af56 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md @@ -3,12 +3,11 @@ title: kubeadm reset phase content_type: concept weight: 90 --- + -`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 +`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。 +因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 -`kubeadm reset phase` 与 [kubeadm reset 工作流程](/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow) 一致，后台都使用相同的代码。 +`kubeadm reset phase` 与 +[kubeadm reset 工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow) +一致，后台都使用相同的代码。 ## kubeadm reset phase {#cmd-reset-phase} @@ -91,7 +93,11 @@ Using this phase you can perform cleanup on this node. * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality --> -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改 -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) + 引导 Kubernetes 控制平面节点 +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) + 将节点添加到集群 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) + 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改 +* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) + 尝试实验性功能 diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md index eb348c89ce..b1cc69d433 100644 --- a/content/zh/docs/reference/tools.md +++ b/content/zh/docs/reference/tools.md @@ -6,37 +6,35 @@ content_type: concept --- - - Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernetes 系统。 - ## Kubectl -[`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。 +[`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具， +可以用来操控 Kubernetes 集群。 ## Kubeadm -[`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。 +[`kubeadm`](/zh/docs/tasks/tools/install-kubeadm/) 是一个命令行工具， +可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段） +上轻松部署一个安全可靠的 Kubernetes 集群。 ## Minikube @@ -45,8 +43,8 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet easy to run a single-node Kubernetes cluster locally on your workstation for development and testing purposes. --> -[`minikube`](https://minikube.sigs.k8s.io/docs/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。 - +[`minikube`](https://minikube.sigs.k8s.io/docs/) 是一个可以方便用户 +在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。 ## Dashboard @@ -54,7 +52,9 @@ development and testing purposes. [`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. --> -[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。 +[`Dashboard`](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) +是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes +集群，进行故障排查以及管理集群和集群资源。 ## Helm @@ -62,7 +62,9 @@ to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resou [`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured Kubernetes resources, aka Kubernetes charts. --> -[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理预先配置 Kubernetes 资源包的工具，这里的资源在 Helm 中也被称作 Kubernetes charts。 +[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理 +预先配置完毕的 Kubernetes 资源包的工具，这里的资源在 Helm 中也被称作 +Kubernetes charts。 -[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。 +[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具， +用来帮助 Docker Compose 用户迁移至 Kubernetes。 {{< caution >}} 并非所有的自愿干扰都会受到 Pod 干扰预算的限制。 -例如，删除 Peployment 或 Pod 的删除操作就会跳过 Pod 干扰预算检查。 +例如，删除 Deployment 或 Pod 的删除操作就会跳过 Pod 干扰预算检查。 {{< /caution >}} + + + + +在很多组织中，其服务和应用的很大比例是 Windows 应用。 +[Windows 容器](https://aka.ms/windowscontainers)提供了一种对进程和包依赖关系 +进行封装的现代方式，这使得用户更容易采用 DevOps 实践，令 Windows 应用同样遵从 +云原生模式。 +Kubernetes 已经成为事实上的标准容器编排器，Kubernetes 1.14 发行版本中包含了将 +Windows 容器调度到 Kubernetes 集群中 Windows 节点上的生产级支持，从而使得巨大 +的 Windows 应用生态圈能够充分利用 Kubernetes 的能力。 +对于同时投入基于 Windows 应用和 Linux 应用的组织而言，他们不必寻找不同的编排系统 +来管理其工作负载，其跨部署的运维效率得以大幅提升，而不必关心所用操作系统。 + + + + +## kubernetes 中的 Windows 容器 {#windows-containers-in-kubernetes} + +若要在 Kubernetes 中启用对 Windows 容器的编排，只需在现有的 Linux 集群中 +包含 Windows 节点。在 Kubernetes 上调度 {{< glossary_tooltip text="Pods" term_id="pod" >}} +中的 Windows 容器与调用基于 Linux 的容器一样简单、一样容易。 + + +为了运行 Windows 容器，你的 Kubernetes 集群必须包含多个操作系统，控制面 +节点运行 Linux，工作节点则可以根据负载需要运行 Windows 或 Linux。 +Windows Server 2019 是唯一被支持的 Windows 操作系统，在 Windows 上启用 +[Kubernetes 节点](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) +支持（包括 kubelet, [容器运行时](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、 +以及 kube-proxy）。关于 Windows 发行版渠道的详细讨论，可参见 +[Microsoft 文档](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)。 + + +{{< note >}} +Kubernetes 控制面，包括[主控组件](/zh/docs/concepts/overview/components/)，继续 +在 Linux 上运行。目前没有支持完全是 Windows 节点的 Kubernetes 集群的计划。 +{{< /note >}} + + +{{< note >}} +在本文中，当我们讨论 Windows 容器时，我们所指的是具有进程隔离能力的 Windows +容器。具有 [Hyper-V 隔离能力](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) +的 Windows 容器计划在将来发行版本中推出。 +{{< /note >}} + + +## 支持的功能与局限性 {#supported-functionality-and-limitations} + +### 支持的功能 {#supported-functionality} + +#### Windows 操作系统版本支持 {#windows-os-version-support} + +参考下面的表格，了解 Kubernetes 中支持的 Windows 操作系统。 +同一个异构的 Kubernetes 集群中可以同时包含 Windows 和 Linux 工作节点。 +Windows 容器仅能调度到 Windows 节点，Linux 容器则只能调度到 Linux 节点。 + +| Kubernetes 版本 | Windows Server LTSC 版本 | Windows Server SAC 版本 | +| --- | --- | --- | --- | +| *Kubernetes v1.14* | Windows Server 2019 | Windows Server ver 1809 | +| *Kubernetes v1.15* | Windows Server 2019 | Windows Server ver 1809 | +| *Kubernetes v1.16* | Windows Server 2019 | Windows Server ver 1809 | +| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 | +| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 | +| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | + + +关于不同的 Windows Server 版本的服务渠道，包括其支持模式等相关信息可以在 +[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19) +找到。 + + +我们并不指望所有 Windows 客户都为其应用频繁地更新操作系统。 +对应用的更新是向集群中引入新代码的根本原因。 +对于想要更新运行于 Kubernetes 之上的容器中操作系统的客户，我们会在添加对新 +操作系统版本的支持时提供指南和分步的操作指令。 +该指南会包含与集群节点一起来升级用户应用的建议升级步骤。 +Windows 节点遵从 Kubernetes +[版本偏差策略](/zh/docs/setup/release/version-skew-policy/)（节点到控制面的 +版本控制），与 Linux 节点的现行策略相同。 + +Windows Server 主机操作系统会受 [Windows Server](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) +授权策略控制。Windows 容器镜像则遵从 +[Windows 容器的补充授权条款](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula) +约定。 + +带进程隔离的 Windows 容器受一些严格的兼容性规则约束， +[其中宿主 OS 版本必须与容器基准镜像的 OS 版本相同](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility)。 +一旦我们在 Kubernetes 中支持带 Hyper-V 隔离的 Windows 容器， +这一约束和兼容性规则也会发生改变。 + + +#### 计算 {#compute} + +从 API 和 kubectl 的角度，Windows 容器的表现在很大程度上与基于 Linux 的容器 +是相同的。不过也有一些与关键功能相关的差别值得注意，这些差别列举于 +[局限性](#limitations)小节中。 + + +关键性的 Kubernetes 元素在 Windows 下与其在 Linux 下工作方式相同。我们在本节中 +讨论一些关键性的负载支撑组件及其在 Windows 中的映射。 + +* [Pods](/zh/docs/concepts/workloads/pods/) + + + Pod 是 Kubernetes 中最基本的构造模块，是 Kubernetes 对象模型中你可以创建或部署的 + 最小、最简单元。你不可以在同一 Pod 中部署 Windows 和 Linux 容器。 + Pod 中的所有容器都会被调度到同一节点（Node），而每个节点代表的是一种特定的平台 + 和体系结构。Windows 容器支持 Pod 的以下能力、属性和事件： + + + * 在带进程隔离和卷共享支持的 Pod 中运行一个或多个容器 + * Pod 状态字段 + * 就绪态（Readiness）和活跃性（Liveness）探针 + * postStart 和 preStop 容器生命周期事件 + * ConfigMap、Secrets：用作环境变量或卷 + * emptyDir 卷 + * 从宿主系统挂载命名管道 + * 资源限制 + +* [控制器（Controllers）](/zh/docs/concepts/workloads/controllers/) + + + Kubernetes 控制器处理 Pod 的期望状态。Windows 容器支持以下负载控制器： + + * ReplicaSet + * ReplicationController + * Deployment + * StatefulSet + * DaemonSet + * Job + * CronJob + +* [服务（Services）](/zh/docs/concepts/services-networking/service/) + + + Kubernetes Service 是一种抽象对象，用来定义 Pod 的一个逻辑集合及用来访问这些 + Pod 的策略。Service 有时也称作微服务（Micro-service）。你可以使用服务来实现 + 跨操作系统的连接。在 Windows 系统中，服务可以使用下面的类型、属性和能力： + + * Service 环境变量 + * NodePort + * ClusterIP + * LoadBalancer + * ExternalName + * 无头（Headless）服务 + + +Pods、控制器和服务是在 Kubernetes 上管理 Windows 负载的关键元素。 +不过，在一个动态的云原生环境中，这些元素本身还不足以用来正确管理 +Windows 负载的生命周期。我们为此添加了如下功能特性： + +* Pod 和容器的度量（Metrics） +* 对水平 Pod 自动扩展的支持 +* 对 kubectl exec 命令的支持 +* 资源配额 +* 调度器抢占 + + +#### 容器运行时 {#container-runtime} + +##### Docker EE + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + + +Docker EE-basic 19.03+ 是建议所有 Windows Server 版本采用的容器运行时。 +该容器运行时能够与 kubelet 中的 dockershim 代码协同工作。 + +##### CRI-ContainerD + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + + +{{< caution >}} +在 ContainerD 上使用 GMSA 访问 Windows 网络共享资源时，有一个 +[已知的局限](/zh/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)， +需要内核补丁来解决。 +你可以在关注 [Microsoft Windows Containers 问题跟踪](https://github.com/microsoft/Windows-Containers/issues/44) +来跟进相关的更新。 +{{< /caution >}} + + +{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0-beta.2+ +也可在 Windows Kubernetes 节点上用作容器运行时。 + + +在 Windows 对 ContainerD 的最初支持是在 Kubernetes v1.18 加入的。 +Windows 上 ContainerD 的进展可以在 +[enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001) +跟进。 + +你可以进一步了解如何[在 Windows 上安装 ContainerD](/zh/docs/setup/production-environment/container-runtimes/#install-containerd). + + +#### 持久性存储 {#persistent-storage} + +使用 Kubernetes [卷](/zh/docs/concepts/storage/volumes/)，对数据持久性和 Pod 卷 +共享有需求的复杂应用也可以部署到 Kubernetes 上。 +管理与特定存储后端或协议相关的持久卷时，相关的操作包括：对卷的配备（Provisioning）、 +去配（De-provisioning）和调整大小，将卷挂接到 Kubernetes 节点或从节点上解除挂接， +将卷挂载到需要持久数据的 Pod 中的某容器或从容器上卸载。 +负责实现为特定存储后端或协议实现卷管理动作的代码以 Kubernetes 卷 +[插件](/zh/docs/concepts/storage/volumes/#types-of-volumes)的形式发布。 +Windows 支持以下大类的 Kubernetes 卷插件： + + +##### 树内卷插件 {#in-tree-volume-plugins} + +与树内卷插件（In-Tree Volume Plugin）相关的代码都作为核心 Kubernetes 代码基 +的一部分发布。树内卷插件的部署不需要安装额外的脚本，也不需要额外部署独立的 +容器化插件组件。这些插件可以处理：对应存储后端上存储卷的配备、去配和尺寸更改， +将卷挂接到 Kubernetes 或从其上解挂，以及将卷挂载到 Pod 中各个容器上或从其上 +卸载。以下树内插件支持 Windows 节点： + +* [awsElasticBlockStore](/zh/docs/concepts/storage/volumes/#awselasticblockstore) +* [azureDisk](/zh/docs/concepts/storage/volumes/#azuredisk) +* [azureFile](/zh/docs/concepts/storage/volumes/#azurefile) +* [gcePersistentDisk](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) +* [vsphereVolume](/zh/docs/concepts/storage/volumes/#vspherevolume) + + +##### FlexVolume 插件 {#flexvolume-plugins} + +与 [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) 插件相关的代码是作为 +树外（Out-of-tree）脚本或可执行文件来发布的，因此需要在宿主系统上直接部署。 +FlexVolume 插件处理将卷挂接到 Kubernetes 节点或从其上解挂、将卷挂载到 Pod 中 +各个容器上或从其上卸载等操作。对于与 FlexVolume 插件相关联的持久卷的配备和 +去配操作，可以通过外部的配置程序来处理。这类配置程序通常与 FlexVolume 插件 +相分离。下面的 FlexVolume +[插件](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) +可以以 PowerShell 脚本的形式部署到宿主系统上，支持 Windows 节点： + +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) + + +##### CSI 插件 {#csi-plugins} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + + +与 {{< glossary_tooltip text="CSI" term_id="csi" >}} 插件相关联的代码作为 +树外脚本和可执行文件来发布且通常发布为容器镜像形式，并使用 DaemonSet 和 +StatefulSet 这类标准的 Kubernetes 构造体来部署。 +CSI 插件处理 Kubernetes 中的很多卷管理操作：对卷的配备、去配和调整大小， +将卷挂接到 Kubernetes 节点或从节点上解除挂接，将卷挂载到需要持久数据的 Pod +中的某容器或从容器上卸载，使用快照和克隆来备份或恢复持久数据。 +CSI 插件通常包含节点插件（以 DaemonSet 形式运行于各节点上）和控制器插件。 + + +CSI 节点插件（尤其是那些通过块设备或者共享文件系统形式来提供持久卷的插件） +需要执行很多特权级操作，例如扫描磁盘设备、挂载文件系统等等。 +这些操作在不同的宿主操作系统上差别较大。对于 Linux 工作节点而言，容器化的 +CSI 节点插件通常部署为特权级的容器。对于 Windows 工作节点而言，容器化的 +CSI 节点插件的特权操作通过 +[csi-proxy](https://github.com/kubernetes-csi/csi-proxy) +来支持；csi-proxy 是一个社区管理的、独立的可执行文件，需要预安装在每个 +Windows 节点之上。请参考你要部署的 CSI 插件的部署指南以进一步了解其细节。 + + +#### 联网 {#networking} + +Windows 容器的联网是通过 +[CNI 插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +来暴露出来的。Windows 容器的联网行为与虚拟机的联网行为类似。 +每个容器有一块虚拟的网络适配器（vNIC）连接到 Hyper-V 的虚拟交换机（vSwitch）。 +宿主的联网服务（Host Networking Service，HNS）和宿主计算服务（Host Compute +Service，HCS）协同工作，创建容器并将容器的虚拟网卡连接到网络上。 +HCS 负责管理容器，HNS 则负责管理网络资源，例如： + + +* 虚拟网络（包括创建 vSwitch） +* 端点（Endpoint）/ vNIC +* 名字空间（Namespace） +* 策略（报文封装、负载均衡规则、访问控制列表、网络地址转译规则等等） + +支持的服务规约类型如下： + +* NodePort +* ClusterIP +* LoadBalancer +* ExternalName + + +##### 网络模式 {#network-modes} + +Windows 支持五种不同的网络驱动/模式：二层桥接（L2bridge）、二层隧道（L2tunnel）、 +覆盖网络（Overlay）、透明网络（Transparent）和网络地址转译（NAT）。 +在一个包含 Windows 和 Linux 工作节点的异构集群中，你需要选择一种对 Windows 和 +Linux 兼容的联网方案。下面是 Windows 上支持的一些树外插件及何时使用某种 +CNI 插件的建议： + +| 网络驱动 | 描述 | 容器报文修改 | 网络插件 | 网络插件特点 | +| ----------- | ---------- | -------------- | ---------- | ---------------| +| L2bridge | 容器挂接到外部 vSwitch 上。容器挂接到下层网络之上，但由于容器的 MAC 地址在入站和出站时被重写，物理网络不需要这些地址。 | MAC 地址被重写为宿主系统的 MAC 地址，IP 地址也可能依据 HNS OutboundNAT 策略重写为宿主的 IP 地址。 | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge)、[Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)；Flannel 宿主网关（host-gateway）使用 win-bridge | win-bridge 使用二层桥接（L2bridge）网络模式，将容器连接到下层宿主系统上，从而提供最佳性能。需要用户定义的路由（User-Defined Routes，UDR）才能实现节点间的连接。 | +| L2Tunnel | 这是二层桥接的一种特殊情形，但仅被用于 Azure 上。所有报文都被发送到虚拟化环境中的宿主机上并根据 SDN 策略进行处理。 | MAC 地址被改写，IP 地址在下层网络上可见。 | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI 使得容器能够与 Azure vNET 集成，并允许容器利用 [Azure 虚拟网络](https://azure.microsoft.com/en-us/services/virtual-network/)所提供的功能特性集合。例如，可以安全地连接到 Azure 服务上或者使用 Azure NSG。你可以参考 [azure-cni](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) 所提供的一些示例。 | +| 覆盖网络（Kubernetes 中为 Windows 提供的覆盖网络支持处于 *alpha* 阶段） | 每个容器会获得一个连接到外部 vSwitch 的虚拟网卡（vNIC）。每个覆盖网络都有自己的、通过定制 IP 前缀来定义的 IP 子网。覆盖网络驱动使用 VXLAN 封装。 | 封装于外层包头内。 | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay)、Flannel VXLAN（使用 win-overlay） | 当（比如出于安全原因）期望虚拟容器网络与下层宿主网络隔离时，应该使用 win-overlay。如果你的数据中心可用 IP 地址受限，覆盖网络允许你在不同的网络中复用 IP 地址（每个覆盖网络有不同的 VNID 标签）。这一选项要求在 Windows Server 2009 上安装 [KB4489899](https://support.microsoft.com/help/4489899) 补丁。 | +| 透明网络（[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) 的特殊用例） | 需要一个外部 vSwitch。容器挂接到某外部 vSwitch 上，该 vSwitch 通过逻辑网络（逻辑交换机和路由器）允许 Pod 间通信。 | 报文或者通过 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 来封装，或者通过 [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) 隧道来封装，以便能够到达不在同一宿主系统上的每个 Pod。
报文通过 OVN 网络控制器所提供的隧道元数据信息来判定是转发还是丢弃。
北-南向通信通过 NAT 网络地址转译来实现。 | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [通过 Ansible 来部署](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)。所发布的 ACL 可以通过 Kubernetes 策略来应用实施。支持 IPAM 。负载均衡能力不依赖 kube-proxy。网络地址转译（NAT）也不需要 iptables 或 netsh。 | +| NAT（*未在 Kubernetes 中使用*） | 容器获得一个连接到某内部 vSwitch 的 vNIC 接口。DNS/DHCP 服务通过名为 [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) 的内部组件来提供。 | MAC 地址和 IP 地址都被重写为宿主系统的 MAC 地址和 IP 地址。| [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 列在此表中仅出于完整性考虑 | + + + +如前所述，[Flannel](https://github.com/coreos/flannel) CNI +[meta 插件](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) +在 Windows 上也是 +[被支持](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) +的，方法是通过 [VXLAN 网络后端](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) +（**alpha 阶段** ：委托给 win-overlay）和 +[主机-网关（host-gateway）网络后端](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) +（稳定版本；委托给 win-bridge 实现）。 +此插件支持将操作委托给所引用的 CNI 插件（win-overlay、win-bridge）之一， +从而能够与 Windows 上的 Flannel 守护进程（Flanneld）一同工作，自动为节点 +分配子网租期，创建 HNS 网络。 +该插件读入其自身的配置文件（cni.conf），并将其与 FlannelD 所生成的 subnet.env +文件中的环境变量整合，之后将其操作委托给所引用的 CNI 插件之一以完成网络发现， +并将包含节点所被分配的子网信息的正确配置发送给 IPAM 插件（例如 host-local）。 + + +对于节点、Pod 和服务对象，可针对 TCP/UDP 流量支持以下网络数据流： + +* Pod -> Pod （IP 寻址） +* Pod -> Pod （名字寻址） +* Pod -> 服务（集群 IP） +* Pod -> 服务（部分限定域名，仅适用于名称中不包含“.”的情形） +* Pod -> 服务（全限定域名） +* Pod -> 集群外部（IP 寻址） +* Pod -> 集群外部（DNS 寻址） +* 节点 -> Pod +* Pod -> 节点 + + +##### IP 地址管理（IPAM） {#ipam} + +Windows 上支持以下 IPAM 选项： + +* [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) +* HNS IPAM (Inbox 平台 IPAM，未指定 IPAM 时的默认设置） +* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)（仅适用于 azure-cni ） + + +##### 负载均衡与服务 {#load-balancing-and-services} + +在 Windows 系统上，你可以使用以下配置来设定服务和负载均衡行为： + + + +{{< table caption="Windows 服务配置" >}} + +| 功能特性 | 描述 | 支持的 Kubernetes 版本 | 支持的 Windows OS 版本 | 如何启用 | +| -------- | --------| ---------------------- | ---------------------- | ---------- | +| 会话亲和性 | 确保来自特定客户的连接每次都被交给同一 Pod。 | v1.19+ | [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) 或更高版本 | 将 `service.spec.sessionAffinity` 设置为 "ClientIP" | +| 直接服务器返回 | 这是一种负载均衡模式，IP 地址的修正和负载均衡地址转译（LBNAT）直接在容器的 vSwitch 端口上处理；服务流量到达时，其源端 IP 地址设置为来源 Pod 的 IP。这种方案的延迟很低且可扩缩性好。 | v1.15+ | Windows Server 2004 版 | 为 kube-proxy 设置标志：`--feature-gates="WinDSR=true" --enable-dsr=true` | +| 保留目标地址 | 对服务流量略过 DNAT 步骤，这样就可以在到达后端 Pod 的报文中保留目标服务的虚拟 IP 地址。这一配置也会确保入站报文的客户端 IP 地址也被保留下来。 | v1.15+ | Windows Server 1903 或更高版本 | 在服务注解中设置 `"preserve-destination": "true"` 并启用 kube-proxy 中的 DSR 标志。 | +| IPv4/IPv6 双栈网络 | 在集群内外同时支持原生的 IPv4-到-IPv4 和 IPv6-到-IPv6 通信。 | v1.19+ | Windows Server vNext Insider Preview Build 19603 或更高版本 | 参见 [IPv4/IPv6 dual-stack](#ipv4ipv6-dual-stack) | + +{{< /table >}} + + +#### IPv4/IPv6 双栈支持 {#ipv4ipv6-dual-stack} + +你可以通过使用 `IPv6DualStack` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +来为 `l2bridge` 网络启用 IPv4/IPv6 双栈联网支持。 +进一步的细节可参见[启用 IPv4/IPv6 双协议栈](/zh/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack)。 + + +对 Windows 而言，在 Kubernetes 中使用 IPv6 需要 +Windows Server vNext Insider Preview Build 19603 或更高版本。 + +目前 Windows 上的覆盖网络（VXLAN）还不支持双协议栈联网。 + + +### 局限性 {#limitations} + +#### 控制面 {#control-plane} + +在 Kubernetes 架构和节点阵列中仅支持将 Windows 作为工作节点使用。 +这意味着 Kubernetes 集群必须总是包含 Linux 主控节点，零个或者多个 Linux +工作节点以及零个或者多个 Windows 工作节点。 + + +#### 计算 {#compute} + +##### 资源管理与进程隔离 {#resource-management-and-process-isolation} + +Linux 上使用 Linux 控制组（CGroups）作为 Pod 的边界，以实现资源控制。 +容器都创建于这一边界之内，从而实现网络、进程和文件系统的隔离。 +控制组 CGroups API 可用来收集 CPU、I/O 和内存的统计信息。 +与此相比，Windows 为每个容器创建一个带有系统名字空间过滤设置的 Job 对象， +以容纳容器中的所有进程并提供其与宿主系统间的逻辑隔离。 +没有现成的名字空间过滤设置是无法运行 Windows 容器的。 +这也意味着，系统特权无法在宿主环境中评估，因而 Windows 上也就不存在特权容器。 +归咎于独立存在的安全账号管理器（Security Account Manager，SAM），容器也不能 +获得宿主系统上的任何身份标识。 + + +##### 操作系统限制 {#operating-system-restrictions} + +Windows 有着严格的兼容性规则，宿主 OS 的版本必须与容器基准镜像 OS 的版本匹配。 +目前仅支持容器操作系统为 Windows Server 2019 的 Windows 容器。 +对于容器的 Hyper-V 隔离、允许一定程度上的 Windows 容器镜像版本向后兼容性等等， +都是将来版本计划的一部分。 + + +##### 功能特性限制 {#feature-restrictions} + +* 终止宽限期（Termination Grace Period）：未实现 +* 单文件映射：将用 CRI-ContainerD 来实现 +* 终止消息（Termination message）：将用 CRI-ContainerD 来实现 +* 特权容器：Windows 容器当前不支持 +* 巨页（Huge Pages）：Windows 容器当前不支持 +* 现有的节点问题探测器（Node Problem Detector）仅适用于 Linux，且要求使用特权容器。 + 一般而言，我们不设想此探测器能用于 Windows 节点，因为 Windows 不支持特权容器。 +* 并非支持共享名字空间的所有功能特性（参见 API 节以了解详细信息） + + +##### 内存预留与处理 {#memory-reservations-and-handling} + +Windows 不像 Linux 一样有一个内存耗尽（Out-of-memory）进程杀手（Process +Killer）机制。Windows 总是将用户态的内存分配视为虚拟请求，页面文件（Pagefile） +是必需的。这一差异的直接结果是 Windows 不会像 Linux 那样出现内存耗尽的状况， +系统会将进程内存页面写入磁盘而不会因内存耗尽而终止进程。 +当内存被过量使用且所有物理内存都被用光时，系统的换页行为会导致性能下降。 + + +通过一个两步的过程是有可能将内存用量限制在一个合理的范围的。 +首先，使用 kubelet 参数 `--kubelet-reserve` 与/或 `--system-reserve` +来划分节点上的内存用量（各容器之外）。 +这样做会减少节点可分配内存 +（[NodeAllocatable](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)）。 +在你部署工作负载时，对容器使用资源限制（必须仅设置 limits 或者让 limits 等于 +requests 值）。这也会从 NodeAllocatable 中耗掉部分内存量，从而避免在节点 +负荷已满时调度器继续向节点添加 Pods。 + +避免过量分配的最佳实践是为 kubelet 配置至少 2 GB 的系统预留内存，以供 +Windows、Docker 和 Kubernetes 进程使用。 + + +参数的不同行为描述如下： + +* `--kubelet-reserve`、`--system-reserve` 和 `--eviction-hard` 标志会更新节点可分配内存量 +* 未实现通过使用 `--enforce-node-allocable` 来完成的 Pod 驱逐 +* 未实现通过使用 `--eviction-hard` 和 `--eviction-soft` 来完成的 Pod 驱逐 +* `MemoryPressure` 状况未实现 +* `kubelet` 不会采取措施来执行基于 OOM 的驱逐动作 +* Windows 节点上运行的 kubelet 没有内存约束。 + `--kubelet-reserve` 和 `--system-reserve` 不会为 kubelet 或宿主系统上运行 + 的进程设限。这意味着 kubelet 或宿主系统上的进程可能导致内存资源紧张， + 而这一情况既不受节点可分配量影响，也不会被调度器感知。 + + +#### 存储 {#storage} + +Windows 上包含一个分层的文件系统来挂载容器的分层，并会基于 NTFS 来创建一个 +拷贝文件系统。容器中的所有文件路径都仅在该容器的上下文内完成解析。 + +* 卷挂载仅可针对容器中的目录进行，不可针对独立的文件 +* 卷挂载无法将文件或目录投射回宿主文件系统 +* 不支持只读文件系统，因为 Windows 注册表和 SAM 数据库总是需要写访问权限。 + 不过，Windows 支持只读的卷。 +* 不支持卷的用户掩码和访问许可，因为宿主与容器之间并不共享 SAM，二者之间不存在 + 映射关系。所有访问许可都是在容器上下文中解析的。 + + +因此，Windows 节点上不支持以下存储功能： + +* 卷的子路径挂载；只能在 Windows 容器上挂载整个卷。 +* 为 Secret 执行子路径挂载 +* 宿主挂载投射 +* 默认访问模式（因为该特性依赖 UID/GID） +* 只读的根文件系统；映射的卷仍然支持 `readOnly` +* 块设备映射 +* 将内存作为存储介质 +* 类似 UUID/GUID、每用户不同的 Linux 文件系统访问许可等文件系统特性 +* 基于 NFS 的存储和卷支持 +* 扩充已挂载卷（resizefs） + + +#### 联网 {#networking} + +Windows 容器联网与 Linux 联网有着非常重要的差别。 +[Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) +中包含额外的细节和背景信息。 + + +Windows 宿主联网服务和虚拟交换机实现了名字空间隔离，可以根据需要为 Pod 或容器 +创建虚拟的网络接口（NICs）。不过，很多类似 DNS、路由、度量值之类的配置数据都 +保存在 Windows 注册表数据库中而不是像 Linux 一样保存在 `/etc/...` 文件中。 +Windows 为容器提供的注册表与宿主系统的注册表是分离的，因此类似于将 /etc/resolv.conf +文件从宿主系统映射到容器中的做法不会产生与 Linux 系统相同的效果。 +这些信息必须在容器内部使用 Windows API 来配置。 +因此，CNI 实现需要调用 HNS，而不是依赖文件映射来将网络细节传递到 Pod +或容器中。 + + +Windows 节点不支持以下联网功能： + +* Windows Pod 不能使用宿主网络模式 +* 从节点本地访问 NodePort 会失败（但从其他节点或外部客户端可访问） +* Windows Server 的未来版本中会支持从节点访问服务的 VIPs +* kube-proxy 的覆盖网络支持是 Alpha 特性。此外，它要求在 Windows Server 2019 上安装 + [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) 补丁 +* 本地流量策略和 DSR（保留目标地址）模式 +* 连接到 l2bridge、l2tunnel 或覆盖网络的 Windows 容器不支持使用 IPv6 协议栈通信。 + 要使得这些网络驱动能够支持 IPv6 地址需要在 Windows 平台上开展大量的工作， + 还需要在 Kubernetes 侧修改 kubelet、kube-proxy 以及 CNI 插件。 +* 通过 win-overlay、win-bridge 和 Azure-CNI 插件使用 ICMP 协议向集群外通信。 + 尤其是，Windows 数据面（[VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)） + 不支持转换 ICMP 报文。这意味着： + * 指向同一网络内目标地址的 ICMP 报文（例如 Pod 之间的 ping 通信）是可以工作的，没有局限性 + * TCP/UDP 报文可以正常工作，没有局限性 + * 指向远程网络的 ICMP 报文（例如，从 Pod 中 ping 外部互联网的通信）无法被转换， + 因此也无法被路由回到其源点。 + * 由于 TCP/UDP 包仍可被转换，用户可以将 `ping <目标>` 操作替换为 `curl <目标>` + 以便能够调试与外部世界的网络连接。 + + +Kubernetes v1.15 中添加了以下功能特性： + +* `kubectl port-forward` + + +##### CNI 插件 {#cni-plugins} + +* Windows 参考网络插件 win-bridge 和 win-overlay 当前未实现 + [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0， + 原因是缺少检查用（CHECK）的实现。 +* Windows 上的 Flannel VXLAN CNI 有以下局限性： + + 1. 其设计上不支持从节点到 Pod 的连接。 + 只有在 Flannel v0.12.0 或更高版本后才有可能访问本地 Pods。 + 2. 我们被限制只能使用 VNI 4096 和 UDP 端口 4789。 + VNI 的限制正在被解决，会在将来的版本中消失（开源的 Flannel 更改）。 + 参见官方的 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) + 后端文档以了解关于这些参数的详细信息。 + +##### DNS {#dns-limitations} + + +* 不支持 DNS 的 ClusterFirstWithHostNet 配置。Windows 将所有包含 “.” 的名字 + 视为全限定域名（FQDN），因而不会对其执行部分限定域名（PQDN）解析。 +* 在 Linux 上，你可以有一个 DNS 后缀列表供解析部分限定域名时使用。 + 在 Windows 上，我们只有一个 DNS 后缀，即与该 Pod 名字空间相关联的 DNS + 后缀（例如 `mydns.svc.cluster.local`）。 + Windows 可以解析全限定域名、或者恰好可用该后缀来解析的服务名称。 + 例如，在 default 名字空间中生成的 Pod 会获得 DNS 后缀 + `default.svc.cluster.local`。在 Windows Pod 中，你可以解析 + `kubernetes.default.svc.cluster.local` 和 `kubernetes`，但无法解析二者 + 之间的形式，如 `kubernetes.default` 或 `kubernetes.default.svc`。 +* 在 Windows 上，可以使用的 DNS 解析程序有很多。由于这些解析程序彼此之间 + 会有轻微的行为差别，建议使用 `Resolve-DNSName` 工具来完成名字查询解析。 + + +##### IPv6 + +Windows 上的 Kubernetes 不支持单协议栈的“只用 IPv6”联网选项。 +不过，系统支持在 IPv4/IPv6 双协议栈的 Pod 和节点上运行单协议家族的服务。 +更多细节可参阅 [IPv4/IPv6 双协议栈联网](#ipv4ipv6-dual-stack)一节。 + + +##### 会话亲和性 {#session-affinity} + +不支持使用 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 来为 +Windows 服务设置最大会话粘滞时间。 + + +##### 安全性 {#security} + +Secret 以明文形式写入节点的卷中（而不是像 Linux 那样写入内存或 tmpfs 中）。 +这意味着客户必须做以下两件事： + +1. 使用文件访问控制列表来保护 Secret 文件所在的位置 +2. 使用 [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) + 来执行卷层面的加密 + + +Windows 上目前不支持 [`RunAsUser`](/zh/docs/concepts/policy/pod-security-policy/#users-and-groups)。 +一种替代方案是在为容器打包时创建本地账号。 +将来的版本中可能会添加对 `RunAsUser` 的支持。 + +不支持特定于 Linux 的 Pod 安全上下文特权，例如 SELinux、AppArmor、Seccomp、 +权能字（POSIX 权能字）等等。 + +此外，如前所述，Windows 不支持特权容器。 + + +#### API + +对 Windows 而言，大多数 Kubernetes API 的工作方式没有变化。 +一些不易察觉的差别通常体现在 OS 和容器运行时上的不同。 +在某些场合，负载 API （如 Pod 或 Container）的某些属性在设计时假定其 +在 Linux 上实现，因此会无法在 Windows 上运行。 + +在较高层面，不同的 OS 概念有： + + +* 身份标识 - Linux 使用证书类型来表示用户 ID（UID）和组 ID（GID）。用户和组名 + 没有特定标准，它们仅是 `/etc/groups` 或 `/etc/passwd` 中的别名表项，会映射回 + UID+GID。Windows 使用一个更大的二进制安全标识符（SID），保存在 Windows + 安全访问管理器（Security Access Manager，SAM）数据库中。此数据库并不在宿主系统 + 与容器间，或者任意两个容器之间共享。 +* 文件许可 - Windows 使用基于 SID 的访问控制列表，而不是基于 UID+GID 的访问权限位掩码。 +* 文件路径 - Windows 上的习惯是使用 `\` 而非 `/`。Go 语言的 IO 库通常能够同时接受二者， + 并做出正确判断。不过当你在指定要在容器内解析的路径或命令行时，可能需要使用 `\`。 +* 信号 - Windows 交互式应用以不同方式来处理终止事件，并可实现以下方式之一或组合： + * UI 线程处理包含 WM_CLOSE 在内的良定的消息 + * 控制台应用使用控制处理程序来处理 Ctrl-C 或 Ctrl-Break + * 服务会注册服务控制处理程序，接受 SERVICE_CONTROL_STOP 控制代码 + + +退出代码遵从相同的习惯，0 表示成功，非 0 值表示失败。 +特定的错误代码在 Windows 和 Linux 上可能会不同。不过，从 Kubernetes 组件 +（kubelet、kube-proxy）所返回的退出代码是没有变化的。 + + +##### V1.Container + +* `v1.Container.ResourceRequirements.limits.cpu` 和 `v1.Container.ResourceRequirements.limits.memory` - Windows + 不对 CPU 分配设置硬性的限制。与之相反，Windows 使用一个份额（share）系统。 + 基于毫核（millicores）的现有字段值会被缩放为相对的份额值，供 Windows 调度器使用。 + 参见 [kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go) 和 + [Microsoft 文档中关于资源控制的部分](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls)。 + + * Windows 容器运行时中没有实现巨页支持，因此相关特性不可用。 + 巨页支持需要[判定用户的特权](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) + 而这一特性无法在容器级别配置。 + +* `v1.Container.ResourceRequirements.requests.cpu` 和 `v1.Container.ResourceRequirements.requests.memory` - 请求 + 值会从节点可分配资源中扣除，从而可用来避免节点上的资源过量分配。 + 但是，它们无法用来在一个已经过量分配的节点上提供资源保障。 + 如果操作员希望彻底避免过量分配，作为最佳实践，他们就需要为所有容器设置资源请求值。 +* `v1.Container.SecurityContext.allowPrivilegeEscalation` - 在 Windows 上无法实现，对应的权能 + 无一可在 Windows 上生效。 +* `v1.Container.SecurityContext.Capabilities` - Windows 上未实现 POSIX 权能机制 +* `v1.Container.SecurityContext.privileged` - Windows 不支持特权容器 +* `v1.Container.SecurityContext.procMount` - Windows 不包含 `/proc` 文件系统 +* `v1.Container.SecurityContext.readOnlyRootFilesystem` - 在 Windows 上无法实现， + 要在容器内使用注册表或运行系统进程就必需写访问权限。 +* `v1.Container.SecurityContext.runAsGroup` - 在 Windows 上无法实现，没有 GID 支持 +* `v1.Container.SecurityContext.runAsNonRoot` - Windows 上没有 root 用户。 + 与之最接近的等价用户是 `ContainerAdministrator`，而该身份标识在节点上并不存在。 +* `v1.Container.SecurityContext.runAsUser` - 在 Windows 上无法实现，因为没有作为整数支持的 GID。 +* `v1.Container.SecurityContext.seLinuxOptions` - 在 Windows 上无法实现，因为没有 SELinux +* `V1.Container.terminationMessagePath` - 因为 Windows 不支持单个文件的映射，这一功能 + 在 Windows 上也受限。默认值 `/dev/termination-log` 在 Windows 上也无法使用因为 + 对应路径在 Windows 上不存在。 + + +##### V1.Pod + +* `v1.Pod.hostIPC`、`v1.Pod.hostPID` - Windows 不支持共享宿主系统的名字空间 +* `v1.Pod.hostNetwork` - Windows 操作系统不支持共享宿主网络 +* `v1.Pod.dnsPolicy` - 不支持 `ClusterFirstWithHostNet`，因为 Windows 不支持宿主网络 +* `v1.Pod.podSecurityContext` - 参见下面的 `v1.PodSecurityContext` +* `v1.Pod.shareProcessNamespace` - 此为 Beta 特性且依赖于 Windows 上未实现的 Linux + 名字空间。Windows 无法共享进程名字空间或者容器的根文件系统。只能共享网络。 +* `v1.Pod.terminationGracePeriodSeconds` - 这一特性未在 Windows 版本的 Docker 中完全实现。 + 参见[问题报告](https://github.com/moby/moby/issues/25982)。 + 目前实现的行为是向 ENTRYPOINT 进程发送 CTRL_SHUTDOWN_EVENT 时间，之后 Windows 默认 + 等待 5 秒钟，并最终使用正常的 Windows 关机行为关闭所有进程。 + 这里的 5 秒钟默认值实际上保存在[容器内](https://github.com/moby/moby/issues/25982#issuecomment-426441183) + 的 Windows 注册表中，因此可以在构造容器时重载。 +* `v1.Pod.volumeDevices` - 此为 Beta 特性且未在 Windows 上实现。Windows 无法挂接 + 原生的块设备到 Pod 中。 +* `v1.Pod.volumes` - `emptyDir`、`secret`、`configMap` 和 `hostPath` 都可正常工作且在 + TestGrid 中测试。 + * `v1.emptyDir.volumeSource` - Windows 上节点的默认介质是磁盘。不支持将内存作为介质， + 因为 Windows 不支持内置的 RAM 磁盘。 +* `v1.VolumeMount.mountPropagation` - Windows 上不支持挂载传播。 + + +##### V1.PodSecurityContext + +PodSecurityContext 的所有选项在 Windows 上都无法工作。这些选项列在下面仅供参考。 + +* `v1.PodSecurityContext.seLinuxOptions` - Windows 上无 SELinux +* `v1.PodSecurityContext.runAsUser` - 提供 UID；Windows 不支持 +* `v1.PodSecurityContext.runAsGroup` - 提供 GID；Windows 不支持 +* `v1.PodSecurityContext.runAsNonRoot` - Windows 上没有 root 用户 + 最接近的等价账号是 `ContainerAdministrator`，而该身份标识在节点上不存在 +* `v1.PodSecurityContext.supplementalGroups` - 提供 GID；Windows 不支持 +* `v1.PodSecurityContext.sysctls` - 这些是 Linux sysctl 接口的一部分；Windows 上 + 没有等价机制。 + + +## 获取帮助和故障排查 {#troubleshooting} + +对你的 Kubernetes 集群进行排查的主要帮助信息来源应该是 +[这份文档](/docs/tasks/debug-application-cluster/troubleshooting/)。 +该文档中包含了一些额外的、特定于 Windows 系统的故障排查帮助信息。 +Kubernetes 中日志是故障排查的一个重要元素。确保你在尝试从其他贡献者那里获得 +故障排查帮助时提供日志信息。 +你可以按照 SIG-Windows [贡献指南和收集日志](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) +所给的指令来操作。 + + +1. 我怎样知道 `start.ps1` 是否已成功完成？ + + 你应该能看到节点上运行的 kubelet、kube-proxy 和（如果你选择 Flannel + 作为联网方案）flanneld 宿主代理进程，它们的运行日志显示在不同的 + PowerShell 窗口中。此外，你的 Windows 节点应该在你的 Kubernetes 集群 + 列举为 "Ready" 节点。 + + +2. 我可以将 Kubernetes 节点进程配置为服务运行在后台么？ + + kubelet 和 kube-proxy 都已经被配置为以本地 Windows 服务运行， + 并且在出现失效事件（例如进程意外结束）时通过自动重启服务来提供一定的弹性。 + 你有两种办法将这些节点组件配置为服务。 + + + 1. 以本地 Windows 服务的形式 + + Kubelet 和 kube-proxy 可以用 `sc.exe` 以本地 Windows 服务的形式运行： + + ```powershell + # 用两个单独的命令为 kubelet 和 kube-proxy 创建服务 + sc.exe create <组件名称> binPath= "<可执行文件路径> -service <其它参数>" + + # 请注意如果参数中包含空格，必须使用转义 + sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <其它参数>" + + # 启动服务 + Start-Service kubelet + Start-Service kube-proxy + + # 停止服务 + Stop-Service kubelet (-Force) + Stop-Service kube-proxy (-Force) + + # 查询服务状态 + Get-Service kubelet + Get-Service kube-proxy + ``` + + + 2. 使用 nssm.exe + + 你也总是可以使用替代的服务管理器，例如[nssm.exe](https://nssm.cc/)，来为你在后台运行 + 这些进程（`flanneld`、`kubelet` 和 `kube-proxy`）。你可以使用这一 + [示例脚本](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)， + 利用 `nssm.exe` 将 `kubelet`、`kube-proxy` 和 `flanneld.exe` 注册为要在后台运行的 + Windows 服务。 + + ```powershell + register-svc.ps1 -NetworkMode <网络模式> -ManagementIP -ClusterCIDR <集群子网> -KubeDnsServiceIP -LogDir <日志目录> + + # NetworkMode = 网络模式 l2bridge（flannel host-gw，也是默认值）或 overlay（flannel vxlan）选做网络方案 + # ManagementIP = 分配给 Windows 节点的 IP 地址。你可以使用 ipconfig 得到此值 + # ClusterCIDR = 集群子网范围（默认值为 10.244.0.0/16） + # KubeDnsServiceIP = Kubernetes DNS 服务 IP（默认值为 10.96.0.10） + # LogDir = kubelet 和 kube-proxy 的日志会被重定向到这一目录中的对应输出文件，默认值为 `C:\k`。 + ``` + + 若以上所引用的脚本不适合，你可以使用下面的例子手动配置 `nssm.exe`。 + + ```powershell + # 注册 flanneld.exe + nssm install flanneld C:\flannel\flanneld.exe + nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm set flanneld AppEnvironmentExtra NODE_NAME=<主机名> + nssm set flanneld AppDirectory C:\flannel + nssm start flanneld + + # 注册 kubelet.exe + # Microsoft 在 mcr.microsoft.com/k8s/core/pause:1.2.0 发布其 pause 基础设施容器 + nssm install kubelet C:\k\kubelet.exe + nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config + nssm set kubelet AppDirectory C:\k + nssm start kubelet + + # 注册 kube-proxy.exe (l2bridge / host-gw) + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<主机名>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<日志目录> --logtostderr=false + nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy + + # 注册 kube-proxy.exe (overlay / vxlan) + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<主机名> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<源端 VIP> --enable-dsr=false --log-dir=<日志目录> --logtostderr=false + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy + ``` + + + 作为初始的故障排查操作，你可以使用在 [nssm.exe](https://nssm.cc/) 中使用下面的标志 + 以便将标准输出和标准错误输出重定向到一个输出文件： + + ```powershell + nssm set <服务名称> AppStdout C:\k\mysvc.log + nssm set <服务名称> AppStderr C:\k\mysvc.log + ``` + + 要了解更多的细节，可参见官方的 [nssm 用法](https://nssm.cc/usage)文档。 + + +3. 我的 Windows Pods 无发连接网络 + + 如果你在使用虚拟机，请确保 VM 网络适配器均已开启 MAC 侦听（Spoofing）。 + + +4. 我的 Windows Pods 无法 ping 外部资源 + + Windows Pods 目前没有为 ICMP 协议提供出站规则。不过 TCP/UDP 是支持的。 + 尝试与集群外资源连接时，可以将 `ping ` 命令替换为对应的 `curl ` 命令。 + + 如果你还遇到问题，很可能你在 + [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) + 中的网络配置值得额外的注意。你总是可以编辑这一静态文件。 + 配置的更新会应用到所有新创建的 Kubernetes 资源上。 + + Kubernetes 网络的需求之一（参见[Kubernetes 模型](/zh/docs/concepts/cluster-administration/networking/)） + 是集群内部无需网络地址转译（NAT）即可实现通信。为了符合这一要求，对所有我们不希望出站时发生 NAT + 的通信都存在一个 [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)。 + 然而这也意味着你需要将你要查询的外部 IP 从 ExceptionList 中移除。 + 只有这时，从你的 Windows Pod 发起的网络请求才会被正确地通过 SNAT 转换以接收到 + 来自外部世界的响应。 + 就此而言，你在 `cni.conf` 中的 `ExceptionList` 应该看起来像这样： + + ```conf + "ExceptionList": [ + "10.244.0.0/16", # 集群子网 + "10.96.0.0/12", # 服务子网 + "10.127.130.0/24" # 管理（主机）子网 + ] + ``` + + +5. 我的 Windows 节点无法访问 NodePort 服务 + + 从节点自身发起的本地 NodePort 请求会失败。这是一个已知的局限。 + NodePort 服务的访问从其他节点或者外部客户端都可正常进行。 + + +6. 容器的 vNICs 和 HNS 端点被删除了 + + 这一问题可能因为 `hostname-override` 参数未能传递给 + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) 而导致。 + 解决这一问题时，用户需要按如下方式将主机名传递给 kube-proxy： + + ```powershell + C:\k\kube-proxy.exe --hostname-override=$(hostname) + ``` + + +7. 使用 Flannel 时，我的节点在重新加入集群时遇到问题 + + 无论何时，当一个之前被删除的节点被重新添加到集群时，flannelD 都会将为节点分配 + 一个新的 Pod 子网。 + 用户需要将将下面路径中的老的 Pod 子网配置文件删除： + + ```powershell + Remove-Item C:\k\SourceVip.json + Remove-Item C:\k\SourceVipRequest.json + ``` + + +8. 在启动了 `start.ps1` 之后，flanneld 一直停滞在 "Waiting for the Network to be created" 状态 + + 关于这一[正在被分析的问题](https://github.com/coreos/flannel/issues/1066)有很多的报告； + 最可能的一种原因是关于何时设置 Flannel 网络的管理 IP 的时间问题。 + 一种解决办法是重新启动 `start.ps1` 或者按如下方式手动重启之： + + ```powershell + PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") + PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + ``` + + +9. 我的 Windows Pods 无法启动，因为缺少 `/run/flannel/subnet.env` 文件 + + 这表明 Flannel 网络未能正确启动。你可以尝试重启 flanneld.exe 或者将文件手动地 + 从 Kubernetes 主控节点的 `/run/flannel/subnet.env` 路径复制到 Windows 工作 + 节点的 `C:\run\flannel\subnet.env` 路径，并将 `FLANNEL_SUBNET` 行改为一个 + 不同的数值。例如，如果期望节点子网为 `10.244.4.1/24`： + + ```env + FLANNEL_NETWORK=10.244.0.0/16 + FLANNEL_SUBNET=10.244.4.1/24 + FLANNEL_MTU=1500 + FLANNEL_IPMASQ=true + ``` + + +10. 我的 Windows 节点无法使用服务 IP 访问我的服务 + + 这是 Windows 上当前网络协议栈的一个已知的限制。 + Windows Pods 能够访问服务 IP。 + + +11. 启动 kubelet 时找不到网络适配器 + + Windows 网络堆栈需要一个虚拟的适配器，这样 Kubernetes 网络才能工作。 + 如果下面的命令（在管理员 Shell 中）没有任何返回结果，证明虚拟网络创建 + （kubelet 正常工作的必要前提之一）失败了： + + ```powershell + Get-HnsNetwork | ? Name -ieq "cbr0" + Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + ``` + + + 当宿主系统的网络适配器名称不是 "Ethernet" 时，通常值得更改 `start.ps1` 脚本中的 + [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) + 参数来重试。否则可以查验 `start-kubelet.ps1` 的输出，看看是否在虚拟网络创建 + 过程中报告了其他错误。 + + +12. 我的 Pods 停滞在 "Container Creating" 状态或者反复重启 + + 检查你的 pause 镜像是与你的 OS 版本兼容的。 + [这里的指令](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) + 假定你的 OS 和容器版本都是 1803。如果你安装的是更新版本的 Windows，比如说 + 某个 Insider 构造版本，你需要相应地调整要使用的镜像。 + 请参照 Microsoft 的 [Docker 仓库](https://hub.docker.com/u/microsoft/) + 了解镜像。不管怎样，pause 镜像的 Dockerfile 和示例服务都期望镜像的标签 + 为 `:latest`。 + + 从 Kubernetes v1.14 版本起，Microsoft 开始在 `mcr.microsoft.com/k8s/core/pause:1.2.0` + 发布其 pause 基础设施容器。 + + +13. DNS 解析无法正常工作 + + 参阅 Windows 上 [DNS 相关的局限](#dns-limitations) 节。 + + +14. `kubectl port-forward` 失败，错误信息为 "unable to do port forwarding: wincat not found" + + 此功能是在 Kubernetes v1.15 中实现的，pause 基础设施容器为 `mcr.microsoft.com/k8s/core/pause:1.2.0`。 + 请确保你使用的是这些版本或者更新版本。 + 如果你想要自行构造你自己的 pause 基础设施容器，要确保其中包含了 + [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat) + + +15. 我的 Kubernetes 安装失败，因为我的 Windows Server 节点在防火墙后面 + + 如果你处于防火墙之后，那么必须定义如下 PowerShell 环境变量： + + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + + +15. `pause` 容器是什么？ + + 在一个 Kubernetes Pod 中，一个基础设施容器，或称 "pause" 容器，会被首先创建出来， + 用以托管容器端点。属于同一 Pod 的容器，包括基础设施容器和工作容器，会共享相同的 + 网络名字空间和端点（相同的 IP 和端口空间）。我们需要 pause 容器来工作容器崩溃或 + 重启的状况，以确保不会丢失任何网络配置。 + + "pause" （基础设施）镜像托管在 Microsoft Container Registry (MCR) 上。 + 你可以使用 `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0` 来访问它。 + 要了解进一步的细节，可参阅 [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)。 + + +### 进一步探究 {#further-investigation} + +如果以上步骤未能解决你遇到的问题，你可以通过以下方式获得在 Kubernetes +中的 Windows 节点上运行 Windows 容器的帮助： + +* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) 主题 +* Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io/) +* Kubernetes Slack [#SIG-Windows 频道](https://kubernetes.slack.com/messages/sig-windows) + + +## 报告问题和功能需求 {#reporting-issues-and-feature-requests} + +如果你遇到看起来像是软件缺陷的问题，或者你想要提起某种功能需求，请使用 +[GitHub 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。 +你可以在 [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) +上发起 Issue 并将其指派给 SIG-Windows。你应该首先搜索 Issue 列表，看看是否 +该 Issue 以前曾经被报告过，以评论形式将你在该 Issue 上的体验追加进去，并附上 +额外的日志信息。SIG-Windows Slack 频道也是一个获得初步支持的好渠道，可以在 +生成新的 Ticket 之前对一些想法进行故障分析。 + + +在登记软件缺陷时，请给出如何重现该问题的详细信息，例如： + +* Kubernetes 版本：kubectl 版本 +* 环境细节：云平台、OS 版本、网络选型和配置情况以及 Docker 版本 +* 重现该问题的详细步骤 +* [相关的日志](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) +* 通过为该 Issue 添加 `/sig windows` 评论为其添加 `sig/windows` 标签， + 进而引起 SIG-Windows 成员的注意。 + +## {{% heading "whatsnext" %}} + + +在我们的未来蓝图中包含很多功能特性（要实现）。下面是一个浓缩的简要列表，不过我们 +鼓励你查看我们的 [roadmap 项目](https://github.com/orgs/kubernetes/projects/8)并 +通过[贡献](https://github.com/kubernetes/community/blob/master/sig-windows/)的方式 +帮助我们把 Windows 支持做得更好。 + + +### Hyper-V 隔离 {#hyper-v-isolation} + +要满足 Kubernetes 中 Windows 容器的如下用例，需要利用 Hyper-V 隔离： + +* 在 Pod 之间实施基于监管程序（Hypervisor）的隔离，以增强安全性 +* 出于向后兼容需要，允许添加运行新 Windows Server 版本的节点时不必重新创建容器 +* 为 Pod 设置特定的 CPU/NUMA 配置 +* 实施内存隔离与预留 + + +现有的 Hyper-V 隔离支持是添加自 v1.10 版本的实验性功能特性，会在未来版本中弃用， +向前文所提到的 CRI-ContainerD 和 RuntimeClass 特性倾斜。 +要使用当前的功能特性并创建 Hyper-V 隔离的容器，需要在启动 kubelet 时设置特性门控 +`HyperVContainer=true`，同时为 Pod 添加注解 +`experimental.windows.kubernetes.io/isolation-type=hyperv`。 +在实验性实现版本中，此功能特性限制每个 Pod 中只能包含一个容器。 + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis +spec: + selector: + matchLabels: + app: iis + replicas: 3 + template: + metadata: + labels: + app: iis + annotations: + experimental.windows.kubernetes.io/isolation-type: hyperv + spec: + containers: + - name: iis + image: microsoft/iis + ports: + - containerPort: 80 +``` + + +### 使用 kubeadm 和 Cluster API 来部署 {#deployment-with-kubeadm-and-cluster-api} + +kubeadm 已经成为用户部署 Kubernetes 集群的事实标准。 +kubeadm 对 Windows 节点的支持目前还在开发过程中，不过你可以阅读相关的 +[指南](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)。 +我们也在投入资源到 Cluster API，以确保 Windows 节点被正确配置。 + + +### 若干其他关键功能 {#a-few-other-key-features} + +* 为组管理的服务账号（Group Managed Service Accounts，GMSA）提供 Beta 支持 +* 添加更多的 CNI 支持 +* 实现更多的存储插件 + diff --git a/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md b/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md index 3a5221a1b0..95a80ea123 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md @@ -481,7 +481,7 @@ If you add the `lifecycle` section show above to your Pod spec, the Pod will exe ## GMSA limitations When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work. It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required. The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). --> -## GMSA 的局限 +## GMSA 的局限 {#gmsa-limitations} 在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) 时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。 From 246ded8b5a5065e266b615a2a59b9c7e25703e4f Mon Sep 17 00:00:00 2001 From: Arhell Date: Sun, 6 Dec 2020 01:26:53 +0200 Subject: [PATCH 38/66] [zh] sync remove problems in DaemonSet fixed by controllerRef --- .../concepts/workloads/controllers/daemonset.md | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md index 5ad4bf617a..60f8f656fe 100644 --- a/content/zh/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md @@ -174,20 +174,6 @@ If the `.spec.selector` is specified, it must match the `.spec.template.metadata 如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。 如果与后者不匹配，则 DeamonSet 会被 API 拒绝。 - -另外，通常不应直接通过另一个 DaemonSet 或另一个工作负载资源（例如 ReplicaSet） -来创建其标签与该选择器匹配的任何 Pod。否则，DaemonSet -{{< glossary_tooltip term_text="控制器" term_id="controller" >}} -会认为这些 Pod 是由它创建的。 -Kubernetes 不会阻止你这样做。 -你可能要执行此操作的一种情况是，手动在节点上创建具有不同值的 Pod 进行测试。 - ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects} -*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다. +*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다. * 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지) * 그 애플리케이션이 이용할 수 있는 리소스 diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 631f0347d4..597bf0e48d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -189,7 +189,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' #### 서비스와 레플리케이션 컨트롤러 -`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다. +`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다. 서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다. diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index ffda9f5eda..2f351b2ba5 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -74,8 +74,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 | `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. | | `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. | | `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. | -| `hugepages-` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 -휴즈 페이지 요청은 이 값을 초과하지 못함. | +| `hugepages-` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 휴즈 페이지 요청은 이 값을 초과하지 못함. | | `cpu` | `requests.cpu` 와 같음. | | `memory` | `requests.memory` 와 같음. | diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index b6efd38404..f8efb77d8f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -8,125 +8,146 @@ weight: 50 {{< feature-state for_k8s_version="v1.16" state="alpha" >}} -kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 kube-scheduler를 미세 조정할 수 있다. - - +kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 +확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 +kube-scheduler를 미세 조정할 수 있다. ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기 -쿠버네티스 1.15 이전에는 Kube-scheduler가 CPU 및 메모리와 같은 리소스의 용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용했다. 쿠버네티스 1.16은 우선 순위 기능에 새로운 파라미터를 추가해서 사용자가 용량 대비 요청 비율을 기반으로 노드에 점수를 매기도록 각 리소스의 가중치와 함께 리소스를 지정할 수 있다. 이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들수 있어 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 `requestedToCapacityRatioArguments`라는 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 셰이프(shape)는 사용자가 `utilization`과 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 리소스는 -점수를 매길 때 고려할 리소스를 지정하는 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 구성된다. +쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 +용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를 +통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 +대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. +`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 +동작은 `requestedToCapacityRatioArguments`라는 +구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` +두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과 +`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 +조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할 +리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 +구성된다. -다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다. +다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 +`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 +설정하는 구성의 예시이다. -```json -{ - "kind" : "Policy", - "apiVersion" : "v1", - - ... - - "priorities" : [ - - ... - - { - "name": "RequestedToCapacityRatioPriority", - "weight": 2, - "argument": { - "requestedToCapacityRatioArguments": { - "shape": [ - {"utilization": 0, "score": 0}, - {"utilization": 100, "score": 10} - ], - "resources": [ - {"name": "intel.com/foo", "weight": 3}, - {"name": "intel.com/bar", "weight": 5} - ] - } - } - } - ], - } +```yaml +apiVersion: v1 +kind: Policy +# ... +priorities: + # ... + - name: RequestedToCapacityRatioPriority + weight: 2 + argument: + requestedToCapacityRatioArguments: + shape: + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 5 ``` **이 기능은 기본적으로 비활성화되어 있다.** -### RequestedToCapacityRatioResourceAllocation 우선 순위 기능 튜닝하기 +### 우선 순위 기능 튜닝하기 -`shape` 는 `RequestedToCapacityRatioPriority` 기능의 동작을 지정하는 데 사용된다. +`shape` 는 `RequestedToCapacityRatioPriority` 기능의 +동작을 지정하는 데 사용된다. ```yaml - {"utilization": 0, "score": 0}, - {"utilization": 100, "score": 10} +shape: + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 ``` -위의 인수는 사용률이 0%인 경우 점수는 0, 사용률이 100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을 활성화하려면 점수 값을 다음과 같이 변경해야 한다. +위의 인수는 `utilization` 이 0%인 경우 `score` 는 0, `utilization` 이 +100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을 +활성화하려면 점수 값을 다음과 같이 변경해야 한다. ```yaml - {"utilization": 0, "score": 100}, - {"utilization": 100, "score": 0} +shape: + - utilization: 0 + score: 100 + - utilization: 100 + score: 0 ``` `resources` 는 기본적으로 다음과 같이 설정되는 선택적인 파라미터이다. ``` yaml -"resources": [ - {"name": "CPU", "weight": 1}, - {"name": "Memory", "weight": 1} - ] +resources: + - name: CPU + weight: 1 + - name: Memory + weight: 1 ``` 다음과 같이 확장된 리소스를 추가하는 데 사용할 수 있다. ```yaml -"resources": [ - {"name": "intel.com/foo", "weight": 5}, - {"name": "CPU", "weight": 3}, - {"name": "Memory", "weight": 1} - ] +resources: + - name: intel.com/foo + weight: 5 + - name: CPU + weight: 3 + - name: Memory + weight: 1 ``` -가중치 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한, 가중치는 음수로 설정할 수 없다. +`weight` 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한, +`weight` 는 음수로 설정할 수 없다. -### RequestedToCapacityRatioResourceAllocation 우선 순위 기능이 노드에 점수를 매기는 방법 +### 용량 할당을 위해 노드에 점수 매기기 이 섹션은 이 기능 내부의 세부적인 사항을 이해하려는 사람들을 위한 것이다. 아래는 주어진 값의 집합에 대해 노드 점수가 계산되는 방법의 예시이다. -``` -Requested Resources +요청된 리소스는 다음과 같다. +``` intel.com/foo : 2 Memory: 256MB CPU: 2 +``` -Resource Weights +리소스의 가중치는 다음과 같다. +``` intel.com/foo : 5 Memory: 1 CPU: 3 +``` FunctionShapePoint {{0, 0}, {100, 10}} -Node 1 Spec +노드 1의 사양은 다음과 같다. +``` Available: -intel.com/foo : 4 -Memory : 1 GB -CPU: 8 + intel.com/foo: 4 + Memory: 1 GB + CPU: 8 Used: -intel.com/foo: 1 -Memory: 256MB -CPU: 1 + intel.com/foo: 1 + Memory: 256MB + CPU: 1 +``` +노드 점수는 다음과 같다. -Node Score: - +``` intel.com/foo = resourceScoringFunction((2+1),4) = (100 - ((4-3)*100/4) = (100 - 25) @@ -148,24 +169,24 @@ CPU = resourceScoringFunction((2+1),8) NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 +``` +노드 2의 사양은 다음과 같다. -Node 2 Spec - +``` Available: -intel.com/foo: 8 -Memory: 1GB -CPU: 8 - + intel.com/foo: 8 + Memory: 1GB + CPU: 8 Used: + intel.com/foo: 2 + Memory: 512MB + CPU: 6 +``` -intel.com/foo: 2 -Memory: 512MB -CPU: 6 - - -Node Score: +노드 점수는 다음과 같다. +``` intel.com/foo = resourceScoringFunction((2+2),8) = (100 - ((8-4)*100/8) = (100 - 50) @@ -189,3 +210,8 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` + +## {{% heading "whatsnext" %}} + +- [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다. +- [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다. diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index a72b857d07..bab0803b99 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -28,15 +28,15 @@ _톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트 예를 들면 다음과 같다. ```shell -kubectl taint nodes node1 key=value:NoSchedule +kubectl taint nodes node1 key1=value1:NoSchedule ``` -`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key`, 값 `value` 및 테인트 이펙트(effect) `NoSchedule` 이 있다. +`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key1`, 값 `value1` 및 테인트 이펙트(effect) `NoSchedule` 이 있다. 이는 일치하는 톨러레이션이 없으면 파드를 `node1` 에 스케줄할 수 없음을 의미한다. 위의 명령으로 추가한 테인트를 제거하려면, 다음을 실행한다. ```shell -kubectl taint nodes node1 key:NoSchedule- +kubectl taint nodes node1 key1=value1:NoSchedule- ``` PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러레이션은 @@ -45,15 +45,15 @@ PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러 ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Equal" - value: "value" + value: "value1" effect: "NoSchedule" ``` ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Exists" effect: "NoSchedule" ``` @@ -76,7 +76,7 @@ tolerations: operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로 모든 것이 톨러레이션 된다. -비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다. +비어있는 `effect` 는 모든 이펙트를 키 `key1` 와 일치시킨다. {{< /note >}} diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index d9f34a202e..0b4bb6e2cc 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -110,7 +110,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre 어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다. 어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다. -어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다. +어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다. 여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다. 이는 다이어그램에 **3**단계로 표시되어 있다. diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index a7e3336fa2..6546aa9735 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -152,7 +152,7 @@ spec: DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. -엔드포인트 객체는 `hostname` 필드를 +엔드포인트 오브젝트는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. {{< note >}} @@ -253,7 +253,7 @@ spec: 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. 병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. -- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. +- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 오브젝트들의 선택적 목록이다. 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, 병합 시 중복되는 항목은 제거된다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 72e077de6c..653993a485 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -22,12 +22,14 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 ## 추가 컨트롤러 +{{% thirdparty-content %}} + * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. * [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. -* [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다. +* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 VMware에서 제공하고 지원한다. * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 76076f5965..be145f78c9 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -214,7 +214,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. {{< /note >}} -# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는) +## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는) 쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다. diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 7526aff98d..8bc6f7b1bf 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -89,7 +89,7 @@ volumeBindingMode: Immediate 등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기 위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은 -[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다. +[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에 있다. 예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부 프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부 diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 5903905d59..58e8821194 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -28,7 +28,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. -* API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다. +* API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다. * `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다. * 쿠버네티스 팀은 `VolumeSnapshot` 베타 버젼의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다. * CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다. @@ -60,7 +60,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}} API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). -퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. +퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. ### 삭제 diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 5c5748e24e..5bbcb0e1c2 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -171,13 +171,17 @@ spec: ``` 파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는 -파드에는 영향을 주지 않는다. 파드는 템플릿 업데이트를 직접 받지 않는다. 대신, -수정된 파드 템플릿과 일치하는 새로운 파드가 생성된다. +파드에는 직접적인 영향을 주지 않는다. 워크로드 리소스의 파드 템플릿을 +변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 한다. -예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 각 디플로이먼트 오브젝트에 대한 현재 -파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트된 경우, 디플로이먼트는 -기존 파드를 제거하고 업데이트된 템플릿을 기반으로 새로운 파드를 생성해야 한다. 각 워크로드 -리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다. +예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재 +파드 템플릿과 일치하는지 확인한다. 스테이트풀셋을 수정하여 파드 템플릿을 +변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작한다. +결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료된다. + +각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다. +스테이트풀셋에 대해 자세히 알아 보려면, +스테이트풀셋 기본 튜토리얼에서 [업데이트 전략](/ko/docs/tutorials/stateful-application/basic-stateful-set/#스테이트풀셋-업데이트하기)을 읽어본다. 노드에서 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}은 파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한 diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index c8224ea76c..a0a3a0ae77 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -284,8 +284,6 @@ graph BT ### 클러스터 수준의 기본 제약 조건 -{{< feature-state for_k8s_version="v1.19" state="beta" >}} - 클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 4b14ad3c80..0582739545 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -1,6 +1,6 @@ --- content_type: concept -title: 쿠버네티스 문서에 기여하기 +title: K8s 문서에 기여하기 linktitle: 기여 main_menu: true no_list: true @@ -8,7 +8,7 @@ weight: 80 card: name: contribute weight: 10 - title: 기여 시작하기 + title: K8s에 기여 시작하기 --- diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 20377994f1..82ef348775 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -30,7 +30,7 @@ cards: button: "튜토리얼 보기" button_path: "/ko/docs/tutorials" - name: setup - title: "클러스터 구축하기" + title: "K8s 클러스터 구축하기" description: "보유한 자원과 요구에 맞게 동작하는 쿠버네티스를 구축한다." button: "쿠버네티스 구축하기" button_path: "/ko/docs/setup" @@ -55,7 +55,7 @@ cards: button: 문서에 기여하기 button_path: "/ko/docs/contribute" - name: release-notes - title: 릴리스 노트 + title: K8s 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. button: "쿠버네티스 다운로드" button_path: "/docs/setup/release/notes" diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index 40d0a37c92..b34f68e392 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -128,7 +128,7 @@ API 서버 인가를 외부 서비스에 노출시킨다. * `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다. * `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다. -이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인 +이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인 일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다. ```bash diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md index 1b7da703dc..4e4c1c2fb8 100644 --- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md @@ -18,95 +18,105 @@ weight: 50 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다. - - 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 - 위한 것이다. - - 사용자 어카운트는 전역을 대상으로 고려된다. - 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다. - 서비스 어카운트는 네임스페이스에 할당된다. - - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, - 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. - 서비스 어카운트 생성은 - 클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록 - 보다 가볍게 만들어졌다. - - 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다. - - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. - 서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에 - 이러한 설정은 이식성이 좋다. +- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 + 위한 것이다. +- 사용자 어카운트는 전역을 대상으로 고려된다. + 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다. +- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, + 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. + 서비스 어카운트 생성은 + 클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 + 보다 가볍게 만들어졌다. +- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다. +- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. + 서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에 + 이러한 설정은 이식성이 좋다. ## 서비스 어카운트 자동화 서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다. - - 서비스 어카운트 어드미션 컨트롤러 - - 토큰 컨트롤러 - - 서비스 어카운트 컨트롤러 +- `ServiceAccount` 어드미션 컨트롤러 +- 토큰 컨트롤러 +- `ServiceAccount` 컨트롤러 -### 서비스 어카운트 어드미션 컨트롤러 +### 서비스어카운트(ServiceAccount) 어드미션 컨트롤러 -파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/) -라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다. +파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는 +플러그인을 통해 구현된다. +이것은 API 서버의 일부이다. 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다. 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다. - 1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다. - 1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다. - 1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다. - 1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다. - 1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다. +1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를 + `default`로 설정한다. +1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면 + 이를 거부한다. +1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의 + `imagePullSecrets`이 파드에 추가된다. +1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의 + `automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우 + 파드에 API 접근 토큰이 포함된 `volume`을 추가한다. +1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우, + `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 + 파드의 각 컨테이너에 `volumeSource`를 추가한다. -v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다. +`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다. 서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다. -[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다. +[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 +자세한 내용을 참조한다. ### 토큰 컨트롤러 -토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는, +토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는, -- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다. -- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다. -- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다. -- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다. +- 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당 + 서비스어카운트 토큰 시크릿을 생성한다. +- 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트 + 토큰 시크릿을 삭제한다. +- 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가 + 존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다. +- 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서 + 참조를 제거한다. -서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다. -개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. -마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다. -공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다. +서비스 어카운트 개인키 파일은 `--service-account-private-key-file` +플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 +한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. +마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를 +`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 +검증하는 데 사용될 것이다. #### 추가적인 API 토큰 생성 -컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다. -서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해 -서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면 +컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다. +서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해 +서비스어카운트를 참조하는 어노테이션과 함께 `kubernetes.io/service-account-token` 유형의 시크릿을 생성하면 컨트롤러가 새로 생성된 토큰으로 갱신한다. -secret.json: +다음은 시크릿에 대한 샘플 구성이다. -```json -{ - "kind": "Secret", - "apiVersion": "v1", - "metadata": { - "name": "mysecretname", - "annotations": { - "kubernetes.io/service-account.name": "myserviceaccount" - } - }, - "type": "kubernetes.io/service-account-token" -} +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecretname + annotations: + kubernetes.io/service-account.name: myserviceaccount +type: kubernetes.io/service-account-token ``` ```shell -kubectl create -f ./secret.json +kubectl create -f ./secret.yaml kubectl describe secret mysecretname ``` -#### 서비스 어카운트 토큰 삭제/무효화 +#### 서비스 어카운트 토큰 시크릿 삭제/무효화 ```shell kubectl delete secret mysecretname ``` -### 서비스 어카운트 컨트롤러 +### 서비스어카운트 컨트롤러 -서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고 -"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다. +서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고 +"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index f5b7fa8dad..bb6f839d86 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -83,8 +83,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | | | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | -| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 | -| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | | | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | | | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | | `DevicePlugins` | `true` | 베타 | 1.10 | | @@ -137,12 +135,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `RuntimeClass` | `true` | 베타 | 1.14 | | | `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 | | `SCTPSupport` | `true` | 베타 | 1.19 | | -| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | -| `ServiceAppProtocol` | `true` | 베타 | 1.19 | | | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | | `ServerSideApply` | `true` | 베타 | 1.16 | | | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | -| `ServiceAppProtocol` | `false` | 알파 | 1.18 | | +| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | +| `ServiceAppProtocol` | `true` | 베타 | 1.19 | | | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | | | `ServiceTopology` | `false` | 알파 | 1.17 | | @@ -209,6 +206,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | | `CustomPodDNS` | `true` | GA | 1.14 | - | +| `CustomResourceDefaulting` | `false` | 알파 | 1.15 | 1.15 | +| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | 1.16 | +| `CustomResourceDefaulting` | `true` | GA | 1.17 | - | | `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 | | `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 | | `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - | diff --git a/content/ko/docs/reference/glossary/api-group.md b/content/ko/docs/reference/glossary/api-group.md new file mode 100644 index 0000000000..0c27d3181e --- /dev/null +++ b/content/ko/docs/reference/glossary/api-group.md @@ -0,0 +1,19 @@ +--- +title: API 그룹(API Group) +id: api-group +date: 2019-09-02 +full_link: /ko/docs/concepts/overview/kubernetes-api/#api-groups +short_description: > + 쿠버네티스 API의 연관된 경로들의 집합. + +aka: +tags: +- fundamental +- architecture +--- +쿠버네티스 API의 연관된 경로들의 집합. + + +API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의 `apiVersion` 필드에 지정된다. + +* 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-groups)을 참조한다. diff --git a/content/ko/docs/reference/glossary/mirror-pod.md b/content/ko/docs/reference/glossary/mirror-pod.md index 1819e74917..62f5b19237 100755 --- a/content/ko/docs/reference/glossary/mirror-pod.md +++ b/content/ko/docs/reference/glossary/mirror-pod.md @@ -3,18 +3,18 @@ title: 미러 파드(Mirror Pod) id: mirror-pod date: 2019-08-06 short_description: > - Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 객체. + Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 오브젝트. aka: tags: - fundamental --- Kubelet이 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}}를 - 표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 객체 + 표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 오브젝트 Kubelet이 설정에서 스태틱 파드를 찾으면, 자동으로 쿠버네티스 -API 서버에 파드 객체 생성을 시도한다. 이렇게 생성된 파드를 +API 서버에 파드 오브젝트 생성을 시도한다. 이렇게 생성된 파드를 API 서버에서 확인할 수는 있지만, API 서버를 통해 제어할 수는 없다. (예를 들어, 미러 파드를 제거하더라도 kubelet 데몬이 해당 파드를 멈추지 않는다.) diff --git a/content/ko/docs/reference/glossary/object.md b/content/ko/docs/reference/glossary/object.md new file mode 100644 index 0000000000..f2226143d6 --- /dev/null +++ b/content/ko/docs/reference/glossary/object.md @@ -0,0 +1,19 @@ +--- +title: 오브젝트(Object) +id: object +date: 2020-12-1 +full_link: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects +short_description: > + 클러스터 상태의 일부를 나타내는 쿠버네티스 시스템의 엔티티이다. +aka: +tags: +- fundamental +--- +쿠버네티스 시스템의 엔티티이다. 쿠버네티스 API가 클러스터의 상태를 나타내기 위해 +사용하는 엔티티이다. + +쿠버네티스 오브젝트는 일반적으로 "의도를 담은 레코드"이다. 당신이 오브젝트를 생성하게 되면, 쿠버네티스 +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 그 아이템이 실제 존재함을 보장하기 위해 +지속적으로 작동한다. +객체를 생성함으로써 당신의 클러스터의 워크로드 해당 부분이 어떻게 보이길 원하는지 쿠버네티스 시스템에 효과적으로 알리는 것이다. +이것은 당신의 클러스터의 의도한 상태이다. diff --git a/content/ko/docs/reference/glossary/uid.md b/content/ko/docs/reference/glossary/uid.md index b04a1be5c8..1cc78e4772 100755 --- a/content/ko/docs/reference/glossary/uid.md +++ b/content/ko/docs/reference/glossary/uid.md @@ -14,5 +14,5 @@ tags: -쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록 상 유사한 개체의 출현을 서로 구분하기 위함이다. +쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index bf3e0cc81d..5e03ead888 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -86,6 +86,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성 kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성 kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성 kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작 + +# "Hello World"를 출력하는 잡(Job) 생성 +kubectl create job hello --image=busybox -- echo "Hello World" + +# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성 +kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World" + kubectl explain pods # 파드 매니페스트 문서를 조회 # stdin으로 다수의 YAML 오브젝트 생성 diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index 6626947c2a..e86a5579b7 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -59,7 +59,7 @@ kubectl [command] [TYPE] [NAME] [flags] * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>` * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).
- 예: `kubectl get pod -f ./pod.yaml` + 예: `kubectl get -f ./pod.yaml` * `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
diff --git a/content/ko/docs/reference/using-api/health-checks.md b/content/ko/docs/reference/using-api/health-checks.md new file mode 100644 index 0000000000..07857ea5d2 --- /dev/null +++ b/content/ko/docs/reference/using-api/health-checks.md @@ -0,0 +1,101 @@ +--- +title: 쿠버네티스 API 헬스(health) 엔드포인트 +content_type: concept +weight: 50 +--- + + +쿠버네티스 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}는 현재 상태를 나타내는 API 엔드포인트를 제공한다. +이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다. + + + +## 헬스를 위한 API 엔드포인트 + +쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(`healthz`, `livez` 와 `readyz`)를 제공한다. +`healthz` 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 `livez` 와 `readyz` 엔드포인트를 사용해야 한다. +`livez` 엔드포인트는 `--livez-grace-period` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 시작 대기 시간을 지정할 수 있다. +`/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다. +API 서버의 `health`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다. +상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다. +아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다. + +다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다. + +모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. +이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다. + +```shell +curl -k https://localhost:6443/livez?verbose +``` + +인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다. + +```shell +kubectl get --raw='/readyz?verbose' +``` + +출력은 다음과 같다. + + [+]ping ok + [+]log ok + [+]etcd ok + [+]poststarthook/start-kube-apiserver-admission-initializer ok + [+]poststarthook/generic-apiserver-start-informers ok + [+]poststarthook/start-apiextensions-informers ok + [+]poststarthook/start-apiextensions-controllers ok + [+]poststarthook/crd-informer-synced ok + [+]poststarthook/bootstrap-controller ok + [+]poststarthook/rbac/bootstrap-roles ok + [+]poststarthook/scheduling/bootstrap-system-priority-classes ok + [+]poststarthook/start-cluster-authentication-info-controller ok + [+]poststarthook/start-kube-aggregator-informers ok + [+]poststarthook/apiservice-registration-controller ok + [+]poststarthook/apiservice-status-available-controller ok + [+]poststarthook/kube-apiserver-autoregistration ok + [+]autoregister-completion ok + [+]poststarthook/apiservice-openapi-controller ok + healthz check passed + +또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다. +쿼리 파라미터는 다음 예와 같이 조합될 수 있다. + +```shell +curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' +``` + +출력에서 etcd 체크가 제외된 것을 보여준다. + + [+]ping ok + [+]log ok + [+]etcd excluded: ok + [+]poststarthook/start-kube-apiserver-admission-initializer ok + [+]poststarthook/generic-apiserver-start-informers ok + [+]poststarthook/start-apiextensions-informers ok + [+]poststarthook/start-apiextensions-controllers ok + [+]poststarthook/crd-informer-synced ok + [+]poststarthook/bootstrap-controller ok + [+]poststarthook/rbac/bootstrap-roles ok + [+]poststarthook/scheduling/bootstrap-system-priority-classes ok + [+]poststarthook/start-cluster-authentication-info-controller ok + [+]poststarthook/start-kube-aggregator-informers ok + [+]poststarthook/apiservice-registration-controller ok + [+]poststarthook/apiservice-status-available-controller ok + [+]poststarthook/kube-apiserver-autoregistration ok + [+]autoregister-completion ok + [+]poststarthook/apiservice-openapi-controller ok + [+]shutdown ok + healthz check passed + +## 개별 헬스 체크 + +{{< feature-state state="alpha" >}} + +각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다. +개별 체크를 위한 스키마는 `/livez/` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. +`` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다. +이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다. + +```shell +curl -k https://localhost:6443/livez/etcd +``` diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index 39efd52b80..6f6dbbae0e 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -1,122 +1,120 @@ --- -title: 대형 클러스터 구축 +title: 대형 클러스터에 대한 고려 사항 weight: 20 --- -## 지원 - -{{< param "version" >}} 버전에서, 쿠버네티스는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는, 다음 기준을 *모두* 만족하는 설정을 지원한다. +클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는 +쿠버네티스 에이전트를 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}(물리 +또는 가상 머신)의 집합이다. +쿠버네티스 {{}}는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는, +쿠버네티스는 다음 기준을 *모두* 만족하는 설정을 수용하도록 설계되었다. +* 노드 당 파드 100 개 이하 * 노드 5000개 이하 * 전체 파드 150000개 이하 * 전체 컨테이너 300000개 이하 -* 노드 당 파드 100개 이하 +노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은 +클러스터 배포 방법에 따라 다르다. -## 설치 +## 클라우드 프로바이더 리소스 쿼터 {#quota-issues} -클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다. +여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해 +고려할 점은 다음과 같다. -보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다. - -하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다. - -큰 쿠버네티스 클러스터를 설정할 때는 다음 이슈들을 고려해야 한다. - -### 쿼터 문제 - -여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해 고려할 점: - -* CPU, IP 등의 쿼터를 늘린다. - * 예를 들어, [GCE의 경우](https://cloud.google.com/compute/docs/resource-quotas) 다음에 관한 쿼터를 늘릴 수 있다. +* 다음과 같은 클라우드 리소스에 대한 쿼터 증가를 요청한다. + * 컴퓨터 인스턴스 * CPU - * VM 인스턴스 - * 전체 영구 디스크 예약 + * 스토리지 볼륨 * 사용 중인 IP 주소 - * 방화벽 규칙 - * 포워딩 규칙 - * 라우트 - * 대상 풀 -* 일부 클라우드 프로바이더는 VM 생성 속도에 상한이 있어, 셋업 스크립트 수행 간 새로운 노드 VM을 생성하는 사이사이에 대기시간이 추가되는 작은 배치가 걸릴 수 있다. + * 패킷 필터링 규칙 세트 + * 로드밸런서 개수 + * 로그 스트림 +* 일부 클라우드 프로바이더는 새로운 인스턴스 생성 속도에 상한이 있어, 클러스터 확장 작업 간 새로운 노드를 일괄적으로 배치하고, 배치 간에 일시 중지한다. + +## 컨트롤 플레인 컴포넌트 + +대규모 클러스터의 경우, 충분한 컴퓨트 및 기타 리소스가 있는 컨트롤 플레인이 +필요하다. + +일반적으로 장애 영역 당 하나 또는 두 개의 컨트롤 플레인 인스턴스를 +실행하고, 해당 인스턴스를 수직으로(vertically) 먼저 확장한 다음 (수직) 규모로 하락하는 +지점에 도달한 후 수평으로(horizontally) 확장한다. + +내결함성을 제공하려면 장애 영역 당 하나 이상의 인스턴스를 실행해야 한다. 쿠버네티스 +노드는 동일한 장애 영역에 있는 컨트롤 플레인 엔드포인트로 트래픽을 +자동으로 조정하지 않는다. 그러나, 클라우드 프로바이더는 이를 수행하기 위한 자체 메커니즘을 가지고 있을 수 있다. + +예를 들어, 관리형 로드 밸런서를 사용하여 장애 영역 _A_ 의 +kubelet 및 파드에서 시작되는 트래픽을 전송하도록 로드 밸런서를 구성하고, 해당 트래픽을 +_A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 컨트롤 플레인 호스트 또는 +엔드포인트 장애 영역 _A_ 이 오프라인이 되면, 영역 _A_ 의 노드에 대한 +모든 컨트롤 플레인 트래픽이 이제 영역간에 전송되고 있음을 의미한다. 각 영역에서 여러 컨트롤 플레인 호스트를 +실행하면 가용성이 낮아진다. ### etcd 저장소 -큰 클러스터의 성능 향상을 위해, 우리는 이벤트를 각각의 전용 etcd 인스턴스에 저장한다. +큰 클러스터의 성능 향상을 위해, 사용자는 이벤트 오브젝트를 각각의 +전용 etcd 인스턴스에 저장한다. 클러스터 생성시의 부가 스트립트이다. +클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다. * 추가 ectd 인스턴스 시작 및 설정 -* 이벤트를 저장하기 위한 api-server 설정 +* 이벤트를 저장하기 위한 {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} 설정 -### 마스터 크기와 마스터 구성 요소 +## 애드온 리소스 -GCE/구글 쿠버네티스 엔진 및 AWS에서, `kube-up`은 클러스터 내 노드의 수에 따라 마스터용으로 적합한 VM 크기를 자동으로 설정한다. -기타 다른 프로바이더의 경우, 수동으로 설정해야 한다. 참고로 GCE에 적용하는 크기는 다음과 같다. +쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은 +파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을 +최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용되는 것과 마찬가지로 +{{< glossary_tooltip text="애드온" term_id="addons" >}}에도 적용될 수 있으며 +적용되어야 한다. -* 1-5 노드: n1-standard-1 -* 6-10 노드: n1-standard-2 -* 11-100 노드: n1-standard-4 -* 101-250 노드: n1-standard-8 -* 251-500 노드: n1-standard-16 -* 500 노드 이상: n1-standard-32 - -AWS에 적용하는 크기는 다음과 같다. - -* 1-5 노드: m3.medium -* 6-10 노드: m3.large -* 11-100 노드: m3.xlarge -* 101-250 노드: m3.2xlarge -* 251-500 노드: c4.4xlarge -* 500 노드 이상: c4.8xlarge - -{{< note >}} -구글 쿠버네티스 엔진에서, 마스터 노드 크기는 클러스터의 크기에 따라 자동적으로 조절된다. 자세한 사항은 [이 블로그 글](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html)을 참고하라. - -AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 그대로이며 변경되지 않는다. 이후에 클러스터를 스케일 업/다운하거나 수동으로 노드를 추가/제거하거나 클러스터 오토스케일러를 사용하더라도 그렇다. -{{< /note >}} - -### 애드온 자원 - -[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](https://pr.k8s.io/10653/files)과 [#10778](https://pr.k8s.io/10778/files) 참고). - -예시: +예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다. ```yaml + ... containers: - name: fluentd-cloud-logging - image: k8s.gcr.io/fluentd-gcp:1.16 + image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi ``` -힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](https://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](https://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다. +애드온의 기본 제한은 일반적으로 중소형 쿠버네티스 클러스터에서 +각 애드온을 실행한 경험에서 수집된 데이터를 기반으로 한다. 대규모 클러스터에서 +실행할 때, 애드온은 종종 기본 제한보다 많은 리소스를 소비한다. +이러한 값을 조정하지 않고 대규모 클러스터를 배포하면, 애드온이 +메모리 제한에 계속 도달하기 때문에 지속적으로 종료될 수 있다. +또는, 애드온이 실행될 수 있지만 CPU 시간 슬라이스 제한으로 인해 +성능이 저하된다. -많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라. +클러스터 애드온 리소스 문제가 발생하지 않도록, 노드가 많은 클러스터를 +만들 때, 다음 사항을 고려한다. -* 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다). - * [InfluxDB와 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, 사이드카](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) -* 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자): - * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) -* 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다). - * [ElasticSearch 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [GCP 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) +* 일부 애드온은 수직으로 확장된다. 클러스터 또는 전체 장애 영역을 + 제공하는 애드온 레플리카가 하나 있다. 이러한 애드온의 경우, 클러스터를 확장할 때 + 요청과 제한을 늘린다. +* 많은 애드온은 수평으로 확장된다. 더 많은 파드를 실행하여 용량을 추가하지만, + 매우 큰 클러스터에서는 CPU 또는 메모리 제한을 약간 높여야 할 수도 있다. + VerticalPodAutoscaler는 _recommender_ 모드에서 실행되어 요청 및 제한에 대한 + 제안 수치를 제공할 수 있다. +* 일부 애드온은 {{< glossary_tooltip text="데몬셋(DaemonSet)" + term_id="daemonset" >}}에 의해 제어되는 노드 당 하나의 복사본으로 실행된다(예: 노드 수준 로그 수집기). 수평 + 확장 애드온의 경우와 유사하게, CPU 또는 메모리 제한을 약간 높여야 + 할 수도 있다. -힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](https://issue.k8s.io/16185)과 -[#22940](https://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, - 힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자. +## {{% heading "whatsnext" %}} -애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 -[컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라. +`VerticalPodAutoscaler` 는 리소스 요청 및 파드 제한을 관리하는 데 도움이 되도록 +클러스터에 배포할 수 있는 사용자 정의 리소스이다. +클러스터에 중요한 애드온을 포함하여 클러스터 컴포넌트를 확장하는 방법에 대한 +자세한 내용은 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)를 +방문하여 배워본다. -### 시작 시 사소한 노드 오류 허용 - -다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고 -`kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다. -현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ), -`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다. -이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다. -실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다. +[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는 +여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는 +노드 수를 실행할 수 있도록 도와준다. diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md index 9e9a65bee9..c2f919968f 100644 --- a/content/ko/docs/setup/best-practices/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -22,7 +22,11 @@ weight: 30 노드 적합성 테스트는 다음 순서로 진행된다. -1. 테스트 프레임워크는 Kublet을 테스트하기 위해 로컬 마스터를 시작하기 때문에, Kublet이 localhost를 가르키도록 `--api-servers="http://localhost:8080"`를 사용한다. 고려해야 할 다른 Kubelet 플래그들은 다음과 같다. +1. kubelet에 대한 `--kubeconfig` 옵션의 값을 계산한다. 예를 들면, 다음과 같다. + `--kubeconfig = / var / lib / kubelet / config.yaml`. + 테스트 프레임워크는 kubelet을 테스트하기 위해 로컬 컨트롤 플레인을 시작하기 때문에, + `http://localhost:8080` 을 API 서버의 URL로 사용한다. + 사용할 수 있는 kubelet 커맨드 라인 파라미터가 몇 개 있다. * `--pod-cidr`: `kubenet`을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) `--pod-cidr=10.180.0.0/24`. * `--cloud-provider`: `--cloud-provider=gce`를 사용 중이라면, 테스트 실행 시에는 제거해야 한다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 5f6051d59c..bbf5de5d82 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -1,7 +1,7 @@ --- title: 컨테이너 런타임 content_type: concept -weight: 10 +weight: 20 --- diff --git a/content/ko/docs/setup/production-environment/turnkey/_index.md b/content/ko/docs/setup/production-environment/turnkey/_index.md deleted file mode 100644 index 652a2f3f63..0000000000 --- a/content/ko/docs/setup/production-environment/turnkey/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: 턴키 클라우드 솔루션 -weight: 30 ---- diff --git a/content/ko/docs/setup/release/version-skew-policy.md b/content/ko/docs/setup/release/version-skew-policy.md new file mode 100644 index 0000000000..feb675f8ba --- /dev/null +++ b/content/ko/docs/setup/release/version-skew-policy.md @@ -0,0 +1,154 @@ +--- +title: 쿠버네티스 버전 및 버전 차이(skew) 지원 정책 +content_type: concept +weight: 30 +--- + + +이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다. +특정 클러스터 배포 도구는 버전 차이에 대한 추가적인 제한을 설정할 수 있다. + + + + +## 지원되는 버전 + +쿠버네티스 버전은 **x.y.z**로 표현되는데, +여기서 **x**는 메이저 버전, **y**는 마이너 버전, **z**는 [시맨틱 버전](https://semver.org/) 용어에 따른 패치 버전이다. +자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다. + +쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다. + +보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다. +패치 릴리스는 각 브랜치별로 [정기적인 주기](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다. + +[릴리스 관리자](https://git.k8s.io/sig-release/release-managers.md) 그룹이 이러한 결정 권한을 가진다. + +자세한 내용은 쿠버네티스 [패치 릴리스](https://git.k8s.io/sig-release/releases/patch-releases.md) 페이지를 참조한다. + +## 지원되는 버전 차이 + +### kube-apiserver + +[고가용성(HA) 클러스터](/docs/setup/production-environment/tools/kubeadm/high-availability/)에서 최신 및 가장 오래된 `kube-apiserver` 인스턴스가 각각 한 단계 마이너 버전 내에 있어야 한다. + +예: + +* 최신 `kube-apiserver`는 **{{< skew latestVersion >}}** 이다. +* 다른 `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 을 지원한다. + +### kubelet + +`kubelet`은 `kube-apiserver`보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원한다. + +예: + +* `kube-apiserver`가 **{{< skew latestVersion >}}** 이다. +* `kubelet`은 **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}** 및 **{{< skew oldestMinorVersion >}}** 을 지원한다. + +{{< note >}} +HA 클러스터의 `kube-apiserver` 인스턴스 사이에 버전 차이가 있으면 허용되는 `kubelet` 버전의 범위도 줄어든다. +{{}} + +예: + +* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다. +* `kubelet`은 **{{< skew prevMinorVersion >}}** 및 **{{< skew oldestMinorVersion >}}** 을 지원한다(**{{< skew latestVersion >}}** 는 `kube-apiserver`의 **{{< skew prevMinorVersion >}}** 인스턴스보다 최신 버전이기 때문에 지원하지 않는다). + +### kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager + +`kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 그들과 통신하는 `kube-apiserver` 인스턴스보다 최신 버전이면 안 된다. `kube-apiserver` 마이너 버전과 일치할 것으로 예상하지만, 최대 한 단계 낮은 마이너 버전까지는 허용한다(실시간 업그레이드를 지원하기 위해서). + +예: + +* `kube-apiserver`은 **{{< skew latestVersion >}}** 이다. +* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 **{{< skew latestVersion >}}** 과 **{{< skew prevMinorVersion >}}** 을 지원한다. + +{{< note >}} +HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 존재하고 이러한 구성 요소가 클러스터의 모든 `kube-apiserver` 인스턴스와 통신할 수 있는 경우(예를 들어, 로드 밸런서를 통해서)에는 구성 요소의 허용하는 버전의 범위도 줄어든다. +{{< /note >}} + +예: + +* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다. +* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 모든 `kube-apiserver` 인스턴스로 라우팅하는 로드 밸런서와 통신한다. +* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 **{{< skew prevMinorVersion >}}** 에서 지원한다(**{{< skew latestVersion >}}** 는 `kube-apiserver` 인스턴스의 **{{< skew prevMinorVersion >}}** 버전보다 최신이기 때문에 지원하지 않는다). + +### kubectl + +`kubectl`은 `kube-apiserver`의 한 단계 마이너 버전(이전 또는 최신) 내에서 지원한다. + +예: + +* `kube-apiserver`은 **{{< skew latestVersion >}}** 이다. +* `kubectl`은 **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 을 지원한다. + +{{< note >}} +HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 있으면 지원되는 `kubectl` 버전의 범위도 줄어든다. +{{< /note >}} + +예: + +* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다. +* `kubectl`은 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 에서 지원한다(다른 버전은 `kube-apiserver` 인스턴스 중에 한 단계 이상의 마이너 버전 차이가 난다). + +## 지원되는 구성 요소 업그레이드 순서 + +구성요소 간 지원되는 버전 차이는 구성요소를 업그레이드하는 순서에 영향을 준다. +이 섹션에서는 기존 클러스터를 버전 **{{< skew prevMinorVersion >}}** 에서 버전 **{{< skew latestVersion >}}** 로 전환하기 위해 구성 요소를 업그레이드하는 순서를 설명한다. + +### kube-apiserver + +사전 요구 사항: + +* 단일 인스턴스 클러스터에서 기존 `kube-apiserver` 인스턴스는 **{{< skew prevMinorVersion >}}** 이어야 한다. +* HA 클러스터에서 모든 `kube-apiserver` 인스턴스는 **{{< skew prevMinorVersion >}}** 또는 **{{< skew latestVersion >}}** 이어야 한다(이것은 `kube-apiserver` 인스턴스 간의 가장 최신과 오래된 버전의 차이를 최대 1개의 마이너 버전의 차이로 보장한다). +* 이 서버와 통신하는 `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`의 버전은 **{{< skew prevMinorVersion >}}** 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니고 새로운 API서버 버전의 마이너 1개의 버전 내에 있음을 보장한다). +* 모든 `kubelet` 인스턴스는 버전 **{{< skew prevMinorVersion >}}** 또는 **{{< skew oldestMinorVersion >}}** 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니며, 새로운 API서버 버전의 2개의 마이너 버전 내에 있음을 보장한다). +* 등록된 어드미션 웹훅은 새로운 `kube-apiserver` 인스턴스가 전송하는 데이터를 처리할 수 있다: + * `ValidatingWebhookConfiguration` 그리고 `MutatingWebhookConfiguration` 오브젝트는 **{{< skew latestVersion >}}** 에 추가된 REST 리소스의 새 버전을 포함하도록 업데이트한다(또는 v1.15 이상에서 사용 가능한 [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) 설정을 사용). + * 웹훅은 자신에게 전송될 REST리소스의 새버전과 **{{< skew latestVersion >}}** 에서 기존 버전에 추가된 새로운 필드를 처리할 수 있다. + +`kube-apiserver`를 **{{< skew latestVersion >}}** 으로 업그레이드 + +{{< note >}} +[API 지원 중단](/docs/reference/using-api/deprecation-policy/) 및 +[API 변경 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) +에 대한 프로젝트 정책에서는 단일 클러스터일지라도 업그레이드할 때 `kube-apiserver`의 마이너 버전을 건너뛰지 않도록 요구한다. +{{< /note >}} + +### kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager + +사전 요구 사항: + +* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 이여야 한다(HA 클러스터에서 `kube-apiserver` 인스턴스와 통신할 수 있는 구성 요소를 업그레이드 전에 모든 `kube-apiserver` 인스턴스는 업그레이드되어야 한다). + +`kube-controller-manager`, `kube-scheduler` 및 `cloud-controller-manager` 를 **{{< skew latestVersion >}}** 으로 업그레이드한다. + +### kubelet + +사전 요구 사항: + +* `kubelet`과 통신하는 `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 이어야 한다. + +필요에 따라서 `kubelet` 인스턴스를 **{{< skew latestVersion >}}** 으로 업그레이드할 수 있다(또는 **{{< skew prevMinorVersion >}}** 아니면 **{{< skew oldestMinorVersion >}}** 으로 유지할 수 있음). + +{{< warning >}} +클러스터 안의 `kubelet` 인스턴스를 `kube-apiserver`의 버전보다 2단계 낮은 버전으로 실행하는 것을 권장하지 않는다: + +* `kube-apiserver`를 업그레이드한다면 한 단계 낮은 버전으로 업그레이드해야 한다. +* 이것은 관리되고 있는 3단계의 마이너 버전보다 낮은 `kubelet`을 실행할 가능성을 높인다. +{{}} + +### kube-proxy + +* `kube-proxy`는 반드시 `kubelet`과 동일한 마이너 버전이어야 한다. +* `kube-proxy`는 반드시 `kube-apiserver` 보다 최신 버전이면 안 된다. +* `kube-proxy`는 `kube-apiserver` 보다 2단계 낮은 마이너 버전 이내여야 한다. + +예: + +`kube-proxy` 버전이 **{{< skew oldestMinorVersion >}}** 인 경우: + +* `kubelet` 버전도 반드시 **{{< skew oldestMinorVersion >}}** 와 동일한 마이너 버전이어야 한다. +* `kube-apiserver` 버전은 반드시 **{{< skew oldestMinorVersion >}}** 에서 **{{< skew latestVersion >}}** 사이 이어야 한다. diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md deleted file mode 100644 index 0f241c87f4..0000000000 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ /dev/null @@ -1,217 +0,0 @@ ---- -title: 클러스터 관리 -content_type: concept ---- - - - -이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, -클러스터의 마스터와 워커 노드들의 업그레이드, -노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 -쿠버네티스 API 버전 업그레이드. - - - -## 클러스터 생성과 설정 - -일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/ko/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다. - -## 클러스터 업그레이드 - -클러스터 업그레이드 상태의 현황은 제공자에 따라 달라지며, 몇몇 릴리스들은 업그레이드에 각별한 주의를 요하기도 한다. 관리자들에게는 클러스터 업그레이드에 앞서 [릴리스 노트](https://git.k8s.io/kubernetes/CHANGELOG/README.md)와 버전에 맞는 업그레이드 노트 모두를 검토하도록 권장하고 있다. - -### Azure Kubernetes Service (AKS) 클러스터 업그레이드 - -Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 -현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다. - -### Google Compute Engine 클러스터 업그레이드 - -Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 -재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 -동일한 Persistent Disk(PD)를 유지한다. - -GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 -순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 -레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다. - -open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다. - -`cluster/gce/upgrade.sh -h`를 실행하여 사용법을 알아볼 수 있다. - -예를 들어, 마스터만 특정 버전(v1.0.2)로 업그레이드하려고 한다면 다음과 같이 커맨드를 사용한다. - -```shell -cluster/gce/upgrade.sh -M v1.0.2 -``` - -이 대신에, 전체 클러스터를 최신 안정 릴리스로 업그레이드하려고 한다면 다음과 같이 커맨드를 사용한다. - -```shell -cluster/gce/upgrade.sh release/stable -``` - -### Google Kubernetes Engine 클러스터 업그레이드 - -Google Kubernetes Engine은 자동으로 마스터 구성요소들(예. `kube-apiserver`, `kube-scheduler`)을 최신 버전으로 업데이트한다. 이는 운영체제와 마스터 상에서 동작하는 다른 구성요소들의 업그레이드를 처리하기도 한다. - -노드 업그레이드 프로세스는 사용자가 직접 시작하는 방식이며 [Google Kubernetes Engine 문서](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)에 설명되어 있다. - -### Amazon EKS 클러스터 업그레이드 -Amazon EKS 클러스터는 eksctl, AWS 관리 콘솔, AWS CLI를 사용해서 마스터 구성요소를 업그레이드할 수 있다. 프로세스는 사용자가 시작하며 [Amazon EKS 문서](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)에 설명되어 있다. - -### Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) 클러스터 업그레이드 - -Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레인을 가질 수 있도록 사용자를 대신하여 Oracle 컨트롤 플레인 내에 마스터 노드들의 세트를 (그리고 etcd 노드들과 같은 관련 쿠버네티스 인프라스트럭처를) 생성하고 관리한다. 또한 이 마스터 노드들을 다운타임 없이 쿠버네티스 신규 버전으로 유연하게 업그레이드할 수도 있다. 이 기능들은 [OKE 문서](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)에 설명되어 있다. - -### 다른 플랫폼들의 클러스터 업그레이드 - -다른 제공자들과 도구들은 업그레이드를 다른 방식으로 관리한다. 이들의 업그레이드를 위해서는 이들의 주요 문서를 참조하기를 권장한다. - -* [kops](https://github.com/kubernetes/kops) -* [kubespray](https://github.com/kubernetes-sigs/kubespray) -* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html) -* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) -* ... - -위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) -페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다. - -## 클러스터 크기 재조정 - -[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 -클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. -GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. -[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 -`Compute > Compute Engine > Instance groups > your group > Edit group`에서 -인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다. - -```shell -gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE -``` - -인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에 -Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다. -사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다. - -다른 환경에서는 사용자가 직접 머신을 구성하고 어떤 머신에서 API 서버가 동작하는지를 Kubelet에 알려줘야 할 수도 있다. - -### Azure Kubernetes Service (AKS) 클러스터 크기 재조정 - -Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며 -[Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서 -이를 설명하고 있다. - - -### 클러스터 오토스케일링 - -GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 -재조정하도록 클러스터를 구성할 수 있다. - -[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 -사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. -이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. -여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 -다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다. - -Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 -추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다. - -Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 -더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다. - -Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다. - -GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. -cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다. - -* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다. -* `KUBE_AUTOSCALER_MIN_NODES` - 클러스터 노드들의 최소 개수. -* `KUBE_AUTOSCALER_MAX_NODES` - 클러스터 노드들의 최대 개수. - -예제: - -```shell -KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh -``` - -Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 -생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 -전달하여 cluster autoscaler를 구성할 수 있다. - -예제: - -```shell -gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5 -``` - -```shell -gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15 -``` - -**Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.** - -cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 -autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) -문서를 참조하기를 바란다. - -## 노드 유지보수 - -(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, -Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 -(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) -노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 -레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 -복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다. - -만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다. - -노드에 스케줄할 수 없도록 표시하면서 해당 노드 상의 모든 파드들을 자연스럽게 종료하기 위해 `kubectl drain`을 사용한다. - -```shell -kubectl drain $NODENAME -``` - -이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다. - -레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다. - -레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다. - -해당 노드에 유지보수 작업을 수행한다. - -해당 노드가 다시 스케줄될 수 있도록 한다. - -```shell -kubectl uncordon $NODENAME -``` - -해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 -자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; -이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) -상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라. - -## 고급 주제들 - -### 클러스터에서 API 버전을 ON/OFF 하기 - -특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 -전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. -예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. -이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`) - -### 클러스터에서 스토리지 API 버전을 변경 - -클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다. -지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 -쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다. - -### 구성 파일을 신규 API 버전으로 변경 - -다른 API 버전들 간에 구성 파일을 전환하는데 `kubectl convert` 커맨드를 사용할 수 있다. - -```shell -kubectl convert -f pod.yaml --output-version v1 -``` - -옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index fef1abead5..0294db62ec 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -137,7 +137,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow ### 윈도우 워커 노드 조인(joining) {{< note >}} `Containers` 기능을 설치하고 도커를 설치해야 한다. -[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)에서 설치에 대한 내용을 참고할 수 있다. +[윈도우 서버에 Docker Engine - Enterprise 설치](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 설치에 대한 내용을 참고할 수 있다. {{< /note >}} {{< note >}} diff --git a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md index 2d1d482585..57e0a94b40 100644 --- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md @@ -45,8 +45,8 @@ kubectl create namespace qos-example 파드에 Guaranteed QoS 클래스 할당을 위한 전제 조건은 다음과 같다. -* 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다. -* 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다. +* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다. +* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다. 이것은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과 메모리 요청량을 갖고 있고, 200MiB로 동일하다. 해당 컨테이너는 CPU 상한과 CPU 요청량을 가지며, 700 milliCPU로 동일하다. diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 4efe37f77b..1f640005f0 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -45,7 +45,7 @@ kubectl describe pods ${POD_NAME} 사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우 몇 가지 방법을 시도할 수 있다. -* 클러스터에 [노드를 더 추가하기](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-크기-재조정). +* 클러스터에 노드를 더 추가하기. * pending 상태인 파드를 위한 공간을 확보하기 위해 [불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination) diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index d3b06d2703..a9db844f06 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -29,7 +29,7 @@ kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네 플러그인 관리자이다. {{< caution >}} -Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수 있는 kubectl 플러그인은 +Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사용할 수 있는 kubectl 플러그인은 보안 감사를 받지 않는다. 써드파티 플러그인은 시스템에서 실행되는 임의의 프로그램이므로, 사용자는 이를 인지한 상태에서 설치하고 실행해야 한다. {{< /caution >}} @@ -42,7 +42,7 @@ Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수 서로의 이름과 겹치는 유효한 플러그인 파일에 대한 경고도 포함된다. [Krew](https://krew.dev/)를 사용하여 커뮤니티가 관리하는 -[플러그인 인덱스](https://index.krew.dev/)에서 `kubectl` +[플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)에서 `kubectl` 플러그인을 검색하고 설치할 수 있다. #### 제한 사항 @@ -351,7 +351,7 @@ CLI 런타임 리포지터리에 제공된 도구 사용법의 예제는 방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에 단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다. Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록 -[플러그인 인덱스](https://index.krew.dev/)를 +[플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 유지 관리한다. @@ -384,5 +384,3 @@ kubectl 플러그인의 배포 패키지를 궁금한 사항이 있으면, [SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다. * kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다. - - diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md index a2c43f3321..8bb7ab89f2 100644 --- a/content/ko/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -44,7 +44,7 @@ kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아 kubectl delete -f --cascade=false ``` -`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. +`kubectl delete` 에 `--cascade=false` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. ```shell kubectl delete pods -l app=myapp diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index b81329c24a..b4ca1826d6 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -16,29 +16,27 @@ Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 ## {{% heading "prerequisites" %}} - 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭-서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. -Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. -메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. +[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 +[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다. +Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면, +[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, -버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. -또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. +버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 +사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. 마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우, -버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다. +버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 +메트릭 API와 통신이 가능해야 한다. 자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다. - - ## php-apache 서버 구동 및 노출 -Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. -Dockerfile은 다음과 같다. +Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다. -``` +```dockerfile FROM php:5-apache COPY index.php /var/www/html/index.php RUN chmod a+rx index.php @@ -46,7 +44,7 @@ RUN chmod a+rx index.php index.php는 CPU 과부하 연산을 수행한다. -``` +```php }} - 다음의 명령어를 실행한다. + ```shell kubectl apply -f https://k8s.io/examples/application/php-apache.yaml ``` + ``` deployment.apps/php-apache created service/php-apache created @@ -85,6 +84,7 @@ service/php-apache created ```shell kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 ``` + ``` horizontalpodautoscaler.autoscaling/php-apache autoscaled ``` @@ -94,10 +94,10 @@ horizontalpodautoscaler.autoscaling/php-apache autoscaled ```shell kubectl get hpa ``` + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s - ``` 아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다 (``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다). @@ -116,10 +116,10 @@ kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin ```shell kubectl get hpa ``` + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m - ``` CPU 소비가 305%까지 증가하였다. @@ -128,6 +128,7 @@ CPU 소비가 305%까지 증가하였다. ```shell kubectl get deployment php-apache ``` + ``` NAME READY UP-TO-DATE AVAILABLE AGE php-apache 7/7 7 7 19m @@ -151,6 +152,7 @@ php-apache 7/7 7 7 19m ```shell kubectl get hpa ``` + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m @@ -159,6 +161,7 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 ```shell kubectl get deployment php-apache ``` + ``` NAME READY UP-TO-DATE AVAILABLE AGE php-apache 1/1 1 1 27m @@ -170,8 +173,6 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 레플리카 오토스케일링은 몇 분 정도 소요된다. {{< /note >}} - - ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링 @@ -417,7 +418,8 @@ HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl des ```shell kubectl describe hpa cm-test ``` -```shell + +``` Name: cm-test Namespace: prom Labels: @@ -472,6 +474,7 @@ HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 ```shell kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml ``` + ``` horizontalpodautoscaler.autoscaling/php-apache created ``` diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 5afca02371..6f018a283e 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -434,7 +434,14 @@ behavior: selectPolicy: Disabled ``` +## 암시적 유지 관리 모드 비활성화 +HPA 구성 자체를 변경할 필요없이 대상에 대한 +HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한 +레플리카 수가 0으로 설정되고, HPA의 최소 레플리카 수가 0 보다 크면, 대상의 +의도한 레플리카 수 또는 HPA의 최소 레플리카 수를 수동으로 조정하여 +다시 활성화할 때까지 HPA는 대상 조정을 +중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정). ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tutorials/configuration/configure-java-microservice/_index.md b/content/ko/docs/tutorials/configuration/configure-java-microservice/_index.md new file mode 100644 index 0000000000..2c5ff0b7d7 --- /dev/null +++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/_index.md @@ -0,0 +1,4 @@ +--- +title: "예제: Java 마이크로서비스 구성하기" +weight: 10 +--- diff --git a/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html new file mode 100644 index 0000000000..3f61c6fa52 --- /dev/null +++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html @@ -0,0 +1,30 @@ +--- +title: "대화형 튜토리얼 - Java 마이크로서비스 구성하기" +weight: 20 +--- + + + + + + + + + + + +
+ +
+
+
+ 터미널 화면을 조작하려면, 데스크톱/태블릿 버전을 사용하기 바란다. +
+
+
+
+ +
+ + + diff --git a/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md new file mode 100644 index 0000000000..5cb55ec401 --- /dev/null +++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md @@ -0,0 +1,39 @@ +--- +title: "MicroProfile, 컨피그맵(ConfigMaps) 및 시크릿(Secrets)을 사용하여 구성 외부화(externalizing)" +content_type: tutorial +weight: 10 +--- + + + +이 튜토리얼에서는 마이크로서비스의 구성을 외부화하는 방법과 이유를 알아본다. 특히, 쿠버네티스 컨피그맵과 시크릿을 사용하여 환경 변수를 설정한 다음 MicroProfile Config를 이용한 사용 방법을 배운다. + + +## {{% heading "prerequisites" %}} + +### 쿠버네티스 컨피그맵 및 시크릿 생성하기 +쿠버네티스에서 도커 컨테이너에 대한 환경 변수를 설정하는 방법에는 Dockerfile, kubernetes.yml, 쿠버네티스 컨피그맵 및 쿠버네티스 시크릿이 있다. 이 튜토리얼에서는 사용자의 마이크로서비스에 값을 주입하기 위한 환경 변수를 설정하기 위해 후자의 두 가지를 사용하는 방법에 대해 배운다. 컨피그맵 및 시크릿을 사용할 때의 이점 중 하나는 여러 다른 컨테이너에 대해 서로 다른 환경 변수에 할당되는 것을 포함하여, 여러 컨테이너에서 다시 사용할 수 있다는 것이다. + +컨피그맵은 기밀이 아닌 키-값 쌍을 저장하는 API 오브젝트이다. 대화형 튜토리얼에서는 컨피그맵을 사용하여 애플리케이션의 이름을 저장하는 방법을 배운다. 컨피그맵에 대한 자세한 정보는 [여기](/docs/tasks/configure-pod-container/configure-pod-configmap/)에서 문서를 찾을 수 있다. + +시크릿은 키-값 쌍을 저장하는 데도 사용되지만, 기밀/민감한 정보를 위한 것이며 Base64 인코딩을 사용하여 저장된다는 점에서 컨피그맵과 다르다. 따라서 시크릿은 자격 증명, 키 및 토큰과 같은 항목을 저장하는 데 적합한 선택이 된다. 이 내용은 대화형 튜토리얼에서 수행할 것이다. 시크릿에 대한 자세한 내용은 [여기](/ko/docs/concepts/configuration/secret/)에서 문서를 찾을 수 있다. + + +### 코드로부터 구성 외부화 +구성은 일반적으로 환경에 따라 변경되기 때문에, 외부화된 애플리케이션 구성(externalized application configuration)은 유용하다. 이를 이루기 위해, Java의 CDI(콘텍스트와 의존성 주입) 및 MicroProfile Config를 사용한다. MicroProfile Config는 클라우드 네이티브 마이크로서비스를 개발하고 배포하기 위한 개방형 Java 기술 세트인 MicroProfile의 기능이다. + +CDI는 느슨하게 결합된 협업 빈(beans)을 통해 애플리케이션을 어셈블할 수 있는 표준 종속성 주입(standard dependency injection) 기능을 제공한다. MicroProfile Config는 애플리케이션, 런타임 및 환경을 포함한 다양한 소스에서 구성 속성을 가져오는 표준 방법을 앱과 마이크로서비스에 제공한다. 소스의 정의된 우선순위에 따라 속성은 애플리케이션이 API를 통해 접근할 수 있는 단일 속성 집합으로 자동 결합된다. 대화형 튜토리얼에서는 CDI와 MicroProfile을 함께 사용하여 쿠버네티스 컨피그맵 및 시크릿을 통한 외부 제공 속성을 검색하고 애플리케이션 코드에 삽입한다. + +많은 오픈 소스 프레임워크와 런타임이 MicroProfile Config를 구현하고 지원한다. 대화형 튜토리얼을 통해 클라우드 네이티브 앱과 마이크로서비스를 빌드하고 실행하기 위한 유연한 오픈 소스 Java 런타임인 ​​Open Liberty를 사용하게 될 것이다. 그러나, 모든 MicroProfile 호환 런타임을 대신 사용할 수 있다. + + +## {{% heading "objectives" %}} + +* 쿠버네티스 컨피그맵 및 시크릿 생성 +* MicroProfile Config를 사용하여 마이크로서비스 구성 주입 + + + + +## 예제: MicroProfile, 컨피그맵 및 시크릿를 사용하여 구성 외부화 +### [대화형 튜토리얼 시작](/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index bb28639e83..34095ef424 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -65,7 +65,7 @@ resources: EOF ``` -컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉터리를 적용한다. +컨피그 맵과 파드 오브젝트를 생성하도록 kustomization 디렉터리를 적용한다. ```shell kubectl apply -k . diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index d9baf3a832..4be0e94231 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -1,6 +1,7 @@ --- title: 쿠버네티스 기초 학습 linkTitle: 쿠버네티스 기초 학습 +no_list: true weight: 10 card: name: tutorials diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 7c3721d72c..5c27b55183 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -76,7 +76,7 @@ MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필 ## kustomization.yaml 생성하기 ### 시크릿 생성자 추가 -[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다. +[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 오브젝트이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 오브젝트를 관리한다. `kustomization.yaml`의 제너레이터로 시크릿을 생성할 수 있다. 다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다. @@ -131,7 +131,7 @@ EOF kubectl apply -k ./ ``` -이제 모든 개체가 존재하는지 확인할 수 있다. +이제 모든 오브젝트가 존재하는지 확인할 수 있다. 1. 시크릿이 존재하는지 다음 명령어를 실행하여 확인한다. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 8e17a85527..77f2ca8c33 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -18,7 +18,7 @@ weight: 40 - [파드](/ko/docs/concepts/workloads/pods/) - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) - [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) -- [퍼시스턴트볼륨](/ko/docs/concepts/storage/volumes/) +- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) - [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets) @@ -38,7 +38,7 @@ weight: 40 이 튜토리얼을 마치면 다음에 대해 알게 된다. - 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가. -- 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가. +- 어떻게 앙상블을 일관되게 설정하는가. - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. - 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. @@ -761,7 +761,7 @@ fi kubectl get pod -w -l app=zk ``` -다른 창에서 `zk-0` 파드의 파일시스템에서 `zkOk.sh` 스크립트를 삭제하기 위해 다음 명령어를 이용하자. +다른 창에서 `zk-0` 파드의 파일시스템에서 `zookeeper-ready` 스크립트를 삭제하기 위해 다음 명령어를 이용하자. ```shell kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready diff --git a/content/ko/training/_index.html b/content/ko/training/_index.html index a46e95cb85..ff24428664 100644 --- a/content/ko/training/_index.html +++ b/content/ko/training/_index.html @@ -10,16 +10,19 @@ class: training
-
- -
-
- -

클라우드 네이티브 커리어를 구축하세요

쿠버네티스는 클라우드 네이티브 무브먼트의 핵심입니다. 리눅스 재단이 제공하는 교육과 인증 프로그램을 통해 커리어에 투자하고, 쿠버네티스를 배우며, 클라우드 네이티브 프로젝트를 성공적으로 수행하세요.

+
+ +
+
+ +
+
+ +
@@ -74,31 +77,36 @@ class: training -
+
-
-

쿠버네티스 공인 자격 획득하기

-
+

쿠버네티스 공인 자격 획득하기

-
공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD)

공인 쿠버네티스 애플리케이션 개발자 시험은 사용자가 쿠버네티스의 클라우드 네이티브 애플리케이션을 디자인, 구축, 구성과 노출을 할 수 있음을 인증합니다.

+

CKAD는 애플리케이션 리소스를 정의하고 핵심 기본 요소를 사용하여 쿠버네티스에서 확장 가능한 애플리케이션 및 도구를 빌드, 모니터링하고 문제를 해결합니다.


인증으로 이동하기 -
-
공인 쿠버네티스 관리자(Certified Kubernetes Administrator, CKA)

공인 쿠버네티스 관리자(CKA) 프로그램은 CKA가 쿠버네티스 관리자 직무을 수행할 수 있는 기술, 지식과 역량을 갖추고 있음을 보장합니다.

+

공인 쿠버네티스 관리자는 기본 설치를 수행하고 프로덕션 등급의 쿠버네티스 클러스터를 구성하고 관리하는 능력을 보여줍니다.


인증으로 이동하기 -
+
+
+
+ 공인 쿠버네티스 보안 전문가(Certified Kubernetes Security Specialist, CKS) +
+

공인 쿠버네티스 보안 전문가(CKS) 프로그램은 CKS가 다양한 모범 사례에 대해 능숙하고 자신감을 가지도록 보장합니다. CKS 인증은 빌드, 배포 및 런타임 중에 컨테이너 기반 애플리케이션과 쿠버네티스 플랫폼을 보호하는 기술을 다룹니다.

+

CKS 지원자는 CKS에 참여하기 전에 충분한 쿠버네티스 전문 지식을 보유하고 있음을 입증하기 위해 현재 버전의 공인 쿠버네티스 관리자(CKA) 인증을 보유해야 합니다.

+
+ 인증으로 이동하기
From 5f5952973eabba189a887fb3a2f4378012533fef Mon Sep 17 00:00:00 2001 From: bl-ue <54780737+bl-ue@users.noreply.github.com> Date: Sun, 6 Dec 2020 08:17:59 -0500 Subject: [PATCH 40/66] Containers in a pod share their MAC address Containers in a pod share their MAC address as well as IP address --- .../docs/concepts/cluster-administration/networking.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 184b40c8dc..15f4222224 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -58,10 +58,11 @@ to containers. If your job previously ran in a VM, your VM had an IP and could talk to other VMs in your project. This is the same basic model. Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod` -share their network namespaces - including their IP address. This means that -containers within a `Pod` can all reach each other's ports on `localhost`. This -also means that containers within a `Pod` must coordinate port usage, but this -is no different from processes in a VM. This is called the "IP-per-pod" model. +share their network namespaces - including their IP address and MAC address. +This means that containers within a `Pod` can all reach each other's ports on +`localhost`. This also means that containers within a `Pod` must coordinate port +usage, but this is no different from processes in a VM. This is called the +"IP-per-pod" model. How this is implemented is a detail of the particular container runtime in use. From db3ee6e7b65abae407a2f51e9a83f8fe6a095760 Mon Sep 17 00:00:00 2001 From: jiajie Date: Sun, 6 Dec 2020 23:20:34 +0800 Subject: [PATCH 41/66] Update kubectl-plugins.md update doc to match master branch --- .../tasks/extend-kubectl/kubectl-plugins.md | 40 ++++++++++--------- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md index 6734a0d0d5..883246e975 100644 --- a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -14,10 +14,9 @@ content_type: task --> - 本指南演示了如何为 [kubectl](/zh/docs/reference/kubectl/kubectl/) 安装和编写扩展。 通过将核心 `kubectl` 命令看作与 Kubernetes 集群交互的基本构建块， @@ -52,12 +51,12 @@ the Kubernetes SIG CLI community. Krew 是一个由 Kubernetes SIG CLI 社区维护的插件管理器。 {{< caution >}} -Krew [插件索引](https://index.krew.dev/)所维护的 kubectl 插件并未经过安全性审查。 +Krew [插件索引](https://krew.sigs.k8s.io/plugins/) 所维护的 kubectl 插件并未经过安全性审查。 你要了解安装和运行第三方插件的安全风险，因为它们本质上时是一些在你的机器上 运行的程序。 {{< /caution >}} @@ -69,6 +68,10 @@ Krew [插件索引](https://index.krew.dev/)所维护的 kubectl 插件并未经 Executing this command causes a traversal of all files in your PATH. Any files that are executable, and begin with `kubectl-` will show up *in the order in which they are present in your PATH* in this command's output. A warning will be included for any files beginning with `kubectl-` that are *not* executable. A warning will also be included for any valid plugin files that overlap each other's name. + +You can use [Krew](https://krew.dev/) to discover and install `kubectl` +plugins from a community-curated +[plugin index](https://krew.sigs.k8s.io/plugins/). --> ### 发现插件 @@ -77,6 +80,8 @@ A warning will also be included for any valid plugin files that overlap each oth 任何以 `kubectl-` 开头的文件如果`不可执行`，都将包含一个警告。 对于任何相同的有效插件文件，都将包含一个警告。 +你可以使用 [Krew](https://krew.dev/) 从社区策划中发现和安装 `kubectl` 插件。 +[插件索引](https://krew.sigs.k8s.io/plugins/) -所有参数和标记按原样传递给可执行文件： + 所有参数和标记按原样传递给可执行文件： ``` kubectl foo version @@ -274,17 +279,17 @@ Upon having found a plugin with this name, kubectl then invokes that plugin, pas # 创建一个插件 echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz sudo chmod +x ./kubectl-foo-bar-baz - + # 将插件放到 PATH 下完成"安装" sudo mv ./kubectl-foo-bar-baz /usr/local/bin - + # 确保 kubectl 能够识别我们的插件 kubectl plugin list ``` ``` The following kubectl-compatible plugins are available: - + /usr/local/bin/kubectl-foo-bar-baz ``` @@ -322,7 +327,7 @@ command containing dashes in its commandline invocation by using underscores (`_ # 创建文件名中包含下划线的插件 echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar sudo chmod +x ./kubectl-foo_bar - + # 将插件放到 PATH 下 sudo mv ./kubectl-foo_bar /usr/local/bin @@ -378,11 +383,11 @@ PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list ``` The following kubectl-compatible plugins are available: - + /usr/local/bin/plugins/kubectl-foo /usr/local/bin/moreplugins/kubectl-foo - warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo - + error: one plugin warning was found ``` @@ -469,13 +474,13 @@ kubectl plugin list ``` ``` The following kubectl-compatible plugins are available: - + test/fixtures/pkg/kubectl/plugins/kubectl-foo /usr/local/bin/kubectl-foo - warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo plugins/kubectl-invalid - warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable - + error: 2 plugin warnings were found ``` @@ -525,7 +530,7 @@ package it, distribute it and deliver updates to your users. distribute your plugins. This way, you use a single packaging format for all target platforms (Linux, Windows, macOS etc) and deliver updates to your users. Krew also maintains a [plugin -index](https://index.krew.dev/) so that other people can +index](https://krew.sigs.k8s.io/plugins/) so that other people can discover your plugin and install it. --> ### Krew {#distributing-krew} @@ -533,7 +538,7 @@ discover your plugin and install it. [Krew](https://krew.dev/) 提供了一种对插件进行打包和分发的跨平台方式。 基于这种方式，你会在所有的目标平台（Linux、Windows、macOS 等）使用同一 种打包形式，包括为用户提供更新。 -Krew 也维护一个[插件索引（plugin index）](https://index.krew.dev/) +Krew 也维护一个[插件索引（plugin index）](https://krew.sigs.k8s.io/plugins/) 以便其他人能够发现你的插件并安装之。 +概述 + +*Kubernetes 欢迎所有新的和有经验的贡献者的改进！* + + +{{< note >}} +要了解更多有关为Kubernetes做出贡献的信息，请参阅 +[贡献者文档](https://www.kubernetes.dev/docs/). +{{< /note >}} -本网站由 [Kubernetes SIG（特别兴趣小组） Docs](/zh/docs/contribute/#get-involved-with-SIG-Docs) 维护. +本网站由 [Kubernetes SIG（特别兴趣小组） Docs](/zh/docs/contribute/#get-involved-with-SIG-Docs) 维护。 Kubernetes 文档项目的贡献者: @@ -64,6 +80,13 @@ You need to be comfortable with [GitHub](https://lab.github.com/) to work effectively in the Kubernetes community. +--> +## 入门 {#getting-started} + +任何人都可以提出文档方面的问题（issue），或贡献一个变更，用拉取请求（PR）的方式提交到 +[GitHub 上的 `kubernetes/website` 仓库](https://github.com/kubernetes/website)。 +当然你需要熟练使用 [git](https://git-scm.com/) 和 [GitHub](https://lab.github.com/) 才能在 Kubernetes 社区中有效工作。 + -## 入门 {#getting-started} - -任何人都可以提出文档方面的问题（issue），或贡献一个变更，用拉取请求（PR）的方式提交到 -[GitHub 上的 `kubernetes/website` 仓库](https://github.com/kubernetes/website)。 -当然你需要熟练使用 [git](https://git-scm.com/) 和 [GitHub](https://lab.github.com/) 才能在 Kubernetes 社区中有效工作。 - -参与文档编制: +如何参与文档编制: 1. 签署 CNCF 的[贡献者许可协议](https://github.com/kubernetes/community/blob/master/CLA.md)。 2. 熟悉[文档仓库](https://github.com/kubernetes/website) @@ -134,7 +151,7 @@ roles and permissions. - Document [features in a release](/docs/contribute/new-content/new-features/). - Participate in [SIG Docs](/docs/contribute/participate/), and become a [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/). - + - Start or help with a [localization](/docs/contribute/localization/). --> ## 下一步 {#next-teps} @@ -142,7 +159,7 @@ roles and permissions. - 学习在仓库的[本地克隆中工作](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 - 为[发行版的特性](/zh/docs/contribute/new-content/new-features/)编写文档。 - 加入 [SIG Docs](/zh/docs/contribute/participate/), 并成为[成员或评审者](/zh/docs/contribute/participate/roles-and-responsibilities/)。 - + - 开始或帮助[本地化](/zh/docs/contribute/localization/) 工作。 这个模型不仅不复杂，而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容， 如果你的工作开始是在虚拟机中运行的，你的虚拟机有一个 IP ， 这样就可以和其他的虚拟机进行通信，这是基本相同的模型。 -Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器分享它们的网络命名空间 - 包括它们的 IP 地址。 +Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。 这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。 这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同， 这也被称为“一个 Pod 一个 IP” 模型。 From b4484da6f69cbab3db3a5ab06d0bed31994e5932 Mon Sep 17 00:00:00 2001 From: jiazxjason <52809535+jiazxjason@users.noreply.github.com> Date: Mon, 7 Dec 2020 09:46:12 +0800 Subject: [PATCH 45/66] Update safely-drain-node.md --- .../administer-cluster/safely-drain-node.md | 68 ++++++++++++------- 1 file changed, 42 insertions(+), 26 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md index e4a93e99e5..a7ecadf0c2 100644 --- a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md @@ -1,28 +1,30 @@ --- -title: 确保 PodDisruptionBudget 的前提下安全地清空一个节点 +title: 安全地清空一个节点 content_type: task +min-kubernetes-server-version: 1.5 +--- + -本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个 -{{< glossary_tooltip text="节点" term_id="node" >}}。 +本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个{{< glossary_tooltip text="节点" term_id="node" >}}。 ## {{% heading "prerequisites" %}} {{% version-check %}} - -此任务假设您已经满足以下先决条件： + --> + 此任务假定您已经满足了以下先决条件： * 使用的 Kubernetes 版本 >= 1.5。 * 以下两项，具备其一： 1. 在节点清空期间，不要求应用程序具有高可用性 - 1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)， - 并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。 + 2. 您已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。 + +## （可选） 配置中断预算 {#configure-poddisruptionbudget} + +为了确保您的工作在维护期间仍然可用，您可以配置一个 [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/)。 + +如果可用性对于正在清空的该节点上运行或可能在该节点上运行的任何应用程序很重要，首先 [配置一个 PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) 并继续遵循本指南。 + ## 驱逐 API {#the-eviction-api} 如果你不喜欢使用 -[kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) +[kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain) （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程）， 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。 @@ -176,8 +192,7 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。 Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。 -要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST -发出所尝试的操作。这里有一个例子： +要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子： ```json { @@ -212,8 +227,8 @@ The API can respond in one of three ways: future versions. - If there is some kind of misconfiguration, like multiple budgets pointing at the same pod, you will get `500 Internal Server Error`. ---> -API可以通过以下三种方式之一进行响应： + --> + API 可以通过以下三种方式之一进行响应： - 如果驱逐被授权，那么 Pod 将被删掉，并且你会收到 `200 OK`， 就像你向 Pod 的 URL 发送了 `DELETE` 请求一样。 @@ -229,9 +244,9 @@ For a given eviction request, there are two cases: - There is no budget that matches this pod. In this case, the server always returns `200 OK`. - There is at least one budget. In this case, any of the three above responses may - apply. ---> -对于一个给定的驱逐请求，有两种情况： + apply. + --> + 对于一个给定的驱逐请求，有两种情况： - 没有匹配这个 Pod 的预算。这种情况，服务器总是返回 `200 OK`。 - 至少匹配一个预算。在这种情况下，上述三种回答中的任何一种都可能适用。 @@ -259,8 +274,7 @@ application owners and cluster owners to establish an agreement on behavior in t ## 驱逐阻塞 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。 -例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 -Pod 有很长的终止宽限期，就会发生这种情况。 +例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。 在这种情况下，有两种可能的解决方案： @@ -272,9 +286,11 @@ Kubernetes 并没有具体说明在这种情况下应该采取什么行为， ## {{% heading "whatsnext" %}} + -* 执行[配置 PDB](/zh/docs/tasks/run-application/configure-pdb/)中的各个步骤， - 保护你的应用 +* Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). + --> +* 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。 +* 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。 From 953e4ecf85407ff3f119e1a226173410728c1885 Mon Sep 17 00:00:00 2001 From: jiajie Date: Mon, 7 Dec 2020 10:11:33 +0800 Subject: [PATCH 46/66] Update reserve-compute-resources.md add a missing en line --- .../tasks/administer-cluster/reserve-compute-resources.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md index 104c845855..7a93c9c932 100644 --- a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -47,7 +47,7 @@ Your Kubernetes server must be at or later than version 1.17 to use the kubelet command line option `--reserved-cpus` to set an [explicitly reserved CPU list](#explicitly-reserved-cpu-list). --> -你的 kubernetes 服务器版本必须至少是 1.17 版本，才能使用 kubelet +您的 kubernetes 服务器版本必须至少是 1.17 版本，才能使用 kubelet 命令行选项 `--reserved-cpus` 设置 [显式预留 CPU 列表](#explicitly-reserved-cpu-list)。 @@ -56,6 +56,8 @@ the kubelet command line option `--reserved-cpus` to set an -概述 -*Kubernetes 欢迎所有新的和有经验的贡献者的改进！* +*Kubernetes 欢迎来自所有贡献者的改进，无论你是新人和有经验的贡献者！* {{< note >}} -要了解更多有关为Kubernetes做出贡献的信息，请参阅 +要了解有关为 Kubernetes 做出贡献的更多信息，请参阅 [贡献者文档](https://www.kubernetes.dev/docs/). {{< /note >}} -## 为服务账户添加 ImagePullSecrets {#add-imagepullsecrets-to-a-service-account} +## 为服务账户添加 ImagePullSecrets {#add-imagepullsecrets-to-a-service-account} ### 创建 ImagePullSecret @@ -283,7 +282,7 @@ The content of `token` is elided here. 输出类似于： - ``` + ``` NAME TYPE DATA AGE myregistrykey   kubernetes.io/.dockerconfigjson   1       1d ``` @@ -562,10 +561,14 @@ JWKS URI is required to use the `https` scheme. ## {{% heading "whatsnext" %}} +另请参见： + - [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/) - [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) - [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html) From 0c084cf152c332e405ebdd07b071b5e2949b92c6 Mon Sep 17 00:00:00 2001 From: guzj11 <67083623+guzj11@users.noreply.github.com> Date: Mon, 7 Dec 2020 13:59:26 +0800 Subject: [PATCH 50/66] Update user-guide-content-moved.md (#25437) * Update user-guide-content-moved.md update user-guide-content-move.md to sync with en and add the translation. * Apply suggestions from code review Co-authored-by: Qiming Teng Co-authored-by: Qiming Teng --- content/zh/includes/user-guide-content-moved.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/zh/includes/user-guide-content-moved.md b/content/zh/includes/user-guide-content-moved.md index e69de29bb2..18b4b00073 100644 --- a/content/zh/includes/user-guide-content-moved.md +++ b/content/zh/includes/user-guide-content-moved.md @@ -0,0 +1,8 @@ + +Kubernetes文档中[使用手册](/zh/docs/user-guide/)部分中的主题被移动到 +[任务](/zh/docs/tasks/)、[教程](/zh/docs/tutorials/)和[概念](/zh/docs/concepts)节。 +本主题内容已移至: From e04bd16578eada295ac43b95909ac873647be95f Mon Sep 17 00:00:00 2001 From: jiazxjason <52809535+jiazxjason@users.noreply.github.com> Date: Mon, 7 Dec 2020 14:01:09 +0800 Subject: [PATCH 51/66] Update safely-drain-node.md --- .../administer-cluster/safely-drain-node.md | 34 +++++++++++-------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md index a7ecadf0c2..5a0d2c0c4c 100644 --- a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md @@ -35,13 +35,14 @@ This task assumes that you have met the following prerequisites: 2. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/) and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for applications that need them. - --> - 此任务假定您已经满足了以下先决条件： +--> +此任务假定你已经满足了以下先决条件： * 使用的 Kubernetes 版本 >= 1.5。 * 以下两项，具备其一： 1. 在节点清空期间，不要求应用程序具有高可用性 - 2. 您已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。 + 2. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)， +并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。 @@ -55,11 +56,11 @@ If availability is important for any applications that run or could run on the n that you are draining, [configure a PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) first and the continue following this guide. --> -## （可选） 配置中断预算 {#configure-poddisruptionbudget} +## （可选） 配置干扰预算 {#configure-poddisruptionbudget} -为了确保您的工作在维护期间仍然可用，您可以配置一个 [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/)。 - -如果可用性对于正在清空的该节点上运行或可能在该节点上运行的任何应用程序很重要，首先 [配置一个 PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) 并继续遵循本指南。 +为了确保你的负载在维护期间仍然可用，你可以配置一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)。 +如果可用性对于正在清空的该节点上运行或可能在该节点上运行的任何应用程序很重要， +首先 [配置一个 PodDisruptionBudgets](/zh/docs/tasks/run-application/configure-pdb/) 并继续遵循本指南。 ## 驱逐 API {#the-eviction-api} 如果你不喜欢使用 -[kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain) +[kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程）， 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。 @@ -227,8 +229,8 @@ The API can respond in one of three ways: future versions. - If there is some kind of misconfiguration, like multiple budgets pointing at the same pod, you will get `500 Internal Server Error`. - --> - API 可以通过以下三种方式之一进行响应： +--> +API 可以通过以下三种方式之一进行响应： - 如果驱逐被授权，那么 Pod 将被删掉，并且你会收到 `200 OK`， 就像你向 Pod 的 URL 发送了 `DELETE` 请求一样。 @@ -245,8 +247,8 @@ For a given eviction request, there are two cases: returns `200 OK`. - There is at least one budget. In this case, any of the three above responses may apply. - --> - 对于一个给定的驱逐请求，有两种情况： +--> +对于一个给定的驱逐请求，有两种情况： - 没有匹配这个 Pod 的预算。这种情况，服务器总是返回 `200 OK`。 - 至少匹配一个预算。在这种情况下，上述三种回答中的任何一种都可能适用。 @@ -274,7 +276,8 @@ application owners and cluster owners to establish an agreement on behavior in t ## 驱逐阻塞 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。 -例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。 +例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 +Pod 有很长的终止宽限期，就会发生这种情况。 在这种情况下，有两种可能的解决方案： @@ -291,6 +294,7 @@ Kubernetes 并没有具体说明在这种情况下应该采取什么行为， * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). --> -* 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。 +* 执行[配置 PDB](/zh/docs/tasks/run-application/configure-pdb/)中的各个步骤， + 保护你的应用 * 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。 From 81b4221ed83618bca3fe79ed2dc558df45c2fa70 Mon Sep 17 00:00:00 2001 From: jiajie Date: Mon, 7 Dec 2020 14:07:08 +0800 Subject: [PATCH 52/66] Update http-proxy-access-api.md put a missing line back --- .../zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md index 32a782b5ac..e59cff4696 100644 --- a/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md +++ b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md @@ -3,7 +3,6 @@ title: 使用 HTTP 代理访问 Kubernetes API content_type: task weight: 40 --- - +输出应该类似这样： { "kind": "APIVersions", From 03e09ed876c816e7ce52f959f0cb951802daf176 Mon Sep 17 00:00:00 2001 From: jiazxjason <52809535+jiazxjason@users.noreply.github.com> Date: Mon, 7 Dec 2020 15:11:16 +0800 Subject: [PATCH 53/66] Update content/zh/docs/tasks/administer-cluster/safely-drain-node.md Co-authored-by: Qiming Teng --- content/zh/docs/tasks/administer-cluster/safely-drain-node.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md index 5a0d2c0c4c..0fd12f25d7 100644 --- a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md @@ -60,7 +60,8 @@ first and the continue following this guide. 为了确保你的负载在维护期间仍然可用，你可以配置一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)。 如果可用性对于正在清空的该节点上运行或可能在该节点上运行的任何应用程序很重要， -首先 [配置一个 PodDisruptionBudgets](/zh/docs/tasks/run-application/configure-pdb/) 并继续遵循本指南。 +请先[配置一个 PodDisruptionBudgets](/zh/docs/tasks/run-application/configure-pdb/) 并继续 +阅读本指南。 @@ -60,8 +60,7 @@ first and the continue following this guide. 为了确保你的负载在维护期间仍然可用，你可以配置一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)。 如果可用性对于正在清空的该节点上运行或可能在该节点上运行的任何应用程序很重要， -请先[配置一个 PodDisruptionBudgets](/zh/docs/tasks/run-application/configure-pdb/) 并继续 -阅读本指南。 +首先 [配置一个 PodDisruptionBudgets](/zh/docs/tasks/run-application/configure-pdb/) 并继续遵循本指南。 -Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。 +Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。在Kubernetes 1.11及其以后版本中，推荐使用CoreDNS，CoreDNS默认与kubeadm一起安装。 -有关如何为 Kubernetes 集群配置 DNS 的详细信息，请参阅 [Kubernetes DNS 插件示例.](https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns) +获取更多关于如何为Kubernetes集群配置CoreDNS的信息，参阅 [定制DNS服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。演示如何利用kube-dns配置kubernetes DNS的例子，参阅 [Kubernetes DNS插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 From c97259b9fc9c34accd67712db45d1dbe62e6a4b4 Mon Sep 17 00:00:00 2001 From: bing Date: Mon, 7 Dec 2020 15:31:40 +0800 Subject: [PATCH 56/66] Update certificates.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 修正markdown链接错误 --- .../zh/docs/setup/best-practices/certificates.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/zh/docs/setup/best-practices/certificates.md b/content/zh/docs/setup/best-practices/certificates.md index dcb331fa93..3a72705416 100644 --- a/content/zh/docs/setup/best-practices/certificates.md +++ b/content/zh/docs/setup/best-practices/certificates.md @@ -47,7 +47,7 @@ Kubernetes 需要 PKI 才能执行以下操作： * Client certificate for the API server to talk to etcd * Client certificate/kubeconfig for the controller manager to talk to the API server * Client certificate/kubeconfig for the scheduler to talk to the API server. -* Client and server certificates for the [front-proxy][proxy] +* Client and server certificates for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) --> * Kubelet 的客户端证书，用于 API 服务器身份验证 * API 服务器端点的证书 @@ -106,7 +106,7 @@ Required CAs: |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | Kubernetes general CA | | etcd/ca.crt,key | etcd-ca | For all etcd-related functions | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy][proxy] | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | On top of the above CAs, it is also necessary to get a public/private key pair for service account management, `sa.key` and `sa.pub`. --> @@ -116,7 +116,7 @@ On top of the above CAs, it is also necessary to get a public/private key pair f |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | Kubernetes 通用 CA | | etcd/ca.crt,key | etcd-ca | 与 etcd 相关的所有功能 | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理][proxy] | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | 上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 `sa.key` 和 `sa.pub`。 @@ -144,17 +144,17 @@ Required certificates: | front-proxy-client | kubernetes-front-proxy-ca | | client | | [1]: 用来连接到集群的不同 IP 或 DNS 名 （就像 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 为负载均衡所使用的固定 IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、 `kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）。 -其中，`kind` 对应一种或多种类型的 [x509 密钥用途][https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage]： +其中，`kind` 对应一种或多种类型的 [x509 密钥用途](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)： ### 证书路径 -证书应放置在建议的路径中（以便 [kubeadm][kubeadm]使用）。无论使用什么位置，都应使用给定的参数指定路径。 +证书应放置在建议的路径中（以便 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)使用）。无论使用什么位置，都应使用给定的参数指定路径。 | 默认 CN | 建议的密钥路径 | 建议的证书路径 | 命令 | 密钥参数 | 证书参数 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| From 99467aea3ee6afd81b287ce143db13e7ded9c801 Mon Sep 17 00:00:00 2001 From: jiajie Date: Mon, 7 Dec 2020 15:40:22 +0800 Subject: [PATCH 57/66] Update http-proxy-access-api.md --- .../zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md index e59cff4696..2e4e8bdfd1 100644 --- a/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md +++ b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md @@ -66,9 +66,11 @@ Get the API versions: 获取 API 版本： curl http://localhost:8080/api/ + + 输出应该类似这样： { From 44a2b1871d203b5d00fd5899a338d66bb63adf77 Mon Sep 17 00:00:00 2001 From: jiajie Date: Mon, 7 Dec 2020 15:56:28 +0800 Subject: [PATCH 58/66] Update new-features.md update zh content to match en master branch --- .../contribute/new-content/new-features.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/content/zh/docs/contribute/new-content/new-features.md b/content/zh/docs/contribute/new-content/new-features.md index 3d261e956d..b7ff463590 100644 --- a/content/zh/docs/contribute/new-content/new-features.md +++ b/content/zh/docs/contribute/new-content/new-features.md @@ -10,6 +10,7 @@ card: title: 为发行版本撰写功能特性文档 --- @@ -188,7 +190,9 @@ SIG Docs 一起工作，确保这一新功能在发行之前已经为之撰写 1. Open a pull request against the `dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small commit that you will amend later. -2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to +2. Edit the pull request description to include links to [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) +PR(s) and [kubernetes/enhancements](https://github.com/kubernetes/enhancements) issue(s). +3. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to assign the PR to the relevant milestone. This alerts the docs person managing this release that the feature docs are coming. --> @@ -196,8 +200,9 @@ this release that the feature docs are coming. 1. 在 `kubernetes/website` 仓库上针对 `dev-{{< skew nextMinorVersion >}}` 分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。 -1. 使用 Prow 命令 `/milestone {{< skew nextMinorVersion >}}` 将 PR - 指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有 +1. 编辑拉取请求描述以包括指向 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) PR和 [kubernetes/enhancements](https://github.com/kubernetes/enhancements) 问题的链接。 +1. 使用 Prow 命令 `/milestone {{< skew nextMinorVersion >}}` + 将 PR指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有 新的功能特性要合并到将来版本。 -### 所有 PRs 均经过评审且合并就绪 +### 所有 PR 均经过评审且合并就绪 如果你的 PR 在发行截止日期之前尚未合并到 `dev-{{< skew nextMinorVersion >}}` 分支， 请与负责管理该发行版本的文档团队成员一起合作，在截止期限之前将其合并。 @@ -264,4 +272,3 @@ remove it from that table. [Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) 表格中。 如果你的功能特性不再是 Alpha 阶段，请确保特性门控状态得到更新。 - From fc13bc7a1cacb1f30619018b2c1815a0e108201a Mon Sep 17 00:00:00 2001 From: jiajie Date: Mon, 7 Dec 2020 16:36:08 +0800 Subject: [PATCH 59/66] Update new-features.md --- content/zh/docs/contribute/new-content/new-features.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/zh/docs/contribute/new-content/new-features.md b/content/zh/docs/contribute/new-content/new-features.md index b7ff463590..ad19d1168e 100644 --- a/content/zh/docs/contribute/new-content/new-features.md +++ b/content/zh/docs/contribute/new-content/new-features.md @@ -10,7 +10,6 @@ card: title: 为发行版本撰写功能特性文档 --- @@ -200,7 +198,8 @@ this release that the feature docs are coming. 1. 在 `kubernetes/website` 仓库上针对 `dev-{{< skew nextMinorVersion >}}` 分支提交一个 PR，其中包含较少的、待以后慢慢补齐的提交内容。 -1. 编辑拉取请求描述以包括指向 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) PR和 [kubernetes/enhancements](https://github.com/kubernetes/enhancements) 问题的链接。 +1. 编辑拉取请求描述以包括指向 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) PR + 和 [kubernetes/enhancements](https://github.com/kubernetes/enhancements) 问题的链接。 1. 使用 Prow 命令 `/milestone {{< skew nextMinorVersion >}}` 将 PR指派到对应的里程碑。这样做会提醒负责管理对应发行版本的文档团队成员，有 新的功能特性要合并到将来版本。 @@ -242,7 +241,7 @@ received, the feature may be removed from the milestone. 在 `#sig-docs` Slack 频道中提问。 当你已经完成内容撰写，指派给你的功能特性的文档贡献者会去评阅文档。 -为了确保技术准确性，内容可能还需要相应SIG的技术审核。 +为了确保技术准确性，内容可能还需要相应 SIG 的技术审核。 尽量利用他们所给出的建议，改进文档内容以达到发布就绪状态。 如果你的功能特性需要文档，而一直没有关于该特性的文档提交评阅， From a902f96a601ab4fcfa33d28160ef17aaf81187b7 Mon Sep 17 00:00:00 2001 From: jiajie Date: Mon, 7 Dec 2020 17:06:11 +0800 Subject: [PATCH 60/66] Update kubectl-plugins.md --- .../tasks/extend-kubectl/kubectl-plugins.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md index 883246e975..584e2c1329 100644 --- a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -80,8 +80,9 @@ plugins from a community-curated 任何以 `kubectl-` 开头的文件如果`不可执行`，都将包含一个警告。 对于任何相同的有效插件文件，都将包含一个警告。 -你可以使用 [Krew](https://krew.dev/) 从社区策划中发现和安装 `kubectl` 插件。 -[插件索引](https://krew.sigs.k8s.io/plugins/) +你可以使用 [Krew](https://krew.dev/) 从社区策划的[插件索引](https://krew.sigs.k8s.io/plugins/) +中发现和安装 `kubectl` 插件。 + - 所有参数和标记按原样传递给可执行文件： +所有参数和标记按原样传递给可执行文件： ``` kubectl foo version @@ -279,17 +280,17 @@ Upon having found a plugin with this name, kubectl then invokes that plugin, pas # 创建一个插件 echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz sudo chmod +x ./kubectl-foo-bar-baz - + # 将插件放到 PATH 下完成"安装" sudo mv ./kubectl-foo-bar-baz /usr/local/bin - + # 确保 kubectl 能够识别我们的插件 kubectl plugin list ``` ``` The following kubectl-compatible plugins are available: - + /usr/local/bin/kubectl-foo-bar-baz ``` @@ -480,7 +481,7 @@ test/fixtures/pkg/kubectl/plugins/kubectl-foo - warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo plugins/kubectl-invalid - warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable - + error: 2 plugin warnings were found ``` From cfbe452d06d8fee35bfb3ca21798ca28f0aa4075 Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 7 Dec 2020 15:56:30 +0200 Subject: [PATCH 61/66] [zh] sync missing period in logging.md --- content/zh/docs/concepts/cluster-administration/logging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md index e858fc57a8..2a820144be 100644 --- a/content/zh/docs/concepts/cluster-administration/logging.md +++ b/content/zh/docs/concepts/cluster-administration/logging.md @@ -159,7 +159,7 @@ up logging for COS image on GCP in the corresponding [script][cosConfigureHelper --> 例如，你可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息， 相应的脚本在 -[这里](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh) +[这里](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)。 +* 为 Guestbook 应用添加 + [ELK 日志与监控](/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) * 完成 [Kubernetes Basics](/zh/docs/tutorials/kubernetes-basics/) 交互式教程 * 使用 Kubernetes 创建一个博客，使用 [MySQL 和 Wordpress 的持久卷](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) * 阅读更多关于[连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) * 阅读更多关于[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) - From ef092b3365ef83e787876fdd170ca8bcee336b1d Mon Sep 17 00:00:00 2001 From: guzj11 <67083623+guzj11@users.noreply.github.com> Date: Mon, 7 Dec 2020 16:17:59 +0800 Subject: [PATCH 63/66] Update configure-dns-cluster.md apply suggestion from tengqm --- .../access-application-cluster/configure-dns-cluster.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md index 429c31a53f..ddd5c81de4 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -16,12 +16,13 @@ content_type: concept -Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。在Kubernetes 1.11及其以后版本中，推荐使用CoreDNS，CoreDNS默认与kubeadm一起安装。 +Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS，CoreDNS 默认与 kubeadm 一起安装。 -获取更多关于如何为Kubernetes集群配置CoreDNS的信息，参阅 [定制DNS服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。演示如何利用kube-dns配置kubernetes DNS的例子，参阅 [Kubernetes DNS插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 +获取更多关于如何为 Kubernetes 集群配置 CoreDNS 的信息，参阅 [定制 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。 +演示如何利用 kube-dns 配置 kubernetes DNS 的例子，参阅 [Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 From 3451609fddcf389f7defc133aeb396f8bdd9c621 Mon Sep 17 00:00:00 2001 From: guzj11 <67083623+guzj11@users.noreply.github.com> Date: Mon, 7 Dec 2020 16:31:29 +0800 Subject: [PATCH 64/66] Update configure-dns-cluster.md --- .../access-application-cluster/configure-dns-cluster.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md index ddd5c81de4..ecec45aa34 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -16,13 +16,16 @@ content_type: concept -Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS，CoreDNS 默认与 kubeadm 一起安装。 +Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。 +在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS，CoreDNS 默认与 kubeadm 一起安装。 -获取更多关于如何为 Kubernetes 集群配置 CoreDNS 的信息，参阅 [定制 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。 -演示如何利用 kube-dns 配置 kubernetes DNS 的例子，参阅 [Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 +获取更多关于如何为 Kubernetes 集群配置 CoreDNS 的信息， +参阅 [定制 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。 +演示如何与 kube-dns 一起使用 kubernetes DNS 的例子， +参阅 [Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 From c613f7561ec0c6633059c82ab868691e5f8e08da Mon Sep 17 00:00:00 2001 From: guzj11 <67083623+guzj11@users.noreply.github.com> Date: Mon, 7 Dec 2020 16:47:46 +0800 Subject: [PATCH 65/66] Update configure-dns-cluster.md --- .../configure-dns-cluster.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md index ecec45aa34..0c9c4a812d 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -17,15 +17,16 @@ content_type: concept Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default. In Kubernetes version 1.11 and later, CoreDNS is recommended and is installed by default with kubeadm. --> Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。 -在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS，CoreDNS 默认与 kubeadm 一起安装。 +在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS， +kubeadm 默认会安装 CoreDNS。 -获取更多关于如何为 Kubernetes 集群配置 CoreDNS 的信息， -参阅 [定制 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。 -演示如何与 kube-dns 一起使用 kubernetes DNS 的例子， -参阅 [Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 +要了解如何为 Kubernetes 集群配置 CoreDNS 的更多信息，参阅 +[定制 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。 +演示如何与 kube-dns 一起使用 kubernetes DNS 的例子，参阅 +[Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 From 12d2845dc58a48f05b31d1902e66b650bf020d54 Mon Sep 17 00:00:00 2001 From: guzj11 <67083623+guzj11@users.noreply.github.com> Date: Mon, 7 Dec 2020 22:44:36 +0800 Subject: [PATCH 66/66] Update configure-dns-cluster.md --- .../access-application-cluster/configure-dns-cluster.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md index 0c9c4a812d..9125fcbfc0 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -24,9 +24,9 @@ kubeadm 默认会安装 CoreDNS。 -要了解如何为 Kubernetes 集群配置 CoreDNS 的更多信息，参阅 -[定制 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)。 -演示如何与 kube-dns 一起使用 kubernetes DNS 的例子，参阅 +要了解关于如何为 Kubernetes 集群配置 CoreDNS 的更多信息，参阅 +[定制 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/)。 +关于如何利用 kube-dns 配置 kubernetes DNS 的演示例子，参阅 [Kubernetes DNS 插件示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。