Inspired from https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
Service discovery and load balancing
每一个远程工作的个体（一下称员工），本质上是在提供服务。服务的发现即发现能够提供服务的个体。
负载均衡，即给每个个体分配合理的工作量。
Storage orchestration
根据可行的方式支付，不限制支付形式。
Automated rollouts and rollbacks
根据工作计划，完成任务即可撤离，或切换到其他任务。
如果任务不能按时完成，则可能考虑换人重新开始。
Automatic bin packing
雇主给员工分配合理的资源，员工决定怎么使用资源完成任务。
Self-healing
当不再适合工作时，替换员工，仅在员工具备工作条件为雇主服务。
Secret and configuration management
及时更新保密协议和隐私信息，且不透漏给第三方。
————update————
构成一个k8s团队的组件
主要针对控制平面组件做拆解
kube-apiserver
项目经理/team leader
需要和团队中提供服务的个体建立联系，分派任务和资源，并考虑平衡。
可以是“集群”也可以是“单例”
etcd
财务，通过工具或平台记录团队运行状况。
根据每一个个体的产出，针对异地的工作者发放薪水。
kube-scheduler
进度跟进及控制者，product owner/产品
kube-controller-manager
人事，及时跟进人员的工作状态（请假/离职）
为新成员提供boarding，账户权限etc
cloud-controller-manager
法务/人事，根据当地法律法规，制定工作合同等法律文件，确保不同地区的成员能够顺利工作，没有税法等法律风险。
其他的锦上添花的部分就不展开了
结论：
搭建这样的团队并不容易，如果是初期小团队尝试这种方式很可能要一人分饰多角。
挺有想法的。啥时候实践一下
https://eleduck.com/posts/Ygf0Da
已经有人在实践了
异常终止
**本工作室充分理解远程开发协作的交付时间和中断风险，并承担相应风险，远程开发者随时可因任何原因终止协作 **
请在任务约定到期前的任何时间知会本工作室，以便及时处理。约定任务完成时间到达后的1天内，如远程开发者无信息回馈或者失联，默认终止开发协议。
任何异常终止，并不影响后续的合作。
很6了。
拆分任务的成本比较高，需要非常有经验，且这个人/团队可能无法替换（k8s本身）
就像k8s本身，api-server和controller manager肯定是必要的，没有这些也不能成为k8s。
没有能拆分任务的人/团队，这种方式必然运转不起来。
这里有两层意思，一方面是要有能拆分任务的人，另一方面是任务是可拆分的。映射到k8s的例子就是，k8s适合大规模分布式系统，却不适合强耦合高资源占用的系统，例如模型训练等。
TLDR就是这种分工模式能不能落地，很吃任务/业务类型。是一种新型分工模式，却不一定是一种通用方案
很有意思的想法，把技术架构的解决问题的思想放到了现实的事件中，希望以后能够形成体系，多分享具体经验！
这个不是个人独创，忘了在哪看到的，大意是，组织架构最终会反应到软件架构上。
比如之前单体架构的软件，基本上可能就按分前后端开发，运维，dba之类分组织架构。
等到微服务出来之后，一些企业就对应的将组织架构做了调整。
比如一个team负责一个微服务，如果是到用户端到产品，那这个team里，可能产品，前后端devops都有。一些team负责微服务治理。
不过楼下那个老哥说得好，要结合市场情况来看。
组织架构与软件系统架构的关系这事是 康威定律吧。不知道今后的趋势是什么，每一个阶段大概多久，比如单体-大团队存在了X年，微服务-小团队Y年，今后会是更加灵活的团队吧
感觉最大的问题是解决工作任务的标准化，毕竟彻底解藕可以随时加入上手的任务不多
看上一条评论的回复
想法挺好, 但是k8s模式对infrastructure是有一定要求的, 人力市场比较难满足这样的要求, 人员是可以随意切换的, 但是人员的素质, 能力包括工作方式这个就很难保证了, 除非有人出钱出力搭建一个这样的人才云, 把人才作为一个infrastructure资源进行筛选, 培训, 封装, 组成一个人员可以无缝切换的人才池.
另一个思路，是可以通过比较廉价的招聘方式来筛选应聘者。
常见的实践是开放式0面，即给你3-5天，做一个日常任务相类似的任务，不限是否联网之类。
本身做0面的成本会筛选掉一部分不合适的，然后面试时只要排除代笔的可能性基本上成本还是可控的。