diff --git a/content/zh-cn/blog/_posts/2022-05-13-grpc-probes-in-beta.md b/content/zh-cn/blog/_posts/2022-05-13-grpc-probes-in-beta.md
new file mode 100644
index 0000000000..657f768e31
--- /dev/null
+++ b/content/zh-cn/blog/_posts/2022-05-13-grpc-probes-in-beta.md
@@ -0,0 +1,343 @@
+---
+layout: blog
+title: "Kubernetes 1.24：gRPC 容器探针功能进入 Beta 阶段"
+date: 2022-05-13
+slug: grpc-probes-now-in-beta
+---
+<!--
+layout: blog
+title: "Kubernetes 1.24: gRPC container probes in beta"
+date: 2022-05-13
+slug: grpc-probes-now-in-beta
+-->
+
+<!--
+**Author**: Sergey Kanzhelev (Google)
+-->
+**作者**：Sergey Kanzhelev (Google)
+
+<!--
+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
+without exposing any HTTP endpoint, nor do you need an executable. Kubernetes can natively connect to your your workload via gRPC and query its status.
+-->
+在 Kubernetes 1.24 中，gRPC 探针（probe）功能进入了 beta 阶段，默认情况下可用。
+现在，你可以为 gRPC 应用程序配置启动、活跃和就绪探测，而无需公开任何 HTTP 端点，
+也不需要可执行文件。Kubernetes 可以通过 gRPC 直接连接到你的工作负载并查询其状态。
+
+<!--
+## Some history
+
+It's useful to let the system managing your workload check that the app is
+healthy, has started OK, and whether the app considers itself good to accept
+traffic. Before the gRPC support was added, Kubernetes already allowed you to
+check for health based on running an executable from inside the container image,
+by making an HTTP request, or by checking whether a TCP connection succeeded.
+-->
+## 一些历史
+
+让管理你的工作负载的系统检查应用程序是否健康、启动是否正常，以及应用程序是否认为自己可以接收流量，是很有用的。
+在添加 gRPC 探针支持之前，Kubernetes 已经允许你通过从容器镜像内部运行可执行文件、发出 HTTP
+请求或检查 TCP 连接是否成功来检查健康状况。
+
+<!--
+For most apps, those checks are enough. If your app provides a gRPC endpoint
+for a health (or readiness) check, it is easy
+to repurpose the `exec` probe to use it for gRPC health checking.
+In the blog article [Health checking gRPC servers on Kubernetes](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/),
+Ahmet Alp Balkan described how you can do that — a mechanism that still works today.
+-->
+对于大多数应用程序来说，这些检查就足够了。如果你的应用程序提供了用于运行状况（或准备就绪）检查的
+gRPC 端点，则很容易重新调整 `exec` 探针的用途，将其用于 gRPC 运行状况检查。
+在博文[在 Kubernetes 上对 gRPC 服务器进行健康检查](/zh-cn/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)中，
+Ahmet Alp Balkan 描述了如何做到这一点 —— 这种机制至今仍在工作。
+
+<!--
+There is a commonly used tool to enable this that was [created](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)
+on August 21, 2018, and with
+the first release at [Sep 19, 2018](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1).
+-->
+2018 年 8 月 21 日所[创建](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)的一种常用工具可以启用此功能，
+工具于 [2018 年 9 月 19 日](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1)首次发布。
+
+<!--
+This approach for gRPC apps health checking is very popular. There are [3,626 Dockerfiles](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)
+with the `grpc_health_probe` and [6,621 yaml](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code) files that are discovered with the
+basic search on GitHub (at the moment of writing). This is good indication of the tool popularity
+and the need to support this natively.
+-->
+这种 gRPC 应用健康检查的方法非常受欢迎。使用 GitHub 上的基本搜索，发现了带有 `grpc_health_probe`
+的 [3,626 个 Dockerfile 文件](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)和
+[6,621 个 yaml 文件](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code)（在撰写本文时）。
+这很好地表明了该工具的受欢迎程度，以及对其本地支持的需求。
+
+<!--
+Kubernetes v1.23 introduced an alpha-quality implementation of native support for
+querying a workload status using gRPC. Because it was an alpha feature,
+this was disabled by default for the v1.23 release.
+-->
+Kubernetes v1.23 引入了一个 alpha 质量的实现，原生支持使用 gRPC 查询工作负载状态。
+因为这是一个 alpha 特性，所以在 1.23 版中默认是禁用的。
+
+<!--
+## Using the feature
+
+We built gRPC health checking in similar way with other probes and believe
+it will be [easy to use](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)
+if you are familiar with other probe types in Kubernetes.
+The natively supported health probe has many benefits over the workaround involving `grpc_health_probe` executable.
+-->
+## 使用该功能
+
+我们用与其他探针类似的方式构建了 gRPC 健康检查，相信如果你熟悉 Kubernetes 中的其他探针类型，
+它会[很容易使用](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。
+与涉及 `grpc_health_probe` 可执行文件的解决办法相比，原生支持的健康探针有许多好处。
+
+<!--
+With the native gRPC support you don't need to download and carry `10MB` of an additional executable with your image.
+Exec probes are generally slower than a gRPC call as they require instantiating a new process to run an executable.
+It also makes the checks less sensible for edge cases when the pod is running at maximum resources and has troubles
+instantiating new processes.
+-->
+有了原生 gRPC 支持，你不需要在镜像中下载和携带 `10MB` 的额外可执行文件。
+Exec 探针通常比 gRPC 调用慢，因为它们需要实例化一个新进程来运行可执行文件。
+当 Pod 在最大资源下运行并且在实例化新进程时遇到困难时，它还使得对边界情况的检查变得不那么智能。
+
+<!--
+There are a few limitations though. Since configuring a client certificate for probes is hard,
+services that require client authentication are not supported. The built-in probes are also
+not checking the server certificates and ignore related problems.
+-->
+不过有一些限制。由于为探针配置客户端证书很难，因此不支持依赖客户端身份验证的服务。
+内置探针也不检查服务器证书，并忽略相关问题。
+
+<!--
+Built-in checks also cannot be configured to ignore certain types of errors
+(`grpc_health_probe` returns different exit codes for different errors),
+and cannot be "chained" to run the health check on multiple services in a single probe.
+-->
+内置检查也不能配置为忽略某些类型的错误（`grpc_health_probe` 针对不同的错误返回不同的退出代码），
+并且不能“串接”以在单个探测中对多个服务运行健康检查。
+
+<!--
+But all these limitations are quite standard for gRPC and there are easy workarounds
+for those.
+-->
+但是所有这些限制对于 gRPC 来说都是相当标准的，并且有简单的解决方法。
+
+<!--
+## Try it for yourself
+
+### Cluster-level setup
+
+You can try this feature today. To try native gRPC probes, you can spin up a Kubernetes cluster
+yourself with the `GRPCContainerProbe` feature gate enabled, there are many [tools available](/docs/tasks/tools/).
+-->
+## 自己试试
+
+### 集群级设置
+
+你现在可以尝试这个功能。要尝试原生 gRPC 探针，你可以自己启动一个启用了
+`GRPCContainerProbe` 特性门控的 Kubernetes 集群，可用的[工具](/zh-cn/docs/tasks/tools/)有很多。
+
+<!--
+Since the feature gate `GRPCContainerProbe` is enabled by default in 1.24,
+many vendors will have this functionality working out of the box.
+So you may just create an 1.24 cluster on platform of your choice. Some vendors
+allow to enable alpha features on 1.23 clusters.
+-->
+由于特性门控 `GRPCContainerProbe` 在 1.24 版本中是默认启用的，因此许多供应商支持此功能开箱即用。
+因此，你可以在自己选择的平台上创建 1.24 版本集群。一些供应商允许在 1.23 版本集群上启用 alpha 特性。
+
+<!--
+For example, at the moment of writing, you can spin up the test cluster on GKE for a quick test.
+Other vendors may also have similar capabilities, especially if you
+are reading this blog post long after the Kubernetes 1.24 release.
+-->
+例如，在编写本文时，你可以在 GKE 上运行测试集群来进行快速测试。
+其他供应商可能也有类似的功能，尤其是当你在 Kubernetes 1.24 版本发布很久后才阅读这篇博客时。
+
+<!--
+On GKE use the following command (note, version is `1.23` and `enable-kubernetes-alpha` are specified).
+-->
+在 GKE 上使用以下命令（注意，版本是 `1.23`，并且指定了 `enable-kubernetes-alpha`）。
+
+```shell
+gcloud container clusters create test-grpc \
+    --enable-kubernetes-alpha \
+    --no-enable-autorepair \
+    --no-enable-autoupgrade \
+    --release-channel=rapid \
+    --cluster-version=1.23
+```
+
+<!--
+You will also need to configure `kubectl` to access the cluster:
+-->
+你还需要配置 kubectl 来访问集群：
+
+```shell
+gcloud container clusters get-credentials test-grpc
+```
+
+<!--
+### Trying the feature out
+
+Let's create the pod to test how gRPC probes work. For this test we will use the `agnhost` image.
+This is a k8s maintained image with that can be used for all sorts of workload testing.
+For example, it has a useful [grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) module
+that exposes two ports - one is serving health checking service,
+another - http port to react on commands `make-serving` and `make-not-serving`.
+-->
+### 试用该功能
+
+让我们创建 Pod 来测试 gRPC 探针是如何工作的。对于这个测试，我们将使用 `agnhost` 镜像。
+这是一个 k8s 维护的镜像，可用于各种工作负载测试。例如，它有一个有用的
+[grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking)
+模块，该模块暴露了两个端口：一个是提供健康检查服务的端口，另一个是对 `make-serving` 和
+`make-not-serving` 命令做出反应的 http 端口。
+
+<!--
+Here is an example pod definition. It starts the `grpc-health-checking` module,
+exposes ports `5000` and `8080`, and configures gRPC readiness probe:
+-->
+下面是一个 Pod 定义示例。它启用 `grpc-health-checking` 模块，暴露 5000 和 8080 端口，并配置 gRPC 就绪探针：
+
+``` yaml
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-grpc
+spec:
+  containers:
+  - name: agnhost
+    image: k8s.gcr.io/e2e-test-images/agnhost:2.35
+    command: ["/agnhost", "grpc-health-checking"]
+    ports:
+    - containerPort: 5000
+    - containerPort: 8080
+    readinessProbe:
+      grpc:
+        port: 5000
+```
+
+<!--
+If the file called `test.yaml`, you can create the pod and check it's status.
+The pod will be in ready state as indicated by the snippet of the output.
+-->
+如果文件名为 `test.yaml`，你可以用以下命令创建 Pod，并检查它的状态。如输出片段所示，Pod 将处于就绪状态。
+
+```shell
+kubectl apply -f test.yaml
+kubectl describe test-grpc
+```
+
+<!--
+The output will contain something like this:
+-->
+输出将包含如下内容：
+
+```
+Conditions:
+  Type              Status
+  Initialized       True
+  Ready             True
+  ContainersReady   True
+  PodScheduled      True
+```
+
+<!--
+Now let's change the health checking endpoint status to NOT_SERVING.
+In order to call the http port of the Pod, let's create a port forward:
+-->
+现在让我们将健康检查端点状态更改为 `NOT_SERVING`。为了调用 Pod 的 http 端口，让我们创建一个端口转发：
+
+```shell
+kubectl port-forward test-grpc 8080:8080
+```
+
+<!--
+You can `curl` to call the command...
+-->
+你可以用 `curl` 来调用这个命令。
+
+```shell
+curl http://localhost:8080/make-not-serving
+```
+
+<!--
+... and in a few seconds the port status will switch to not ready.
+-->
+几秒钟后，端口状态将切换到未就绪。
+
+```shell
+kubectl describe pod test-grpc
+```
+
+<!--
+The output now will have:
+-->
+现在的输出将显示：
+
+```
+Conditions:
+  Type              Status
+  Initialized       True
+  Ready             False
+  ContainersReady   False
+  PodScheduled      True
+
+...
+
+  Warning  Unhealthy  2s (x6 over 42s)  kubelet            Readiness probe failed: service unhealthy (responded with "NOT_SERVING")
+```
+
+<!--
+Once it is switched back, in about one second the Pod will get back to ready status:
+-->
+一旦切换回来，Pod 将在大约一秒钟后恢复到就绪状态：
+
+``` bsh
+curl http://localhost:8080/make-serving
+kubectl describe test-grpc
+```
+
+<!--
+The output indicates that the Pod went back to being `Ready`:
+-->
+输出表明 Pod 恢复为 `Ready`：
+
+```
+Conditions:
+  Type              Status
+  Initialized       True
+  Ready             True
+  ContainersReady   True
+  PodScheduled      True
+```
+
+<!--
+This new built-in gRPC health probing on Kubernetes makes implementing a health-check via gRPC
+much easier than the older approach that relied on using a separate `exec` probe. Read through
+the official
+[documentation](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)
+to learn more and provide feedback before the feature will be promoted to GA.
+-->
+Kubernetes 上这种新的内置 gRPC 健康探测，使得通过 gRPC 实现健康检查比依赖使用额外的 `exec`
+探测的旧方法更容易。请阅读官方
+[文档](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)
+了解更多信息并在该功能正式发布（GA）之前提供反馈。
+
+<!--
+## Summary
+
+Kubernetes is a popular workload orchestration platform and we add features based on feedback and demand.
+Features like gRPC probes support is a minor improvement that will make life of many app developers
+easier and apps more resilient. Try it today and give feedback, before the feature went into GA.
+-->
+## 总结
+
+Kubernetes 是一个流行的工作负载编排平台，我们根据反馈和需求添加功能。
+像 gRPC 探针支持这样的特性是一个小的改进，它将使许多应用程序开发人员的生活更容易，应用程序更有弹性。
+在该功能 GA（正式发布）之前，现在就试试，并给出反馈。