前言

Kubernetes在集群接入层设计并提供了两种原生资源Service和Ingress，别离负责四层和七层的网络接入层配置。

传统的做法是创立Ingress或LoadBalancer类型的Service来绑定腾讯云的负载平衡将服务对外裸露。这种做法将用户流量负载到用户节点的NodePort上，通过KubeProxy组件转发到容器网络中，但这种计划在业务的性能和能力反对会有所局限。

为了解决这个问题，TKE容器团队为在腾讯云上应用独立或托管集群的用户提供了一种新的网络模式，利用弹性网卡直连Pod的计划很大的加强了性能和业务能力的反对。

本文将会从传统的模式的问题动手，比拟新旧模式的区别，并在最初提供新直连模式的应用指引。

传统模式面临的问题与挑战

性能与个性

KubeProxy在集群中会将用户NodePort的流量通过NAT的形式转发到集群网络中。这个NAT转发带来了以下一些问题。

  1. NAT转发导致申请在性能上有肯定的损失。
    1. 进行NAT操作自身会带来性能上的损失。
    2. NAT转发的目标地址可能会使得流量在容器网络内跨节点转发。
  3. NAT转发导致申请的起源IP被批改了，客户端无奈获取起源IP。
  4. 当负载平衡的流量集中到几个NodePort时。过于集中的流量会导致NodePort的SNAT转发过多，使得源端口耗尽流量异样。还可能导致 conntrack 插入抵触导致丢包，影响性能。
  5. KubeProxy的转发具备随机性，无奈反对会话放弃。
  6. KubeProxy的每个NodePort其实也起到独立的负载平衡作用，因为负载平衡无奈收敛到一个中央，所以难以达到全局的负载平衡。

为了解决以上问题，咱们以前给用户提供的技术倡议次要是通过Local转发的形式，防止KubeProxyNAT转发带来的问题。然而因为转发的随机性，一个节点上部署多个正本时会话放弃仍旧无奈反对。而且Local转发在滚动更新时，容易呈现服务的闪断，对业务的滚动更新策略以及优雅停机提出了更高的要求。咱们有理由去寻找更好的计划解决这个问题。

业务可用性

通过NodePort接入服务时，NodePort的设计存在极大的容错性。负载平衡会绑定集群所有节点的NodePort作为后端。集群任意一个节点的拜访服务时，流量将随机调配到集群的工作负载中。这就意味着局部NodePort的不可用，或者是Pod的不可用都不会影响服务的流量接入。

和Local拜访一样，间接将负载平衡后端连贯到用户Pod的状况下，当业务在滚动更新时，如果负载平衡不可能及时绑定上新的Pod，业务的疾速滚动可能导致业务入口的负载平衡后端数量严重不足甚至被清空。因而，业务滚动更新的时候，接入层的负载平衡的状态良好，方能保障滚动更新的平安安稳。

负载平衡的管制面性能

负载平衡的管制面接口。包含创立删除批改四层、七层监听器，创立删除七层规定，绑定各个监听器或者规定的后端。这些接口大部分是异步接口，须要轮询申请后果，接口的调用工夫绝对较长。当用户集群规模较大时，大量的接入层资源同步会导致组件存在很大的时延上的压力。

新旧模式比照

性能比照

Pod直连模式曾经在腾讯TKE上线，是对负载平衡的管制面优化。针对整个同步流程，重点优化了批量调用和后端实例查问两个近程调用比拟频繁的中央。优化实现后，Ingress典型场景下的管制面性能较优化前版本有了95%-97%左右的性能晋升。目前同步的耗时次要集中在异步接口的期待上。

后端节点突增 (应答集群扩容的场景)

七层规定突增（应答业务第一次上线部署到集群的场景）

除去管制面性能优化这样的硬核优化，负载平衡可能间接拜访容器网络的Pod就是组件业务能力最重要的组成部分了，其不仅防止了NAT转发性能上的损失，同时防止了NAT转发带来的各种对集群内业务性能影响。然而在启动该我的项目时这一块还没有特地好的拜访容器网络的反对。所以一期思考集群CNI网络模式下Pod有弹性网卡入口，这个入口能够间接接入到负载平衡以达到间接拜访的目标。负载平衡间接后端拜访到容器网络，目前曾经有通过云联网解决的计划，后续也会持续跟进这种更贴近集群网络的直连计划。

接下来可能间接拜访了，如何保障滚动更新时的可用性保障呢？咱们找到了官网提供的一个个性ReadinessGate。这个个性在1.12正式提供进去，次要是用来管制Pod的状态。默认状况下，Pod有以下Condition：PodScheduled、Initialized、ContainersReady，当这几个状态都Ready的时候，Pod Ready的Condition就通过了。然而在云原生的场景上面，Pod的状态是十分有可能须要参考其余状态的。ReadinessGate提供了这样一个机制，容许为Pod的状态判断增加一个栅栏，由第三方来进行判断与管制。这样Pod的状态就和第三方关联起来了。

负载平衡流量比照

传统NodePort模式

申请细节过程

  1. 申请流量进入负载平衡
  2. 申请被负载平衡转发到某一个节点的NodePort
  3. KubeProxy将来自NodePort的流量进行NAT转发，目标地址是随机的一个Pod。
  4. 申请进入容器网络，并依据Pod地址转发到对应节点。
  5. 申请来到Pod所属节点，转发到Pod。

新的Pod直连模式

申请细节过程

  1. 申请流量进入负载平衡
  2. 申请被负载平衡转发到某一个Pod的ENI弹性网卡

直连与Local拜访的区别

看起来这两种拜访形式的成果是一样的，然而在细节上还是存在一些差异。

  1. 从性能上区别不大，开启Local拜访时，流量不会进行NAT操作也不会进行跨节点转发，所以仅仅多了一个到容器网络的路由。
  2. 没有进行NAT操作，起源IP就可能正确获取了。会话放弃性能可能会有以下问题，当一个节点上存在多个Pod时，流量到哪一个Pod是随机的，这个机制可能会使话放弃呈现问题。

ReadinessGate的引入

后面有两个细节，能够在这里失去解答。

  1. 为什么要求集群版本高于 1.12
  2. 为什么kubectl get pod -o wide的后果中READINESS GATES列有内容。

这里波及到一个滚动更新相干的问题
当用户开始为利用做滚动更新的时候，Kubernetes会依据更新策略进行滚动更新。然而其判断一批Pod启动的标识仅包含Pod本身的状态，并不会思考这个Pod在负载平衡上是否曾经进行配置健康检查是否通过。有的时候当接入层组件高负载，不能及时对这些Pod进行及时调度的话，这些滚动更新胜利的Pod可能并没有正在对外提供服务，从而导致服务的中断。为了将滚动更新和负载平衡的后端状态关联起来，TKE接入层组件引入了Kubernetes 1.12中引入的新个性ReadinessGate。TKE接入层组件只有在确认后端绑定胜利并且健康检查通过时，通过配置ReadinessGate的状态来使Pod达到Ready的状态，从而推动整个工作负载的滚动更新。

在集群中应用ReadinessGate的细节
Kubernetes集群提供的是一个服务注册的机制，你只须要将你的服务以MutatingWebhookConfigurations资源的模式注册到集群中就能够了。集群会在Pod创立的时候依照你的配置的回调门路告诉你，这个时候就能够对Pod做一些创立前的操作，在这个Case外面就是给Pod加上ReadinessGate。惟一须要留神的就是这个回调过程必须是Https的，所以标配须要在MutatingWebhookConfigurations中配置签发申请的CA，并在服务端配置该CA签发的证书。

ReadinessGate机制的劫难复原
用户集群中的服务注册或是证书有可能被用户删除，尽管这些零碎组件资源不应该被用户批改或毁坏。但在用户对集群的摸索或是误操作下，这类问题会不可避免的呈现。所以接入层组件在启动时会查看以上资源的完整性，在完整性受到破坏时会重建以上资源，增强零碎的鲁棒性。

QPS和网络时延比照

直连与NodePort是服务利用的接入层计划，其实最终参加工作的还是用户部署的工作负载，用户工作负载的能力间接决定了业务的QPS等指标。所以咱们针对这两种接入层计划，在工作负载压力较低的状况下，重点针对网络链路的时延进行了一些比照测试。直连在接入层的网络链路上可能优化10%左右的工夫。同时测试中的监控也发现，直连模式缩小了大量VPC网络内的流量。测试场景，从20节点到80节点，逐渐增大集群规模，通过wrk工具对集群进行网络延时的测试。针对QPS和网络时延，下图给出了直连场景与NodePort的比照测试。

KubeProxy的一些设计思考

KubeProxy的毛病也在前文中提到的一样显著。然而基于云上负载平衡、VPC网络的各种个性，咱们能给出各种其余更加本地化的接入层计划。但这并不意味着KubeProxy的设计不好或是作用不大。其对集群接入层的设计极具普适性、容错性，根本实用于所有业务场景下的集群，作为一个官网提供的组件这个设计是十分适合的。

新模式应用指引

前置要求

  1. Kubernetes集群版本须要高于 1.12。
  2. 集群网络模式必须开启VPC-CNI弹性网卡模式。
  3. 直连模式Service应用的工作负载需应用VPC-CNI弹性网卡模式。

控制台操作指引

  1. 登录 容器服务控制台。

  2. 参考控制台 创立 Service 步骤，进入 “新建Service” 页面，依据理论需要设置 Service 参数。

    其中，局部要害参数信息需进行如下设置，如下图所示：

    • 服务拜访形式：抉择为【提供公网拜访】或【VPC内网拜访】。
    • 网络模式：勾选【采纳负载平衡直连Pod模式】。
    • Workload绑定：抉择【援用Worklocad】，并在弹出窗口中抉择 VPC-CNI 模式的后端工作负载。
  3. 单击【创立服务】，实现创立。

Kubectl操作指引

  • Workload示例：nginx-deployment-eni.yaml

    留神spec.template.metadata.annotations中申明了tke.cloud.tencent.com/networks: tke-route-eni，在工作负载应用VPC-CNI弹性网卡模式。

apiVersion: apps/v1
kind: Deployment
metadata:
labels:

app: nginx

name: nginx-deployment-eni
spec:
replicas: 3
selector:

matchLabels:  app: nginx

template:

metadata:  annotations:    tke.cloud.tencent.com/networks: tke-route-eni  labels:    app: nginxspec:  containers:    - image: nginx:1.7.9      name: nginx      ports:        - containerPort: 80          protocol: TCP
- Service示例：nginx-service-eni.yaml  > 留神：`metadata.annotations`中申明了`service.cloud.tencent.com/direct-access: "true"`，Service在同步负载平衡时将采纳直连的形式配置拜访后端。

apiVersion: v1
kind: Service
metadata:
annotations:

service.cloud.tencent.com/direct-access: "true"

labels:

app: nginx

name: nginx-service-eni
spec:
externalTrafficPolicy: Cluster
ports:

- name: 80-80-no  port: 80  protocol: TCP  targetPort: 80

selector:

app: nginx

sessionAffinity: None
type: LoadBalancer

- 部署以上内容到集群  > 留神：在你的环境你首先须要连贯到集群（没有集群的须要先创立集群），能够参考文章尾部的帮忙文档配置kubectl连贯集群。

➜ ~ kubectl apply -f nginx-deployment-eni.yaml
deployment.apps/nginx-deployment-eni created

➜ ~ kubectl apply -f nginx-service-eni.yaml
service/nginx-service-eni configured

➜ ~ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-eni-bb7544db8-6ljkm 1/1 Running 0 24s 172.17.160.191 172.17.0.3 <none> 1/1
nginx-deployment-eni-bb7544db8-xqqtv 1/1 Running 0 24s 172.17.160.190 172.17.0.46 <none> 1/1
nginx-deployment-eni-bb7544db8-zk2cx 1/1 Running 0 24s 172.17.160.189 172.17.0.9 <none> 1/1
➜ ~ kubectl get service -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.187.252.1 <none> 443/TCP 6d4h <none>
nginx-service-eni LoadBalancer 10.187.254.62 150.158.221.31 80:32693/TCP 6d1h app=nginx

## 总结与业界比照，- AWS有相似计划，通过弹性网卡的形式实现了Pod直连。- GKE（Google Kubernetes Engine）也有相似计划。联合CLB（Google Cloud Load Balancing）的NEG（Network Endpoint Groups）个性实现接入层直连Pod。当初腾讯云TKE也利用弹性网卡实现了Pod直连的网络模式，现已在腾讯云TKE上线。接下来，咱们还打算对这个个性进行更多优化，包含1. 不依赖VPC-ENI的网络模式，实现一般容器网络下的Pod直连。2. 反对在Pod删除之前，摘除负载平衡后端。欢送大家一起来应用！## 相干参考1. [Kubernetes Service介绍](https://kubernetes.io/docs/concepts/services-networking/service)2. [Kubernetes Ingress介绍](https://kubernetes.io/docs/concepts/services-networking/ingress)3. [Kubernetes Deployments 滚动更新策略](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy)4. [Kubernetes Pods ReadinessGate个性](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)5. [Kubernetes 通过Local转发获取起源IP](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)6. [TKE容器服务 网络模式选型](https://cloud.tencent.com/document/product/457/41636)7. [TKE容器服务 VPC-CNI网络模式](https://cloud.tencent.com/document/product/457/34993)8. [TKE容器服务 配置kubectl并连贯集群](https://cloud.tencent.com/document/product/457/32191)9. [AWS ALB Ingress Controller](https://aws.amazon.com/cn/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/)10. [GKE 通过独立 NEG 配置容器原生负载平衡](https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg)>【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！