前段时间读了容器与容器云一书，很大的篇幅写了docker这部分，都是与linux知识相关，尤其是linux内核调度等。虽然有点linux基础，但这部分还是读的很艰难，读完之后很快到了k8s的部分。算是理清了docker与K8s在学习上的一些关系。
Docker更偏向底层，K8s通过OCI来调度各类容器，不局限于docker，甚至包括其他容器rkt、containerd等。但是了解基本的docker与底层linux的cgroup、namespace、network、volume的关系，以及docker容器镜像的知识，有助于理解后续k8s的隔离、限制、数据卷挂载等内容。

感悟-1

实际上k8s的推出，只是把docker等容器作为基底，而k8s真正的威力在于上层的调度、编排，把一系列容器的散兵游勇整合编排成为高可用、弹性的生产级别的系统。
OReilly对2020新技术的预测中提到了K8S，其中几句印象深刻：”云原生设计是一种思考软件和架构的新方法。但是向云原生的转型不仅影响了软件架构，而且也影响了基础设施和运维。它利用了新的设计模式（微服务），同时改良了现有技术（服务编排），从而在所有环境（云或本地环境）中实现了类似云的弹性和适应性。“
能达到与公有云弹性扩展相提并论的地步，并且能够部署在任意地方，可想而知K8S在2018-2020这两年的增速有多快。

总结

要真正发挥容器技术的实力，你就不能仅仅局限于对 Linux 容器本身的钻研和使用。这些知识更适合作为你的技术储备，以便在需要的时候可以帮你更快地定位问题，并解决问题。而更深入地学习容器技术的关键在于，如何使用这些技术来“容器化”你的应用。

比如，我们的应用既可能是 Java Web 和 MySQL 这样的组合，也可能是 Cassandra 这样的分布式系统。而要使用容器把后者运行起来，你单单通过 Docker 把一个 Cassandra 镜像跑起来是没用的。

要把 Cassandra 应用容器化的关键，在于如何处理好这些 Cassandra 容器之间的编排关系。比如，哪些 Cassandra 容器是主，哪些是从？主从容器如何区分？它们之间又如何进行自动发现和通信？Cassandra 容器的持久化数据又如何保持，等等。

这也是为什么我们要反复强调 Kubernetes 项目的主要原因：这个项目体现出来的容器化“表达能力”，具有独有的先进性和完备性。这就使得它不仅能运行 Java Web 与 MySQL 这样的常规组合，还能够处理 Cassandra 容器集群等复杂编排问题。