Pod概念
pod是k8s的基本调度单元 pod扮演的是传统部署环境中的虚拟机角色 容器扮演的运行在虚拟机中的用户进程
由一个或多个容器组合在一起得共享资源
共享存储 如Volumes卷
网络 唯一的集群IP地址
每个容器运行的信息 例如:容器镜像版本
Pod对象字段
NodeSelector 提供用户将Pod与Node进行绑定的字段 Pod只能运行在满足NodeSelector的节点上 否则会调度失败
NodeName 一旦Pod的这个字段被赋值 k8s就会被认为此Pod已经通过了调度 调度的结果就是赋值的节点名字(可以用来调试)
HostAliases 定义Pod的hosts文件(/etc/hosts) 里面的内容
凡是跟 Linux Namespace相关的属性 都是Pod级别的
Init Containers字段
Init Containers的生命周期 会先于所有的Containers 并且严格按照定义的顺序执行
Containers字段
ImagePullPolicy 拉取镜像的策略方式
Lifecycle 容器状态发送变化时触发的钩子操作
postStart 在容器启动后立即执行的一个操作 和容器的ENTRYPOINT命令是异步执行的 postStart启动时候ENTRYPOINT有可能并没有执行完
postStart 执行失败该pod也会处于失败状态
preStop 容器被杀死之前执行 preStop操作是同步执行的 它会阻塞当前容器的杀死流程 直到preStop执行完毕才能运行容器退出
Pod的生命周期
Pending Pod的YAML文件已经提交给k8s API对象已经保存到etcd中 但是Pod中的某些容器还没有被创建
Running Pod已经被成功调度 包含的容器都已经被创建 并且至少有一个容器正在运行
Succeeded Pod中所有的容器都已经正常运行完毕并且已经退出（一次性任务）
Failed Pod中至少有一个容器以不正常的状态(非0的返回码)退出
Unknown 意味着Pod的状态不能持续的被kubelet汇报给apiserver(可能是主从节点通信问题)
Ready和Running的区别 Running 只代表容器自身的进程是正常运行的 但不能表示容器中提供服务的主进程是正常的(nginx返回500)等
Pod的Volume类型
投射数据卷(projected)
Secret 把pod想要访问的加密数据存储在etcd中 通过pod中的容器以挂载volume的方式来访问
这些保存在etcd里面的信息会以文件的方式出现在容器的volume目录中一旦etcd中的数据发生变化volume里面的内容也会被自动更新
而这个文件的名字,就是 kubectl create secret 指定的 Key,或者说是 Secret 对象的data字段指定的 Key
由kubelet组件定时进行维护 所以这些内容的更新可能会有一定的时延 需要有重试和超时处理机制
configMap
明文存储配置文件信息
Downward
获取宿主机和Pod本身的一些属性信息 downwardApi能够获取到的信息一定是Pod里面的容器进程启动之前就能够确定下来的信息
pod里容器运行后才能出现的信息就不能被获取到了 这种情况要获取可以用sidecar容器来获取相关信息
serviceAccountToken
apiserver访问授权信息
Service Account介绍
是k8s系统内置的一种服务账户 它是k8s进行权限分配的对象
service Account的授权信息和文件实际上保存在它所绑定的一个特殊的Secret对象中 这个特殊的Secret对象就叫做ServiceAccountToken
k8s在每个pod创建的时候 自动在它的spec.volumes部分添加了默认的ServiceAccountToken定义然后给每个容器加上对应的volumeMounts字段
Pod中的容器固定路径的授权文件路径 /var/run/secrets/kubernetes.io/serviceaccount
容器健康检查和恢复机制
restartPolicy 它是Pod的Spec部分的一个标准字段(pod.spec.restartPolicy)默认值是 Always即:任何时候这个容器发生了异常它一定会被重新创建
Kubernetes中并没有Docker的Stop语义,所以虽然是 Restart(重启) 但实际却是重新创建了容器
kubelet会根据这个探针的返回值来决定这个容器的状态 而不是直接以容器是否运行(Docker返回的信息)做为是否健康的依据
pod的恢复机制是重新创建一个新容器 而不是重启一个容器
pod一旦与某个宿主机进行了绑定 默认就不会离开这个节点 哪怕这个节点已经宕机了
如果需要在节点宕机后使pod自动切换到其它节点 就必须使用pod控制器(Deployment)来管理pod 这就是单纯的pod和控制器管理的pod的区别
livenessProbe探针
exec shell命令
httpGet
tcpSocket
livenessProbe的检查结果 影响的是Pod的生命周期 会导致Pod里面的容器发生异常时候自动重新创建新的容器 Pod的恢复策略
readinessProbe探针
语法和livenessProbe一样 但是作用却不一样 readlinessProbe检查出的结果成功与否 决定着这个Pod能否通过Service的方式被访问到
而不影响Pod的生命周期
Pod通过设置restartPolicy改变Pod的恢复策略.除了Always还有OnFailure和Never两种情况:
1.Always：在任何情况下只要容器不在运行状态,就自动重新创建一个新的容器
一个Pod它只计算1+1=2计算完成输出结果后退出变成Succeeded状态.这时,你如果再用restartPolicy=Always强制重启这个Pod的容器就没有意义
2.OnFailure: 只在容器异常时才自动重启容器
3.Never: 从来不重启容器
如果要关心这个容器退出后的上下文环境比如容器退出后的日志,文件和目录.就需要将restartPolicy设置为Never.因为一旦容器被自动重新创建,这些内容就有可能丢失掉了（被垃圾回收了）
Pod显示状态的原则
1.只要Pod的restartPolicy指定的策略允许重启异常的容器(比如:Always)那么这个Pod就会保持Running状态,并进行容器重启.否则Pod就会进入Failed状态
2.对于包含多个容器的Pod只有它里面所有的容器都进入异常状态后Pod才会进入Failed状态.在此之前Pod都是Running状态此时Pod的READY字段会显示正常容器的个数
Pod预设置
可以首先创建一个PodPreset的对象 然后通过selector选中相关Pod的定义 在创建Pod对象的时候自动把两者的字段进行合并
PodPreset只会影响被创建出来的pod实例 并不会影响创建pod的各种控制器的定义(Deployment)
k8s一切皆对象
1.应用抽象成Pod对象
2.应用的配置抽象成ConfigMap对象
3.应用要访问的密码抽象成Secret对象
4.Pod进行批量化,自动化修改的工具对象抽象成PodPreset对象
Node资源对象
Node是Kubernetes中的工作节点,可以是虚拟机或物理机.每个Node由Master管理Node上可以有多个pod,Kubernetes Master会自动处理群集中Node的pod调度,同时Master的自动调度会考虑每个Node上的可用资源
Node上运行的进程：
1.Kubelet
Kubelet管理Kubernetes Master和Node之间的通信管理机器上运行的Pods和containers容器
2.container runtime (如Docker,rkt)
3.kube-proxy 监视的service创建和变化 动态创建Node上面的iptables规则