Skip to main content

Command Palette

Search for a command to run...

换马甲:十分钟 Helm 变 Operator

Updated
2 min read

Operator 是一种将传统运维思路转换为 Kubernetes CRD 控制的方法,利用 CRD 对软件部署和配置进行定义,整个部署和管理过程在 Kubernetes 角度上来看,都是一个可见、可审计的行为,这无疑对运维工作是大有裨益的。CoreOS 也提供了 Operator Framwork 用于进行 Operator 的开发,不过门槛还是稍高的。如果放低要求,是否能有一个折衷方案?

CoreOS 为最近加入 CNCF 的 Helm 提供了一个小工具,可以无需编程操作,较为方便的将 Helm Chart 转换为 Operator,并将原有的 values.yaml 更替为 CR 资源进行操作,对于无状态应用的部署流程,可以说是比较便利了。下面就随便举个例子,看看这马甲是怎么换的。

目前版本相当幼稚,看看就好了。

准备工作

首先是一个可操作的 Kubernetes 集群,要求版本为 1.9+。 接下来要有一个可操作的 Helm 客户端(无需 Tiller 部署),用于下载 Chart。

使用 git 获取 Helm app operator kit

$ git clone https://github.com/operator-framework/helm-app-operator-kit.git
Cloning into 'helm-app-operator-kit'...
...
Resolving deltas: 100% (58/58), done.

镜像构建

下载一个实验 Chart 并解压

$ helm fetch stable/memcached
$ tar xf memcached-2.2.0.tgz
$ ls -la
...
-rw-r--r--   1 dustise  wheel    680  8 30 11:50 Dockerfile
...
drwxr-xr-x  10 dustise  wheel    320  8 30 11:50 helm-app-operator
drwxr-xr-x   7 dustise  wheel    224  8 30 11:52 memcached
...

这里的 Dockerfile 可以略微关注一下:

FROM golang:1.10 as builder
...
RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
...
RUN CGO_ENABLED=0 GOOS=linux go build -o bin/operator cmd/helm-app-operator/main.go
...
FROM alpine:3.6
...
COPY --from=builder /go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/bin/operator /operator
...
CMD ["/operator"]

一个典型的分段构建过程。在 Go 环境中生成可执行文件用于最终镜像的执行。

使用 Dockerfile 进行构建:

docker build -t your-repo:25000/helm/memcached-operator \
    --build-arg HELM_CHART=memcached \
    --build-arg API_VERSION=anywhere.io/v1alpha1 \
    --build-arg KIND=memcached .
  • HELM_CHART:我们之前解压的 Chart 目录。
  • API_VERSION:即将用到的自定义资源的 API 组和版本。
  • KIND:自定义资源名称。

Docker 构建完成之后,将新镜像 Push 到 Kubernetes 可访问的镜像库中。

Operator 部署

构建成功之后,进入 helm-app-operator/deploy 目录,要部署 Operator,首先要修改几个文件。

rbac.yaml

这是 Operator 运行所需的权限设置文件,根据前面的配置,我们需要给他加入两个权限:namespace 以及新建的 CRD 的操作权限。

这里的 RoleBinding 只是绑定到了 default 命名空间的 default ServiceAccount,如果要给 Operator Pod 单独赋权,就要对 subject 进行修改。

文件编辑结束后,就可以使用 kubectl apply 提交到集群运行。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: helm-app-operator
rules:
...
  - secrets
  - namespaces
  verbs:
  - "*"
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  verbs:
  - "*"
...
- apiGroups:
  - anywhere.io
  resources:
  - "*"
  verbs:
  - "*"

crd.yaml

接下来就是自定义资源的定义了。这里需要和前面我们制定的 API 结构相吻合

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: memcacheds.anywhere.io # 资源名 + 组名
spec:
  group: anywhere.io # 组
  names:
    kind: memcached # 对象
    listKind: memcachedList #列表
    plural: memcacheds # 复数形式
    singular: memcached # 单数形式
  scope: Namespaced
  version: v1alpha1 # 版本

同样的,使用 kubectl apply 提交这一定义给 Kubernetes 集群。

operator.yaml

这个文件很简单,是一个 Deployment 对象定义,修改一下镜像名即可,如果 rbac.yaml 中修改了绑定账号,这里也需要修改 Operator 的运行账号。

最后,用 kubectl apply deploy/operator.yaml,即可启动 Operator 的运行了。可以使用 kubectl get po -w 获取运行状况。

创建应用实例

deploy 目录中还有另外一个文件:cr.yaml,就是我们的自定义资源实例文件。过去需要在 Chart 的 values.yaml 中编写的内容,现在需要在这里完成了。通过 helm inspect stable/memcached 命令,可以看到其中支持的参数列表。这里我们可以设置一下,用来创建一个 3 实例的集群:

apiVersion: anywhere.io/v1alpha1
kind: memcached
metadata:
  name: memcached-yy
  labels:
    app: example-app
spec:
  replicaCount: 3

使用 kubectl apply 提交之后,可以看到集群上开始创建这一实例:

$ kubectl get po
...
helm-app-operator-memcached-yy-0      1/1       Running            0          10h
helm-app-operator-memcached-yy-1      1/1       Running            0          10h
helm-app-operator-memcached-yy-2      1/1       Running            0          10h
...

这里 Operator Pod 可能会崩溃,删除即可正常工作😄。

查询实例情况:

$ kubectl get memcached
NAME           CREATED AT
memcached-r    10h
memcached-yy   10h

删除实例

$ kubectl delete memcached memcached-yy
memcached.anywhere.io "memcached-yy" deleted

再次使用 kubectl get po,会发现对应 Pod 已经删除。

结语

CoreOS 再次提供了一个有趣的方向,有效的降低了 Operator 的入门门槛。但是这一方案除了成熟度相当不足之外,Helm 本身对运维的支持其实也是非常弱的,对有状态应用是无论如何不能使用这种方式来进行运维的。——马甲,只是马甲。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts