container/orchestration

[giscus[bot]]

container/orchestration

构建大规模高可用的分布式系统

https://www.thebyte.com.cn/container/orchestration.html

[lbsu]

“按照既定顺序系统一系列 Pod”？

[isno]

抱歉，容器这一章还没写完，处于草稿状态。

[Mokaz111]

并未应用提供专用的系统资源,应该是打错了，并 为 应用提供

[isno]

谢谢提醒。容器的内容3月内修改完。

[nieen]

7.2章节下的三级目录编号错了

[nieen]

包括 7.4 7.7

[isno]

好的，谢谢，这两三天内修正

[Zeratal]

“Sidecar 模式其实就是在 Pod 里面定义一些专门的容器，通过职责分离与容器的隔离特性，够降低容器的复杂度，使开发一个高内聚、低耦合的软件变的更加容易。”
-----------“够降低”是不是打错了，“从而降低”或者“去降低”会不会通顺些

[Zeratal]

或者去掉“够”这个字

[echo1937]

"不然会给系统带来很大的文件"?

"不然会给系统带来很大的问题"

[zou2699]

”该项目由 Google 工程师（主要是 Paul Menage 和 Rohit Seth）在 200 年发起“，这里日期错了

[isno]

已修改

[8Haixin]

"将资源需求声明直接定义在 Pod 上，并以 Pod 作为最小的原子单位来实现调度。Pod 与 Pod 之间不存在超亲密的关系，如果有关系，就通过网络通信实现关联。复杂的协同调度问题在 Kubernetes 中直接消失了。"

”复杂的协同调度问题在 Kubernetes 中直接消失的原因“ 是 ”以 Pod 为调度单位和资源声明在 Pod 上定义和存在超亲密关系的Pod 间通过网络通信关联“？

[isno]

是的

[8Haixin]

感谢作者大大的回复！
想再请教一下，按照您例子推理，成组调度是不是就要得等到Node2资源满足亲和性约束的容器需求后，再进行统一调度 ?
您说的”复杂的协同调度问题“是指协同调度带来的”调度效率降低、资源利用不足，并可能出现互相等待而导致死锁的问题“吗？
这篇看完之后还是不太理解， ”以 Pod 为调度单位和资源声明在 Pod 上定义和存在超亲密关系的Pod 间通过网络通信关联“，是怎么解决”复杂的协同调度问题“的。

[isno]

调度是件很复杂的事情，【7.7.3 调度器与扩展设计】，这一节介绍了调度的逻辑，你看看。

应该能理解：实现“成组调度”的复杂性

[zjyyzhengli]

1. 于是有了 UTC（UNIX Time-Sharing）命名空间 -- 这里的缩写应该是UTS吧？
2. 辅助容器实现特性的技术需求（如日志记录、监控、安全性或数据同步） -- 这里是“特殊”？

[isno]

1. 我写错了，是 UTS 命名空间。
2. 漏写了

谢谢指正