关于service-mesh:译别用大炮打蚊子ServiceMesh的替代方案
译者序转移，用 专人专事** 来应答复杂度，以晋升效率 在做技术选型的时候，简略性 （管制复杂度）也是咱们的一个重要考量，不能因为要解决一个问题而引入了更多问题最近看到一篇文章，笔者深认为然：复杂度只能无限隐没和转移，不可能齐全（甚至是大部分）隐没，所以咱们做软件架构往往谋求的是 **注释服务网格是一项热门技术，有时甚至被吹捧为微服务胜利的必要条件。然而，像许多形象一样，服务网格能够节俭施行工夫，但不能节俭学习工夫。事实上，许多小平台团队都因为服务网格所减少的复杂性而感到不堪重负，尤其是在部署实现后的运维工作中。 天然地，人们会问：额定的复杂性是否真的超过了收益? 在这篇文章中，咱们提出了一些在采纳服务网格之前值得思考的代替计划。 服务网格最受欢迎的劣势有: 认证;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 转发到你的应用程序。 ...