Kubernetes与Istio的实践与落地

白凡

分享：张夏
编辑：白凡

首先说一下容器落地的难点，在于容器化自身需要解决的问题，容器化服务跨机房容灾，提高计算资源的利用率，Docker化调试与问题的定位，数据如何更快更好地持久化，内核版本稳定性，隔离度与安全性。容器化迁移需要解决的问题。原业务微服务化转型，与公司原有系统对接，新配套如何快速更上，当前业务平滑无缝迁移，减少非技术因素影响。

我首先讲四个方面的内容，第一，基于Kubernetes的容器云建设。第二，利用JitlabCI/CD构建CI/CD。第三，基于Hehe应用发布/配置管理。第四，用ServiceMesh进行服务治理。

使用的技术，高可用/容灾：Haproxy-数据备份。
网络：Calico/Flannel。DNs：COREDNS。
Proxy模式：IPVS。
存储驱动模式：DIRECT-LVM。
CI/CD：GitabCI/CD on Kubernetes 。
服务编排：Kubernetes+HELM等等。
Service Mesh：Istio。
应用配置管理：Helm。
应用商店：应用HELM模板。

容器云的实践，镜像分层构建实践。
复杂容器服务编排。
服务质量保证实践。
代码与配置的分离。
四、七层的服务发现。
持续集成持续部署。
Istio服务治理实践。

构建Docker镜像最佳实践，预期是快速构建镜像，更快拉取镜像，节约存储空间。实践是使用微镜像，减少镜像层数。避免不必要的包安装。复用CACHE，使用VOLUME，清理YUM/APK CACHE。

用HELM部署与管理复杂KUBERNETES应用，K8S服务编排唯一开源资项目，K8S包管理工具。用于部署复杂K8S应用，处理复杂的服务间依赖。查看发布历史与某一次发布的具体配置。基于GO模板语言，实现应用快速部署到K8S集群。

1. 基于kubernetes的容器云建设

我们来看一下HELM很多公司用了很久的，我是在一年多前吧，大概一年半之前，看HELM，HELM其实引用它的背景，我之前想做一个配置管理，我希望对应用发布呢。

对应用可能发布多个版本，希望通过HELM看到历史发布的信息，一个应用发布了三次，第三次有问题，我需要回滚，不知道回滚第一次还是第二次，我需要查看的功能。如果用K8S我们知道，K8S文件描述自己的功能，很多让文件落地。

但是，文件并不难写，难写的K8S更新迭代，这个比较复杂，大家看到网上有很多的培训，培训两三天做不完，我在国内做了一次培训，2-3天培训不完。几乎关心自己的配置，开发关系到自己的文件，针对不同的业务或者是用到很多的K8S公司，让它能去不懂的语言可视化的方式，让他去看，在底层包起来，用户关心对K8S来讲，关系自己的镜像，或者是镜像的image所以把这个包起来，包在模板里面，通过模板配置的形式，把这个模板我们来维护，用户配置其实我们也维护，我们现在讲构成，大家可以看到，这个配置后来是我们自动生成的；

刚才提到配置之外，HELM还支持管理应用的发布，后面有一个例子可以看到。HELM还有一个非常重要的功能处理负责依赖。我们通过HELM模板知道，在公司推容器云，公司不太好推容器云，引入HELM开发工作量非常非常小，甚至开发题需要学习K8S的功能，把这个学习起来，开发成本和使用成本非常非常低。

这就是我们刚才提的，如果用K8S处理的话，处理依赖的话，K8S用INITCONANIER，或者POST STORT 、PRESTOP去做两个买点，比如说在升级的时候，无论是蓝绿或者是灰度，做的时候考虑升级服务一定不能影响现在正在正在提供的服务，我们可以通过买点做这个事情。

即使没有状态的服务，用UP DEED也是有上海的。我们看一下QOS，线下无所谓，预发布环境，线下环境，没有关系我们直接用K8S两个类型，可以提高自然利用率，但是一旦是我们线上环境，上容器化，新上经验不是很多的情况，建议都是用该容器的方式做，定额分配资源，不会造成资源竞争。

相对来讲的话，只要分配给资源，K8S集群统一调度，不会与资源竞争。我们看一下服务发现，环境变量注入的方式不太推荐，早期采用了LINUX环境变量方式，为每个SERVICE生成对应的LINUX环境变量，并在POD启动时，自动注入这些变量。

DNS我们推荐，通过ADD-ON方式引入DNS功能，通过把SERVICE NAME作为DNS域名，为了更简单把GUESTBOOK的例子摘出来的。大家可以看一下。

看一下七层服务发现，基于内部相互的去寻找另外一个服务，但是七层我们想集群外部，比如说容器化了，希望访问到别的容器服务，或者是别的集群服务，或者是我访问，或者外面的非容器内的想访问容器内部的服务，我只列的部分，简单来讲的话，公司用得比较多的，我也参加过很多的会，听过各公司的分享。（NODEPORT用的非常高的，LOADBALANCER用的不太高，我们这边用INGRESS没有用NGINX，但是性能比NGINX差一点。我们用1.6.4版本的时候，不支持加密，所以还是用了INGRESS，INGRESS相对更好一些。

自动化运维只是简单举一个例子，K8S做了很多自动化的事情，我们可以利用起来，举一个例子，拿DEPLOYMENT的例子讲，我们看一个服务正不正常，可以通过监控，POD的数量，配制好Probe探针LIVENESS与READNESS再通过简单的判断AVAILABLE的POD数量是否等于预期的即可，大大简化了运维与监控的成本。

2. 利用GITLAB CI/CD构建CI/CD

看第二部分，基于Istio做的。

其实目标很简单，希望能够CI/CD希望把公司的一些工具，比如说需要大中台，把工具能够串联起来，从提交代码开始，到最后发布能够串联起来，CI/CD干了这些事情.

这次选择Istio2.0，用了很长时间，这个不太好推，开发用起来，维持起来挺难的，相当于学习了另外一种语言这种傻瓜式怎么做，就是用Istio的来做。

这个用起来非常简单和方便，不是很熟悉的人两三天就可以学的，提供很多的模板，现在这个公司大面积推FCI，我们的业务很多，包括扩张非常厉害，几千人的规模，新业务老业务非常杂，把这些所有都谈了一遍，他们不需要做什么，提交代码就可以了，剩下的事情由我们来做。

接下来讲一下IstioCI-CD的过程，这个是开发提交代码，提交代码之后是非常粗略的，后面可以详细的，代码比如说做编译，打包，走各种测试，组建测试完了之后，预发布环节有流量的话，希望这个服务上线之前有审批，最后去发布，包括上生产环境。看下面这个图，是杰蛙的图，非常经典。

Istio主要做CI嘛，这个流程相对完整一点，但是不够完整，差得比较多，我们可以看一下，开发从提交代码之后，跑一些单元测试，代码风格检查，代码覆盖率，每个公司要求不一样，对代码的质量，有的公司要求代码覆盖率低于80%，有的90%，过了之后才可以往下走。前面单元测试这些代码覆盖率，代码扫描过了之后，可以看看下面再往下走的时候，我们开始关心镜像，其实前面还有编译打包，跟别的方式做的不一样，包是不存的，Istio管代码，代码不会丢。因为编译环境不丢，代码环境不丢，我可以随时随地弄一个包出来，存在镜像里面的，有镜像的名称，如果一旦线上有问题的时候，从后向前能够推导我们代码，和版本做结合。

这个是我们一个例子，做到一键式发布，开发提交代码，把镜像的名称，GITLAB都打到了刚才上面提的HELM包里面去，这里面都有关联，包括后面的经费，每一个业务线的经费，包括产品的后关联，我们从上面可以看到，我们想集群，第二图我们有多少数，版本里面选的那个其实就是我们用CI阶段自动构建起来的HELM包出来的，这个包并不是一个真正的含镜像的包，只是含镜像的GITLAB，还是在镜像中心里面，包括如果说我们做环境变量的替换到原来的配置的话，也是可以做的，这些都达到我们HELM包里面的。

3. 基于Helm应用发布/配置管理

部署需要选一点东西，需要选择测试集群或者是预发布集群，但是升级和回本更简单的，我们选了一次，比如说现在想做升级，那我们直接点击升级，选择对应的包的回本，都是CI/CD打出来的，回滚其实也是类型，因为采用HELM做的，有一个历史的的信息。这里面有一个小的问题，就是说，我们其实用HELM大家都知道，实际上我们没有HELM的顾虑，前面也提到的IDC环境并不是特别稳定，所以说就是不建议集群跨机房，一个集群只能在一个机房，基于这个结论之后，我们在比如说一个服务可能是说，这个服务高可用，可能只部署了一个机房，需要布多个机房，涉及多个集群，这种情况之后，无论是部署从升级回滚考虑一致性的问题。

第一个机房不成功的，第二个失败的，我们强制多回滚的状态。为什么呢？我们回滚第一个成功，第二个没有成功，第二个是没有rollback信息的，第三个有，然后把我简单说一下，他们做什么管理，做了一个开源HELM，我们用按照序列号激增的一个办法，把K8S部署得一堆文件包起来的，部署在一个地方。

大家可以看到，这个是具体服务，是我们上线的具体服务，发布了很多次，因为是新服务，做得不太好，所以总上线，总改，能有一个历史完整信息，可以看到发布这么多次，如果用HELM来看的话，有什么不一致，都可以看得到的。环境变量不一致，不需要自己关心的我们引用这一套方案之后呢，节约了成本，更简单了，不用考虑太多的事情，只关心自己的代码就可以了，既然服务网格的话，一定涉及到服务通信，所以Service mesh。

4. 使用serviceMesh做服务治理

为什么选择Istio，我从官网上英文的我自己翻译的，就是说这个功能是这样的。

我们可以了解一下，首先我们现在用的功能最常见的功能是什么？公司用GRPC这个功能，是我们最常用的，后面有一些实践基于GRPC做的。

我们有很多的路由算法，我们基于容器化的，我们也用了Servicemesh 做的。

另外还有一个是说，如果不写成这样子的，开发原来访问的，服务访问的时候，导致有一个问题，我们为了更好的和现在系统兼容的话，尽量少改，所以后面还有别的方案，通过端口进行区分。

就是说，通过集群的VIP前面提到有HA的，那么HA需要考虑到，HA我们用有一个集群VIP，所以VIP是多活这种情况导致我们每一个办法，

我们看一下好的环境服务发现，容器化的过程一定不是一天就完成了，有一些服务比较大的情况，公司业务比较大，可能两年做不完，有一个中间状态。

多集群POD调度，同一个集群内部，Kubernetes提供了非常丰富的调度策略，初期可以使用，Kubernetes提供了调度策略，后期可根本需求进行相关调度开发。同一个机房多个集群，采用调度的时候，业务通过指定要调度到的集群地址就可以。跨机房多个集群，分两种情况，同类型的业务，可以采用Kubernetes。

混合环境的流量分发相对来说比较复杂的，当时做的时候发现，通过销售人员做的，但是我们现在做的时候，改变了一种策略，多个Kubernetes。我讲的大概是这些。