Kubernetes 社区每周在线交流笔记 - 2015 年 7 月 10 日

Kubernetes 贡献者社区每周都会通过 Google Hangouts 进行在线会议。我们希望任何感兴趣的人都能了解此论坛中讨论的内容。

以下是本次会议的记录

• Eric Paris: 用 ansible 替换 salt（如果需要的话）
  • 在 contrib 中，有一个用 ansible 编写的供应工具
  • 重写的目的是尽可能地消除云提供商相关的代码
  • salt 的设置在脚本中执行大量设置，然后使用 salt 设置环境
    • 这意味着像生成证书这样的事情在 GCE/AWS/Vagrant 上以不同方式完成
  • 对于 ansible，所有事情都必须在 ansible 内完成
  • 关于 ansible 的背景信息
    • 没有客户端
    • 供应者通过 ssh 连接到机器并在机器上运行脚本
    • 你定义你希望集群是什么样子，运行脚本，它就会一次性设置好所有内容
    • 如果你在配置文件中进行一项更改，ansible 会重新运行所有内容（这并非总是理想的）
    • 使用 jinja2 模板
  • 创建只安装最少软件的机器，然后使用 ansible 使该机器进入可运行状态
    • 设置所有插件
  • 消除了供应者 shell 脚本
  • 完整集群设置目前大约需要 6 分钟
    • 安装了一些软件包的 CentOS
    • 重新部署到集群需要 25 秒
  • Eric 的问题
    • 提供商特定的配置放在哪里？
      • ansible 配置所做的唯一网络设置是 flannel；你可以关闭它
    • init 和 systemd 如何处理？
      • 代码应该能够轻松支持（尚未实现）
  • 讨论
    • 为什么不将设置工作推送到容器或 kubernetes 配置中？
      • 要引导一个集群，只需要放下 kubelet 和一个清单文件
    • 运行 kubelet 和配置网络应该是唯一需要做的事情。我们可以制作一个预配置好的机器镜像，减去数据包（证书等）
      • 如果 kubelet 和 docker 尚未安装，ansible 脚本会安装它们
    • 每个操作系统（RedHat, Debian, Ubuntu）可以有不同的镜像。我们可以将此视为构建过程的一部分，而不是安装过程的一部分。
    • 裸金属环境也需要有解决方案。
    • 赞成总体目标 -- 减少 salt 配置中的特殊配置
    • 除了 kubelet，所有其他组件都应该在容器内运行（最终 kubelet 也应该这样）
      • 在容器中运行并不能减少我们目前的复杂性
      • 但这更清楚地定义了代码预期的接口
    • 这些工具（Chef, Puppet, Ansible）将二进制分发与配置混为一谈
      • 容器更清晰地分离了这些问题
    • mesos 部署尚未完全自动化，但 mesos 部署完全不同：kubelet 放在现有的 mesos 集群之上
      • bash 脚本让 mesos 开发者可以看到每个云提供商在做什么，并重用相关的部分
      • 存在很大的逆向工程难度，但 bash 至少比 salt 可读性更好
    • Openstack 也使用了不同的部署方式
    • 我们需要一份详细记录了启动集群所需步骤（例如创建证书）的列表
      • 这将使我们能够比较不同云提供商的方案
      • 我们应该尽可能减少步骤数量
      • Ansible 启动一个集群有 241 个步骤
• 1.0 代码冻结
  • 我们如何解除代码冻结？
  • 这是下周的话题，但提前透露一下，我们将缓慢推进，而不是完全放开流量
    • 我们希望尽快处理积压的工作，同时保持 HEAD 和 1.0 分支的稳定性
    • 积压了近 300 个 PR，但在冻结期间也开发了各种并行特性分支
  • 今天将发布一个 cherry pick 版本 (1.0.1)，修复一些问题
  • 下周我们将讨论补丁版本的发布节奏

• ←上一页
• 下一页→