Kubecon Shanghai 2019 回顾

现在回想起来，也许正是那么多有趣的人与技术会在此相遇，让我着迷于参与社区、参与开源、参与到整个云原生大潮中。

正文

今年Kubecon在上海如期举行了，Kubecon的分享一如既往的保持了非常高的质量，在这里记录一下我听完以后比较印象深刻的分享。

Helm3的发布

发布了Helm3,谈到了Helm3的架构，去除C/S架构，Helm3只会拥有客户端，并且会有更为明确的行为逻辑。

比起从Helm2 迁移到Helm3 ，更倾向于转向 kustomize

HP在istio对于权限的多层应用

Fitstation这个业务既有自己的服务，也有许多外部合作商与和第三方相关的服务，所以如何管理好这些来自各个parties/partners的服务相互调用的权限关系就非常重要了。

分享者讲述通过istio去做多层的权限设计体系，对于合作伙伴作为L1层，采用RBAC鉴权模型，对于第三方服务，采用L2层，基于外部的OpenAuth引擎(他们使用的是AWS IAM服务)，然后对于自身内部服务则为L3层，内部服务调用互相可信。L1/L2/L3互相之间的通信都通过istio auth adapter来控制权限，即语言无关、框架无关，又能做到无侵入式的对接到第三方服务/与合作方服务。

通过istio去做多层权限设计这个思想与实践非常棒，但这么设计的具体原因以及所对应的真实业务场景需求，需要问下分享者本人做一些确认。

Local PV宣传

K8S 1.14 GA特性 Local PV 的宣传，相比PV有着更高的iops,相比HostPath挂载的是整个硬盘，同时分享人还给出了关于localPV的各种BP。

Tidb和Tikv作为分布式数据库，同时需要有SSD的支持，这一特性可以说是对这两大产品来说重大利好了，分享人也是来自Pingcap。同时这也提醒了我也许在后面对于键值或者RDBMS这类云上存储服务的需求，可以考虑采用Tikv或者Tidb作为试点，对于异地多活场景也许有原生方案支持。

CRD的宣传

两位分享人分享了在存储组提交了某个新的特性PR被核心组拒绝后，然后反思对Kube core组件的思考，认为自己所提供的新功能通过CRD定义更为合适的故事。这次的Kubecon大会有很多有价值的分享都提到了自己是如何通过CRD来最终解决问题的，特别是KubeBuilder的发布与K8s 1.15特性中对CRD的OpenAPI支持。个人认为如今我们在K8S上许多特定的需求都不应该去改动K8S Core的代码，而是应该通过CRD的形式来满足特定的需求(例如来自组织形式的需求)

树莓派Kubernetes

分享者分享了自己通过树莓派搭建了一个K8s集群。感觉像是个玩具项目，非常fun。对于本地K8S开发我更倾向于Kubernetes For Docker.

Kubernetes上 Mysql 容器的正确大小与自动扩展

一个来自京东的分享，目前京东生产环境的Mysql容器已经全部容器化。对于Mysql本地HA的方案，京东采用了Vitess的方案。同时还自研了新的调度算法，主要在于Node Constraint采取了应用资源相关性与limit share Headroom作为了全新的约束条件以及在Node selector上进行了从K8S默认的打分机制更改为资源(cpu,memory)夹角公式，由于这个夹角公式是可以使多维的，所以可以说以后加入更多的资源维度需求(gpu,网络带宽,iops)

干货非常多的一场分享。首先对于mysql的本地HA方案，之前本身一直纠结与Vitness与Helm提供的Mysql-ha。通过这次分享基本敲定打算跟随社区的步伐走，使用Vitness做本地HA。另外一方面，对于大集群/万级规模的容器数量而言，K8S默认的调度算法并非完全合适，所以自研调度器算是一个比较有价值的事情，后面我们会在腾讯/阿里这些公司的分享上都遇到自研调度器的场景。 比较可惜的是，没有去提问确认京东自研的调度器算法是仅仅针对存储场景下的容器还是可以cover整个集群场景

高可用与扩展性Prometheus

来自阿里的分享，主要介绍了Prometheus的高可用性方案与多集群Prometheus的Global Query方案。描述了Prometheus 联邦方案的不足之处，提出使用Thanos方案来同时满足HA与Global Query。

同时还给出了针对大规模场景集群下，采集指标的技术方案。给出的方案是专门写了一个Node agent，采用了Prometheus的TSDB作为Node本身的存储，同时暴露Prometheus metrics接口与提供一些聚合能力。

然后在下层采集端，通过go-plugin组件做出指标采集器的插件化配置，并且保证对于相同的指标，不会在不同的采集器内被重复采集/对于不同的指标，也采取了不同的采集频率。从而达到了性能与需求的平衡。具体可以查看链接中的PPT内容。

这个分享的主题非常切入国际化业务的应用场景，尤其是Prometheus的Global Query。对于国际站而言，由于业务跑在了多个集群，对于相同的指标而言，我必须在label上打上地域性标签。我不知道对于这种场景Thenos的解决方案是否比现有的方案更加优雅简单。

Knative Serving原理介绍

分享者解释了一波Knative的serveless实质原理，介绍了Knative是如何接受请求，处理请求，以及对于请求冷热路径的处理从而灵活调控应用实例来达到资源利用率。并且由于Knative基于Istio的设计，所以同时还能基于Istio的服务治理能力给予流量管理和可观测性,PPT做的非常言简意赅，看完就看懂了。

目前的Serveless领域内，各个标准各个实现非常纷繁复杂，通过这次听完Knative的分享，基本上确定了我Serveless方案就走Knative的想法，而不再是Kubeless或者是其他方案。

对于Serveless而言，相比较传统的 “先启动应用，然后接受请求，最后处理请求”，这种形式，Serveless的“先接受请求，再启动应用，最后处理请求”的方式确实能更加节省资源。 但是对于这种请求流程处理的改变，看下来个人感觉首先要求应用处理HTTP请求启动时间尽可能短，Java这种上来就启动个60秒的就很不合适，最好是类似 python 、nodeJs这种脚本型、或者是Golang这种二进制包，另外一方面由于这种处理方式可能更适合异步的请求调用，对于同步请求而言存在风险。

大规模场景下的Kubernetes Master性能优化

介绍了在大规模场景下对Kubernetes管理的性能优化方案，以及如何管理多个K8S集群。 首先在分享者的介绍，阿里内部有数十个K8S集群，每个K8S集群基本上有上千的应用，上万的服务，千万级的容器。

由于对于这种千万级容器的K8S集群场景，他的存储对象可以说是非常巨大的，对于背后etcd的压力也是非常大的。

所以首先第一步对于etcd的存储于查询做了性能优化，具体可以参考 etcd优化 ，同时做了etcd-proxy,从而支持基于index查询，比如在etcd层面获取某个namespace下的所有pod信息。

同时对于kubelet的心跳，也做了网络层面的优化，1.1.4开启lease特性后，Kubelet的心跳数据包将减去不必要的数据。同时对于K8s代码中出现场景非常多的List/Watch Cacher也做了基于k8S场景下的优化，这些优化都已经提交到K8S社区作为1.14/1.15的新特性。

emmm确实对于阿里这种场景极大规模的场景下会暴露出这种性能瓶颈问题，平时在使用内网K8S和生产环境的K8S根本没有感受到这方面的瓶颈过

Istio在大规模场景下的性能与最佳实践

非常具有干货的一场分享，Istio这个项目从发布之处就一直在被诟病Sidecar方案的服务网购在大规模场景下的性能问题。分享者通过对开启与未开启Istio 1.1下新特性Sidecar，来进行istio Pilot资源消耗与xds连接数比较，最终得出结论，在istio1.1下只要通过完善的Sidecar设置，istio完全可以在

数千级节点 + 数千级服务 + 万级POD(数千级被istio管理) 这个规模下保持良好的性能结果，并对响应的资源消耗给出了一个推荐数值，和大规模下的istio BP参数推荐。

对于大规模istio支撑的一剂强心针，虽然目前国际站生产环境istio已经稳定运行了将近一年了，但是始终是数个节点+十几个服务+数十个pod这种级别，所以基本就不会考虑到性能问题。在听了这个分享以后，对于未来服务网格支撑大规模集群有了信心。而且还接触到了一个Kubernetes压测工具，Kubemark。但不知道为什么google上搜的时候发现社区内部的kubemark资料很难搜到了。

通过学习痕迹优化微服务

分享者通过istio 和Jaeger获取生产环境中的HTTP请求链路数据，然后通过KubeFlow进行LSTM训练，发现流量中的故障点，最后得到一些可预测的结论来提前进行实例调度(类似在流量高峰来临前提前准备扩容)

由于我8是很懂机器/深度学习，所以这块听得比较懵逼。会后有个提问者的问题问的非常有价值，就是这个训练后得到的结果是否是领域相关的还是可以推广到所有HTTP业务，很遗憾分享者给的答案是领域相关。

另外通过分享者的架构发现目前我的Jaeger架构是All-in-one，这个在大规模集群下会有点性能问题，准备后面有空改进为自建Jaeger服务。

有效管理大规模K8S集群

依旧是来自阿里的分享，着重介绍了Kubernetes in Kubernetes的管理方式。即运维方通过元Kubernetes去声明管理业务K8S，元K8S可以创建/删除/修改业务K8S，然后业务方使用的K8S就是直接在业务K8S上进行。

同时由于采取的是声明式API，所以同样也支持了业务K8S的故障自愈等相关能力。对于声明式API有了新的理解，同时觉得这种K8S in K8S的管理方式很炫，两者结合确实可以减轻不少在K8S管理方面的运维压力。不清楚以后社区是否会出现这样的产品。

电商巨头的云原生迁移之路

本次Kubecon最棒的一个分享，没有之一。让我只恨自己为什么没带录音笔来现场。而且还在现场见到了张磊大佬。介绍了阿里云内部的Kubernetes架构(神龙裸金属+弹性资源池 → 元Kubernetes → 业务Kubernetes)

其中K8S调度器毫无疑问自研的，通过CRD创建了很多新的资源对象来满足业务需求，剔除富容器(没错就是你Pouch）,转而改用containerd（runc+kata,docker在性能上确实不行),业务的Pod自动注入治理sidecar(监控，日志，Mesh等等)。

提出了很多因为场景/规模/业务因素而作出的改进。在k8s性能优化这块和上文分享有重叠。

InPlace Update: 业务容器/Sidecar更新时，通过原地更新container取代了销毁和创建Pod。对于阿里四大金刚业务而言，某个服务有上万Pod是很正常的事情，在发布非常频繁，并且非常追求稳定的电商/金融场景下，上万规模的销毁和创建Pod即带来了非常高的不稳定性，也给调度器/etcd/apiServer带来了很大的压力。

BatchUpdate: 对于某些有几万个pod的statefulset，k8s原来的更新POD批次是one by one的，这太慢了，新的CRD对象加强级Statefulset支持批量级更新，比如500个pod分10批次更新，每个批次一起更新50个。

SidecarSet: 更为强大的Sidecar注入能力

BroadcastJob: daemonset + Job的组合版。

这些CRD组件都已经开源 Openkruise

非常赞同业务容器+服务治理sidecar的思想，剔除富容器，拥抱containerd，kruise的做法也代表了CRD这条路的正确性，对我而言最有价值的应该就是SidecarSet与BroadcastJob这两类资源。会后还加了张磊大神微信，赚翻了。

Contour Ingress Controller

Vmware发布的一个新的IngressController，基于Envoy，所以也拥有很多看来神似istio流量治理的功能。很适合运用与大规模/多团队的Kubernetes场景下，而且在api方面有着比nginx ingress controller更好更丰富的声明能力。

说实话nginx ingress controller也就适合在简单场景下用用了，遇到一些比较复杂的api路由或者流量治理下他那令人捉鸡的语法表达能力来管理这种场景是真的麻烦。目前contour虽然没有发布生产就绪版，但是未来可期。也许以后我们可以考虑切换到使用Contour。

CloudCode

Google发布的一个Vscode/Intellij插件，非常好用非常骚，可以直接调试Kubernetes上运行的应用。非常实用。

个人点评: 这个东西结合istio我已经想到了一个绝妙的idea，我准备打算把这个idea留到hackday再做，所以不在这里透露了。

一些想去看但很遗憾没去看的会议

DragonFly： 一个国人写的镜像分发，作者在知乎上发言很跳，但是这款软件确实在Kubecon上评价不错。

CloudEvent： 一个新的CNCF Serveless产品，感觉可以关注下。

Kata: 对于公有云来说，docker在隔离性还有待提高，kata+firecracker的组合在性能与隔离的平衡上值得期待。

kubeEdge: Kubernetes在边缘计算场景下的一个产品，从个人而言很有兴趣，可惜和其他更高质量的分享重了。

AWS Workshop: AWS作为全球第一的云服务商，非常想去体验/熟悉一下他们的各种云产品，也为以后国际站使用AWS服务做调研/ 可惜没去。。。

后记

在这次Kubecon上不仅碰到了以前的老同学 CH同学 聊了许多在社区里contribute的机会，也遇到了很多之前在社区/Kubecon认识的老朋友，和华为云的架构师聊服务网格产品化，和惠普的工程师交流服务网格的实践应用，还遇到了以前的同事 磊哥 聊了最近的工作状况，最后还和ServiceMesher社区的成员来了一张宝贵的合影,可惜没管理好表情。

总体而言，参与Kubecon给我最大的体验就是非常的感动，站在2019年这个时间节点，云原生的整个Landscape逐渐清晰，作为这整个浪潮的参与者、分享者、实践者，个中滋味激动至极、难以言喻。