云原生架构与 GitOps 实战
王炜
前腾讯云 CODING 架构师
5442 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
云原生架构与 GitOps 实战
15
15
1.0x
00:00/00:00
登录|注册

07|K8s 极简实战(二):如何为业务选择最适合的工作负载类型?

你好,我是王炜。
上一节课,我带你认识了 K8s 资源的逻辑隔离机制,也就是命名空间。它可以帮助我们更好地组织 K8s 资源,同时具有一定的隔离特性。
工作负载是 K8s 运行的业务程序。还记得我们在上一模块说 K8s 的最小调度单位是 Pod 吗?虽然工作负载类型有好几种,但他们最终都是以 Pod 的形式运行的。当然,Pod 也是一种工作负载类型,不过我们之前有提到过,在实际的项目中,我们并不会直接使用 Pod 这个工作负载类型,而是通过其他的工作负载类型来间接使用它。
这节课,我们就来看看有哪些 K8s 常用的工作负载类型,以及如何使用它们。我仍然从示例应用出发,重点向你介绍 Deployment 工作负载,只要你掌握它,就可以满足工作中常见的业务场景。
在正式开始之前,你还是需要确保已经按照“示例应用介绍”的引导在本地 Kind 集群部署了示例应用。

工作负载类型

K8s 的工作负载包括:ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob。在实际工作中,我们最常用到的是 Deployment,不过在正式介绍它之前,我们首先需要先了解另外一个工作负载:ReplicaSet。

ReplicaSet

确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《云原生架构与 GitOps 实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • GAC·DU
    请问老师,滚动更新之后旧的镜像是如何处理的?我现在是通过写脚本的方式,部署在每个node上,设置Crontab定时清理,觉得不够智能。

    作者回复: 其实我们完全不用担心旧镜像占用磁盘空间的问题。 实际上 K8s 会根据镜像使用情况来帮我们自动清理它们,一般我们不需要进行人工干预,并且 K8s 也不推荐我们手动干预这个过程。 此外,kubelet 有两个参数可以控制镜像删除的行为,一个是 image-gc-high-threshold,另一个是 image-gc-low-threshold,他们的值默认是 85% 和 80%,这意味着当磁盘使用率达到 85% 的时候自动执行清理,并将磁盘使用率降到 80%。 最后,不同版本的业务镜像其实大部分的 Layer 层都是相同的,每次拉取新镜像版本只会有少量层的变化,并不是每次拉取镜像都会额外占用一份镜像空间大小,手动清理他们的收益不大,并且还可能会增加镜像拉取的时间,从而影响应用的更新速度。

    归属地:广东
    10
  • ghostwritten
    负载类型:ReplicaSet、Deployment、Statefulset、DaemonSet、job/cronjob 1. Pod 不具备自动恢复能力 2. ReplicaSet:kubectl apply -f 无法更新生效,删除pod可重载配置mainful生效 3. Deployment:无状态应用,常用;应用前后端组件等。 StrategyType: Recreate:此策略类型将在创建新 Pod 之前先销毁现有 Pod RollingUpdate: 滚动更新的方式对 Pod 进行逐个更新,它是默认的更新策略,不会造成业务停机 RollingUpdateStrategy 是对滚动更新更加精细的控制。 max surge 用来指定最大超出期望 Pod 的个数 max unavailable 是允许 Pod 不可用的数量 4. Statefulset:有状态应用,应用副本差异、持久存储,不常用理由:kubernets不擅长数据备份和容灾等。中间件可Helm Chart 安装。 5. DaemonSet:存储插件、网络插件代理、监控和日志组件 6. job\cronjob: 备份、巡检....; 特殊字段:backoffLimit 、completions 、restartPolicy、activeDeadlineSeconds.... 学习命令: kubectl get pods --selector=app=frontend -o jsonpath='{.items[*].spec.containers[0].image}’ kubectl patch hpa backend -p '{"spec":{"minReplicas": 3}}' -n example kubectl get replicaset --watch -n example kubectl set image deployment/backend flask-backend=lyzhang1999/backend:v1 -n example ..... [kubectl](https://smoothies.com.cn/kubernetes-docs/%E7%BB%84%E4%BB%B6/Kubectl/kubectl-command.html)

    作者回复: 很完整的课程命令总结👍🏻

    归属地:广东
    4
  • includestdio.h
    最多会有6个。新的 rs 拉起一个新 Pod ,旧的 rs 终止一个 Pod ,但是终止并不确保完全退出,只要旧 Pod 处于 Terminating 状态,则新的 rs 则会继续拉起下一个 Pod。如果旧Pod终止的足够慢,则有可能出现3个running的新Pod和3个Terminating的旧Pod

    作者回复: 非常正确,这确实是有可能出现的。 可以进一步研究看看如何解决这个问题,让 K8s 在旧版本完全退出后才拉起新的 Pod,而不是 在 Terminating 状态就拉起。

    归属地:广东
    3
    3
  • Noel ZHANG
    其实我一直想知道在deployment滚动更新的时候流量是怎么分配的,我们用不到这么细,也就没研究过

    作者回复: 滚动的更新过程中,新的服务会加入到 Service Endpoint,旧的服务会逐渐从 Endpoint 中删除。 对于 iptables 和 ipvs 两种 kube-proxy 的实现方式在流量处理上有所不同,iptables 默认会随机把流量转发到 Endpoint 后端上,ipvs 则默认会以加权轮询的方式转发流量。

    归属地:江苏
  • 郑海成
    max unavilable 0,max surge 1,最坏情况:新的rs 3 replica,旧rs 3副本

    作者回复: 是的。

    归属地:北京
  • 宝仔
    “restartPolicy 代表重启策略,如果我们把 restartPolicy 设置为 Never,意味着 Pod 运行完成后将不会被重新启动”。这里老师是不是有问题,应该是restartPolicy设置了Nerver之后,代表的是Pod运行失败后不会被重新启动,而不是运行完成后被重新启动吧。

    作者回复: 是的,感谢指正。

    归属地:广东
  • 李多
    “为了更加直观地展示他们之间的关系,我们可以尝试更新 Deployment。先将我们之前部署的 frontend HPA 最小 Pod 数量调整为 3,你可以使用 kubectl patch hpa 命令来调整:” 这部分应该是“ backend HPA 最小 Pod 数量调整为 3”吧,和后面代码对应的。

    作者回复: 是的。

    归属地:广东
  • includestdio.h
    “在正式修改 Deployment 之前,我们先使用 kubect get replicaset --watch 来监控” 命令错了哈 -.-

    作者回复: 感谢指正~

    归属地:广东
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部