容器

本质：由Linux Namespace、Linux Cgroups和rootfs三种技术构建出来的进程的隔离环境
容器的视图
- 静态视图（Container Image）：一组联合挂载在/var/lib/docker/aufs/mnt上的rootfs
- 动态视图（Container Runtime）：由Namespace+Cgroups构成的隔离环境
开发人员并不关心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
  - 调用存储插件来为容器配置持久化网络

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