Kubernetes 专业问答
498 35最热 | 最新
- 8年运维，从物理机，虚拟机，容器一路玩过来，目前失业了
- 不管docker还是k8s，选用适合自己的架构就好，有些面试官面试就看面试宝典那玩意问，经验丰富运维工程师也不一定懂理论，但照样可以进行运维。
- 自学的k8s，没有绝对的说法
- 市场和行业竞争：为了吸引优秀人才，公司需要提供有竞争力的薪酬。随着市场行情的变化，新员工的薪酬必须接轨市场，而老员工的薪酬则相对稳定，难以调整。 人工成本：招聘新员工的成本相对较低，尤其是当公司需要大规模招聘时，可以更好地控制成本。相比之下，给老员工普遍涨薪会增加较大的成本负担。 调节团队积极性：新员工的加入可以激发老员工的积极性，形成“鲶鱼效应”，促进团队的整体活力。 老员工的问题：老员工可能存在抱怨、居功自傲或能力不足的问题，这些问题会影响团队氛围和工作效率，因此公司更倾向于招聘新人。 内部制度：公司的薪酬体系通常有固定的薪资带宽，老员工涨薪会触及薪资上限，而招聘新人则没有这个问题。 个人因素：老员工可能因为习惯和惯性，对涨薪的期望值较低，而新员工则对薪酬有更高的期望，这也会影响公司的决策。 补充原因： 老板的节流策略：很多老板通过控制人工成本来增加利润，因此不愿意给老员工涨薪。 避免连锁反应：给部分老员工涨薪可能会引发其他员工的不满，导致连锁反应，因此公司更倾向于避免这种情况。 不可替代性弱：老员工可能因为长期在同一个岗位工作，缺乏市场竞争力，公司更愿意招聘更有潜力的新人。
- 市场和行业竞争：为了吸引优秀人才，公司需要提供有竞争力的薪酬。随着市场行情的变化，新员工的薪酬必须接轨市场，而老员工的薪酬则相对稳定，难以调整。 人工成本：招聘新员工的成本相对较低，尤其是当公司需要大规模招聘时，可以更好地控制成本。相比之下，给老员工普遍涨薪会增加较大的成本负担。 调节团队积极性：新员工的加入可以激发老员工的积极性，形成“鲶鱼效应”，促进团队的整体活力。 老员工的问题：老员工可能存在抱怨、居功自傲或能力不足的问题，这些问题会影响团队氛围和工作效率，因此公司更倾向于招聘新人。 内部制度：公司的薪酬体系通常有固定的薪资带宽，老员工涨薪会触及薪资上限，而招聘新人则没有这个问题。 个人因素：老员工可能因为习惯和惯性，对涨薪的期望值较低，而新员工则对薪酬有更高的期望，这也会影响公司的决策。 补充原因： 老板的节流策略：很多老板通过控制人工成本来增加利润，因此不愿意给老员工涨薪。 避免连锁反应：给部分老员工涨薪可能会引发其他员工的不满，导致连锁反应，因此公司更倾向于避免这种情况。 不可替代性弱：老员工可能因为长期在同一个岗位工作，缺乏市场竞争力，公司更愿意招聘更有潜力的新人。
- 两天一夜的毕业旅行，哪位家长还没回复我信息，麻烦回复一下是否去哈！
- 07年做网格调度管理时候，当时处于kvm，Citrix，xen和VMware时代，公司推销大咖常问客户的问题是： 你们机房这么大，系统这么多，你们知道有多少电费是白白浪费的吗？你们知道你们机房有多少颗CPU是空闲的吗？ 就这样居然推销一单又一单🤡，业绩大好。
- 因为k8s是目前使用最普遍的容器编排工具。可以在其基础之上构建和部署应用。有广泛的插件支持，可以很方便的迁移自己的业务运行到k8s集群。提供高可用、可扩展的服务。
- 商家想要做用户种草，需要关注重点种草人群。在快手磁力方舟5R人群资产模型中，R3人群蓄水是品效销链路上的关键一环。对R3人群种草，商家可以选择R3优化模型、种草快线等产品。 R3优化模型是品牌广告下首个以“R3经营”为优化目标的产品，能够帮助广告主有效提升新增R3数量，降低R3用户获取成本，实现品牌兴趣人群资产提升。种草快线是“磁力聚星”联动“磁力方舟”平台，针对品牌心智种草场景打造的“破圈种草”&“效果验证”为一体的投放项目，高效积累高价值R3，扩大品牌声量。
- 首先，你这描述就让人摸不着头脑， pod 是 k8s 的最小控制单元，它可以包含一个或多个容器。它不是节点。其次，网络不通，太笼统，k8s 网络情况比较复杂，有 pod 间的相互通信，无论是否同一 node 节点。有 pod 与 service 间的转发。有集群外部的访问请求与 service 的通信。这就三个网络了。还有 DNS 插件，它是否正常工作？ k8s 内部网络通信，需要 DNS 插件，它会将各 pod，各 service 都解析 DNS 域名，并存储在 etcd 中。所以 DNS 插件也是影响 k8s 网络的原因之一。
- 就问你凭什么会 k8s，我就不明白了，那么多容器编排工具非得选一个重量级的。docker 自带的 dockerswarm 足够中小型或者容器集群用量不高的大公司用了。北京地铁监控还用 mariadb 数据库，你们就非得 k8s，搭建麻烦，运维也是一头雾水，没有个资深的 k8s 架构师，随便会点 docker 的运维也想完全给公司起一个 k8s 的生产环境吗，这不是学习，是生产，要学 k8s 可以看培训机构的课，真正公司使用还得正的八经老架构带一个团队做
- 现阶段高级运维必须会 k8s 的，特别是大公司。 我学习都是直接看文档，文档是最好的老师。 刚开始可能看不下去，坚持住了就会发现文档最好。
- 高级运维一般都要求会 k8s， k8s 可以理解成运维的一个框架，一个自动化框架。（从代码提交，打包发版，负载均衡数量，流量控制，监控告警，都有涉及。） 实际上主要还是集成现有开源服务的。 不过运维有一点是 k8s 目前无法实现的，就是性能调优。 很多段子再说：你运维技术再牛逼，我有了 k8s 就不需要你了。 这些话说给纯开发听可以， 因为他们不知道： 服务器资源购买规划， 提升现有资源利用率， 快速定位错误， 故障定位。 外部 web 攻击预防，实际攻击处理。 内部服务器操作规范， 性能瓶颈分析优化 服务器安全保障。 只知道 k8s 自动化框架，而且一般 k8s 是运维搭建的，开发搭建的说不定哪天整个公司的被人一锅端了。 当然啦，肯定有开发大佬懂运维的， 也有运维大佬有编程技术专利的。 所以建议能学还是学一下 k8s。 至于用不用，和会不会是两码事哦。 k8s 的设计还是很值得借鉴的。
- 干运维和会代码不冲突，devops 是云计算，微服务大背景下的产物，而 k8s 让微服务有了调度平台，让企业可以自建 PaaS，为什么现在都要求 k8s，只要公司是敏捷开发，想快速迭代就会对 k8s 有需求，而 k8s 本身要玩的好，只会传统运维是不够的，你没发和开发打成理解一直，也没法定制开发，所以就会到刚开始，会代码的要求，也解释了为什么要求 devops
- 只是一个趋势 公司最开始迁移的时候 我自己也花了 大半年的时间去学习k8s 然后发现入门以后东西越来越多 现在已经学习一年点一点点 但是我们的都是学应用 有多少devops 开发 了解过k8s里面的源码 比如说他的墓碑机制 我觉得这个东西很6 如果你要深入一个东西，那你肯定是需要去懂它里面一些机制 那我们看的只是看原理 并没有了解它里面是怎么去真正的运作的 同学在多点 做平台开发 完完全全是使用golang去二次开发 k8s 如果说单纯的应用这个系统 那一年多完完全全够了 如果说是要开发他，那就需要很多很多的精力
- 一、K8s 中 pod 的三种重启策略 1、Always Always 是默认的重启策略，它表示无论何时容器终止，都应该立即重启容器，并且不管退出代码是什么。 2、OnFailure OnFailure 表示只有在容器以非零状态退出时才会重启容器。如果容器成功退出，则不会重启容器。这种策略通常用于运行一次性任务的场景，例如数据迁移、备份等。 3、Never Never 表示容器在退出后不会自动重启。这种策略通常用于手动管理 Pod，例如进行特定的调试工作。
- 我是通过看k8s官网，中英文都看，看常用命令和案例，结合自己部署的集群（一开始手动部署多遍，后面使用集成部署方案kubeoperator），进而将公司内的业务（java、nginx、jenkins）迁移到k8s集群中，通过实际的操作学习其中的奥秘，遇到不懂的请教群dqq群里的经验小伙和度娘，发现有个奇怪现象：在qq群里问很low的问题会被歧视伸手党。高级运维不一定要会k8s，看具体企业需要什么人才，有的可能没有k8s也照样可以风生水起，不过我们尽可能学到更多的知识，对自己和企业都是一种帮助，不进则退。
- 我用了 4 年时间，方法是我书架上从 docker 以后的书按顺序先看一遍，最后学 go 搞 crd，DevOPs 那一套。正如好多人说的，很多公司用不上这一套！
- 同样的计算资源，可以发挥更大的并行能力，如传统的Jenkins集群上并行CI数量受限于计算结点的数量，而管理相同结点的K8s集群可以处理远大于结点数的CI数量，总结为更有效的使用基础设施。