我正在编写要在Kubernetes上部署的服务。客户将是其他服务，而不是人员，这些服务可能位于其他命名空间甚至群集中。我的目标是：
我知道Kubernetes并没有提供真正对这些服务有帮助的服务，因此我需要在服务中构建一些明确的内容。我想了解当前的最佳实践，以及如何最大程度地利用Kubernetes或生态系统中的可用资源，以实现这些目标，同时最大程度地减少编码和管理负担。我考虑过的一些选择：
自定义用户名/共享密钥。我可以将共享机密传递给所有调用服务，然后编写自己的自定义代码以验证共享机密是否匹配。我认为将这些作为令牌传递是正确的举动。使用Kubernetes服务帐户和角色对象是否是这些共享机密的合理容器？如果是这样，是否有可以使查找，关联和策略工作更轻松的库？
JWT 。 JWT似乎更倾向于传递声明（如最终用户身份），并且似乎要求所有参与组件共享相同的JWT机密。由于我不希望calling-service-foo能够通过calling-service-bar进行身份验证，因此尚不清楚JWT是正确的选择。有想法吗？
mTLS 。我可以为所有参与的服务颁发TLS证书。我可以使用哪些组件来自动颁发这些证书？我应该尝试使用Kubernetes服务帐户或角色对象来管理这些帐户，还是应该滚动自己的CRD？
Istio 。看起来Istio可以透明地完成很多工作，但是到目前为止，我发现解释该问题的所有资源似乎都假定透明是目标。但是，由于我将需要呼叫服务的身份，是否有可能使它脱离Istio？如果我的呼叫者不在我的集群中，可以这样做吗？
SPIRE（spiffe.io）。看起来它与我的用例非常匹配，但它似乎是新的，而且我不知道人们有多少经验。
这些选项中的任何一个（请更正我对它们中的任何一个）是否能作为最佳实践脱颖而出，还是我应该考虑的其他选择？
谢谢！
答案 0 :(得分：0)
您需要的是一个充当微服务API端点网关的组件。这种组件属于一种称为“ API管理”（Wikipedia page）的软件类别，其使用不仅限于Kubernetes。
API管理软件有很多选择，例如Wikipedia页面中列出的，但是我的项目使用Gravitee，到目前为止，由于其简单的管理UI，我们很喜欢它。随时在https://gravitee.io/上进行探索。
除了是其中一位用户之外，我与Gravitee.io没有任何关系（尽管我确实为一个PR做出了贡献）
答案 1 :(得分：0)
我知道我现在迟到了，但如果其他人正在寻找： Istio 已经包含多集群支持，它使通信变得轻松。