关于kubernetes:cOStoolkitContainer-OS-的下一程

4次阅读

共计 5060 个字符，预计需要花费 13 分钟才能阅读完成。

作者简介
张智博，SUSE Rancher 大中华区研发总监，始终沉闷在研发一线，经验了 OpenStack 到 Kubernetes 的技术改革，在底层操作系统 Linux、虚拟化 KVM 和 Docker 容器技术畛域都有丰盛的研发和实践经验。

背景：笔者已经保护过一款面向 Docker 的开源容器化操作系统 RancherOS。cOS-toolkit 作为连续 Container OS 思维的新兴我的项目，做了更深层次的形象。本文将逐渐分析 cOS-toolkit 的设计理念和应用办法，并分享集体的一些思考。

RancherOS 的反思

RancherOS 公布之初，Docker 正是如日中天之时，牵强附会，RancherOS 的指标就是成为一款面向 Docker 的 Container OS。除了根底的 Immutable OS 规范个性之外，咱们做了很多魔改：比方把 dockerd 改为 system-docker 来替换 systemd，从而能够像治理容器一样治理一些零碎服务；极致裁剪了内核，心愿把它打造成以最低老本运行 Docker 的 OS；两层的 rootfs，当然用户空间的 rootfs 实质上是一个 Ubuntu/CentOS/Buildroot 等镜像运行的容器；应用 YAML 配置清单来做零碎初始化，通过这种形象来简化系统管理员的累赘等等。

随着工夫的推移，一些魔改的思路随着上游的倒退而变得不可继续，比方 system-docker 组件始终停留在晚期版本，无奈进化。精简内核也带来了诸多问题，未能背靠一个弱小的社区，很难继续保护这些内核以及零碎组件，并在兼容性上提供可信赖的保障。默认的 console 基于 Buildroot 我的项目构建，每次减少软件包都是十分繁琐简单的工作，并且 Buildroot 自身谋求的精简有时无奈满足服务器端的需要。用户的自定义需要很难失去满足，用户通常须要期待官网版本的更新，用户自定义的技术老本十分高，难以上手。

RancherOS 的倒退过程中获得了肯定数量的社区用户，并尝试了小范畴的商业化反对，它把想法变成事实，对于特定群体是一个好的开源我的项目。然而，从可继续倒退角度，进行保护是一个更感性的抉择。只管，可能看到社区用户依然在公布一些 RancherOS 的衍生版本 BurmillaOS（https://burmillaos.org/）。

cOS-toolkit 接棒下一程

cOS-toolkit 是一个构建 ContainerOS 的工具包，之前 RancherOS 自身就是一个 Linux 发行版，而 cOS-toolkit 提供了构建这种发行版更弱小的形象能力。汲取之前的一些开源我的项目教训，联合当下市场的支流需要，cOS-toolkit 能够带来以下要害个性：

  • 应用 Container 形式进行构建和降级。cOS-toolkit 应用了开源工具 luet（https://github.com/mudler/luet），luet 是一个基于容器的多平台包管理工具。cOS-toolkit 的外围能力就来自于 luet，cOS-toolkit 自身就保护了若干 luet packages（https://github.com/rancher-sa…）。在各种 Linux 发行版的根底镜像之上，叠加这些 packages，就能够基于 Dockerfile 的模式构建 Container OS。这种作法能够依靠每个 Linux 发行版背地弱小的社区，cOS-toolkit 无需关注某个软件包如何编译集成，也不会毁坏每个发行版发烧友的应用习惯。

  • 反对 OTA 更新。这个个性还处在一直进化中，Container OS 的 OTA 能够将更新内容构建后公布到镜像仓库中，通过 Kubernetes 的扩大编排能力来进行所有节点的系统升级，降级动作触发特定容器镜像更新，并利用到 cOS-toolkit 构建的 OS 中。

  • Cloud-init 反对，基于 systemd，以及不可变个性。Cloud-init 的反对能力间接反映了在私有云环境的敌对水平上；而基于 systemd 是可持续性倒退的一个重要抉择；对 Immutable 的反对在整个设计中具备优先权，这是简直所有 Container OS 的标配属性。
  • 简略不便的自定义。cOS-toolkit 不再只是一种发行版，它提供了更弱小的自定义构建能力，用户除了能够援用 cOS-toolkit 中保护的 packages，还能够自定义 package 进行扩大，同时 cOS-toolkit 自身还简化了各种 OEM 配置（https://rancher-sandbox.githu…），更换 branding 以及变更初始用户名明码会非常简单。弱小的自定义能力，还让用户能够针对云环境或者边缘环境等硬件规格个性来构建特定的 OS，针对各种硬件环境的驱动和软件包自身就依靠背地弱小的发行版社区，无论品质还是兼容性都有可靠保证。

cOS-toolkit 工程会默认构建一些根底发行版：

  • Blue：基于 Fedora
  • Green：基于 openSUSE
  • Orange：基于 Ubuntu

因为外围工程人员来自 SUSE，基于 openSUSE 的变种会进行较完整的测试，这些镜像介质能够在 Github Release（https://github.com/rancher-sa…）中下载。

SUSE Rancher 曾经开始用 cOS-toolkit 构建一些新兴产品，比方 Harvester OS 以及 RancherOS v2。前者提供了 Harvester 集群的底座 OS，便于 Harvester 对节点进行更深层次的治理；后者将来将致力于提供能够面向 Rancher 以及 K3s/RKE2 的底座 OS，进一步简化产品部署和运维难度。RancherOS v2 也处于开源踊跃孵化中：https://github.com/rancher-sa…

cOS-toolkit 初体验

反对私有云的敌对体验曾经是新兴操作系统的标配，cOS-toolkit 构建的 Green（基于 openSUSE）变种齐全反对 AWS/Azure/GCP 等私有云。咱们以 AWS 版本为例进行初始体验，AMI 信息能够在 Github Release（https://github.com/rancher-sa…）中下载到，本文体验版本为 v0.7.4。

因为这些 AMI 在构建时默认应用 UEFI 形式启动，所以局部实例类型无奈反对，本次体验应用 t3.large。

默认状况下，零碎初始会进入 Recovery 模式，用户能够在该模式下进行自定义装置，通过内置的装置工具配合预约义的 YAML 配置进行零碎初始化装置。不过，因为咱们应用 AWS 云环境，咱们能够借助 cloud-init 机制来简化这一过程。在基于 cOS AMI 启动实例时（根磁盘 16GiB），配置以下 cloud-init 内容：

name: "Default deployment"
stages:
   rootfs.after:
     - name: "Repart image"
       layout:
         # It will partition a device including the given filesystem label or part label (filesystem label matches first)
         device:
           label: COS_RECOVERY
         add_partitions:
           - fsLabel: COS_STATE
             # 10Gb for COS_STATE, so the disk should have at least 16Gb
             size: 10240
             pLabel: state
           - fsLabel: COS_PERSISTENT
             # unset size or 0 size means all available space
             pLabel: persistent
   initramfs:
     - if: '[-f"/run/cos/recovery_mode"]'
       name: "Set sshd to wait for deployment"
       files:
       - path: "/etc/systemd/system/sshd.service.d/override.conf"
         content: |
             [Unit]
             After=cos-setup-network.service
   network:
     - if: '[-f"/run/cos/recovery_mode"]'
       name: "Deploy cos-system"
       commands:
         - |
             cos-deploy --no-verify --no-cosign && shutdown -r now

这份 cloud-init userdata 会帮忙咱们布局根磁盘分区表信息，同时进行初始化装置。留神 cos-deploy 时如果没有指定版本，则会装置最新版本。这意味着只管咱们应用 v0.7.4 的 AMI，但在 cos-deploy 后会在源中寻找更新的版本来部署到根磁盘中，这其实也是 OTA 更新机制的一部分。

零碎装置初始化结束后，能够通过 ssh 拜访，因为还没有残缺适配 AWS 的 metadata，所以临时还是应用 user/password 形式拜访，且咱们没有在 userdata 中更改明码，故能够应用默认用户名和明码 root/cos。整个零碎会异样洁净简洁，因为 Green 变种应用 openSUSE 发行版为根底，其内核版本也与 openSUSE 15.3  保持一致，零碎版本也同时追踪到 v0.8.2。

除了应用 cloud-init 机制装置零碎外，还能够手动应用 cos-deploy 进行装置，能够在执行过程中清晰看到拉取了 v0.8.2 较新的零碎镜像。

当然，咱们也能够制作自定义镜像并推送到镜像仓库中，零碎镜像的构建能够依靠 Dockerfile 机制。以 Github Repo 中的 standard example（https://github.com/rancher-sa…）为例，根底镜像应用 openSUSE 后，通过在 Dockerfile 中执行 zypper 来装置软件包，而这些软件包则依靠弱小的社区来保障品质：

ARG LUET_VERSION=0.20.6
FROM quay.io/luet/base:$LUET_VERSION AS luet


FROM opensuse/leap:15.3


ENV COSIGN_EXPERIMENTAL=1
ENV COSIGN_REPOSITORY=raccos/releases-green


ARG ARCH=amd64
ENV ARCH=${ARCH}
RUN zypper in -y \
    bash-completion \
    conntrack-tools \
    coreutils \
    curl \
    device-mapper \
    dosfstools \
    dracut \
    kernel-default \
    kernel-firmware-bnx2 \
    kernel-firmware-i915 \
    kernel-firmware-intel \
    kernel-firmware-iwlwifi \
    kernel-firmware-mellanox \
    kernel-firmware-network \
    kernel-firmware-platform \
    kernel-firmware-realtek \
    less \
…
…

咱们把这个 Dockerfile 构建成容器镜像（如：niusmallnan/containeros:dev），并推送到 Dockerhub。在方才曾经启动的 AWS VM 执行：cos-upgrade –no-verify –reboot -d niusmallnan/containeros:dev，主动重启后，咱们能够取得一个新版本的 OS，这就是基于容器模式的 OTA 更新的根底演示。拜访虚拟机能够看到，无论是 OS 版本信息，内置软件包，以及内核版本均产生了变动：

cOS-toolkit 还在不断完善中，很多细节还有优化空间。cOS-toolkit  并不是在继续提供某个发行版，而是保护构建个性化 Container OS 的工具集，用户能够依靠它进行 OS 的制作和公布，同时享受其带来的容器镜像格调的 OTA 更新机制。

更多内容请参考官网文档：https://rancher-sandbox.githu…

正文完
kubernetes
发表至： kubernetes
2022-03-11
 0
关于kubernetes:云原生时代的DevOps平台设计之道
关于kubernetes:K8S-笔记-实操之-Kubectl-日志输出详细程度和调试
关于kubernetes:不背锅运维K8S之污点污点容忍
关于云原生:阿里巴巴云原生-etcd-服务集群管控优化实践

站内搜索

-「」