流程

1. 针对此流程在 OpenShift Container Platform Web 控制台中新建一个项目。这个示例使用名为 my-etcd 的项目。

2. 导航至 Operators → Installed Operators 页面。由集群管理员安装到集群且可供使用的 Operator 将以集群服务版本（CSV）列表形式显示在此处。CSV 用于启动和管理由 Operator 提供的软件。

   提示

   使用以下命令从 CLI 获得该列表：

   $ oc get csv

3. 在 Installed Operators 页面中，点 etcd Operator 查看更多详情和可用操作。

   正如 Provided API 下所示，该 Operator 提供了三类新资源，包括一种用于 etcd Cluster 的资源（EtcdCluster 资源）。这些对象的工作方式与内置的原生 Kubernetes 对象（如 Deployment 或 ReplicaSet ）相似，但包含特定于管理 etcd 的逻辑。

4. 新建 etcd 集群：

   1. 在 etcd Cluster API 框中，点 Create instance。
   2. 在下一页上，您可对 EtcdCluster 对象的最小起始模板进行任何修改，比如集群大小。现在，点击 Create 即可完成。点击后即可触发 Operator 启动 pod、服务和新 etcd 集群的其他组件。

5. 点 example etcd 集群，然后点 Resources 选项卡，您可以看到项目现在包含很多由 Operator 自动创建和配置的资源。

   验证已创建了支持您从项目中的其他 pod 访问数据库的 Kubernetes 服务。

6. 给定项目中具有 edit 角色的所有用户均可创建、管理和删除应用程序实例（本例中为 etcd 集群），这些实例由已在项目中创建的 Operator 以自助方式管理，就像云服务一样。如果要赋予其他用户这一权利，项目管理员可使用以下命令添加角色：

   $ oc policy add-role-to-user edit <user> -n <target_project>

流程

1. 在 Web 控制台中导航至 Operators → OperatorHub 页面。

2. 找到您需要的 Operator（滚动页面会在 Filter by keyword 框中输入查找关键字）。例如，输入 advanced 来查找 Advanced Cluster Management for Kubernetes Operator。

   您还可以根据基础架构功能过滤选项。例如，如果您希望 Operator 在断开连接的环境中工作，请选择 Disconnected。

3. 选择要显示更多信息的 Operator。

   注意

   选择 Community Operator 会警告红帽没有认证社区 Operator ; 您必须确认该警告方可继续。

4. 阅读 Operator 信息并单击 Install。

5. 在 Install Operator 页面中：

   1. 选择要在其中安装 Operator 的特定单一命名空间。该 Operator 仅限在该单一命名空间中监视和使用。
   2. 选择一个更新频道（如有多个可用）。
   3. 如前面所述，选择自动或手动批准策略。

6. 点击 Install 使 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。

   1. 如果选择了手动批准策略，订阅的升级状态将保持在 Upgrading 状态，直至您审核并批准安装计划。

      在 Install Plan 页面批准后，订阅的升级状态将变为 Up to date。

   2. 如果选择了 Automatic 批准策略，升级状态会在不用人工参与的情况下变为 Up to date。

7. 在订阅的升级状态成为 Up to date 后，选择 Operators → Installed Operators 来验证已安装 Operator 的 ClusterServiceVersion（CSV）是否最终出现了。状态最终会在相关命名空间中变为 InstallSucceeded。

   注意

   对于 All namespaces…​ 安装模式，状态在 openshift-operators 命名空间中解析为 InstallSucceeded，但如果检查其他命名空间，则状态为 Copied。

   如果没有：

   1. 检查 openshift-operators 项目（如果选择了 A specific namespace…​ 安装模式）中的 openshift-operators 项目中的 pod 的日志，这会在 Workloads → Pods 页面中报告问题以便进一步排除故障。

流程

1. 查看 OperatorHub 中集群可用的 Operator 列表：

   $ oc get packagemanifests -n openshift-marketplace

   输出示例

   NAME                               CATALOG               AGE
   3scale-operator                    Red Hat Operators     91m
   advanced-cluster-management        Red Hat Operators     91m
   amq7-cert-manager                  Red Hat Operators     91m
   ...
   couchbase-enterprise-certified     Certified Operators   91m
   crunchy-postgres-operator          Certified Operators   91m
   mongodb-enterprise                 Certified Operators   91m
   ...
   etcd                               Community Operators   91m
   jaeger                             Community Operators   91m
   kubefed                            Community Operators   91m
   ...

   记录下所需 Operator 的目录。

2. 检查所需 Operator，以验证其支持的安装模式和可用频道：

   $ oc describe packagemanifests <operator_name> -n openshift-marketplace

3. 一个 Operator 组（由 OperatorGroup 对象定义），在其中选择目标命名空间，在其中为与 Operator 组相同的命名空间中的所有 Operator 生成所需的 RBAC 访问权限。

   订阅 Operator 的命名空间必须具有与 Operator 的安装模式相匹配的 Operator 组，可采用 AllNamespaces 模式，也可采用 SingleNamespace 模式。如果您要使用 AllNamespaces 安装 Operator，则 openshift-operators 命名空间已有适当的 Operator 组。

   如果要安装的 Operator 采用 SingleNamespace 模式，而您没有适当的 Operator 组，则必须创建一个。

   注意

   在选择 SingleNamespace 模式时，该流程的 Web 控制台版本会在后台自动为您处理 OperatorGroup 和 Subscription 对象的创建。

   1. 创建 OperatorGroup 对象 YAML 文件，如 operatorgroup.yaml：

      OperatorGroup 对象示例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

   2. 创建 OperatorGroup 对象：

      $ oc apply -f operatorgroup.yaml

4. 创建一个 Subscription 对象 YAML 文件，以便为 Operator 订阅一个命名空间，如 sub.yaml：

   Subscription 对象示例

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: <subscription_name>
     namespace: openshift-operators 1
   spec:
     channel: <channel_name> 2
     name: <operator_name> 3
     source: redhat-operators 4
     sourceNamespace: openshift-marketplace 5
     config:
       env: 6
       - name: ARGS
         value: "-v=10"
       envFrom: 7
       - secretRef:
           name: license-secret
       volumes: 8
       - name: <volume_name>
         configMap:
           name: <configmap_name>
       volumeMounts: 9
       - mountPath: <directory_name>
         name: <volume_name>
       tolerations: 10
       - operator: "Exists"
       resources: 11
         requests:
           memory: "64Mi"
           cpu: "250m"
         limits:
           memory: "128Mi"
           cpu: "500m"
       nodeSelector: 12
         foo: bar

   1

   对于 AllNamespaces 安装模式的使用，指定 openshift-operators 命名空间。否则，为 SingleNamespace 安装模式使用指定相关单一命名空间。

   2

   要订阅的频道的名称。

   3

   要订阅的 Operator 的名称。

   4

   提供 Operator 的目录源的名称。

   5

   目录源的命名空间。将 openshift-marketplace 用于默认的 OperatorHub 目录源。

   6

   env 参数定义必须存在于由 OLM 创建的 pod 中所有容器中的环境变量列表。

   7

   envFrom 参数定义要在容器中填充环境变量的源列表。

   8

   volumes 参数定义 OLM 创建的 pod 上必须存在的卷列表。

   9

   volumeMounts 参数定义由 OLM 创建的 pod 中必须存在的 VolumeMounts 列表。如果 volumeMount 引用不存在的 卷，OLM 无法部署 Operator。

   10

   tolerations 参数为 OLM 创建的 pod 定义 Tolerations 列表。

   11

   resources 参数为 OLM 创建的 pod 中所有容器定义资源限制。

   12

   nodeSelector 参数为 OLM 创建的 pod 定义 NodeSelector。

5. 创建 Subscription 对象：

   $ oc apply -f sub.yaml

   此时，OLM 已了解所选的 Operator。Operator 的集群服务版本（CSV）应出现在目标命名空间中，由 Operator 提供的 API 应可用于创建。

流程

1. 通过设置 startingCSV 字段，创建一个 Subscription 对象 YAML 文件，向带有特定版本的 Operator 订阅一个命名空间。将 installPlanApproval 字段设置为 Manual，以便在目录中存在更新的版本时防止 Operator 自动升级。

   例如，可以使用以下 sub.yaml 文件安装 Red Hat Quay Operator，专门用于版本 3.4.0：

   带有特定起始 Operator 版本的订阅

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: quay-operator
     namespace: quay
   spec:
     channel: quay-v3.4
     installPlanApproval: Manual 1
     name: quay-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: quay-operator.v3.4.0 2

   1

   如果您指定的版本会被目录中的更新版本取代，则将批准策略设置为 Manual。此计划阻止自动升级到更新的版本，且需要在启动 CSV 可以完成安装前手动批准。

   2

   设置 Operator CSV 的特定版本。

2. 创建 Subscription 对象：

   $ oc apply -f sub.yaml

3. 手动批准待处理的安装计划以完成 Operator 安装。

流程

1. 在 Web 控制台中导航至 Operators → OperatorHub 页面。

2. 找到您需要的 Operator（滚动页面会在 Filter by keyword 框中输入查找关键字）。例如，输入 advanced 来查找 Advanced Cluster Management for Kubernetes Operator。

   您还可以根据基础架构功能过滤选项。例如，如果您希望 Operator 在断开连接的环境中工作，请选择 Disconnected。

3. 选择要显示更多信息的 Operator。

   注意

   选择 Community Operator 会警告红帽没有认证社区 Operator ; 您必须确认该警告方可继续。

4. 阅读 Operator 信息并单击 Install。

5. 在 Install Operator 页面中：

   1. 任选以下一项：

      • All namespaces on the cluster (default)，选择该项会将 Operator 安装至默认 openshift-operators 命名空间，以便供集群中的所有命名空间监视和使用。该选项并非始终可用。
      • A specific namespace on the cluster，该项支持您选择单一特定命名空间来安装 Operator。该 Operator 仅限在该单一命名空间中监视和使用。
   2. 选择要在其中安装 Operator 的特定单一命名空间。该 Operator 仅限在该单一命名空间中监视和使用。
   3. 选择一个更新频道（如有多个可用）。
   4. 如前面所述，选择自动或手动批准策略。

6. 点击 Install 使 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。

   1. 如果选择了手动批准策略，订阅的升级状态将保持在 Upgrading 状态，直至您审核并批准安装计划。

      在 Install Plan 页面批准后，订阅的升级状态将变为 Up to date。

   2. 如果选择了 Automatic 批准策略，升级状态会在不用人工参与的情况下变为 Up to date。

7. 在订阅的升级状态成为 Up to date 后，选择 Operators → Installed Operators 来验证已安装 Operator 的 ClusterServiceVersion（CSV）是否最终出现了。状态最终会在相关命名空间中变为 InstallSucceeded。

   注意

   对于 All namespaces…​ 安装模式，状态在 openshift-operators 命名空间中解析为 InstallSucceeded，但如果检查其他命名空间，则状态为 Copied。

   如果没有：

   1. 检查 openshift-operators 项目（如果选择了 A specific namespace…​ 安装模式）中的 openshift-operators 项目中的 pod 的日志，这会在 Workloads → Pods 页面中报告问题以便进一步排除故障。

流程

1. 查看 OperatorHub 中集群可用的 Operator 列表：

   $ oc get packagemanifests -n openshift-marketplace

   输出示例

   NAME                               CATALOG               AGE
   3scale-operator                    Red Hat Operators     91m
   advanced-cluster-management        Red Hat Operators     91m
   amq7-cert-manager                  Red Hat Operators     91m
   ...
   couchbase-enterprise-certified     Certified Operators   91m
   crunchy-postgres-operator          Certified Operators   91m
   mongodb-enterprise                 Certified Operators   91m
   ...
   etcd                               Community Operators   91m
   jaeger                             Community Operators   91m
   kubefed                            Community Operators   91m
   ...

   记录下所需 Operator 的目录。

2. 检查所需 Operator，以验证其支持的安装模式和可用频道：

   $ oc describe packagemanifests <operator_name> -n openshift-marketplace

3. 一个 Operator 组（由 OperatorGroup 对象定义），在其中选择目标命名空间，在其中为与 Operator 组相同的命名空间中的所有 Operator 生成所需的 RBAC 访问权限。

   订阅 Operator 的命名空间必须具有与 Operator 的安装模式相匹配的 Operator 组，可采用 AllNamespaces 模式，也可采用 SingleNamespace 模式。如果您要使用 AllNamespaces 安装 Operator，则 openshift-operators 命名空间已有适当的 Operator 组。

   如果要安装的 Operator 采用 SingleNamespace 模式，而您没有适当的 Operator 组，则必须创建一个。

   注意

   在选择 SingleNamespace 模式时，该流程的 Web 控制台版本会在后台自动为您处理 OperatorGroup 和 Subscription 对象的创建。

   1. 创建 OperatorGroup 对象 YAML 文件，如 operatorgroup.yaml：

      OperatorGroup 对象示例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

   2. 创建 OperatorGroup 对象：

      $ oc apply -f operatorgroup.yaml

4. 创建一个 Subscription 对象 YAML 文件，以便为 Operator 订阅一个命名空间，如 sub.yaml：

   Subscription 对象示例

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: <subscription_name>
     namespace: openshift-operators 1
   spec:
     channel: <channel_name> 2
     name: <operator_name> 3
     source: redhat-operators 4
     sourceNamespace: openshift-marketplace 5
     config:
       env: 6
       - name: ARGS
         value: "-v=10"
       envFrom: 7
       - secretRef:
           name: license-secret
       volumes: 8
       - name: <volume_name>
         configMap:
           name: <configmap_name>
       volumeMounts: 9
       - mountPath: <directory_name>
         name: <volume_name>
       tolerations: 10
       - operator: "Exists"
       resources: 11
         requests:
           memory: "64Mi"
           cpu: "250m"
         limits:
           memory: "128Mi"
           cpu: "500m"
       nodeSelector: 12
         foo: bar

   1

   对于 AllNamespaces 安装模式的使用，指定 openshift-operators 命名空间。否则，为 SingleNamespace 安装模式使用指定相关单一命名空间。

   2

   要订阅的频道的名称。

   3

   要订阅的 Operator 的名称。

   4

   提供 Operator 的目录源的名称。

   5

   目录源的命名空间。将 openshift-marketplace 用于默认的 OperatorHub 目录源。

   6

   env 参数定义必须存在于由 OLM 创建的 pod 中所有容器中的环境变量列表。

   7

   envFrom 参数定义要在容器中填充环境变量的源列表。

   8

   volumes 参数定义 OLM 创建的 pod 上必须存在的卷列表。

   9

   volumeMounts 参数定义由 OLM 创建的 pod 中必须存在的 VolumeMounts 列表。如果 volumeMount 引用不存在的 卷，OLM 无法部署 Operator。

   10

   tolerations 参数为 OLM 创建的 pod 定义 Tolerations 列表。

   11

   resources 参数为 OLM 创建的 pod 中所有容器定义资源限制。

   12

   nodeSelector 参数为 OLM 创建的 pod 定义 NodeSelector。

5. 创建 Subscription 对象：

   $ oc apply -f sub.yaml

   此时，OLM 已了解所选的 Operator。Operator 的集群服务版本（CSV）应出现在目标命名空间中，由 Operator 提供的 API 应可用于创建。

流程

1. 通过设置 startingCSV 字段，创建一个 Subscription 对象 YAML 文件，向带有特定版本的 Operator 订阅一个命名空间。将 installPlanApproval 字段设置为 Manual，以便在目录中存在更新的版本时防止 Operator 自动升级。

   例如，可以使用以下 sub.yaml 文件安装 Red Hat Quay Operator，专门用于版本 3.4.0：

   带有特定起始 Operator 版本的订阅

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: quay-operator
     namespace: quay
   spec:
     channel: quay-v3.4
     installPlanApproval: Manual 1
     name: quay-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: quay-operator.v3.4.0 2

   1

   如果您指定的版本会被目录中的更新版本取代，则将批准策略设置为 Manual。此计划阻止自动升级到更新的版本，且需要在启动 CSV 可以完成安装前手动批准。

   2

   设置 Operator CSV 的特定版本。

2. 创建 Subscription 对象：

   $ oc apply -f sub.yaml

3. 手动批准待处理的安装计划以完成 Operator 安装。

流程

1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中，进入 Operators → Installed Operators。
2. 点击您要更改更新频道的 Operator 名称。
3. 点 Subscription 标签页。
4. 点 Channel 中的更新频道的名称。
5. 点要更改的更新频道，然后点 Save。

6. 对于带有 自动批准策略 的订阅，升级会自动开始。返回 Operators → Installed Operators 页面来监控升级的过程。完成后，状态会变为 Succeeded 和 Up to date。

   对于采用手动批准策略的订阅，您可以使用 Subscription 选项卡手动批准升级。

流程

1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中，进入 Operators → Installed Operators。
2. 处于待定升级的 Operator 会显示 Upgrade available 状态。点您要升级的 Operator 的名称。
3. 点 Subscription 标签页。任何需要批准的升级都会在 Upgrade Status 旁边显示。例如：它可能会显示 1 requires approval。
4. 点 1 requires approval，然后点 Preview Install Plan。
5. 查看列出可用于升级的资源。在满意后，点 Approve。
6. 返回 Operators → Installed Operators 页面来监控升级的过程。完成后，状态会变为 Succeeded 和 Up to date。

流程

1. 进入 Operators → Installed Operators 页面，在 Filter by name 字段滚动鼠标或键入关键词，以查找您想要的 Operator。然后点击。

2. 在 Operator Details 页面右侧，从 Actions 列表中选择 Uninstall Operator。

   此时会显示 Uninstall Operator? 对话框，提醒您：

   删除 Operator 不会移除任何自定义资源定义或受管资源。如果 Operator 在集群中部署了应用程序，或者配置了非集群资源，则这些应用程序将继续运行，需要手动清理。

   此操作将删除 Operator 以及 Operator 部署和 pod（若有）。任何 Operands 和由 Operator 管理的资源（包括 CRD 和 CR）都不会被删除。Web 控制台为一些 Operator 启用仪表板和导航项。要在卸载 Operator 后删除这些，您可能需要手动删除 Operator CRD。

3. 选择 Uninstall。此 Operator 将停止运行，并且不再接收更新。

流程

1. 通过 currentCSV 字段检查已订阅 Operator 的当前版本（如 jaeger）：

   $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV

   输出示例

     currentCSV: jaeger-operator.v1.8.2

2. 删除订阅（如 jaeger）:

   $ oc delete subscription jaeger -n openshift-operators

   输出示例

   subscription.operators.coreos.com "jaeger" deleted

3. 使用上一步中的 currentCSV 值来删除目标命名空间中相应 Operator 的 CSV：

   $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators

   输出示例

   clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

流程

1. 从安装 Operator 的命名空间中获取 Subscription 和 ClusterServiceVersion 对象的名称：

   $ oc get sub,csv -n <namespace>

   输出示例

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

2. 删除订阅：

   $ oc delete subscription <subscription_name> -n <namespace>

3. 删除集群服务版本：

   $ oc delete csv <csv_name> -n <namespace>

4. 在 openshift-marketplace 命名空间中获取所有失败的作业的名称和相关配置映射：

   $ oc get job,configmap -n openshift-marketplace

   输出示例

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. 删除作业：

   $ oc delete job <job_name> -n openshift-marketplace

   这样可确保尝试拉取无法访问的镜像的 Pod 不会被重新创建。

6. 删除配置映射：

   $ oc delete configmap <configmap_name> -n openshift-marketplace

7. 在 Web 控制台中使用 OperatorHub 重新安装 Operator。

流程

1. 在 Web 控制台中导航至 Operators → OperatorHub 页面。
2. 选择 Operator 并点 Install。

3. 在 Install Operator 页面中，修改 Subscription 对象，使其在 spec 部分中包含一个或多个以下环境变量：

   • HTTP_PROXY
   • HTTPS_PROXY
   • NO_PROXY

   例如：

   带有代理设置的Subscription 对象覆盖

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: etcd-config-test
     namespace: openshift-operators
   spec:
     config:
       env:
       - name: HTTP_PROXY
         value: test_http
       - name: HTTPS_PROXY
         value: test_https
       - name: NO_PROXY
         value: test
     channel: clusterwide-alpha
     installPlanApproval: Automatic
     name: etcd
     source: community-operators
     sourceNamespace: openshift-marketplace
     startingCSV: etcdoperator.v0.9.4-clusterwide

   注意

   这些环境变量也可以使用空值取消设置，以删除所有之前设定的集群范围或自定义代理设置。

   OLM 将这些环境变量作为一个单元处理; 如果至少设置了一个环境变量，则所有 3 个变量都将被视为覆盖，并且集群范围的默认值不会用于订阅的 Operator 部署。

4. 点击 Install 使 Operator 可供所选命名空间使用。

5. 当 Operator 的 CSV 出现在相关命名空间中后，您可以验证部署中是否设置了自定义代理环境变量。例如，使用 CLI：

   $ oc get deployment -n openshift-operators \
       etcd-operator -o yaml \
       | grep -i "PROXY" -A 2

   输出示例

           - name: HTTP_PROXY
             value: test_http
           - name: HTTPS_PROXY
             value: test_https
           - name: NO_PROXY
             value: test
           image: quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21088a98b93838e284a6086b13917f96b0d9c
   ...

流程

1. 在存在 Operator 订阅的命名空间中创建一个空配置映射，并包括以下标签：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: trusted-ca 1
     labels:
       config.openshift.io/inject-trusted-cabundle: "true" 2

   1

   配置映射的名称。

   2

   请求 Cluster Network Operator 注入合并的捆绑包。

   创建此配置映射后，它会立即使用合并捆绑包的证书内容填充。

2. 更新您的 Subscription 对象，使其包含 spec.config 部分，该部分可将 trusted-ca 配置映射作为卷挂载到需要自定义 CA 的 pod 中的每个容器：

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: my-operator
   spec:
     package: etcd
     channel: alpha
     config: 1
       selector:
         matchLabels:
           <labels_for_pods> 2
       volumes: 3
       - name: trusted-ca
         configMap:
           name: trusted-ca
           items:
             - key: ca-bundle.crt 4
               path: tls-ca-bundle.pem 5
       volumeMounts: 6
       - name: trusted-ca
         mountPath: /etc/pki/ca-trust/extracted/pem
         readOnly: true

   1

   如果不存在，请添加 config 部分。

   2

   指定标签以匹配 Operator 拥有的 pod。

   3

   创建一个 trusted-ca 卷。

   4

   ca-bundle.crt 需要作为配置映射键。

   5

   tls-ca-bundle.pem 需要作为配置映射路径。

   6

   创建一个 trusted-ca 卷挂载。

流程

1. 列出 Operator 订阅：

   $ oc get subs -n <operator_namespace>

2. 使用 oc describe 命令检查 Subscription 资源：

   $ oc describe sub <subscription_name> -n <operator_namespace>

3. 在命令输出中，找到 Operator 订阅状况类型的 Conditions 部分。在以下示例中，CatalogSourcesUnhealthy 条件类型具有 false 状态，因为所有可用目录源都健康：

   输出示例

   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy

流程

1. 列出命名空间中的目录源。例如，您可以检查 openshift-marketplace 命名空间，该命名空间用于集群范围的目录源：

   $ oc get catalogsources -n openshift-marketplace

   输出示例

   NAME                  DISPLAY               TYPE   PUBLISHER   AGE
   certified-operators   Certified Operators   grpc   Red Hat     55m
   community-operators   Community Operators   grpc   Red Hat     55m
   example-catalog       Example Catalog       grpc   Example Org 2m25s
   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

2. 使用 oc describe 命令获取有关目录源的详情和状态：

   $ oc describe catalogsource example-catalog -n openshift-marketplace

   输出示例

   Name:         example-catalog
   Namespace:    openshift-marketplace
   ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace

   在上例的输出中，最后观察到的状态是 TRANSIENT_FAILURE。此状态表示目录源建立连接时出现问题。

3. 列出创建目录源的命名空间中的 pod：

   $ oc get pods -n openshift-marketplace

   输出示例

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

   在命名空间中创建目录源时，会在该命名空间中为目录源创建一个 pod。在前面的示例中，example-catalog-bwt8z pod 的状态是 ImagePullBackOff。此状态表示拉取目录源的索引镜像存在问题。

4. 使用 oc describe 命令检查 pod 以获取更多详细信息：

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   输出示例

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

   在前面的示例输出中，错误消息表示目录源的索引镜像因为授权问题而无法成功拉取。例如，索引镜像可能存储在需要登录凭证的 registry 中。

流程

1. 新建命名空间：

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: scoped
   EOF

2. 分配 Operator 的权限范围。这涉及创建新服务帐户、相关角色和角色绑定。

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: scoped
     namespace: scoped
   EOF

   为简便起见，以下示例授予服务账户在指定命名空间进行任何操作的权限。在生产环境中，应创建更为精细的权限集：

   $ cat <<EOF | oc create -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: scoped
     namespace: scoped
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["*"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: scoped-bindings
     namespace: scoped
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: scoped
   subjects:
   - kind: ServiceAccount
     name: scoped
     namespace: scoped
   EOF

3. 在指定的命名空间中创建 OperatorGroup 对象。该 Operator 组以指定的命名空间为目标，以确保其租期仅限于该命名空间。

   另外，Operator 组允许用户指定服务帐户。指定上一步中创建的服务帐户：

   $ cat <<EOF | oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: scoped
     namespace: scoped
   spec:
     serviceAccountName: scoped
     targetNamespaces:
     - scoped
   EOF

   在指定命名空间中安装的任何 Operator 均会关联至此 Operator 组，因此也会关联到指定的服务账户。

4. 在指定命名空间中创建 Subscription 对象以安装 Operator:

   $ cat <<EOF | oc create -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: etcd
     namespace: scoped
   spec:
     channel: singlenamespace-alpha
     name: etcd
     source: <catalog_source_name> 1
     sourceNamespace: <catalog_source_namespace> 2
   EOF

   1

   指定已存在于指定命名空间中或位于全局目录命名空间中的目录源。

   2

   指定创建目录源的命名空间。

   与该 Operator 组相关联的所有 Operator 都仅限于为指定服务账户授予的权限。如果 Operator 请求的权限超出服务账户范围，安装会失败并显示相关错误。

流程

1. 查看 Subscription 对象。其状态中有一个指向 InstallPlan 对象的对象引用 installPlanRef，该对象试图为 Operator 创建需要的 [Cluster]Role[Binding]：

   apiVersion: operators.coreos.com/v1
   kind: Subscription
   metadata:
     name: etcd
     namespace: scoped
   status:
     installPlanRef:
       apiVersion: operators.coreos.com/v1
       kind: InstallPlan
       name: install-4plp8
       namespace: scoped
       resourceVersion: "117359"
       uid: 2c1df80e-afea-11e9-bce3-5254009c9c23

2. 检查 InstallPlan 对象的状态中的任何错误：

   apiVersion: operators.coreos.com/v1
   kind: InstallPlan
   status:
     conditions:
     - lastTransitionTime: "2019-07-26T21:13:10Z"
       lastUpdateTime: "2019-07-26T21:13:10Z"
       message: 'error creating clusterrole etcdoperator.v0.9.4-clusterwide-dsfx4: clusterroles.rbac.authorization.k8s.io
         is forbidden: User "system:serviceaccount:scoped:scoped" cannot create resource
         "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope'
       reason: InstallComponentFailed
       status: "False"
       type: Installed
     phase: Failed

   错误信息中会显示：

   • 创建失败的资源类型，包括资源的 API 组。本例中为 rbac.authorization.k8s.io 组中的 clusterroles。
   • 资源名称。
   • 错误类型：is forbidden 表明相应用户没有足够权限来执行这一操作。
   • 试图创建或更新资源的用户名称。本例中指的是 Operator 组中指定的服务账户。

   • 操作范围：集群范围内或范围外。

     用户可在服务账户中增加所缺权限，然后迭代操作。

     注意

     Operator Lifecycle Manager（OLM）目前未提供第一次尝试的完整错误列表。

流程

1. 在 Web 控制台的 Administrator 视角中，导航至 Administration → Cluster Settings。
2. 点 Global Configuration 选项卡，然后点 OperatorHub。
3. 点 Sources 选项卡。
4. 选择您要删除的目录的 Options 菜单 ，然后点 Delete CatalogSource。

流程

1. 通过 registry.redhat.io 进行身份验证：

   $ podman login registry.redhat.io

2. 通过目标 registry 进行身份验证：

   $ podman login <target_registry>

3. 确定您要包括在您的修剪索引中的软件包列表。

   1. 运行您要修剪容器中的源索引镜像。例如：

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.6

      输出示例

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.6...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. 在一个单独的终端会话中，使用 grpcurl 命令获取由索引提供的软件包列表：

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. 检查 package.out 文件，确定要保留在此列表中的哪个软件包名称。例如：

      软件包列表片断示例

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. 在您执行 podman run 命令的终端会话中，按 Ctrl 和 C 停止容器进程。

4. 运行以下命令来修剪指定软件包以外的所有源索引：

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.6 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.6] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6 4

   1

   到修剪的索引。

   2

   要保留的软件包用逗号隔开。

   3

   只适用于 IBM Power Systems 和 IBM Z 镜像： Operator Registry 基础镜像和与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签。

   4

   用于正在构建新索引镜像的自定义标签。

5. 运行以下命令将新索引镜像推送到目标 registry:

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6

   其中 <namespace> 是 registry 上的任何现有命名空间。例如，您可以创建一个 olm-mirror 命名空间来将所有镜像的内容推送到。

流程

1. 如果要镜像红帽提供的目录，请在具有无网络访问限制的工作站中运行以下命令，以便与 registry.redhat.io 进行身份验证：

   $ podman login registry.redhat.io

2. oc adm catalog mirror 命令提取索引镜像的内容，以生成镜像所需的清单。命令的默认行为会生成清单，然后会自动将索引镜像以及索引镜像本身中的所有镜像内容镜像（mirror）到您的镜像 registry。另外，如果您的镜像 registry 位于完全断开连接的主机上，或者断开连接的或 airgapped 主机上，您可以首先将内容镜像到可移动介质，将介质移到断开连接的环境中，然后将内容从介质镜像到 registry。

   • 选项 A: 如果您的镜像 registry 与您的没有网络访问限制的工作站位于同一个网络中，请在您的工作站中执行以下操作：

     1. 如果您的镜像 registry 需要身份验证，请运行以下命令登录到 registry:

        $ podman login <mirror_registry>

     2. 运行以下命令镜像内容：

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6

        1

        指定您要镜像的目录的索引镜像。例如，这可能是之前创建的已修剪索引镜像，也可以是默认目录的源索引镜像之一，如 registry.redhat.io/redhat/redhat-operator-index:v4.6。

        2

        指定要将 Operator 内容镜像到的目标 registry 和命名空间的完全限定域名(FQDN)，其中 <namespace> 是 registry 上的任何现有命名空间。例如，您可以创建一个 olm-mirror 命名空间来将所有镜像的内容推送到。

        3

        可选：如果需要，指定 registry 凭证文件的位置。registry.redhat.io 需要 {REG_CREDS}。

        4

        可选：如果您不想为目标 registry 配置信任，请添加 --insecure 标志。

        5

        可选：在有多个变体可用时，指定索引镜像的平台和架构。镜像被传递为 '<platform>/<arch>[/<variant>]'。这不适用于索引引用的镜像。有效值是 linux/amd64、linux/ppc64le 和 linux/s390x。

        6

        可选：只生成镜像所需的清单，但并不实际将镜像内容镜像到 registry。这个选项对检查哪些将被镜像（mirror）非常有用，如果您只需要一小部分软件包，可以对映射列表进行修改。然后，您可以使用带有 oc image mirror 命令的 mapping.txt 文件来在以后的步骤中镜像修改的镜像列表。此标志仅用于从目录中对内容进行高级选择性镜像；opm index prune 命令适用于大多数目录管理用例，如果之前用来修剪索引镜像。

        输出示例

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1

        命令生成的临时 index.db 数据库的目录。

        2

        务必记录生成的 manifests 目录名称。该目录名将在以后的步骤中使用。

        注意

        Red Hat Quay 不支持嵌套存储库。因此，运行 oc adm catalog mirror 命令会失败，并显示 401 未授权错误。作为临时解决方案，您可以在运行 oc adm catalog mirror 命令时使用 --max-components=2 选项来禁用嵌套存储库的创建。有关这个临时解决方案的更多信息，请参阅使用带有 Quay registry 知识库文章的 catalog mirror 命令时出现 Unauthorized 错误。

   • 选项 B：如果您的镜像 registry 位于断开连接的主机上，请执行以下操作。

     1. 在您的工作站中运行以下命令，且没有网络访问权限将内容镜像到本地文件中：

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        指定您要镜像的目录的索引镜像。例如，这可能是之前创建的已修剪索引镜像，也可以是默认目录的源索引镜像之一，如 registry.redhat.io/redhat/redhat-operator-index:v4.6。

        2

        将内容镜像到您当前目录中的本地文件。

        输出示例

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1

        务必记录生成的 manifests 目录名称。该目录名将在以后的步骤中使用。

        2

        记录基于您提供的索引镜像展开的 file:// 路径。该路径在以后的步骤中会使用。

     2. 将当前目录中生成的 v2/ 目录复制到可移动介质中。
     3. 物理删除该介质并将其附加到断开连接的环境中可访问镜像 registry 的主机。

     4. 如果您的镜像 registry 需要身份验证，请在断开连接的环境中的主机上运行以下命令以登录到 registry：

        $ podman login <mirror_registry>

     5. 从包含 v2/ 目录的父目录运行以下命令，将镜像从本地文件上传到镜像 registry：

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        指定上一命令输出中的 file:// 路径。

        2

        指定要将 Operator 内容镜像到的目标 registry 和命名空间的完全限定域名(FQDN)，其中 <namespace> 是 registry 上的任何现有命名空间。例如，您可以创建一个 olm-mirror 命名空间来将所有镜像的内容推送到。

        注意

        Red Hat Quay 不支持嵌套存储库。因此，运行 oc adm catalog mirror 命令会失败，并显示 401 未授权错误。作为临时解决方案，您可以在运行 oc adm catalog mirror 命令时使用 --max-components=2 选项来禁用嵌套存储库的创建。有关这个临时解决方案的更多信息，请参阅使用带有 Quay registry 知识库文章的 catalog mirror 命令时出现 Unauthorized 错误。

3. 将内容镜像到 registry 后，检查当前目录中生成的清单目录。

   注意

   清单目录名会在以后的步骤中使用。

   如果您在上一步中将内容镜像到同一网络上的 registry，则目录名称采用以下格式：

   manifests-<index_image_name>-<random_number>

   如果您在上一步中将内容镜像到断开连接的主机上的 registry，则目录名称采用以下格式：

   manifests-index/<namespace>/<index_image_name>-<random_number>

   manifests 目录包含以下文件，其中的一些文件可能需要进一步修改：

   • catalogSource.yaml 文件是 CatalogSource 对象的基本定义，它预先填充索引镜像标签及其他相关元数据。此文件可原样使用，或进行相应修改来在集群中添加目录源。

     重要

     如果将内容镜像到本地文件，您必须修改 catalogSource .yaml 文件，从 metadata.name 字段中删除任何反斜杠(/)字符。否则，当您试图创建对象时，会失败并显示 "invalid resource name” 错误。

   • 用来定义 ImageContentSourcePolicy 对象的 imageContentSourcePolicy.yaml，它可以将节点配置为在 Operator 清单中存储的镜像（image）引用和镜像 (mirror) 的 registry 间进行转换。

     注意

     如果您的集群使用 ImageContentSourcePolicy 对象来配置存储库镜像，则只能将全局 pull secret 用于镜像 registry。您不能在项目中添加 pull secret。

   • mapping.txt 文件，在其中包含所有源镜像，并将它们映射到目标 registry。此文件与 oc image mirror 命令兼容，可用于进一步自定义镜像（mirror）配置。

     重要

     如果您在镜像过程中使用 --manifests-only 标志，并希望进一步调整要镜像的软件包子集，请参阅"镜像软件包清单格式目录镜像"中有关修改 mapping.txt 文件的步骤，并使用 oc image mirror 命令使用该文件。在进行了这些操作后，您可以继续这个过程。

4. 在可访问断开连接的集群的主机上，运行以下命令来指定 manifests 目录中的 imageContentSourcePolicy.yaml 文件，创建 ImageContentSourcePolicy 对象：

   $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

   其中 <path/to/manifests/dir> 是镜像内容的 manifests 目录的路径。

流程

1. 创建一个 CatalogSource 对象来引用索引镜像。如果使用 oc adm catalog mirror 命令将目录镜像到目标 registry，您可以使用生成的 catalogSource.yaml 文件作为起点。

   1. 根据您的规格修改以下内容，并将它保存为 catalogSource.yaml 文件：

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog 1
        namespace: openshift-marketplace 2
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.6 3
        displayName: My Operator Catalog
        publisher: <publisher_name> 4
        updateStrategy:
          registryPoll: 5
            interval: 30m

      1

      如果您在上传到 registry 前将内容镜像到本地文件，请从 metadata.name 字段中删除任何反斜杠(/)字符，以避免在创建对象时出现 "invalid resource name" 错误。

      2

      如果您希望目录源对所有命名空间中的用户全局可用，请指定 openshift-marketplace 命名空间。否则，您可以指定一个不同的命名空间来对目录进行作用域并只对该命名空间可用。

      3

      指定索引镜像。

      4

      指定发布目录的名称或机构名称。

      5

      目录源可以自动检查新版本以保持最新。

   2. 使用该文件创建 CatalogSource 对象：

      $ oc apply -f catalogSource.yaml

2. 确定成功创建以下资源。

   1. 检查 pod:

      $ oc get pods -n openshift-marketplace

      输出示例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. 检查目录源：

      $ oc get catalogsource -n openshift-marketplace

      输出示例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. 检查软件包清单：

      $ oc get packagemanifest -n openshift-marketplace

      输出示例

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

流程

1. 通过添加捆绑包镜像来更新现有索引：

   $ opm index add \
       --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
       --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
       --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
       --pull-tool podman 4

   1

   --bundles 标志指定要添加到索引中的、以逗号分隔的额外捆绑包镜像列表。

   2

   --from-index 标志指定之前推送的索引。

   3

   --tag 标志指定要应用到更新的索引镜像的镜像标签。

   4

   --pull-tool 标志指定用于拉取容器镜像的工具。

   其中：

   <registry>

   指定 registry 的主机名，如 quay.io 或 mirror.example.com。

   <namespace>

   指定 registry 的命名空间，如 ocs-dev 或 abc。

   <new_bundle_image>

   指定要添加到 registry 的新捆绑包镜像，如 ocs-operator。

   <digest>

   指定捆绑包镜像的 SHA 镜像 ID 或摘要，如 c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41。

   <existing_index_image>

   指定之前推送的镜像，如 abc-redhat-operator-index。

   <existing_tag>

   指定之前推送的镜像标签，如 4.6。

   <updated_tag>

   指定要应用到更新的索引镜像的镜像标签，如 4.6.1。

   示例命令

   $ opm index add \
       --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
       --from-index mirror.example.com/abc/abc-redhat-operator-index:4.6 \
       --tag mirror.example.com/abc/abc-redhat-operator-index:4.6.1 \
       --pull-tool podman

2. 推送更新的索引镜像：

   $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

3. 按照镜像 Operator 目录流程中的步骤来镜像更新的内容。但是，当进入创建 ImageContentSourcePolicy（ICSP）对象的步骤时，请使用 oc replace 命令而不是 oc create 命令。例如：

   $ oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yaml

   这一更改是必需的，因为对象已存在且必须更新。

   注意

   通常，oc apply 命令可用于更新之前使用 oc apply 创建的现有对象。但是，由于有关 ICSP 对象中的 metadata.annotations 字段大小的已知问题，oc replace 命令当前必须用于此步骤。

4. Operator Lifecycle Manager（OLM）会在常规时间段内自动轮询目录源中引用的索引镜像，验证是否已成功添加新软件包：

   $ oc get packagemanifests -n openshift-marketplace

1. 使用 Operator SDK 命令行界面（CLI）创建 Operator 项目。
2. 通过添加自定义资源定义 (CRD) 来定义新的资源 API。
3. 使用 Operator SDK API 指定要监视的资源。
4. 在指定的处理程序中定义 Operator 协调逻辑，并使用 Operator SDK API 与资源交互。
5. 使用 Operator SDK CLI 来构建和生成 Operator 部署清单。

流程

1. 设置发行版本变量：

   $ RELEASE_VERSION=v0.19.4

2. 下载发行版二进制文件。

   • Linux：

     $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu

   • macOS：

     $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin

3. 验证所下载的发行版本二进制文件。

   1. 下载提供的 .asc 文件。

      • Linux：

        $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu.asc

      • macOS：

        $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin.asc

   2. 将二进制文件和对应的 .asc 文件放在同一个目录中，并运行以下命令验证该二进制文件：

      • Linux：

        $ gpg --verify operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu.asc

      • macOS：

        $ gpg --verify operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin.asc

      如果您的工作站上没有维护人员的公钥，则会出现以下错误：

      带有错误的输出示例

      $ gpg: assuming signed data in 'operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin'
      $ gpg: Signature made Fri Apr  5 20:03:22 2019 CEST
      $ gpg:                using RSA key <key_id> 1
      $ gpg: Can't check signature: No public key

      1

      RSA 密钥字符串。

      要下载密钥，请运行以下命令，用上一条命令输出的 RSA 密钥字符串来替换 <key_id>：

      $ gpg [--keyserver keys.gnupg.net] --recv-key "<key_id>" 1

      1

      如果您尚未配置密钥服务器，请使用 --keyserver 选项指定一个密钥服务器。

4. 在您的 PATH 中安装发行版本二进制文件：

   • Linux：

     $ chmod +x operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu

     $ sudo cp operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu /usr/local/bin/operator-sdk

     $ rm operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu

   • macOS：

     $ chmod +x operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin

     $ sudo cp operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin /usr/local/bin/operator-sdk

     $ rm operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin

5. 验证是否已正确安装 CLI 工具：

   $ operator-sdk version

流程

1. 使用 brew 命令安装 SDK CLI：

   $ brew install operator-sdk

2. 验证是否已正确安装 CLI 工具：

   $ operator-sdk version

流程

1. 克隆 operator-sdk 存储库：

   $ git clone https://github.com/operator-framework/operator-sdk

2. 进入克隆存储库的目录：

   $ cd operator-sdk

3. 检查 v0.19.4 发行版本：

   $ git checkout tags/v0.19.4 -b v0.19.4

4. 更新依赖项：

   $ make tidy

5. 编译并安装 SDK CLI：

   $ make install

   这会在 $GOPATH/bin/ 目录中安装 CLI 二进制 operator-sdk。

6. 验证是否已正确安装 CLI 工具：

   $ operator-sdk version

流程

1. 创建 Operator 项目：

   1. 为项目创建一个目录：

      $ mkdir -p $HOME/projects/memcached-operator

   2. 进入该目录：

      $ cd $HOME/projects/memcached-operator

   3. 激活对 Go 模块的支持：

      $ export GO111MODULE=on

   4. 运行 operator-sdk init 命令以初始化项目：

      $ operator-sdk init \
          --domain=example.com \
          --repo=github.com/example-inc/memcached-operator

      注意

      operator-sdk init 命令默认使用 go.kubebuilder.io/v2 插件。

2. 更新 Operator 以使用支持的镜像：

   1. 在项目根级别 Dockerfile 中，更改默认运行程序镜像引用：

      FROM gcr.io/distroless/static:nonroot

      改为：

      FROM registry.access.redhat.com/ubi8/ubi-minimal:latest

   2. 根据 Go 项目版本，您的 Dockerfile 可能包含 USER 65532:65532 或 USER nonroot:nonroot 指令。在这两种情况下，删除该行，因为受支持的 runner 镜像不需要该行。

   3. 在 config/default/manager_auth_proxy_patch.yaml 文件中，修改 image 值：

      gcr.io/kubebuilder/kube-rbac-proxy:<tag>

      使用支持的镜像：

      registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.6

3. 通过替换以下行，更新 Makefile 中的 test 目标，以安装后续构建过程中所需的依赖项：

   例 5.1. 现有 test 目标

   test: generate fmt vet manifests
           go test ./... -coverprofile cover.out

   使用以下行：

   例 5.2. 更新了 test 目标

   ENVTEST_ASSETS_DIR=$(shell pwd)/testbin
   test: manifests generate fmt vet ## Run tests.
   	mkdir -p ${ENVTEST_ASSETS_DIR}
   	test -f ${ENVTEST_ASSETS_DIR}/setup-envtest.sh || curl -sSLo ${ENVTEST_ASSETS_DIR}/setup-envtest.sh https://raw.githubusercontent.com/kubernetes-sigs/controller-runtime/v0.7.2/hack/setup-envtest.sh
   	source ${ENVTEST_ASSETS_DIR}/setup-envtest.sh; fetch_envtest_tools $(ENVTEST_ASSETS_DIR); setup_envtest_env $(ENVTEST_ASSETS_DIR); go test ./... -coverprofile cover.out

4. 创建自定义资源定义（CRD）API 和控制器：

   1. 运行以下命令创建带有组 cache、版本v1 和种类 Memcached 的 API：

      $ operator-sdk create api \
          --group=cache \
          --version=v1 \
          --kind=Memcached

   2. 提示时，输入 y 来创建资源和控制器：

      Create Resource [y/n]
      y
      Create Controller [y/n]
      y

      输出示例

      Writing scaffold for you to edit...
      api/v1/memcached_types.go
      controllers/memcached_controller.go
      ...

      此过程在 api/v1/memcached_types.go 和 controllers/memcached_controller.go 上生成 Memcached 资源 API。

   3. 修改 api/v1/memcached_types.go 中的 Go 类型定义，使其具有以下 spec 和 status：

      // MemcachedSpec defines the desired state of Memcached
      type MemcachedSpec struct {
      	// +kubebuilder:validation:Minimum=0
      	// Size is the size of the memcached deployment
      	Size int32 `json:"size"`
      }
      
      // MemcachedStatus defines the observed state of Memcached
      type MemcachedStatus struct {
      	// Nodes are the names of the memcached pods
      	Nodes []string `json:"nodes"`
      }

   4. 添加 +kubebuilder:subresource:status marker，将 status 子资源添加到 CRD 清单中：

      // Memcached is the Schema for the memcacheds API
      // +kubebuilder:subresource:status 1
      type Memcached struct {
      	metav1.TypeMeta   `json:",inline"`
      	metav1.ObjectMeta `json:"metadata,omitempty"`
      
      	Spec   MemcachedSpec   `json:"spec,omitempty"`
      	Status MemcachedStatus `json:"status,omitempty"`
      }

      1

      添加这一行。

      这可让控制器在不更改剩余的 CR 对象的情况下更新 CR 状态。

   5. 为资源类型更新生成的代码：

      $ make generate

      提示

      在修改了 *_types.go 文件后，您必须运行 make generate 命令来更新该资源类型生成的代码。

      以上 Makefile 目标调用 controller-gen 程序来更新 api/v1/zz_generated.deepcopy.go 文件。这样可确保您的 API Go 类型定义实现了 runtime.Object 接口，所有 Kind 类型都必须实现。

5. 生成和更新 CRD 清单：

   $ make manifests

   此 Makefile 目标调用 controller-gen 实用程序在 config/crd/bases/cache.example.com_memcacheds.yaml 文件中生成 CRD 清单。

   1. 可选：将自定义验证添加到 CRD 中。

      当生成清单时，OpenAPI v3.0 模式会添加到 spec.validation 块中的 CRD 清单中。此验证块允许 Kubernetes 在 Memcached 自定义资源（CR）创建或更新时验证其中的属性。

      作为 Operator 作者，您可以使用类似于注解的单行注释（称为 Kubebuilder markers ）来配置 API 的自定义验证。这些标记必须始终具有 +kubebuilder:validation 前缀。例如，可以通过添加以下标记来添加一个 enum-type 规格：

      // +kubebuilder:validation:Enum=Lion;Wolf;Dragon
      type Alias string

      API 代码中的标记用法会在 Kubebuilder 生成 CRD 和用于配置/代码生成的标记文档中讨论。Kubebuilder CRD 验证文档还提供了 OpenAPIv3 验证标记的完整列表。

      如果添加任何自定义验证，请运行以下命令来更新 CRD 的 OpenAPI 验证部分：

      $ make manifests

6. 在创建新 API 和控制器后，您可以实现控制器逻辑。在本例中，将生成的控制器文件 controllers/memcached_controller.go 替换为以下示例实现：

   例 5.3. memcached_controller.go示例

   /*
   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at
   
       http://www.apache.org/licenses/LICENSE-2.0
   
   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
   */
   
   package controllers
   
   import (
   	"context"
   	"reflect"
   
   	"github.com/go-logr/logr"
   	appsv1 "k8s.io/api/apps/v1"
   	corev1 "k8s.io/api/core/v1"
   	"k8s.io/apimachinery/pkg/api/errors"
   	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
   	"k8s.io/apimachinery/pkg/runtime"
   	"k8s.io/apimachinery/pkg/types"
   	ctrl "sigs.k8s.io/controller-runtime"
   	"sigs.k8s.io/controller-runtime/pkg/client"
   
   	cachev1 "github.com/example-inc/memcached-operator/api/v1"
   )
   
   // MemcachedReconciler reconciles a Memcached object
   type MemcachedReconciler struct {
   	client.Client
   	Log    logr.Logger
   	Scheme *runtime.Scheme
   }
   
   // +kubebuilder:rbac:groups=cache.example.com,resources=memcacheds,verbs=get;list;watch;create;update;patch;delete
   // +kubebuilder:rbac:groups=cache.example.com,resources=memcacheds/status,verbs=get;update;patch
   // +kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete
   // +kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;
   
   func (r *MemcachedReconciler) Reconcile(req ctrl.Request) (ctrl.Result, error) {
   	ctx := context.Background()
   	log := r.Log.WithValues("memcached", req.NamespacedName)
   
   	// Fetch the Memcached instance
   	memcached := &cachev1.Memcached{}
   	err := r.Get(ctx, req.NamespacedName, memcached)
   	if err != nil {
   		if errors.IsNotFound(err) {
   			// Request object not found, could have been deleted after reconcile request.
   			// Owned objects are automatically garbage collected. For additional cleanup logic use finalizers.
   			// Return and don't requeue
   			log.Info("Memcached resource not found. Ignoring since object must be deleted")
   			return ctrl.Result{}, nil
   		}
   		// Error reading the object - requeue the request.
   		log.Error(err, "Failed to get Memcached")
   		return ctrl.Result{}, err
   	}
   
   	// Check if the deployment already exists, if not create a new one
   	found := &appsv1.Deployment{}
   	err = r.Get(ctx, types.NamespacedName{Name: memcached.Name, Namespace: memcached.Namespace}, found)
   	if err != nil && errors.IsNotFound(err) {
   		// Define a new deployment
   		dep := r.deploymentForMemcached(memcached)
   		log.Info("Creating a new Deployment", "Deployment.Namespace", dep.Namespace, "Deployment.Name", dep.Name)
   		err = r.Create(ctx, dep)
   		if err != nil {
   			log.Error(err, "Failed to create new Deployment", "Deployment.Namespace", dep.Namespace, "Deployment.Name", dep.Name)
   			return ctrl.Result{}, err
   		}
   		// Deployment created successfully - return and requeue
   		return ctrl.Result{Requeue: true}, nil
   	} else if err != nil {
   		log.Error(err, "Failed to get Deployment")
   		return ctrl.Result{}, err
   	}
   
   	// Ensure the deployment size is the same as the spec
   	size := memcached.Spec.Size
   	if *found.Spec.Replicas != size {
   		found.Spec.Replicas = &size
   		err = r.Update(ctx, found)
   		if err != nil {
   			log.Error(err, "Failed to update Deployment", "Deployment.Namespace", found.Namespace, "Deployment.Name", found.Name)
   			return ctrl.Result{}, err
   		}
   		// Spec updated - return and requeue
   		return ctrl.Result{Requeue: true}, nil
   	}
   
   	// Update the Memcached status with the pod names
   	// List the pods for this memcached's deployment
   	podList := &corev1.PodList{}
   	listOpts := []client.ListOption{
   		client.InNamespace(memcached.Namespace),
   		client.MatchingLabels(labelsForMemcached(memcached.Name)),
   	}
   	if err = r.List(ctx, podList, listOpts...); err != nil {
   		log.Error(err, "Failed to list pods", "Memcached.Namespace", memcached.Namespace, "Memcached.Name", memcached.Name)
   		return ctrl.Result{}, err
   	}
   	podNames := getPodNames(podList.Items)
   
   	// Update status.Nodes if needed
   	if !reflect.DeepEqual(podNames, memcached.Status.Nodes) {
   		memcached.Status.Nodes = podNames
   		err := r.Status().Update(ctx, memcached)
   		if err != nil {
   			log.Error(err, "Failed to update Memcached status")
   			return ctrl.Result{}, err
   		}
   	}
   
   	return ctrl.Result{}, nil
   }
   
   // deploymentForMemcached returns a memcached Deployment object
   func (r *MemcachedReconciler) deploymentForMemcached(m *cachev1.Memcached) *appsv1.Deployment {
   	ls := labelsForMemcached(m.Name)
   	replicas := m.Spec.Size
   
   	dep := &appsv1.Deployment{
   		ObjectMeta: metav1.ObjectMeta{
   			Name:      m.Name,
   			Namespace: m.Namespace,
   		},
   		Spec: appsv1.DeploymentSpec{
   			Replicas: &replicas,
   			Selector: &metav1.LabelSelector{
   				MatchLabels: ls,
   			},
   			Template: corev1.PodTemplateSpec{
   				ObjectMeta: metav1.ObjectMeta{
   					Labels: ls,
   				},
   				Spec: corev1.PodSpec{
   					Containers: []corev1.Container{{
   						Image:   "memcached:1.4.36-alpine",
   						Name:    "memcached",
   						Command: []string{"memcached", "-m=64", "-o", "modern", "-v"},
   						Ports: []corev1.ContainerPort{{
   							ContainerPort: 11211,
   							Name:          "memcached",
   						}},
   					}},
   				},
   			},
   		},
   	}
   	// Set Memcached instance as the owner and controller
   	ctrl.SetControllerReference(m, dep, r.Scheme)
   	return dep
   }
   
   // labelsForMemcached returns the labels for selecting the resources
   // belonging to the given memcached CR name.
   func labelsForMemcached(name string) map[string]string {
   	return map[string]string{"app": "memcached", "memcached_cr": name}
   }
   
   // getPodNames returns the pod names of the array of pods passed in
   func getPodNames(pods []corev1.Pod) []string {
   	var podNames []string
   	for _, pod := range pods {
   		podNames = append(podNames, pod.Name)
   	}
   	return podNames
   }
   
   func (r *MemcachedReconciler) SetupWithManager(mgr ctrl.Manager) error {
   	return ctrl.NewControllerManagedBy(mgr).
   		For(&cachev1.Memcached{}).
   		Owns(&appsv1.Deployment{}).
   		Complete(r)
   }

   示例控制器为每个 Memcached CR 运行以下协调逻辑：

   • 如果尚无 Memcached 部署，创建一个。
   • 确保部署大小与 Memcached CR spec 指定的大小相同。
   • 使用 memcached Pod 的名称更新 Memcached CR 状态。

   接下来的两个子步骤检查控制器如何监视资源以及协调循环的触发方式。您可跳过这些步骤，直接构建和运行 Operator。

   1. 检查 controllers/memcached_controller.go 文件中的控制器实施，以查看控制器如何监视资源。

      SetupWithManager() 函数指定如何构建控制器来监控 CR 以及由该控制器拥有和管理的其他资源：

      例 5.4. SetupWithManager() 功能

      import (
      	...
      	appsv1 "k8s.io/api/apps/v1"
      	...
      )
      
      func (r *MemcachedReconciler) SetupWithManager(mgr ctrl.Manager) error {
      	return ctrl.NewControllerManagedBy(mgr).
      		For(&cachev1.Memcached{}).
      		Owns(&appsv1.Deployment{}).
      		Complete(r)
      }

      NewControllerManagedBy() 提供了一个控制器构建器，它允许各种控制器配置。

      for(&cachev1.Memcached{}) 将 Memcached 类型指定为要监视的主要资源。对于 Memcached 类型的每个 Add、Update 或 Delete 事件，协调循环都会为该 Memcached 对象发送一个协调 Request 参数，其中包括命名空间和名称键。

      owns(&appsv1.Deployment{}) 将 Deployment 类型指定为要监视的辅助资源。对于 Deployment 类型的每个 Add、Update 或 Delete 事件，事件处理程序会将每个事件映射到部署所有者的协调请求。在本例中，所有者是创建部署的 Memcached 对象。

   2. 每个控制器都有一个协调器对象，它带有实现了协调循环的 Reconcile() 方法。协调循环通过 Request 参数传递，该参数是从缓存中查找主资源对象 Memcached 的命名空间和名称键：

      例 5.5. 协调循环

      import (
      	ctrl "sigs.k8s.io/controller-runtime"
      
      	cachev1 "github.com/example-inc/memcached-operator/api/v1"
      	...
      )
      
      func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
        // Lookup the Memcached instance for this reconcile request
        memcached := &cachev1.Memcached{}
        err := r.Get(ctx, req.NamespacedName, memcached)
        ...
      }

      根据 Reconcile() 函数的返回值，协调 Request 可能会重新排队，且可能会再次触发循环：

      例 5.6. 重排队列的逻辑

      // Reconcile successful - don't requeue
      return reconcile.Result{}, nil
      // Reconcile failed due to error - requeue
      return reconcile.Result{}, err
      // Requeue for any reason other than error
      return reconcile.Result{Requeue: true}, nil

      您可以将 Result.RequeueAfter 设置为在宽限期后重排队列请求：

      例 5.7. 宽限期后重排队列

      import "time"
      
      // Reconcile for any reason other than an error after 5 seconds
      return ctrl.Result{RequeueAfter: time.Second*5}, nil

      注意

      您可以返回带有 RequeueAfter 设置的 Result 来定期协调一个 CR。

      有关协调器、客户端并与资源事件交互的更多信息，请参阅 Controller Runtime Client API 文档。

流程

1. 切换到安装 Operator 的命名空间。例如，如果使用 make deploy 命令部署 Operator：

   $ oc project memcached-operator-system

2. 编辑 config/samples/cache_v1_memcached.yaml 上的 Memcached CR 清单示例，使其包含以下规格：

   apiVersion: cache.example.com/v1
   kind: Memcached
   metadata:
     name: memcached-sample
   ...
   spec:
   ...
     size: 3

3. 创建 CR:

   $ oc apply -f config/samples/cache_v1_memcached.yaml

4. 确保 Memcached Operator 为示例 CR 创建部署，其大小正确：

   $ oc get deployments

   输出示例

   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   memcached-operator-controller-manager   1/1     1            1           8m
   memcached-sample                        3/3     3            3           1m

5. 检查 pod 和 CR 状态，以确认其状态是否使用 Memcached pod 名称更新。

   1. 检查 pod:

      $ oc get pods

      输出示例

      NAME                                  READY     STATUS    RESTARTS   AGE
      memcached-sample-6fd7c98d8-7dqdr      1/1       Running   0          1m
      memcached-sample-6fd7c98d8-g5k7v      1/1       Running   0          1m
      memcached-sample-6fd7c98d8-m7vn7      1/1       Running   0          1m

   2. 检查 CR 状态：

      $ oc get memcached/memcached-sample -o yaml

      输出示例

      apiVersion: cache.example.com/v1
      kind: Memcached
      metadata:
      ...
        name: memcached-sample
      ...
      spec:
        size: 3
      status:
        nodes:
        - memcached-sample-6fd7c98d8-7dqdr
        - memcached-sample-6fd7c98d8-g5k7v
        - memcached-sample-6fd7c98d8-m7vn7

6. 更新部署大小。

   1. 更新 config/samples/cache_v1_memcached.yaml 文件，将 Memcached CR 中的 spec.size 字段从 3 改为 5：

      $ oc patch memcached memcached-sample \
          -p '{"spec":{"size": 5}}' \
          --type=merge

   2. 确认 Operator 已更改部署大小：

      $ oc get deployments

      输出示例

      NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator-controller-manager   1/1     1            1           10m
      memcached-sample                        5/5     5            5           3m

流程

1. 创建新 Operator 项目。命名空间范围的 Operator 会监视和管理单一命名空间中的资源。命名空间范围的 Operator 因具有高灵活性而常被视为首选。这类 Operator 支持解耦升级、针对故障和监控隔离命名空间以及区别化 API 定义。

   要创建基于 Ansible 的、全命名空间范围的新 memcached-operator 项目并改为新目录，请使用以下命令：

   $ operator-sdk new memcached-operator \
       --api-version=cache.example.com/v1alpha1 \
       --kind=Memcached \
       --type=ansible

   $ cd memcached-operator

   这会创建 memcached-operator 项目，专门用于监视 API 版本 example.com/v1apha1 和 kind Memcached 的 Memcached 资源。

2. 自定义 Operator 逻辑。

   在本例中，memcached-operator 会针对每个 Memcached 自定义资源 (CR) 执行以下协调逻辑：

   • 如果尚无 Memcached 部署，创建一个。
   • 确保部署的大小与 Memcached CR 指定的大小相同。

   默认情况下，memcached-operator 会监视 Memcached 资源事件，如 watches.yaml 文件中所示，并执行 Ansible 角色 Memcached：

   - version: v1alpha1
     group: cache.example.com
     kind: Memcached

   您可选择在 watches.yaml 文件中自定义以下逻辑：

   1. 指定 role 选项会将 Operator 配置为在通过 Ansible 角色启动 ansible-runner 时使用该指定路径。默认情况下，operator-sdk new 命令会填写到您的角色应前往的绝对路径：

      - version: v1alpha1
        group: cache.example.com
        kind: Memcached
        role: /opt/ansible/roles/memcached

   2. 指定 watches.yaml 文件中的 playbook 选项会将 Operator 配置为在通过 Ansible playbook 启动 ansible-runner 时使用该指定路径。

      - version: v1alpha1
        group: cache.example.com
        kind: Memcached
        playbook: /opt/ansible/playbook.yaml

3. 构建 Memcached Ansible 角色。

   修改 roles/memcached/ 目录下生成的 Ansible 角色。该 Ansible 角色会控制修改资源时所执行的逻辑。

   1. 定义 Memcached spec。

      可完全在 Ansible 中定义基于 Ansible 的 Operator spec。Ansible Operator 会将 CR spec 字段中列出的所有键值对作为变量传递给 Ansible。在运行 Ansible 之前，Operator 会将 spec 字段中所有变量的名称转换为 snake 格式（小写并附带下划线）。例如，spec 中的 serviceAccount 在 Ansible 中会变成 service_account。

      提示

      您应在 Ansible 中对变量执行一些类型验证，以确保应用程序收到所需输入。

      如果用户未设置 spec 字段，则请修改 roles/memcached/defaults/main.yml 文件设置默认值：

      size: 1

   2. 定义 Memcached 部署。

      定义了 Memcached spec 后，即可定义资源发生更改时实际应执行的 Ansible。因为这是一个 Ansible 角色，所以默认行为是执行 roles/memcached/tasks/main.yml 文件中的任务。

      目的是在不存在部署的情况下让 Ansible 创建 Deployment，该 Deployment 将运行 memcached:1.4.36-alpine 镜像。Ansible 2.7+ 支持 k8s Ansible 模块，本例利用该模块来控制部署定义。

      修改 roles/memcached/tasks/main.yml 以匹配以下内容：

      - name: start memcached
        k8s:
          definition:
            kind: Deployment
            apiVersion: apps/v1
            metadata:
              name: '{{ meta.name }}-memcached'
              namespace: '{{ meta.namespace }}'
            spec:
              replicas: "{{size}}"
              selector:
                matchLabels:
                  app: memcached
              template:
                metadata:
                  labels:
                    app: memcached
                spec:
                  containers:
                  - name: memcached
                    command:
                    - memcached
                    - -m=64
                    - -o
                    - modern
                    - -v
                    image: "docker.io/memcached:1.4.36-alpine"
                    ports:
                      - containerPort: 11211

      注意

      本例使用 size 变量来控制 Memcached 部署的副本数。本示例将默认值设定为 1，但任何用户都可以创建一个 CR 覆盖该默认值。

4. 部署 CRD。

   在运行 Operator 之前，Kubernetes 需要了解 Operator 将会监视的新自定义资源定义 (CRD)。部署 Memcached CRD：

   $ oc create -f deploy/crds/cache.example.com_memcacheds_crd.yaml

5. 构建并运行 Operator。

   有两种方式来构建和运行 Operator：

   • 作为 Kubernetes 集群内的一个 pod。
   • 作为集群外的 Go 程序，使用 operator-sdk up 命令。

   选择以下任一方法：

   1. 作为 Kubernetes 集群内的一个 pod 来运行。这是生产环境的首先方法。

      1. 构建 memcached-operator 镜像并将其推送至 registry：

         $ operator-sdk build quay.io/example/memcached-operator:v0.0.1

         $ podman push quay.io/example/memcached-operator:v0.0.1

      2. deploy/operator.yaml 文件中会生成 Deployment 清单。本文件中的部署镜像需要从占位符 REPLACE_IMAGE 修改为之前构建的镜像。为此，请运行：

         $ sed -i 's|REPLACE_IMAGE|quay.io/example/memcached-operator:v0.0.1|g' deploy/operator.yaml

      3. 部署 memcached-operator 清单：

         $ oc create -f deploy/service_account.yaml

         $ oc create -f deploy/role.yaml

         $ oc create -f deploy/role_binding.yaml

         $ oc create -f deploy/operator.yaml

      4. 验证 memcached-operator 部署是否正在运行：

         $ oc get deployment

         NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
         memcached-operator       1         1         1            1           1m

   2. 在集群外运行。这是开发阶段的首选方法，可加快部署和测试的速度。

      请确保已安装 Ansible Runner 和 Ansible Runner HTTP Plug-in，否则在创建 CR 时，系统会显示 Ansible Runner 出现意外错误。

      此外，还务必要确保您的计算机上存在 watches.yaml 文件中引用的角色路径。因为通常会在磁盘上角色所处的位置使用容器，所以必须手动将角色复制到已配置的 Ansible 角色路径中（如 /etc/ansible/roles）。

      1. 要使用 $HOME/.kube/config 中的默认 Kubernetes 配置文件在本地运行 Operator：

         $ operator-sdk run --local

         要使用所提供的 Kubernetes 配置文件在本地运行 Operator：

         $ operator-sdk run --local --kubeconfig=config

6. 创建一个 Memcached CR。

   1. 按所示方式修改 deploy/crds/cache_v1alpha1_memcached_cr.yaml 文件并创建一个 Memcached CR：

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      输出示例

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 3

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. 确保 memcached-operator 为 CR 创建部署：

      $ oc get deployment

      输出示例

      NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator       1         1         1            1           2m
      example-memcached        3         3         3            3           1m

   3. 检查 pod，确认已创建三个副本：

      $ oc get pods

      NAME                                  READY     STATUS    RESTARTS   AGE
      example-memcached-6fd7c98d8-7dqdr     1/1       Running   0          1m
      example-memcached-6fd7c98d8-g5k7v     1/1       Running   0          1m
      example-memcached-6fd7c98d8-m7vn7     1/1       Running   0          1m
      memcached-operator-7cc7cfdf86-vvjqk   1/1       Running   0          2m

7. 更新大小。

   1. 将 memcached CR 中的 spec.size 字段从 3 改为 4，并应用以下更改：

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      输出示例

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 4

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. 确认 Operator 已更改部署大小：

      $ oc get deployment

      输出示例

      NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      example-memcached    4         4         4            4           5m

8. 清理资源：

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   $ oc delete -f deploy/operator.yaml

   $ oc delete -f deploy/role_binding.yaml

   $ oc delete -f deploy/role.yaml

   $ oc delete -f deploy/service_account.yaml

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_crd.yaml