本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

每周 Kubernetes 社区环聊笔记 - 2015 年 7 月 17 日

每周,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 vs. systemd 呢?

        • 应该能够在代码中支持,没有任何麻烦(尚未实现)
    • 讨论

      • 为什么不将设置工作推送到容器或 kubernetes 配置中?

        • 要引导集群,只需放置一个 kubelet 和一个清单
      • 运行 kubelet 和配置网络应该是唯一需要做的事情。我们可以创建一个预配置的机器镜像,减去数据包(证书等)

        • ansible 脚本会在未安装的情况下安装 kubelet 和 docker
      • 每个操作系统(RedHat、Debian、Ubuntu)都可以有不同的镜像。我们可以将其视为构建过程的一部分,而不是安装过程的一部分。

      • 也需要有裸机解决方案。

      • 赞成总体目标——减少 salt 配置中的特殊配置

      • 除了 kubelet 之外的所有东西都应该在容器中运行(最终 kubelet 也应该在容器中运行)

        • 在容器中运行并不能减少我们目前拥有的复杂性
        • 但它确实更清楚地定义了代码期望的接口
      • 这些工具(Chef、Puppet、Ansible)将二进制分发与配置混为一谈

        • 容器更清楚地将这些问题分开
      • mesos 部署尚未完全自动化,但 mesos 部署完全不同:kubelets 放置在现有 mesos 集群之上

        • bash 脚本允许 mesos 开发人员查看每个云提供商正在做什么并重用相关部分
        • 有一个很大的逆向工程曲线,但 bash 至少是可读的,而 salt 则不然
      • Openstack 也使用不同的部署

      • 我们需要一个有良好文档的必要步骤列表(例如创建证书)来搭建集群

        • 这将使我们能够跨云提供商进行比较
        • 我们应该尽可能减少步骤数量
        • Ansible 启动集群有 241 个步骤
  • 1.0 代码冻结

    • 我们如何摆脱代码冻结?

    • 这是下周的话题,但预览是我们将缓慢进行,而不是完全打开水闸

      • 我们希望尽快清理积压工作,同时保持 HEAD 和 1.0 分支的稳定性
      • 积压了近 300 个 PR,但在冻结期间也开发了各种并行功能分支
    • 今天发布了一个修补了一些问题的 cherry pick 版本(1.0.1)

    • 下周我们将讨论补丁发布的节奏