NSX ALB容器集成方案-AKO技术架构

1、NSX ALB容器集成方案-AKO技术架构祼金属服务器虚拟机容器私有数据中心公有云虚拟机容器新一代分布式易扩展的多云架构NSX 高级负载均衡控制器服务引擎 SERVICE ENGINE控制与转发平面分离弹性智能分析自动化多云架构2AKO 简介3原生 kubernetes 如何对内提供服务Service = 固定服务 IP + “负载均衡”+ CoreDNSService Type：ClusterIPService 本身无存活状态监控需要依赖 kubelet 进行 pod 健康检查。如果节点故障，service 中断时间=节点故障检 查超时时间（默认2min）k8s W orkersW eb-p

2、od1W eb-pod2service-w ebapp-pod1app-pod2D ep loym ent-ap pS ervice-appD ep loym ent-w eb4原生 kubernetes 如何对外提供服务NodePort = 通过 IPtables 将每个 Node 收到的指定流量转发给 ServiceService Type：NodePort原生 Service 下，流量路径 不可预测，默认配置下无 session affinity。N ode-2N ode-1W eb-pod1W eb-pod2D ep loym ent-w ebS ervice-w ebS ervice

3、-w ebN odeP ort 8443N odeP ort 8443N ode-2N ode-1W eb-pod1W eb-pod2D ep loym ent-w ebS ervice-w ebS ervice-w ebN odeP ort 8443N odeP ort 84435原生 kubernetes 如何对外提供服务NodePort 本身无高可用机制，需要依赖于外部负载均衡提供N ode-2N ode-1W eb-pod1W eb-pod2D ep loym ent-w ebS ervice-w ebS ervice-w ebN odeP ort 8443N odeP ort 844

4、36原生 kubernetes 如何对外提供服务Pod 端口直接映射到 HostNetwork，转发性能更高HostPortN ode-2N ode-1N ginx-pod1N ginx-pod2D aem onset-N ginxH ost-P ort 80443H ost-P ort 80443N ode-2N ode-1N ginx-pod1N ginx-pod2D aem onset-N ginxH ost-P ort 80443H ost-P ort 804437原生 kubernetes 如何对外提供服务基于域名访问的 IngressIngressN ode-3N ode-2N o

5、de-1IngressIngressH ost-P ort 80443H ost-P ort 80443N ginx-Ingress C ontrolerW eb-pod1W eb-pod2IngressH ost-P ort 80443N ode-4IngressH ost-P ort 80443kubernetes A P I S erver 8Service type loadbalancer原生 kubernetes 如何对外提供服务所有组件都在外部实现，通过 Nodeport 访问 Pod方案：非云原生方案的硬件 LB、Huawei CCE所有组件都在外部实现，通过三层路由直接访问P

6、od 方案：部分公有云 LBExternalLoadbalancersw eb-pod1w eb-pod2kubernetes A P I S erver ExternalC loud P rovid erExternalLoadbalancersExternalLoadbalancersw eb-pod1kubernetes A P I S erver ExternalC loud P rovid erExternalLoadbalancersN odeP ort 8443N ode-1N ode-2N ode-1N ode-29Service type loadbalancer原生 kub

7、ernetes 如何对外提供服务w eb-pod1kubernetes A P I S erver ExternalC loud P rovid erP od based LoadbalancersExternalLoadbalancersw eb-pod1w eb-pod2kubernetes A P I S erver ExternalC loud P rovid erExternalLoadbalancersC ustom K ubernetes operator控制平面及数据平面在外，通过云原生方式扩展和监控 API方案：Avi kubernetes OperatorN ode-1N

8、ode-2N ode-1N ode-210控制平面在外，数据平面在内 方案：Avi kubernetes CloudIngress开源方案中 Nginx Ingress Controller 占有半壁江山，基于 Hostport 暴露， 不支持自定义端口，默认参数只能满足 基本功能，配置高级功能参数需要 PhD，监控功能薄弱仅支持 HTTP/HTTPS 应用Nodeport/Hostport利用 iptables NAT 规则将请求发往对 应主机/主机端口映射端口选择要么动态分配缺乏控制，要么 静态分配 Excel 管理端口冲突问题功能单一，排错复杂service type LoadBalan

9、cerK8s 仅提供 API 不提供解决方案开源社区无可靠的产品和大量应用案例依赖于 Cloud Provider 提供 Loadbalancer服务很多 Cloud Provider 也基于 Nodeport 实现11原生 kubernetes 如何对外提供服务流量管理和服务发现本地负载均衡及全局负载均衡路由策略健康监控TLS 终结，证书管理和自动化CI/CD, 灰度发布DNS安全网络策略认证黑/白名单流量限速DOS 检测WAF可视化应用和基础架构性能分析交易日志交易追踪Kubernetes 应用交付应该具备哪些功能?安全管理员研发运维12Avi Kubernetes Operator（AK

10、O）架构及组件组件Avi Kubernetes Operator (AKO) Pod- 提供 Ingress-Controller 功能和 Avi 配置功能- 自动监控 k8s 对象，并将其转换成 Avi Controller APIs- 作为 POD 运行在 K8s/OC 集群中Avi Controller- 管 理 Service Engines- 集中的流量分析和展示External Avi Service Engine- 托管 Virtual-Services，提供 K8s/OC Ingresses/Routes 功能- 负责 Virtual-Service 数据平面流量13多集群 A

11、KO Avi Multi-Cluster Kubernetes Operator (AMKO) BetaAvi Multi-Cluster Kubernetes Operator (AMKO)- 加快多集群应用的部署- 每个 k8s/OC 集群中运行一个 AKO 节点- 可以跨集群发布同一个应用的 IngressMasterSite 1 GSLB LeaderSite 2Global Server Load BalancingMulti-AZ Load-BalancingMulti-Cluster Application DeploymentsAvi ControllerDNSMasterNo

12、de NAMKONode 1AKONode 1AKOSite NMasterNode 1AKO14AMKO 使用场景: 多集群应用发布Tier 1Application 1Application 2Availability-Zone 1Availability-Zone 2GSLBSite- 1Site - 2多区域应用交付跨地域多集群应用跨可用区域进行应用部署，进一步提高应用高可用性跨地域多集群应用，满足容灾需求Application 1基于应用健康情况进行流量转发基于Client 地域或其他属性完成流量转发DNSDNSLBDNSDNSTier 2AMKO15AMKODemo 演示16L4

13、Loadbalancer 创建17Ingress 的创建（HTTP）18Avi 端到端性能分析及日志查看19AKO 优势及价值20AKO 架构优势 1：一体化应用交付平台搭积木 负载均衡、GSLB、WAF 等功能分别由不同的产品提供高延迟 一个完整的架构需要 4 跳高花销 各个产品均需要付费维保Nginx + LB + WAF + GSLBAvi 一体化应用交付平台一体化方案 L4-L7 LB、 WAF、可视化、 GSLB 一应俱全低延迟 只有两跳统一管理 管理层和数据层分离，统一管理运维简单 只需要维护一套产品安全 分布式 WAF，策略配置简单可视化 通过自带可视化功能快速定位问题WAFEn

14、terprise-grade L4 Load BalancerL7 Proxy4Hop sGSLBGSLB+ WAF+L4-L7 LB2Hop sWAF企业级4层负载均衡L7 代理GSLB21AKO 架构优势 2：端到端性能监控22AKO 架构优势 3：按需扩展ClusterAvi Service EnginesAvi ControllerFabric Performance 12M TPS 4 TbpsTraffic load didInecrreases fufurrttherr按需扩缩23高性能支持超大规模高可用模式场景描述特点Active/Standby传统负载均衡到Avi的迁移一个

15、SE group 仅有两个 SE，默认 一个始终为活动，另一个为热备， 在多 VS 的情况下支持 Active/Active较为传统的高可用模式，允许单 节点故障N+M适合于单个 SE 能够满足单个 VS 的性能需求，以及应用对高可用要 求不高，可以接受短暂的服务中断 的场景其中 N 代表运行所有 VS 需要的最 小 SE 数量，M 代表允许的 SE 故 障数。两者共同决定了最终会有多 少个 SE 创建出来比较灵活，资源利用率较高，允 许多个节点故障Active/Active承载 mission-critical 任务，提供 最高级别的可用性，性能保障将一个 VS 放在多个 SE 上，实现无

16、感知故障切换性能有保障，故障切换无感知， 资源利用率较低24AKO 架构优势 4：灵活的高可用策略AKO 架构优势 5：服务发现自动化Avi 自带 IP-域名注册功能25AKO 使用 k8s CRD（ Custom Resource Definitions ） 来进行高级功能的配置，相比Annotation，使用 CRD 有下列优势：语法验证：在通过 kubectl 创建 CRD 资源对象时便会进行配置校验，避免误配置。故障排除：CRD 创建完成后可以通过 k8s 原生命令查看 CRD 状态及报错原因，方便排错。控制隔离：CRD 支持 k8s 的 RBAC，可以进行细化的访问控制。26AKO

17、架构优势 6：充分利用 k8s APICRD 优势示例：配置状态检查及排错HostRule 示例：27K8s CRD 简介28CRD 全称 Custom Resource Definitions，在 k8s 中用于扩展 API，添加新类型的资源对象。apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata:name: spec:group: versions:- name: v1 served: true storage: true schema:openAPIV3Schema: type: obje

18、ct properties:spec:type: object properties: cronSpec:type: string image: type: string replicas:type: integer scope: Namespaced names:plural: crontabs singular: crontab kind: CronTab shortNames:- ct 定义 CRD 创建 CRD 资源对象apiVersion: /v1 kind: CronTabmetadata:name: my-new-cron-object spec:cronSpec: * * *

19、* */5image: my-awesome-cron-image 自定义 Pod 监听 k8s API，处理 CRD 资源对象AKO 架构优势 7：节省地址空间针对 Ingress 服务使用共享 VIP通过共享 VIP 可以极大节省地址用量简化运维 IP 地址数量减少，相应的 IP 管理成本减少简化架构 更少的网段，更少的虚拟网卡VIP 1Ingress 1Ingress 2Ingress 3Ingress 4Ingress 5Ingress 6Ingress 7Ingress 8Ingress 9Ingress 10Ingress 11Ingress NVIP 2Ingress 1VIP

20、1Ingress 2VIP 2Ingress 3VIP 3Ingress 4VIP 4Ingress 5VIP 5Ingress 6VIP 6Ingress 7VIP 7Ingress 8VIP 8Ingress 9VIP 9Ingress 10VIP 10Ingress 11VIP 11Ingress NVIP 12dedicated-VIP 模式共享 VIP 模式29AKO 架构优势 7：节省地址空间共享 VIP 支持多种 Sharding 算法共享 VIP 支持不同的算法，例如：FQDN 哈希、 namespace 哈希、Per- namespace-VIP*注：当前版本只支持FQDN和

21、namespace哈希VIP 1Ingress 1Ingress 2Ingress 3Ingress 4Ingress 5Ingress 6Ingress 7Ingress 8Ingress 9Ingress 10Ingress NIngress 11VIP 2VIP 3Namespace 1Namespace 2Namespace 3VIP 1Ingress 1Ingress 9Ingress 5Ingress 4Ingress 2Ingress 3Ingress 6Ingress 8Ingress 7Ingress 10Ingress 11Ingress NVIP 2VIP 3FQDN H

22、ASHFQDN HASH FQDN HASHappN.30Ako 设计31Design Considerations32Avi Controller：部署在 k8s 集群外，理论上只要网络可达，部署在哪里都可以。Avi SE：SE 用于执行数据层面的负载均衡、WAF、GSLB 等，在使用 AKO 时 SE 部署在容器集群外部。AKO：提供 Ingress-Controller 功能和 Avi 配置功能， 通过 HELM 部署Avi Cloud Type：Avi Controller 通过 Avi cloud 来管理 SE，可以放在 vSphere （建议 Write mode）、Azure C

23、loud、Linux server Cloud 等注意：使用 AKO 时不使用Kubernetes cloud ，因为所有对接通过 AKO 完成，不通过 AVI controller 完成Design Considerations33部署模型：支持单臂模式和双臂模式IPAM 及 DNS：由 Avi Cloud 处理 IPAM 和 DNS 功能。具体配置取决于 Avi Cloud configuration （详见后面 Slides）SE 数据网络：详见后面 SlidesAvi 部署设计: DNS方案1：将 Avi DNS 作为主 DNS，未知解析指向外部 DNSAvi DNS 创建步骤及工作流

24、：使用 system-DNS 模板创建 virtual service为 vs 添加 DNS pool，此 DNS pool 成员为外部 DNS Server3.全局开启 DNS Service，实现 DNS Profile 中子域名的自动 解析4.同时将不能解析的请求发给外部 DNS ServerAvi 中定义的域名范围D Avi 定义的域名F34FAvi DNSAvi DNS外部 DNS外部 DNSAvi 部署设计: DNS方案2：将 Avi DNS 作为主 DNS 服务器的外部 NS 服务器Avi DNS 创建步骤及工作流：使用 system-DNS 模板创建 virtual servi

25、ce，不配置 Pool， 不检查 Pool 健康状态全局开启 DNS Service，实现 DNS Profile 中子域名的自动 解析3.所有请求先发给外部 DNS，然后再转发给 Avi DNSAvi 中定义的域名范围D Avi 定义的域名F外部 DNS外部 DNSAvi DNSAvi DNSD35Avi 部署设计: SE 到 Pod 的网络访问Node NNode 1AKOVIP4Pod IPNorth-South VIP NetworkPod Network XPod Network Y36Pod 网络不可路由Canal、Calico、Antrea、Flannel 等网络插件，pod 网

26、段在集群外不能直接访问（不可路由），这 些网络插件会在每个 Node 上分配一个 Pod 网段，Pod 从此 CIDR 获取地址如果 SE 和 Node 在同一个网段，可以在 AKO 上开启 static route programming ，AKO 自动获取 k8s node CIDR，通过 avi Controller 配置静态路由，下一跳指向 k8s node ip。如果 SE 和 Node 不在同一个网段，可以通过 Nodeport 方式暴露 Pod 后再配置 SE 。如果有多个 cluster 使用相同的 CIDR，需要在 avi Controller 和 ako 中配置 vrfPod 网络可路由NSX-T CNI、AWS CNI（EKS）、Azure CNI（AKS）等网络插件，pod 网段可路由，此时可以关闭 AKO 的 static route programming，手动添加静态路由使得 SE 可以和 POD 通信。AKO: Pod 网络POD 网络可路由在