共计 3080 个字符，预计需要花费 8 分钟才能阅读完成。
准备常识
1. K8S 上 Service 类型
- ClusterIP
通过集群的外部 IP 裸露服务，抉择该值，服务只可能在集群外部能够拜访，这也是默认的 ServiceType。
- NodePort
通过每个 Node 上的 IP 和动态端口（NodePort）裸露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会主动创立。通过申请 <NodeIP>:<NodePort>，能够从集群的内部拜访一个 NodePort 服务。
- LoadBalancer
应用云提供商的负载局衡器，能够向内部裸露服务。内部的负载均衡器能够路由到 NodePort 服务和 ClusterIP 服务。
- ExternalName
通过返回 CNAME 和它的值，能够将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。没有任何类型代理被创立。本文暂不探讨这种类型。
参考文档：https://cloud.tencent.com/document/product/457/45487
平台相干基础知识
腾讯云容器服务（Tencent Kubernetes Engine，TKE）基于原生 Kubernetes 提供以容器为外围的、高度可扩大的高性能容器治理服务，齐全兼容原生 Kubernetes API，同时扩大了腾讯云的云硬盘、负载平衡等 kubernetes 插件，为容器化的利用提供高效部署、资源调度、服务发现和动静伸缩等一系列残缺性能，解决用户开发、测试及运维过程的环境一致性问题，进步了大规模容器集群治理的便捷性，帮忙用户降低成本，提高效率。
2. TKE 上四层网络流量裸露形式
TKE 上默认应用 service-controller 来治理 CLB 上四层监听器和规定。这种形式，CLB 后端绑定每个节点的 NodePort，CLB 接管外界流量，转发到其中一个节点的 NodePort 上，再通过 Kubernetes 外部的负载平衡，应用 iptables 或 ipvs 转发到 Pod。
申请细节过程：
- 申请流量进入负载平衡
- 申请被负载平衡转发到某一个节点的 NodePort
- KubeProxy 将来自 NodePort 的流量进行 NAT 转发，目标地址是随机的一个 Pod
- 申请进入容器网络，并依据 Pod 地址转发到对应节点
- 申请来到 Pod 所属节点，转发到 Pod
实现后果如下图：
参考文档：https://cloud.tencent.com/document/product/457/45487
3. TKE 上七层网络流量裸露形式
TKE 上默认应用 l7-lb-controller 作为 Ingress 控制器，它会治理 CLB 上七层监听器和规定。实现原理和申请细节同四层实现，然而在 CLB 层面会依据域名和 URL 来转发到不同的后端 service，同时能够进行 SSL 卸载。
实现细节：
应用 TKE 默认自带的 Ingress，会为每个 Ingress 资源创立一个 CLB 以及 80，443 的 7 层监听器规定 (HTTP/HTTPS)，并为 Ingress 每个 location 绑定对应 TKE 各个节点某个雷同的 NodePort 作为 rs (每个 location 对应一个 Service，每个 Service 都通过各个节点的某个雷同 NodePort 裸露流量)，CLB 依据申请匹配 location 转发到相应的 rs (即 NodePort)，流量到了 NodePort 后会再通过 K8S 的 iptables 或 ipvs 转发给对应的后端 Pod。
实现后果如下图：
4. TKE 上的 VPC-CNI
TKE 通常用的 Global Router 网络模式（网桥计划），还有一种是 VPC-CNI（弹性网卡计划）。VPC-CNI 是 TKE 上一种新的网络模式，为每个 Pod 调配一个 ENI 弹性网卡的 EIP，Pod 间间接通过弹性网卡通信。能够了解为：给每个 Pod 调配了一个内网 IP。
长处：每个 Pod 都能够有内网 IP
毛病：须要调配一个独自的闲暇子网
参考文档：https://cloud.tencent.com/document/product/457/41636
5. TKE 上 CLB 直通 Pod
TKE 的 CLB 默认绑定的都是 node 的 IP 和端口，在应用了 VPC-CNI 给 Pod 提供独立内网 IP 之后，CLB 能够间接绑定 Pod。
申请细节过程：
- 申请流量进入负载平衡
- 申请被负载平衡转发到某一个 Pod 的 ENI 弹性网卡
参考文档：https://cloud.tencent.com/document/product/457/41897
参考文档：https://mp.weixin.qq.com/s/fJ…
实现后果如下图，留神图中的 ENI 弹性网卡和 Pod 的理论端口 80：
6. TKE 应用已有负载均衡器
先创立 CLB
在 service 的 annotations 增加：
service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx参考文档：https://cloud.tencent.com/document/product/457/45491
7. TKE 应用内网负载均衡器
能够通过指定应用已有内网负载均衡器实现。
也能够通过以下形式动态创建：
在 service 的 annotations 增加：
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxx # value 替换为集群所在 vpc 的其中一个子网 id 8. TKE 部署 Nginx Ingress
当 TKE 的默认 Ingress 实现（CLB 的 7 层规定）无奈满足业务需要时，能够额定部署 Nginx Ingress（个别都用不上）
参考文档：https://cloud.tencent.com/document/product/457/47293
理论业务场景的最佳实际
1. 对集群内裸露流量
【优先】四层协定：
- 【举荐】应用 ClusterIP 类型的 Service，并通过集群内域名拜访
- 【可选】应用公网 CLB 的四层规定
- 【不举荐】应用内网 CLB 的四层规定
七层协定：
- 【举荐】应用 ClusterIP 类型的 Service，并通过集群内域名拜访，降级为四层协定
- 【可选】应用公网 CLB 的七层规定
- 【不举荐】应用内网 CLB 的七层规定
在集群内应用内网 CLB 须要留神回环问题，故不举荐集群内应用内网 CLB。
2. 对集群外裸露流量
倡议生产环境均应用已有 CLB，即先手动创立 CLB，再在相干 Service 或 Ingress 指定 CLB 的 id。
TKE 默认控制器在 Service 应用如下配置：
service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx同时 CLB 开启“启用默认放通”，CLB 和 CVM 之间默认放通，则不必依据 NodePort 调整 CVM 上的平安组，如下图：
【优先】七层协定：
- 【举荐】TKE 自带 Ingress（3. TKE 上七层网络流量裸露形式）
- 【可选】自行部署 Nginx Ingress（8. TKE 部署 Nginx Ingress）
四层协定：
- 【举荐】TKE 自带 LoadBalancer（2. TKE 上四层网络流量裸露形式）
应用 Istio：
Istio 有点相似于 Nginx Ingress，都是先 CLB 四层监听器转发到 NodePort，再通过 istio-ingressgateway 这个 service 定义的规定，转发到 istio-ingressgateway-xx 这个 Pod，再转发到集群内其余 Istio Sidecar。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
