在弄flink on k8s的时候遇到一个很奇怪的问题，你们在使用的时候遇到过这个问题吗？

这个问题可能是由于 Flink 在 Kubernetes 上的配置加载机制导致的。在 Kubernetes 上运行 Flink 时，Flink 会优先加载容器内部的配置文件，而不是宿主机上的配置文件。
解决这个问题的一种常见方法是在 Kubernetes Pod 中使用 ConfigMap 或 Secret 来注入配置文件。你可以创建一个 ConfigMap 来包含你的 flink-conf.yaml 配置文件，并在 Flink 的 Deployment 或 StatefulSet 中将这个 ConfigMap 挂载到容器内部的相应路径。这样，Flink 在启动时会加载容器内的配置文件，而不是默认的 /opt/flink/conf/flink-conf.yaml。
另外，确保在 Flink 的配置中正确指定了配置文件的路径。你可能需要检查一下 Flink 在 Kubernetes 上的启动脚本或配置文件，以确保它们引用了正确的配置文件路径。
如果你们使用的是 Helm Chart 来部署 Flink，也可以在 Helm Chart 中配置相应的值，以确保 Flink 在启动时加载正确的配置文件。
总的来说，要解决这个问题，你需要确保 Flink 在 Kubernetes 上能够正确加载你想要的配置文件，并且没有被容器内部的自动生成的配置文件覆盖掉。3月15日 10:37 ，此回答整理自钉群“【①群】Apache Flink China社区”

在使用 Apache Flink on Kubernetes (K8s) 时，确实有可能出现您描述的情况，即在 flink-conf.yaml 中定义的配置在某些情况下未被正确应用到 K8s 上运行的任务管理器（JobManager）和任务管理节点（TaskManager）。这种情况可能是由于以下几个原因导致的：

1. 配置覆盖：

   • 在 Flink on K8s 中，通过环境变量或命令行参数传递给容器的配置会优先级高于 flink-conf.yaml 文件中的静态配置。这意味着如果您在启动 Flink 容器时指定了特定的配置选项，这些配置将覆盖 flink-conf.yaml 中的相应设置。

2. 配置注入：

   • 当您通过 Flink Kubernetes Operator 或者 helm chart 部署 Flink 应用时，可能有默认的配置注入逻辑，它会在启动容器时动态创建一个新的 flink-conf.yaml 或修改已存在的配置文件。

3. 配置目录映射：

   • 如果您的 K8s 部署 YAML 文件没有正确挂载配置目录，或者配置卷（configMap 或 Secret）未正确关联到 Pod 中的 Flink 配置目录 /opt/flink/conf，那么容器内实际使用的可能是镜像自带的默认配置而非您外部提供的配置。

4. 配置更新后未重启服务：

   • 修改了 flink-conf.yaml 后，需要确保 JobManager 和 TaskManager 能够感知到配置变更并重新加载。在 K8s 中，即使配置映射正确，也需要考虑容器内的服务是否能够识别到外部配置文件的变动并作出反应。

要解决这个问题，请确保：

• 检查 K8s 部署 YAML 文件，确认配置文件的持久化卷映射是否正确设置。
• 确保没有通过环境变量或启动命令行参数无意间覆盖了所需的配置项。
• 如果使用的是 Flink Kubernetes Operator 或 Helm Chart，查阅相关文档了解如何正确地传递和注入自定义配置。
• 如果配置更新后容器内部服务未重新加载，可能需要手动触发重启或者查看是否有自动检测配置变更并重启的服务机制。

总之，在排查此类问题时，细致检查部署过程和容器启动参数是非常重要的步骤。同时，也可以参考 Flink 官方文档关于 Kubernetes 集成部分的具体指导。