Outdated article
The Kubernetes project considers this article to be outdated because it is more than one year old. Check that the information in the page has not become incorrect since its publication.
每周 Kubernetes 社区例会笔记 - 2015年4月3日
Kubernetes: 每周 Kubernetes 社区聚会笔记
每周,Kubernetes 贡献社区几乎都会通过 Google Hangouts 开会。 我们希望任何有兴趣的人都知道本论坛讨论的内容。
议程:
- Quinton - 集群联邦
- Satnam - 性能基准测试更新
会议记录:
- Quinton - 集群联邦
- 在旧金山见面会后,想法浮出水面
-
- 请阅读、评论
- 不是 1.0,而是将文档放在一起以显示路线图
- 可以在 Kubernetes 之外构建
- 用于控制多个集群中事物的 API ,包括一些逻辑
-
Auth(n)(z)
-
调度策略
-
……
- 集群联邦的不同原因
-
区域(非)可用性:对区域故障的弹性
-
混合云:有些在云中,有些在本地。 由于各种原因
-
避免锁定云提供商。 由于各种原因
-
"Cloudbursting" - 自动溢出到云中
- 困难的问题
-
位置亲和性。Pod 需要多近?
-
工作负载的耦合
-
绝对位置(例如,欧盟数据需要在欧盟内)
-
-
跨集群服务发现
- 服务/DNS 如何跨集群工作
-
跨集群工作负载迁移
- 如何在跨集群中逐块移动应用程序?
-
跨集群调度
-
如何充分了解集群以知道在哪里进行调度
-
可能使用成本函数以最小的复杂性得出亲和性
-
还可以使用成本来确定调度位置(使用不足的集群比过度使用的集群便宜)
-
- 隐含要求
-
跨集群集成不应创建跨集群故障模式
- 在 Ubernetes 死亡的灾难情况下可以独立使用。
-
统一可见性
- 希望有统一的监控,报警,日志,内省,用户体验等。
-
统一的配额和身份管理
- 希望将用户数据库和 auth(n)/(z) 放在一个位置
- 需要注意的是,导致软件故障的大多数原因不是基础架构
-
拙劣的软件升级
-
拙劣的配置升级
-
拙劣的密钥分发
-
过载
-
失败的外部依赖
- 讨论:
-
”ubernetes“ 的边界确定
- 可能在可用区,但也可能在机架,或地区
-
重要的是不要鸽子洞并防止其他用户
- Satnam - 浸泡测试
- 想要测量长时间运行的事务,以确保集群在一段时间内是稳定的。性能不会降低,不会发生内存泄漏等。
- github.com/GoogleCloudPlatform/kubernetes/test/soak/…
- 单个二进制文件,在每个节点上放置许多 Pod,并查询每个 Pod 以确保其正在运行。
- Pod 的创建速度越来越快(即使在过去一周内),也可以使事情进展得更快。
- Pod 运行起来后,我们通过代理点击 Pod。决定使用代理是有意的,因此我们测试了 kubernetes apiserver。
- 代码已经签入。
- 将 Pod 固定在每个节点上,练习每个 Pod,确保你得到每个节点的响应。
- 单个二进制文件,永远运行。
- Brian - v1beta3 默认启用, v1beta1 和 v1beta2 不支持,在6月关闭。仍应与升级现有集群等一起使用。