1.POD容器组
在Kubernetes中， pods是能够创建、调度、和管理的最小部署单元，是一组容器的集合，而不是单独的应用容器
同一个Pod里的容器共享同一个网络命名空间， IP地址及端口空间。
从生命周期来说， Pod是短暂的而不是长久的应用。 Pods被调度到节点，保持在这个节点上直到被销毁。
1）容器分类
Infrastructure Container： 基础容器
用户不可见，无需感知
维护整个Pod网络空间
InitContainers：初始化容器，一般用于服务等待处理以及注册Pod信息等
先于业务容器开始执行
顺序执行，执行成功退出（ exit 0），全部执行成功后开始启动业务容器
Containers：业务容器
并行启动，启动成功后一直Running
2）容器基本组成
镜像部分：
镜像地址和拉取策略
拉取镜像的认证凭据
启动命令：
command：替换docker容器的entrypoint ARGS：作为docker容器entrypoint的入参
计算资源：
请求值：调度依据
限制值：容器最大能使用的规格
3）重启策略
定义 Pod 或工作负载时，可以指定 restartPolicy，可选的值有：
Always：默认值，只要退出就重启 OnFailure：失败退出时（exit code 不为 0）才重启 Never： 永远不重启
restartPolicy 作用于 Pod 中的所有容器。kubelete 将在五分钟内，按照递延的时间间隔（10s, 20s, 40s ...）尝试重启已退出的容器，并在十分钟后再次启动这个循环，直到容器成功启动，或者 Pod 被删除。在控制器Deployment/StatefulSet/DaemonSet 中，只支持 Always 这一个选项，不支持OnFailure和Never选项。
4）健康检查
分命令行形式、httpGet请求方式以及TCPSocket方式
业务探针（ReadinessProbe） 当Pod处于就绪状态时，负载均衡器才会将流量打到这个Pod，否则把流量从这个Pod上面摘除 存活探针（LivenessProbe） 如果一个 Pod 被探测到不处于存活状态，则由上层判断机制来处理，如果上层配置重启策略为restart always的话，Pod 就会被重启
健康检查的结果分为三种：
Success，表示 container 通过了健康检查，也就是 Liveness probe 或 Readiness probe 是正常的一个状态； Failure，表示 container 没有通过健康检查。针对 Readiness probe，service 层就会将没有通过 Readiness probe 的 pod 进行摘除，不再分发请求到该 Pod；针对 Liveness probe，就会将这个 pod 进行重新拉起，或者是删除。 Unknown，表示当前的执行机制没有进行完整的一个执行，可能是因为类似像超时或者像一些脚本没有及时返回，此时 Readiness probe 或 Liveness probe 不做任何操作，会等待下一次的机制来进行检查。
5）外部输入
POD可以接收的外部输入方式：环境变量、配置文件以及密钥
环境变量：使用简单，但一旦变更后必须重启容器
Key-value自定义 From配置文件（configmap） From密钥（Secret）
以卷形式挂载到容器使用，权限可控。
配置文件（configmap） 密钥（secret）
配置文件（ ConfigMap）及密钥（ Secret）大小不能超过1M，Secret有类型区分，不同类型有不通校验方式，输入的value需Base64加密
6）持久化存储
主机hostpath
必须要求POD调度到固定节点上
云存储
多类型选择，如云硬盘、文件存储、对象存储等
不用担心POD迁移
PV/PVC
PersistentVolume（PV）是集群中由管理员配置的一段网络存储。 它是集群中的资源，就像节点是集群资源一样。 PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。 此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。
PersistentVolumeClaim（PVC）是由用户进行存储的请求。 它类似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。
7）服务域名发现
dnsPolicy： Pod内域名解析的策略
ClusterFirst：使用kube-dns作为域名解析服务器 Default：使用节点（ kubelet）指定的域名服务器解析域名 ClusterFirstWithHostNet：当Pod使用主机网络部署时使用
2.工作负载
1）工作负载ReplicaSet
ReplicaSet用于解决pod的扩容和缩容问题。
通常用于无状态应用
2）工作负载Deployment
Kubernetes Deployment提供了官方的用于更新Pod和Replica Set（下一代的ReplicationController）的方法，您可以在Deployment对象中只描述您所期望的理想状态（预期的运行状态），Deployment控制器为您将现在的实际状态转换成您期望的状态;
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务，恢复上线任务，回滚到以前某一版本（成功/稳定）Deployment等功能，在某种程度上， Deployment可以帮我们实现无人值守的上线，大大降低我们的上线过程的复杂沟通、操作风险。
Deployment的典型用例：
使用Deployment来启动（上线/部署）一个Pod或者ReplicaSet
检查一个Deployment是否成功执行
更新Deployment来重新创建相应的Pods（例如，需要使用一个新的Image）
如果现有的Deployment不稳定，那么回滚到一个早期的稳定的Deployment版本
3）工作负载StatefulSet
StatefulSet—有状态应用
用于解决各个pod实例独立生命周期管理，提供各个实例的启动顺序和唯一性
稳定，唯一的网络标识符。
稳定，持久存储--StatefulSet:每个pod对应一个pv
有序的，优雅的部署和扩展。
有序，优雅的删除和终止。
有序的自动滚动更新。
4）工作负载DaemonSet
DaemonSet能够让所有（或者一些特定）的Node节点运行同一个pod。当节点加入到kubernetes集\群中， pod会被（ DaemonSet）调度到该节点上运行，当节点从kubernetes集群中被移除，被（ DaemonSet）调度的pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。
在使用kubernetes来运行应用时，很多时候我们需要在一个区域（ zone）或者所有Node上运行同一个守护进程（ pod），例如如下场景：
每个Node上运行一个分布式存储的守护进程，例如glusterd， ceph
运行日志采集器在每个Node上，例如fluentd， logstash
运行监控的采集端在每个Node，例如prometheus node exporter， collectd等
5）工作负载Job
分为普通任务job和定时任务Cronjob
一次性执行，非阻塞
适合CI，视频解码，基因测序等业务
3.自定义资源CRD（CustomResourceDefinition）
用户可自定义资源模型，可扩展型强
需要实现自己的controller进行自定义资源的管理
4.POD与服务的关系
1）Service
Service定义了pods的逻辑集合和访问这个集合的策略。 Pods集合是通过定义Service时提供的Label选择器完成的
Service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理
Service的抽象使得前端客户和后端Pods进行了解耦
支持ClusterIP， NodePort以及LoadBalancer三种类型
Service的底层实现有userspace、 iptables和ipvs三种模式
Service类型： ClusterIP、 NodePort、 LoadBalancer
2）Ingress
Ingress基于service实现7层路由转发能力