本文是上海站 Meetup 讲师王文虎依据其分享内容整顿的文章。
KubeSphere 社区的小伙伴们,大家好。我是中通快递容器云平台的研发工程师王文虎,次要负责中通快递容器云平台开发、利用容器化推广、容器平台运维等工作。非常感谢 KubeSphere 社区的邀请,让我有机会跟大家分享中通快递要害业务和简单架构挑战下的 Kubernetes 集群服务裸露实际。
ZKE 容器治理平台
首先介绍一下中通的容器云治理平台 ZKE。ZKE 平台是基于 KubeSphere 开发的,当初治理的中通外部集群超过十个,蕴含开发、测试、预公布、生产等环境,所有用户都通过 ZKE 平台治理容器利用。
Kubernetes 集群服务裸露计划
依据中通的理论业务需要和一些摸索,梳理出了中通 kubernetes 集群服务裸露的几种计划。
Dubbo 服务之间拜访
中通大部分利用都是基于 Java 语言开发的,应用的微服务框架为 Dubbo。在上容器之初,咱们思考到虚拟机和容器并存的场景可能会继续很长时间,所以在布局 Kubernetes 集群的时候,通过把容器网络和物理网络买通的形式,来解决 Dubbo 服务在容器和虚拟机混布的场景下相互调用的问题。
- 如何买通 Kubernetes 容器网络和物理网络?
咱们外部环境中 Kubernetes 集群网络组件应用 calico BGP 模式,数据中心物理网络也开启了 BGP 路由协定,通过在物理网络上开启 BGP RR(Route Reflector),防止前期集群规模太大导致 BGP 宣告路由条目过多的问题。BGP RR 和 Kubernetes 集群节点建设 EBGP 街坊,互相学习路由。
泛域名形式拜访
在初步推广开发和测试容器化时,咱们遇到最多的问题就是用户在利用公布到容器环境后如何拜访。
用户在 ZKE 平台上创立 Ingress 当前,该域名是不能拜访的,必须要运维把域名指向集群 Ingress Controller,而且公司申请域名须要走 OA 流程,所以这就使得咱们的容器环境在初始推广阶段进度很慢。
咱们收集了局部用户的反馈,加上本人的思考,终于摸索出了一条开发 / 测试环境比拟高效的 Ingress 应用之路:
通过给每个集群调配一个三级泛域名,在公司 DNS 上配置把对应泛域名指向集群的 Ingress Controller,用户后续创立业务域名时能够间接在 ZKE 界面上创立 Ingress,该域名便会立刻失效,省去了很大部分测试和开发环境上容器的工夫,因为公司平安治理要求,Ingress 只提供了裸露 HTTP 协定的性能,然而这一措施也还是很大水平放慢了测试开发容器化的推广速度。
自定义域名拜访
泛域名能够帮咱们解决大部分开发 / 测试环境的域名需要,然而针对生产环境、我的项目域名须要应用 HTTPS 协定、我的项目须要自定义域名这些场景时,用户除了须要创立 Ingres 之外,还是须要通过 OA 流程进行审批的。
服务裸露计划踩坑实际
以下内容是咱们在应用 Kubernetes 的过程中服务裸露以及网络相干踩的坑,供大家参考以避坑。
Ingress Nginx Controller 服务踩坑实际
下图是我依据 Ingress Nginx Controller 代码启动流程,画的启动流程图(对于启动流程以及这个问题更详细分析能够查看链接:https://mp.weixin.qq.com/s/Pw…
Ingress Nginx Controller 启动流程与一个通用的 K8S Controller 的相似,然而真正执行把 K8S Ingress 及其相干资源同步到 Nginx 配置文件的业务逻辑是从 n.syncIngress
函数开始的,这个留到上面说。
该问题是咱们测试环境应用过程中踩过的一个坑,用户通过 ZKE 治理平台创立 Ingress 时触发了集群 Ingress Controller 故障。咱们在做故障剖析时发现了故障复现的条件,如下图所示:
后面说到 n.syncIngress
函数是 Ingress Nginx Controller 业务逻辑的入口,从该入口到本次故障最终调用函数两头的调用链 PPT 中也有提供,最终的问题点落在了 extractTLSSecretName
函数。
依据代码逻辑再剖析一下起因:
- createServers 函数会遍历
ing.Spec.Rules
,当ing.Spec.TLS
字段不为空时会把rule.Host
、ingress 以参数模式传入extractTLSSecretName
函数; extractTLSSecretName
函数首先会遍历ing.Spec.TLS
,校验tls.Hosts
中是否蕴含 host,如果蕴含间接返回tls.SecretName
;- 当
tls.Hosts
中不蕴含 host 时,会把tls.SecretName
对应的 secret 资源转为*ingress.SSLCert
类型并且校验 host 是否匹配证书中的 SAN 或 CN 属性。然而当配置的 secret 为非 TLS 类型证书时,cert.Certificate
值为 nil,就会导致cert.Certificate.VerifyHostname
(host) 处代码会报 panic 导致主程序异样,而后 nginx controller 就挂了;
修复措施分两局部:
- 平台用户操作层面防止这种状况:次要是通过用户创立 ingress 抉择证书时过滤掉非 TLS 类型的 secret,保障绝大部分通过平台使用者不会触发此类问题;
- 修复代码逻辑根治此问题:减少判断
cert.Certificate
是否为 nil 的逻辑。
Calico 敞开 natOutgoing 配置
这个配置产生的背景是在 Dubbo 利用生产容器化过程中,生产环境 Zookeeper 对单个 IP 连贯限度数比节点上 Pod 数小,导致节点上容器里的 Dubbo 利用常常会呈现连贯 Zookeeper 被回绝的问题。再因为容器网络和物理网络曾经买通,通过 calico 配置 natOutgoing 参数为 false,这个问题就迎刃而解了。
本文由博客一文多发平台 OpenWrite 公布!