从微服务架构来讲,多个独立功能内聚的服务带来了整体的灵活性,但是同时也带来了部署运维的复杂度提升,这时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》