每周 Kubernetes 社区环聊笔记 - 2015 年 4 月 3 日

Kubernetes：每周 Kubernetes 社区交流笔记

每周，Kubernetes 贡献者社区都会通过 Google Hangouts 进行虚拟会议。我们希望所有感兴趣的人都能了解这个论坛讨论了什么。

议程

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

会议纪要

1. Quinton - 集群联邦

• SF 聚会后的一些想法
• • 请阅读并评论
• 不是 1.0 版本，但整理了一份文档以展示路线图
• 可以在 Kubernetes 之外构建
• API 用于跨多个集群控制事物，包括一些逻辑

1. 身份验证和授权

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. 希望将用户数据库和身份验证/授权放在一个地方

• 需要注意的是，大多数软件故障的原因并非基础设施

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 月关闭。现有集群升级等仍应正常工作。

• ←上一篇
• 下一篇→