gRPC GA (#39919)

content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md

@@ -7,6 +7,7 @@ slug: grpc-probes-now-in-beta
 
 **Author**: Sergey Kanzhelev (Google)
 
+_Update: Since this article was posted, the feature was graduated to GA in v1.27 and doesn't require any feature gates to be enabled.
 
 With Kubernetes 1.24 the gRPC probes functionality entered beta and is available by default.
 Now you can configure startup, liveness, and readiness probes for your gRPC app

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -302,10 +302,7 @@ Each probe must define exactly one of these four mechanisms:
   The target should implement
   [gRPC health checks](https://grpc.io/grpc/core/md_doc_health-checking.html).
   The diagnostic is considered successful if the `status`
-  of the response is `SERVING`.
+  of the response is `SERVING`.  
-  gRPC probes are an alpha feature and are only available if you
-  enable the `GRPCContainerProbe`
-  [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
 
 `httpGet`
 : Performs an HTTP `GET` request against the Pod's IP

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -101,8 +101,6 @@ For a reference to old feature gates that are removed, please refer to
 | `ExpandedDNSConfig` | `false` | Alpha | 1.22 | 1.25 |
 | `ExpandedDNSConfig` | `true` | Beta | 1.26 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `GRPCContainerProbe` | `false` | Alpha | 1.23 | 1.23 |
-| `GRPCContainerProbe` | `true` | Beta | 1.24 | |
 | `GracefulNodeShutdown` | `false` | Alpha | 1.20 | 1.20 |
 | `GracefulNodeShutdown` | `true` | Beta | 1.21 | |
 | `GracefulNodeShutdownBasedOnPodPriority` | `false` | Alpha | 1.23 | 1.23 |
@@ -293,6 +291,12 @@ For a reference to old feature gates that are removed, please refer to
 | `ExecProbeTimeout` | `true` | GA | 1.20 | - |
 | `JobMutableNodeSchedulingDirectives` | `true` | Beta | 1.23 | 1.26 |
 | `JobMutableNodeSchedulingDirectives` | `true` | GA | 1.27 | |
+| `GRPCContainerProbe` | `false` | Alpha | 1.23 | 1.23 |
+| `GRPCContainerProbe` | `true` | Beta | 1.24 | 1.26 |
+| `GRPCContainerProbe` | `true` | GA | 1.27 | |
+| `IdentifyPodOS` | `false` | Alpha | 1.23 | 1.23 |
+| `IdentifyPodOS` | `true` | Beta | 1.24 | 1.24 |
+| `IdentifyPodOS` | `true` | GA | 1.25 | - |
 | `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | 1.22 |
 | `JobTrackingWithFinalizers` | `false` | Beta | 1.23 | 1.24 |
 | `JobTrackingWithFinalizers` | `true` | Beta | 1.25 | 1.25 |

content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -240,21 +240,27 @@ kubectl describe pod goproxy
 
 {{< feature-state for_k8s_version="v1.24" state="beta" >}}
 
-If your application implements [gRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/master/doc/health-checking.md),
+If your application implements the [gRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/master/doc/health-checking.md),
-kubelet can be configured to use it for application liveness checks.
+this example shows how to configure Kubernetes to use it for application liveness checks.
-You must enable the `GRPCContainerProbe`
+Similarly you can configure readiness and startup probes.
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-in order to configure checks that rely on gRPC.
 
 Here is an example manifest:
 
 {{< codenew file="pods/probe/grpc-liveness.yaml" >}}
 
-To use a gRPC probe, `port` must be configured. If the health endpoint is configured
+To use a gRPC probe, `port` must be configured. If you want to distinguish probes of different types
-on a non-default service, you must also specify the `service`.
+and probes for different features you can use the `service` field.
+You can set `service` to the value `liveness` and make your gRPC Health Checking endpoint
+respond to this request differently then when you set `service` set to `readiness`.
+This lets you use the same endpoint for different kinds of container health check
+(rather than needing to listen on two different ports).
+If you want to specify your own custom service name and also specify a probe type,
+the Kubernetes project recommends that you use a name that concatenates
+those. For example: `myservice-liveness` (using `-` as a separator).
 
 {{< note >}}
-Unlike HTTP and TCP probes, named ports cannot be used and custom host cannot be configured.
+Unlike HTTP or TCP probes, you cannot specify the healthcheck port by name, and you
+cannot configure a custom hostname.
 {{< /note >}}
 
 Configuration problems (for example: incorrect port and service, unimplemented health checking protocol)