为什么需要在 OpenShift 上部署企业级 Ingress Controller

原文作者：Max Mortillaro of GigaOm

原文链接：为什么需要在 OpenShift 上部署企业级 Ingress Controller

转载来源：NGINX 中文官网

NGINX 唯一中文官方社区，尽在 nginx.org.cn

Red Hat OpenShift 作为业界备受推崇的 Kubernetes 平台解决方案，凭借其全面的功能集、稳健的架构和企业级支持获得了诸多企业的青睐。毫无疑问，这些企业也在寻求企业级流量控制功能及自动化，以增强其 Kubernetes 平台并加快应用开发和部署速度。

Kubernetes 要求使用 Ingress 接口来处理进入集群的外部流量。在实践中，访问 Kubernetes 应用的外部客户端通过网关进行通信，该网关将四层至七层的流量暴露给集群内的 Kubernetes 服务。

要实现这一点，Ingress 资源中的流量路由规则需要由 Ingress controller 来实施。没有 Ingress controller，Ingress 将一无用处。在下图中，Ingress controller 将所有外部流量发送到单个 Kubernetes 服务。

Ingress controller 将所有流量发送到单个 Kubernetes 服务的示例
（改编自 Kubernetes 文档）

NGINX Ingress Controller

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

NGINX Ingress Controller 在两个版本中提供，一个是 NGINX 开源版，另一个是 NGINX Plus。NGINX 开源版 Ingress Controller 是免费的，而 NGINX Plus Ingress Controller 是商业支持的实现，提供先进的企业级功能。

一般来说，Ingress controller 实现只支持 HTTP 和 HTTPS，而 NGINX 实现还支持更广泛的协议，包括 TCP、UDP、gRPC 和 WebSocket，能够将 Ingress 支持扩展到许多新的应用类型。此外，它还支持 TLS Passthrough，这是一个重要的增强功能，使其能够路由 TLS 加密的连接，而无需进行解密或访问 TLS 证书和密钥。

除了这些功能之外，NGINX Ingress Controller 还支持细粒度定制，可以限定到特定的应用或集群以及策略的使用。策略只需定义一次，然后根据需要由不同的团队应用到不同的应用领域。策略可用于限制请求速率、验证 mTLS 身份验证以及基于 IP 地址或子网放行或拒绝流量。NGINX Ingress Controller 还可支持 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 Ingress Controller 的用例

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 controller 不仅仅是负载均衡。对于简单的早期阶段用例而言，默认的 Ingress controller 可能就足以满足需求，但对于寻求充分利用云原生开发模型优势的企业和开发团队来说，生产级能力必不可少。

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

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

NGINX Ingress Controller 能够满足所有这些要求，它为在 OpenShift 上运行 Kubernetes 环境的企业提供了灵捷、安全、可扩展和完全支持的解决方案，可帮助他们实现更高的业务成效，同时创造巨大、即时的价值。

了解有关 NGINX 和 OpenShift 的更多信息：