Kubernetes命名空间:用例和见解

“谁在第一,第二在什么,我不知道在第三” 

谁在第一? 雅培和科斯特洛

介绍

Kubernetes是一个具有多个概念的系统。这些概念中的许多概念在RESTful API(通常称为“资源”或“种类”)中表现为“对象”。这些概念之一是 命名空间。在Kubernetes中,命名空间是将单个Kubernetes集群划分为多个虚拟集群的方法。在这篇文章中,我们将重点介绍客户如何使用命名空间的示例。 

但首先,有一个隐喻:命名空间就像人类的姓氏。姓氏,例如黄,确定一个家庭单位。在黄氏家族中,其成员之一,例如黄氏家族很容易被家人认定为“山姆”。在家庭之外,避免使用“哪个山姆?”问题,Sam通常被称为“ Sam Wong”,甚至可能被称为“来自旧金山的Sam Wong”。  

命名空间是一种逻辑分区功能,该功能使一个Kubernetes群集可以由多个用户,一组用户或具有多个应用程序的单个用户使用,而无需担心不必要的交互。每个用户,一组用户或应用程序都可以存在于其命名空间中,与集群的每个其他用户隔离开来,并且好像它是集群的唯一用户一样运行。 (此外, 资源配额 提供将Kubernetes集群资源的子集分配给命名空间的功能。)

除了最琐碎的Kubernetes用途外,使用命名空间将使您受益。在这篇文章中,我们将介绍最常见的Google Cloud Platform用户使用Kubernetes用户使用命名空间的方法,但是我们的列表并不详尽,我们希望向您学习其他示例。

涵盖用例

  • 企业在名称空间中的角色和职责
  • 划分景观:开发与测试与产品
  • 非多租户方案的客户分区
  • 何时不使用名称空间

用例1:企业中的角色和职责

一个典型的企业包含多个业务/技术实体,它们彼此独立运行,并具有由企业本身管理的某种形式的总体控制层。当定义了与Kubernetes相关的角色和职责时,可以有效地在这样的环境中操作Kubernetes集群。 

以下是一些建议的角色及其职责,这些角色和职责可以使在大型组织中管理Kubernetes集群更加容易。

  • 设计者/架构师角色:该角色将定义整体命名空间策略,并考虑产品/位置/团队/成本中心,并确定如何将它们最佳映射到Kubernetes命名空间。投资这种角色可以防止名称空间扩散和“雪花”名称空间。
  • 管理员角色:该角色具有对所有Kubernetes集群的管理员访问权限。管理员可以创建/删除集群以及添加/删除节点以扩展集群。该角色将负责修补,保护和维护群集。以及在组织中不同实体之间实施配额。 Kubernetes Admin负责实施Designer / Architect定义的名称空间策略。 

这两个角色以及使用群集的实际开发人员还将获得企业安全和网络团队的支持和反馈,这些问题包括安全隔离要求,名称空间如何适合此模型,或协助网络子网和负载平衡器设置。

反模式

  1. Kubernetes孤立的使用“岛屿”而没有集中控制:如果没有最初的投资来建立围绕Kubernetes管理的集中控制结构,则存在以“蘑菇场”拓扑结构结束的风险,即组织内没有定义的集群大小/形状/结构。结果是由于资源利用不足而难以管理,风险较高且成本升高。
  2. 老式的IT控件阻碍了使用和创新:一种常见的趋势是尝试将现有的本地控件/过程转换为新的动态框架,从而降低了这些框架的敏捷性,并使快速动态部署的收益无效。
  3. Omni-cluster:延迟创建用于名称空间管理的结构/机制的工作可能会导致一个大型的Omni-cluster,很难将其分解为较小的使用组。 

用例2:使用命名空间对开发环境进行分区

软件开发团队通常将其开发管道划分为多个离散单元。这些单元采用各种形式并使用各种标签,但往往会导致离散的开发环境,QA环境,可能的登台环境以及最终的生产环境。生成的布局非常适合Kubernetes命名空间。管道中的每个环境或阶段都成为唯一的名称空间。

The above works well as each namespace can be templated and mirrored to the next subsequent environment in the dev cycle, e.g. dev->qa->prod. The fact that each namespace is logically discrete allows the development teams to work within an isolated “development” namespace. DevOps (The closest role at Google is called 现场可靠性工程 “ SRE”)将负责通过管道迁移代码,并确保为每个环境分配了适当的团队。最终,DevOps完全负责最终的生产环境,在该环境中将解决方案交付给最终用户。

将名称空间应用于开发周期的主要好处是可以维持软件组件的命名(例如微服务/端点),而不会在不同环境之间发生冲突。这是由于Kubernetes命名空间的隔离,例如开发人员中的serviceX在所有其他命名空间中都将被称为此类;但是,如有必要,可以在mycluster.com的开发命名空间中使用其完整限定名称serviceX.development.mycluster.com进行唯一引用。

反模式

  1. 滥用名称空间的好处会导致开发流程中出现不必要的环境。所以;如果您不进行登台部署,则不要创建“登台”命名空间。
  2. 过度拥挤的名称空间,例如将所有开发项目都放在一个巨大的“开发”命名空间中。由于名称空间会尝试分区,因此也请使用它们在项目中进行分区。由于命名空间是扁平的,因此您可能希望类似于以下内容:projectA-dev,projectA-prod作为projectA的命名空间。

用例3:对客户进行分区

例如,如果您是一家咨询公司,希望为您的每个客户管理单独的应用程序,那么Namespaces提供的分区将保持一致。您可以为每个客户,客户项目或客户业务部门创建一个单独的命名空间,以使它们保持不同,而不必担心在项目中为资源重复使用相同的名称。

这里一个重要的考虑因素是,Kubernetes当前不提供跨命名空间强制执行访问控制的机制,因此我们建议您不要在外部公开使用此方法开发的应用程序。

反模式

  1. 多租户应用程序不需要Kubernetes命名空间的额外复杂性,因为该应用程序已经在执行此分区。
  2. 客户到名称空间的映射不一致。例如,您在一家跨国公司赢得业务时,最初可能会考虑为该企业使用一个名称空间,而不考虑该客户可能更喜欢进一步分区,例如BigCorp会计和BigCorp工程。在这种情况下,客户部门可能各自保证使用名称空间。

何时不使用命名空间

在某些情况下,Kubernetes命名空间将无法提供所需的隔离。这可能是由于地理,计费或安全因素造成的。对于命名空间进行逻辑分区的所有好处,目前尚无执行分区的能力。 Kubernetes群集中的任何用户或资源都可以访问群集中的任何其他资源,而不管名称空间如何。因此,如果您需要保护或隔离资源,则最终的名称空间是一个单独的Kubernetes集群,您可以对其应用常规的security | ACL控件。

另一个您可能不考虑使用名称空间的时间是您希望反映地理上分散的部署。如果您希望靠近美国,欧盟和亚洲客户进行部署,建议在每个区域本地部署一个Kubernetes集群。

当可能需要按成本中心或客户要求对细粒度的账单进行退款时,建议将账单交给基础架构提供商。例如,在Google Cloud Platform(GCP)中,您可以使用单独的GCP 项目 要么 帐单帐户 并将Kubernetes集群部署到特定客户的项目。

在保密性或合规性要求客户之间完全不透明的情况下,每个客户/工作负载的Kubernetes集群将提供所需的隔离级别。再一次,您应该将资源分区委托给提供者。

正在努力提供(a)Kubernetes命名空间上的ACL,以能够加强安全性; (b)提供Kubernetes 集群联盟。这两种机制都将解决这些反模式中使用单独的Kubernetes集群的原因。 

容易掌握 反模式 Kubernetes的名称空间是版本控制。您不应该使用命名空间来消除Kubernetes资源版本的歧义。容器和容器注册表以及Kubernetes部署资源中提供了对版本控制的支持。通过使用Kubernetes容器模型,多个版本应共存,该模型还可以在具有部署的版本之间自动迁移。此外,版本范围作用域名称空间将导致群集中名称空间的大量扩散,使其难以管理。

卡夫古伯纳特

您可能希望,但是不能创建名称空间的层次结构。命名空间不能相互嵌套。例如,您不能将my-team.my-org创建为名称空间,但可能会有team-org。

命名空间易于创建和使用,但也很容易在无意间将代码部署到错误的命名空间中。良好的DevOps卫生建议在可能的情况下记录和自动化过程,这将有所帮助。避免使用错误的名称空间的另一种方法是设置一个 kubectl上下文

如前所述,Kubernetes目前不提供一种在命名空间之间实施安全性的机制。当您需要能够保证Kubernetes集群的用户或其资源无法访问任何其他Namespaces资源时,您仅应在受信任的域内使用Namespaces(例如内部使用),而不使用Namespaces。 Kubernetes身份验证和授权特殊兴趣小组正在讨论这种增强的安全功能,请访问 SIG认证

-Google Cloud Platform战略客户工程师Mike Altarace和Daz Wilkin