Kubernetes 1.24:gRPC 容器探针功能进入 Beta 阶段

2022-06-10 14:19:46 浏览数 (1)

作者:Sergey Kanzhelev(谷歌)

在 Kubernetes 1.24 中,gRPC 探针(probe)功能进入了测试版,默认情况下可用。现在,你可以为 gRPC 应用程序配置启动、活动和就绪探针,而无需暴露任何 HTTP 端点,也不需要可执行文件。Kubernetes 可以通过 gRPC 原生连接到你的工作负载并查询其状态。

一些历史

让管理你的工作负载的系统检查应用程序是否健康、启动是否正常,以及应用程序是否认为自己可以接受流量,是很有用的。在添加 gRPC 探针支持之前,Kubernetes 已经允许你通过从容器镜像内部运行可执行文件、发出 HTTP 请求或检查 TCP 连接是否成功来检查健康状况。

对于大多数应用程序来说,这些检查就足够了。如果你的应用程序提供了用于运行状况(或准备就绪)检查的 gRPC 端点,则很容易重新调整 exec 探针的用途,将其用于 gRPC 运行状况检查。在博客文章Kubernetes 上检查 gRPC 服务器健康[1]中,Ahmet Alp Balkan 描述了如何做到这一点——这是一种至今仍在工作的机制。

有一个常用工具可以实现这一点,该工具创建[2]于 2018 年 8 月 21 日,并于2018 年 9 月 19 日[3]首次发布。

这种 gRPC 应用健康检查的方法非常受欢迎。使用 GitHub 上的基本搜索,发现了带有 grpc_health_probe 的3,626 个 Dockerfiles 文件[4]6,621 个 yaml 文件[5](在撰写本文时)。这很好地表明了该工具的受欢迎程度,以及对其本地支持的需求。

Kubernetes v1.23 引入了一个 alpha 质量的实现,原生支持使用 gRPC 查询工作负载状态。因为这是一个 alpha 特性,所以在 1.23 版中默认是禁用的。

使用该功能

我们用与其他探针类似的方式构建了 gRPC 健康检查,相信如果你熟悉 Kubernetes 中的其他探针类型,它会很容易使用[6]。与涉及 grpc_health_probe 可执行文件的变通办法相比,原生支持的健康探针有许多好处。

有了原生 gRPC 支持,你不需要下载和携带 10MB 的额外可执行文件。Exec 探针通常比 gRPC 调用慢,因为它们需要实例化一个新进程来运行可执行文件。当 pod 在最大资源下运行并且在实例化新进程时遇到困难时,它还会使检查变得不那么明智。

尽管有一些限制。因为为探针配置客户端证书很难,所以不支持需要客户端身份验证的服务。内置探针也不检查服务器证书,并忽略相关问题。

内置检查也不能给配置为忽略某些类型的错误(grpc_health_probe 为不同的错误返回不同的退出代码),并且不能被“链接”以在单个探测中对多个服务运行健康检查。

但是所有这些限制对于 gRPC 来说都是相当标准的,并且有简单的解决方法。

自己来试试吧

集群级设置

你可以今天尝试这个功能。要尝试原生 gRPC 探针,你可以在启用 GRPCContainerProbe 特性门的情况下自己启动 Kubernetes 集群,有许多工具可用[7]

由于特性门 GRPCContainerProbe 在 1.24 中是默认启用的,因此许多供应商都有现成提供此功能。因此,你可以在自己选择的平台上创建 1.24 集群。一些供应商允许在 1.23 集群上启用 alpha 特性。

例如,在编写本文时,你可以在 GKE 上运行测试集群来进行快速测试。其他供应商可能也有类似的功能,尤其是当你在 Kubernetes 1.24 发布后很久才阅读这篇博客时。

在 GKE 上使用以下命令(注意,版本是 1.23,并且指定了 enable-kubernetes-alpha)。

代码语言:javascript复制
gcloud container clusters create test-grpc 
    --enable-kubernetes-alpha 
    --no-enable-autorepair 
    --no-enable-autoupgrade 
    --release-channel=rapid 
    --cluster-version=1.23

你还需要配置 kubectl 来访问集群:

代码语言:javascript复制
gcloud container clusters get-credentials test-grpc

试用该功能

让我们创建 pod 来测试 gRPC 探针是如何工作的。对于这个测试,我们将使用 agnhost 镜像。这是一个 k8s 维护的镜像,可用于各种工作负载测试。例如,它有一个有用的grpc-health-checking[8]模块,该模块暴露了两个端口——一个是提供健康检查服务的端口,另一个是对 make-serving 和 make-not-serving 命令做出反应的 http 端口。

下面是一个 pod 定义示例。它启动 grpc-health-checking 模块,暴露端口 5000 和 8080,并配置 grpc 就绪探针:

代码语言:javascript复制
---
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

如果文件名为 test.yaml,你可以创建 pod,并检查它的状态。如输出片段所示,pod 将处于就绪状态。

代码语言:javascript复制
kubectl apply -f test.yaml
kubectl describe test-grpc

输出将包含如下内容:

代码语言:javascript复制
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True

现在,让我们将运行状况检查端点状态更改为 NOT_SERVING。为了调用 Pod 的 http 端口,让我们创建一个 port forward:

代码语言:javascript复制
kubectl port-forward test-grpc 8080:8080

你可以 curl 来调用这个命令...

代码语言:javascript复制
curl http://localhost:8080/make-not-serving

...几秒钟后,端口状态将切换到未就绪。

代码语言:javascript复制
kubectl describe pod test-grpc

现在的输出将显示:

代码语言:javascript复制
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")

一旦切换回来,大约一秒钟后,Pod 将回到就绪状态:

代码语言:javascript复制
curl http://localhost:8080/make-serving
kubectl describe test-grpc

输出表明 Pod 返回到就绪状态:

代码语言:javascript复制
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True

Kubernetes 上这种新的内置 gRPC 健康探测,使通过 gRPC 实现健康检查,比依赖于使用单独的 exec 探针的旧方法容易得多。通读官方文档[9]以了解更多信息,并在该功能正式发布前提供反馈。

总结

Kubernetes 是一个流行的工作负载协调平台,我们根据反馈和需求添加功能。像 gRPC 探针支持这样的特性是一个小的改进,将使许多应用程序开发人员的生活更容易,应用程序更有弹性。在该功能 GA(正式发布)之前,立即试用,并给出反馈。

参考资料

[1]

Kubernetes 上检查 gRPC 服务器健康: https://kubernetes.io/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/

[2]

创建: https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d

[3]

2018 年 9 月 19 日: https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1

[4]

3,626 个 Dockerfiles 文件: https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code

[5]

6,621 个 yaml 文件: https://github.com/search?l=YAML&q=grpc_health_probe&type=Code

[6]

很容易使用: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe

[7]

许多工具可用: https://kubernetes.io/docs/tasks/tools/

[8]

grpc-health-checking: https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking

[9]

文档: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe

CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux Foundation,是非营利性组织。

CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。

0 人点赞