kubernetes学习实践(五)-kubernetes的本质

经过前面四章的学习,我们了解了容器,一个正在运行的Linux容器,可以分为两个视角来看:

  • 容器的静态视图:一组联合挂载在/var/lib/docker/aufs/mnt/上的rootfs,即容器镜像。
  • 容器的动态视图:一个由Namespace+Cgroups,构成的隔离环境,即容器运行时。

作为一名开发者,并不关心运行时的差异,因为在整个“开发-测试-发布”的流程中,真正承载着容器信息进行传递的,是容器镜像,而不是运行时。

用户需求

现在我有了应用的容器镜像,需要在指定的集群上把这个应用运行起来。提供如:路由网关,水平扩展,监控,备份,灾难恢复等运维能力。当然这是经典PaaS的能力。如果kubernetes仅仅是停留在拉取用户镜像,运行容器,以及以上能力,跟经典PaaS相比并没有任何优势。

kubernetes架构

kubernetes学习实践(五)-kubernetes的本质_第1张图片
由master和node两种节点组成,分别对应控制节点和计算节点。

控制节点,master由三个紧密协作的独立组件组合而成,分别是:

  • 负责API服务的kube-API server
  • 负责调度的kube-scheduler
  • 负责容器编排的kube-controller-manager

整个集群的持久化数据,则由kube-API server处理后保存在Etcd中。

在kubernetes项目中,kubelet主要负责同容器运行时(如:docker等)进行交互。

kubernetes对交互的抽象

kubernetes不关心你部署的是什么容器,并且定义了容器调用的规范

  • CRI(Container Runtime Interface),kubelet与Container Runtime交互的规范,定义了容器运行时的各项核心操作,如:启动一个容器的所有参数等。
  • gPRC协议,在kubernetes中作为kubelet与Device Plugin交互的规范,进行宿主机物理设备管理的组件。
  • CNI(Container Networking Interface),kubelet与Networking交互的规范,调用网络插件,配置容器网络。
  • CSI(Container Storage Interface),kubelet与Volume Plugin交互的规范,调用存储插件,配置持久化存储。

kubernetes解决任务与任务之间的关系

任务与任务之间往往存在各种各样的关系,如:一个web应用与数据库之间的访问关系,一个负载均衡器和它的后端服务之间的代理关系,一个门户应用与授权组件之间的调用关系。
经典PaaS处理关系的粒度是粗的,是一个VM级别的,是依靠手工运维的。

Pod

pod中的容器共享同一个namespace,同一组数据volume,从而达到高效率交换信息的目的。

//todo

你可能感兴趣的:(kubernetes,Docker)