Kubernetes命名空间：最佳实践？[已关闭]
< b >想改进这个问题？更新问题，以便通过编辑此帖子用事实和引用来回答问题。
我正在为一个基于django的应用程序实现kubernetes集群，但我没有找到命名空间的最佳实践。
我的应用程序将需要各种服务，例如postgresql集群，反向代理（traefik），弹性搜索/ Kibana集群和argoCD
将所有这些服务拉到一个称为生产的唯一命名空间中更好吗？还是我需要按服务将它们分开？
我开始按服务将它们分开，但我面临一些问题。例如，在argo命名空间上启动的argo工作流不能使用从postgreql命名空间存储的秘密。
谢谢你的帮助，Tux Craft
共有3个答案
对于每个服务，例如Argo应该在其命名空间中完成一组服务。
因此，在每个命名空间中运行多个Postgres是很实际的。
我认为最好有一个命名空间和以下几个部署：
> kubens airflow-test
> airflow-test
> kubectl get pods
> airflow-test-postgres
> airflow-test-redis
> airflow-test-worker
> airflow-test-webserver
> airflow-test-scheduler
在此设置中，您可以轻松地在 Pod 之间共享配置映射和机密
> kubectl get configmap
> airflow-test-configmap
>
> kubectl get secrets
> airflow-test-redis-secret
> airflow-test-postgres-secret
值得补充的是，每个吊舱应该有独立的部署。yaml文件，以便将来轻松管理它们
你的问题有点基于意见。但是，我将尝试通过提出两种解决方案来以某种方式弄清楚这个主题。首先，摘录自文档。在那里，您可以找到何时使用多个命名空间的段落：
命名空间旨在用于具有许多用户分布在多个团队或项目中的环境。对于具有几到几十个用户的集群，根本不需要创建或考虑命名空间。当您需要命名空间提供的功能时，开始使用它们。命名空间提供名称的作用域。资源的名称在命名空间中必须是唯一的，但不能跨命名空间是唯一的。命名空间不能相互嵌套，每个 Kubernetes 资源只能位于一个命名空间中。命名空间是一种在多个用户之间划分群集资源的方法（通过资源配额）。没有必要使用多个命名空间来分隔略有不同的资源，例如同一软件的不同版本：使用标签来区分同一命名空间中的资源。
根据本文档，在您的情况下，最好的解决方案是创建一个命名空间和多个部署。这将允许您避免以下问题：
例如，在argo命名空间上启动的argo工作流不能使用postgresql命名空间中存储的秘密。
从技术上讲，您可以使用多个命名空间创建相同的东西。但是，命名空间的重点是隔离，所以在您的情况下，这似乎不是一个好主意。您可以阅读关于位于另一个命名空间中的服务的非常好的主题。
-
问题内容： 我不完全确定行业中是否有标准，所以我在这里问。 我正在命名一个 Users 表，但是我不确定如何命名成员。 是一个显而易见的选项，但我想知道是否应在所有其他字段之前加上“ user_”作为前缀。 user_name user_age 或只是姓名和年龄等… 问题答案： 像这样的前缀是没有意义的，除非您有一些随意性。就像两个地址一样。然后，您可以使用地址_1，地址_2，地址_家庭等 与电话
-
我知道可以在React类中指定样式，如下所示： 我的目标应该是以这种方式进行所有样式设置，并且在CSS文件中完全没有指定样式吗？ 或者我应该完全避免内联样式吗？ 两种方法都做一点似乎有些奇怪和混乱——在调整样式时，需要检查两个地方。
-
我有一个处理实时事件的系统。用户可以在指定的时间间隔插入自定义事件。实时引擎使用java.time.Duration来计时事件。通过jsp向用户展示一个菜单，该菜单以（全）秒为单位指定Duration。事件列表被序列化为Long值。所以我有三种使用相同值的方法。我创建了一个值对象，在每次访问时执行转换，这样我就不必将转换分散在整个代码中。我想知道是否有更好的方法来完成这个场景。这是我的VO。
-
我有一个库伯内特斯集群，同一个应用程序运行几次，但名称空间不同。想象一下 现在我需要在所有这些 Pod 中每 10 分钟执行一次 cronjob。路径每次都是一样的。 有没有“最佳方法”来实现这一目标？ 我在想一个以“CronJob”类型运行的 kubectl 图像，如下所示： 但我很确定这不是解决问题的正确方法。
-
这里有些给使用和编写 Ansible playbook 的贴士. 你能在我们的 ansible-example repository.找到展示这些最佳实践的 playbook 样例.(注意: 这些示例用的也许不是最新版的中所有特性,但它们仍旧是极佳的参考.) Topics 最佳实践 接下来的章节将向你展示一种组织 playbook 内容方式. 你对 Ansible 的使用应该符合你的需求而不是我们
-
处理后台任务与常规调用方法有很大的不同。本指南旨在帮助让您的后台任务平稳有效地运行。本文基于 这篇博客文章。 使任务参数小而简单 方法（任务）在调用之前会被序列化。使用 TypeConverter 类将参数转换为 JSON 字符串。如果您有复杂的实体和 / 或大对象; 包括数组，最好将它们放入数据库，然后只将其标识 (id) 传递给后台任务。 错误例子: public void Method(En