最近一个月大蕉断更了，主要就在做一些跟 k8s 相关的事情，就在昨天刚刚交付产品了一个版本，这几周几乎把大蕉榨干了。但是大蕉从来不是一个怕事的人，干就完了，一个当十个用，没什么大问题。
但是经过了几个月基于k8s写应用，我还是建议你别轻易尝试用 k8s ，这时候就有人问了，我看你前几个月还叫我们没事多学学 k8s 呢，为什么今天就说轻易别基于 k8s 写应用呢?
且听我细细说来。
基于 Docker 定义运行环境实在是太方便了，你可能没法像以前一样有一大堆的发布脚本排查发布环境的问题了。
这样线上环境太稳定，可能会裁剪一部分的开发运维人员。对于一个 Python 应用来说，以前我们需要安装 Linux，安装Python，安装 pip，安装相关的依赖库。可是对于 Docker 镜像定义方式 Dockerfile 来说。
- FROM python:3
- RUN pip install MySQL-python
这两行，Python 环境 和 MySQL 依赖就装好了，已经不需要害怕每个人的环境不一样，不需要害怕线上环境被谁搞坏了。运维可能会失业。
应用升级和回滚真的太方便了，你可能没法像以前一样搞一大堆的发布步骤。
加一个配置文件，换一个依赖包，升级一下linux内核版本，还要兼容一下。搞得每次发布都能由你自己搞。有了 k8s 你已经没这个机会了。这样你的价值会大大缩水。用 k8s 升级只需要这一行就够了。
- kubectl set image deployment your-app your-container=image:tag
这样 k8s 集群会对你的应用进行滚动升级，你不需要害怕升级的时候因为同时重启的问题导致服务不可用，它都帮你解决了。它升级的做法是先启动一个容器，确认这个容器正常服务了，再干掉原来的容器。
当然，发布出问题也是很常见的，以前的回滚要找发布包，回滚依赖，一堆事情做。现在有了 k8s ，回滚也变得简单起来。
- kubectl rollout undo deployment/your-app
回滚的步骤跟升级是一样的，会先启动原来镜像版本的容器，然后再干掉现在版本的容器。这一波操作，会导致你的存在感降低，你无法在发布的时候进行一顿疯狂操作了，很可惜，你很可能会被优化掉。
服务间暴露和调用真的太方便了，只能由你解决的调用 bug 可能一去不复返了。
想想这个场景，一个新人加入团队，面对代码里一堆的根据 ip 调用的逻辑，这个新人能怎么办呢?必然只能问你啊，这个 ip 是什么，另外一个 ip 又是什么?k8s 自带名字服务和负载均衡，如果只是在集群内调用，你终于不需要再用 ip + 端口的模式调用集群内的其他服务了，无论是 RPC 还是 HTTP 调用，都需要ip + 端口吧?很遗憾 k8s 集群默认并不会给你分配任何一个固定 ip 和端口，所有的 ip 和 端口都是动态分配的，你已经不能使用 ip 大法了。那么 k8s 是怎么做到的呢?
首先要明确一个 k8s 的 label 机制。我们俗称 label 名字叫 打标签，就是我会给我的应用(Deployment)打上一些标签，比如打一个标签名叫 app=my-app ，这个就类似给驴的脚底打上三颗痣。然后我再定义一个 Service ，不管这个应用长啥样，也不管它在哪里，只需要找标签为 app=my-app 的应用就完事了，就是说，无论你是剃光头还是留胡子，我都不管，我就找三颗痣，找到了你就是我的宠物。
很多很多的 magic ，等你你来发现，且听我细细说，如果你对 k8s 有兴趣，留言告诉我，我考虑写个实战系列。
如果你是靠各种邪术写魔法代码混职场的，我强烈建议你千万别用 k8s ，你很可能会混不下去。
