为什么您需要 OpenShift 上的企业级入口控制器

[netflix]

企业依靠红帽 OpenShift业界广受好评的 Kubernetes 平台解决方案来获得其全面的功能集、强大的架构和企业级支持。毫不奇怪，这些组织也在寻求企业级流量控制功能与自动化相结合，以增强其 Kubernetes 平台并在应用程序开发和部署周期中实现更快的节奏。

Kubernetes 强制使用 Ingress 接口来处理进入集群的外部流量。实际上，访问 Kubernetes 应用程序的外部客户端通过网关进行通信，该网关将第 4 层到第 7 层的流量公开给集群内的 Kubernetes 服务。

要发挥作用，入口资源中的流量路由规则需要由入口控制器实现。如果没有 Ingress 控制器，Ingress 将无法执行任何有用的操作。在此图中，入口控制器将所有外部流量发送到单个 Kubernetes 服务。

   
将所有流量发送到单个 Kubernetes 服务的示例 Ingress 控制器

NGINX 入口控制器

NGINX Ingress Controller是一种入口控制器实现，可控制 Kubernetes 应用程序的入口和出口流量，通过自动化软件配置增强 NGINX 负载均衡器的功能。它提供了对生产 Kubernetes 部署至关重要的强大流量管理功能，超越了 OpenShift 默认 Ingress 控制器提供的基本功能。

NGINX Ingress Controller 有两个版本，一个具有 NGINX Open Source 的功能，另一个具有 NGINX Plus 的功能。NGINX 开源入口控制器是免费的，而 NGINX Plus 入口控制器是商业支持的实现，具有先进的企业级功能。

一般来说，Ingress 控制器实现仅支持 HTTP 和 HTTPS，但 NGINX 实现还支持TCP、UDP、gRPC 和 WebSocket，这是一组更广泛的协议，将 Ingress 支持扩展到许多新的应用程序类型。它还支持TLS Passthrough，这是一项重要的增强功能，使其能够路由 TLS 加密的连接，而无需解密或访问 TLS 证书和密钥。

除了这些功能之外，NGINX Ingress Controller 还允许进行细粒度的定制，这些定制的范围可以限于特定的应用程序或集群，以及策略的使用。策略可以定义一次，然后根据需要由不同的团队应用于各个应用程序领域。策略可用于限制请求速率、验证 mTLS 身份验证以及基于 IP 地址或子网允许或拒绝流量。还支持 JWT 验证和 WAF 策略。此示例策略将来自每个客户端 IP 地址的请求限制为每秒 1 个请求。

代码:

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: rate-limit-policy
spec:
  RateLimit:
    rate: 1r/s
    key: ${binary_remote_addr}
    zoneSize: 10M

NGINX 入口控制器的用例

NGINX 已经确定了使用NGINX Ingress Controller 的至少三个原因：

• 提供生产级功能
  
• 安全的容器化应用程序
  
• 提供全面的流量管理
  

下图提供了潜在用例的更好视图，其中一些用例（流量路由和 WAF 策略）已在上一节中讨论过。

   
NGINX Ingress Controller 跨运营团队的用例

一个有趣的示例用例是实现蓝绿部署的能力，您可以将生产流量从当前应用程序版本（蓝色）切换到新版本（绿色）并验证新版本是否正常运行。如以下配置示例所示，您可以首先将 90% 的流量定向到蓝色应用程序（当前版本），将 10% 定向到绿色应用程序（新版本）。

您可以监控流量以检测绿色用户群是否遇到任何问题。如果遇到问题，可以回滚配置，将所有绿色用户重新路由回蓝色版本。反之，如果新应用表现良好，您可以调整流量分配，将更多流量引导至绿色版本，并验证绿色应用在负载增加的情况下的表现，最终将所有流量路由至新绿色应用，旧的蓝色应用程序退役。

代码:

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app
spec:
  host: app.example.com
  upstreams:
  - name: products-v1
    service: products-v1-svc
    port: 80
  - name: products-v2
    service: products-v2-svc
    port: 80
  routes:
  - path: /products
    splits:
    - weight: 90
      action:
        pass: products-v1
    - weight: 10
      action:
        pass: products-v2

示例比我们所能涵盖的要多，但 NGINX 有一个专门的 GitHub 存储库，其中包含多个示例。

结论

入口控制器不仅仅是负载平衡。对于简单的早期用例，默认的 Ingress 控制器可能就足够了，但对于寻求充分受益于云原生开发模型的组织和开发团队来说，生产级功能至关重要。

此外，高级入口控制器不仅必须提供复杂的流量管理，还必须提供企业级安全性。这是通过实施双向 TLS (mTLS) 身份验证、加密流量直通和 WAF 保护来实现的。

最后，NetOps 和 NetSecOps 团队也受到 Ingress 控制器的影响。当他们努力实现网络配置和基于策略的流量控制的自动化时，他们不能让新兴的云原生、基于 OpenShift 的工作负载成为需要手动配置活动的薄弱环节。相反，他们寻求与现有安全解决方案无缝集成的工具，以确保跨设备和平台的一致配置。

NGINX Ingress Controller 可满足所有这些要求，为在 OpenShift 上运行 Kubernetes 环境的组织提供灵活、安全、可扩展且完全受支持的解决方案，帮助他们实现更多业务成果，同时提供巨大且即时的价值。