Kubernetes 命名空间:最佳实践?

问题描述

我正在为基于 django 的应用程序实现 kubernetes 集群,但我没有找到命名空间的最佳实践。

我的应用程序将需要各种服务,例如 postgresql 集群、反向代理 (traefik)、Elastic Search / Kibana 集群以及用于 CD 的 argoCD 和 argo 工作流。

将所有这些服务拉入一个名为生产的唯一命名空间是否更好?还是我需要按服务将它们分开?

我开始按服务将它们分开,但我遇到了一些问题。例如,在 argo 命名空间上启动的 argo 工作流不能使用从 postgresql 命名空间存储的机密。

感谢您的帮助, 礼服工艺

解决方法

你的问题有点基于意见。但是,我将尝试通过介绍这两种解决方案来以某种方式找出主题。首先,摘自the documentation。在那里你可以找到一个段落 when to use multiple namespaces:

命名空间旨在用于多个用户分布在多个团队或项目的环境中。对于拥有几到几十个用户的集群,您根本不需要创建或考虑命名空间。当您需要命名空间提供的功能时开始使用命名空间。 命名空间为名称提供了一个范围。资源名称在一个命名空间内必须是唯一的,但跨命名空间不能。命名空间不能相互嵌套,每个 Kubernetes 资源只能位于一个命名空间中。 命名空间是在多个用户之间划分集群资源的一种方式(通过 resource quota)。 不必使用多个命名空间来分隔略有不同的资源,例如同一软件的不同版本:使用labels来区分同一命名空间内的资源。

根据本文档,就您而言,最佳解决方案是创建一个命名空间和多个部署。这将允许您避免这样的问题:

例如,在 argo 命名空间上启动的 argo 工作流不能使用从 postgresql 命名空间存储的机密。

从技术上讲,您可以使用多个命名空间创建相同的内容。但是,命名空间的重点是隔离,因此在您的情况下这似乎不是一个好主意。您可以阅读关于 Service located in another namespace 的非常好的主题。

,

我认为最好有一个命名空间和少量部署 如下图:

> 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

值得补充的是,每个 Pod 都应该有独立的部署 .yaml 文件,以便将来轻松管理它们

,

对于每项服务,例如Argo 应该在其命名空间内完成一组服务。

因此,在每个命名空间中运行多个 Postgres 是可行的。