每周 Kubernetes 社区例会笔记 - 2015年4月3日

Kubernetes: 每周 Kubernetes 社区聚会笔记

每周，Kubernetes 贡献社区几乎都会通过 Google Hangouts 开会。 我们希望任何有兴趣的人都知道本论坛讨论的内容。

议程：

• Quinton - 集群联邦
• Satnam - 性能基准测试更新

会议记录：

1. Quinton - 集群联邦

• 在旧金山见面会后，想法浮出水面
• • 请阅读、评论
• 不是 1.0，而是将文档放在一起以显示路线图
• 可以在 Kubernetes 之外构建
• 用于控制多个集群中事物的 API ，包括一些逻辑

1. Auth(n)(z)

2. 调度策略

3. ……

• 集群联邦的不同原因

1. 区域(非)可用性:对区域故障的弹性

2. 混合云：有些在云中，有些在本地。 由于各种原因

3. 避免锁定云提供商。 由于各种原因

4. "Cloudbursting" - 自动溢出到云中

• 困难的问题

1. 位置亲和性。Pod 需要多近？

   1. 工作负载的耦合

   2. 绝对位置(例如，欧盟数据需要在欧盟内)

2. 跨集群服务发现

   1. 服务/DNS 如何跨集群工作

3. 跨集群工作负载迁移

   1. 如何在跨集群中逐块移动应用程序?

4. 跨集群调度

   1. 如何充分了解集群以知道在哪里进行调度

   2. 可能使用成本函数以最小的复杂性得出亲和性

   3. 还可以使用成本来确定调度位置（使用不足的集群比过度使用的集群便宜）

• 隐含要求

1. 跨集群集成不应创建跨集群故障模式

   1. 在 Ubernetes 死亡的灾难情况下可以独立使用。

2. 统一可见性

   1. 希望有统一的监控，报警，日志，内省，用户体验等。

3. 统一的配额和身份管理

   1. 希望将用户数据库和 auth(n)/(z) 放在一个位置

• 需要注意的是，导致软件故障的大多数原因不是基础架构

1. 拙劣的软件升级

2. 拙劣的配置升级

3. 拙劣的密钥分发

4. 过载

5. 失败的外部依赖

• 讨论：

1. ”ubernetes“ 的边界确定

   1. 可能在可用区，但也可能在机架，或地区

2. 重要的是不要鸽子洞并防止其他用户

2. Satnam - 浸泡测试

• 想要测量长时间运行的事务，以确保集群在一段时间内是稳定的。性能不会降低，不会发生内存泄漏等。
• github.com/GoogleCloudPlatform/kubernetes/test/soak/…
• 单个二进制文件，在每个节点上放置许多 Pod，并查询每个 Pod 以确保其正在运行。
• Pod 的创建速度越来越快（即使在过去一周内），也可以使事情进展得更快。
• Pod 运行起来后，我们通过代理点击 Pod。决定使用代理是有意的，因此我们测试了 kubernetes apiserver。
• 代码已经签入。
• 将 Pod 固定在每个节点上，练习每个 Pod，确保你得到每个节点的响应。
• 单个二进制文件，永远运行。
• Brian - v1beta3 默认启用， v1beta1 和 v1beta2 不支持，在6月关闭。仍应与升级现有集群等一起使用。

• ←上一页
下一页→