Kubernetes -- 架构 & 设计思想
容器
- 本质:由Linux Namespace、Linux Cgroups和rootfs三种技术构建出来的进程的隔离环境
- 容器的视图
- 静态视图(Container Image):一组联合挂载在
/var/lib/docker/aufs/mnt
上的rootfs - 动态视图(Container Runtime):由Namespace+Cgroups构成的隔离环境
- 静态视图(Container Image):一组联合挂载在
- 开发人员并不关心Container Runtime的差异,因为承载容器信息进行传递的,是Container Image
Kubernetes
架构
- 角色:Master(控制节点)、Node(计算节点)
- Master
- kube-apiserver:负责API服务,整个集群的持久化数据,由kube-apiserver处理后保存在Etcd中
- kube-scheduler:负责调度
- kube-controller-manager:负责容器编排
- Node:kubelet,为最核心的组件
- CRI,Container Runtime Interface
- 主要负责与Container Runtime打交道
- 只要Container Runtime能够运行标准的Container Image,就可以通过CRI接入到Kubernetes
- Kubernetes并没有把Docker作为整体架构的核心,而Docker仅仅只是最底层的Container Runtime的实现
- OCI,Open Container Initiative
- 具体的Container Runtime(如Docker)与底层的Linux进行交互
- OCI请求 –> Linux的系统调用(如Namespace、Cgroups等)
- 通过gRPC协议与Device Plugin进行交互
- Device Plugin:用来管理GPU(机器学习)等宿主机上的物理设备
- CNI,Container Networking Interface
- 调用网络插件来为容器配置网络
- CSI,Container Storage Interface
- 调用存储插件来为容器配置持久化网络
- CRI,Container Runtime Interface
设计思想
- Pod
- Pod是Kubernetes中最基础的一个对象
- Pod里面的容器共享同一个Network Namespace、同一组数据卷,从而达到高效率交换信息的目的
- Service
- 容器的IP地址等信息是不固定,给Pod绑定一个Service,Service声明的IP地址等信息是终生不变的
- Service的主要作用:作为Pod的代理入口,代替Pod对外暴露一个固定的网络地址
- 声明式API
- 通过一个编排对象(如Pod、Job、CronJob等),来描述你试图管理的应用
- 为编排对象定义一些服务对象(如Service、Secret、Horizontal Pod Autoscaler等),会负责具体的平台级功能
- 编排对象和服务对象都是Kubernetes的API Object
参考资料
All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.