其实我倒觉得相反

k8s本身并没有离开linux内核提供的这些基础太多，比如namespace，cfs share, quota，ipvlan等基础，有时候出了问题，稍稍一挖，就会发现又穿透k8s，掉进了linux本身的问题里去了

甚至有时候我都觉得 k8s有点太简陋，或者某些关键设计理念本身有点不自洽，
最典型的，pod是k8s认为的最小的完整的功能体，但是k8s却把资源的限定放在了容器级别（因为沿用了docker对cfs的使用方式理念），所以，一个pod里面的不同容器之间，一个容器的富余资源配额，不能被同一pod的另一个容器挪用，所以，在流量类型有变化的情况下，预先设定好的静态的容器资源配额可能就不是最优的了，即使最近出来一个static cpu manager，也只是用来解决cfs over throttle问题的，不是解决pod内部动态资源配比问题的



【 在 littleSram 的大作中提到: 】
: 非常理解
: 关于云原生，我觉得是趋势，确实复杂，好多人都有类似的感觉，当对k8s了解的越多，越发现know nothing about k8s
: 关于架构师，我见到的都是写PPT向老板汇报的那种，基本不写代码，但是会画所谓的架构图，有具体的问题，不会参与。反正这些人都号称架构师。
: ...................
--
FROM 223.81.245.*

很同意你的观点。
从engineer的角度，架构师，至少在某个领域应该是千锤百炼过的。这个应该是和项目管理最根本的区别吧
- 来自 水木社区APP v3.4.2
【 在 wallyz 的大作中提到: 】
: 我并不算是互联网行业的
:
: 但这几年，因为产品向虚拟化，然后再往云原生转型，确实也经历了不少或深或浅的坑
:
: 比如，2019年，RHEL/CentOS 7.X kernel里面一个multiqueue的深坑，在虚拟环境下打开virtio-net的multiqueue，会造成发出去的包乱序的问题，就把产品以及我给狠狠的坑了一下
:
: 去年疑似被k8s环境下，CFS quota over throttling给坑了一把
:
: 今年早些时候又被openstack的NUMA问题给扰了一小段
:
: 其实我不愿意给自己扣一个架构的帽子，我也看不上不接地气只会PPT的架构，至于前面那种，以项目管理的方式作架构，出了问题，让工程师出方案的，就更匪夷所思了。
:
: 产品在现场出了问题，那时候，什么样的人能出的上力，这是很清楚的。这时候，需要从很底（操作系统，网络协议，计算机基本体系结构），到很顶（产品实现的原理甚至细节），都要有挺多的理解，或者去做挺多的调查，才能在各种纷繁复杂的线索中，找出可能的问题，当然，也需要运气。
:
: 无论如何，不接地气的架构，大概不是一个好架构，至少，对这个产品来说，不够好。
:
: 有人说，出了问题不应该是架构来搞；那可能是没经历过实战，那时候，老板手里能抓住什么稻草，就会抓住什么稻草，何况，产品出了严重问题，哪有人可以独善其身。
: 所以，产品出了问题，懵逼的架构，装死不吱声的架构，或者指望别人出方案搞定的架构，在我眼里，都不是好架构
--
FROM 111.65.45.*

人家自己掉的坑，也不一定都说出来给所有人听嘛

即使他们真的无所谓（我觉的可能性不算大），至少我们的产品是有所谓的，因为我们的产品是一路演进的，前后性能有显著差异，那是绝对不可能交代的了的
就像产品在现场出了问题，不管是产品逻辑问题，还是基础设施问题，或者系统内核问题，或者体系限制只能这样，总之，你必须从头到尾说出个一二三，让逻辑讲的通站得住脚，否则，事情不会完

甚至我们都有定期的优化，设定的目标是，把当前系统的资源占用降低十个点，而且是持续的，每年都要做
听起来很疯狂，我也觉得挺疯狂，但沉下去挖一挖，还是有一些优化能做的


【 在 mywindows 的大作中提到: 】
: 互联网的平台都是这样拼起来，不也玩的好好的
--
FROM 223.81.245.*