前言
Kubernetes的种种好处我这里就不再赘述了，而我也在四年前就入了这个坑，最近两年也在公司不遗余力的推广，在中大型项目中推行落地，也专门依托k8s设计了产品。
这个专栏主要记录我在公司主导的产品以及项目中的k8s的落地实践情况，中间碰到的种种问题我也会挨个记录，希望对大家有所帮助，大家有什么相关的疑问，我们也可以友好讨论。
本篇主要讲一下我在公司第一个落地k8s的项目：某城市级智慧停车系统。
背景
记得是将近三年前，公司第一次承接了一个城市级停车项目，以前都是小打小闹，比如管委会的停车项目、高速上一个服务区的停车项目等等，这是第一次承接这么大的停车系统，整的也是十分忐忑，而且就当时公司的技术能力而言，接这种级别的系统，心里也是十分没底，主要担心如下几个方面：
- 人员能力问题。人员技术能力相对薄弱，是否能撑得起这么大的一个项目
- 技术债问题。公司当时的技术栈老旧，规范性差，没有良好的架构设计，贸然接这么大的项目，之后技术债积累下来，是否会压垮团队。
- 人员投入问题。就当时的情况看，多项目并行，这个项目来了，是否能保证人员投入，不会虎头蛇尾。
暂时就列这几个了，当时担心的远远不止上面这些，真要是铺开来说，一篇可行性分析就又出来了，反正就是各种顾虑，但是大家还是决定要接，毕竟要活下去啊，这么大个项目来了，岂有不接的道理！最后还是硬着头皮接了，虽说有种种担忧。
技术选型
其实没那么多冠冕堂皇的理由，赶鸭子上架式的选择了k8s，理由其实很简单，为了区分出我们跟别的厂商的不同以及先进性。我相信大家如果是在项目型的公司，这种赶鸭子上架的事儿也不会少了。
最开始只是从单体的springboot转到了springcloud，不瞒大家说，这个项目甚至是公司第一个完全上springcloud的项目，什么看起来先进就往上面堆，但是我的担忧也愈演愈烈。
再往后，springcloud已经不占优势，而且在日常使用上也出现了服务不稳定、数据库不稳定的问题，这个时候，我就提出了k8s这个东西，以前只是研究性的玩过，感觉这个东西绝对是个趋势，而且会引领变革，这个时候正好项目上要体现出差异，还要保证线上环境的稳定性，避免过多的人投入到后期的项目运维中，那就决定将springcloud部署在服务器上的服务，迁移到k8s上。
地基不稳必然在将来的某一天导致上层建筑的坍塌，但是迫于形势只能走一步看一步了。
实践验证
其实中间还有各种各样的问题，这里就不一一阐述了，只说最后的结果。我们最终还是把k8s上到了生产环境，并且还取得了不错的效果。 我们中间也碰到不少问题，比如实践经验少，只是照猫画虎，照着网上的文档搭建各种数据库集群，然后各种坑；对k8s不够熟悉，使用层面也是各种磕磕绊绊；本身k8s的部署问题等等，但最终都慢慢趟过来了。
实践经验
其实这个局点能上k8s还是有各种因素的叠加，比如后面我碰到的一些局点，在我们当前的技术能力下，基本就没法上，比如电网这些网络环境相当复杂的局点，我这边还没有对网络插件下手，这些局点上去也不敢说手拿把掐，而且他们的诉求还要跟边缘计算结合，那还得上kubeedge这类的，还要求有服务网格的相关内容，那就又要结合istio。所以这个停车项目的局点在现在来看，反而是最容易实践k8s的地方。 下面说几个在这个局点中实践的几个想法吧
- 存储问题。这个项目中其实用的是最简单的nfs存储，为什么没上ceph或者gluster这类看似更安全、更高端的存储方式。简单、高效、实用，这几个点是我最终关注的，这个项目中直接购买的云厂商的nas服务，安全性相对来说是有保障的，我也没必要再去自己搭建分布式存储环境，如果在那个阶段再扩存储这个方向的，团队技术债根本还不完了。
- k8s本身证书到期的问题。k8s本身的机制，证书一年需要更新一次，这个对我们来说，真的是坑，不过这个现在已经通过改源码的方式，随意修改证书过期时间了，这个方法在后续文章也会写。
结语
其实大家发现，这篇下来没讲什么干货，这篇文章算是这个系列的开篇，简单说下怎么入到这个坑里的，以及实践上的一些问题，后续的文章其实也不会跟其他文章一样，讲概念、将具体操作，反而会从实践的角度入手，讲下这几年的项目落地情况以及中间的坑，以及怎么去排掉这些坑的。
如果大家也是在做这些方面的工作，我们可以多做交流，k8s引领了云原生的潮流，而我也相信在后续的5-10年之内，大部分企业都会走上这条道路。
