在较为彻底地理解了Docker原理后，我曾经天真地以为再花差不多的时间就可以同样掌握k8s。直到我看到一张k8s的核心概念关系图：
Docker只是其中粉红色的那一小块（Container）的一部分。。。
我也曾考虑过按照我的理解总结k8s优于Docker Swarm之处，以及为什么k8s能赢下容器编排大战。但很快发现这意味着我还需要先去熟悉Docker Swarm，才能较为准确地进行分析。这又何苦呢？我们已经知道了结论：Kubernetes是容器编排之战的最终战胜者。就算Docker Swarm有再多的优点，我们也不会采用。
我还考虑过类似Docker系列那样，先从原理开始整理。但k8s涉及的原理范围更广，从各种存储介质到OSI七层原理，先研究透再写的话估计还得花一个月。
所以我们跳过枯燥的原理介绍，先进行最有趣的实战环节，做一个包含接近完整功能的POC（Proof of Concept，概念验证）。在POC的过程中，我们再来逐渐熟悉k8s的架构设计和原理。
POC目标
我们的目标是把现在基于虚拟机的部署方式和基于脚本的打包方式，尝试用Docker容器+Kubernetes实现。
部署的时候还需要考虑：
- 服务高可用
- 节点扩展与收缩
- 安全性
- 与代码版本管理平台（Gitlab）和持续集成系统（Gitlab CI/Jenkins）的整合
- 多版本应用维护
- 日志收集
- 监控
- 数据备份
- …其他等等
下面是一个我们当前应用架构的精简版：
- Spring Boot（Java）应用作为后端，暴露接口地址供集群外的App调用。应用高可用部署。
- Nginx上同时host了WebPack打包的静态网站。静态网站也会调用Java应用的接口。Nginx高可用部署。
- Spring Boot应用也同时调用后台的MySQL数据库。MySQL数据库的物理部署架构为Master-Slave形式。Master写入，Slave读取。MySQL的数据库进行每日的全量备份到指定外部硬件存储上。
- Java应用的日志汇总到Elasticsearch中存储，并可通过kibana查看。
- 网络上，集群外可以访问静态网站，Java应用的接口，kibana页面。可以通过工具查询MySQL中的数据。
POC相对实际部署架构的调整：
- 暂时省略了Node.JS后台应用。
- 数据库暂时省略了MongoDB，并用MySQL替换了Oracle。
- 暂时省略了Spring Cloud的注册中心和配置中心。
- 代码版本管理平台/持续集成系统/Maven私服等服务暂时不部署在集群内，使用外部已有的实例。
- 暂时省略了Redis缓存和消息队列（RabbitMQ）。
- 暂时省略了ETL（Kettle）。
使用上一章中搭建完成的单主k8s集群进行部署。
POC中的一个原则
我们在POC及后续实际使用Kubernetes的过程中需要保持一个原则：只通过YAML修改Kubernetes对象。
换句话说，我们尽量避免像以往的运维那样，直接进入虚拟机进行操作。这样的操作是无法记录，不透明的。有可能我们下一次想部署同样的环境的时候遗漏了某个步骤，导致最终部署失败。即使我们写了操作手册也不能确保文字表达不会产生歧义。而YAML定义是透明且不会产生歧义的，且可以通过版本控制追溯历史的。
这也是我为什么会相信Kubernetes是未来的趋势的原因之一：以前的运维经验像口耳相传的秘笈，而未来基于Kubernetes的运维就是使用YAML编程。零散的运维知识点通过Kubernetes被整合成了体系化的知识。配合封装了底层各种优化的公有云，培训出一个合格运维的成本会大大降低。
以前有些中小公司中，只有某个老资格的运维对服务器了如指掌，即使工作态度很差也不敢换人。但Kubernetes化运维时代，只需要部署的YAML配置在，交接时间会大大缩短。（当然网络、底层硬件和存储之类的依然需要不少时间交接。另外还有无法Kubernetes化的Windows服务器）
Serverless和FaaS（Function as a Serivce）技术最近也火热发展中。或许以后都不需要运维了，开发只需要直接向云Kubernetes直接提交业务函数即可。不过目前这些技术还处于探索阶段。
这对运维来说不能说是一个利好消息。但不跟上这个潮流的话，就只有等着被历史的车轮碾过淘汰。
当然上述只是我理想中的情况。现实永远是一个泥潭，会逼得我们做各种dirty workaround。但只要愿景是美好的，我们终能一步步接近。
好了，我们开始吧。