运行应用程序


Red Hat build of MicroShift 4.13

在 MicroShift 中运行应用程序

Red Hat OpenShift Documentation Team

摘要

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

您可以使用 kustomize 配置管理工具来部署应用程序。阅读以下流程,以了解此工具在红帽构建的 MicroShift 中的工作方式。

1.1. 清单在 kustomize 中如何工作

kustomize 配置管理工具与红帽构建的 MicroShift 集成。在每次开始时,红帽构建的 MicroShift 会在 /etc/microshift/manifests/usr/lib/microshift/ 清单目录中搜索 kustomization.yaml 文件。如果找到了一个,红帽构建的 MicroShift 会自动运行与 kubectl apply -k 命令等效的命令,以将标识的清单应用到集群。

Expand
位置作用

/etc/microshift/manifests

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

/usr/lib/microshift/manifests

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

1.2. 使用清单示例

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

流程

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

    1. 定义目录位置:

      $ MANIFEST_DIR=/etc/microshift/manifests
      Copy to Clipboard Toggle word wrap
    2. 创建目录:

      $ sudo mkdir -p ${MANIFEST_DIR}
      Copy to Clipboard Toggle word wrap
    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-deployment
      spec:
        selector:
          matchLabels:
            app: busybox
        template:
          metadata:
            labels:
              app: busybox
          spec:
            containers:
            - name: busybox
              image: BUSYBOX_IMAGE
              command:
                - sleep
                - "3600"
      EOF
      Copy to Clipboard Toggle word wrap
  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: registry.k8s.io/busybox
      EOF
      Copy to Clipboard Toggle word wrap
  3. 运行以下命令重启 Red Hat build of MicroShift 以应用清单:

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令应用清单并启动 busybox pod:

    $ oc get pods -n busybox
    Copy to Clipboard Toggle word wrap

第 2 章 Operator 如何使用红帽构建的 MicroShift

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

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

红帽 MicroShift 应用程序的构建通常预期部署到静态环境中。但是,如果在您的用例中很有用,Operator 就会可用。要确定 Operator 与 Red Hat build of MicroShift 的兼容性,请查看 Operator 的文档。

2.1. 如何在红帽构建的 MicroShift 中安装 Operator

为尽量减少红帽构建的 MicroShift 占用空间,Operator 直接使用清单安装,而不使用 Operator Lifecycle Manager (OLM)。以下示例演示了如何在红帽构建的 MicroShift 中使用 kustomize 配置管理工具来部署应用程序。使用相同的步骤使用清单安装 Operator。

2.1.1. 清单在 kustomize 中如何工作

kustomize 配置管理工具与红帽构建的 MicroShift 集成。在每次开始时,红帽构建的 MicroShift 会在 /etc/microshift/manifests/usr/lib/microshift/ 清单目录中搜索 kustomization.yaml 文件。如果找到了一个,红帽构建的 MicroShift 会自动运行与 kubectl apply -k 命令等效的命令,以将标识的清单应用到集群。

Expand
位置作用

/etc/microshift/manifests

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

/usr/lib/microshift/manifests

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

2.1.2. 使用清单示例

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

流程

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

    1. 定义目录位置:

      $ MANIFEST_DIR=/etc/microshift/manifests
      Copy to Clipboard Toggle word wrap
    2. 创建目录:

      $ sudo mkdir -p ${MANIFEST_DIR}
      Copy to Clipboard Toggle word wrap
    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-deployment
      spec:
        selector:
          matchLabels:
            app: busybox
        template:
          metadata:
            labels:
              app: busybox
          spec:
            containers:
            - name: busybox
              image: BUSYBOX_IMAGE
              command:
                - sleep
                - "3600"
      EOF
      Copy to Clipboard Toggle word wrap
  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: registry.k8s.io/busybox
      EOF
      Copy to Clipboard Toggle word wrap
  3. 运行以下命令重启 Red Hat build of MicroShift 以应用清单:

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令应用清单并启动 busybox pod:

    $ oc get pods -n busybox
    Copy to Clipboard Toggle word wrap

第 3 章 Greenboot 工作负载健康检查脚本

Greenboot 健康检查脚本在边缘设备(这些设备的直接服务可用性可能会非常有限或不存在)上很有用。如果安装了 microshift-greenboot RPM 软件包,您也可以创建健康检查脚本来评估工作负载和应用程序的健康状态。这些额外的健康检查脚本是软件问题检查和自动系统回滚的有用组件。

红帽构建的 MicroShift 健康检查脚本包含在 microshift-greenboot RPM 中。您还可以根据您正在运行的工作负载创建自己的健康检查脚本。例如,您可以编写一个来验证服务是否已启动。

3.1. 工作负载健康检查脚本的工作方式

本教程中描述的工作负载或应用程序健康检查脚本使用 /usr/share/microshift/functions/greenboot.sh 文件中可用的 MicroShift 健康检查功能。这可让您重复使用已经为 MicroShift 核心服务实施的流程。

脚本首先运行检查工作负载的基本功能是否如预期运行。要成功运行脚本:

  • 从 root 用户帐户执行脚本。
  • 启用红帽构建的 MicroShift 服务。

健康检查执行以下操作:

  • 获取 wait_for 函数的当前引导周期的等待超时。
  • 调用 namespace_images_downloaded 功能,以等待 pod 镜像可用。
  • 调用 namespace_pods_ready 函数,以等待 pod 就绪。
  • 调用 namespace_pods_not_restarting 功能来验证 pod 是否没有重启。
注意

重启 pod 可以表示崩溃循环。

3.2. 包括 greenboot 健康检查

健康检查脚本在 /usr/lib/greenboot/check 中提供,这是 RPM-OSTree 系统的只读目录。以下健康检查包含在 greenboot-default-health-checks 框架中。

  • 检查存储库 URL 仍然是 DNS 解析:

    此脚本位于 /usr/lib/greenboot/check/required.d/01_repository_dns_check.sh 下,并确保对存储库 URL 的 DNS 查询仍然可用。

  • 检查更新平台是否仍然可访问:

    此脚本位于 /usr/lib/greenboot/check/wanted.d/01_update_platform_check.sh,并从 /etc/ostree/remotes.d 中定义的更新平台连接并获取 2XX 或 3XX HTTP 代码。

  • 检查硬件 watchdog 是否触发当前的引导:

    此脚本位于 /usr/lib/greenboot/check/required.d/02_watchdog.sh 下,并检查当前引导是否已是 watchdog-triggered。

    • 如果在宽限期内发生 watchdog-triggered 重启,则当前引导将标记为红色。Greenboot 不会触发对上一个部署的回滚。
    • 如果 watchdog-triggered 重启在宽限期后发生,则当前引导不会标记为红色。Greenboot 不会触发对上一个部署的回滚。
    • 默认启用 24 小时宽限期。可以通过以下方法禁用宽限(grace)期:修改 /etc/greenboot/greenboot.conf to false 中的 GREENBOOT_WATCHDOG_CHECK_ENABLED;或通过 /etc/greenboot/greenboot.conf 中的 GREENBOOT_WATCHDOG_GRACE_PERIOD=number_of_hours 变量值进行配置。

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

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

注意

如果 /etc/greenboot/check/required.d 目录退出,则 /etc/greenboot/check/required.d 目录中的所有脚本都会触发重启。

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

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

3.3.1. 关于工作负载健康检查脚本示例

以下示例使用 MicroShift 健康检查脚本的红帽构建作为模板。您可以将这个示例与提供的库一起使用,作为为应用程序创建基本健康检查脚本的指南。

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

您可以从以下示例健康检查脚本开始。根据您的用例进行修改。在工作负载健康检查脚本中,您必须完成以下最小步骤:

  • 设置环境变量。
  • 定义用户工作负载命名空间。
  • 列出预期的 pod 数量。
重要

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

工作负载健康检查脚本示例

# #!/bin/bash
set -e

SCRIPT_NAME=$(basename $0)
PODS_NS_LIST=(<user_workload_namespace1> <user_workload_namespace2>)
PODS_CT_LIST=(<user_workload_namespace1_pod_count> <user_workload_namespace2_pod_count>)
# Update these two lines with at least one namespace and the pod counts that are specific to your workloads. Use the kubernetes <namespace> where your workload is deployed.

# Set greenboot to read and execute the workload health check functions library.
source /usr/share/microshift/functions/greenboot.sh

# Set the exit handler to log the exit status.
trap 'script_exit' EXIT

# Set the script exit handler to log a `FAILURE` or `FINISHED` message depending on the exit status of the last command.
# args: None
# return: None
function script_exit() {
    [ "$?" -ne 0 ] && status=FAILURE || status=FINISHED
    echo $status
}

# Set the system to automatically 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 script to stop without reporting an error if the MicroShift service is not running.
if [ $(systemctl is-enabled microshift.service 2>/dev/null) != "enabled" ] ; then
    echo "MicroShift service is not enabled. Exiting..."
    exit 0
fi

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

# Set the script to wait for the pod images to be downloaded.
for i in ${!PODS_NS_LIST[@]}; do
    CHECK_PODS_NS=${PODS_NS_LIST[$i]}

    echo "Waiting ${WAIT_TIMEOUT_SECS}s for pod image(s) from the ${CHECK_PODS_NS} namespace to be downloaded"
    wait_for ${WAIT_TIMEOUT_SECS} namespace_images_downloaded
done

# Set the script to wait for pods to enter ready state.
for i in ${!PODS_NS_LIST[@]}; do
    CHECK_PODS_NS=${PODS_NS_LIST[$i]}
    CHECK_PODS_CT=${PODS_CT_LIST[$i]}

    echo "Waiting ${WAIT_TIMEOUT_SECS}s for ${CHECK_PODS_CT} pod(s) from the ${CHECK_PODS_NS} namespace to be in 'Ready' state"
    wait_for ${WAIT_TIMEOUT_SECS} namespace_pods_ready
done

# Verify that pods are not restarting by running, which could indicate a crash loop.
for i in ${!PODS_NS_LIST[@]}; do
    CHECK_PODS_NS=${PODS_NS_LIST[$i]}

    echo "Checking pod restart count in the ${CHECK_PODS_NS} namespace"
    namespace_pods_not_restarting ${CHECK_PODS_NS}
done
Copy to Clipboard Toggle word wrap

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

先决条件

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

流程

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

    $ sudo reboot
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,检查 greenboot 健康检查的输出:

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

    红帽构建的 MicroShift 核心服务健康检查在工作负载健康检查前运行。

    输出示例

    GRUB boot variables:
    boot_success=0
    boot_indeterminate=0
    Greenboot variables:
    GREENBOOT_WATCHDOG_CHECK_ENABLED=true
    ...
    ...
    FINISHED
    Script '40_microshift_running_check.sh' SUCCESS
    Running Wanted Health Check Scripts...
    Finished greenboot Health Checks Runner.
    Copy to Clipboard Toggle word wrap

法律通告

Copyright © 2024 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

© 2026 Red Hat