1、分层架构

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构

Nucleus（核心层）：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境；

Application（应用层）：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）；

Governance（管理层）：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）；

Interface（接口层）：kubectl命令行工具、客户端SDK以及集群联邦；

Ecosystem（生态系统）：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：

• Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等；
• Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等；

2、API设计原则

• 所有API应该是声明式的。
• API对象是彼此互补而且可组合的。
• 高层API以操作意图为基础设计。
• 低层API根据高层API的控制需要设计。
• 尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。
• API操作复杂度与对象数量成正比。
• API对象状态不能依赖于网络连接状态。
• 尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

3、API 对象

类 别	名称
资 源 对 象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、 CustomResourceDefinition
存 储 对 象	Volume、PersistentVolume、Secret、ConfigMap
策 略 对 象	SecurityContext、ResourceQuota、LimitRange
身 份 对 象	ServiceAccount、Role、ClusterRole

3.1、Pod

• pod是k8s中的最小单元
• 一个pod中可以运行一个容器，也可以运行多个容器
• 运行多个容器的话，这些容器是一起被调度的
• Pod的生命周期是短暂的，不会自愈，是用完就销毁的实体
• 一般我们是通过Controller来创建和管理pod的

3.2、Controller

• Replication Controller：副本控制器（selector = !=）
• ReplicaSet：副本控制集，和副本控制器的区别是：对选择器的支持（selector 还支持in notin）
• Deployment：比rs更高一级的控制器，除了有RS的功能之外，还有很多高级功能,，比如说最重要的：滚动升级、回滚等

3.3、Service

• 因为pod重建之后ip就变了，pod之间直接访问会有问题，所以不能以确定的IP和端口号提供服务；
• service解耦了服务和应用；
• 客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。
• 通过声明一个service对象来创建Service；

一般常用service的有两种：

• k8s集群内的service：selector指定pod，自动创建Endpoints
• k8s集群外的service：手动创建Endpoints，指定外部服务的ip，端口和协议

kube-proxy和service的关系：
kube-proxy监听着k8s-apiserver，一旦service资源发生变化（调k8s-api修改service信息），kube-proxy就会生成对应的负载调度的调整，这样就保证service的最新状态。

kube-proxy有三种调度模型：

• userspace：k8s1.1之前
• iptables：k8s1.10之前
• ipvs：k8s 1.11之后，如果没有开启ipvs，则自动降级为iptables

3.4、livenessProbe和readinessProbe

• livenessProbe：存活探针
  • 检测应用发生故障时使用，不能提供服务、超时等；
  • 检测失败重启pod，重启时访问流量依旧会发送给该pod；
• readinessProbe：就绪探针
  • 检测pod启动之后应用是否就绪，是否可以提供服务；
  • 检测成功，pod才开始接收流量；

3.5、Volume

• 数据和镜像解耦，以及容器间的数据共享
• k8s抽象出的一个对象，用来保存数据，做存储用
• 常用的几种卷：
  • emptyDir：本地临时卷
  • hostPath：本地卷
  • nfs等：共享卷
  • configmap: 配置文件

emptyDir

当 Pod 被分配给节点时，首先创建 emptyDir 卷，并且只要该 Pod在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入 emptyDir 卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir 中的数据将被永久删除。

hostPath

hostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中，pod删除的时候，卷不会被删除。

nfs等共享存储

nfs 卷允许将现有的 NFS（网络文件系统）共享挂载到您的容器中。不像 emptyDir，当删除 Pod 时，nfs 卷的内容被保留，卷仅仅是被卸载。这意味着 NFS 卷可以预填充数据，并且可以在 pod 之间“切换”数据。 NFS 可以被多个写入者同时挂载。

configmap: 配置文件

• 配置信息和镜像解耦
• 将配置信息放到configmap对象中，然后在pod的对象中导入configmap对象，实现导入配置的操作
• 声明一个ConfigMap的对象，作为Volume挂载到pod中

3.6、PV/PVC

• 实现pod和storage的解耦，这样我们修改storage的时候不需要修改pod，也可以实现存储和应用权限的隔离
• PersistentVolume 和 PersistentVolumeClai

PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。

PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载）。