启航吧~水手！kubernetes漫画时间！

轻松一下~

源自：GKE漫画
别名：一个996程序员被同事折磨摸鱼时间做白日梦神游四海最后长出头发抵达人生巅峰的神奇故事

使用kubernetes丝滑航行，学习k8s以及怎么样使用它来进行持续集成（CI）和持续部署（CD）。没什么好说的，开门见山。

古代，人们和鬼神作战；而现在主人公小J的工作比对抗天神更难。。（手里的咖啡、浓密的胡子、杂乱的桌子上散落的指尖陀螺以及不知到为了遮盖什么而戴着的帽子，泪目。）

主人公小J就职于一家游戏公司，公司的MMO（大型多人在线游戏）很受欢迎，但是运维人员正在随着业务量的增长而痛不欲生！其中一名同事身残志坚，拖着受伤的腿还奋斗在一线。其中有一台服务器（贝茜）已经烧了，更是令他悲痛欲绝。主人公让他继续增加服务器来扩容。
P.S.
①服务器不是应该放在郊区机房里吗。
②这公司剥削劳动人民。

开发、测试、产品对他轮番轰炸。现在小J脑子里边只有一个想法，那就是报复社会（不是

此时，一个coser从80层楼的窗户翻进来了。并告诉小J，k8s能够解决他的问题。

他给小J说自己cos的是雅典娜，是容器之神，还说：“人生苦短，快用容器”！

然而小J说自己已经在用容器来部署应用了，但是管理容器还是很慢、效率低并且漏洞百出。。
coser说：“很好，使用容器是很成功的一步，但是你需要去编排那些小家伙，这就是k8s存在的意义”
此时漫画点题了，因为如果此时打开k8s官网，首先看见的就是
生产级别的容器编排，这就是k8s。

幻影移形之后，就来到了大概权力的游戏第二季的时候（能不能重拍第八季？？），此时单体应用正在统治着开发者，开发者们苦不堪言。（谁看见大屎球不得躲得远远的

单体应用有许多优点，但是各个模块紧密耦合（紧耦合是软件工程设计中要避免的），所以CI/CD的时候简直就是噩梦。将单体应用切割成各个小块，就构成了微服务架构。

微服务可以被单独的调试、升级和部署。部署的时候不需要停掉之前的服务（下线服务用户就无法访问，就不是高可用的系统，这也就是单体应用的弊端）。

coser对小J娓娓道来：“各个微服务之间是松耦合，仅仅用轻量级的协议使他们能够彼此通信，构成有一个系统即可”。

接下来coser向小J展示了后端部署的演变，总共分为三个阶段，裸机–>虚拟机–>容器。
P.S.
轻量和隔离就是容器的最大优势，这个演变过程也可以在Docker的官网找到。

此时coser化身容器技术布道者，滔滔不绝地对小J布道：模块化、互连性、可移植性、再生性和可扩展性。简直所有的好都被容器技术占了。
P.S.
事实也的确如此，容器发展到今天为止已经有将近二十年的历史，早已家喻户晓。而拥有谷歌背书的k8s也在击败swarm和mesos之后成为容器云的事实标准。

但是小J慌了，想想自己的猪队友，管理现在正在运行的容器尚且这么困难，怎么去随时随地的管理那么多容器across the world啊。此时coser说：使用k8s就好了。就这么简单。
P.S.
①k8s的logo的意思就是希腊语中的舵手，寓意着带领集装箱（容器）在海洋中航行。
②我接下来可能会写一篇k8s网络部分的分析，就叫《天空中的大海–我脑海中的k8s网络模型》。

由于k8s是谷歌研发的，小J怀疑coser是不是恰饭的。但coser连忙解（搪）释（塞）道：“k8s是开源的，你在全球最大的同性交友网站上也能看到”。

k8s有几个重要特征：
①最大化资源利用率
②弹性伸缩
③永远运行直到世界末日
并且最重要的是：“运维人员不用24小时待命，可以双休！！”

k8s添加了一个新的抽象层pod，就是用来抽象容器的，因为k8s根本不管你用的是什么容器运行时，是docker也好，是CRI.O也好，还是containerd也好，k8s不关心，因为k8s只认识pod，而pod就是用来隔离docker运行时的。（前一段时间k8s已经抛弃了docker，转向containerd，因为docker中有大量资源k8s用不到，造成资源浪费，也引入不稳定因素）。
P.S.
这个k8s的logo上长了个眼睛属实看的我SAN值狂掉。

大多数pod仅仅包含一个容器（因为pod就是对容器的一层抽象嘛），但是有些紧耦合的容器会共享一个pod，他们通过pause（也是一个容器）共享网络栈和数据卷。并且说明了node的概念，node有时也成为worker，其实就是一台物理server。
P.S.
YZ容器过于紧密，以至于C容器让他们get a room。。

这些node都被master掌控。

管理这些容器只需要把容器运行的期望填写进deployment（一个YAML格式的文件，只是controller-manager其中的一种）就可以了。

填写完成之后k8s就会调度机器、拉取镜像、部署容器。这一切操作，就只需要填写自己需要什么就可以完成了。（真的精妙）

此时coser问小J：你想选择哪种主板型号？哪种Linux发行版？Ubuntu？CoreOS？Debian？在犹他州部署吗？你的IP地址想要设置成多少？小J愤怒了：我tm的根本就不在意，随你的便，我只要get things done就OK了。coser：就是这样。

这就是k8s设计优美的地方，他将许多基础设施都抽象出来（cpu、ram），一视同仁。

所有由同一个镜像运行出来的容器都是相同的可以替换的，可以在任何机器上被拉起，被杀死。

k8s会将容器调度至对的地方（通过调度策略：默认调度规则、亲和性、污点、容忍）。

即使有pod死亡，也不至于导致单点故障，k8s会检测到实际运行的情况与期望不符而重新将pod拉起，保证系统的高可用。

这既是k8s的自愈功能，k8s会上了发条般地疯狂地一刻不停地比对真实情况和期望情况。

一旦有pod状态不对，k8s会将pod杀死并重新拉起，零容忍。

小J问道：那更新呢？？（。太真实了，听说服务上线的时候大家都沐浴、更衣、上香。。不知道是不是真的😂）
coser答：“k8s是滚动更新，起来一个新版本pod再杀死一个老版本pod，让pod数量时刻保持一致，以实现滚动更新”。（k8s还支持回滚）

使用service匹配label来管理后端的pod。
P.S.
此处的service要实现服务发现和负载均衡。k8s发展至今经历三个阶段。
①userspace模式，穿透kube-proxy来实现，效率较低，已弃用。
②iptables模式，通过更改Linux内核中的netfilter中的表来实现负载均衡，不需要穿透，但是负载均衡算法近支持RR轮询，效率一般，将来的k8s版本将会抛弃使用。
③ipvs模式，原理和iptables规则类似，只是是使用ipvs模块来操作内核。效率很高。

k8s日日夜夜运行，高可用。

震惊！小J穿越一趟头发竟然回来了？？

黄粱一梦，还是熟悉的工位。
此时coser露出史上最鸡贼的公司Google的丑恶嘴脸向小J推销GKE（国外有AWS、Azure、Linode,国内有阿里云、腾讯云、华为云都支持直接部署k8s集群）。
并向他说明十分钟能部署好。
P.S.
国内的网络环境至少十年。

纯属娱乐。
看的开心就好。