使用发现选择器配置 Istio 服务网格的命名空间
了解如何使用发现选择器以及它们如何与 Sidecar 资源相交。
当用户将他们的服务迁移到 Istio 服务网格中运行时,他们通常会惊讶于控制平面默认情况下会监控并处理集群中所有命名空间的所有 Kubernetes 资源。对于具有大量命名空间和部署的超大型集群,甚至对于具有快速变化资源的中等规模集群(例如,Spark 作业),这可能是一个问题。
无论是在社区中还是针对我们Solo.io的大型客户,我们都需要一种方法来动态限制作为网格一部分的命名空间集,以便 Istio 控制平面仅处理这些命名空间中的资源。限制命名空间的能力使 Istiod 能够监控和推送更少的资源以及相关的更改到 Sidecar,从而提高控制平面和数据平面的整体性能。
背景
默认情况下,Istio 会监控集群中的所有命名空间、服务、端点和 Pod。例如,在我的 Kubernetes 集群中,我在默认命名空间中部署了 sleep 服务,在 ns-x 命名空间中部署了 httpbin 服务。我已经将 sleep 服务添加到了网格,但我没有计划将 httpbin 服务添加到网格,或者让网格中的任何服务与 httpbin 服务进行交互。
使用 istioctl proxy-config endpoint 命令显示 sleep 部署的所有端点
请注意,ns-x 命名空间中的 httpbin 服务端点位于发现的端点列表中。当您只有少量服务时,这可能不是问题。但是,当您有数百个服务不与 Istio 服务网格中运行的任何服务进行交互时,您可能不希望 Istio 控制平面监控这些服务并将它们的信息发送到网格中服务 Sidecar。
介绍发现选择器
从 Istio 1.10 开始,我们向MeshConfig引入新的 discoverySelectors 选项,它是一个 Kubernetes选择器数组。确切的类型是 []LabelSelector,如此处定义,允许简单选择器和基于集合的选择器。这些选择器适用于命名空间的标签。
您可以配置每个标签选择器以表达各种用例,包括但不限于
- 任意标签名称/值,例如,所有带有标签
istio-discovery=enabled的命名空间 - 使用基于集合的选择器列出命名空间标签,这些选择器带有 OR 语义,例如,所有带有标签
istio-discovery=enabled或region=us-east1的命名空间 - 包含和/或排除命名空间,例如,所有带有标签 istio-discovery=enabled 和标签键
app等于helloworld的命名空间
注意:discoverySelectors 不是安全边界。即使您已配置 discoverySelectors,Istiod 仍然可以访问所有命名空间。
发现选择器实战
假设您知道哪些命名空间应作为服务网格的一部分,作为网格管理员,您可以在安装时或安装后配置 discoverySelectors,方法是将您需要的发现选择器添加到 Istio 的 MeshConfig 资源。例如,您可以配置 Istio 仅发现具有标签 istio-discovery=enabled 的命名空间。
使用我们之前的示例,让我们用标签
istio-discovery=enabled为default命名空间添加标签。$ kubectl label namespace default istio-discovery=enabled使用
istioctl将包含discoverySelectors的 yaml 应用于您的 Istio 安装。注意,为了避免对稳定环境产生任何影响,我们建议您使用不同的修订版本进行 Istio 安装$ istioctl install --skip-confirmation -f - <<EOF apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system spec: # You may override parts of meshconfig by uncommenting the following lines. meshConfig: discoverySelectors: - matchLabels: istio-discovery: enabled EOF显示
sleep部署的端点配置使用发现选择器的 Sleep 部署的端点 请注意,这次
ns-x命名空间中的httpbin服务不在发现的端点列表中,其他不在默认命名空间中的许多服务也不在列表中。如果您显示sleep部署的路由(或集群或监听器)信息,您也会注意到返回的配置要少得多使用发现选择器的 Sleep 部署的路由
您可以使用 matchLabels 使用 AND 语义配置多个标签,或者使用 matchLabels 集使用 OR 语义配置多个标签。无论您是将服务或 Pod 部署到具有不同标签集的命名空间,还是您的组织中的多个应用程序团队使用不同的标签约定,discoverySelectors 都能提供您所需的灵活性。此外,您可以根据我们的文档,将 matchLabels 和 matchExpressions 结合使用。有关选择器语义的更多详细信息,请参阅Kubernetes 选择器文档。
发现选择器与 Sidecar 资源
discoverySelectors 配置使用户能够动态限制作为网格一部分的命名空间集。Sidecar 资源还控制 Sidecar 配置的可见性以及推送至 Sidecar 代理的内容。它们之间有什么区别?
discoverySelectors配置声明 Istio 控制平面监控和处理的内容。如果没有discoverySelectors配置,Istio 控制平面会监控和处理集群中的所有命名空间/服务/端点/Pod,而与您拥有的 Sidecar 资源无关。discoverySelectors由网格管理员在全局范围内为网格配置。虽然 Sidecar 资源也可以由网格管理员在 MeshConfig 根命名空间中为网格全局配置,但它们通常由服务所有者为其命名空间配置。
您可以将 discoverySelectors 与 Sidecar 资源一起使用。您可以使用 discoverySelectors 在网格级别配置 Istio 控制平面应监控和处理哪些命名空间。对于 Istio 服务网格中的这些命名空间,您可以在全局范围内或每个命名空间创建 Sidecar 资源,以进一步控制推送至 Sidecar 代理的内容。让我们将 Bookinfo 服务添加到网格中的 ns-y 命名空间,如以下图表所示。discoverySelectors 使我们能够定义 default 和 ns-y 命名空间是网格的一部分。我们如何配置 sleep 服务以使其仅看到 default 命名空间以外的内容?通过为默认命名空间添加 Sidecar 资源,我们可以有效地配置 sleep Sidecar,使其仅具有对与其当前命名空间关联的集群/路由/监听器/端点以及任何其他必需命名空间的可见性。
总结
发现选择器是强大的配置,可以调整 Istio 控制平面,使其仅监控和处理特定命名空间。如果您不希望 Kubernetes 集群中的所有命名空间都是服务网格的一部分,或者您的 Kubernetes 集群中有多个 Istio 服务网格,我们强烈建议您探索此配置,并与我们联系以获取有关Istio Slack 或 GitHub 上的反馈。



