在过去的一个月里，车前草被中断了。主要是在做k8s相关的东西。就在昨天，交付了一个版本的产品。在过去的几周里，几乎所有的大蕉都被榨干了。不过车前草从来都不是胆小的人，搞定就行，一当十，问题不大。但是基于k8s写了几个月的应用，我还是建议大家不要轻易尝试使用k8s。这时候有人问了，我看你几个月前就跟我们说要多了解k8s。为什么今天说容易？不会基于k8s写应用？详细听我说。基于Docker来定义运行环境真是太方便了。您可能没有很多发布脚本来像以前那样解决发布环境的问题。这样一来线上环境太稳定了，可能会裁掉一些开发维护人员。对于一个Python应用，我们以前需要安装Linux，安装Python，安装pip，安装相关的依赖库。但是对于Docker镜像的定义方法是Dockerfile。FROMpython:3RUNpipinstallMySQL-python这两行，Python环境和MySQL依赖都安装好了，不用怕每个人的环境不一样，不用怕有人把线上环境搞乱。操作和维护可能会失去工作。应用升级和回滚真的很方便，你可能无法像以前那样做很多发布步骤。添加配置文件，更改依赖包，升级linux内核版本，兼容。让每个版本都属于您自己。有了k8s，你就没有这个机会了。这会大大降低你的价值。用k8s升级只需要这一行。kubectlsetimagedeploymentyour-appyour-container=image:tag这样k8s集群就会对你的应用进行滚动升级。不用担心升级过程中因为同时重启的问题导致服务不可用。它会帮助你解决它。它的升级方式是先启动一个容器，确认容器正常服务，然后kill掉原来的容器。当然，发布出现问题也是很常见的。之前的回滚需要找发布包，回滚依赖，一堆事情要做。现在有了k8s，回滚也很容易。kubectlrolloutundodeployment/your-approllback的步骤与升级相同。会先启动原镜像版本的容器，然后杀掉当前版本的容器。这一波操作会降低你的存在感，发布时你将无法再疯狂操作。不幸的是，你很可能被优化掉了。服务之间的暴露和调用真的很方便，以前只能自己解决的调用bug可能就一去不复返了。想想这个场景，一个新人加入团队，面对代码中一堆基于ip调用的逻辑，新人能做什么？只能问你，这个ip是什么，另一个ip是什么？k8s有自己的名字服务和负载均衡。如果只在集群中调用，终于不用ip+port的方式调用集群中的其他服务了。不管是RPC还是HTTP调用，都需要ip+port？遗憾的是k8s集群默认没有给你分配任何固定的ip和端口。所有的ip和端口都是动态分配的，不能再用ip方式了。那么k8s是怎么做到的呢？首先，我们需要定义一个k8s标签机制。我们通常称之为标签，意思是我会在我的应用程序（Deployment）上打上一些标签，比如打上一个标签，名字叫app=my-app，这类似于在驴脚底上打三颗痣。然后我定义了一个Service，不管app长什么样，在什么地方，只要找到app=my-app标签的app就搞定了。也就是说，不管你剃光头还是留胡子，我都无所谓，我会找三颗痣，找到了你，你就是我的宠物。有很多神奇，等你去发现，听我详细说，如果你对k8s感兴趣，请留言告诉我，我会考虑写一个实战系列。如果在职场上靠着各种神仙写魔代码混，我强烈建议你千万不要用k8s，你可能混不进去。
