共计 3023 个字符，预计需要花费 8 分钟才能阅读完成。
原文作者：Owen Garrett of F5
原文链接：在 Kubernetes 中部署利用交付服务（第 2 局部）– NGINX
转载起源：NGINX 官方网站
NGINX 惟一中文官网社区，尽在 nginx.org.cn
本文是以下系列博文中的一篇：
- 在 Kubernetes 中部署利用交付服务（第 1 局部）解释了为什么因分治而重复使用的应用服务反而能够进步整体效率：因为 NetOps 和 DevOps 团队有不同的要求，所以他们会抉择最适宜他们特定需要的工具。
- 在 Kubernetes 中部署利用交付服务（第 2 局部）（本文）以 WAF 为例，就利用交付服务在 Kubernetes 环境中的部署地位提供了领导。您能够依据本人的需要，以基于每个 Service 或基于每个 POD 的形式，将 WAF 部署在 Kubernetes 环境的“前门”或 Ingress Controller 上。
在本系列博文的上一篇，咱们探讨了 DevOps 在管制利用部署、治理和交付形式方面日益增长的影响力。尽管这可能看似会引发与 NetOps 团队的抵触，但企业须要明确的是，每个团队都有不同的职责、指标和运维模式。要想实现专门化并进步运维效率，要害是要谨慎抉择负载平衡和 Web 利用防火墙 (WAF) 等利用交付服务的部署地位，在某些状况下还须要反复部署这些利用交付服务。
在本系列博文的上一篇，咱们探讨了 DevOps 在管制利用部署、治理和交付形式方面日益增长的影响力。尽管这可能看似会引发与 NetOps 团队的抵触，但企业须要明确的是，每个团队都有不同的职责、指标和运维模式。要想实现专门化并进步运维效率，要害是要谨慎抉择负载平衡和 Web 利用防火墙 (WAF) 等利用交付服务的部署地位，在某些状况下还须要反复部署这些利用交付服务。
在确定利用交付服务的部署地位时，需遵循两个次要规范：
- 您心愿部署的服务是 (a) 针对特定利用或业务，还是 (b) 通用于所有利用？
- 服务配置是 (a) 属于 DevOps 或 DevSecOps 治理，还是 (b) 属于 NetOps 或 SecOps 治理？
如果您偏向于 (a)，那么最好将服务部署到凑近须要它的利用左近，并将控制权交给负责这些利用运维的 DevOps 团队。
如果您偏向于 (b)，则最好将服务部署到基础架构的前门，并由负责保障整个平台胜利运维的 NetOps 团队治理。
此外，如果须要折中时，您还须要思考技术上的符合度。想要部署的服务是否能够应用 DevOps 或 NetOps 团队相熟的生态系统工具进行部署和运维？这些相应的工具是否提供必要的性能、配置接口和 API 监控？
Kubernetes 引入了更多抉择
在 Kubernetes 环境中，您能够在以下几个地位部署利用交付服务：
- 前门：内部的负载均衡器或代理
- Ingress Controller：Kubernetes 的进入点
- 基于每个 Service 的代理：外部服务的代理层
- 基于每个 Pod 的代理：针对每个 Pod 的边车型（sidecar）代理
咱们以 Web 利用防火墙 (WAF) 为例。WAF 策略会施行先进的平安防护措施来检查和拦挡歹意流量，但这些策略通常须要针对特定利用进行调整，以最大水平地缩小误报数量。
在前门部署 WAF
当满足以下条件时，请思考在基础架构的前门部署 WAF 设施和相干策略：
- WAF 策略由地方 SecOps 团队创立和治理。
- WAF 设施是由 NetOps 团队管制的专用设备。
- 所有（或大多数）利用必须受同一 WAF 策略的爱护，并且简直不须要针对特定利用进行调整。
- 您心愿可能分明地显示是否合乎安全性和治理策略，并应用繁多控制点拦挡任何可能的入侵或破绽。
在 Ingress Controller 上部署 WAF
当满足以下条件时，请思考在 Ingress Controller 上部署 WAF 利用交付服务：
- WAF 策略由 DevOps 或 DevSecOps 团队领导施行。
- 您心愿在基础架构层集中管理 WAF 策略，而不是将它们委派给各个利用。
- 您大范畴地应用 Kubernetes API 来治理利用的部署和运维操作。
这种办法依然反对地方 SecOps 团队定义 WAF 策略。他们可能以一种能够轻松导入到 Kubernetes 中的形式定义 WAF 策略，而后由负责 Ingress Controller 的 DevOps 团队将 WAF 策略调配给特定的利用。
从 NGINX Plus Ingress Controller 1.8.0 版开始，NGINX App Protect WAF 模块可间接部署在 Ingress Controller 上。所有 WAF 配置都应用 Ingress 资源进行治理，并通过 Kubernetes API 进行配置。
基于每个 Service 部署 WAF
您还能够将 WAF 部署为 Kubernetes 外部的代理层，放在须要 WAF 防护的一个或多个特定 Service 的后面。显然，这种办法要求 WAF 必须是以软件模式存在以便可能轻松、高效地部署在容器内。
当满足以下条件时，请思考按服务将 WAF 部署为代理：
- WAF 策略由 DevSecOps 团队领导施行，并只针对少数几项服务。
- 策略更新可通过适合的容器感知 API 治理，也可通过更新 WAF 代理的 Deployment 来实现。
- WAF 设施在 Kubernetes 环境中失常运行。
例如，带有 App Protect 的 NGINX Plus 就能够通过这种形式轻松实现部署。您能够采取以下操作，使 Deployment 对受其爱护的服务和调用它们的客户端都不可见：
- 将须要爱护的服务名称从（例如）WEB-SVC 重命名为 WEB-SVC-INTERNAL
- 将 WAF 代理部署到一个名为 WEB-SVC 的新 Kubernetes 服务中
- 将 WAF 代理配置为转发申请至 WEB-SVC-INTERNAL
- 此步骤为可选步骤：应用 Kubernetes 网络策略强制规定只有 WAF 代理能够与 WEB-SVC-INTERNAL 通信
基于每个 Pod 部署 WAF
最初，您还能够在 Pod 中部署 WAF，作为 Pod 中运行的利用的入向代理。在这种状况下，WAF 就成为了利用的一部分。
当满足以下条件时，请思考以这种形式部署 WAF：
- WAF 策略只针对特定的利用。
- 您心愿将策略和利用严密绑定在一起，以便在开发流水线的所有节点上都应用该 WAF 策略部署利用。
- 您可能常常须要把利用频繁地重新部署到不同的集群中，但又不想为每个集群增加 WAF 服务和适合的配置。
如果您领有须要特定安全策略的传统利用，并且您心愿将该利用打包成容器以使其更容易部署和扩大，那么此办法再适合不过了。
对于 Service Mesh 的阐明
基于每个 Pod 代理的模式与 Istio、Aspen Mesh、Linkerd、NGINX Mesh 等服务网格推广的边车型（sidecar）代理并不相同：
企业通常很少应用 WAF 检查和爱护东西向流量，并且目前还没有服务网格可能反对您在所选的 sidecar 代理中轻松地配置残缺的 WAF。Ingress Controller 提供了弱小的平安防护边界，针对不受信赖的内部客户端，它是为入向流量（南北向流量）提供爱护的最无效地位。
结语
当初，您在 WAF 等利用交付服务的部署地位方面领有了更多抉择，这意味着您将有更多的机会将 Kubernetes 平台的经营效率最大化。
更多资源
NGINX 惟一中文官网社区，尽在 nginx.org.cn
更多 NGINX 相干的技术干货、互动问答、系列课程、流动资源：
开源社区官网：https://www.nginx.org.cn/
微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg