5.5. 基于 Helm 的 Operator
5.5.1. 基于 Helm 的 Operator 的 operator SDK 指南
Operator 开发人员可以利用 Operator SDK 中的 Helm 支持来为 Nginx 构建基于 Helm 的 Operator 示例,并管理其生命周期。本教程介绍了以下过程:
- 创建 Nginx 部署
-
确保部署大小与
Nginx
自定义资源(CR)spec 指定的大小相同 -
使用 status writer 带有
nginx
Pod 的名称来更新Nginx
CR 状态
红帽支持的 Operator SDK CLI 工具版本,包括 Operator 项目的相关构建和测试工具已被弃用,计划在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序错误修复和支持,但此功能将不再获得改进,并将在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。
对于创建新 Operator 项目,不建议使用红帽支持的 Operator SDK 版本。现有 Operator 项目的 Operator 作者可以使用 Red Hat OpenShift Service on AWS 4 发布的 Operator SDK CLI 工具版本来维护其项目,并创建针对较新版本的 Red Hat OpenShift Service on AWS 的 Operator 发行版本。
以下与 Operator 项目相关的基础镜像 没有被弃用。这些基础镜像的运行时功能和配置 API 仍然会有程序错误修复和并提供对相关 CVE 的解决方案。
- 基于 Ansible 的 Operator 项目的基础镜像
- 基于 Helm 的 Operator 项目的基础镜像
有关 Operator SDK 不支持的、社区维护版本的信息,请参阅 Operator SDK (Operator Framework)。
通过以下两个 Operator Framework 核心组件来完成此过程:
- Operator SDK
-
operator-sdk
CLI 工具和controller-runtime
库 API - Operator Lifecycle Manager (OLM)
- 集群中 Operator 的安装、升级和基于角色的访问控制(RBAC)
5.5.1.1. 前提条件
- 已安装 operator SDK CLI
-
已安装 OpenShift CLI (
oc
) 4+ -
使用具有
dedicated-admin
权限的oc
登录到 Red Hat OpenShift Service on AWS 集群 - 要允许集群拉取镜像,推送镜像的存储库必须设置为公共的存储库,或必须配置一个镜像 pull secret
5.5.1.2. 创建一个项目
使用 Operator SDK CLI 创建名为 nginx-operator
的项目。
流程
为项目创建一个目录:
$ mkdir -p $HOME/projects/nginx-operator
进入该目录:
$ cd $HOME/projects/nginx-operator
使用
helm
插件运行operator-sdk init
命令以初始化项目:$ operator-sdk init \ --plugins=helm \ --domain=example.com \ --group=demo \ --version=v1 \ --kind=Nginx
注意默认情况下,
helm
插件使用样板 Helm Chart 初始化项目。您可以使用其他标记(如--helm-chart
标志)使用现有 Helm chart 初始化项目。init
命令创建nginx-operator
项目,专门用于监视 API 版本为example.com/v1
和 kindNginx
的资源。-
对于基于 Helm 的项目,
init
命令根据 chart 的默认清单部署的资源,在config/rbac/role.yaml
文件中生成 RBAC 规则。验证此文件生成的规则是否满足 Operator 的权限要求。
5.5.1.2.1. 现有 Helm chart
您可以使用以下标记,而不是使用样板 Helm Chart 创建项目,而是使用现有 chart(可以从本地文件系统或远程 Chart 仓库中)使用现有 chart:
-
--helm-chart
-
--helm-chart-repo
-
--helm-chart-version
如果指定了 --helm-chart
标志,--group
、--version
和 --kind
标志将变为可选。如果保留未设置,则使用以下默认值:
标记 | 值 |
---|---|
|
|
|
|
|
|
| 从指定的 chart 中分离 |
如果 --helm-chart
标志指定本地 chart 归档,如 example-chart-1.2.0.tgz
或目录,则 chart 被验证并解包或复制到项目中。否则,Operator SDK 会尝试从远程存储库中获取 chart。
如果没有通过 --helm-chart-repo
标志指定自定义存储库 URL,则支持以下 chart 引用格式:
格式 | 描述 |
---|---|
|
从名为 |
| 通过指定的 URL 获取 Helm Chart 归档。 |
如果自定义仓库 URL 由 --helm-chart-repo
指定,则支持以下 chart 引用格式:
格式 | 描述 |
---|---|
|
在由 |
如果 --helm-chart-version
标志未设置,Operator SDK 会获取最新可用的 Helm Chart 版本。否则,它会获取指定的版本。当使用 --helm-chart
标记指定一个特定版本(例如一个本地路径或 URL)的 chart 时,--helm-chart-version
标志不会被使用。
如需更多详细信息和示例,请运行:
$ operator-sdk init --plugins helm --help
5.5.1.2.2. PROJECT 文件
operator-sdk init
命令生成的文件中是一个 Kubebuilder PROJECT
文件。从项目 root 运行的后续 operator-sdk
命令以及 help
输出可读取该文件,并注意项目类型是 Helm。例如:
domain: example.com layout: - helm.sdk.operatorframework.io/v1 plugins: manifests.sdk.operatorframework.io/v2: {} scorecard.sdk.operatorframework.io/v2: {} sdk.x-openshift.io/v1: {} projectName: nginx-operator resources: - api: crdVersion: v1 namespaced: true domain: example.com group: demo kind: Nginx version: v1 version: "3"
5.5.1.3. 了解 Operator 逻辑
在本例中,nginx-operator
项目会针对每个 Nginx
自定义资源 (CR) 执行以下协调逻辑:
- 如果尚无 Nginx 部署,请创建一个。
- 如果尚无 Nginx 服务,请创建一个。
- 如果被启用且不存在,请创建一个 Nginx ingress。
-
确保部署、服务和可选入口与
Nginx
CR 指定的配置匹配,如副本数、镜像和服务类型。
默认情况下,nginx-operator
项目会监视 Vginx
资源事件,如 watches.yaml
文件中所示,并使用指定 Chart 执行 Helm 发行版本:
# Use the 'create api' subcommand to add watches to this file. - group: demo version: v1 kind: Nginx chart: helm-charts/nginx # +kubebuilder:scaffold:watch
5.5.1.3.1. Helm chart 示例
创建 Helm Operator 项目后,Operator SDK 会创建一个 Helm Chart 示例,其中包含一组模板,用于简单的 Nginx 发行版本。
本例中,针对部署、服务和 Ingress 资源提供了模板,另外还有 NOTES.txt
模板,Helm Chart 开发人员可利用该模板传达有关发型版本的实用信息。
如果您对 Helm chart 有一定的了解,请参阅 Helm 开发人员文档。
5.5.1.3.2. 修改自定义资源规格
Helm 使用名为 values 的概念来自定义 Helm Chart 的默认配置,该 chart 在 values.yaml
文件中定义。
您可以通过在自定义资源(CR)spec 中设置所需的值来覆盖这些默认值。以副本数量为例。
流程
在默认情况下,
helm-charts/nginx/values.yaml
文件有一个设置为1
的名为replicaCount
的值。要在部署中有两个 Nginx 实例,您的 CR spec 必须包含replicaCount: 2
。编辑
config/samples/demo_v1_nginx.yaml
文件以设置replicaCount: 2
:apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample ... spec: ... replicaCount: 2
同样,服务端口默认设置为
80
。要使用8080
,编辑config/samples/demo_v1_nginx.yaml
文件来设置spec.port: 8080
,它会添加服务端口覆盖:apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample spec: replicaCount: 2 service: port: 8080
Helm Operator 应用整个 spec,将其视为 values 文件内容,与 helm install -f ./overrides.yaml
命令的工作方式类似。
5.5.1.4. 启用代理支持
Operator 作者可开发支持网络代理的 Operator。具有 dedicated-admin
角色的管理员配置对 Operator Lifecycle Manager (OLM)处理的环境变量的代理支持。要支持代理集群,Operator 必须检查以下标准代理变量的环境,并将值传递给 Operands:
-
HTTP_PROXY
-
HTTPS_PROXY
-
NO_PROXY
本教程使用 HTTP_PROXY
作为示例环境变量。
前提条件
- 启用了集群范围的出口代理的集群。
流程
通过添加
overrideValues
字段来编辑watches.yaml
文件,使其包含基于环境变量的覆盖:... - group: demo.example.com version: v1alpha1 kind: Nginx chart: helm-charts/nginx overrideValues: proxy.http: $HTTP_PROXY ...
在
helm-charts/nginx/values.yaml
文件中添加proxy.http
值:... proxy: http: "" https: "" no_proxy: ""
要确保 Chart 模板支持使用变量,请编辑
helm-charts/nginx/templates/deployment.yaml
文件中的 chart 模板,使其包含以下内容:containers: - name: {{ .Chart.Name }} securityContext: - toYaml {{ .Values.securityContext | nindent 12 }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}" imagePullPolicy: {{ .Values.image.pullPolicy }} env: - name: http_proxy value: "{{ .Values.proxy.http }}"
通过在
config/manager/manager.yaml
文件中添加以下内容来设置 Operator 部署上的环境变量:containers: - args: - --leader-elect - --leader-election-id=ansible-proxy-demo image: controller:latest name: manager env: - name: "HTTP_PROXY" value: "http_proxy_test"
5.5.1.5. 运行 Operator
要构建并运行 Operator,请使用 Operator SDK CLI 捆绑 Operator,然后使用 Operator Lifecycle Manager (OLM)部署到集群中。
如果要在 OpenShift Container Platform 集群上部署 Operator 而不是 Red Hat OpenShift Service on AWS 集群,则有两个部署选项:
- 作为 Go 程序在集群外本地运行。
- 作为集群的部署运行。
5.5.1.5.1. 捆绑 Operator 并使用 Operator Lifecycle Manager 进行部署
5.5.1.5.1.1. 捆绑 Operator
Operator 捆绑包格式是 Operator SDK 和 Operator Lifecycle Manager(OLM)的默认打包方法。您可以使用 Operator SDK 来构建和推送 Operator 项目作为捆绑包镜像,使 Operator 可供 OLM 使用。
前提条件
- 在开发工作站上安装 operator SDK CLI
-
已安装 OpenShift CLI (
oc
) v4+ - 使用 Operator SDK 初始化 operator 项目
流程
在 Operator 项目目录中运行以下
make
命令来构建和推送 Operator 镜像。在以下步骤中修改IMG
参数来引用您可访问的库。您可以获取在存储库站点(如 Quay.io)存储容器的帐户。构建镜像:
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
注意由 SDK 为 Operator 生成的 Dockerfile 需要为
go build
明确引用GOARCH=amd64
。这可以在非 AMD64 构架中使用GOARCH=$TARGETARCH
。Docker 自动将环境变量设置为-platform
指定的值。对于 Buildah,需要使用-build-arg
来实现这一目的。如需更多信息,请参阅多个架构。将镜像推送到存储库:
$ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
运行
make bundle
命令创建 Operator 捆绑包清单,该命令调用多个命令,其中包括 Operator SDKgenerate bundle
和bundle validate
子命令:$ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
Operator 的捆绑包清单描述了如何显示、创建和管理应用程序。
make bundle
命令在 Operator 项目中创建以下文件和目录:-
包含
ClusterServiceVersion
对象的捆绑包清单目录,名为bundle/manifests
-
名为
bundle/metadata
的捆绑包元数据目录 -
config/crd
目录中的所有自定义资源定义(CRD) -
一个 Dockerfile
bundle.Dockerfile
然后,使用
operator-sdk bundle validate
自动验证这些文件,以确保磁盘上的捆绑包的格式是正确的。-
包含
运行以下命令来构建和推送捆绑包镜像。OLM 使用索引镜像来消耗 Operator 捆绑包,该镜像引用一个或多个捆绑包镜像。
构建捆绑包镜像。使用您要推送镜像的 registry、用户命名空间和镜像标签的详情,设置
BUNDLE_IMG
:$ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
推送捆绑包镜像:
$ docker push <registry>/<user>/<bundle_image_name>:<tag>
5.5.1.5.1.2. 使用 Operator Lifecycle Manager 部署 Operator
Operator Lifecycle Manager(OLM)可帮助您在 Kubernetes 集群中安装、更新和管理 Operator 及其相关服务的生命周期。OLM 默认安装在 Red Hat OpenShift Service on AWS 上,并作为 Kubernetes 扩展运行,以便您可以在没有任何额外工具的情况下对所有 Operator 生命周期管理功能使用 Web 控制台和 OpenShift CLI (oc
)。
Operator Bundle Format 是 Operator SDK 和 OLM 的默认打包方法。您可以使用 Operator SDK 在 OLM 上快速运行捆绑包镜像,以确保它正确运行。
前提条件
- 在开发工作站上安装 operator SDK CLI
- 构建并推送到 registry 的 Operator 捆绑包镜像
-
OLM 安装在一个基于 Kubernetes 的集群上(如果使用
apiextensions.k8s.io/v1
CRD,则为 v1.16.0 或更新版本,如 Red Hat OpenShift Service on AWS 4) -
使用具有
dedicated-admin
权限的账户使用oc
登录到集群
流程
输入以下命令在集群中运行 Operator:
$ operator-sdk run bundle \1 -n <namespace> \2 <registry>/<user>/<bundle_image_name>:<tag> 3
重要从 Red Hat OpenShift Service on AWS 4.11 开始,
run bundle
命令默认支持 Operator 目录的基于文件的目录格式。Operator 目录已弃用的 SQLite 数据库格式仍被支持,但将在以后的发行版本中删除。建议 Operator 作者将其工作流迁移到基于文件的目录格式。这个命令执行以下操作:
- 创建引用捆绑包镜像的索引镜像。索引镜像不透明且具有临时性,但准确反映了如何将捆绑包添加到生产中的目录中。
- 创建指向新索引镜像的目录源,以便 OperatorHub 能够发现 Operator。
-
通过创建一个
OperatorGroup
、Subscription
、InstallPlan
和所有其他所需资源(包括 RBAC),将 Operator 部署到集群中。
5.5.1.6. 创建自定义资源
安装 Operator 后,您可以通过创建一个由 Operator 在集群中提供的自定义资源(CR)来测试它。
先决条件
-
Nginx Operator 示例,它提供了
Nginx
CR,在集群中安装
流程
切换到安装 Operator 的命名空间。例如,如果使用
make deploy
命令部署 Operator:$ oc project nginx-operator-system
编辑
config/samples/demo_v1_nginx.yaml
中的Nginx
CR 清单示例,使其包含以下规格:apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample ... spec: ... replicaCount: 3
Nginx 服务帐户需要特权访问权限才能在 Red Hat OpenShift Service on AWS 中运行。将以下安全性上下文约束 (SCC) 添加到
nginx-sample
pod 的服务帐户中:$ oc adm policy add-scc-to-user \ anyuid system:serviceaccount:nginx-operator-system:nginx-sample
创建 CR:
$ oc apply -f config/samples/demo_v1_nginx.yaml
确保
Nginx
Operator 为示例 CR 创建部署,其大小正确:$ oc get deployments
输出示例
NAME READY UP-TO-DATE AVAILABLE AGE nginx-operator-controller-manager 1/1 1 1 8m nginx-sample 3/3 3 3 1m
检查 pod 和 CR 状态,以确认其状态是否使用 Nginx pod 名称更新。
检查 pod:
$ oc get pods
输出示例
NAME READY STATUS RESTARTS AGE nginx-sample-6fd7c98d8-7dqdr 1/1 Running 0 1m nginx-sample-6fd7c98d8-g5k7v 1/1 Running 0 1m nginx-sample-6fd7c98d8-m7vn7 1/1 Running 0 1m
检查 CR 状态:
$ oc get nginx/nginx-sample -o yaml
输出示例
apiVersion: demo.example.com/v1 kind: Nginx metadata: ... name: nginx-sample ... spec: replicaCount: 3 status: nodes: - nginx-sample-6fd7c98d8-7dqdr - nginx-sample-6fd7c98d8-g5k7v - nginx-sample-6fd7c98d8-m7vn7
更新部署大小。
更新
config/samples/demo_v1_nginx.yaml
文件,将Nginx
CR 中的spec.size
字段从3
改为5
:$ oc patch nginx nginx-sample \ -p '{"spec":{"replicaCount": 5}}' \ --type=merge
确认 Operator 已更改部署大小:
$ oc get deployments
输出示例
NAME READY UP-TO-DATE AVAILABLE AGE nginx-operator-controller-manager 1/1 1 1 10m nginx-sample 5/5 5 5 3m
运行以下命令来删除 CR:
$ oc delete -f config/samples/demo_v1_nginx.yaml
清理本教程中创建的资源。
如果使用
make deploy
命令来测试 Operator,请运行以下命令:$ make undeploy
如果使用
operator-sdk run bundle
命令来测试 Operator,请运行以下命令:$ operator-sdk cleanup <project_name>
5.5.1.7. 其他资源
5.5.2. 基于 Helm 的 Operator 的项目布局
operator-sdk
CLI 可为每个 Operator 项目生成或 scaffold 多个 软件包和文件。
红帽支持的 Operator SDK CLI 工具版本,包括 Operator 项目的相关构建和测试工具已被弃用,计划在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序错误修复和支持,但此功能将不再获得改进,并将在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。
对于创建新 Operator 项目,不建议使用红帽支持的 Operator SDK 版本。现有 Operator 项目的 Operator 作者可以使用 Red Hat OpenShift Service on AWS 4 发布的 Operator SDK CLI 工具版本来维护其项目,并创建针对较新版本的 Red Hat OpenShift Service on AWS 的 Operator 发行版本。
以下与 Operator 项目相关的基础镜像 没有被弃用。这些基础镜像的运行时功能和配置 API 仍然会有程序错误修复和并提供对相关 CVE 的解决方案。
- 基于 Ansible 的 Operator 项目的基础镜像
- 基于 Helm 的 Operator 项目的基础镜像
有关 Operator SDK 不支持的、社区维护版本的信息,请参阅 Operator SDK (Operator Framework)。
5.5.2.1. 基于 Helm 的项目布局
使用 operator-sdk init --plugins helm
命令生成的基于 Helm 的 Operator 项目包含以下目录和文件:
文件/文件夹 | 用途 |
---|---|
| kustomize 清单,用于在 Kubernetes 集群上部署 Operator。 |
|
Helm Chart 使用 |
|
用于使用 |
| Group/version/kind(GVK)和 Helm Chart 的位置。 |
| 用于管理项目的目标。 |
| 包含 Operator 元数据信息的 YAML 文件。 |
5.5.3. 为较新的 Operator SDK 版本更新基于 Helm 的项目
Red Hat OpenShift Service on AWS 4 支持 Operator SDK 1.36.1。如果已在工作站上安装了 1.31.0 CLI,您可以通过安装最新版本将 CLI 更新至 1.36.1。???
红帽支持的 Operator SDK CLI 工具版本,包括 Operator 项目的相关构建和测试工具已被弃用,计划在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序错误修复和支持,但此功能将不再获得改进,并将在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。
对于创建新 Operator 项目,不建议使用红帽支持的 Operator SDK 版本。现有 Operator 项目的 Operator 作者可以使用 Red Hat OpenShift Service on AWS 4 发布的 Operator SDK CLI 工具版本来维护其项目,并创建针对较新版本的 Red Hat OpenShift Service on AWS 的 Operator 发行版本。
以下与 Operator 项目相关的基础镜像 没有被弃用。这些基础镜像的运行时功能和配置 API 仍然会有程序错误修复和并提供对相关 CVE 的解决方案。
- 基于 Ansible 的 Operator 项目的基础镜像
- 基于 Helm 的 Operator 项目的基础镜像
有关 Operator SDK 不支持的、社区维护版本的信息,请参阅 Operator SDK (Operator Framework)。
但是,要确保现有 Operator 项目保持与 Operator SDK 1.36.1 的兼容性,需要执行更新的相关步骤才能解决从 1.31.0 以来引入的相关破坏更改。您必须在之前使用 1.31.0 创建或维护的任何 Operator 项目中手动执行更新步骤。
5.5.3.1. 为 Operator SDK 1.36.1 更新基于 Helm 的 Operator 项目
以下流程更新了基于 Helm 的 Operator 项目,以便与 1.36.1 兼容。
前提条件
- 已安装 operator SDK 1.36.1
- 使用 Operator SDK 1.31.0 创建或维护的 Operator 项目
流程
编辑 Operator 项目的 Makefile,将 Operator SDK 版本更新至
v1.36.1-ocp
,如下例所示:Makefile 示例
# Set the Operator SDK version to use. By default, what is installed on the system is used. # This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit. OPERATOR_SDK_VERSION ?= v1.36.1-ocp
更新
kube-rbac-proxy
容器,以使用基于 Red Hat Enterprise Linux (RHEL) 9 的镜像:在以下文件中找到
kube-rbac-proxy
容器的条目:-
config/default/manager_auth_proxy_patch.yaml
-
Operator 项目的
bundle/manifests/<operator_name>.clusterserviceversion.yaml
,如教程中的memcached-operator.clusterserviceversion.yaml
-
将 pull spec 中的镜像名称从
ose-kube-rbac-proxy
更新至ose-kube-rbac-proxy-rhel9
,并将标签更新为v4
:ose-kube-rbac-proxy-rhel9
使用v4
镜像标签拉取 spec 示例# ... containers: - name: kube-rbac-proxy image: registry.redhat.io/openshift4/ose-kube-rbac-proxy-rhel9:v4 # ...
编辑 Operator 的 Dockerfile,将
ose-helm-rhel9-operator
镜像标签更新为4
,如下例所示:Dockerfile 示例
FROM registry.redhat.io/openshift4/ose-helm-rhel9-operator:v4
-
kustomize/v2
插件现在稳定,在使用go/v4
,ansible/v1
,helm/v1
, 和hybrid/v1-alpha
插件时,插件链中使用的默认版本。有关此默认构建的更多信息,请参阅 Kubebuilder 文档中的 Kustomize v2。 如果您的 Operator 项目使用多平台或多架构,构建,将现有
docker-buildx
目标替换为项目 Makefile 中的以下定义:Makefile 示例
docker-buildx: ## Build and push the Docker image for the manager for multi-platform support - docker buildx create --name project-v3-builder docker buildx use project-v3-builder - docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile . - docker buildx rm project-v3-builder
您必须将 Operator 项目中的 Kubernetes 版本升级到使用 1.29。必须在项目结构、Makefile 和
go.mod
文件中进行以下更改。重要Kubebuilder 弃用
go/v3
插件,因此 Operator SDK 也会在以后的版本中迁移到go/v4
。更新您的
go.mod
文件以升级您的依赖项:k8s.io/api v0.29.2 k8s.io/apimachinery v0.29.2 k8s.io/client-go v0.29.2 sigs.k8s.io/controller-runtime v0.17.3
运行以下命令来下载升级的依赖项:
$ go mod tidy
通过进行以下更改来更新 Makefile 中的 Kustomize 版本:
- curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.2.1/kustomize_v5.2.1_$(OS)_$(ARCH).tar.gz | \ + curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.0/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \
5.5.3.2. 其他资源
5.5.4. Operator SDK 中的 Helm 支持
红帽支持的 Operator SDK CLI 工具版本,包括 Operator 项目的相关构建和测试工具已被弃用,计划在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序错误修复和支持,但此功能将不再获得改进,并将在以后的 Red Hat OpenShift Service on AWS 发行版本中删除。
对于创建新 Operator 项目,不建议使用红帽支持的 Operator SDK 版本。现有 Operator 项目的 Operator 作者可以使用 Red Hat OpenShift Service on AWS 4 发布的 Operator SDK CLI 工具版本来维护其项目,并创建针对较新版本的 Red Hat OpenShift Service on AWS 的 Operator 发行版本。
以下与 Operator 项目相关的基础镜像 没有被弃用。这些基础镜像的运行时功能和配置 API 仍然会有程序错误修复和并提供对相关 CVE 的解决方案。
- 基于 Ansible 的 Operator 项目的基础镜像
- 基于 Helm 的 Operator 项目的基础镜像
有关 Operator SDK 不支持的、社区维护版本的信息,请参阅 Operator SDK (Operator Framework)。
5.5.4.1. Helm chart
通过 Operator SDK 生成 Operator 项目的其中一种方案是利用现有 Helm Chart 来部署 Kubernetes 资源作为统一应用程序,而无需编写任何 Go 代码。这种基于 Helm 的 Operator 非常适合于推出时所需逻辑极少的无状态应用程序,因为更改应该应用于作为 Chart 一部分生成的 Kubernetes 对象。这听起来似乎很有局限性,但就 Kubernetes 社区构建的 Helm Chart 的增长而言,这足以满足它们的大量用例需要。
Operator 的主要功能是从代表应用程序实例的自定义对象中读取数据,并使其所需状态与正在运行的状态相匹配。对于基于 Helm 的 Operator,对象的 spec
字段是一个配置选项列表,通常在 Helm values.yaml
文件中描述。您可以不使用 Helm CLI(如 helm install -f values.yaml
)来通过标志设置这些值,而是在自定义资源 (CR) 中表达这些值,因为 CR 作为原生 Kubernetes 对象能够实现应用的 RBAC 以及审核跟踪所带来的好处。
举一个名为 Tomcat
的简单 CR 示例:
apiVersion: apache.org/v1alpha1 kind: Tomcat metadata: name: example-app spec: replicaCount: 2
replicaCount
值(本例中为 2
)会被传播到使用以下内容的 Chart 模板中:
{{ .Values.replicaCount }}
构建并部署完 Operator 后,您可通过新建一个 CR 实例来部署新的应用实例,或使用 oc
命令列出所有环境中运行的不同实例:
$ oc get Tomcats --all-namespaces
不要求使用 Helm CLI 或安装 Tiller;基于 Helm 的 Operator 会从 Helm 项目中导入代码。您要做的只是运行一个 Operator 实例,并使用自定义资源定义 (CRD) 注册 CR。因其遵循 RBAC,所以可以更容易防止生产环境改变。