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. “云爆发” - 自动溢出到云端

• 棘手的问题

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. 重要的是不要限制用途并阻止其他用户

3. Satnam - 稳定性测试 (Soak Test)

• 希望衡量长时间运行的事物，以确保集群随着时间推移保持稳定。性能不下降，没有内存泄漏等。
• github.com/GoogleCloudPlatform/kubernetes/test/soak/…
• 单一二进制文件，在每个节点上部署大量 Pod，并查询每个 Pod 以确保其正在运行。
• Pod 的创建速度（甚至在过去一周）快了很多很多，以加快测试进度。
• 一旦 Pod 启动运行，我们通过代理访问 Pod。通过代理访问是经过深思熟虑的决定，以便我们测试 Kubernetes APIServer。
• 代码已入库。
• 将 Pod 固定到每个节点，锻炼（测试）每个 Pod，确保每个节点都有响应。
• 单一二进制文件，永久运行。
• Brian - v1beta3 默认启用，v1beta1 和 v1beta2 已弃用，将于六月关闭。升级现有集群等应该仍然有效。

• ←上一页
• 下一页→