为什么 Istio 要求 Pod 至少属于 Kubernetes 中的一个 Service？答案

【问题标题】：Why does Istio require Pods belong to at least one Service in Kubernetes?为什么 Istio 要求 Pod 至少属于 Kubernetes 中的一个 Service？
【发布时间】：2020-01-10 21:29:29
【问题描述】：

Istio 的部署要求规定 Pod must belong to at least one Kubernetes Service 以构成 Istio 网格的一部分。据我了解，造成这种情况的原因之一是在配置规则（例如<serviceName>.<namespace>.svc.cluster.local）中创建一个条目来引用 Pod（或 Pod 组）。

还有其他原因吗？

【问题讨论】：

标签： kubernetes istio

【解决方案1】：

Istio 的许多功能（策略实施、分布式跟踪、跨服务指标）依赖于了解请求来自什么服务。通常你只需要创建 Kubernetes 服务来将入站请求路由到特定的 Pod，但 Istio 更普遍地使用它们来将 Pod 与抽象的“服务”相关联。

假设 pod A 正在调用 pod B。即使在普通的 Kubernetes 中，您也需要为 B 提供服务，并且来自 A 的请求将针对该服务而不是直接针对该 pod。例如，如果您在 Istio 中设置了 metrics（可能使用其内置的 Prometheus），那么 Istio 还会尝试为 A 查找服务。如果找到了，您将看到像 istio_requests_total(source_service="A", destination_service="B") 这样的指标。如果不是，则来源只会显示为“未知”。

【讨论】：

那么你是说 Istio 只使用服务来命名服务？（当我说它用于创建一个引用 Pod 组的条目时，这就是我所指的）并且没有使用 Kubernetes 中的正常用例（即将请求路由到 Pod）？
这两个用例都很重要。
好吧，“服务”的概念随着时间的推移而发生了变化，现在他们更多地指的是发出请求的东西的“工作负载”，服务现在更接近于 kubernetes 中的内容。在指标中，source_service 不再存在，它是source_workload，指的是部署/副本，而不是服务。但是，Istio 仍然需要假设 Pod 前面有服务，否则某些功能将无法工作（例如 groups.google.com/forum/#!topic/istio-users/8MEXiwGfhqw 或 github.com/istio/istio/issues/7787 ）
Kubernetes 中服务（大写字母 S）的概念并没有改变，但这正是我想问的——我想澄清一下“重要”是什么意思，Istio 是如何使用它们的让它们变得重要吗？