Update 2018-10-01-health-checking-grpc.md
yixin21
GitHub
parent
a3c77a0028
commit
92c82ef249
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
layout: blog
|
||||
title: '在 Kubernetes 上运行状况检查 gRPC 服务器'
|
||||
title: '在 Kubernetes 上对 gRPC 服务器进行健康检查'
|
||||
date: 2018-10-01
|
||||
---
|
||||
<!--
|
||||
|
|
@ -24,7 +24,7 @@ configure health checks. In this article, we will talk about
|
|||
[grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/), a
|
||||
Kubernetes-native way to health check gRPC apps.
|
||||
--->
|
||||
[gRPC](https://grpc.io) 将成为本地云微服务间进行通信的通用语言。如果您今天将 gRPC 应用程序部署到 Kubernetes，您可能会想要了解配置运行状况检查的最佳方法。在本文中，我们将介绍 [grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/)，这是 Kubernetes 原生的健康状况检查 gRPC 应用程序的方法。
|
||||
[gRPC](https://grpc.io) 将成为本地云微服务间进行通信的通用语言。如果您现在将 gRPC 应用程序部署到 Kubernetes，您可能会想要了解配置健康检查的最佳方法。在本文中，我们将介绍 [grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/)，这是 Kubernetes 原生的健康检查 gRPC 应用程序的方法。
|
||||
|
||||
<!--
|
||||
If you're unfamiliar, Kubernetes [health
|
||||
|
|
@ -33,7 +33,7 @@ checks](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
|
|||
while you're sleeping. They detect unresponsive pods, mark them unhealthy, and
|
||||
cause these pods to be restarted or rescheduled.
|
||||
--->
|
||||
如果您不熟悉，Kubernetes的 [健康状况检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)（活动性和就绪性探测器）可以使您的应用程序在睡眠时保持可用状态。当检测到没有回应的 Pod 时，会将其标记为不健康，并使这些 Pod 重新启动或重新安排。
|
||||
如果您不熟悉，Kubernetes的 [健康检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)（存活探针和就绪探针）可以使您的应用程序在睡眠时保持可用状态。当检测到没有回应的 Pod 时，会将其标记为不健康，并使这些 Pod 重新启动或重新安排。
|
||||
|
||||
<!--
|
||||
Kubernetes [does not
|
||||
|
|
@ -45,7 +45,7 @@ approaches when they deploy to Kubernetes:
|
|||
--->
|
||||
Kubernetes 原本 [不支持](https://github.com/kubernetes/kubernetes/issues/21493) gRPC 健康检查。gRPC 的开发人员在 Kubernetes 中部署时可以采用以下三种方法：
|
||||
|
||||
[](/images/blog/2019-09-30-health-checking-grpc/options.png)
|
||||
[](/images/blog/2019-09-30-health-checking-grpc/options.png)
|
||||
|
||||
|
||||
<!--
|
||||
|
|
@ -62,7 +62,7 @@ Can we do better? Absolutely.
|
|||
--->
|
||||
1. **httpGet prob：** 不能与 gRPC 一起使用。您需要重构您的应用程序，必须同时支持 gRPC 和 HTTP/1.1 协议（在不同的端口号上）。
|
||||
2. **tcpSocket probe：** 打开 gRPC 服务器的 Socket 是没有意义的，因为它无法读取响应主体。
|
||||
3. **exec probe：** 将定期调用容器生态系统中的程序。对于 gRPC，这意味着您要自己实现运行健康状况 RPC，然后使用容器编写并交付客户端工具。
|
||||
3. **exec probe：** 将定期调用容器生态系统中的程序。对于 gRPC，这意味着您要自己实现健康 RPC，然后使用容器编写并交付客户端工具。
|
||||
|
||||
我们可以做得更好吗？这是肯定的。
|
||||
|
||||
|
|
@ -79,8 +79,8 @@ To standardize the "exec probe" approach mentioned above, we need:
|
|||
|
||||
为了使上述 "exec probe" 方法标准化，我们需要：
|
||||
|
||||
- 可以在任何 gRPC 服务器中轻松实现的 **标准** 健康状态检查 "协议" 。
|
||||
- 一种 **标准** 健康状态检查 "工具" ，可以轻松查询健康协议。
|
||||
- 可以在任何 gRPC 服务器中轻松实现的 **标准** 健康检查 "协议" 。
|
||||
- 一种 **标准** 健康检查 "工具" ，可以轻松查询健康协议。
|
||||
|
||||
<!--
|
||||
Thankfully, gRPC has a [standard health checking
|
||||
|
|
@ -89,7 +89,7 @@ can be used easily from any language. Generated code and the utilities for
|
|||
setting the health status are shipped in nearly all language implementations of
|
||||
gRPC.
|
||||
--->
|
||||
幸运的是，gRPC 具有 [标准的健康状况检查协议](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md)。可以用任何语言轻松调用它。几乎所有实现 gRPC 的语言都附带了生成的代码和用于设置健康状态的实用程序。
|
||||
幸运的是，gRPC 具有 [标准的健康检查协议](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md)。可以用任何语言轻松调用它。几乎所有实现 gRPC 的语言都附带了生成的代码和用于设置健康状态的实用程序。
|
||||
|
||||
<!--
|
||||
If you
|
||||
|
|
@ -97,7 +97,7 @@ If you
|
|||
this health check protocol in your gRPC apps, you can then use a standard/common
|
||||
tool to invoke this `Check()` method to determine server status.
|
||||
--->
|
||||
如果您在 gRPC 应用程序中 [实现](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto) 此健康状况检查协议，那么可以使用标准或通用工具调用 `Check()` 方法来确定服务器状态。
|
||||
如果您在 gRPC 应用程序中 [实现](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto) 此健康检查协议，那么可以使用标准或通用工具调用 `Check()` 方法来确定服务器状态。
|
||||
|
||||
<!--
|
||||
The next thing you need is the "standard tool", and it's the
|
||||
|
|
@ -114,7 +114,7 @@ The next thing you need is the "standard tool", and it's the
|
|||
With this tool, you can use the same health check configuration in all your gRPC
|
||||
applications. This approach requires you to:
|
||||
--->
|
||||
使用此工具，您可以在所有 gRPC 应用程序中使用相同的健康状况检查配置。这种方法有以下要求：
|
||||
使用此工具，您可以在所有 gRPC 应用程序中使用相同的健康检查配置。这种方法有以下要求：
|
||||
|
||||
<!--
|
||||
1. Find the gRPC "health" module in your favorite language and start using it
|
||||
|
|
@ -128,7 +128,7 @@ applications. This approach requires you to:
|
|||
--->
|
||||
1. 用您喜欢的语言找到 gRPC 的 "健康" 模块并开始使用它（例如 [Go 库](https://godoc.org/github.com/grpc/grpc-go/health)）。
|
||||
2. 将二进制文件 [grpc_health_probe](https://github.com/grpc-ecosystem/grpc-health-probe/) 送到容器中。
|
||||
3. 在容器中 [配置](https://github.com/grpc-ecosystem/grpc-health-probe/tree/1329d682b4232c102600b5e7886df8ffdcaf9e26#example-grpc-health-checking-on-kubernetes) Kubernetes 的 "exec" 检查模块调用 "grpc_health_probe" 工具。
|
||||
3. [配置](https://github.com/grpc-ecosystem/grpc-health-probe/tree/1329d682b4232c102600b5e7886df8ffdcaf9e26#example-grpc-health-checking-on-kubernetes) Kubernetes 的 "exec" 检查模块来调用容器中的 "grpc_health_probe" 工具。
|
||||
|
||||
<!--
|
||||
In this case, executing "grpc_health_probe" will call your gRPC server over
|
||||
|
|
@ -164,5 +164,5 @@ feedback](https://github.com/grpc-ecosystem/grpc-health-probe/).
|
|||
## 更多内容
|
||||
|
||||
- 协议： [GRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md) ([health.proto](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto))
|
||||
- 文档： [Kubernetes 活跃性和就绪性检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
|
||||
- 文章： [升级版 Kubernetes Health Check Patterns](https://ahmet.im/blog/advanced-kubernetes-health-checks/)
|
||||
- 文档： [Kubernetes 存活和就绪探针](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
|
||||
- 文章： [升级版 Kubernetes 健康检查模式](https://ahmet.im/blog/advanced-kubernetes-health-checks/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue