vlambda
2021-09-18

大变动！CNA 交付新玩法！Avi Kubernetes Operator

（本文转载于讯服天下）近两年，云原生市场开始快速增长，Docker 的横空出世到 K8s 的事实标准敲定，俨然促成了“一鲸落，万物生”的繁荣生态。

云原生计算基金会 CNCF 整理了一张所有被纳入管理的云原生项目图（2019）：

此图中 Service Proxy 部分，主要承担容器服务代理的功能，常用的如开源的 Nginx，Istio 项目主要角色 Envoy 等。以及如 AVI，Citrix，F5 等传统应用交付厂商的产品。本期将带来 V 记 NSX ALB（AVI）作为容器外部负载均衡（Ingress Controller）方案的分享。

Avi Kubernetes Operator

V 记收购应用交付厂商 AVI 演变而来的 V 记 NSX ALB 产品是一个软件定义的负载均衡解决方案。既然是软件定义的，NSX-ALB 具有控转分离，集中管理，北向 API 接口等 SDN 的特征，配合强大的可视化分析和路径追溯功能，NSX ALB 构成了企业虚拟云网络的重要一环。

与传统硬件负载均衡设备（F5 ，CitrixNetscaler）不同，V 记 NSX ALB 是一个纯软件设备，并且适合多种类型的部署方式（Bare Metal，VM，Container，Public Cloud），是一个分布式的多云负载均衡产品。

为了直观地介绍 NSX ALB 的系统架构，以上图为例，NSX ALB 分为管理层，控制层，数据层。管理层和控制层功能统一由 ALB Controller 的组件提供，可在多种平台（Linux，V记 ESXi，Public Cloud）部署为VM的形式。数据层的功能由 ALB Service Engine 提供，可部署为 VM 或容器的形式。灵活的部署方式和集中式的管控为 NSX ALB 提供了多云管控的能力，企业即可将自己的应用程序扩展的任何平台，任何地点，统一通过 NSX ALB 交付给用户。

对于云原生环境而言，NSX ALB 提供 Avi Kubernetes Operator（AKO）功能，这是一个 ALB 作为提供商的 Kubernetes Operator，提供 Kubernetes Ingress Controller 的功能。AKO 可将 K8s 集群管理员生命的 Ingress 资源和转换为 ALB 对象并通过 ALB Controller 自动化配置到 ALB SE 上，为容器提供统一的外部负载均衡。

那么，社区及商业 Ingress Controller 种类繁多

AKO 又有什么优势呢？

一站式解决方案

包含 L4-L7 Load Balance，WAF，GSLB；

低延时高可靠

路由方式进入 Pod ，降低 Iptables 性能损耗；

集中管理控制

多 K8s 集群，多云环境都由一个 ALB Controller 管控；

简化运维

通过 GUI 和 K8s CRD 进行高效管理；

弹性扩展

NSX ALB 支持横向扩展，可根据业务层并发压力及时弹性扩容；

强大的可视化

提供端到端可视化分析和日志收集。

接下来，笔者会通过一些简单的 Demo 演示 NSX ALB AKO 的基本功能。

AKO Demo 演示

本次 Demo 环境由一个三节点的 K8s 集群构成（1Master，2Node）。AVI SE 与 K8s Node 使用同一网段：PG-VLAN21，172.20.21.0/24。当然，生产环境亦可采用 SE 和后端服务器节点在不同网段的双臂部署，并根据实际情况可开启 VRF 功能。K8s Node 节点间使用 V 记 Antrea 组成容器网络。Antrea 是 V 记开源的一个容器网络项目，Antrea 使用 Geneve 协议组建跨主机的 Overlay 网络，并提供 CNI 功能和 Network Policy。Antrea 与 Calico 和 Flannel 对比，具有两个很引人入胜的功能：

似于 V 记 NSX-T的TraceFlow；
提供新的 ServiceLoadbalance 功能——NodePortLocal。感兴趣的朋友可以访问 Antrea 官网：https://antrea.io/。

接下来笔者会演示一些 AKO 的相关 Demo，首先从部署说起。

由于是外部的负载均衡，首先需在基础设施环境中部署 ALB Controller，本次 Demo 以 V 记 vSphere 虚拟化环境为演示，生产环境可按实际环境部署。

在部署 AKO 之前，需要提前在 ALB Controller 上定义 IPAM 文件和 DNS 文件，使用 IPAM 定义 SE 负载均衡器的 IP 地址和 Virtual Host 对应的 VIP 地址，使用 DNS 文件定义域名和相应的 DNS 服务，可使用 ALB DNS 或者外部 DNS 服务。

IPAM 网络选择与 K8s 节点网段一致的 Port Group，实现单臂部署，对于不可外部路由的容器网络，单臂部署场景 AKO 会自动在 ALB Controller 上配置 SE 到 K8s Pod 的静态路由下发给 SE。

完成前置条件后就可以部署 AKO 了，AKO 需要通过 Helm 包管理器安装，Helm 版本需>3.0。可在 Helm Chart 的 Values 文件自定义相关参数完成自定义部署，主要参数如下：

clusterName

若存在 Tanzu 集成，此 Key 值需设定为 TanzuKubernetes Cluster 名，原生 K8s 环境下和 SE Group 名称保持一致即可。

cniPlugin

nodeNetworkList

vipNetworkList

serviceEngineGroupName

填写对应的 SE Group 组名称，最佳实践需要一个单独的 SE Group 组给 K8s 使用。

controllerVersion

填写当前的 ALB Controller 版本信息，需检查 AKO 和 AVI Controller 兼容性。

controllerHost

修改完毕后，执行安装：

  
    
    
  
   
     
     
   helm install ako/ako --generate-name --version 1.5.1 -f /path/to/values.yaml --set ControllerSettings.controllerHost=<controllerIP or Hostname>--set avicredentials.username=<avi-ctrl-username> --setavicredentials.password=<avi-ctrl-password> --namespace=avi-system

查看 AKO Pod 情况：

  
    
    
  
   
     
     
   kubectl get pods -n avi-system -o wide

在 AKO 成功安装后，IngressController 完成部署，相关 AKO CRD 资源会完成部署，AKO 使用 CRD 和 Operator 的机制部署自定义 K8s 控制器，与传统 Ingress 使用 Annotation 声明 LB 配置不同的是，AKO 几乎全部都使用 CRD，这样的好处在于方便版本控制，同时紧密结合 RBAC 机制，带来较为标准的交付流程。

查看相应的 CRD，可以看到，ALB 共包含三类 CRD，HostRule，HttpRule，aviinfrasettings。其他还有很多 vmware.com 结尾的 CRD 是什么呢，是 Antrea！

  
    
    
  
   
     
     
   kubectl get crd | grep vmware.com

HostRule: 针对 VirtualService 的设置，如 SSL Offloading，Http 策略，WAF 策略等。
HttpRule：针对 Server Pool 设置，如负载均衡算法，健康检查等。
Aviinfrasettings：针对 VIP，SE，Route 等基础设施配置。

了解完结构后，我们迫不及待来演示一个样例：

使用 kubectl 部署一个 Kuard 应用，这是一个常用的 Kubernetes 环境演示应用，通过 Ingress 暴露服务：

查看部署的 Pod：

  
    
    
  
   
     
     
   kubectl get pods -A | grep kuard

查看 Ingress 状态：

  
    
    
  
   
     
     
   kubectl get ingress -A | grep kuard

由于本次 Demo 演示使用 V 记 Antrea 容器网络，Antrea 提供一个类似于 Kubernetes Dashboard 的管理页面，亦可在此 GUI 实现资源部署和资源管理：

当然 Antrea 还可以跟踪流，此处演示 Kuard Pod 跨主机通信的拓扑：

访问 kuard 应用：

此时即可在 NSX ALB 上观察到创建的 LB 服务及相关 VIP，Pool 配置：

由于此 Virtual Service 是并未 TLS 加密，AVI 健康检查硬性减掉了 20 分。接下来可通过 AKO CRD Host Rule 配置 7 层规则：

这个 HostRule 中声明的策略需提前在 ALB Controller 配置好，然后直接在 CRD 引用进行声明即可。

下发 Hostrule 并验证是否成功：

  
    
    
  
   
     
     
   kubectl apply -f avi-kuard-host.yaml
   
     
     
   kubectl get hostrule

此时登录 ALB Controller 可以看到一个基于 FQDN的Virtual Service，并检查是否应用声明的策略：

首先验证 SSL 配置文件：

验证 Http 策略，这个策略可以将匹配 kuard.k8s.v587.local 的所有请求进行速率限制，每秒最多 10 个连接，不匹配的流量则返回 429:

此处使用 Siege 工具发送 Http 请求验证：

  
    
    
  
   
     
     
   siege -c 5 -r 20 https://kuard.k8s.v587.local

对于异常流量，可以使用 ALB Logs 功能，利用强大的可视化分析界面帮助管理员进行分析和排障！这是笔者非常喜欢的一个功能，也是 NSX ALB 相比其他玩家的优势。

接下来验证 Data Scripts 功能，这个功能可以为虚拟服务添加额外的安全保护机制或自定义消息，以便于管理员审计和权限管控。

此样例设置一个添加自定义会话 ID 的 Scripts，根据时间 IP 回应 HASH 值：

之后验证 http 策略和分析文件，Http 做了一些 Http 重定向到 Https，预留 Clinet IP 的规则，分析文件将 syslog 发送至 vRealize Log Insight：

当然，除了使用 HostRule，管理员也可以直接在 ALB Controller 上进行 Virtual Service 的策略配置，GUI 结合 infrastructure as a code 的形式当然更受企业欢迎，我可以不用，你不能没有！配置一个 Http Request 策略，当请求/admin匹配时返回一个自定义 Html，在一些应用程序 URL 路径不符合企业安全规范时可适当规避。