每周 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 - 耐压测试

• 希望测量长时间运行的事物，以确保集群随着时间的推移保持稳定。性能不会下降，没有内存泄漏等。
• github.com/GoogleCloudPlatform/kubernetes/test/soak/…
• 单个二进制文件，在每个节点上放置大量 Pod，并查询每个 Pod 以确保其正在运行。
• Pod 的创建速度快得多（甚至在过去的一周内），以便更快地完成工作。
• 一旦 Pod 启动并运行，我们就会通过代理访问 Pod。故意选择访问代理是为了测试 Kubernetes apiserver。
• 代码已经签入。
• 将 Pod 固定到每个节点，运行每个 Pod，确保你获得每个节点的响应。
• 单个二进制文件，永远运行。
• Brian - v1beta3 默认启用，v1beta1 和 v1beta2 已弃用，在 6 月关闭。应该仍然可以升级现有集群等。

• ←上一页
下一页→