在 Kubernetes 集群上运行 Common Lisp 应用程序答案

【问题标题】：running Common Lisp application on Kubernetes cluster在 Kubernetes 集群上运行 Common Lisp 应用程序
【发布时间】：2021-11-30 23:03:09
【问题描述】：

我已经在 GKE 中部署了 prod 10+ java/js 微服务，一切都很好，没有使用外部卷，它是生成新图像、推送到容器注册表以及将应用程序升级到新版本时的一个简单过程，只需使用新映像部署新部署，并升级使用滚动更新的 pod。

我的问题是 Common Lisp 应用程序会是什么样子？该语言的主要好处是可以在运行时更改代码。配置.lisp 文件是否应该作为 ConfigMap 附加？（对 ConfigMap 的更新仍然需要重新创建 pod 以应用新的 ConfigMap 更改）或者可能是一些卷？（但是如果有 10 个相同部署的 pod 怎么办？都从同一个卷中读取？如果有 50 个或更多 pod 怎么办（不会有一些问题？））并且应用程序的新版本的部署应该看起来像 v1和 v2（新 pod）还是我们以某种方式使用运行时更改的好处（使用我上面提到的解决方案），并且 pod 版本保持不变，而新代码是通过一些外部解决方案添加的

【问题讨论】：

更新：我们确实为 nginx、mime.types 等使用了配置映射，但没有为应用程序使用卷（仅用于工具（jenkins、nexus 等））
我不能说 kubernetes 部分，但对于任何了解 Kubernetes 的人来说，Lisp 应用程序都可以运行在运行时更改类/函数定义的代码，同时更改值的实例；通常你可以打开一个服务器并连接一个 REPL 来执行代码；这不是万无一失的，但是您可以在应用程序运行时小心地将其迁移到较新的版本。有时甚至可能需要完全重启（或者比打补丁更简单）。
嗨@potatopotato，Vatine 的回答能回答你的问题吗？

标签： kubernetes lisp common-lisp

【解决方案1】：

我可能会用编译后的代码生成一个镜像，也可能是一个转储后的镜像，然后依靠 Kubernetes 以一种明智的方式重新启动 Deployment 或 StatefulSet 中的 pod。如有必要（基于网络），请使用就绪检查来控制哪些 pod 将接收请求。

顺便说一句，ConfigMap 的投影内容应该显示在容器中，除非您已经从 ConfigMap 中指定了投影键的文件名，因此应该可以以这种方式保留源，然后让代码本身检查更新，或者让另一种机制发出“重新加载时间”的信号。但是，除非您将其与编译配对，否则您最终可能会得到解释代码。

【讨论】：