Pod控制器 :
RC : 只能选择一个标签
RS : 集合式标签选择器. 可以选择多个Pod标签
Deploy :
DaemonSet
Job
CronJob
StatefulSet
自定义调度器
1.9 版本之前. 控制器删除后 pod 会接着运行. 1.9 之后 控制器删除之后 pod会一并删除
通过修改 kubectl —cascade=false 取消这个默认特性
Job : 批处理调度 一批工作项(work item)
监控pod是否成功的运行或终止
根据Pod的状态给 Job 设置重置的方式及次数
处理依赖关系. 保证上一个任务运行后再运行下一个
控制任务并行. 根据并行度确保Pod运行过程中的并行次数和总体完成大小
四种批处理job模式
| job template expansion | 一个job对应一个 work item |
| queue with pod per item | 采用一个任务队列存放work item. 一个job对象作为消费者区完成work . job会启动 n个pod 一个pod对应一个work item |
| queue with variable pod coun | 同采用任务队列存放 work item . job启动的pod数量是可变 |
| single job with static work assignment | 一个job产生多个pod . 采用静态方式分配任务 |
queue with pod per item
queue with variable pod coun
K8S的三种job类型
| Non-parallel jobs | 一个job只启动一个pod . 除非pod异常才会重启该pod 一旦pod正常结束. job结束 |
| parallel jobs with a fixed completion coun | 并行job会启动多个pod. 需要设定job的 .spec.completions参数为一个正数. 正常结束的pod数量达到此设定值后.job结束. .SPEC.PARALLELISM 用来控制并行度 即启动几个job来处理work item |
| parallel jobs with a work queu | 任务队列方式并行 . 不能设置 .spec.completions 此时 job有以下特性 每个pod 都能独立判断决定是否还有任务需要处理. 如果某个pod正常结束. job不会再启动新的pod 如果一个pod成功结束. 此时应该不存在其他pod还在工作的情况. 他们都应该处于即将结束.退出的状态 |
Cronjob :
minutes hours dayofmonth month dayofweek year 配置在yaml的 SPEC.SCHEDULE 中写
与 crontab 类似 , * 表示每分钟等 / 表示自动起始时间开始出发. minites的 5/20 意味着 5分钟开始之后每隔20分钟出发一次 即 25, 45min 触发
kubectl get jobs --watch 查看触发任务执行的历史和现状
daemonset:
在每个node上都调度一个pod , 调度策略与rc类似. 除使用内置算法调度在每个node调度之外, 也可在pod定义中使用 nodeselector 或 nodeaffinity 来指定满足条件的node范围进行调度 . 也支持 rollingUpdate 滚动升级
更新策略
| ondelete | 默认策略. 用户手动删除旧版pod 才会发新建操作 |
| rollingupdate | 整个过程与 deploy一样是可控 , 1.14 还不支持查看历史记录 回滚得通过 再次提交旧版本配置方式实现 |
StatefulSet
通过 StatefulSet controller直接管理下属Pod, 在Pod中用label标识版本 ( controller-revision-hash )
statlefulset 的pod名后缀是 从 0 - N的序号
扩容时也是按序号增大的顺序扩容,
执行策略
| OrderedReady | 默认策略 前面的所有Pod都Ready之后才能执行新增下一个Pod |
| Parallel | 并行扩容, 不用等待前面Pod都Ready |
缩容按照倒序删除
升级策略字段
| RollingUpdate | 滚动升级 |
| OnDelte | 禁止主动升级 |
Partition: 滚动升级时保留历史版本Pod的数量
Deployment
状态
| Processiong | 处于扩容和发布中 |
| Complete | 所有的replicas 及pod副本全部达到最新且 available |
| Failed |
Spec 的字段:
MinReadySeconds
设置后 . deploy 会在 指定 pod ready 超过指定的时间后才认为pod数 available
revisionHistoryLimit : 保留历史revision
paused : 标识. Deploy只做数量维持. 不做新的发布. 在debug场景可能会用到
progressDeadlineseconds : 如果超过时间还处于 processing . controller 会认为这个Pod 进入failed 的状态
升级相关字段
| MaxUnavailable | 滚动过程最多有多少个Pod不可用 |
| MaxSurge | 滚动过程中最多存在多少个Pod超过预期 replicas数量 |
应用配置管理
ConfigMap 可变更配置
Secret 敏感信息
ServiceAccount 身份认证
Resources 资源配置
SecurityContext SecurityContext
InitContainers 前期校验
ConfigMap 注意要点:
文件大小: ConfigMap文件没有大小限制, 但是ETCD里面 , 数据写入有大小限制. 目前是 1MB 内
ConfigMap 是 NameSapce资源
如果Pod 引用 ConfigMap , ConfigMap 必须提前创建好. 否则pod无法创建成功
使用 envFrom 方式时
如果 ConfigMap里面的key是无效的. 如 key名字带有数字. 则会被忽略
通过 k8sapi创建的pod才能用ConfigMap . 如kubelet 通过mainfest创建的static pod 不能使用ConfigMap
Secret Secret 文件同样有 1Mb限制
信息采用 base64 保存
Secret 类型 ( 在type字段中指定 )
| Opaque | 普通的secret文件 |
| service-account-token | 用于 service-account身份认证 |
| dockerconfigjson | 拉取私有仓库镜像 |
| bootstrap.token | 节点介入集群校验使用 |
Service相关
service 的类型:
| ClusterIP | 默认 |
| NodePort | |
| LoadBalancer | 在nodepor上面多了一层转换. lobadbalancer在所有节点前又挂一个负载均衡. 如 阿里云挂slb. 这个入口把流量负载均衡到每个节点上的nodeport, nodeport再转化成 clusterip 访问实际pod |
| ExternalName | 把集群外部服务引入到集群内部使用 — pod 请求外部服务 |
| Headless Service | 创建service时 clusterIP 指定为None, 不分配ip地址. 通过svc名字 dns解析的方式去访问 |
service 调度策略
RR
SessionAffinity : 基于客户端IP
控制器模式 :
控制循环 : 控制器 / 被控制的系统 / 观测系统的传感器 — 不断使系统向spec表示的最终状态趋近
控制器比较资源 spec和status. 根据diff结果决定对系统进行什么样的操作. 控制器操作产生输出 被传感器以资源status形式上报.
传感器 sensor : Reflector , Informer , Indexer
Reflector : 通过 List 和Watch K8s server 获取资源数据
List 在 Controller 重启及watch 中断情况下. 进行资源全量更新.
Watch : 在多次 List 之间进行增量资源更新
扩容时的流程 .
控制器 采用 声明式的api 设计方式
应用存储和持久化存储
本地存储 : emptydir/hostpath
网络存储 :
projected Volumes : 如 secret/configmap 用卷的形式挂载在容器中. 容器程序通过posix接口访问配置数据
pv & pvc
| pv | 把存储和计算分离. 通过不同组建管理存储和计算资源. 解耦pod 和 volume 之间生命周期的关联 |
| pvc | 职责分离: pvc中只用声明自己需要的存储size, access mode ( 单node独占还是共享, 只读还是读写访问 ). 等业务 的存储需求. pv和对应的后端存储信息交给 cluster admin 统一运维和管控. 安全访问策略更容易控制 pvc 简化了user对存储的需求. pv才是存储实际信息的承载体. 通过 kube-controller-manager中的 PersisentVolumeController 将 pvc 与 合适的 pv bound到一起. 满足用户对存储的需求 |
pvc是面向对象编程中抽象出来的接口, pv是接口对应的实现
| static volume | 需要提前规划/预测需求. 容器倒是pvc找不到合适pv |
| dynamic volume | 徐徐关注pv细节 |
pv 权限
| rwo | 读写权限. 只能被单个node挂载 |
| rox | 只读权限. 允许被多个node挂载 |
| rwx | 读写权限. 允许被多个node挂载 |
资源释放 : 被绑定的pv 在 pvc 删除之后 清除数据才能再次使用
回收策略 : presistentVolumeReclaimPolicy
保留 : 保留数据
回收空间 : 简单清除文件. 如 rm -rf
删除 : 与pv相连的后端存储完成wolume的删除操作 (如 aws )
pv的生命周期
| Available | 可用. 未与某个pvc绑定 |
| bound | 已与某个pvc绑定 |
| released | 绑定的pvc已经删除. 资源已释放. 但没有被集群回收 |
| failed | 自动资源回收失败 |
创建pv会会短暂处于pending状态. 等真正pv创建好后处于 available状态
用户提交pvc之后. 被k8s相关组件做完bound后 pv pvc结合到一起. 此时两者都处在 bound状态
使用完pvc 删除后 pv就处在released状态.
release状态下. pv没法直接回到 available状态. 如果想要复用则 需要:
1.创建新pv对象. 把released的pv相关信息填到新pv
2.删除pod后不删除pvc. 这样给pv绑定的pvc还是存在. 可以直接通过pvc复用
节点亲和性 : 限制只能通过某些node访问 volume . 通过 pv 的 nodeAffinity 字段设置
static PV
Dynamic PV:
存储快照与扩扑调度
k8s 通过 CSI Snapshotter controller 实现存储快照功能
操作由编译器转换成 OpSliceMake 操作 . 通过 VolumeSnapshot 对象声明, 并指定相应的VolumeSnapshotClass对象 动态生成存储快照及存储快照对应的对象 VolumeSnapshotContent
从快照恢复数据
pvc提交之后 集群相关组件找到dataSource指向的存储快照数据. 创建新的对应存储及pv独享. 将快照数据恢复到新pv中
存储阔扑调度 :
场景 : 跨机房, 跨环境 , 跨云环境 区 等场景下 某个环境里面的pv 只给当前环境使用
生成pv的时候 , 并不清楚使用该pv的pod会调度到哪些node上. 但 pv本身对pod所在的node有阔扑位置限制
处理方式 : k8s 将 pv和pvc的binding 操作和动态创建pv操作做了delay, delay到pod调度结果出来后再执行binding
k8s 对 Volume Snapshot/Restore 处理流程
651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
