From 8980c22bb11368eaf9ead9e45e8fea8d75b6015b Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 2 Aug 2023 02:47:26 +0300 Subject: [PATCH 01/21] fix community page horizontal scrolling --- static/css/community.css | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/static/css/community.css b/static/css/community.css index 99ad2948fae..1c64a65b04c 100644 --- a/static/css/community.css +++ b/static/css/community.css @@ -62,7 +62,7 @@ body.cid-community .community-section:first-child { body.cid-community #navigation-items { padding: 0.25em; - width: 100vw; + width: 100%; max-width: initial; margin-top: 2.5em; @@ -117,7 +117,7 @@ body.cid-community .community-section#introduction > p { body.cid-community #gallery { display: flex; - max-width: 100vw; + max-width: 100%; gap: 0.75rem; justify-content: center; margin-left: auto; @@ -140,7 +140,7 @@ body.cid-community #gallery img.community-gallery-mobile { body.cid-community .community-section#events { - width: 100vw; + width: 100%; max-width: initial; margin-bottom: 0; @@ -154,7 +154,7 @@ body.cid-community .community-section#events { } body.cid-community .community-section#values { - width: 100vw; + width: 100%; max-width: initial; background-image: url('/images/community/event-bg.jpg'); color: #fff; @@ -167,7 +167,7 @@ body.cid-community .community-section#values { } body.cid-community .community-section#meetups { - width: 100vw; + width: 100%; max-width: initial; margin-top: 0; @@ -176,8 +176,6 @@ body.cid-community .community-section#meetups { background-repeat: no-repeat, repeat; background-size: auto 100%, cover; color: #fff; - - width: 100vw; /* fallback in case calc() fails */ padding: 5vw; padding-bottom: 1em; @@ -229,7 +227,7 @@ body.cid-community .fullbutton { } body.cid-community #videos { - width: 100vw; + width: 100%; max-width: initial; padding: 0.5em 5vw 5% 5vw; /* fallback in case calc() fails */ background-color: #eeeeee; @@ -321,7 +319,7 @@ body.cid-community .resourcebox { body.cid-community .community-section.community-frame { - width: 100vw; + width: 100%; } body.cid-community .community-section.community-frame .twittercol1 { @@ -422,4 +420,11 @@ body.cid-community #cncf-code-of-conduct h2:after { body.cid-community .community-section#meetups p:last-of-type { margin-bottom: 6em; /* extra space for background */ } +} + +@media only screen and (max-width: 767px) { + body.cid-community .community-section h2:before, + body.cid-community .community-section h2:after { + display: none; + } } \ No newline at end of file From 7f72658d610f4538bb4fa918e6a75447980a0a03 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Wed, 22 Nov 2023 17:44:05 +0800 Subject: [PATCH 02/21] [zh] Sync /access-application-cluster/access-cluster.md --- .../access-cluster.md | 143 +++++++++--------- 1 file changed, 74 insertions(+), 69 deletions(-) diff --git a/content/zh-cn/docs/tasks/access-application-cluster/access-cluster.md b/content/zh-cn/docs/tasks/access-application-cluster/access-cluster.md index 5c1ff12f73f..8d6827ed951 100644 --- a/content/zh-cn/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/zh-cn/docs/tasks/access-application-cluster/access-cluster.md @@ -3,7 +3,6 @@ title: 访问集群 weight: 20 content_type: concept --- - ## 直接访问 REST API {#directly-accessing-the-rest-api} Kubectl 处理 apiserver 的定位和身份验证。 -如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过 -多种方式查找和验证： +如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API， +可以通过多种方式查找和验证： - 以代理模式运行 kubectl。 - 推荐此方式。 @@ -86,7 +85,7 @@ Kubectl 处理 apiserver 的定位和身份验证。 - 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。 - 对 apiserver 进行身份验证。 - 未来可能会实现智能化的客户端负载均衡和故障恢复。 -- 直接向 http 客户端提供位置和凭据。 +- 直接向 http 客户端提供位置和凭证。 - 可选的方案。 - 适用于代理可能引起混淆的某些客户端类型。 - 需要引入根证书到你的浏览器以防止 MITM 攻击。 @@ -94,7 +93,7 @@ Kubectl 处理 apiserver 的定位和身份验证。 @@ -149,9 +148,7 @@ The output is similar to this: Use `kubectl apply` and `kubectl describe secret...` to create a token for the default service account with grep/cut: First, create the Secret, requesting a token for the default ServiceAccount: - --> - ### 不使用 kubectl proxy {#without-kubectl-proxy} 使用 `kubectl apply` 和 `kubectl describe secret ...` 及 grep 和剪切操作来为 default 服务帐户创建令牌，如下所示： @@ -245,16 +242,16 @@ The output is similar to this: ``` 上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。 @@ -275,11 +272,18 @@ client libraries. ### Go client -* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) to see which versions are supported. -* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/kubernetes"` is correct. +* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-`, + see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) + for detailed installation instructions. See + [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) + to see which versions are supported. +* Write an application atop of the client-go clients. Note that client-go defines its own API objects, + so if needed, please import API definitions from client-go rather than from the main repository, + e.g., `import "k8s.io/client-go/kubernetes"` is correct. The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) -as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go). +as the kubectl CLI does to locate and authenticate to the apiserver. See this +[example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go). If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod). --> @@ -307,10 +311,13 @@ Go 客户端可以像 kubectl CLI 一样使用相同的 - ## 访问集群上运行的服务 {#accessing-services-running-on-the-cluster} 上一节介绍了如何连接到 Kubernetes API 服务器。 -有关连接到 Kubernetes 集群上运行的其他服务的信息，请参阅 -[访问集群服务](/zh-cn/docs/tasks/access-application-cluster/access-cluster-services/)。 +有关连接到 Kubernetes 集群上运行的其他服务的信息， +请参阅[访问集群服务](/zh-cn/docs/tasks/access-application-cluster/access-cluster-services/)。 ## 请求重定向 {#requesting-redirects} 重定向功能已弃用并被删除。请改用代理（见下文）。 ## 多种代理 {#so-many-proxies} @@ -404,15 +409,15 @@ There are several different proxies you may encounter when using Kubernetes: - 添加身份验证头部 2. [apiserver 代理](/zh-cn/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services)： @@ -425,13 +430,13 @@ There are several different proxies you may encounter when using Kubernetes: - 在访问服务时进行负载平衡 3. [kube proxy](/zh-cn/docs/concepts/services-networking/service/#ips-and-vips)： @@ -442,11 +447,11 @@ There are several different proxies you may encounter when using Kubernetes: - 只能用来访问服务 4. 位于 apiserver 之前的 Proxy/Load-balancer： @@ -455,14 +460,14 @@ There are several different proxies you may encounter when using Kubernetes: - 如果有多个 apiserver，则充当负载均衡器 5. 外部服务上的云负载均衡器： From 1e58edd888a0eea719e5240b5ccdeae52411f1e1 Mon Sep 17 00:00:00 2001 From: AmarNathChary Date: Thu, 23 Nov 2023 16:22:42 +0530 Subject: [PATCH 03/21] Updated image in blog 2023-11-16 --- .../_posts/2023-11-16-the-case-for-kubernetes-limits/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2023-11-16-the-case-for-kubernetes-limits/index.md b/content/en/blog/_posts/2023-11-16-the-case-for-kubernetes-limits/index.md index ea3d60c358a..d10c72be2a0 100644 --- a/content/en/blog/_posts/2023-11-16-the-case-for-kubernetes-limits/index.md +++ b/content/en/blog/_posts/2023-11-16-the-case-for-kubernetes-limits/index.md @@ -35,7 +35,7 @@ Firstly, let’s discuss bin-packing and cluster resource allocation. There’s When configuring fixed-fraction headroom limits, a proportional amount of this will be available to the pods. If the percentage of unallocated resources in the cluster is lower than the constant we use for setting fixed-fraction headroom limits (see the figure, line 2), all the pods together are able to theoretically use up all the node’s resources; otherwise there are some resources that will inevitably be wasted (see the figure, line 1). In order to eliminate the inevitable resource waste, the percentage for fixed-fraction headroom limits should be configured so that it’s at least equal to the expected percentage of unallocated resources. -{{
}} +{{
}} For requests = limits (see the figure, line 3), this does not hold: Unless we’re able to allocate all node’s resources, there’s going to be some inevitably wasted resources. Without any knobs to turn on the requests/limits side, the only suitable approach here is to ensure efficient bin-packing on the nodes by configuring correct machine profiles. This can be done either manually or by using a variety of cloud service provider tooling – for example [Karpenter](https://karpenter.sh/) for EKS or [GKE Node auto provisioning](https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning). From f5b535a33c49f6033bd77a6a5134009a1ce62fa1 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Thu, 23 Nov 2023 09:25:24 +0800 Subject: [PATCH 04/21] [zh] Add translation to create-cluster-kubeadm.md --- .../tools/kubeadm/create-cluster-kubeadm.md | 121 ++++++++++++++++-- 1 file changed, 110 insertions(+), 11 deletions(-) diff --git a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 7946771e594..ea48228d23d 100644 --- a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -124,9 +124,13 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev ### 主机准备 {#preparing-the-hosts} +#### 安装组件 {#component-installation} + +#### 网络设置 {#network-setup} + +kubeadm 与其他 Kubernetes 组件类似，会尝试在与主机默认网关关联的网络接口上找到可用的 IP 地址。 +这个 IP 地址随后用于由某组件执行的公告和/或监听。 + + +要在 Linux 主机上获得此 IP 地址，你可以使用以下命令： + +```shell +ip route show # 查找以 "default via" 开头的行 +``` + + +Kubernetes 组件不接受自定义网络接口作为选项，因此必须将自定义 IP +地址作为标志传递给所有需要此自定义配置的组件实例。 + +要为使用 `init` 或 `join` 创建的控制平面节点配置 API 服务器的公告地址， +你可以使用 `--apiserver-advertise-address` 标志。 +最好在 [kubeadm API](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3)中使用 +`InitConfiguration.localAPIEndpoint` 和 `JoinConfiguration.controlPlane.localAPIEndpoint` +来设置此选项。 + + +对于所有节点上的 kubelet，`--node-ip` 选项可以在 kubeadm 配置文件 +（`InitConfiguration` 或 `JoinConfiguration`）的 `.nodeRegistration.kubeletExtraArgs` +中设置。 + +有关双协议栈细节参见[使用 kubeadm 支持双协议栈](/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support)。 + +{{< note >}} + +IP 地址成为证书 SAN 字段的一部分。更改这些 IP 地址将需要签署新的证书并重启受影响的组件， +以便反映证书文件中的变化。有关此主题的更多细节参见 +[手动续期证书](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal)。 +{{}} + +{{< warning >}} + +Kubernetes 项目不推荐此方法（使用自定义 IP 地址配置所有组件实例）。 +Kubernetes 维护者建议设置主机网络，使默认网关 IP 成为 Kubernetes 组件自动检测和使用的 IP。 +对于 Linux 节点，你可以使用诸如 `ip route` 的命令来配置网络； +你的操作系统可能还提供更高级的网络管理工具。 +如果节点的默认网关是公共 IP 地址，你应配置数据包过滤或其他保护节点和集群的安全措施。 +{{< /warning >}} + +{{< note >}} + +如果主机没有默认网关，则建议设置一个默认网关。 +否则，在不传递自定义 IP 地址给 Kubernetes 组件的情况下，此组件将退出并报错。 +如果主机上存在两个或多个默认网关，则 Kubernetes +组件将尝试使用所遇到的第一个具有合适全局单播 IP 地址的网关。 +在做出此选择时，网关的确切顺序可能因不同的操作系统和内核版本而有所差异。 +{{< /note >}} + @@ -209,7 +317,7 @@ a provider-specific value. See [Installing a Pod network add-on](#pod-network). 1. （推荐）如果计划将单个控制平面 kubeadm 集群升级成高可用， 你应该指定 `--control-plane-endpoint` 为所有控制平面节点设置共享端点。 端点可以是负载均衡器的 DNS 名称或 IP 地址。 -1. 选择一个 Pod 网络插件，并验证是否需要为 `kubeadm init` 传递参数。 +2. 选择一个 Pod 网络插件，并验证是否需要为 `kubeadm init` 传递参数。 根据你选择的第三方网络插件，你可能需要设置 `--pod-network-cidr` 的值。 请参阅[安装 Pod 网络附加组件](#pod-network)。 @@ -218,19 +326,10 @@ a provider-specific value. See [Installing a Pod network add-on](#pod-network). known endpoints. To use different container runtime or if there are more than one installed on the provisioned node, specify the `--cri-socket` argument to `kubeadm`. See [Installing a runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). -1. (Optional) Unless otherwise specified, `kubeadm` uses the network interface associated -with the default gateway to set the advertise address for this particular control-plane node's API server. -To use a different network interface, specify the `--apiserver-advertise-address=` argument -to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you -must specify an IPv6 address, for example `--apiserver-advertise-address=2001:db8::101` --> -1. （可选）`kubeadm` 试图通过使用已知的端点列表来检测容器运行时。 +3. （可选）`kubeadm` 试图通过使用已知的端点列表来检测容器运行时。 使用不同的容器运行时或在预配置的节点上安装了多个容器运行时，请为 `kubeadm init` 指定 `--cri-socket` 参数。 请参阅[安装运行时](/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)。 -1. （可选）除非另有说明，否则 `kubeadm` 使用与默认网关关联的网络接口来设置此控制平面节点 API server 的广播地址。 - 要使用其他网络接口，请为 `kubeadm init` 设置 `--apiserver-advertise-address=` 参数。 - 要部署使用 IPv6 地址的 Kubernetes 集群， - 必须指定一个 IPv6 地址，例如 `--apiserver-advertise-address=2001:db8::101`。 -3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubelet.d/`。 +3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubernetes/manifests/`。 在 Fedora 上编辑 `/etc/kubernetes/kubelet` 以包含下面这行： ``` From f10369c1f583071141b0ddfdaaacd116099cd742 Mon Sep 17 00:00:00 2001 From: Suruchi Kumari Date: Tue, 28 Nov 2023 05:58:17 +0000 Subject: [PATCH 13/21] changes done as per reviews Signed-off-by: GitHub --- .../configure-liveness-readiness-startup-probes.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index f49d4965556..4d0b744d7d2 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -488,9 +488,9 @@ startupProbe: ``` {{< note >}} -When the kubelet probes a Pod using HTTP, the default behavior is only to follows redirects if the redirect -is to the same host. If the kubelet receives 11 or more redirects during probing, the probe is considered a -warning and a related Event is created: +When the kubelet probes a Pod using HTTP, it only follows redirects if the redirect +is to the same host. If the kubelet receives 11 or more redirects during probing, the probe is considered successful +and a related Event is created: ```none Events: @@ -504,8 +504,7 @@ Events: Warning ProbeWarning 4m11s (x1197 over 24m) kubelet Readiness probe warning: Probe terminated redirects ``` -If the kubelet receives a redirect where the hostname is different from the request, the outcome of the probe -is a warning and the kubelet creates an event to report this. +If the kubelet receives a redirect where the hostname is different from the request, the outcome of the probe is treated as successful and kubelet creates an event to report the redirect failure. {{< /note >}} ### TCP probes From d5bd665a80aa7d05b9a39b8878310d2cb408f0db Mon Sep 17 00:00:00 2001 From: John Howard Date: Tue, 28 Nov 2023 05:28:47 -0800 Subject: [PATCH 14/21] Add Gateway API recent features blog post (#43619) * WIP: Add Gateway API recent features blog post * add two sections * New blog sections * Few tweaks * Add first paragraph * Fix image URL * Address Rob's comments * Remove duplicate line * Candace's comments * Candace's comments * Update 2023-11-1-Gateway-API-Future.md * Address comments * Push date --- .../_posts/2023-11-28-Gateway-API-Future.md | 259 ++++++++++++++++++ 1 file changed, 259 insertions(+) create mode 100644 content/en/blog/_posts/2023-11-28-Gateway-API-Future.md diff --git a/content/en/blog/_posts/2023-11-28-Gateway-API-Future.md b/content/en/blog/_posts/2023-11-28-Gateway-API-Future.md new file mode 100644 index 00000000000..69023b8a33f --- /dev/null +++ b/content/en/blog/_posts/2023-11-28-Gateway-API-Future.md @@ -0,0 +1,259 @@ +--- +layout: blog +title: "New Experimental Features in Gateway API v1.0" +date: 2023-11-28T10:00:00-08:00 +slug: gateway-api-ga +--- + +***Authors:*** Candace Holman (Red Hat), Dave Protasowski (VMware), Gaurav K Ghildiyal (Google), John Howard (Google), Simone Rodigari (IBM) + +Recently, the [Gateway API](https://gateway-api.sigs.k8s.io/) [announced its v1.0 GA release](/blog/2023/10/31/gateway-api-ga/), marking a huge milestone for the project. + +Along with stabilizing some of the core functionality in the API, a number of exciting new *experimental* features have been added. + +## Backend TLS Policy + +`BackendTLSPolicy` is a new Gateway API type used for specifying the TLS configuration of the connection from the Gateway to backend Pods via the Service API object. +It is specified as a [Direct PolicyAttachment](https://gateway-api.sigs.k8s.io/geps/gep-713/#direct-policy-attachment) without defaults or overrides, applied to a Service that accesses a backend, where the BackendTLSPolicy resides in the same namespace as the Service to which it is applied. +All Gateway API Routes that point to a referenced Service should respect a configured `BackendTLSPolicy`. + +While there were existing ways provided for [TLS to be configured for edge and passthrough termination](https://gateway-api.sigs.k8s.io/guides/tls/#tls-configuration), this new API object specifically addresses the configuration of TLS in order to convey HTTPS from the Gateway dataplane to the backend. +This is referred to as "backend TLS termination" and enables the Gateway to know how to connect to a backend Pod that has its own certificate. + +![Termination Types](https://gateway-api.sigs.k8s.io/geps/images/1897-TLStermtypes.png) + +The specification of a `BackendTLSPolicy` consists of: +- `targetRef` - Defines the targeted API object of the policy. Only Service is allowed. +- `tls` - Defines the configuration for TLS, including `hostname`, `caCertRefs`, and `wellKnownCACerts`. Either `caCertRefs` or `wellKnownCACerts` may be specified, but not both. +- `hostname` - Defines the Server Name Indication (SNI) that the Gateway uses to connect to the backend. The certificate served by the backend must match this SNI. +- `caCertRefs` - Defines one or more references to objects that contain PEM-encoded TLS certificates, which are used to establish a TLS handshake between the Gateway and backend. +- `wellKnownCACerts` - Specifies whether or not system CA certificates may be used in the TLS handshake between the Gateway and backend. + +### Examples + +#### Using System Certificates + +In this example, the `BackendTLSPolicy` is configured to use system certificates to connect with a TLS-encrypted upstream connection where Pods backing the `dev` Service are expected to serve a valid certificate for `dev.example.com`. + +```yaml +apiVersion: gateway.networking.k8s.io/v1alpha2 +kind: BackendTLSPolicy +metadata: + name: tls-upstream-dev +spec: + targetRef: + kind: Service + name: dev-service + group: "" + tls: + wellKnownCACerts: "System" + hostname: dev.example.com +``` + +#### Using Explicit CA Certificates + +In this example, the `BackendTLSPolicy` is configured to use certificates defined in the configuration map `auth-cert` to connect with a TLS-encrypted upstream connection where Pods backing the `auth` Service are expected to serve a valid certificate for `auth.example.com`. + +```yaml +apiVersion: gateway.networking.k8s.io/v1alpha2 +kind: BackendTLSPolicy +metadata: + name: tls-upstream-auth +spec: + targetRef: + kind: Service + name: auth-service + group: "" + tls: + caCertRefs: + - kind: ConfigMapReference + name: auth-cert + group: "" + hostname: auth.example.com +``` + +The following illustrates a BackendTLSPolicy that configures TLS for a Service serving a backend: + +{{< mermaid >}} +flowchart LR + client(["client"]) + gateway["Gateway"] + style gateway fill:#02f,color:#fff + httproute["HTTP
Route"] + style httproute fill:#02f,color:#fff + service["Service"] + style service fill:#02f,color:#fff + pod1["Pod"] + style pod1 fill:#02f,color:#fff + pod2["Pod"] + style pod2 fill:#02f,color:#fff + client -.->|HTTP
request| gateway + gateway --> httproute + httproute -.->|BackendTLSPolicy|service + service --> pod1 & pod2 +{{}} + +For more information, refer to the [documentation for TLS](https://gateway-api.sigs.k8s.io/guides/tls). + +## HTTPRoute Timeouts + +A key enhancement in Gateway API's latest release (v1.0) is the introduction of the `timeouts` field within HTTPRoute Rules. This feature offers a dynamic way to manage timeouts for incoming HTTP requests, adding precision and reliability to your gateway setups. + +With Timeouts, developers can fine-tune their Gateway API's behavior in two fundamental ways: + +1. **Request Timeout**: + + The request timeout is the duration within which the Gateway API implementation must send a response to a client's HTTP request. + It allows flexibility in specifying when this timeout starts, either before or after the entire client request stream is received, making it implementation-specific. + This timeout efficiently covers the entire request-response transaction, enhancing the responsiveness of your services. + +1. **Backend Request Timeout**: + + The backendRequest timeout is a game-changer for those dealing with backends. + It sets a timeout for a single request sent from the Gateway to a backend service. + This timeout spans from the initiation of the request to the reception of the full response from the backend. + This feature is particularly helpful in scenarios where the Gateway needs to retry connections to a backend, ensuring smooth communication under various conditions. + +Notably, the `request` timeout encompasses the `backendRequest` timeout. Hence, the value of `backendRequest` should never exceed the value of the `request` timeout. + +The ability to configure these timeouts adds a new layer of reliability to your Kubernetes services. +Whether it's ensuring client requests are processed within a specified timeframe or managing backend service communications, Gateway API's Timeouts offer the control and predictability you need. + +To get started, you can define timeouts in your HTTPRoute Rules using the Timeouts field, specifying their type as Duration. +A zero-valued timeout (`0s`) disables the timeout, while a valid non-zero-valued timeout should be at least 1ms. + +Here's an example of setting request and backendRequest timeouts in an HTTPRoute: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: timeout-example +spec: + parentRefs: + - name: example-gateway + rules: + - matches: + - path: + type: PathPrefix + value: /timeout + timeouts: + request: 10s + backendRequest: 2s + backendRefs: + - name: timeout-svc + port: 8080 +``` + +In this example, a `request` timeout of 10 seconds is defined, ensuring that client requests are processed within that timeframe. +Additionally, a 2-second `backendRequest` timeout is set for individual requests from the Gateway to a backend service called timeout-svc. + +These new HTTPRoute Timeouts provide Kubernetes users with more control and flexibility in managing network communications, helping ensure a smoother and more predictable experience for both clients and backends. +For additional details and examples, refer to the [official timeouts API documentation](https://gateway-api.sigs.k8s.io/api-types/httproute/#timeouts-optional). + +## Gateway Infrastructure Labels + +While Gateway API providers a common API for different implementations, each implementation will have different resources created under-the-hood to apply users' intent. +This could be configuring cloud load balancers, creating in-cluster Pods and Services, or more. + +While the API has always provided an extension point -- `parametersRef` in `GatewayClass` -- to customize implementation specific things, there was no common core way to express common infrastructure customizations. + +Gateway API v1.0 paves the way for this with a new `infrastructure` field on the `Gateway` object, allowing customization of the underlying infrastructure. +For now, this starts small with two critical fields: labels and annotations. +When these are set, any generated infrastructure will have the provided labels and annotations set on them. + +For example, I may want to group all my resources for one application together: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: hello-world +spec: + infrastructure: + labels: + app.kubernetes.io/name: hello-world +``` + +In the future, we are looking into more common infrastructure configurations, such as resource sizing. + +For more information, refer to the [documentation](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.GatewayInfrastructure) for this feature. + +## Support for Websockets, HTTP/2 and more! + +Not all implementations of Gateway API support automatic protocol selection. +In some cases protocols are disabled without an explicit opt-in. + +When a Route's backend references a Kubernetes Service, application developers can specify the protocol using `ServicePort` [`appProtocol`][appProtocol] field. + +For example the following `store` Kubernetes Service is indicating the port `8080` supports HTTP/2 Prior Knowledge. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: store +spec: + selector: + app: store + ports: + - protocol: TCP + appProtocol: kubernetes.io/h2c + port: 8080 + targetPort: 8080 +``` + +Currently, Gateway API has conformance testing for: + +- `kubernetes.io/h2c` - HTTP/2 Prior Knowledge +- `kubernetes.io/ws` - WebSocket over HTTP + +For more information, refer to the documentation for [Backend Protocol Selection](https://gateway-api.sigs.k8s.io/guides/backend-protocol). + +[appProtocol]: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol + +## `gwctl`, our new Gateway API command line tool + +`gwctl` is a command line tool that aims to be a `kubectl` replacement for viewing Gateway API resources. + +The initial release of `gwctl` that comes bundled with Gateway v1.0 release includes helpful features for managing Gateway API Policies. +Gateway API Policies serve as powerful extension mechanisms for modifying the behavior of Gateway resources. +One challenge with using policies is that it may be hard to discover which policies are affecting which Gateway resources. +`gwctl` helps bridge this gap by answering questions like: + +* Which policies are available for use in the Kubernetes cluster? +* Which policies are attached to a particular Gateway, HTTPRoute, etc? +* If policies are applied to multiple resources in the Gateway resource hierarchy, what is the effective policy that is affecting a particular resource? (For example, if an HTTP request timeout policy is applied to both an HTTPRoute and its parent Gateway, what is the effective timeout for the HTTPRoute?) + +`gwctl` is still in the very early phases of development and hence may be a bit rough around the edges. +Follow the instructions in [the repository](https://github.com/kubernetes-sigs/gateway-api/tree/main/gwctl#try-it-out) to install and try out `gwctl`. + +### Examples + +Here are some examples of how `gwctl` can be used: + +```bash +# List all policies in the cluster. This will also give the resource they bind +# to. +gwctl get policies -A +# List all available policy types. +gwctl get policycrds +# Describe all HTTPRoutes in namespace ns2. (Output includes effective policies) +gwctl describe httproutes -n ns2 +# Describe a single HTTPRoute in the default namespace. (Output includes +# effective policies) +gwctl describe httproutes my-httproute-1 +# Describe all Gateways across all namespaces. (Output includes effective +# policies) +gwctl describe gateways -A +# Describe a single GatewayClass. (Output includes effective policies) +gwctl describe gatewayclasses foo-com-external-gateway-class +``` + +## Get involved + +These projects, and many more, continue to be improved in Gateway API. +There are lots of opportunities to get involved and help define the future of Kubernetes routing APIs for both Ingress and Mesh. + +If this is interesting to you, please [join us in the community](https://gateway-api.sigs.k8s.io/contributing/) and help us build the future of Gateway API together! + From fd9b1115dabde0b410ad71d7e1509d2fade29005 Mon Sep 17 00:00:00 2001 From: xin gu <418294249@qq.com> Date: Tue, 28 Nov 2023 22:00:52 +0800 Subject: [PATCH 15/21] sync cel deprecation-guide --- content/zh-cn/docs/reference/using-api/cel.md | 4 ++-- content/zh-cn/docs/reference/using-api/deprecation-guide.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/zh-cn/docs/reference/using-api/cel.md b/content/zh-cn/docs/reference/using-api/cel.md index 56c6063621d..dde390d46f2 100644 --- a/content/zh-cn/docs/reference/using-api/cel.md +++ b/content/zh-cn/docs/reference/using-api/cel.md @@ -636,8 +636,8 @@ Some Kubernetes resources define an additional runtime cost budget that bounds the execution of multiple expressions. If the sum total of the cost of expressions exceed the budget, execution of the expressions will be halted, and an error will result. For example the validation of a custom resource has a -_per-validation_ runtime cost budget for all [Validation -Rules](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules) +_per-validation_ runtime cost budget for all +[Validation Rules](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules) evaluated to validate the custom resource. --> 一些 Kubernetes 资源定义了额外的运行时成本预算，用于限制多个表达式的执行。 diff --git a/content/zh-cn/docs/reference/using-api/deprecation-guide.md b/content/zh-cn/docs/reference/using-api/deprecation-guide.md index 518fc1990de..c6a4e4cfdda 100644 --- a/content/zh-cn/docs/reference/using-api/deprecation-guide.md +++ b/content/zh-cn/docs/reference/using-api/deprecation-guide.md @@ -66,9 +66,9 @@ The **flowcontrol.apiserver.k8s.io/v1beta2** API version of FlowSchema and Prior ### v1.27 -**v1.27** 发行版本中将去除以下已弃用的 API 版本： +**v1.27** 发行版本停止支持以下已弃用的 API 版本： #### CSIStorageCapacity {#csistoragecapacity-v127} From 976ead0a1a7976edc9346b39d653dcda29655d5f Mon Sep 17 00:00:00 2001 From: Mengjiao Liu <44460091+mengjiao-liu@users.noreply.github.com> Date: Wed, 29 Nov 2023 08:06:06 +0800 Subject: [PATCH 16/21] Update In-tree storage driver status (#42415) * Update In-tree storage driver status * Update In-tree storage driver `gcePersistentDisk` status to removed * Remove GCEPersistentDisk volume info from the storage-classes page --- .../concepts/storage/persistent-volumes.md | 28 +--- .../docs/concepts/storage/storage-classes.md | 57 -------- content/en/docs/concepts/storage/volumes.md | 128 ++---------------- .../docs/concepts/storage/windows-storage.md | 1 - 4 files changed, 15 insertions(+), 199 deletions(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 2d7c00b7b71..d7511f47551 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -184,8 +184,8 @@ and the volume is considered "released". But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps. -1. Delete the PersistentVolume. The associated storage asset in external infrastructure - (such as an AWS EBS or GCE PD volume) still exists after the PV is deleted. +1. Delete the PersistentVolume. The associated storage asset in external infrastructure + still exists after the PV is deleted. 1. Manually clean up the data on the associated storage asset accordingly. 1. Manually delete the associated storage asset. @@ -196,7 +196,7 @@ the same storage asset definition. For volume plugins that support the `Delete` reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated -storage asset in the external infrastructure, such as an AWS EBS or GCE PD volume. Volumes that were dynamically provisioned +storage asset in the external infrastructure. Volumes that were dynamically provisioned inherit the [reclaim policy of their StorageClass](#reclaim-policy), which defaults to `Delete`. The administrator should configure the StorageClass according to users' expectations; otherwise, the PV must be edited or @@ -370,7 +370,6 @@ the following types of volumes: * azureFile (deprecated) * {{< glossary_tooltip text="csi" term_id="csi" >}} * flexVolume (deprecated) -* gcePersistentDisk (deprecated) * rbd (deprecated) * portworxVolume (deprecated) @@ -438,11 +437,6 @@ Similar to other volume types - FlexVolume volumes can also be expanded when in- FlexVolume resize is possible only when the underlying driver supports resize. {{< /note >}} -{{< note >}} -Expanding EBS volumes is a time-consuming operation. -Also, there is a per-volume quota of one modification every 6 hours. -{{< /note >}} - #### Recovering from Failure when Expanding Volumes If a user specifies a new size that is too big to be satisfied by underlying @@ -518,8 +512,6 @@ This means that support is still available but will be removed in a future Kuber (**deprecated** in v1.21) * [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume (**deprecated** in v1.23) -* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk - (**deprecated** in v1.17) * [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume (**deprecated** in v1.25) * [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume @@ -663,8 +655,7 @@ are specified as ReadWriteOncePod, the volume is constrained and can be mounted {{< /note >}} > __Important!__ A volume can only be mounted using one access mode at a time, -> even if it supports many. For example, a GCEPersistentDisk can be mounted as -> ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time. +> even if it supports many. | Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod | | :--- | :---: | :---: | :---: | - | @@ -673,8 +664,6 @@ are specified as ReadWriteOncePod, the volume is constrained and can be mounted | CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver | | FC | ✓ | ✓ | - | - | | FlexVolume | ✓ | ✓ | depends on the driver | - | -| GCEPersistentDisk | ✓ | ✓ | - | - | -| Glusterfs | ✓ | ✓ | ✓ | - | | HostPath | ✓ | - | - | - | | iSCSI | ✓ | ✓ | - | - | | NFS | ✓ | ✓ | ✓ | - | @@ -701,9 +690,9 @@ Current reclaim policies are: * Retain -- manual reclamation * Recycle -- basic scrub (`rm -rf /thevolume/*`) -* Delete -- associated storage asset such as AWS EBS or GCE PD volume is deleted +* Delete -- associated storage asset -Currently, only NFS and HostPath support recycling. AWS EBS and GCE PD volumes support deletion. +For Kubernetes {{< skew currentVersion >}}, only `nfs` and `hostPath` volume types support recycling. ### Mount Options @@ -719,7 +708,6 @@ The following volume types support mount options: * `azureFile` * `cephfs` (**deprecated** in v1.28) * `cinder` (**deprecated** in v1.18) -* `gcePersistentDisk` (**deprecated** in v1.28) * `iscsi` * `nfs` * `rbd` (**deprecated** in v1.28) @@ -734,8 +722,7 @@ it will become fully deprecated in a future Kubernetes release. ### Node Affinity {{< note >}} -For most volume types, you do not need to set this field. It is automatically -populated for [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) volume block types. +For most volume types, you do not need to set this field. You need to explicitly set this for [local](/docs/concepts/storage/volumes/#local) volumes. {{< /note >}} @@ -956,7 +943,6 @@ applicable: * CSI * FC (Fibre Channel) -* GCEPersistentDisk (deprecated) * iSCSI * Local volume * OpenStack Cinder diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 393d72a77bf..bea656be354 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -78,7 +78,6 @@ for provisioning PVs. This field must be specified. | CephFS | - | - | | FC | - | - | | FlexVolume | - | - | -| GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | | iSCSI | - | - | | NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | @@ -125,7 +124,6 @@ StorageClass has the field `allowVolumeExpansion` set to true. | Volume type | Required Kubernetes version | | :------------------- | :-------------------------- | -| gcePersistentDisk | 1.11 | | rbd | 1.11 | | Azure File | 1.11 | | Portworx | 1.11 | @@ -169,13 +167,7 @@ requirements](/docs/concepts/configuration/manage-resources-containers/), anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), and [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration). -The following plugins support `WaitForFirstConsumer` with dynamic provisioning: - -- [GCEPersistentDisk](#gce-pd) - The following plugins support `WaitForFirstConsumer` with pre-created PersistentVolume binding: - -- All of the above - [Local](#local) [CSI volumes](/docs/concepts/storage/volumes/#csi) are also supported with dynamic provisioning @@ -294,55 +286,6 @@ parameters: [allowedTopologies](#allowed-topologies) {{< /note >}} -### GCE PD - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: slow -provisioner: kubernetes.io/gce-pd -parameters: - type: pd-standard - fstype: ext4 - replication-type: none -``` - -- `type`: `pd-standard` or `pd-ssd`. Default: `pd-standard` -- `zone` (Deprecated): GCE zone. If neither `zone` nor `zones` is specified, volumes are - generally round-robin-ed across all active zones where Kubernetes cluster has - a node. `zone` and `zones` parameters must not be used at the same time. -- `zones` (Deprecated): A comma separated list of GCE zone(s). If neither `zone` nor `zones` - is specified, volumes are generally round-robin-ed across all active zones - where Kubernetes cluster has a node. `zone` and `zones` parameters must not - be used at the same time. -- `fstype`: `ext4` or `xfs`. Default: `ext4`. The defined filesystem type must be supported by the host operating system. - -- `replication-type`: `none` or `regional-pd`. Default: `none`. - -If `replication-type` is set to `none`, a regular (zonal) PD will be provisioned. - -If `replication-type` is set to `regional-pd`, a -[Regional Persistent Disk](https://cloud.google.com/compute/docs/disks/#repds) -will be provisioned. It's highly recommended to have -`volumeBindingMode: WaitForFirstConsumer` set, in which case when you create -a Pod that consumes a PersistentVolumeClaim which uses this StorageClass, a -Regional Persistent Disk is provisioned with two zones. One zone is the same -as the zone that the Pod is scheduled in. The other zone is randomly picked -from the zones available to the cluster. Disk zones can be further constrained -using `allowedTopologies`. - -{{< note >}} -`zone` and `zones` parameters are deprecated and replaced with -[allowedTopologies](#allowed-topologies). When -[GCE CSI Migration](/docs/concepts/storage/volumes/#gce-csi-migration) is -enabled, a GCE PD volume can be provisioned in a topology that does not match -any nodes, but any pod trying to use that volume will fail to schedule. With -legacy pre-migration GCE PD, in this case an error will be produced -instead at provisioning time. GCE CSI Migration is enabled by default beginning -from the Kubernetes 1.23 release. -{{< /note >}} - ### NFS ```yaml diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 90054ea8762..08be7f60e39 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -295,127 +295,15 @@ beforehand so that Kubernetes hosts can access them. See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) for more details. -### gcePersistentDisk (deprecated) {#gcepersistentdisk} +### gcePersistentDisk (removed) {#gcepersistentdisk} -{{< feature-state for_k8s_version="v1.17" state="deprecated" >}} +Kubernetes {{< skew currentVersion >}} does not include a `gcePersistentDisk` volume type. -A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE) -[persistent disk](https://cloud.google.com/compute/docs/disks) (PD) into your Pod. -Unlike `emptyDir`, which is erased when a pod is removed, the contents of a PD are -preserved and the volume is merely unmounted. This means that a PD can be -pre-populated with data, and that data can be shared between pods. +The `gcePersistentDisk` in-tree storage driver was deprecated in the Kubernetes v1.17 release +and then removed entirely in the v1.28 release. -{{< note >}} -You must create a PD using `gcloud` or the GCE API or UI before you can use it. -{{< /note >}} - -There are some restrictions when using a `gcePersistentDisk`: - -* the nodes on which Pods are running must be GCE VMs -* those VMs need to be in the same GCE project and zone as the persistent disk - -One feature of GCE persistent disk is concurrent read-only access to a persistent disk. -A `gcePersistentDisk` volume permits multiple consumers to simultaneously -mount a persistent disk as read-only. This means that you can pre-populate a PD with your dataset -and then serve it in parallel from as many Pods as you need. Unfortunately, -PDs can only be mounted by a single consumer in read-write mode. Simultaneous -writers are not allowed. - -Using a GCE persistent disk with a Pod controlled by a ReplicaSet will fail unless -the PD is read-only or the replica count is 0 or 1. - -#### Creating a GCE persistent disk {#gce-create-persistent-disk} - -Before you can use a GCE persistent disk with a Pod, you need to create it. - -```shell -gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk -``` - -#### GCE persistent disk configuration example - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-pd -spec: - containers: - - image: registry.k8s.io/test-webserver - name: test-container - volumeMounts: - - mountPath: /test-pd - name: test-volume - volumes: - - name: test-volume - # This GCE PD must already exist. - gcePersistentDisk: - pdName: my-data-disk - fsType: ext4 -``` - -#### Regional persistent disks - -The [Regional persistent disks](https://cloud.google.com/compute/docs/disks/#repds) -feature allows the creation of persistent disks that are available in two zones -within the same region. In order to use this feature, the volume must be provisioned -as a PersistentVolume; referencing the volume directly from a pod is not supported. - -#### Manually provisioning a Regional PD PersistentVolume - -Dynamic provisioning is possible using a -[StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce-pd). -Before creating a PersistentVolume, you must create the persistent disk: - -```shell -gcloud compute disks create --size=500GB my-data-disk - --region us-central1 - --replica-zones us-central1-a,us-central1-b -``` - -#### Regional persistent disk configuration example - -```yaml -apiVersion: v1 -kind: PersistentVolume -metadata: - name: test-volume -spec: - capacity: - storage: 400Gi - accessModes: - - ReadWriteOnce - gcePersistentDisk: - pdName: my-data-disk - fsType: ext4 - nodeAffinity: - required: - nodeSelectorTerms: - - matchExpressions: - # failure-domain.beta.kubernetes.io/zone should be used prior to 1.21 - - key: topology.kubernetes.io/zone - operator: In - values: - - us-central1-a - - us-central1-b -``` - -#### GCE CSI migration - -{{< feature-state for_k8s_version="v1.25" state="stable" >}} - -The `CSIMigration` feature for GCE PD, when enabled, redirects all plugin operations -from the existing in-tree plugin to the `pd.csi.storage.gke.io` Container -Storage Interface (CSI) Driver. In order to use this feature, the [GCE PD CSI -Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) -must be installed on the cluster. - -#### GCE CSI migration complete - -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} - -To disable the `gcePersistentDisk` storage plugin from being loaded by the controller manager -and the kubelet, set the `InTreePluginGCEUnregister` flag to `true`. +The Kubernetes project suggests that you use the [Google Compute Engine Persistent Disk CSI](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) +third party storage driver instead. ### gitRepo (deprecated) {#gitrepo} @@ -704,8 +592,8 @@ for an example of mounting NFS volumes with PersistentVolumes. A `persistentVolumeClaim` volume is used to mount a [PersistentVolume](/docs/concepts/storage/persistent-volumes/) into a Pod. PersistentVolumeClaims -are a way for users to "claim" durable storage (such as a GCE PersistentDisk or an -iSCSI volume) without knowing the details of the particular cloud environment. +are a way for users to "claim" durable storage (such as an iSCSI volume) +without knowing the details of the particular cloud environment. See the information about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) for more details. diff --git a/content/en/docs/concepts/storage/windows-storage.md b/content/en/docs/concepts/storage/windows-storage.md index 6bfc117029d..b55ec7335ec 100644 --- a/content/en/docs/concepts/storage/windows-storage.md +++ b/content/en/docs/concepts/storage/windows-storage.md @@ -66,5 +66,4 @@ The following broad classes of Kubernetes volume plugins are supported on Window The following in-tree plugins support persistent storage on Windows nodes: * [`azureFile`](/docs/concepts/storage/volumes/#azurefile) -* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) * [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) From 554888678c5e8f02eb80d68f6e56adc008b7c298 Mon Sep 17 00:00:00 2001 From: Michael Date: Thu, 23 Nov 2023 07:57:23 +0800 Subject: [PATCH 17/21] [zh] Sync scheduling-framework.md --- .../scheduling-framework.md | 119 ++++++++++++------ 1 file changed, 78 insertions(+), 41 deletions(-) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md index 436e2cc5a5c..a1e63aec70f 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -3,15 +3,12 @@ title: 调度框架 content_type: concept weight: 60 --- - @@ -25,7 +22,6 @@ scheduling "core" lightweight and maintainable. Refer to the [design proposal of scheduling framework][kep] for more technical information on the design of the framework. --> - 调度框架是面向 Kubernetes 调度器的一种插件架构， 它为现有的调度器添加了一组新的“插件” API。插件会被编译到调度器之中。 这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。 @@ -39,7 +35,7 @@ framework. -# 框架工作流程 +# 框架工作流程 {#framework-workflow} -## 调度周期和绑定周期 +## 调度周期和绑定周期 {#scheduling-cycle-and-binding-cycle} -## 扩展点 +## 接口 {#interfaces} -下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。 -在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。 +下图显示了一个 Pod 的调度上下文以及调度框架公开的接口。 -一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。 +一个插件可能实现多个接口，以执行更为复杂或有状态的任务。 + + +某些接口与可以通过[调度器配置](/zh-cn/docs/reference/scheduling/config/#extension-points)来设置的调度器扩展点匹配。 +EnqueueExtension 作为一个接口，插件可以在此接口之上根据集群中的变化来控制是否重新尝试调度被此插件拒绝的 Pod。 +实现 PreEnqueue、PreFilter、Filter、Reserve 或 Permit 的插件应实现此接口。 + +#### QueueingHint + +{{< feature-state for_k8s_version="v1.28" state="beta" >}} + + +QueueingHint 作为一个回调函数，用于决定是否将 Pod 重新排队到活跃队列或回退队列。 +每当集群中发生某种事件或变化时，此函数就会被执行。 +当 QueueingHint 发现事件可能使 Pod 可调度时，Pod 将被放入活跃队列或回退队列， +以便调度器可以重新尝试调度 Pod。 + +{{< note >}} + +在调度过程中对 QueueingHint 求值是一个 Beta 级别的特性，在 1.28 中默认被启用。 +你可以通过 `SchedulerQueueingHints` +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用它。 +{{< /note >}} +--> ### PreScore {#pre-score} +--> 这些插件用于执行 “前置评分（pre-scoring）” 工作，即生成一个可共享状态供 Score 插件使用。 如果 PreScore 插件返回错误，则调度周期将终止。 +--> ### Score {#scoring} 这些插件用于对通过过滤阶段的节点进行排序。调度器将为每个节点调用每个评分插件。 将有一个定义明确的整数范围，代表最小和最大分数。 -在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重 -合并所有插件的节点分数。 +在[标准化评分](#normalize-scoring)阶段之后， +调度器将根据配置的插件权重合并所有插件的节点分数。 -实现了 Reserve 扩展的插件，拥有两个方法，即 `Reserve` 和 `Unreserve`， +实现了 Reserve 接口的插件，拥有两个方法，即 `Reserve` 和 `Unreserve`， 他们分别支持两个名为 Reserve 和 Unreserve 的信息处理性质的调度阶段。 维护运行时状态的插件（又称 "有状态插件"）应该使用这两个阶段， 以便在节点上的资源被保留和未保留给特定的 Pod 时得到调度器的通知。 @@ -360,7 +398,7 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 If any Permit plugin denies a Pod, it is returned to the scheduling queue. This will trigger the Unreserve phase in [Reserve plugins](#reserve). --> -1. **拒绝** \ +2. **拒绝** \ 如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。 这将触发 [Reserve 插件](#reserve)中的 Unreserve 阶段。 @@ -372,7 +410,7 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 and the Pod is returned to the scheduling queue, triggering the Unreserve phase in [Reserve plugins](#reserve). --> -1. **等待**（带有超时） \ +3. **等待**（带有超时）\ 如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中” 的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到批准。 如果超时发生，**等待** 变成 **拒绝**，并且 Pod @@ -384,7 +422,7 @@ While any plugin can access the list of "waiting" Pods and approve them (see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. - --> +--> 尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 (查看 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle))。 我们期望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。 @@ -402,15 +440,14 @@ example, a pre-bind plugin may provision a network volume and mount it on the target node before allowing the Pod to run there. --> 这些插件用于执行 Pod 绑定前所需的所有工作。 -例如，一个 PreBind 插件可能需要制备网络卷并且在允许 Pod 运行在该节点之前 -将其挂载到目标节点上。 +例如，一个 PreBind 插件可能需要制备网络卷并且在允许 Pod +运行在该节点之前将其挂载到目标节点上。 -如果任何 PreBind 插件返回错误，则 Pod 将被 [拒绝](#reserve) 并且 -退回到调度队列中。 +如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#reserve)并且退回到调度队列中。 -这是个信息性的扩展点。 +这是个信息性的接口。 PostBind 插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。 -## 插件 API +## 插件 API {#plugin-api} -## 插件配置 +## 插件配置 {#plugin-configuration} +--> 你可以在调度器配置中启用或禁用插件。 -如果你在使用 Kubernetes v1.18 或更高版本，大部分调度 -[插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins) +如果你在使用 Kubernetes v1.18 或更高版本， +大部分调度[插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins) 都在使用中且默认启用。 +--> 除了默认的插件，你还可以实现自己的调度插件并且将它们与默认插件一起配置。 你可以访问 [scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) 了解更多信息。 @@ -521,7 +558,7 @@ plugins and get them configured along with default plugins. You can visit If you are using Kubernetes v1.18 or later, you can configure a set of plugins as a scheduler profile and then define multiple profiles to fit various kinds of workload. Learn more at [multiple profiles](/docs/reference/scheduling/config/#multiple-profiles). - --> -如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为 -一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。 +--> +如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为一个调度器配置文件， +然后定义不同的配置文件来满足各类工作负载。 了解更多关于[多配置文件](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)。 From c0a72d25d892480aa471de590cd8d2bfc4ca8b5b Mon Sep 17 00:00:00 2001 From: Suruchi Kumari Date: Wed, 29 Nov 2023 13:26:04 +0000 Subject: [PATCH 18/21] added doc for setting up cloud provider kubectl auth via plugin Signed-off-by: GitHub --- .../reference/access-authn-authz/authentication.md | 4 ++++ .../en/docs/tasks/tools/included/verify-kubectl.md | 13 ++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 7bc2a3d560f..a2ddea62a16 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -888,6 +888,10 @@ protocol specific logic, then returns opaque credentials to use. Almost all cred use cases require a server side component with support for the [webhook token authenticator](#webhook-token-authentication) to interpret the credential format produced by the client plugin. +{{< note >}} +Earlier versions of `kubectl` included built-in support for authenticating to AKS and GKE, but this is no longer present. +{{< /note >}} + ### Example use case In a hypothetical use case, an organization would run an external service that exchanges LDAP credentials diff --git a/content/en/docs/tasks/tools/included/verify-kubectl.md b/content/en/docs/tasks/tools/included/verify-kubectl.md index 78246912657..602ac7b10d1 100644 --- a/content/en/docs/tasks/tools/included/verify-kubectl.md +++ b/content/en/docs/tasks/tools/included/verify-kubectl.md @@ -35,4 +35,15 @@ If kubectl cluster-info returns the url response but you can't access your clust ```shell kubectl cluster-info dump -``` \ No newline at end of file +``` + +{{< note >}} +### Troubleshooting the 'No Auth Provider Found' Error Message + +In Kubernetes **v1.26**, kubectl removed the built-in authentication for the following cloud +providers managed Kubernetes offerings. These providers have released kubectl plugins to provide the cloud-specific authentication. For instructions, refer to the following provider documentation: + +* AKS (Azure): [kubelogin plugin](https://github.com/Azure/kubelogin) +* GKE (Google Cloud): [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) + +{{< /note >}} \ No newline at end of file From 708220bb13d1792064d9d5a67781ec865ae99017 Mon Sep 17 00:00:00 2001 From: Suruchi Kumari Date: Wed, 29 Nov 2023 19:40:47 +0530 Subject: [PATCH 19/21] Update content Co-authored-by: Tim Bannister --- .../en/docs/tasks/tools/included/verify-kubectl.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/content/en/docs/tasks/tools/included/verify-kubectl.md b/content/en/docs/tasks/tools/included/verify-kubectl.md index 602ac7b10d1..1d61af2907c 100644 --- a/content/en/docs/tasks/tools/included/verify-kubectl.md +++ b/content/en/docs/tasks/tools/included/verify-kubectl.md @@ -37,13 +37,12 @@ If kubectl cluster-info returns the url response but you can't access your clust kubectl cluster-info dump ``` -{{< note >}} -### Troubleshooting the 'No Auth Provider Found' Error Message +### Troubleshooting the 'No Auth Provider Found' error message {#no-auth-provider-found} -In Kubernetes **v1.26**, kubectl removed the built-in authentication for the following cloud -providers managed Kubernetes offerings. These providers have released kubectl plugins to provide the cloud-specific authentication. For instructions, refer to the following provider documentation: +In Kubernetes 1.26, kubectl removed the built-in authentication for the following cloud +providers' managed Kubernetes offerings. These providers have released kubectl plugins to provide the cloud-specific authentication. For instructions, refer to the following provider documentation: -* AKS (Azure): [kubelogin plugin](https://github.com/Azure/kubelogin) -* GKE (Google Cloud): [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) +* Azure AKS: [kubelogin plugin](https://github.com/Azure/kubelogin) +* Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) -{{< /note >}} \ No newline at end of file +(There could also be other reasons to see the same error message, unrelated to that change.) From 1efeb86821b1f699747924613d84c523a19a680f Mon Sep 17 00:00:00 2001 From: Suruchi Kumari Date: Wed, 29 Nov 2023 21:43:11 +0530 Subject: [PATCH 20/21] Update verify-kubectl.md --- content/en/docs/tasks/tools/included/verify-kubectl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/tools/included/verify-kubectl.md b/content/en/docs/tasks/tools/included/verify-kubectl.md index 1d61af2907c..ae5d818e02a 100644 --- a/content/en/docs/tasks/tools/included/verify-kubectl.md +++ b/content/en/docs/tasks/tools/included/verify-kubectl.md @@ -42,7 +42,7 @@ kubectl cluster-info dump In Kubernetes 1.26, kubectl removed the built-in authentication for the following cloud providers' managed Kubernetes offerings. These providers have released kubectl plugins to provide the cloud-specific authentication. For instructions, refer to the following provider documentation: -* Azure AKS: [kubelogin plugin](https://github.com/Azure/kubelogin) +* Azure AKS: [kubelogin plugin](https://azure.github.io/kubelogin/) * Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) (There could also be other reasons to see the same error message, unrelated to that change.) From 44d56518bcea6830f23e01ce3098141cc7eeed64 Mon Sep 17 00:00:00 2001 From: DeltaX Date: Thu, 30 Nov 2023 01:37:04 +0800 Subject: [PATCH 21/21] [zh] Sync cluster-level-pss. Remove useless step and command. --- .../tutorials/security/cluster-level-pss.md | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/content/zh-cn/docs/tutorials/security/cluster-level-pss.md b/content/zh-cn/docs/tutorials/security/cluster-level-pss.md index fe6cf93174b..6fead0ce0e0 100644 --- a/content/zh-cn/docs/tutorials/security/cluster-level-pss.md +++ b/content/zh-cn/docs/tutorials/security/cluster-level-pss.md @@ -434,25 +434,6 @@ following: --> 7. 在 default 名字空间下创建一个 Pod： - ``` - cat < /tmp/pss/nginx-pod.yaml - apiVersion: v1 - kind: Pod - metadata: - name: nginx - spec: - containers: - - image: nginx - name: nginx - ports: - - containerPort: 80 - EOF - ``` - -8. 在集群中创建 Pod： - ```shell kubectl apply -f https://k8s.io/examples/security/example-baseline-pod.yaml ```