你正在查看的文档所针对的是 Kubernetes 版本: v1.28
Kubernetes v1.28 版本的文档已不再维护。你现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。
每周 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月关闭。仍应与升级现有集群等一起使用。