背景

Ask 是 K8S 的一种特殊扩展, 它屏蔽了 node 层, 按 pod 收费.

这样可以实现低成本和弹性扩容, 在大规模的伸缩中极大的增加了效率和降低了成本

弹性扩展, 用多少算多少, 听起来确实很美好.

Ingress 本质上是一种抽象, 顾名思义, 就是所有请求的入口, 可以对请求进行控制和验证

常用的是 nginx 实现的 ingress, 通过规则映射, 将站点信息抽象各位一个个的匹配规则

接着, 我们有一个前端打点上报需求, 准备用阿里云的 ask 来做.

只是一个很简单的通过 http 请求将数据上报至阿里云 SLS 的服务.

没有状态, 存储之类的需求, 所以用 golang 写了一个简单的 api 来解决.

万事俱备, 等待数据, 然而研发同学说不太对劲.

tls 证书错误

直接甩了个错误给我看.

一看这信息, 很明显是证书问题.

然后想起, 好像确实没有在 ingress 里面配置证书.

阿里云上的 ingress 可以直接在控制台添加证书信息.

本质上是用了 ingress 的nginx.ingress.kubernetes.io/auth-tls-secret注解来实现

直接在控制配置相关的 tls 信息即可, 然而现实很骨感.

错误依旧… 难道是我打开的方式不对?

再三检查发现后并没有发现错误, 没有办法.

通过在浏览器里面直接访问域名, 提示证书不安全.

好家伙, 这是啥, ingress controller fake certificate, 明明已经指定了域名的证书.

咋会出现这么个玩意, 看起来像是 ingress 自己生成的, 但是原生的 ingress 应该是不带这玩意的.

百思不得其解啊, 最终发现 slb 居然是七层的负载均衡, 这就相当于其实客户端是和 slb 的七层负载均衡进行 tls 加密.

然后对后端的服务进行了请求, 最终将内容返回给客户端, 所以直接在 slb 层配置证书后解决了问题.

然而现实还不肯放过我这个孩子.

解决了 slb 后居然又出了一个新的问题, 就是 cors

为了防止恶意攻击, 所以浏览器限制了客户端的请求.

我们输入域名访问的站点是主站, 如果请求非主站的域名.

需要返回Access-Control-Allow-*等信息, 来通知浏览器放行.

所以我们需要在七层的负载均衡上提供相应的头信息.

然而悲剧的是阿里云提供的七层负载均衡并不能自定义相关的头信息.

在和阿里云的同学沟通的确实七层的负载均衡无法提供自定义的头信息

所以还是换回了 ack 使用, 而且 ask 的整个架构也和 ack 不太一样.

ack 的数据流是这样的client->slb->nodeport->ipvs->nginx-ingress->service

1. client将数据发送给slb的TCP端口上
2. slb将数据包转发给nodeport
3. 数据通过nodeport进入ipvs
4. ipvs再将数据通过不同的策略转给nginx-ingress的pod
5. nginx-ingress最终对相应的反向代理请求service

ask 的数据流很简单client->alb-ingress->service

1 2	1. 客户端发送请求给alb-ingress 2. alb-ingress通过eni直接进行反向代理请求service

这也就意味着 alb-ingress 和 service 的网络是互通的, 并且将路由信息直接注册到 alb-ingress 中.

ask 方案性能最好, 没有过多的网络消耗, 但是无法兼容 nginx-ingress, 有些需求可能无法实现, 比如 cors

ack 在性能上虽然不是最佳, 但胜在灵活性上, 可以兼容 nginx-ingress 注解灵活的对请求进行控制

性能和灵活一直都在相爱相杀, 最终还是取决于业务场景.

以上是我在使用阿里云的 ack 和 ask 碰到的问题和总结.