关于云计算:中通快递关键业务和复杂架构挑战下的-Kubernetes-集群服务暴露实践

本文是上海站 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 函数。

依据代码逻辑再剖析一下起因：

1. createServers 函数会遍历 ing.Spec.Rules，当 ing.Spec.TLS 字段不为空时会把 rule.Host、ingress 以参数模式传入 extractTLSSecretName 函数；
2. extractTLSSecretName 函数首先会遍历 ing.Spec.TLS，校验 tls.Hosts 中是否蕴含 host，如果蕴含间接返回 tls.SecretName；
3. 当 tls.Hosts 中不蕴含 host 时，会把 tls.SecretName 对应的 secret 资源转为 *ingress.SSLCert 类型并且校验 host 是否匹配证书中的 SAN 或 CN 属性。然而当配置的 secret 为非 TLS 类型证书时，cert.Certificate 值为 nil，就会导致 cert.Certificate.VerifyHostname(host) 处代码会报 panic 导致主程序异样，而后 nginx controller 就挂了；

修复措施分两局部：

1. 平台用户操作层面防止这种状况：次要是通过用户创立 ingress 抉择证书时过滤掉非 TLS 类型的 secret，保障绝大部分通过平台使用者不会触发此类问题；
2. 修复代码逻辑根治此问题：减少判断 cert.Certificate 是否为 nil 的逻辑。

Calico 敞开 natOutgoing 配置

这个配置产生的背景是在 Dubbo 利用生产容器化过程中，生产环境 Zookeeper 对单个 IP 连贯限度数比节点上 Pod 数小，导致节点上容器里的 Dubbo 利用常常会呈现连贯 Zookeeper 被回绝的问题。再因为容器网络和物理网络曾经买通，通过 calico 配置 natOutgoing 参数为 false，这个问题就迎刃而解了。

本文由博客一文多发平台 OpenWrite 公布！