本篇文章给大家分享的是有关基于k8s的DevOps实践是怎么样的，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都网站设计、做网站、申扎网络推广、微信小程序开发、申扎网络营销、申扎企业策划、申扎品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供申扎建站搭建服务，24小时服务热线：13518219792，官方网址：www.cdcxhl.com
首先，我们从开发整个环节来看用户故事，思考如何将平台做的更简单。
DevOps开发阶段
从图上的开发过程，我们可以梳理出目前的需求主要包括：为服务解决方案、云开发平台、CI/CD、基于k8s的IaaS、可观察性、边缘计算、Serverless、DApp，我们最终确定了目前需要完成的4项核心功能，并确定了优先级：
CI/CD
基于k8s的IaaS
数据可视化
云开发平台
明确需求后，我们考虑过以上功能是否需要直接外采或自研。外采的好处在于可以快速部署，但实际研发过程中，我们只需要其中部分功能，“全家桶”的捆绑无法满足灵活自定义的需求，难以进行后续进一步演进开发。根据实际情况，我们最终考虑一步步自研完成。
在产品设计阶段，我们需要既能保证快速上线，同时满足后期局部的可修改性，我们为这个长期项目做了乐高式松耦合设计：
架构图
松耦合架构允许每一层只完成该部分的功能，最小化对上下的耦合度，保证局部修改对整个系统影响最小。例如：我们需要部署一个Prometheus监控，运维同学无需管理源码，我们只需要直接从配置开始进入部署，或者把镜像缓存到本地后开始部署。
在开始之前我们首先确定了Git工作流，我们考虑过主干开发，考虑到主客观条件以及我们的目标是让开发变成一件简单的事情，我们最终采用了如下图的开发流程。
CI/CD研发我们最初选用的是Jenkins。但是我们的Git用的是Bitbucket，初期用户体验并不是很好，而且部署的权限控制、账号体系都比较繁琐。为达到更好用户体验目的，我们现在开始尝试使用Bamboo研发CI/CD。
除了用户体验外，在使用Jenkins期间，Jenkinsfile前期的管理也比较粗糙，项目增多后分叉也变的很多，迭代和维护都很繁琐。为更好地管理Bamboo的配置，我们采用了Git子树，以达到方便升级的效果；同时我们也把执行动作脚本化，既确保差异管理又能脱离CI/CD体系，本地即可完成独立调试开发。
在整个实践过程中遇到的最大问题在于测试、测试推广以及快速构建各种集成测试环境。
测试推广更多的属于管理问题，研发可以涉及的主要在于：自动化生成一些测试和基镜，帮助项目快速补齐部分测试。
关于如何快速构建各种集成测试环境，我们使用Helm来部署每个项目。通过主Helm 包的依赖尽可能快速地构建关联环境。
环境构建只是开始，环境有了，我们需要测试它们，目前自动化测试最为合适。
如果这个过程有测试部门参与会简单很多，根据业务线和场景去做各个测试管理和维护。
在没有测试部门参与的情况下我们该怎么做？如果代码是同语言大仓库，这个问题也会很简单，只需进行关联回归即可。但是我们面临的现实情况是：一个cdn系统设计涉及各个组件各种环境和语言。我们的解决方式是把测试链条的各个环节落实到各自的项目上，谁开发谁负责原则。我们只管理关系链，做上线前回归。
在整个实践过程中遇到的最大问题在于测试、测试推广以及快速构建各种集成测试环境。
测试推广更多的属于管理问题，研发可以涉及的主要在于：自动化生成一些测试和基镜，帮助项目快速补齐部分测试。
关于如何快速构建各种集成测试环境，我们使用Helm来部署每个项目。通过主Helm 包的依赖尽可能快速地构建关联环境。
环境构建只是开始，环境有了，我们需要测试它们，目前自动化测试最为合适。
如果这个过程有测试部门参与会简单很多，根据业务线和场景去做各个测试管理和维护。
在没有测试部门参与的情况下我们该怎么做？如果代码是同语言大仓库，这个问题也会很简单，只需进行关联回归即可。但是我们面临的现实情况是：一个CDN系统设计涉及各个组件各种环境和语言。我们的解决方式是把测试链条的各个环节落实到各自的项目上，谁开发谁负责原则。我们只管理关系链，做上线前回归。
快速部署关联系统方案
很多开发者都会遇到多个项目开发环境的切换问题，例如：很多同语言的新老项目版本差异较大、需自定义环境设置；或者很多新人想要入手一个项目搭建开发环境就要耗费大量时间。
我们的原则是把开发变成一件很简单的事情。我们正在尝试使用Eclipse Che的工作空间管理的方式来管理项目开发环境，以降低开发门槛。Eclipse Che是一个开源的解决方案，这里不作过多介绍，感兴趣的朋友可以自己了解下。
产品的最终形态可能是什么样子？
目前按照目前的优先级，火箭右侧的4项核心功能是我们优先要做的。就像上面所说的松耦合架构有利于产品的局部迭代升级，局部的量变有可能带来产品的质变。
往前一步，我们需要做什么，才能更贴近用户？应该是微服务解决方案。
往后一步，我们需要做什么，才能更贴近云服务？目前能确定的是对标产品是容器云，那这个平台的卖点就是一个完整开发工具链的容器云。
关于边缘计算，作为IaaS层的k8s换成KubeEdge等或许我们产品就具备了边缘计算的能力。
如果区块链的DApp或是Serverless成熟的IaaS层的修改替换更容易让产品快速适应市场。
以上就是基于k8s的DevOps实践是怎么样的，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。