Kubernetes、Helm、Varnish、构建 vcl 文件

Question

我现在面临的是我的 kube 集群（rke2）内的 varnish 部署。

集群包含 6 个节点，我的应用程序 pod 通过自动缩放分布在所有节点上。

第一期：

Varnish 需要正确设置

acl purgers

和

backend(s)

，包括主机名和端口，并将该配置存储为

*.vcl

文件（我相信 ConfigMap 足以满足这样的需求）

问题 1：如何“响应”应用程序复制中的更改并更新 ConfigMap？

问题2：当我的应用程序中的某些内容发生更改（更改

backends

的数量，更新

purgers

等）时，如何“告诉”varnish重新加载配置文件？

问题3：清漆用

DaemonSet

还是

StatefulSet

？老实说，我个人会选择 Daemon，因为它会自动安装在集群上的所有节点中，但是如果我想对集群上的不同应用程序使用类似的机制（varnish），那么这将创建

no. nodes * no. applications

varnish pod。

感谢您的任何支持

Answer 1

使用

varnishreload

在运行时重新加载VCL

此时，Varnish 对后端定义进行编译时处理。这意味着在运行时不会发现突然的变化，并且需要

varnishreload

运行来重新加载 VCL 配置。正如您在问题中提到的，这同样适用于 ACL。

官方 Helm 图表

在 Varnish Software，我们有一个官方的 Helm 图表，但它指的是 Varnish Enterprise Docker 镜像，这是 Varnish 的商业版本。

我们目前正在开发该 Helm 图表的开源版本，我会要求我们的工程师在创建它时考虑 K8S 集群的动态特性。

但是，Varnish Enterprise 确实提供了动态 ACL 和动态后端，这可以轻松解决这些问题。如果您有兴趣，我建议您观看我创建的以下 Youtube 视频：https://www.youtube.com/watch?v=ELvwXh_gpyw.

恐怕您在使用我们的 Helm 图表的开源版本时需要多一点耐心。我希望能在夏天之前完成。

使用服务的内部 DNS 名称作为后端

解决 Kubernetes 动态特性的另一种方法是使用服务的内部 DNS 名称作为后端主机。

假设您有一个名为

hello-world

的服务，位于集群的

default

命名空间中。要将其用作 Varnish 服务器的后端，您可以在 VCL 中简单地指定以下后端定义：

backend default {
    .host = "hello-world.default.svc.cluster.local";
}

如果通过此服务公开的 Pod 扩展或缩小，该服务将在其内部服务 DNS 名称中反映这些更改，而不更改为该服务的 IP 地址。

我猜你可以在 ACL 定义中做同样的事情：

acl purgers
    "hello-world.default.svc.cluster.local";
    "some-other-service.default.svc.cluster.local";
}

守护进程集或状态集

我无法真正给你关于 Daemon Sets 与 Stateful Sets 的明确答案，但是我可以告诉你官方 Helm 图表支持这两种方式。

我想这取决于具体情况。但我真的无法就此提供可靠的建议。