Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

运行应用程序

Red Hat build of MicroShift 4.19

在 MicroShift 中运行应用程序

Red Hat OpenShift Documentation Team

摘要

本文档提供了有关如何在 MicroShift 中运行应用程序的详细信息。

第 1 章 使用 Kustomize 清单部署应用程序

您可以在应用程序清单中使用 kustomize 配置管理工具来部署应用程序。阅读以下流程，以了解 Kustomize 在 MicroShift 中的工作方式。

1.1. Kustomize 如何与清单一起工作以部署应用程序

kustomize 配置管理工具与 MicroShift 集成。您可以将 Kustomize 和 OpenShift CLI (oc)组合使用，将自定义应用到应用程序清单，并将这些应用程序部署到 MicroShift 集群。

  • kustomization.yaml 文件是资源以及自定义的规格。
  • Kustomize 使用 kustomization.yaml 文件来加载资源，如应用程序，然后应用您想要对应用程序清单的任何更改，并使用超laid的更改生成清单副本。
  • 使用带有 overlay 的清单副本可保留应用程序的原始配置文件，同时允许您有效地部署应用程序的迭代和自定义。
  • 然后，您可以使用 oc 命令在 MicroShift 集群中部署应用程序。
注意

在每个系统启动时，MicroShift 会删除 删除子目录中找到的清单，然后将清单目录中找到的清单文件应用到集群。

1.1.1. MicroShift 如何使用清单

每次开始时，MicroShift 会在以下清单目录中搜索 Kustomize 清单文件：

  • /etc/microshift/manifests
  • /etc/microshift/manifests.d/*
  • /usr/lib/microshift/
  • /usr/lib/microshift/manifests.d/*

如果搜索的目录中存在以下文件类型，MicroShift 会自动运行与 kubectl apply -k 命令对应的命令，以将清单应用到集群：

  • kustomization.yaml
  • kustomization.yml
  • kustomization

这种从多个目录的自动加载意味着您可以管理 MicroShift 工作负载，并灵活地运行不同的工作负载。

表 1.1. MicroShift 清单目录
位置作用

/etc/microshift/manifests

用于配置管理系统或开发的读写位置。

/etc/microshift/manifests.d/*

用于配置管理系统或开发的读写位置。

/usr/lib/microshift/manifests

在基于 OSTree 的系统上嵌入配置清单的只读位置。

/usr/lib/microshift/manifestsd./*

在基于 OSTree 的系统上嵌入配置清单的只读位置。

1.2. 覆盖清单路径列表

您可以使用新的单一路径或对多个文件使用新的 glob 模式来覆盖默认清单路径列表。使用以下步骤自定义清单路径。

流程

  1. 通过插入您自己的值并运行以下命令之一来覆盖默认路径列表：

    1. 在单一路径的配置文件中，将 manifests.kustomizePaths 设置为 <"/opt/alternate/ path">。

    2. 在 glob 模式的配置文件中将 kustomizePaths 设置为 ,"/opt/alternative/path.d configured"。 

      manifests:
    kustomizePaths:
        - <location>
      1
      Copy to Clipboard
      1
      使用 "/opt/alternate/path" 或 glob 模式（使用 "/opt/ alternative/path.d configured"），将每个位置条目设置为精确的路径。

  2. 要禁用加载清单，请将配置选项设置为空列表。 

    manifests:
    kustomizePaths: []
    Copy to Clipboard
    注意

    配置文件完全覆盖默认值。如果设置了 kustomizePaths 值，则只使用配置文件中的值。将值设为空列表将禁用清单加载。

1.3. 使用清单示例

本例演示了使用 /etc/microshift/manifests 目录中的 kustomize 清单自动部署 BusyBox 容器。

流程

  1. 运行以下命令来创建 BusyBox 清单文件：

    1. 定义目录位置： 

      $ MANIFEST_DIR=/etc/microshift/manifests
      Copy to Clipboard

    2. 创建目录： 

      $ sudo mkdir -p ${MANIFEST_DIR}
      Copy to Clipboard

    3. 将 YAML 文件放在目录中： 

      sudo tee ${MANIFEST_DIR}/busybox.yaml &>/dev/null <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: busybox
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: busybox-deployment
spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: BUSYBOX_IMAGE
        command: [ "/bin/sh", "-c", "while true ; do date; sleep 3600; done;" ]
EOF
      Copy to Clipboard

  2. 接下来，运行以下命令来创建 kustomize 清单文件：

    1. 将 YAML 文件放在目录中： 

      sudo tee ${MANIFEST_DIR}/kustomization.yaml &>/dev/null <<EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: busybox
resources:
  - busybox.yaml
images:
  - name: BUSYBOX_IMAGE
    newName: busybox:1.35
EOF
      Copy to Clipboard

  3. 运行以下命令重启 MicroShift 以应用清单： 

    $ sudo systemctl restart microshift
    Copy to Clipboard

  4. 运行以下命令应用清单并启动 busybox pod： 

    $ oc get pods -n busybox
    Copy to Clipboard

第 2 章 删除或更新 Kustomize 清单资源

MicroShift 支持以下删除清单资源：

  • 清单删除：当您需要从集群中删除资源时，可以删除清单。
  • 清单升级：在应用程序升级过程中，可能需要删除一些资源，而其他资源则保留下来保留数据。

在创建新清单时，您可以使用 manifest resource delete 来删除或更新旧对象，确保没有冲突或问题。

重要

放置在 删除 子目录中的清单文件不会自动删除，需要手动删除。只有放入删除子目录中的清单文件中列出的资源才会删除。

2.1. 清单删除如何工作

默认情况下，MicroShift 会在清单路径中的 删除 子目录中搜索删除清单。当用户在这些子目录中放置清单时，MicroShift 会在系统启动时删除清单。阅读以下内容，以了解清单删除如何在 MicroShift 中正常工作。

  1. 每次系统启动时，在应用清单之前，MicroShift 会在配置的 manifests 目录中扫描以下 删除 子目录，以识别需要删除的清单：

    • /usr/lib/microshift/manifests/delete
    • /usr/lib/microshift/manifests.d/delete/*
    • /etc/microshift/manifests/delete
    • /etc/microshift/manifests.d/delete/*
  2. MicroShift 通过运行与 kubectl delete --ignore-not-found -k 命令等效的等效，删除删除目录中定义的清单中定义的资源。

2.2. 清单资源删除的用例

以下小节解释了使用清单资源删除的用例。

2.2.1. 为 RPM 系统删除清单

在 RPM 系统删除场景中使用以下流程来完全删除清单中定义的资源。

流程

  1. 识别需要放入 删除 子目录中的清单。

  2. 运行以下命令，创建将放置清单的 delete 子目录： 

    $ sudo mkdir -p <path_of_delete_directory>
    1
    Copy to Clipboard
    1
    将 <path_of_delete_directory > 替换为以下有效目录路径之一： /etc/microshift/manifests.d/delete,/etc/microshift/manifests/delete/, /usr/lib/microshift/manifests.d/delete, 或 /usr/lib/microshift/manifests/delete。

  3. 运行以下命令，将清单文件移到配置的 manifests 目录下的其中一个 删除 子目录中： 

    $ [sudo] mv <path_of_manifests> <path_of_delete_directory>
    Copy to Clipboard

    其中： <path_of_manifests > :: 指定要删除的清单的路径，例如 /etc/microshift/manifests.d/010-SOME-MANIFEST。<path_of_delete_directory > :: 指定以下有效目录路径之一： /etc/microshift/manifests.d/delete,/etc/microshift/manifests/delete,/usr/lib/microshift/manifests.d/delete 或 /usr/lib/microshift/manifests/delete。

  4. 运行以下命令重启 MicroShift： 

    $ sudo systemctl restart microshift
    Copy to Clipboard
  5. MicroShift 在清单文件放在 delete 子目录中后，检测和删除资源。

2.2.2. 为 OSTree 系统删除清单

使用以下步骤完全删除清单中定义的资源。

重要

对于 OSTree 安装，删除 子目录是只读的。

流程

  1. 识别需要放入 删除 子目录中的清单。
  2. 将清单打包到 RPM 中。如需了解将清单打包到 RPM 的步骤，请参阅为应用程序构建 RPM 软件包。
  3. 将打包的 RPM 添加到蓝图文件中，以将其安装到正确的位置。如需了解 将 RPM 添加到蓝图中的流程，请参阅在蓝图中添加应用程序 RPM。

2.2.3. 升级 RPM 系统的清单

使用以下步骤删除某些资源，同时保留其他资源来保留数据。

流程

  1. 识别需要更新的清单。
  2. 创建要在清单目录中应用的新清单。
  3. 为资源删除创建新清单。不需要在这些清单中包含 spec。请参阅使用清单示例 使用示例创建新清单。
  4. 使用"删除 RPM 系统清单"中的流程来创建 删除 子目录，并将为资源删除创建的清单放在此路径中。

2.2.4. 为 OSTree 系统升级清单

使用以下步骤删除某些资源，同时保留其他资源来保留数据。

重要

对于 OSTree 系统，删除 子目录是只读的。

流程

  1. 识别需要更新的清单。
  2. 创建一个新清单，以应用到清单目录中。请参阅使用清单示例 使用示例创建新清单。
  3. 创建一个新清单，以放入删除子目录中的资源 删除。
  4. 使用"为 OSTree 系统删除清单"中的流程来删除清单。

第 3 章 使用 MicroShift Observability

MicroShift Observability 收集并传输系统数据，用于监控和分析。数据包括性能和使用情况指标，以及错误报告。

3.1. 安装并启用 MicroShift Observability

您可以随时安装 MicroShift Observability，包括在初始 MicroShift 安装过程中。

流程

  1. 输入以下命令安装 microshift-observability RPM： 

    $ sudo dnf install microshift-observability
    Copy to Clipboard

  2. 输入以下命令启用 microshift-observability 系统服务： 

    $ sudo systemctl enable microshift-observability
    Copy to Clipboard

  3. 输入以下命令启动 microshift-observability 系统服务： 

    $ sudo systemctl start microshift-observability
    Copy to Clipboard

  4. 在初始安装后重启 MicroShift。 

    $ sudo systemctl restart microshift-observability
    Copy to Clipboard

如果您启动 microshift-observability RPM 后没有输出，则安装成功。

3.2. 配置 MicroShift Observability

您必须通过指定有效端点在安装 MicroShift Observability 后配置它。如果没有指定端点，MicroShift Observability 不会启动。

您可以在启动 MicroShift 前为每个配置指定任何 OpenTelemetry 协议(OTLP)兼容端点。

流程

  1. 更新 /etc/microshift/observability/opentelemetry-collector.yaml 文件，以使用以下信息指定与 OTLP 兼容的端点：端点必须链接到 IP 地址或主机名，以及 OTLP 服务的端口号。

    与 OTLP 兼容的端点配置

    # ...
exporters:
  otlp:
    sending_queue:
      storage: file_storage
    endpoint: ${env:OTEL_BACKEND}:4317
    1 
    
    tls:
      insecure: true
# ...
service:
# ...
  telemetry:
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: http://${env:OTEL_BACKEND}:4318
    2 
    
# ...
    Copy to Clipboard

    1 2
    将 ${env:OTEL_BACKEND} 替换为远程后端的 IP 地址或主机名。此 IP 地址解析为本地节点的主机名。MicroShift 服务日志中会报告无法访问的端点。

  2. 每次更新 opentelemetry-collector.yaml 文件时，您必须重启 MicroShift Observability 以应用更新。

    输入以下命令重启 MicroShift Observability： 

    $ sudo systemctl restart microshift-observability
    Copy to Clipboard

3.3. 选择 MicroShift Observability 配置

数据的数量和复杂性取决于预定义的配置。这些配置决定了数据源的数量和传输的数据量。这些配置被定义为 small、medium 和 large （默认）。

opentelemetry-collector.yaml 文件包含用于收集用于监控系统资源的数据的特定参数。收集的数据中包含集群事件的所有警告。MicroShift Observability 收集并传输以下资源的数据：

  • 容器、pod 和节点的 CPU、内存、磁盘和网络指标
  • Kubernetes 事件
  • 主机 CPU、内存、磁盘和网络指标
  • 用于某些 MicroShift 服务和依赖项的系统日志
  • 由具有 prometheus.io/scrape:true 注解的 pod 公开的指标

将 exporters.otlp.endpoint 和 services.telemetry.metrics.readers[0].endpoint 字段的值替换为远程后端的 IP 地址或主机名。此 IP 地址解析为本地节点的主机名。MicroShift observability 服务日志中会报告任何无法访问的端点。

3.4. 选择小配置

您可以通过更新 YAML 文件，将 MicroShift Observability 配置为从各种源收集最小性能和资源信息。

  1. 通过在 /etc/microshift/observability/opentelemetry-collector.yaml 文件中添加以下信息来选择小配置： 

     receivers:
  kubeletstats:
    auth_type: tls
    ca_file: /var/lib/microshift/certs/ca-bundle/client-ca.crt
    key_file: /var/lib/microshift/certs/admin-kubeconfig-signer/openshift-observability-client/client.key
    cert_file: /var/lib/microshift/certs/admin-kubeconfig-signer/openshift-observability-client/client.crt
    insecure_skip_verify: true
    collection_interval: 10s
    endpoint: "${env:K8S_NODE_NAME}:10250"
    node: ${env:K8S_NODE_NAME}
    k8s_api_config:
      auth_type: kubeConfig
  k8s_events:
    auth_type: kubeConfig
processors:
  batch:
  resourcedetection/system:
    detectors: [ "system" ]
    system:
      hostname_sources: [ "os" ]
exporters:
  otlp:
    sending_queue:
      storage: file_storage
    endpoint: ${env:OTEL_BACKEND}:4317
    1 
    
    tls:
      insecure: true
extensions:
  file_storage:
    directory: /var/lib/microshift-observability
service:
  extensions: [ file_storage ]
  pipelines:
    metrics/kubeletstats:
      receivers: [ kubeletstats ]
      processors: [ batch ]
      exporters: [ otlp ]
    logs/kube_events:
      receivers: [ k8s_events ]
      processors: [ resourcedetection/system, batch ]
      exporters: [ otlp ]
  telemetry:
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: http://${env:OTEL_BACKEND}:4318
    2
    Copy to Clipboard
    1 2
    将变量 ${env:OTEL_BACKEND} 替换为远程后端的 IP 地址或主机名。此 IP 地址解析为本地节点的主机名。MicroShift 服务日志中会报告任何无法访问的端点。
  2. 重启 MicroShift Observability 以完成配置选择。

3.5. 选择介质配置

您可以通过更新 YAML 文件，将 MicroShift Observability 配置为从各种源收集性能和资源信息。

  1. 通过在 /etc/microshift/observability/opentelemetry-collector.yaml 文件中添加以下信息来选择介质配置： 

     receivers:
  kubeletstats:
    auth_type: tls
    ca_file: /var/lib/microshift/certs/ca-bundle/client-ca.crt
    key_file: /var/lib/microshift/certs/admin-kubeconfig-signer/openshift-observability-client/client.key
    cert_file: /var/lib/microshift/certs/admin-kubeconfig-signer/openshift-observability-client/client.crt
    insecure_skip_verify: true
    collection_interval: 10s
    endpoint: "${env:K8S_NODE_NAME}:10250"
    node: ${env:K8S_NODE_NAME}
    k8s_api_config:
      auth_type: kubeConfig
  k8s_events:
    auth_type: kubeConfig
  journald:
    units:
      - microshift
    priority: info
processors:
  batch:
  resourcedetection/system:
    detectors: [ "system" ]
    system:
      hostname_sources: [ "os" ]
exporters:
  otlp:
    sending_queue:
      storage: file_storage
    endpoint: ${env:OTEL_BACKEND}:4317
    1 
    
    tls:
      insecure: true
extensions:
  file_storage:
    directory: /var/lib/microshift-observability
service:
  extensions: [ file_storage ]
  pipelines:
    metrics/kubeletstats:
      receivers: [ kubeletstats ]
      processors: [ batch ]
      exporters: [ otlp ]
    logs/kube_events:
      receivers: [ k8s_events ]
      processors: [ resourcedetection/system, batch ]
      exporters: [ otlp ]
    logs/journald:
      receivers: [ journald ]
      processors: [ resourcedetection/system ]
      exporters: [ otlp ]
  telemetry:
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: http://${env:OTEL_BACKEND}:4318
    2
    Copy to Clipboard
    1 2
    将变量 ${env:OTEL_BACKEND} 替换为远程后端的 IP 地址或主机名。此 IP 地址解析为本地节点的主机名。任何无法访问的端点都会在 microshift-observability 服务日志中报告。
  2. 重启 MicroShift Observability 以完成配置选择。

3.6. 选择大型配置

您可以通过更新 YAML 文件，将 MicroShift Observability 配置为从最大源数收集最大性能和资源信息。

  1. 通过在 /etc/microshift/observability/opentelemetry-collector.yaml 文件中添加以下信息来选择大型配置。large 是默认配置。 

    receivers:
  kubeletstats:
    auth_type: tls
    ca_file: /var/lib/microshift/certs/ca-bundle/client-ca.crt
    key_file: /var/lib/microshift/certs/admin-kubeconfig-signer/openshift-observability-client/client.key
    cert_file: /var/lib/microshift/certs/admin-kubeconfig-signer/openshift-observability-client/client.crt
    insecure_skip_verify: true
    collection_interval: 10s
    endpoint: "${env:K8S_NODE_NAME}:10250"
    node: ${env:K8S_NODE_NAME}
    k8s_api_config:
      auth_type: kubeConfig
  k8s_events:
    auth_type: kubeConfig
  hostmetrics:
    root_path: /
    collection_interval: 10s
    scrapers:
      cpu:
      memory:
      network:
      disk:
      filesystem:
  journald:
    units:
      - microshift
      - microshift-observability
      - microshift-etcd
      - crio
      - openvswitch.service
      - ovsdb-server.service
      - ovs-vswitchd.service
    priority: info
  prometheus:
    config:
      scrape_configs:
        - job_name: k8s
          scrape_interval: 10s
          kubernetes_sd_configs:
            - kubeconfig_file: /var/lib/microshift/resources/observability-client/kubeconfig
              role: pod
          relabel_configs:
              # Only scrape Pods with annotation "prometheus.io/scrape": "true"
            - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
              action: keep
              regex: true
              # Use value of "prometheus.io/path" annotation for scraping
            - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
              action: replace
              target_label: __metrics_path__
              regex: (.+)
              # Use value of "prometheus.io/port" annotation for scraping
            - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
              action: replace
              regex: ([^:]+)(?::\d+)?;(\d+)
              replacement: $1:$2
              target_label: __address__
processors:
  batch:
  resourcedetection/system:
    detectors: [ "system" ]
    system:
      hostname_sources: [ "os" ]
exporters:
  otlp:
    sending_queue:
      storage: file_storage
    endpoint: ${env:OTEL_BACKEND}:4317
    1 
    
    tls:
      insecure: true
extensions:
  file_storage:
    directory: /var/lib/microshift-observability
service:
  extensions: [ file_storage ]
  pipelines:
    metrics/kubeletstats:
      receivers: [ kubeletstats ]
      processors: [ batch ]
      exporters: [ otlp ]
    metrics/hostmetrics:
      receivers: [ hostmetrics ]
      processors: [ resourcedetection/system, batch ]
      exporters: [ otlp ]
    logs/kube_events:
      receivers: [ k8s_events ]
      processors: [ resourcedetection/system, batch ]
      exporters: [ otlp ]
    logs/host:
      receivers: [ hostmetrics ]
      processors: [ resourcedetection/system ]
      exporters: [ otlp ]
    logs/journald:
      receivers: [ journald ]
      processors: [ resourcedetection/system ]
      exporters: [ otlp ]
    metrics/pods:
      receivers: [ prometheus ]
      processors: [ batch ]
      exporters: [ otlp ]
  telemetry:
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: http://${env:OTEL_BACKEND}:4318
    2
    Copy to Clipboard
    1 2
    将变量 ${env:OTEL_BACKEND} 替换为远程后端的 IP 地址或主机名。此 IP 地址解析为本地节点的主机名。任何无法访问的端点都会在 microshift-observability 服务日志中报告。
  2. 重启 MicroShift Observability 以完成配置选择。

3.7. 验证 MicroShift Observability 状态

MicroShift Observability 启动后，您可以使用 systemd 服务验证状态。MicroShift Observability 服务日志作为 journald 日志提供。

流程

  1. 输入以下命令检查 MicroShift Observability 状态： 

    $ sudo systemctl status microshift-observability
    Copy to Clipboard

  2. 输入以下命令检查 MicroShift Observability 日志： 

    $ sudo journalctl -u microshift-observability
    Copy to Clipboard

第 4 章 在 RHEL for Edge 镜像中嵌入应用程序的选项

您可以在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中嵌入基于微服务的工作负载和应用程序，以便在 MicroShift 集群中运行。嵌入的应用程序可以直接安装在边缘设备上，以便在断开连接的或离线环境中运行。

4.1. 将应用程序 RPM 添加到 rpm-ostree 镜像

如果您的应用包含 API、容器镜像和用于部署的配置文件，如清单，您可以构建应用程序 RPM。然后，您可以在 RHEL for Edge 系统镜像中添加 RPM。

以下是在完全自包含的操作系统镜像中嵌入应用程序或工作负载的流程：

  • 构建您自己的 RPM，其中包含您的应用程序清单。
  • 将 RPM 添加到用于安装 MicroShift 的蓝图中。
  • 将工作负载容器镜像添加到同一蓝图中。
  • 创建可引导 ISO。

有关在 RHEL for Edge 镜像中准备和嵌入应用程序的逐步指南，请使用以下教程：

4.2. 将应用程序清单添加到镜像以供离线使用

如果您有一个简单的应用程序，其中包含几个用于部署的文件，如清单，您可以将这些清单直接添加到 RHEL for Edge 系统镜像中。

如需示例，请参阅以下 RHEL for Edge 文档中的"创建自定义文件蓝图自定义"部分：

4.3. 嵌入应用程序以供离线使用

如果您的应用程序包含多个文件，您可以嵌入应用程序以离线使用。请参见以下步骤：

第 5 章 嵌入应用程序以供离线使用

您可以在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中嵌入基于微服务的工作负载和应用程序。嵌入意味着您可以在 air-gapped、断开连接或离线环境中运行 MicroShift 集群。

5.1. 嵌入工作负载容器镜像以供离线使用

要在边缘的设备中嵌入没有网络连接的容器镜像，您必须创建一个新容器，挂载 ISO，然后将内容复制到文件系统中。

先决条件

  • 有到主机的 root 访问权限。
  • 应用程序 RPM 已添加到蓝图中。
  • 已安装 OpenShift CLI（oc）。

流程

  1. 运行以下命令，呈现清单，提取所有容器镜像引用，并将应用程序镜像转换为蓝图容器源： 

    $ oc kustomize ~/manifests | grep "image:" | grep -oE '[^ ]+$' | while read line; do echo -e "[[containers]]\nsource = \"${line}\"\n"; done >><my_blueprint>.toml
    Copy to Clipboard

  2. 运行以下命令，将更新的蓝图推送到镜像构建器： 

    $ sudo composer-cli blueprints push <my_blueprint>.toml
    Copy to Clipboard

  3. 如果您的工作负载容器位于私有存储库中，则必须为镜像构建器提供必要的 pull secret：

    1. 在 /etc/osbuild-worker/osbuild-worker.toml 配置文件中的 [containers] 部分中设置 auth_file_path，以指向 pull secret。

    2. 如果需要，为 pull secret 创建目录和文件，例如：

      目录和文件示例

      [containers]
auth_file_path = "/<path>/pull-secret.json"
      1
      Copy to Clipboard

      1
      使用之前设置的自定义位置来复制和检索镜像。

  4. 运行以下命令来构建容器镜像： 

    $ sudo composer-cli compose start-ostree <my_blueprint> edge-commit
    Copy to Clipboard
  5. 继续您首选的 rpm-ostree 镜像流，如等待构建完成、导出镜像并将其集成到 rpm-ostree 存储库或创建可引导 ISO。

第 6 章 嵌入 MicroShift 应用程序教程

以下教程提供了如何在 RHEL for Edge 镜像中嵌入应用程序，以便在各种环境中使用 MicroShift 集群的详细示例。

6.1. 嵌入应用程序 RPM 指南

以下教程列出了 MicroShift 安装步骤，并添加用于嵌入应用程序的工作流描述。如果您已熟悉 rpm-ostree 系统，如 Red Hat Enterprise Linux for Edge (RHEL for Edge)和 MicroShift，您可以直接进入这个步骤。

6.1.1. 安装工作流查看

嵌入应用程序需要一个类似的工作流，才能将 MicroShift 嵌入到 RHEL for Edge 镜像中。

  • 下图显示了如何将 RPM、容器和文件等系统工件添加到蓝图中，并由镜像 composer 创建 ostree 提交。
  • 然后，ostree 提交可以遵循 ISO 路径或边缘设备的存储库路径。
  • ISO 路径可用于断开连接的环境，而存储库路径通常用于连接网络。

嵌入 MicroShift 工作流

468 RHbM install workflow 1023 1

查看这些步骤可帮助您了解嵌入应用程序所需的步骤：

  1. 要在 RHEL for Edge 上嵌入 MicroShift，请将 MicroShift 存储库添加到镜像构建器中。
  2. 您创建了声明所有 RPM、容器镜像、文件和自定义的蓝图，包括添加 MicroShift。
  3. 将蓝图添加到镜像构建器中，并使用镜像构建器 CLI 工具(composer-cli)运行构建。此步骤创建 rpm-ostree 提交，用于创建容器镜像。此镜像包含 RHEL for Edge。
  4. 您可以将安装程序蓝图添加到镜像构建器，以创建要从中引导的 rpm-ostree 镜像(ISO)。此构建同时包含 RHEL for Edge 和 MicroShift。
  5. 您下载了带有 MicroShift 嵌入的 ISO，准备好使用它，然后将其安装到边缘设备中。

6.1.2. 嵌入应用程序 RPM 工作流

设置满足镜像构建器要求的构建主机后，您可以使用清单目录的形式将应用程序添加到镜像。这些步骤后，将应用程序或工作负载嵌入到新 ISO 中的最简单方法是创建自己的 RPM 来包括清单。您的应用程序 RPM 包含描述部署的所有配置文件。

以下"嵌入的应用程序工作流"镜像演示了如何在单个应用程序 RPM 构建中组合 Kubernetes 应用程序清单和 RPM 规格文件。此构建成为在 ostree 提交中嵌入 MicroShift 的工作流中包含的 RPM 工件。

嵌入应用程序工作流

468 RHbM install workflow 1023 2

以下流程使用 rpmbuild 工具创建规格文件和本地存储库。规范文件定义了如何构建软件包，将应用程序清单移到 MicroShift 的 RPM 软件包中的正确位置，以提取它们。然后，该 RPM 软件包被嵌入到 ISO 中。

6.1.3. 准备制作应用程序 RPM

要构建自己的 RPM，请选择您选择的工具，如 rpmbuild 工具，并在主目录中初始化 RPM 构建树。以下是一个示例过程。只要您的 RPM 可以被镜像构建器访问，就可以使用您喜欢的方法构建应用程序 RPM。

先决条件

  • 您已设置了满足镜像构建器系统要求的 Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.6 构建主机。
  • 有到主机的 root 访问权限。

流程

  1. 运行以下命令安装 rpmbuild 工具并为它创建 yum 存储库： 

    $ sudo dnf install rpmdevtools rpmlint yum-utils createrepo
    Copy to Clipboard

  2. 运行以下命令，创建构建 RPM 软件包所需的文件树： 

    $ rpmdev-setuptree
    Copy to Clipboard

验证

  • 运行以下命令列出以确认创建的目录： 

    $ ls ~/rpmbuild/
    Copy to Clipboard

    输出示例

    BUILD RPMS SOURCES SPECS SRPMS
    Copy to Clipboard

6.1.4. 为应用程序清单构建 RPM 软件包

要构建自己的 RPM，您必须创建一个 spec 文件，该文件将应用程序清单添加到 RPM 软件包中。以下是一个示例过程。只要镜像构建器可以访问应用程序 RPM 和其他元素，就可以使用您喜欢的方法。

先决条件

  • 您已设置了满足镜像构建器系统要求的 Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.6 构建主机。
  • 有到主机的 root 访问权限。
  • 创建构建 RPM 软件包所需的文件树。

流程

  1. 在 ~/rpmbuild/SPECS 目录中，使用以下模板创建一个文件，如 & lt;application_workload_manifests.spec > ：

    spec 文件示例

    Name: <application_workload_manifests>
Version: 0.0.1
Release: 1%{?dist}
Summary: Adds workload manifests to microshift
BuildArch: noarch
License: GPL
Source0: %{name}-%{version}.tar.gz
#Requires: microshift
%description
Adds workload manifests to microshift
%prep
%autosetup
%install
    1 
    
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/%{_prefix}/lib/microshift/manifests
cp -pr ~/manifests $RPM_BUILD_ROOT/%{_prefix}/lib/microshift/
%clean
rm -rf $RPM_BUILD_ROOT

%files
%{_prefix}/lib/microshift/manifests/**
%changelog
* <DDD MM DD YYYY username@domain - V major.minor.patch>
- <your_change_log_comment>
    Copy to Clipboard

    1
    %install 部分在 RPM 软件包 /usr/lib/microshift/manifests/ 中创建目标目录，并从源主目录 ~/manifests 复制清单。
    重要

    所有所需的 YAML 文件都必须位于源主目录 ~/manifests 中，如果使用 kustomize.yaml 文件，包括 kustomize.yaml 文件。

  2. 运行以下命令，在 ~/rpmbuild/RPMS 目录中构建 RPM 软件包： 

    $ rpmbuild -bb ~/rpmbuild/SPECS/<application_workload_manifests.spec>
    Copy to Clipboard

6.1.5. 在蓝图中添加应用程序 RPM

要将应用程序 RPM 添加到蓝图中，您必须创建一个本地仓库，供镜像构建器用于创建 ISO。在这个版本中，您的工作负载所需的容器镜像可以通过网络拉取。

先决条件

  • 有到主机的 root 访问权限。
  • ~/rpmbuild/RPMS 目录中存在工作负载或应用程序 RPM。

流程

  1. 运行以下命令来创建本地 RPM 存储库： 

    $ createrepo ~/rpmbuild/RPMS/
    Copy to Clipboard

  2. 运行以下命令，授予镜像构建器对 RPM 存储库的访问权限： 

    $ sudo chmod a+rx ~
    Copy to Clipboard
    注意

    您必须确保镜像构建器具有访问镜像构建所需的所有文件的所有必要权限，或者无法继续构建。

  3. 使用以下模板创建蓝图文件 repo-local-rpmbuild.toml ： 

    id = "local-rpm-build"
name = "RPMs build locally"
type = "yum-baseurl"
url = "file://<path>/rpmbuild/RPMS"
    1 
    
check_gpg = false
check_ssl = false
system = false
    Copy to Clipboard
    1
    指定创建您选择的位置的路径的一部分。在后续命令中使用此路径来设置存储库并复制 RPM。

  4. 运行以下命令，将存储库添加为镜像构建器的源： 

    $ sudo composer-cli sources add repo-local-rpmbuild.toml
    Copy to Clipboard

  5. 通过添加以下行来在蓝图中添加 RPM： 

    …
[[packages]]
name = "<application_workload_manifests>"
    1 
    
version = "*"
…
    Copy to Clipboard
    1
    在此处添加工作负载的名称。

  6. 运行以下命令，将更新的蓝图推送到镜像构建器： 

    $ sudo composer-cli blueprints push repo-local-rpmbuild.toml
    Copy to Clipboard

  7. 此时，您可以运行镜像构建器来创建 ISO，或嵌入容器镜像以离线使用。

    1. 要创建 ISO，请运行以下命令启动镜像构建器： 

      $ sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commit
      Copy to Clipboard

在这种情况下，容器镜像会在启动时由边缘设备通过网络拉取。

第 7 章 对应用程序和工作负载健康检查使用 greenboot

您可以使用 greenboot 健康检查来评估工作负载和应用程序的健康状态。

7.1. 工作负载健康检查如何工作

Greenboot 健康检查对直接可维护性或不存在的边缘设备有用。您可以使用 greenboot 健康检查来评估工作负载和应用程序的健康状态。这些额外的健康检查对软件问题检测和自动系统回滚很有用。

工作负载或应用程序健康检查可以使用 MicroShift 核心服务已实现的 MicroShift 基本健康检查功能。建议为您的应用程序创建自己的综合脚本。例如，您可以编写一个验证服务是否已启动的时间。

您还可以使用 microshift healthcheck 命令，该命令可以运行检查工作负载的基本功能是否如预期运行。

重要

与检查 /usr/share/microshift/functions/greenboot.sh 中的工作负载健康状况相关的以下功能已弃用，并计划在以后的发行版本中删除：

  • wait_for
  • namespace_images_downloaded
  • namespace_deployment_ready
  • namespace_daemonset_ready
  • namespace_pods_ready
  • namespace_pods_not_restarting
  • print_failure_logs
  • log_failure_cmd
  • log_script_exit
  • lvmsDriverShouldExist
  • csiComponentShouldBeDeploy

7.2. 如何使用 MicroShift 健康检查命令

microshift healthcheck 命令检查提供类型的工作负载是否存在，并验证指定超时持续时间的状态。就绪副本数（即 pod）必须与预期数量匹配。

要成功运行 microshift healthcheck 命令，请使用以下先决条件：

  • 从 root 用户帐户执行命令。
  • 启用 MicroShift 服务。

您可以在 microshift healthcheck 命令中添加以下操作：

  • -v=2 来提高输出的详细程度
  • --timeout="${WAIT_TIMEOUT_SECS}s"，以覆盖默认的 600s 超时值
  • --namespace '< namespace> 指定工作负载的命名空间

  • --deployments '<application-deployment > 以检查特定部署的就绪情况

    示例命令

    $ sudo microshift healthcheck -v=2 --timeout="300s" --namespace busybox --deployments busybox-deployment
    Copy to Clipboard

    输出示例

    ??? I0410 08:54:03.766578    5898 service.go:29] microshift.service is enabled
??? I0410 08:54:03.766699    5898 service.go:31] Waiting 5m0s for microshift.service to be ready
??? I0410 08:54:03.768794    5898 service.go:38] microshift.service is ready
??? I0410 08:54:03.770585    5898 utils.go:34] Waiting for 1 goroutines
??? I0410 08:54:03.770955    5898 workloads.go:94] Waiting 5m0s for deployment/busybox-deployment in busybox
??? I0410 08:54:03.777830    5898 workloads.go:132] Deployment/busybox-deployment in busybox is ready
??? I0410 08:54:03.777858    5898 healthcheck.go:75] Workloads are ready
    Copy to Clipboard

microshift healthcheck 命令还接受以下附加参数来指定其他类型的工作负载：

  • --daemonsets
  • --statefulsets
  • 这些选项采用以逗号分隔的资源列表，例如：- daemonsets ovnkube-master,ovnkube-node。

另外，a- custom 选项可与 JSON 字符串一起使用，例如： 

$ sudo microshift healthcheck --custom '{"openshift-storage":{"deployments":
    ["lvms-operator"], "daemonsets": ["vg-manager"]}, "openshift-ovn-kubernetes":
    {"daemonsets": ["ovnkube-master", "ovnkube-node"]}}'
Copy to Clipboard

输出示例

??? I0410 08:54:25.291059    5979 service.go:29] microshift.service is enabled
??? I0410 08:54:25.291167    5979 service.go:31] Waiting 5m0s for microshift.service to be ready
??? I0410 08:54:25.293188    5979 service.go:38] microshift.service is ready
??? I0410 08:54:25.294331    5979 workloads.go:58] Waiting 5m0s for daemonset/ovnkube-node in openshift-ovn-kubernetes
??? I0410 08:54:25.294351    5979 workloads.go:58] Waiting 5m0s for daemonset/ovnkube-master in openshift-ovn-kubernetes
??? I0410 08:54:25.294331    5979 workloads.go:58] Waiting 5m0s for daemonset/vg-manager in openshift-storage
??? I0410 08:54:25.294341    5979 workloads.go:94] Waiting 5m0s for deployment/lvms-operator in openshift-storage
??? I0410 08:54:25.309739    5979 workloads.go:89] Daemonset/ovnkube-node in openshift-ovn-kubernetes is ready
??? I0410 08:54:25.310213    5979 workloads.go:89] Daemonset/vg-manager in openshift-storage is ready
??? I0410 08:54:25.310731    5979 workloads.go:132] Deployment/lvms-operator in openshift-storage is ready
??? I0410 08:54:25.311017    5979 workloads.go:89] Daemonset/ovnkube-master in openshift-ovn-kubernetes is ready
??? I0410 08:54:25.311189    5979 healthcheck.go:52] Workloads are ready
Copy to Clipboard

7.3. 如何为您的应用程序创建健康检查脚本

您可以在您选择的文本编辑器中创建工作负载或应用程序健康检查脚本。将脚本保存到 /etc/greenboot/check/required.d 目录中。当 /etc/greenboot/check/required.d 目录中的脚本退出时，greenboot 会触发重启尝试修复系统。

注意

如果 /etc/greenboot/check/required.d 目录中的任何脚本退出并显示错误，则会触发重新引导。

如果您的健康检查逻辑需要任何 post-check 步骤，您也可以创建额外的脚本并将其保存到相关的 greenboot 目录中。例如：

  • 您还可以在 /etc/greenboot/green.d 中声明成功后要运行的 shell 脚本。
  • 您可以将在声明引导失败后要运行的 shell 脚本放在 /etc/greenboot/red.d 中。例如，如果您在重启前有修复系统的步骤，您可以为用例创建脚本并将其放在 /etc/greenboot/red.d 目录中。

7.3.1. 工作负载 max 持续时间或超时脚本示例

以下示例使用 MicroShift 核心服务健康检查脚本作为模板。

7.3.1.1. 创建健康检查脚本的基本先决条件
  • 必须安装工作负载。
  • 您必须有 root 访问权限。
7.3.1.2. 示例和功能要求

您可以使用以下示例健康检查脚本开始。根据您的用例，将其添加到其中。在自定义工作负载健康检查脚本中，您必须定义相关的命名空间、部署、daemonset 和 statefulset。

重要

为您的应用程序选择一个名称前缀，以确保它在 40_microshift_running_check.sh 脚本后运行，该脚本为其核心服务实施 MicroShift 健康检查过程。

greenboot 健康检查脚本示例

#!/bin/bash
set -e

SCRIPT_NAME=$(basename $0)

# Load the workload health check functions library
source /usr/share/microshift/functions/greenboot.sh

# Stop the script if the user running it is not 'root'
if [ $(id -u) -ne 0 ] ; then
    echo "The '${SCRIPT_NAME}' script must be run with the 'root' user privileges"
    exit 1
fi

echo "STARTED"

# Set the wait timeout for the current check based on the boot counter
WAIT_TIMEOUT_SECS=$(get_wait_timeout)

/usr/bin/microshift healthcheck -v=2 --timeout="${WAIT_TIMEOUT_SECS}s" --namespace busybox --deployments busybox-deployment
Copy to Clipboard

重要

与检查之前包含在 /usr/share/microshift/functions/greenboot.sh 脚本文件中的工作负载健康状况相关的功能已弃用。您可以编写自定义脚本，或使用带有各种选项的 microshift healthcheck 命令。如需更多信息，请参阅"工作负载健康检查脚本的工作方式"。

7.3.2. 测试工作负载健康检查脚本

greenboot 工作负载健康检查脚本的输出因主机系统类型而异。仅包含 {op-system-full} 系统类型的输出示例。

先决条件

  • 有 root 访问权限。
  • 已安装工作负载。
  • 为工作负载创建了健康检查脚本。
  • MicroShift 服务已启用。

流程

  1. 要测试 greenboot 是否在运行健康检查脚本文件，请运行以下命令重启主机： 

    $ sudo reboot
    Copy to Clipboard

  2. 运行以下命令，检查 greenboot 健康检查的输出： 

    $ sudo journalctl -o cat -u greenboot-healthcheck.service
    Copy to Clipboard
    注意

    MicroShift 核心服务健康检查在工作负载健康检查前运行。

    RHEL 系统的镜像模式输出示例

    Starting greenboot Health Checks Runner...
Running Required Health Check Scripts...
Script '00_required_scripts_start.sh' SUCCESS
Running Wanted Health Check Scripts...
Script '00_wanted_scripts_start.sh' SUCCESS
Running Required Health Check Scripts...
--------------------
DEPRECATION NOTICE:
/usr/share/microshift/functions/greenboot.sh is now deprecated and will be removed in future release.
Planned removal: MicroShift 4.21
As a replacement consider using 'microshift healthcheck' command
--------------------
STARTED
GRUB boot variables:
boot_success=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_GREENBOOT_FAIL_MARKER=/run/microshift-greenboot-healthcheck-failed
System installation type:
bootc
System installation status:
bootcHost
??? I0403 11:54:30.526488     979 service.go:29] microshift.service is enabled
??? I0403 11:54:30.527145     979 service.go:31] Waiting 10m0s for microshift.service to be ready
??? I0403 11:58:52.530299     979 service.go:38] microshift.service is ready
??? I0403 11:58:52.532292     979 net.go:79] host gateway IP address: 192.168.112.125
??? I0403 11:58:52.555077     979 microshift_core_workloads.go:71] vgs reported: {"report":[{"vg":[{"vg_name":"rhel"}]}],"log":[]}
??? I0403 11:58:52.555138     979 microshift_core_workloads.go:93] Detected 1 volume group (rhel) - LVMS is expected
??? I0403 11:58:52.555143     979 microshift_core_workloads.go:126] Configured optional CSI components: []
??? I0403 11:58:52.555147     979 microshift_core_workloads.go:117] At least one CSI Component is enabled
??? I0403 11:58:52.555770     979 utils.go:34] Waiting for 9 goroutines
??? I0403 11:58:52.555791     979 workloads.go:94] Waiting 10m0s for deployment/service-ca in openshift-service-ca
??? I0403 11:58:52.555890     979 workloads.go:58] Waiting 10m0s for daemonset/ovnkube-master in openshift-ovn-kubernetes
??? I0403 11:58:52.555999     979 workloads.go:94] Waiting 10m0s for deployment/router-default in openshift-ingress
??? I0403 11:58:52.556096     979 workloads.go:58] Waiting 10m0s for daemonset/dns-default in openshift-dns
??? I0403 11:58:52.556244     979 workloads.go:58] Waiting 10m0s for daemonset/ovnkube-node in openshift-ovn-kubernetes
??? I0403 11:58:52.556330     979 workloads.go:94] Waiting 10m0s for deployment/lvms-operator in openshift-storage
??? I0403 11:58:52.556382     979 workloads.go:58] Waiting 10m0s for daemonset/vg-manager in openshift-storage
??? I0403 11:58:52.556425     979 workloads.go:94] Waiting 10m0s for deployment/csi-snapshot-controller in kube-system
??? I0403 11:58:52.556474     979 workloads.go:58] Waiting 10m0s for daemonset/node-resolver in openshift-dns
??? I0403 11:58:52.574284     979 workloads.go:89] Daemonset/ovnkube-node in openshift-ovn-kubernetes is ready
??? I0403 11:58:52.574344     979 workloads.go:89] Daemonset/dns-default in openshift-dns is ready
??? I0403 11:59:12.871058     979 workloads.go:89] Daemonset/node-resolver in openshift-dns is ready
??? I0403 11:59:12.871621     979 workloads.go:89] Daemonset/ovnkube-master in openshift-ovn-kubernetes is ready
??? I0403 11:59:12.871748     979 workloads.go:132] Deployment/csi-snapshot-controller in kube-system is ready
??? I0403 11:59:25.175015     979 workloads.go:132] Deployment/service-ca in openshift-service-ca is ready
??? I0403 11:59:42.559264     979 workloads.go:132] Deployment/lvms-operator in openshift-storage is ready
??? I0403 11:59:52.557786     979 workloads.go:132] Deployment/router-default in openshift-ingress is ready
??? I0403 11:59:52.558489     979 workloads.go:89] Daemonset/vg-manager in openshift-storage is ready
??? I0403 11:59:52.558505     979 healthcheck.go:28] MicroShift is ready
Script '40_microshift_running_check.sh' SUCCESS
--------------------
DEPRECATION NOTICE:
/usr/share/microshift/functions/greenboot.sh is now deprecated and will be removed in future release.
Planned removal: MicroShift 4.21
As a replacement consider using 'microshift healthcheck' command
--------------------
STARTED
GRUB boot variables:
boot_success=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_GREENBOOT_FAIL_MARKER=/run/microshift-greenboot-healthcheck-failed
System installation type:
bootc
System installation status:
bootcHost
??? I0403 11:59:52.750474    4059 service.go:29] microshift.service is enabled
??? I0403 11:59:52.750873    4059 service.go:31] Waiting 10m0s for microshift.service to be ready
??? I0403 11:59:52.752273    4059 service.go:38] microshift.service is ready
??? I0403 11:59:52.753263    4059 utils.go:34] Waiting for 1 goroutines
??? I0403 11:59:52.753393    4059 workloads.go:94] Waiting 10m0s for deployment/kserve-controller-manager in redhat-ods-applications
??? I0403 12:00:02.755475    4059 workloads.go:132] Deployment/kserve-controller-manager in redhat-ods-applications is ready
??? I0403 12:00:02.755605    4059 healthcheck.go:75] Workloads are ready
Script '41_microshift_running_check_ai_model_serving.sh' SUCCESS
--------------------
DEPRECATION NOTICE:
/usr/share/microshift/functions/greenboot.sh is now deprecated and will be removed in future release.
Planned removal: MicroShift 4.21
As a replacement consider using 'microshift healthcheck' command
--------------------
STARTED
GRUB boot variables:
boot_success=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_GREENBOOT_FAIL_MARKER=/run/microshift-greenboot-healthcheck-failed
System installation type:
bootc
System installation status:
bootcHost
??? I0403 12:00:02.896949    4128 service.go:29] microshift.service is enabled
??? I0403 12:00:02.897208    4128 service.go:31] Waiting 10m0s for microshift.service to be ready
??? I0403 12:00:02.899492    4128 service.go:38] microshift.service is ready
??? I0403 12:00:02.900279    4128 utils.go:34] Waiting for 2 goroutines
??? I0403 12:00:02.900363    4128 workloads.go:94] Waiting 10m0s for deployment/istiod-openshift-gateway-api in openshift-gateway-api
??? I0403 12:00:02.900948    4128 workloads.go:94] Waiting 10m0s for deployment/servicemesh-operator3 in openshift-gateway-api
??? I0403 12:00:42.913338    4128 workloads.go:132] Deployment/servicemesh-operator3 in openshift-gateway-api is ready
??? I0403 12:01:12.902297    4128 workloads.go:132] Deployment/istiod-openshift-gateway-api in openshift-gateway-api is ready
??? I0403 12:01:12.902418    4128 healthcheck.go:75] Workloads are ready
Script '41_microshift_running_check_gateway_api.sh' SUCCESS
--------------------
DEPRECATION NOTICE:
/usr/share/microshift/functions/greenboot.sh is now deprecated and will be removed in future release.
Planned removal: MicroShift 4.21
As a replacement consider using 'microshift healthcheck' command
--------------------
STARTED
GRUB boot variables:
boot_success=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_GREENBOOT_FAIL_MARKER=/run/microshift-greenboot-healthcheck-failed
System installation type:
bootc
System installation status:
bootcHost
??? I0403 12:01:13.057998    4772 service.go:29] microshift.service is enabled
??? I0403 12:01:13.058107    4772 service.go:31] Waiting 10m0s for microshift.service to be ready
??? I0403 12:01:13.059839    4772 service.go:38] microshift.service is ready
??? I0403 12:01:13.060617    4772 utils.go:34] Waiting for 2 goroutines
??? I0403 12:01:13.060644    4772 workloads.go:58] Waiting 10m0s for daemonset/dhcp-daemon in openshift-multus
??? I0403 12:01:13.060686    4772 workloads.go:58] Waiting 10m0s for daemonset/multus in openshift-multus
??? I0403 12:01:13.069341    4772 workloads.go:89] Daemonset/multus in openshift-multus is ready
??? I0403 12:01:13.069450    4772 workloads.go:89] Daemonset/dhcp-daemon in openshift-multus is ready
??? I0403 12:01:13.069503    4772 healthcheck.go:75] Workloads are ready
Script '41_microshift_running_check_multus.sh' SUCCESS
--------------------
DEPRECATION NOTICE:
/usr/share/microshift/functions/greenboot.sh is now deprecated and will be removed in future release.
Planned removal: MicroShift 4.21
As a replacement consider using 'microshift healthcheck' command
--------------------
STARTED
GRUB boot variables:
boot_success=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_GREENBOOT_FAIL_MARKER=/run/microshift-greenboot-healthcheck-failed
System installation type:
bootc
System installation status:
bootcHost
??? I0403 12:01:13.206381    4804 service.go:29] microshift.service is enabled
??? I0403 12:01:13.206583    4804 service.go:31] Waiting 10m0s for microshift.service to be ready
??? I0403 12:01:13.207979    4804 service.go:38] microshift.service is ready
??? I0403 12:01:13.208717    4804 utils.go:34] Waiting for 2 goroutines
??? I0403 12:01:13.208779    4804 workloads.go:94] Waiting 10m0s for deployment/catalog-operator in openshift-operator-lifecycle-manager
??? I0403 12:01:13.209285    4804 workloads.go:94] Waiting 10m0s for deployment/olm-operator in openshift-operator-lifecycle-manager
??? I0403 12:01:13.215578    4804 workloads.go:132] Deployment/catalog-operator in openshift-operator-lifecycle-manager is ready
??? I0403 12:01:13.215673    4804 workloads.go:132] Deployment/olm-operator in openshift-operator-lifecycle-manager is ready
??? I0403 12:01:13.215684    4804 healthcheck.go:75] Workloads are ready
Script '50_microshift_running_check_olm.sh' SUCCESS
Running Wanted Health Check Scripts...
Finished greenboot Health Checks Runner.
    Copy to Clipboard

    RHEL for Edge 系统的部分输出示例

    #...
GRUB boot variables:
boot_success=0
boot_indeterminate=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_WAIT_TIMEOUT_SEC=600
System installation type:
ostree
System installation status:
* rhel 19619bd269094510180c845c44d0944fd9aa15925376f249c4d680a3355e51ae.0
    Version: 9.6
    origin refspec: edge:rhel-9.6-microshift-4.19
#...
    Copy to Clipboard

    RPM 系统的部分输出示例

    #...
GRUB boot variables:
boot_success=1
boot_indeterminate=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
System installation type:
RPM
System installation status:
Not an ostree / bootc system
#...
    Copy to Clipboard

第 8 章 使用 GitOps 控制器自动执行应用程序管理

带有 MicroShift 的 Argo CD 的 GitOps 是一个轻量级的附加控制器，它派生自 Red Hat OpenShift GitOps Operator。MicroShift 的 GitOps 使用 Argo CD 的命令行界面(CLI)与作为声明性 GitOps 引擎的 GitOps 控制器交互。您可以在集群和开发生命周期中一致地配置和部署基于 Kubernetes 的基础架构和应用程序。

8.1. GitOps 代理的作用

通过使用带有 MicroShift 的 Argo CD 代理的 GitOps，您可以使用以下原则：

  • 实施应用程序生命周期管理。

    • 使用在 Git 存储库中开发和维护软件的核心原则创建和管理集群和应用程序配置文件。
    • 您可以更新单个存储库和 GitOps 会自动部署新应用程序或更新现有应用程序。
    • 例如，如果您有 1,000 个边缘设备，每个设备都使用 MicroShift 和本地 GitOps 代理，您可以在所有 1,000 设备上轻松添加或更新应用程序，且只在中央 Git 存储库中进行一次更改。
  • Git 存储库包含指定环境中所需的基础架构声明描述，并包含一个自动化流程，使您的环境与上述状态匹配。
  • 您还可以使用 Git 存储库作为更改的审计跟踪，以便您可以根据 Git 流创建进程，如检查和批准实施配置更改的合并拉取请求。

8.2. 在 MicroShift 上创建 GitOps 应用程序

您可以创建自定义 YAML 配置来在 MicroShift 服务中部署和管理应用程序。要安装运行 GitOps 应用程序所需的软件包，请按照"从 RPM 软件包安装 GitOps Argo CD 清单"中的文档进行操作。

先决条件

  • 已安装 microshift-gitops 软件包。
  • Argo CD pod 在 openshift-gitops 命名空间中运行。

流程

  1. 创建 YAML 文件并为应用程序添加自定义配置：

    spring-petclinic 应用程序的 YAML 示例

    kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: default
  namespace: openshift-gitops
spec:
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  destinations:
  - namespace: '*'
    server: '*'
  sourceRepos:
  - '*'
---
kind: Application
apiVersion: argoproj.io/v1alpha1
metadata:
  name: spring-petclinic
  namespace: openshift-gitops
spec:
  destination:
    namespace: spring-petclinic
    server: https://kubernetes.default.svc
  project: default
  source:
    directory:
      recurse: true
    path: app
    repoURL: https://github.com/siamaksade/openshift-gitops-getting-started
  syncPolicy:
    automated: {}
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true
    Copy to Clipboard

  2. 要部署 YAML 文件中定义的应用程序，请运行以下命令： 

    $ oc apply -f <my_app.yaml>
    1
    Copy to Clipboard
    1
    将 <my_app.yaml > 替换为应用程序 YAML 的名称。

验证

  • 要验证应用程序是否已部署并同步，请运行以下命令： 

    $ oc get applications -A
    Copy to Clipboard

    应用程序可能需要几分钟时间来显示 Healthy 状态。

    输出示例

    NAMESPACE          NAME               SYNC STATUS   HEALTH STATUS
openshift-gitops   spring-petclinic   Synced        Healthy
    Copy to Clipboard

8.3. 在 MicroShift 中使用 GitOps 代理的限制

带有 Argo CD for MicroShift 的 GitOps 与 Red Hat OpenShift GitOps Operator 有以下区别：

  • gitops-operator 组件不与 MicroShift 一起使用。
  • 要维护 MicroShift 的小资源使用，Argo CD web 控制台不可用。您可以使用 Argo CD CLI。
  • 因为 MicroShift 是单节点，所以不支持多集群。MicroShift 的每个实例都与本地 GitOps 代理配对。
  • oc adm must-gather 命令在 MicroShift 中不可用。

8.4. GitOps 故障排除

如果 GitOps 控制器出现问题，您可以使用 OpenShift CLI (oc)工具。

8.4.1. 使用 oc adm inspect 调试 GitOps

您可以使用 OpenShift CLI (oc)调试 GitOps。

先决条件

  • 已安装 oc 命令行工具。

流程

  1. 在 GitOps 命名空间中运行时运行 oc adm inspect 命令： 

    $ oc adm inspect ns/openshift-gitops
    Copy to Clipboard

    输出示例

    Gathering data for ns/openshift-gitops...
W0501 20:34:35.978508 57625 util.go:118] the server doesn't have a resource type egressfirewalls, skipping the inspection
W0501 20:34:35.980881 57625 util.go:118] the server doesn't have a resource type egressqoses, skipping the inspection
W0501 20:34:36.040664 57625 util.go:118] the server doesn't have a resource type servicemonitors, skipping the inspection
Wrote inspect data to inspect.local.2673575938140296280.
    Copy to Clipboard

后续步骤

  • 如果 oc adm inspect 没有提供您需要的信息，您可以运行 sos 报告。

第 9 章 Pod 安全身份验证和授权

Pod 安全准入是 Kubernetes pod 安全标准的实现。使用 pod 安全准入来限制 pod 的行为。

9.1. 安全性上下文约束与 pod 安全标准同步

MicroShift 包括 Kubernetes pod 安全准入。

除了全局 pod 安全准入控制配置外，还存在一个控制器，它根据给定命名空间中的服务帐户的安全上下文约束(SCC)权限将 pod 安全准入控制 warn 和 audit 标签应用到命名空间。

重要

定义为集群有效负载一部分的命名空间会永久禁用 pod 安全准入同步。您可以根据需要，在其他命名空间中启用 pod 安全准入同步。如果 Operator 安装在用户创建的 openshift-* 命名空间中，则在命名空间中创建集群服务版本(CSV)后，默认会开启同步。

控制器检查 ServiceAccount 对象权限，以便在每个命名空间中使用安全性上下文约束。安全性上下文约束 (SCC) 根据其字段值映射到 Pod 安全配置集，控制器使用这些翻译配置集。Pod 安全准入 warn 和 audit 标签被设置为命名空间中找到的最特权 pod 安全配置集，以防止在创建 pod 时出现警告和审计日志记录。

命名空间标签基于对命名空间本地服务帐户权限的考虑。

直接应用 pod 可能会使用运行 Pod 的用户的 SCC 特权。但是，在自动标记过程中不会考虑用户权限。

9.1.1. 查看命名空间中的安全性上下文约束

您可以查看给定命名空间中的安全性上下文约束(SCC)权限。

先决条件

  • 已安装 OpenShift CLI（oc）。

流程

  • 要查看命名空间中的安全性上下文约束，请运行以下命令： 

    oc get --show-labels namespace <namespace>
    Copy to Clipboard

9.2. 控制 pod 安全准入同步

您可以为大多数命名空间启用自动 pod 安全准入同步。

当 security.openshift.io/scc.podSecurityLabelSync 字段为空或设置为 false 时，不会强制系统默认值。您必须将标签设置为 true，才能进行同步。

重要

定义为集群有效负载一部分的命名空间会永久禁用 pod 安全准入同步。这些命名空间包括：

  • default
  • kube-node-lease
  • kube-system
  • kube-public
  • openshift
  • 所有带有 openshift- 前缀的系统创建命名空间（默认为 openshift-operators 除外）,所有具有 openshift- 前缀的命名空间不会被同步。您可以为任何用户创建的 openshift-* 命名空间启用同步。除了 openshift-operators 之外，您无法为任何系统创建的 openshift-* 命名空间启用同步。

如果 Operator 安装在用户创建的 openshift-* 命名空间中，则在命名空间中创建集群服务版本(CSV)后，默认会开启同步。同步标签继承命名空间中服务帐户的权限。

流程

  • 要在命名空间中启用 pod 安全准入标签同步，请将 security.openshift.io/scc.podSecurityLabelSync 标签的值设置为 true。

    运行以下命令: 

    $ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=true
    Copy to Clipboard
注意

您可以使用 --overwrite 标志来反转命名空间中 pod 安全标签同步的影响。

第 10 章 Operator

10.1. 将 Operator 与 MicroShift 搭配使用

您可以将 Operator 与 MicroShift 搭配使用，以创建用于监控集群中运行的服务的应用程序。Operator 可以管理应用程序及其资源，如部署数据库或消息总线。作为在集群中运行的自定义软件，可以使用 Operator 来实现和自动化常见操作。

Operator 提供了更本地化的配置体验，并与 Kubernetes API 和 CLI 工具（如 kubectl 和 oc ）集成。Operator 是专为您的应用程序而设计的。Operator 允许您配置组件而不是修改全局配置文件。

MicroShift 应用程序通常预期部署在静态环境中。但是，如果在您的用例中很有用，Operator 就会可用。要确定 Operator 与 MicroShift 的兼容性，请查看 Operator 文档。

10.1.1. 如何将 Operator 与 MicroShift 集群搭配使用

将 Operator 用于 MicroShift 集群的方法有两种：

10.1.1.1. Operator 的清单

可以使用清单直接安装和管理 Operator。您可以在 MicroShift 中使用 kustomize 配置管理工具来部署应用程序。使用相同的步骤使用清单安装 Operator。

10.1.1.2. Operator 的 Operator Lifecycle Manager

您还可以使用 Operator Lifecycle Manager (OLM)将附加组件 Operator 安装到 MicroShift 集群。OLM 可用于管理广泛可用的自定义 Operator 和 Operator。构建目录需要在 MicroShift 中使用 OLM。

10.2. 在 MicroShift 中使用 Operator Lifecycle Manager

Operator Lifecycle Manager (OLM)软件包管理器在 MicroShift 中使用，用于 安装和运行可选附加组件 Operator。

10.2.1. 在 MicroShift 中使用 OLM 的注意事项

  • 在 OpenShift Container Platform 中应用的集群 Operator 不会在 MicroShift 中使用。

  • 您必须为您要用于应用程序的附加组件 Operator 创建自己的目录。默认不提供目录。

    • 每个目录都必须添加到集群中的一个可访问的 CatalogSource，以便 OLM 目录 Operator 可以使用目录进行内容。

  • 您必须使用 CLI 与 MicroShift 进行 OLM 活动。控制台和 OperatorHub GUI 不可用。

重要

在使用 Operator 之前，请验证 MicroShift 上是否支持 Operator 的供应商。

10.2.2. 确定您的 OLM 安装类型

您可以安装 OLM 软件包管理器以用于 MicroShift 4.15 或更新版本。根据您的用例，可以通过不同的方法为 MicroShift 集群安装 OLM。

10.2.3. MicroShift 中的命名空间使用

microshift-olm RPM 创建三个默认命名空间：一个用于运行 OLM，两个用于目录和 Operator 安装。您可以根据您的用例需要创建额外的命名空间。

10.2.3.1. 默认命名空间

下表列出了默认命名空间以及每个命名空间的工作方式的简短描述。

表 10.1. OLM 为 MicroShift 创建的默认命名空间

默认命名空间

详情

openshift-operator-lifecycle-manager

OLM 软件包管理器在此命名空间中运行。

openshift-marketplace

全局命名空间。默认为空。要使目录源对所有命名空间中的用户全局可用，请在 catalog-source YAML 中设置 openshift-marketplace 命名空间。

openshift-operators

Operator 在 MicroShift 中运行的默认命名空间。引用 openshift-operators 命名空间中的目录的 Operator 必须具有 AllNamespaces 监视范围。

10.2.3.2. 自定义命名空间

如果要在一个命名空间中同时使用目录和 Operator，您必须创建一个自定义命名空间。创建命名空间后，您必须在该命名空间中创建目录。在自定义命名空间中运行的所有 Operator 都必须具有相同的单命名空间监视范围。

10.2.4. 关于构建 Operator 目录

要将 Operator Lifecycle Manager (OLM)与 MicroShift 搭配使用，您必须构建自定义 Operator 目录，然后使用 OLM 管理。OpenShift Container Platform 中包含的标准目录没有包括在 MicroShift 中。

10.2.4.1. 基于文件的目录

您可以为自定义 Operator 创建目录，或过滤广泛可用 Operator 的目录。您可以组合这两种方法来创建特定用例所需的目录。要使用您自己的 Operator 和 OLM 运行 MicroShift，请使用基于文件的目录结构制作目录。

重要
  • 将目录源添加到集群时， 在 catalogSource.yaml 文件中将 securityContextConfig 值设置为 restricted。确保您的目录可以使用 restricted 权限运行。

10.2.5. 如何使用 OLM 部署 Operator

创建和部署自定义目录后，您必须创建一个 Subscription 自定义资源(CR)，该资源可以访问该目录并安装您选择的 Operator。运行 Operator 的位置取决于您在其中创建 Subscription CR 的命名空间。

重要

OLM 中的 Operator 具有监视范围。例如，一些 Operator 只支持监视自己的命名空间，其他 Operator 支持监视集群中的每个命名空间。在给定命名空间中安装的所有 Operator 必须具有相同的监视范围。

10.2.5.1. 连接和 OLM Operator 部署

Operator 可以在目录运行的任何地方部署。

  • 对于连接到互联网的集群，不需要镜像镜像。镜像可以通过网络拉取镜像。
  • 对于 MicroShift 仅可访问内部网络的受限网络，镜像必须镜像到内部 registry。
  • 对于 MicroShift 集群完全离线的用例，所有镜像都必须嵌入到 osbuild 蓝图中。
10.2.5.2. 使用全局命名空间将基于 OLM 的 Operator 添加到网络集群中

要将不同的操作器部署到不同的命名空间，请使用此流程。对于具有网络连接的 MicroShift 集群，Operator Lifecycle Manager (OLM)可以访问托管在远程 registry 上的源。以下流程列出了使用配置文件安装使用全局命名空间的 Operator 的基本步骤。

注意

要使用安装在其他命名空间中或多个命名空间中的 Operator，请确保目录源和引用 Operator 的 Subscription CR 在 openshift-marketplace 命名空间中运行。

先决条件

  • 已安装 OpenShift CLI (oc)。
  • 已安装 Operator Lifecycle Manager (OLM)。
  • 您已在全局命名空间中创建了自定义目录。

流程

  1. 使用以下命令确认 OLM 正在运行： 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=olm-operator
    Copy to Clipboard

    输出示例

    NAME                            READY   STATUS    RESTARTS   AGE
olm-operator-85b5c6786-n6kbc    1/1     Running   0          2m24s
    Copy to Clipboard

  2. 使用以下命令确认 OLM 目录 Operator 正在运行： 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=catalog-operator
    Copy to Clipboard

    输出示例

    NAME                                READY   STATUS    RESTARTS   AGE
catalog-operator-5fc7f857b6-tj8cf   1/1     Running   0          2m33s
    Copy to Clipboard

注意

以下步骤假设您使用全局命名空间 openshift-marketplace。目录必须与 Operator 在相同的命名空间中运行。Operator 必须支持 AllNamespaces 模式。

  1. 使用以下示例 YAML 创建 CatalogSource 对象：

    目录源 YAML 示例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest
  displayName: Community Operators
    2 
    
  publisher: OperatorHub.io
  grpcPodConfig:
    securityContextConfig: restricted
    3 
    
  updateStrategy:
    registryPoll:
      interval: 60m
    Copy to Clipboard

    1
    全局命名空间。将 metadata.namespace 设置为 openshift-marketplace 可让目录在所有命名空间中运行。任何命名空间中的订阅可以引用在 openshift-marketplace 命名空间中创建的目录。
    2
    对于 MicroShift，默认情况下不使用 OLM 安装社区 Operator。此处仅列于此处的示例。
    3
    securityContextConfig 的值必须设置为 restricted 用于 MicroShift。

  2. 运行以下命令来应用 CatalogSource 配置： 

    $ oc apply -f <catalog_source.yaml>
    1
    Copy to Clipboard
    1
    将 <catalog-source.yaml > 替换为您的目录源配置文件名称。在本例中，使用 catalogsource.yaml。

    输出示例

    catalogsource.operators.coreos.com/operatorhubio-catalog created
    Copy to Clipboard

  3. 要验证是否应用了目录源，请使用以下命令检查 READY 状态： 

    $ oc describe catalogsources.operators.coreos.com -n openshift-marketplace operatorhubio-catalog
    Copy to Clipboard

    输出示例

    Name:         operatorhubio-catalog
Namespace:    openshift-marketplace
Labels:       <none>
Annotations:  <none>
API Version:  operators.coreos.com/v1alpha1
Kind:         CatalogSource
Metadata:
  Creation Timestamp:  2024-01-31T09:55:31Z
  Generation:          1
  Resource Version:    1212
  UID:                 4edc1a96-83cd-4de9-ac8c-c269ca895f3e
Spec:
  Display Name:  Community Operators
  Grpc Pod Config:
    Security Context Config:  restricted
  Image:                      quay.io/operatorhubio/catalog:latest
  Publisher:                  OperatorHub.io
  Source Type:                grpc
  Update Strategy:
    Registry Poll:
      Interval:  60m
Status:
  Connection State:
    Address:              operatorhubio-catalog.openshift-marketplace.svc:50051
    Last Connect:         2024-01-31T09:55:57Z
    Last Observed State:  READY
    1 
    
  Registry Service:
    Created At:         2024-01-31T09:55:31Z
    Port:               50051
    Protocol:           grpc
    Service Name:       operatorhubio-catalog
    Service Namespace:  openshift-marketplace
Events:                 <none>
    Copy to Clipboard

    1
    状态报告为 READY。

  4. 使用以下命令确认目录源正在运行： 

    $ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog
    Copy to Clipboard

    输出示例

    NAME                          READY   STATUS    RESTARTS   AGE
operatorhubio-catalog-x24nh   1/1     Running   0          59s
    Copy to Clipboard

  5. 使用以下示例 YAML 创建 Subscription CR 配置文件：

    Subscription 自定义资源 YAML 示例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-cert-manager
  namespace: openshift-operators
spec:
  channel: stable
  name: cert-manager
  source: operatorhubio-catalog
  sourceNamespace: openshift-marketplace
    1
    Copy to Clipboard

    1
    全局命名空间。将 sourceNamespace 值设置为 openshift-marketplace 可让 Operator 在 openshift-marketplace 命名空间中运行。

  6. 运行以下命令来应用 Subscription CR 配置： 

    $ oc apply -f <subscription_cr.yaml>
    1
    Copy to Clipboard
    1
    将 <subscription_cr.yaml& gt; 替换为您的 Subscription CR 文件名。

    输出示例

    subscription.operators.coreos.com/my-cert-manager created
    Copy to Clipboard

  7. 您可以为您要使用的特定 Operand 创建配置文件，并立即应用它。

验证

  1. 使用以下命令验证您的 Operator 是否正在运行： 

    $ oc get pods -n openshift-operators
    1
    Copy to Clipboard
    1
    使用 Subscription CR 中的命名空间。
    注意

    Operator 启动需要一分钟或两分钟。

    输出示例

    NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-7df8994ddb-4vrkr              1/1     Running   0          19s
cert-manager-cainjector-5746db8fd7-69442   1/1     Running   0          18s
cert-manager-webhook-f858bf58b-748nt       1/1     Running   0          18s
    Copy to Clipboard

10.2.5.3. 将基于 OLM 的 Operator 添加到特定命名空间中的网络集群中

如果要为 Operator 指定命名空间，如 olm-microshift，请使用这个步骤。在本例中，目录范围在全局 openshift-marketplace 命名空间中。Operator 使用全局命名空间中的内容，但仅在 olm-microshift 命名空间中运行。对于具有网络连接的 MicroShift 集群，Operator Lifecycle Manager (OLM)可以访问托管在远程 registry 上的源。

重要

特定命名空间中安装的所有 Operator 必须具有相同的监视范围。在这种情况下，watch 范围为 OwnNamespace。

先决条件

  • 已安装 OpenShift CLI (oc)。
  • 已安装 Operator Lifecycle Manager (OLM)。
  • 您已创建了在全局命名空间中运行的自定义目录。

流程

  1. 使用以下命令确认 OLM 正在运行： 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=olm-operator
    Copy to Clipboard

    输出示例

    NAME                           READY   STATUS    RESTARTS   AGE
olm-operator-85b5c6786-n6kbc   1/1     Running   0          16m
    Copy to Clipboard

  2. 使用以下命令确认 OLM 目录 Operator 正在运行： 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=catalog-operator
    Copy to Clipboard

    输出示例

    NAME                                READY   STATUS    RESTARTS   AGE
catalog-operator-5fc7f857b6-tj8cf   1/1     Running   0          16m
    Copy to Clipboard

  3. 使用以下示例 YAML 创建命名空间：

    命名空间 YAML 示例

    apiVersion: v1
kind: Namespace
metadata:
  name: olm-microshift
    Copy to Clipboard

  4. 使用以下命令应用命名空间配置： 

    $ oc apply -f <ns.yaml>
    1
    Copy to Clipboard
    1
    将 <ns.yaml > 替换为命名空间配置文件的名称。本例中使用了 olm-microshift。

    输出示例

    namespace/olm-microshift created
    Copy to Clipboard

  5. 使用以下示例 YAML 创建 Operator 组 YAML：

    Operator 组 YAML 示例

    kind: OperatorGroup
apiVersion: operators.coreos.com/v1
metadata:
  name: og
  namespace: olm-microshift
spec:
    1 
    
  targetNamespaces:
  - olm-microshift
    Copy to Clipboard

    1
    对于使用全局命名空间的 Operator，请省略 spec.targetNamespaces 字段和值。

  6. 运行以下命令来应用 Operator 组配置： 

    $ oc apply -f <og.yaml>
    1
    Copy to Clipboard
    1
    将 <og.yaml > 替换为 operator 组配置文件的名称。

    输出示例

    operatorgroup.operators.coreos.com/og created
    Copy to Clipboard

  7. 使用以下示例 YAML 创建 CatalogSource 对象：

    目录源 YAML 示例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest
  displayName: Community Operators
    2 
    
  publisher: OperatorHub.io
  grpcPodConfig:
    securityContextConfig: restricted
    3 
    
  updateStrategy:
    registryPoll:
      interval: 60m
    Copy to Clipboard

    1
    全局命名空间。将 metadata.namespace 设置为 openshift-marketplace 可让目录在所有命名空间中运行。任何命名空间中的订阅 CR 可以引用在 openshift-marketplace 命名空间中创建的目录。
    2
    对于 MicroShift，默认情况下不使用 OLM 安装社区 Operator。此处仅列于此处的示例。
    3
    securityContextConfig 的值必须设置为 restricted 用于 MicroShift。

  8. 运行以下命令来应用 CatalogSource 配置： 

    $ oc apply -f <catalog_source.yaml>
    1
    Copy to Clipboard
    1
    将 <catalog_source.yaml > 替换为您的目录源配置文件名称。

  9. 要验证是否应用了目录源，请使用以下命令检查 READY 状态： 

    $ oc describe catalogsources.operators.coreos.com -n openshift-marketplace operatorhubio-catalog
    Copy to Clipboard

    输出示例

    Name:         operatorhubio-catalog
Namespace:    openshift-marketplace
Labels:       <none>
Annotations:  <none>
API Version:  operators.coreos.com/v1alpha1
Kind:         CatalogSource
Metadata:
  Creation Timestamp:  2024-01-31T10:09:46Z
  Generation:          1
  Resource Version:    2811
  UID:                 60ce4a36-86d3-4921-b9fc-84d67c28df48
Spec:
  Display Name:  Community Operators
  Grpc Pod Config:
    Security Context Config:  restricted
  Image:                      quay.io/operatorhubio/catalog:latest
  Publisher:                  OperatorHub.io
  Source Type:                grpc
  Update Strategy:
    Registry Poll:
      Interval:  60m
Status:
  Connection State:
    Address:              operatorhubio-catalog.openshift-marketplace.svc:50051
    Last Connect:         2024-01-31T10:10:04Z
    Last Observed State:  READY
    1 
    
  Registry Service:
    Created At:         2024-01-31T10:09:46Z
    Port:               50051
    Protocol:           grpc
    Service Name:       operatorhubio-catalog
    Service Namespace:  openshift-marketplace
Events:                 <none>
    Copy to Clipboard

    1
    状态报告为 READY。

  10. 使用以下命令确认目录源正在运行： 

    $ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog
    Copy to Clipboard

    输出示例

    NAME                          READY   STATUS    RESTARTS   AGE
operatorhubio-catalog-j7sc8   1/1     Running   0          43s
    Copy to Clipboard

  11. 使用以下示例 YAML 创建 Subscription CR 配置文件：

    Subscription 自定义资源 YAML 示例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-gitlab-operator-kubernetes
  namespace: olm-microshift
    1 
    
spec:
  channel: stable
  name: gitlab-operator-kubernetes
  source: operatorhubio-catalog
  sourceNamespace: openshift-marketplace
    2
    Copy to Clipboard

    1
    特定命名空间。Operator 引用内容的全局命名空间，但在 olm-microshift 命名空间中运行。
    2
    全局命名空间。任何命名空间中的订阅 CR 可以引用在 openshift-marketplace 命名空间中创建的目录。

  12. 运行以下命令来应用 Subscription CR 配置： 

    $ oc apply -f <subscription_cr.yaml>
    1
    Copy to Clipboard
    1
    将 <subscription_cr.yaml > 替换为 Subscription CR 配置文件的名称。

    输出示例

    subscription.operators.coreos.com/my-gitlab-operator-kubernetes
    Copy to Clipboard

  13. 您可以为您要使用的特定 Operand 创建配置文件，并立即应用它。

验证

  1. 使用以下命令验证您的 Operator 是否正在运行： 

    $ oc get pods -n olm-microshift
    1
    Copy to Clipboard
    1
    使用 Subscription CR 中的命名空间。
    注意

    Operator 启动需要一分钟或两分钟。

    输出示例

    NAME                                         READY   STATUS    RESTARTS   AGE
gitlab-controller-manager-69bb6df7d6-g7ntx   2/2     Running   0          3m24s
    Copy to Clipboard

10.3. 使用 oc-mirror 插件创建自定义目录

您可以使用广泛可用的 Operator 创建自定义目录，并使用 oc-mirror OpenShift CLI (oc)插件镜像它们。

10.3.1. 使用红帽提供的 Operator 目录和镜像 registry

您可以过滤和修剪目录以获取特定的 Operator，并使用 oc-mirror OpenShift CLI (oc)插件镜像它们。您还可以在断开连接的设置中使用 Operator，或嵌入在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中。要了解更多有关如何配置系统以进行镜像的详细信息，请使用以下"添加资源"部分中的链接。如果您准备好从红帽提供的 Operator 目录部署 Operator，请镜像它们，或将其嵌入到 RHEL for Edge 镜像中，请从以下部分开始，使用 oc-mirror 插件"Inspecting catalog contents"。

10.3.2. 关于用于创建镜像 registry 的 oc-mirror 插件

您可以在 MicroShift 中使用 oc-mirror OpenShift CLI (oc)插件来过滤和修剪 Operator 目录。然后，您可以将过滤的目录内容镜像到镜像 registry，或者在 RHEL for Edge 断开连接或离线部署中使用容器镜像。

注意

MicroShift 使用 oc-mirror 插件的通用版本(1)。不要在 oc-mirror 插件的技术预览版本(2)中使用以下步骤。

您可以在本地将所需 Operator 所需的容器镜像或支持 Docker v2-2 （如 Red Hat Quay）的容器镜像 registry。将内容从连接到互联网的红帽托管的 registry 中镜像到断开连接的镜像 registry 的步骤是相同的，而与您选择的 registry 无关。镜像目录内容后，将每个集群配置为从镜像 registry 中检索此内容。

10.3.2.1. 填充镜像 registry 时的连接注意事项

在填充 registry 时，您可以使用以下连接场景之一：

连接的镜像
如果您有一个可以同时访问互联网和您的镜像 registry （而不是您的集群节点）的主机，您可以直接从该机器中镜像内容。
断开连接的镜像

如果您没有可以同时访问互联网和您的镜像 registry 的主机，则必须将镜像镜像到文件系统，然后将该主机或可移动介质放入断开连接的环境中。

重要

您置备的集群中的每个机器都必须可以访问容器 registry。如果 registry 无法访问，安装、更新和其他操作（如重新定位工作负载）可能会失败。

要避免由无法访问的 registry 导致的问题，请使用以下标准实践：

  • 以高可用性方式运行镜像 registry。
  • 确保镜像 registry 至少与集群的生产环境可用性匹配。
10.3.2.2. 使用 oc-mirror 插件检查目录内容

使用以下示例步骤从可用的 OpenShift Container Platform 内容中选择目录并列出 Operator，以添加到 oc-mirror 插件镜像设置配置文件中。

注意

如果使用自己的目录和 Operator，您可以直接将镜像推送到内部 registry。

先决条件

  • 已安装 OpenShift CLI (oc)。
  • 已安装 Operator Lifecycle Manager (OLM)。
  • 已安装 oc-mirror OpenShift CLI (oc)插件。

流程

  1. 运行以下命令，获取红帽提供的 Operator 目录列表以过滤： 

    $ oc mirror list operators --version 4.19 --catalogs
    Copy to Clipboard

  2. 运行以下命令，获取 Red Hat Operator 目录中的 Operator 列表： 

    $ oc mirror list operators <--catalog=<catalog_source>>
    1
    Copy to Clipboard
    1
    指定目录源，如 registry.redhat.io/redhat/redhat-operator-index:v4.19 或 quay.io/operatorhubio/catalog:latest。
  3. 选择一个 Operator。在本例中，选择 amq-broker-rhel8。

  4. 可选： 要检查您要过滤的 Operator 的频道和版本，请输入以下命令：

    1. 运行以下命令获取频道列表： 

      $ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.17 --package=amq-broker-rhel8
      Copy to Clipboard

    2. 运行以下命令，获取频道中的版本列表： 

      $ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.17 --package=amq-broker-rhel8 --channel=7.11.x
      Copy to Clipboard

后续步骤

  • 使用此流程中收集的信息创建和编辑镜像设置配置文件。
  • 将镜像从转换的镜像设置配置文件镜像到镜像 registry 或磁盘。
10.3.2.3. 创建镜像设置配置文件

您必须创建一个镜像设置配置文件，以使用 oc-mirror 插件镜像目录内容。镜像设置配置文件定义要镜像哪些 Operator 以及 oc-mirror 插件的其他配置设置。生成默认镜像集文件后，您必须编辑内容，以便剩余的条目与 MicroShift 和您计划使用的 Operator 兼容。

您必须在镜像设置配置文件中指定存储后端。此存储后端可以是本地目录或支持 Docker v2-2 的 registry。oc-mirror 插件在创建镜像的过程中将元数据存储在这个存储后端中。

重要

不要删除或修改 oc-mirror 插件生成的元数据。每次针对同一镜像 registry 运行 oc-mirror 插件时，都必须使用相同的存储后端。

先决条件

流程

  1. 使用 oc mirror init 命令为镜像设置配置创建模板，并将其保存到名为 imageset-config.yaml 的文件中： 

    $ oc mirror init --registry <storage_backend> > imageset-config.yaml
    1
    Copy to Clipboard
    1
    指定存储后端的位置，如 example.com/mirror/oc-mirror-metadata。

    默认镜像设置配置文件示例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: registry.example.com/oc-mirror
    skipTLS: false
mirror:
  platform:
    1 
    
    channels:
    - name: stable-4.19
      type: ocp
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
    packages:
    - name: serverless-operator
      channels:
      - name: stable
  additionalImages:
    2 
    
  - name: registry.redhat.io/ubi8/ubi:latest
  helm: {}
    3
    Copy to Clipboard

    1
    MicroShift 不支持 platform 字段和相关字段，必须被删除。
    2
    指定要在镜像集中包含的任何其他镜像。如果您不需要指定其他镜像，请删除此字段。
    3
    MicroShift 不支持 Helm，必须被删除。

  2. 编辑镜像设置配置文件的值，以满足 MicroShift 和您要镜像的 Operator 的要求，如下例所示：

    编辑的 MicroShift 镜像设置配置文件示例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
    1 
    
  registry:
    imageURL: <storage_backend>
    2 
    
    skipTLS: false
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
    3 
    
    packages:
    - name: amq-broker-rhel8
    4 
    
      channels:
      - name: 7.11.x
    5
    Copy to Clipboard

    1
    设置保存镜像设置元数据的后端位置。此位置可以是 registry 或本地目录。必须指定 storageConfig 值。
    2
    设置存储后端的 registry URL，如 <example.com/mirror/oc-mirror-metadata。
    3
    将 Operator 目录设置为从中检索镜像。
    4
    指定要包含在镜像集中的 Operator 软件包。删除此字段以检索目录中的所有软件包。
    5
    仅指定要包含在镜像集中的 Operator 软件包的某些频道。即使您没有使用该频道中的捆绑包，还必须始终包含 Operator 软件包的默认频道。您可以运行以下命令来找到默认频道：oc mirror list operators --catalog=<catalog_name> --package=<package_name>。
  3. 保存更新的文件。

后续步骤

  • 使用 oc-mirror 插件将镜像直接设置为目标镜像 registry。
  • 配置 CRI-O。
  • 将目录源应用到集群。
10.3.2.3.1. 镜像设置配置参数

oc-mirror 插件需要一个镜像设置配置文件，该文件定义哪些镜像要镜像(mirror)。下表列出了 ImageSetConfiguration 资源的可用参数。

表 10.2. ImageSetConfiguration 参数
参数描述值

apiVersion

ImageSetConfiguration 内容的 API 版本。

字符串.例如： mirror.openshift.io/v1alpha2。

mirror

镜像集的配置。

对象

mirror.additionalImages

镜像集的额外镜像配置。

对象数组。例如： 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest
Copy to Clipboard

mirror.additionalImages.name

要 mirror 的镜像的标签或摘要。

字符串.例如： registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

阻止 mirror 的镜像的完整标签、摘要或模式。

字符串数组。例如： docker.io/library/alpine

mirror.operators

镜像集的 Operator 配置。

对象数组。例如： 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'
Copy to Clipboard

mirror.operators.catalog

包括在镜像集中的 Operator 目录。

字符串.例如： registry.redhat.io/redhat/redhat-operator-index:v4.19。

mirror.operators.full

为 true 时，下载完整的目录、Operator 软件包或 Operator 频道。

布尔值.默认值为 false。

mirror.operators.packages

Operator 软件包配置。

对象数组。例如： 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'
Copy to Clipboard

mirror.operators.packages.name

镜像集中要包含的 Operator 软件包名称

字符串.例如： elasticsearch-operator。

mirror.operators.packages.channels

Operator 软件包频道配置。

对象

mirror.operators.packages.channels.name

Operator 频道名称（软件包中唯一）要包括在镜像集中。

字符串.例如： fast 或 stable-v4.19。

mirror.operators.packages.channels.maxVersion

Operator 镜像的最高版本，在其中存在所有频道。详情请查看以下备注。

字符串.例如： 5.2.3-31

mirror.operators.packages.channels.minBundle

要包含的最小捆绑包的名称，以及频道头更新图中的所有捆绑包。仅在命名捆绑包没有语义版本元数据时设置此字段。

字符串.例如： bundleName

mirror.operators.packages.channels.minVersion

Operator 的最低版本，用于镜像存在的所有频道。详情请查看以下备注。

字符串.例如： 5.2.3-31

mirror.operators.packages.maxVersion

Operator 最高版本，可跨所有存在的频道进行镜像。详情请查看以下备注。

字符串.例如： 5.2.3-31。

mirror.operators.packages.minVersion

Operator 的最低版本，用于镜像存在的所有频道。详情请查看以下备注。

字符串.例如： 5.2.3-31。

mirror.operators.skipDependencies

如果为 true，则不会包含捆绑包的依赖项。

布尔值.默认值为 false。

mirror.operators.targetCatalog

要镜像引用的目录的替代名称和可选命名空间层次结构。

字符串.例如：my-namespace/my-operator-catalog

mirror.operators.targetName

将引用的目录镜像为。

targetName 参数已弃用。改为使用 targetCatalog 参数。

字符串.例如： my-operator-catalog

mirror.operators.targetTag

附加到 targetName 或 targetCatalog 的替代标签。

字符串.例如： v1

storageConfig

镜像集的后端配置。

对象

storageConfig.local

镜像集的本地后端配置。

对象

storageConfig.local.path

包含镜像设置元数据的目录路径。

字符串.例如： ./path/to/dir/。

storageConfig.registry

镜像集的 registry 后端配置。

对象

storageConfig.registry.imageURL

后端 registry URI。可以选择在 URI 中包含命名空间引用。

字符串.例如： quay.io/myuser/imageset:metadata。

storageConfig.registry.skipTLS

（可选）跳过引用的后端 registry 的 TLS 验证。

布尔值.默认值为 false。

注意

使用 minVersion 和 maxVersion 属性过滤特定 Operator 版本范围可能会导致多个频道头错误。错误信息将显示有多个频道头。这是因为在应用过滤器时，Operator 的更新图会被截断。

Operator Lifecycle Manager 要求每个 operator 频道都包含一个端点组成更新图表的版本，即 Operator 的最新版本。在应用图形的过滤器范围时，可以进入两个或多个独立图形或具有多个端点的图形。

要避免这个错误，请不要过滤 Operator 的最新版本。如果您仍然遇到错误，具体取决于 Operator，则必须增加 maxVersion 属性，或者 minVersion 属性必须减少。因为每个 Operator 图都可以不同，所以您可能需要调整这些值，直到错误解决为止。

10.3.2.4. 镜像(mirror)到镜像(mirror)的镜像

您可以使用 oc-mirror 插件将镜像直接设置为在镜像设置过程中可访问的目标镜像 registry。

您必须在镜像设置配置文件中指定存储后端。这个存储后端可以是本地目录或 Docker v2 registry。oc-mirror 插件在创建镜像的过程中将元数据存储在这个存储后端中。

重要

不要删除或修改 oc-mirror 插件生成的元数据。每次针对同一镜像 registry 运行 oc-mirror 插件时，都必须使用相同的存储后端。

先决条件

  • 您可以访问互联网来获取所需的容器镜像。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 oc-mirror CLI 插件。
  • 您已创建了镜像设置配置文件。

流程

  • 运行 oc mirror 命令将指定镜像集配置中的镜像镜像到指定的 registry: 

    $ oc mirror --config=./<imageset-config.yaml> \
    1 
    
  docker://registry.example:5000
    2
    Copy to Clipboard
    1
    指定您创建的镜像设置配置文件。例如，imageset-config.yaml。
    2
    指定要镜像设置文件的 registry。registry 必须以 docker:// 开头。如果为镜像 registry 指定顶层命名空间，则必须在后续执行时使用此命名空间。

输出示例

Rendering catalog image "registry.example.com/redhat/redhat-operator-index:v{ocp-version}" with file-based catalog
Copy to Clipboard

验证

  1. 进入生成的 oc-mirror-workspace/ 目录。
  2. 导航到结果目录，例如，results-1639608409/。
  3. 验证 ImageContentSourcePolicy 和 CatalogSource 资源是否存在 YAML 文件。
重要

ImageContentSourcePolicy YAML 文件用作 MicroShift 中手动配置 CRI-O 的参考内容。您不能将资源直接应用到 MicroShift 集群中。

后续步骤

  • 转换 ImageContentSourcePolicy YAML 内容，以用于手动配置 CRI-O。
  • 如果需要，将镜像从 mirror 镜像到磁盘，以进行断开连接或离线使用。
  • 配置集群以使用 oc-mirror 生成的资源。

故障排除

10.3.2.5. 配置 CRI-O，为 Operator 使用 registry 镜像

您必须使用 oc-mirror 插件创建的 imageContentSourcePolicy.yaml 文件转换为与 MicroShift 使用的 CRI-O 容器运行时配置兼容的格式。

先决条件

  • 已安装 OpenShift CLI (oc)。
  • 已安装 Operator Lifecycle Manager (OLM)。
  • 已安装 oc-mirror OpenShift CLI (oc)插件。
  • 已安装 yq 二进制文件。
  • ImageContentSourcePolicy 和 CatalogSource YAML 文件位于 oc-mirror-workspace/results github 目录中。

流程

  1. 运行以下命令确认 imageContentSourcePolicy.yaml 文件的内容： 

    $ cat oc-mirror-workspace/<results-directory>/imageContentSourcePolicy.yaml
    1
    Copy to Clipboard
    1
    指定 结果 目录名称，如 < results-1707148826>。

    输出示例

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  labels:
    operators.openshift.org/catalog: "true"
  name: operator-0
spec:
  repositoryDigestMirrors:
  - mirrors:
    - registry.<example.com>/amq7
    source: registry.redhat.io/amq7
    Copy to Clipboard

  2. 运行以下命令，将 imageContentSourcePolicy.yaml 转换为可用于 CRI-O 配置的格式： 

    yq '.spec.repositoryDigestMirrors[] as $item ireduce([]; . + [{"mirror": $item.mirrors[], "source": ($item | .source)}]) | .[] |
  "[[registry]]
      prefix = \"" + .source + "\"
      location = \"" + .mirror + "\"
      mirror-by-digest-only = true
      insecure = true
      "' ./icsp.yaml
    Copy to Clipboard

    输出示例

    [[registry]]
      prefix = "registry.redhat.io/amq7"
      location = "registry.example.com/amq7"
      mirror-by-digest-only = true
      insecure = true
    Copy to Clipboard

  3. 将输出添加到 /etc/containers/registries.conf.d/ 目录中的 CRI-O 配置文件中：

    crio-config.yaml 镜像配置文件示例

    [[registry]]
      prefix = "registry.redhat.io/amq7"
      location = "registry.example.com/amq7"
      mirror-by-digest-only = true
      insecure = true

[[registry]]
    prefix = ""
    location = "quay.io"
    mirror-by-digest-only = true
[[registry.mirror]]
    location = "<registry_host>:<port>"
    1 
    
    insecure = false
    Copy to Clipboard

    1
    指定镜像 registry 服务器的主机名和端口，如 microshift-quay:8443。

  4. 使用以下命令重启 MicroShift 来应用 CRI-O 配置更改： 

    $ sudo systemctl restart crio
    Copy to Clipboard
10.3.2.6. 安装使用 oc-mirror 插件创建的自定义目录

将镜像设置为镜像 registry 后，您必须将生成的 CatalogSource 自定义资源(CR)应用到集群。Operator Lifecycle Manager (OLM)使用 CatalogSource CR 来检索有关镜像 registry 中可用 Operator 的信息。然后，您必须创建并应用订阅 CR 来订阅您的自定义目录。

先决条件

  • 您已将镜像设置为 registry 镜像。
  • 您可以将镜像引用信息添加到 CRI-O 容器运行时配置中。

流程

  1. 运行以下命令，应用来自结果目录中的目录源配置文件来创建目录源对象： 

    $ oc apply -f ./oc-mirror-workspace/results-1708508014/catalogSource-cs-redhat-operator-index.yaml
    Copy to Clipboard

    目录源配置文件示例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: redhat-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: registry.example.com/redhat/redhat-operator-index:v4.17
  updateStrategy:
    registryPoll:
      interval: 60m
    Copy to Clipboard

    1
    指定全局命名空间。将 metadata.namespace 设置为 openshift-marketplace 可让目录引用所有命名空间中的目录。任何命名空间中的订阅可以引用在 openshift-marketplace 命名空间中创建的目录。

    输出示例

    catalogsource.operators.coreos.com/cs-redhat-operator-index created
    Copy to Clipboard

  2. 运行以下命令验证 CatalogSource 资源是否已成功安装： 

    $ oc get catalogsource --all-namespaces
    Copy to Clipboard

  3. 使用以下命令验证目录源是否正在运行： 

    $ oc get pods -n openshift-marketplace
    Copy to Clipboard

    输出示例

    NAME                             READY   STATUS    RESTARTS   AGE
cs-redhat-operator-index-4227b   2/2     Running   0          2m5s
    Copy to Clipboard

  4. 创建一个 Subscription CR，类似以下示例：

    Subscription CR 示例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: amq-broker
  namespace: openshift-operators
spec:
  channel: 7.11.x
  name: amq-broker-rhel8
  source: cs-redhat-operator-index
  sourceNamespace: openshift-marketplace
    Copy to Clipboard

  5. 运行以下命令来应用 Subscription CR 配置： 

    $ oc apply -f ./<my-subscription-cr.yaml>
    1
    Copy to Clipboard
    1
    指定订阅的名称，如 my-subscription-cr.yaml。

    输出示例

    subscription.operators.coreos.com/amq-broker created
    Copy to Clipboard

10.4. 将基于 OLM 的 Operator 添加到断开连接的集群中

您可以通过将基于 OLM 的 Operator 嵌入到 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中，在断开连接的环境中使用基于 OLM 的 Operator。

10.4.1. 关于将基于 OLM 的 Operator 添加到断开连接的集群中

对于在断开连接的集群中安装的 Operator，Operator Lifecycle Manager (OLM)默认无法访问远程 registry 上托管的源，因为这些远程源需要足够的互联网连接。因此，您必须将远程 registry 镜像到高度可用的容器 registry。

在断开连接的环境中，需要执行以下步骤来使用基于 OLM 的 Operator：

  • 将 OLM 包含在您的镜像 registry 的容器镜像列表中。
  • 通过直接更新 CRI-O 配置将系统配置为使用您的镜像 registry。MicroShift 不支持 ImageContentSourcePolicy。
  • 在集群中添加 CatalogSource 对象，以便 OLM 目录 Operator 可以使用镜像 registry 上的本地目录。
  • 确保 MicroShift 已安装在断开连接的容量中运行。
  • 确保网络设置配置为在断开连接的模式下运行。

在断开连接的集群中启用 OLM 后，您可以继续使用互联网连接的工作站在发布较新版本的 Operator 时保持本地目录源更新。

10.4.1.1. 执行空运行

您可以使用 oc-mirror 来执行空运行，而无需实际镜像(mirror)。这可让您查看要镜像的镜像列表，以及从镜像 registry 修剪的所有镜像。使用空运行（dry run）还允许您在早期版本中捕获与镜像集配置相关的任何错误，或使用生成的镜像列表以及其他工具来执行镜像操作。

先决条件

  • 您可以访问互联网来获取所需的容器镜像。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 oc-mirror CLI 插件。
  • 您已创建了镜像设置配置文件。

流程

  1. 使用 --dry-run 标志运行 oc mirror 命令来执行空运行： 

    $ oc mirror --config=./imageset-config.yaml \
    1 
    
  docker://registry.example:5000            \
    2 
    
  --dry-run
    3
    Copy to Clipboard
    1
    传递创建的镜像设置配置文件。此流程假设它名为 imageset-config.yaml。
    2
    指定镜像 registry。在使用 --dry-run 标志时，不会镜像这个 registry。
    3
    使用 --dry-run 标志来生成空运行工件，而不是实际的镜像设置文件。

    输出示例

    Checking push permissions for registry.example:5000
Creating directory: oc-mirror-workspace/src/publish
Creating directory: oc-mirror-workspace/src/v2
Creating directory: oc-mirror-workspace/src/charts
Creating directory: oc-mirror-workspace/src/release-signatures
No metadata detected, creating new workspace
wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index

...

info: Planning completed in 31.48s
info: Dry run complete
Writing image mapping to oc-mirror-workspace/mapping.txt
    Copy to Clipboard

  2. 进入生成的工作区目录： 

    $ cd oc-mirror-workspace/
    Copy to Clipboard

  3. 查看生成的 mapping.txt 文件。

    此文件包含将要镜像的所有镜像的列表。

  4. 查看生成的 prune-plan.json 文件。

    此文件包含在发布镜像集时从镜像 registry 中修剪的所有镜像的列表。

    注意

    只有在 oc-mirror 命令指向您的镜像 registry 且需要修剪的镜像时，才会生成 prune-plan.json 文件。

10.4.1.2. 获取在断开连接的环境中用于 RHEL for Edge 的目录和 Operator 容器镜像引用

在使用 oc-mirror 插件执行空运行后，以查看您要镜像的镜像列表，您必须获取所有容器镜像引用，然后格式化要添加到镜像构建器蓝图的输出。

注意

对于为专有 Operator 创建的目录，您可以在不按照以下流程的情况下格式化镜像构建器蓝图的镜像引用。

先决条件

  • 您有一个要使用的 Operator 的目录索引。
  • 已安装 jq CLI 工具。
  • 熟悉镜像构建器蓝图文件。
  • 您有一个 Image Builder 蓝图 TOML 文件。

流程

  1. 解析目录 index.json 文件，以获取 Image Builder 蓝图中包含的镜像引用。您可以使用未过滤的目录，也可以过滤掉无法镜像的镜像：

    1. 运行以下命令，解析未过滤的目录 index.json 文件以获取镜像引用： 

      jq -r --slurp '.[] | select(.relatedImages != null) | "[[containers]]\nsource = \"" + .relatedImages[].image + "\"\n"'   ./oc-mirror-workspace/src/catalogs/registry.redhat.io/redhat/redhat-operator-index/v4.17/index/index.json
      Copy to Clipboard

    2. 如果要过滤无法镜像的镜像，请运行以下命令来过滤并解析目录 index.json 文件： 

      $ jq -r --slurp '.[] | select(.relatedImages != null) | .relatedImages[] | select(.name |  contains("ppc") or contains("s390x") | not) | "[[containers]]\\nsource = \\"" + .image + "\\"\\n"' ./oc-mirror-workspace/src/catalogs/registry.redhat.io/redhat/redhat-operator-index/v4.17/index/index.json
      Copy to Clipboard
      注意

      此步骤使用 AMQ Broker Operator 作为示例。您可以在 jq 命令中添加其他条件，以便根据您的用例的要求进行进一步过滤。

      image-reference 输出示例

      [[containers]]
source = "registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:0b2126cfb6054fdf428c1f43b69e36e93a09a49ce15350e9273c98cc08c6598b"

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:0dde839c2dce7cb684094bf26523c8e16677de03149a0fff468b8c3f106e1f4f"
...
...

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-rhel8@sha256:e8fa2a00e576ecb95561ffbdbf87b1c82d479c8791ab2c6ce741dd0d0b496d15"

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-rhel8@sha256:ff6fefad518a6c997d4c5a6e475ba89640260167f0bc27715daf3cc30116fad1"
…
EOF
      Copy to Clipboard

      重要

      对于镜像和断开连接的用例，请确保从目录 index.json 文件过滤的所有源都是摘要。如果有任何源使用标签而不是摘要，Operator 安装会失败。标签需要互联网连接。

  2. 运行以下命令，查看 imageset-config.yaml 以获取 CatalogSource 自定义资源(CR)的目录镜像引用： 

    $ cat imageset-config.yaml
    Copy to Clipboard

    输出示例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: registry.example.com/microshift-mirror
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    1 
    
    packages:
    - name: amq-broker-rhel8
      channels:
      - name: 7.11.x
    Copy to Clipboard

    1
    使用 mirror.catalog 目录镜像引用中的值对 follwing jq 命令获取镜像摘要。在本例中，< registry.redhat.io/redhat/redhat-operator-index:v4.17 >。

  3. 运行以下命令，获取目录索引镜像的 SHA： 

    $ skopeo inspect docker://<registry.redhat.io/redhat/redhat-operator-index:v4.17> | jq `.Digest`
    1
    Copy to Clipboard
    1
    使用 jq 命令的 mirror.catalog 目录镜像引用中的值来获取镜像摘要。在本例中，< registry.redhat.io/redhat/redhat-operator-index:v4.17 >。

    输出示例

    "sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
    Copy to Clipboard

  4. 要准备好将镜像引用添加到 Image Builder 蓝图文件中，请使用以下示例格式化目录镜像引用： 

    [[containers]]
source = "registry.redhat.io/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
    Copy to Clipboard

  5. 将之前所有步骤中的镜像引用添加到镜像构建器蓝图中。

    生成的镜像构建器蓝图示例片断

    name = "microshift_blueprint"
description = "MicroShift 4.17.1 on x86_64 platform"
version = "0.0.1"
modules = []
groups = []

[[packages]]
    1 
    
name = "microshift"
version = "4.17.1"
...
...

[customizations.services]
    2 
    
enabled = ["microshift"]

[customizations.firewall]
ports = ["22:tcp", "80:tcp", "443:tcp", "5353:udp", "6443:tcp", "30000-32767:tcp", "30000-32767:udp"]
...
...

[[containers]]
    3 
    
source = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:f41e79c17e8b41f1b0a5a32c3e2dd7cd15b8274554d3f1ba12b2598a347475f4"

[[containers]]
source = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:dbc65f1fba7d92b36cf7514cd130fe83a9bd211005ddb23a8dc479e0eea645fd"
...
...

[[containers]]
    4 
    
source = "registry.redhat.io/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
...
...

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-init-rhel8@sha256:0dde839c2dce7cb684094bf26523c8e16677de03149a0fff468b8c3f106e1f4f"
...
...

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-rhel8@sha256:e8fa2a00e576ecb95561ffbdbf87b1c82d479c8791ab2c6ce741dd0d0b496d15"

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-rhel8@sha256:ff6fefad518a6c997d4c5a6e475ba89640260167f0bc27715daf3cc30116fad1"
…
EOF
    Copy to Clipboard

    1
    使用与 microshift-release-info RPM 兼容的同一版本，所有非可选 MicroShift RPM 软件包的引用。
    2
    有关在系统引导时自动启用 MicroShift 并应用默认网络设置的引用。
    3
    对断开连接的部署所需的所有非可选 MicroShift 容器镜像的引用。
    4
    目录索引的引用。
10.4.1.3. 在断开连接的部署 RHEL for Edge 镜像中应用目录和 Operator

为断开连接的环境创建 RHEL for Edge 镜像并配置了 MicroShift 网络设置以进行断开连接的使用后，您可以配置命名空间并创建目录和 Operator 自定义资源(CR)以运行 Operator。

先决条件

  • 您有一个 RHEL for Edge 镜像。
  • 联网配置为断开连接使用。
  • 您已完成了 oc-mirror 插件空运行过程。

流程

  1. 创建 CatalogSource 自定义资源(CR)，类似以下示例：

    my-catalog-source-cr.yaml 文件示例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: cs-redhat-operator-index
  namespace: openshift-marketplace
    1 
    
spec:
  image: registry.example.com/redhat/redhat-operator-index:v4.17
  sourceType: grpc
  displayName:
  publisher:
  updateStrategy:
    registryPoll:
      interval: 60m
    Copy to Clipboard

    1
    全局命名空间。将 metadata.namespace 设置为 openshift-marketplace 可让目录在所有命名空间中运行。任何命名空间中的订阅可以引用在 openshift-marketplace 命名空间中创建的目录。
    注意

    openshift-marketplace 的默认 pod 安全准入定义是 baseline，因此在该命名空间中创建的目录源自定义资源(CR)不需要设置 spec.grpcPodConfig.securityContextConfig 值。如果需要使用命名空间和 Operator，您可以设置 legacy 或 restricted 值。

  2. 将目录索引提交的 SHA 添加到 Catalog Source (CR)中，如下例所示：

    命名空间 spec.image 配置示例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: cs-redhat-operator-index
  namespace: openshift-marketplace
spec:
  image: registry.example.com/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6
    1 
    
  sourceType: grpc
  displayName:
  publisher:
  updateStrategy:
    registryPoll:
      interval: 60m
    Copy to Clipboard

    1
    镜像提交的 SHA。使用添加到镜像构建器蓝图中的同一 SHA。
    重要

    您必须在目录 CR 中使用 SHA 而不是标签，否则 pod 无法启动。

  3. 运行以下命令，将 oc-mirror 插件试运行结果目录中的 YAML 文件应用到集群： 

    $ oc apply -f ./oc-mirror-workspace/results-1708508014/catalogSource-cs-redhat-operator-index.yaml
    Copy to Clipboard

    输出示例

    catalogsource.operators.coreos.com/cs-redhat-operator-index created
    Copy to Clipboard

  4. 运行以下命令验证 CatalogSource 资源是否已成功安装： 

    $ oc get catalogsource --all-namespaces
    Copy to Clipboard

  5. 使用以下命令验证目录源是否正在运行： 

    $ oc get pods -n openshift-marketplace
    Copy to Clipboard

    输出示例

    NAME                             READY   STATUS    RESTARTS   AGE
cs-redhat-operator-index-4227b   2/2     Running   0          2m5s
    Copy to Clipboard

  6. 创建一个 Subscription CR，类似以下示例：

    my-subscription-cr.yaml 文件示例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: amq-broker
  namespace: openshift-operators
spec:
  channel: 7.11.x
  name: amq-broker-rhel8
  source: cs-redhat-operator-index
  sourceNamespace: openshift-marketplace
    Copy to Clipboard

  7. 运行以下命令来应用 Subscription CR： 

    $ oc apply -f ./<my-subscription-cr.yaml>
    1
    Copy to Clipboard
    1
    指定 Subscription CR 的名称，如 my-subscription-cr.yaml。

    输出示例

    subscription.operators.coreos.com/amq-broker created
    Copy to Clipboard

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat