译者序
转移 ，用 专人专事 ** 来应答复杂度，以晋升效率
- 在做技术选型的时候，简略性（管制复杂度）也是咱们的一个重要考量，不能因为要解决一个问题而引入了更多问题最近看到一篇文章，笔者深认为然：
- 复杂度只能无限隐没和转移，不可能齐全（甚至是大部分）隐没，所以咱们做软件架构往往谋求的是 **
注释
服务网格是一项热门技术，有时甚至被吹捧为微服务胜利的必要条件。然而，像许多形象一样，服务网格能够节俭施行工夫，但不能节俭学习工夫。事实上，许多小平台团队都因为服务网格所减少的复杂性而感到不堪重负，尤其是在部署实现后的运维工作中。
天然地，人们会问：额定的复杂性是否真的超过了收益?
在这篇文章中，咱们提出了一些在采纳服务网格之前值得思考的代替计划。
服务网格最受欢迎的劣势有:
- 认证;
- Ingress 加密;
- 集群内网络加密;
- 通信隔离。
对于每一个劣势，咱们都将展现相应的代替计划。在咱们的教训中，这些计划更靠近系统管理员曾经相熟的计划。对于不足专业知识或平台工程的团队来说，这些计划可能更具吸引力。
在某些状况下，你会须要服务网格，例如，当你须要让多个 kubernetes 集群之间的 Pod 到 Pod 的通信更加平安巩固之时。通过排除不满足你需要的解决方案，你将进一步压服本人为什么一开始会抉择服务网格。
劣势 1：应用 OAuth2 代理进行认证
许多利用团队须要在其微服务后面增加一个认证层。举个例子，齐全实现 OAuth2 或 OpenID 波及许多简单的工作，利用团队更心愿“某些组件”间接向其应用程序提供具备正确申明的 JWT token，以便他们能专一于利用特定的访问控制，而不是编写许多通用的、非业务差异化的样板代码。
咱们以前在博客中介绍了如何将 Istio 与 OAuth2 代理集成来达到这个目标。然而，如果这是你想通过 Istio 实现的惟一目标，那么采纳它则有点过犹不及。
代替计划：Nginx Ingress Controller
这是一个我认为更简略的解决方案，特地是对曾经习惯于 Nginx 的团队来说。如果你仅仅须要传统的 oauth2 代理，Nginx Ingress Controller 曾经可能和它进行集成了。你只需应用 auth-url 注解，Controller 会实现其余的工作。下图阐明了此计划的原理：
我认为这个解决方案更简略的起因是，它实际上只影响流量如何进入你的 Kubernetes 集群。Pod 到 Pod 的通信工作形式与以前雷同。
作为额定的益处，如果你相熟 Nginx 然而放心 Ingress Controller 带来的自动化（译注：你放心配置文件不可控），你能够间接查看 Nginx 是如何配置的，输出下方命令即可:
kubectl exec -ti \
-n ingress-nginx \
$(kubectl get pod \
-n ingress-nginx \
-l app.kubernetes.io/component=controller \
-o name \
| head -1 \
) \
-- \
cat /etc/nginx/nginx.conf默认状况下，你的应用程序不能取得 JWT token。要确保你的应用程序获取细粒度的访问控制所需的申明，你必须做到两点:
• 给 Oauth2 代理增加 --set-authorization-header 命令行选项：这能够确保 Oauth2 代理生成 HTTP 认证 header。
• 给你的 Ingress 增加以下注解: nginx.ingress.kubernetes.io/auth-response-headers:“authorization”。这确保了 Nginx Ingress Controller 会将 Oauth2 代理增加的 HTTP A 认证 header 转发到你的应用程序。
更多细节和开箱即用的代码片段：
- https://github.com/elastisys/compliantkubernetes/blob/main/user-demo/deploy/oauth2-proxy.yaml
- https://elastisys.io/compliantkubernetes/user-guide/network-m…
劣势 2：Ingress 加密
许多法规要求对不可信网络上的网络流量进行加密。例如，PCI-DSS 条例 4 规定:“通过加密将持卡人数据传输到凋谢的公共网络中。”GDPR 和瑞典医疗保健法蕴含相似的规定。
解决方案很简略：增加 TLS 终结。然而，TLS 终结并不具备业务差异性和利用相关性。现实状况下，平台应该“主动实现它”。我常常看到团队仅为此一项性能而采纳服务网格，但实际上有一个更简略的代替计划。
代替计划：证书管理器
你能够装置 cert-manager，创立 ClusterIssuer，并通过注解将你的 Ingress 与该 ClusterIssuer 关联。证书管理器会和 LetsEncrypt 沟通并提供 TLS 证书，并在证书过期前轮转。
上图对此进行了阐明，以及开箱即用的代码片段[https://elastisys.io/compliantkubernetes/user-guide/network-m…]。请参阅 cert-manager.io/cluster-issuer 注解。
劣势 3：集群内网络加密
筹备好面对一些争议。
我常常看见企业采纳服务网格，仅仅是因为“mTLS 和 Pod 到 Pod 的加密很酷，并且由某些法规要求”。上面是我对这个话题的认识。
首先，你很少 (如果有的话) 须要 Pod 到 Pod 的加密。如上所述，PCI-DSS 和瑞典医疗保健法只要求在凋谢 (即不可信) 网络上加密。我常常据说团队采纳 Pod 到 Pod 加密来“以防万一”底层网络不可信。如果你无奈信赖你的基础设施提供商，请更换提供商。因为再多的加密都无奈阻止他们窃取你内存中未加密的数据。
其次，假如你真的须要集群内加密。例如，你想要在 2 个通过不可信网络连接的数据中心中搭建 Kubernetes 集群。或者，你想防止与两个数据中心之间的网络提供商签订另一份相似 GDPR 的数据保护协定(DPA)。
代替计划：CNI 级别加密
在这种状况下，只需在你的容器网络接口 (CNI) 提供商中启用 WireGuard 和 / 或 IPsec。这能够实现节点（node 而非 pod）到节点的网络流量加密的成果。至多 Calico 和 Flannel 反对此性能。例如，如果你应用 Kubespray 来配置 Calico，配置形式非常简单:
calico_wireguard_enabled: true
劣势 4：网络通信隔离
服务网格带来另一个性能：它为每个 Pod 提供一个身份（identity），而后通过互相认证 (mTLS) 来实现基于身份的访问控制。这带来了两个益处：
- 首先，你的 Pod“不与陌生人交谈”，这能够让某些破绽更难利用，如臭名远扬的 Log4Shell
- 其次，它减小了爆炸半径：如果一个 Pod 被攻破, 攻击者会发现横向挪动更加艰难（译注：也就是很难从一个 pod 攻破另一个 pod）。
代替计划：网络策略
然而，应用网络策略能够以更简略和更标准化的形式达到雷同的目标。它们就像容器化世界中的防火墙规定或平安组。实质上，随着 Pod 在每次部署后更改 IP 地址，网络策略将 Pod 标识转换为基于 IP 的防火墙规定，由 Linux 内核强制执行。
一个网络策略由两局部组成：selector 和 rules。selector 选择网络策略利用于哪些 Pod，能够匹配 Pod 标签或命名空间标签。rules 指定哪些到 / 从所选 Pod 的入口和进口流量是被容许的。Safeguards 能够用来确保每个 Pod 都能被某个网络策略抉择到。
在一些组织中，网络安全性和利用安全性是不同团队的责任。这能够通过网络策略和 Kubernetes RBAC 来实现技术上的实现。只有网络团队被受权编辑网络策略，而利用团队只被受权在给定的命名空间中部署。
最初的倡议：将命名空间视为“外部 API”。因为命名空间最终成为集群 DNS 名称的一部分，所以最好依据它提供的服务 (例如“auth”、“database”、“licensing”) 而不是团队名称 (“team-green”、“team-yellow”等) 来给命名空间取名字。这种做法也简化了网络安全团队设置网络策略的过程。
论断
简略性和可了解性是安全性的要害。只管服务网格带来很大的益处，但在采纳它们之前应思考更简略的代替计划。我的教训是，网络和网络安全自身曾经足够简单。增加额定的一层会带来肯定的危险：让你的平台团队不堪重负，还会给他们带来 on-call 的焦虑。
当然，有许多服务网格性能目前还没有更简略的代替计划，例如跨集群的平安通信，联邦网络的可察看性。如果你的确须要更高级的性能，咱们心愿本文可能帮忙你作出理智的决定和拥抱新增的技术。
Kubernetes 网络和服务网格都在疾速倒退。就在最近几个月，Calico 减少了一个 eBPF 数据立体，Istio 被捐献给 CNCF。这样的事件能够很快推动采纳或不采纳服务网格的决策。咱们当然会察看最新状况，并持续书写对于 Kubernetes 网络的文章。
原文
Alternatives to Consider Before Investing in Service Meshes：https://elastisys.com/dont-use-a-canon-to-shoot-a-mosquito-al…