k8s初步理解

从微服务架构来讲，多个独立功能内聚的服务带来了整体的灵活性，但是同时也带来了部署运维的复杂度提升，这时Docker配合Devops带来了不少的便利(轻量、隔离、一致性、CI、CD等)解决了不少问题，再配合compose，看起来一切都很美了，为什么还需要K8s？

可以这样理解：把微服务理解为人，那么服务治理其实就是人之间的沟通而已，人太多了就需要生存空间和沟通方式的优化，这就需要集群和编排了。Docker Compose，swarm，可以解决少数人之间的关系，比如把手机号给你，你就可以方便的找到我，但是如果手机号变更的时候就会麻烦，人多了也会麻烦。而k8s是站在上帝视角俯视芸芸众生后的高度抽象，他看到了大概有哪些类人(组织）以及不同组织有什么样的特点（Job、CornJob、Autoscaler、StatefulSet、DaemonSet…），不同组织之间交流可能需要什么（ConfigMap,Secret…）,这样比价紧密的人们在相同pod中，通过Service-不会变更的手机号，来和不同的组织进行沟通，Deployment、RC则可以帮组人们快速构建组织。Dokcer 后出的swarm mode，有类似的视角抽象（比如Service），不过相对来说并不完善。

pod是一个小家庭，它把密不可分的家庭成员(container)聚在一起，Infra container则是家长，掌管家中共通资源，家庭成员通过sidecar方式互帮互助，其乐融融～

云计算系统的操作系统是 k8s ，容器就相当于是其进程，而 Pod 则是进程组。
容器镜像是二进制可执行安装包

Pod 的另一个重要意义，容器设计模式，通过这篇里有了更深的认知，在迁移传统基于虚拟机的应用时起到了关键作用。
实际上是在扮演传统基础设施里"虚拟机"的角色；而容器则是这个虚拟机里的应用程序」。要完成传统基于虚拟机的应用到微服务架构的迁移，核心思想是：分析应用组成（组件、进程），将其拆分成松耦合的容器（以容器镜像方式分发），利用 Init Container 来解决顺序和依赖关系。

转载自：极客时间《深入剖析Kubernetes》