上文介绍了在 TKE 的集群当中部署 nginx-ingress-operator 和 nginx-ingress-controller 的使用流程和部署方案建议，完成以上步骤，仅仅是在集群内部署了 Nginx 的相关组件，但要接收外部的流量，还需要配置，还需要配置 nginx 的前端 LB。当前 TKE 已完成对 Nginx Ingress 的产品化支持，可以根据业务需要选择以下部署模式之一。
方案一：VPC-CNI 模式集群使用 CLB 直通 Nginx 的 Service（推荐）前置条件（满足其一即可）：
集群自身网络插件为 VPC-CNI
集群自身网络插件为 Global Router，并已开启 VPC-CNI 的支持（两种模式混用）
我们以节点池部署的负载示例
当前方案性能好，所有的 Pod 都使用的弹性网卡，弹性网卡的 Pod 是支持 CLB 直绑 Pod 的，可以绕过 NodePort，并且不需要手动维护 CLB，支持自动扩缩容，是最理想的方案。 方案二：Global Router 模式集群使用普通 LoadBalancer 模式的 Service
当前 TKE 对于 LoadBalancer 类型的 Service 默认的实现是基于 NodePort，CLB 会绑定各节点的 NodePort 作为后端的 RS，将流量转发到节点的 NodePort，然后节点再通过 Iptables 或 IPVS 将请求路由到 Service 对应的后端 Pod（指 Nginx Ingress Controller 的 Pod）。
您的集群如果不支持 VPC-CNI 的网络模式，可以通过常规的 LoadBalancer 访问方式的 Service 接入流量。
这是在 TKE 上部署 Nginx Ingress 最简单的方式，流量会经过一层 NodePort，多一层转发，但可能存在以下的问题：
转发路径较长，流量到 NodePort 后，还会再经过 Kubernetes 内部负载均衡，通过 Iptables 或 IPVS 转发到 Nginx，会增加一点网络耗时
经过 NodePort，必然会发生 SNAT，如果流量过于集中，容易导致源端口耗尽或者 conntrack 插入冲突而导致丢包，引发部分流量异常。
每个节点的 NodePort 也充当一个负载均衡器，CLB 如果绑定大量节点的 NodePort，负载均衡的状态就分散在每个节点上，容易导致全局负载不均。
CLB 会对 NodePort 进行健康探测，探测包最终会被转发到 Nginx Ingress 的 Pod，如果 CLB 绑定的节点数量多于 Nginx Ingress 的 Pod，会导致探测包对 Nginx Ingress 造成较大的压力。
方案三：使用 HostNetwork + LB方案二虽然是最简单的部署方式，但是流量会经过一层 NodePort，且可能存在如上所描述的问题，我们可以让 Nginx Ingress 使用 HostNetwork，CLB 直接绑定节点 IP + 端口(80,443)。由于使用 HostNetwork，nginx ingress 的 Pod 就不能被调度到同一个节点当中，避免端口监听冲突。
由于 TKE 尚未对此方案进行产品化，可以通过提前规划，选择部分节点，专门用于部署 nginx-ingress-controller，为节点打上 Label，然后以 DaemonSet 的方式部署在这些节点上（即 nginx-ingress-controller 的部署方案一）。
TKE 通过集成 腾讯云容器团队的高性能云原生监控服务（传送门：https://console.cloud.tencent.com/tke2/prometheus ），也可在以前发布的文章《如何用 Prometheus 监控十万 container 的 Kubernetes 集群》中了解 Prometheus，Kvass 和怎么利用 kvass 为基础的 Prometheus 集群化技术。
绑定监控实例TKE 通过集成 腾讯云日志服务 CLS，提供了全套完整的产品化能力，实现 nginx-ingress-controller 的日志采集和消费能力，但需要注意如下几个事项：
前置要求：确保当前集群已开启日志采集功能
在 nginx-ingress-controller 实例中，配置日志采集的相关选项。