根据持续开发入口负载平衡解决方案。
版本1.8.0充分展示了我们提供灵活，功能强大且容易 - 使用Ingress Controller的承诺。IngressController可以使用Kubernetes Ingress Resources和Nginx Ingress资源进行配置：
?Kubernetes入口资源与不同的入口控制器实现完全兼容，并且可以使用注释和自定义模板来扩展以生成复杂的配置。
?NGINX入口资源提供NGINX特定配置模式，比定制的Kubernetes Ingress资源更丰富，更安全。
基于版本1.7.0，版本1.8.0的主要增强和改进包括：
?Integrated NGINX应用程序保护-NGINX APP Protect是领先的NGINX应用程序安全解决方案，可以为Web应用程序提供 - 深度签名和结构化保护。
?NGINX INGRESS资源的可扩展性 - 对于想要使用nginx和virtualServerRoute资源的用户使用NGINXX功能，这些功能想要使用Nginx Ingress资源，但需要自定义VirtualServer和VirtualServerRoute中的NGINX特征中的NGINX特征中的两种互补机制：配置Sneclippets：配置SNENPIPPETS：和自定义模板。
?URI重写和修改请求以及响应标头 - 这些功能可以支持您的罚款（添加，删除和忽略）请求和响应标头传递给上游并返回客户端。
?策略和IP地址访问控制列表 - 通过摘要策略和流量管理功能到独立的K8S对象中，不同的团队可以定义和部署多个位置。ACCESSCONTROL列表（ACL）可用于过滤通过NGINX Ingress Controller流动的网络流量。
?其他新功能 -
Kubernetes的Nginx Ingress Controller是一个具有NGINX开放源代码或NGINX加上Kubernetes环境中的实例的监护人过程。监护人过程负责监视Kubernetes Ingress Invers Resources和NginX Invress Resources以识别和部署Ingress的服务。在此请求中找到了这样的请求。，它将自动配置nginx或nginx Plus，以将流量路由转向这些服务并执行负载余额。
已经启动了各种NGINX入口控制器。官方Nginx实现高性能，可以随时投入生产，适合长期部署特征。我们旨在为每个版本和丰富功能提供出色的稳定性可以在整个企业中部署。我们免费为Nginx Plus用户提供全部支持，并致力于为NGINX开源用户提供出色的稳定性和支持。
集成的NGINX应用程序保护
随着越来越多的公司尽最大努力加速数字转型，对应用程序的攻击正在增加。每天进行更复杂的新漏洞。可以快速有效地减轻恶意攻击。
NGINX Ingress Controller版本1.8.0嵌入了Nginx App Protect中，该版本可以支持您熟悉的Kubernetes API Management App保护安全策略和配置。
该集成解决方案具有三个独特的优势：
?保护应用程序边界 - 在建筑师设计，不合理的Kubernetes部署中，入口控制器是数据平面流中Kubernetes所有操作服务的唯一入口处，这使其成为部署安全代理的理想位置。
?集成数据平面 - 将WAF置于入口控制器中，以消除对独立WAF设备的需求。这可以减少复杂性，成本和故障点的数量。
?使用Kubernetes API的集成控制平面 - 管理WAF配置更轻松地实现CI/CD进程的自动化。NginxIngress Controller配置Kubernetes的基于角色的访问控制（RBAC），因此WAF配置可以安全地分配特殊DEV Seepsecopss。
如果您想了解详细的概述，请使用NGINX App Protect检查相关博客的应用程序，以保护Kubernetes中的应用程序。如果您想了解如何配置和失败NGINX App Protect在Nginx Ingress Controller中，请检查Ingress Controller文档。如果您想了解有关其他应用程序保护的信息，请检查Nginx App Protect文档。
您必须同时订阅NGINX PLUS和NGINX APP保护服务，以在Nginx Ingress Controller Images中构建App Protect。
使用片段和自定义模板扩展Nginx Ingress Resources
在上一个版本中，您可以使用摘要和自定义模板将NGINX配置插入标准的Kubernetes Ingress Resources.SNIPPETS支持您在NGINX的大多数配置中部署NGINX以本机配置的形式进行。其他配置块（例如默认服务器）并将其应用于ConfigMaps.Version 1.8.0将摘要和自定义模板的使用扩展到Nginx Ingress Resources，VirtualServer和VirtualServerRoute。
摘要和自定义模板支持管理员是尚未发布的标准Kubernetes入口资源或NGINX INGRESS资源。尤其重要的情况是，何时nnginx of nginx代理Kubernetes的非kubernetes应用程序，借助snippets和snippets和自定义模板，您可以继续使用尚未在NGINX入口资源中发布的NGINX特性，例如高速缓存和速度限制。
此示例配置显示了如何通过在不同的NGINX配置上下文中使用不同的设置来配置高速缓存和速率限制：不同的设置：
仔细检查片段和自定义模板非常重要，因为无效的摘要或模板将防止NGINX重新加载其配置。尽管在这种情况下，流量处理不会中断（NGINX继续在现有的有效配置下运行），您也可以使用）提高稳定性的其他机制：
?全局设置/禁用摘要设置。
?通常只有管理员可以应用ConfigMap，这是配置自定义模板的唯一机制。
URI重写和修改请求和响应标头
版本1.8.0添加了上游和下游连接中URI重写和修改的请求和响应标头的特征。本质上，最终用户和后端服务器是通过添加过滤和修改层解耦的。此功能直接在VirtualServer和VirtualServerRoute资源中，并可以为特定路径进行配置。
URI重写和修改请求和响应头的特征可以支持您快速解决生产环境中无法预测的可靠性问题，而无需返回 - 端 - 端开发人员消除故障或重写代码。此反过来又提高了可用性，安全性和安全性，安全性和弹性Kubernetes的应用程序。
典型用例包括：
?URI重写-Administrator可能需要在未找到非应用代码的路径上发布应用程序。例如，您可以向外设置应用程序，并将请求重新定义为正在侦听的root（ /）URI通过Ingress控制器到后端的应用程序。
?高速缓存 - 应用开发人员不能总是正确设置高速缓存标头，也不能完全没有高速缓存标头。Administrator可以使用标头修改来修复已部署的应用程序。
您可以通过代理操作将请求传递到上游，以便在VirtualServer或VirtualServerRoute的配置中配置标题修改和URI重写。
在此示例配置中，当入口控制器代理 /茶路径的客户端请求时，它将在将请求转发到上游之前修改请求（content-type）请求头。在Retapath字段中指定的URI。在将服务器响应转回客户端之前，Ingress Controller添加了一个新的访问控制 - 允许 - 柔蛋白标头字段，并将HIDE，忽略和传达其他几个标头字段。
此示例配置说明了如何在条件匹配过程中重写动作块中的标头操作和URI，以实现更复杂的流量处理：
策略和IP地址访问控制列表
大多数组织都是与多个团队合作的。
考虑到每个组织约会的方式都不同，NGINX Intress支持您以最大的灵活性来定义每个团队责任的特定配置部分，并最终集成和执行。在很大程度上。
为了支持多租用家庭，NGINX Ingress Controller 1.8.0介绍了策略策略。第一个支持策略类型是：基于IP地址的访问控制列表（ACL）。
?通过将策略和流量管理功能抽象为独立的K8S对象，不同的团队可以定义和部署多个位置。该方法用于配置Nginx Ingress Controller，这更简单，更自然，并带来许多优势：类型安全，类型安全，预约，多租户，包装和简化配置，重用和可靠性。
?使用基于ACL的ACL，您可以过滤网络流量，并准确控制或拒绝使用特定的入口资源访问IP地址（或IP地址组，定义CIDR））。
注意：在版本1.8.0中，只能在策略应用于服务器上下文中的虚拟服务器资源中才能引用策略。在未来版本中，我们计划将策略支持扩展到virtualServerRoute资源，在其中应用策略对于位置上下文。我们还计划实施其他功能实施策略，例如速度限制。
下图说明了策略的使用。左边的VirtualServer资源引用了一种称为WebApp-Policy的策略。右侧的配置代码段使用此名称来定义10.0.0.0/8子网的过滤策略（允许或拒绝）。将此名称分布到两个策略意味着您可以使用Kubernetes API应用相应的策略到虚拟服务器之间切换不同的策略。
其他新功能
准备检测
在具有更多入口资源（标准kubernetes，nginx或两者）的环境中，可以在加载NGINX配置之前启动POD，从而导致“ Blackholed”。准备性检测功能以确保流量准备好接受流量（即，NGINX配置已完成，并且不会重新加载）。
在NGINX入口资源和掌舵图中启用多个入学控制器
在先前的版本中，各种nginx Ingress Controller实例可以在同一集群上共存，但只能在1.8.0版中使用标准的kubernetes.io/ingress.class.class.class。和VirtualServerRoute资源以实现相同的目的。我们还更新了Helm图表以支持多个Nginx Ingress Controller的部署。
显示VirtualServer和VirtualServerRoute资源
kubectl描述命令的输出指示入口控制器的配置是否已成功更新（在事件部分中），并列出了其外部端点的IP地址和端口（在状态部分中）。在版本1.8.0中，我们扩展的VirtualServer和VirtualServerRoute资源以返回此信息。对于VirtualServerRoute资源，状态零件还将命名Parent -Class -Class -Class VirtualServer资源。
作为应用程序所有者，您可能会发现，已删除了VirtualServer，即VirtualServerRoute资源的父类，这使得无法访问该应用程序。现在您可以通过将Kubectl Dricesd Dricesd Command compand ostals and VirtualServerver和VirtualServerRoute资源发送来解决问题。
此示例命令显示了成功应用Cafe VirtualServer的配置。在事件部分中，类型是正常的，并且添加了理由。
此示例表明，由于无效，Cafe VirtualServer的配置被拒绝。在活动部分中，类型为警告并拒绝了原因。原因是两者都被命名为上游。
在“输出状态”部分中，消息和原因字段报告与事件部分以及每个外部端点的IP地址和端口相同。
更新红帽openshift的nginx入口操作员
?策略 - 您现在可以使用NGINX Ingress Controller运算符来部署策略。
?应用程序保护扩展 - 您可以使用操作员扩展NGINX Ingress Controller的App Protect的能力，以允许所有NGINX INGRESS Controller实例检查流量的安全性。
有关版本1.8.0的完整更改日志，请检查版本说明。
如果您想尝试NGINX开源nginx Ingress Controller，则可以获取源代码的所有权或从DockerHub下载前构建的容器。
想要及时，全面地获取与NGINX相关的技术干货，交互式问题，系列课程和活动资源？请访问Nginx开源社区的官方网站http://nginx.org.org.cn
资料来源：NGINX开源社区