服务网格是一项热门技术，有时甚至被吹捧为微服务成功的必要条件。然而，与许多抽象一样，服务网格节省时间，而不是学习时间。事实上，许多小型平台团队对服务网格增加的复杂性感到不知所措，尤其是在涉及长时间运行的操作时。很自然地会问一个问题：额外的复杂性是否真的超过了好处？在这篇文章中，我们提出了在投资服务网格之前要考虑的替代方案。服务网格最流行的好处是：身份验证；入口加密；集群内网络加密；通讯隔离。对于这些好处中的每一个，我们都会根据我们的经验提出更接近管理员已经熟悉的替代方案。这些对于缺乏专业知识或平台工程带宽的组织可能更具吸引力。在某些情况下，您将需要一个服务网格，例如当您需要跨多个Kubernetes集群进行安全的Pod到Pod通信时。通过排除不满足您需求的解决方案，您将进一步说服自己为什么选择服务网格作为开始。服务网格优势1-使用OAuth2-proxy进行身份验证许多应用程序团队需要在他们的微服务前面添加一个身份验证层。例如，完全实现OAuth2或OpenID涉及相当多的跳跃。与其编写大量样板代码（与非特定应用程序和非业务差异化相比），团队更希望“某事”只是将具有正确声明的JWT令牌交给他们的应用程序，以便专注于特定应用程序程序访问控制。我们之前在博客中介绍了如何将Istio与OAuth2-proxy集成以实现这一目标。但是，如果这是您需要从Istio获得的唯一东西，那么它可能有点矫枉过正。服务网格的替代方案：NginxIngressController让我来说明一下我认为更简单的解决方案，尤其是对于已经在使用Nginx的团队。如果您只需要一些好的oauth2-proxy，NginxIngressController很容易与之集成。只需使用auth-url注释，控制器将完成剩下的工作。下图说明了这是如何工作的。我认为这个解决方案更简单的原因是它只影响流量进入Kubernetes集群的方式。Pod到Pod的通信像以前一样工作。如果您熟悉Nginx，但害怕IngressController在其周围添加的自动化，您可以通过键入以下命令直接检查Nginx的配置方式：kubectlexec-ti\-ningress-nginx\$(kubectlgetpod\-ningress-nginx\-lapp.kubernetes.io/component=controller\-oname\|head-1\)\--\cat/etc/nginx/nginx.conf默认情况下，你的应用程序不会获得JWT令牌卡.为了确保您的应用程序获得细粒度的访问控制声明，您必须做两件事：首先，将--set-authorization-header命令行选项添加到oauth2-proxy：这确保oauth2-proxy生成HTTP授权标头头。其次，将以下注释添加到您的Ingress：nginx.ingress.kubernetes.io/auth-response-headers:“authorization”。这确保Nginx入口控制器将HTTP授权标头从oauth2-proxy转发到您的应用程序。如果您需要更多详细信息，可以在此处找到现成的代码片段。https://github.com/elastisys/compliantkubernetes/blob/main/user-demo/deploy/oauth2-proxy.yamlhttps://elastisys.io/compliantkubernetes/user-guide/network-model/#ingress服务网格优势二：入口加密许多法规要求对不受信任网络上的网络流量进行加密。例如，PCI-DSS要求4指出：“持卡人数据的传输在开放的公共网络上进行加密。”GDPR和瑞典医疗保健（“Behandlingavpersonuppgifteri?ppnan?t”“通过开放网络处理个人数据”）包含类似的法规。解决方案很简单：添加TLS终止。但是，TLS终止不是业务差异化因素，也不是特定于应用程序的。理想情况下，平台应该“做”。我经常看到团队只是为了这个功能而采用服务网格，但还有一个更简单的选择。服务网格的替代方案：Cert-manager您可以安装cert-manager，创建ClusterIssuer并通过注释使用该ClusterIssuer配置Ingress。Cert-manager将发挥其与LetsEncrypt对话的魔力，提供TLS证书并在其过期前轮换。上图和相同的现成代码片段对此进行了说明。请参阅cert-manager.io/cluster-issuer说明。ServiceMesh优势三：集群内网络加密，为一些纠纷做准备。我经常看到组织添加服务网格，因为mTLS和Pod-to-Pod加密很酷，并且某些法规可能需要这样做。这是我对这个话题的看法。首先，您很少（如果有的话）需要Pod到Pod加密。如上所述，PCI-DSS和SwedishHealthcare都只需要对开放（即不可信）网络进行加密。我经常听到团队争论Pod到Pod加密，“以防万一”底层网络不受信任。如果您不能信任您的基础架构提供商，请更换提供商。当数据在内存中未加密时，再多的加密也无法阻止他们访问您的数据。其次，假设您确实需要集群内加密。例如，您希望将Kubernetes集群扩展到通过不受信任的网络连接的两个数据中心。或者您可能希望避免与您的两个数据中心之间的网络提供商签署另一个GDPR样式的数据保护协议(DPA)。服务网格的替代方案：CNI级加密在这种情况下，只需在您的容器网络接口(CNI)提供程序中启用WireGuard或IPsec。这样就达到了加密网络流量Node-to-Node的效果。至少Calico和Flannel对此有支持。例如，如果您使用Kubespray设置Calico，只需添加：calico_wireguard_enabled:trueServiceMesh优势四：网络通信的隔离服务网格带来另一个特性：它们为每个Pod提供一个身份，然后通过相互身份验证(mTLS)进行身份验证实现基于身份的访问控制。这带来了两个好处：首先，您的pod“不与陌生人交谈”，这有助于使某些漏洞更难被利用，例如臭名昭??著的Log4Shell。其次，它减少了爆炸半径：如果Pod被破坏，攻击者将发现很难横向移动。服务网格的替代方案：NetworkPolicies但同样的好处可以通过使用NetworkPolicies以更简单和更标准化的方式实现。它们就像容器化世界中的防火墙规则或安全组。由于Pod每次部署时都会更改IP地址，NetworkPolicies实质上将Pod身份转换为基于IP的防火墙规则，由Linux内核强制执行。NetworkPolicy由两部分组成：选择器和规则。选择器选择NetworkPolicy应用于哪些Pod，匹配Pod标签或命名空间标签。规则指定允许进出选定Pod的入口和出口流量。可以设置安全措施以确保每个Pod都由NetworkPolicy选择。在某些组织中，网络安全和应用程序安全由不同的团队负责。这可以通过NetworkPolicies和KubernetesRBAC在技术上强制执行。只有网络团队被授予编辑NetworkPolicies的权限，而应用程序团队仅被授予在选定命名空间中部署的权限。最后一条建议：将名称空间视为“内部API”。由于命名空间最终成为集群内DNS名称的一部分，因此最好通过它提供的服务（例如“auth”、“database”、“licensing”）而不是团队名称（“team-green”）来命名命名空间”、“黄队”等）。这种做法还简化了网络安全团队设置NetworkPolicies的过程。结论简单易懂是安全的关键。虽然安全网格带来了巨大的好处，但在采用它们之前请考虑更简单的替代方案。我的经验是网络和网络安全已经足够复杂了。添加另一层可能会使您的平台团队不堪重负，并给他们带来“待命焦虑”。当然，有许多伟大的服务网格功能缺乏更简单的替代方案，例如多集群安全通信和联合网络可观察性。如果您确实需要更高级的功能，我们希望这篇博文能帮助您做出明智的决定并接受新技术。Kubernetes网络和服务网格都在快速发展。就在最近几个月，Calico添加了一个eBPF数据平面，Istio被捐赠给了CNCF。此类事件可以帮助决策者决定是否赞成采用服务网格。
