当您开始构建越来越多的 Kubernetes 服务时，一开始很简单的事情开始变得更加复杂。 例如，开发团队不能以相同的名称创建服务或部署。 如果您有数千个 Pod，仅仅列出它们就会花费大量时间，更不用说对它们进行适当的管理了。 这只是冰山一角。
让我们看看命名空间如何让管理 Kubernetes 资源变得更加容易。 那么什么是命名空间呢？ 命名空间可以被视为 Kubernetes 集群中的虚拟集群。 您可以在同一个 Kubernetes 集群中拥有多个独立的命名空间。 他们可以真正帮助您和您的团队在组织、安全甚至系统性能方面提供帮助。
在大多数 Kubernetes 发行版中，集群开箱即用，带有一个名为“default”的命名空间。 Kubernetes 实际上处理三个命名空间：default、kube-system 和 kube-public。 目前，Kube-public 的使用频率并不高。
离开 kube 命名空间是一个好主意，特别是在像 Google Kubernetes Engine 这样的托管系统中。 它使用“默认”命名空间作为创建服务和应用程序的位置。 它绝对没有什么特别之处，只是 Kubernetes 配置为开箱即用，并且您无法删除它。 这对于入门和低性能系统来说非常有用，但我不建议在大型产品系统上使用默认名称空间。 在后一种情况下，一个开发团队可以轻松地重写其他人的代码，并在没有意识到的情况下破坏另一个团队的工作。
因此，您应该创建多个命名空间并使用它们将您的服务分段为可管理的块。 可以使用单个命令创建命名空间。 如果要创建名为 test 的命名空间，请使用 $ kubectl create namespace test 命令，或者简单地创建一个 YAML 文件并像任何其他 Kubernetes 资源一样使用它。
您可以使用 $ kubectl get namespace 命令查看所有命名空间。
执行后，您将看到三个内置命名空间和一个名为“test”的新命名空间。 让我们看一下用于创建 pod 的简单 YAML 文件。 您可以注意到其中没有提及名称空间。
如果您使用 kubectl 运行此文件，它将在当前活动命名空间中创建 mypod 模块。 这将是默认命名空间，直到您更改它为止。 有两种方法可以告诉 Kubernetes 您要在哪个命名空间中创建资源。 第一种方法是在创建资源时使用命名空间标志。
第二种方法是在 YAML 声明中指定名称空间。
如果您在 YAML 中指定命名空间，则资源将始终在该空间中创建。 如果您在使用命名空间标志时尝试使用不同的命名空间，该命令将失败。 现在，如果您尝试找到您的 Pod，您将找不到。
这是因为所有命令都是在当前活动命名空间之外执行的。 您需要使用命名空间标志来查找 pod，但这很快就会变得乏味，特别是如果您是使用自己的命名空间的团队中的开发人员，并且不想为每个命令使用该标志。 让我们看看如何解决这个问题。
开箱即用，您的活动名称空间被命名为默认名称空间。 如果您未在资源的 YAML 中指定命名空间，则所有 Kubernetes 命令都将使用该活动的默认命名空间。 不幸的是，尝试使用 kubectl 管理活动命名空间可能会失败。 然而，有一个非常好的工具叫 Kubens，可以使这个过程变得更加容易。 运行 kubens 命令时，您会看到所有命名空间，其中突出显示活动命名空间。
要将活动命名空间切换到测试命名空间，只需运行 $ kubens test 命令即可。 如果您再次运行 $kubens 命令，您可以看到现在分配了一个新的活动命名空间 - test。
这意味着您不需要命名空间标志来查看测试命名空间中的 pod。
因此，命名空间彼此隐藏，但并不彼此隔离。 一个命名空间中的服务可以很容易地与另一个命名空间中的服务进行通信，这通常非常有用。 能够跨不同命名空间进行通信意味着您的开发人员的服务可以与不同命名空间中的另一个开发团队的服务进行通信。
通常，当您的应用程序想要访问 Kubernetes 服务时，您可以使用内置的 DNS 发现服务，并简单地告诉您的应用程序该服务的名称。 但是，您可以在多个命名空间中以相同的名称创建服务，这是非法的。
幸运的是，使用 DNS 地址的扩展形式可以轻松解决这个问题。 Kubernetes 中的服务使用通用 DNS 模板公开其端点。 它看起来像这样：
通常，您只需要服务名称，DNS 将自动解析完整地址。
但是，如果您需要访问不同命名空间中的服务，只需使用服务名称加上命名空间名称即可：
例如，如果要连接到测试命名空间中的服务数据库，可以使用database.test
如果要连接到 prod 命名空间中的服务数据库，请使用database.prod。
如果您确实想隔离和限制命名空间访问，Kubernetes 允许您借助 Kubernetes 网络策略来实现此目的。 我将在下一个系列中讨论这个问题。
我经常被问到这样的问题：应该创建多少个命名空间以及出于什么目的？ 什么是托管数据？
如果您创建太多名称空间，它们只会妨碍您。 如果它们太少，您将失去这种解决方案的所有优势。 我认为每个公司在创建组织结构的过程中都会经历四个主要阶段。 根据您的项目或公司所处的开发阶段，您可以采用适当的命名空间策略。
想象一下，您是一个正在开发 5-10 个微服务的小团队的一员，您可以轻松地将所有开发人员聚集在一个房间里。 在这种情况下，在默认命名空间中运行所有产品服务是有意义的。 当然，为了进行更多操作，您可以使用 2 个命名空间 - 分别用于 prod 和 dev。 最有可能的是，您正在使用 Minikube 等工具在本地计算机上测试您的开发。
假设情况发生了变化，现在您拥有一个快速增长的团队，同时处理 10 多个微服务。 有时您需要使用多个集群或命名空间，分别用于生产和开发。 您可以将团队分为几个子组，以便每个子组都有自己的微服务，并且每个团队都可以选择自己的命名空间以促进管理软件开发和发布的过程。
随着团队中的每个成员都了解系统作为一个整体是如何工作的，与所有其他开发人员协调每个更改变得越来越困难。 尝试在本地计算机上启动完整的堆栈每天都变得越来越困难。
在大公司中，开发人员根本不知道谁到底在做什么。 团队使用服务合同或使用服务网格技术进行通信，这在网络上添加了一个抽象层，例如 Istio 配置工具。 尝试在本地运行整个堆栈是不可能的。我强烈建议使用持续交付（CD）框架，例如 Kubernetes 中的 Spinnaker。 因此，到了某个时候，每个命令肯定需要自己的命名空间。 每个团队甚至可以为开发环境和生产环境选择多个命名空间。
最后，还有一些大型创业公司，其中一组开发人员甚至不知道其他组的存在。 这样的公司通常可能会雇用第三方开发人员，他们通过记录良好的 API 进行交互。 每个这样的组都有多个团队和多个微服务。 在这种情况下，您必须使用我之前谈到的所有工具。
程序员不应该手动部署服务，也不应该访问与他们无关的命名空间。 现阶段，建议拥有多个集群，以减少配置不良的应用程序的“爆炸半径”，以简化计费流程和资源管理。
因此，组织正确使用命名空间可以使 Kubernetes 更加易于管理、控制、安全和灵活。
一些广告🙂
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com