运行的应用程序
第 1 章 使用 Kustomize 清单部署应用程序
您可以将 kustomize
配置管理工具与应用程序清单一起使用来部署应用程序。阅读以下流程,以了解 Kustomize 在 MicroShift 中的工作方式。
1.1. Kustomize 如何与清单一起工作来部署应用程序
kustomize
配置管理工具与 MicroShift 集成。您可以使用 Kustomize 和 OpenShift CLI (oc
)将自定义应用到应用程序清单,并将这些应用程序部署到 MicroShift 集群。
-
kustomization.yaml
文件是资源及自定义的规格。 -
Kustomize 使用
kustomization.yaml
文件加载资源,如应用程序,然后应用您想要的应用程序清单的任何更改,并生成具有 overlaid 更改的清单副本。 - 使用带有覆盖的清单副本会使应用程序的原始配置文件保持不变,同时允许您有效地部署应用程序的迭代和自定义。
-
然后,您可以使用
oc
命令在 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 工作负载,使不同工作负载可以独立运行。
位置 | 作用 |
---|---|
| 用于配置管理系统或开发的读写位置。 |
| 用于配置管理系统或开发的读写位置。 |
| 在基于 OSTree 的系统上嵌入配置清单的只读位置。 |
| 在基于 OSTree 的系统上嵌入配置清单的只读位置。 |
1.2. 覆盖清单路径列表
您可以使用新的单一路径或将新的 glob 模式用于多个文件来覆盖默认清单路径列表。使用以下步骤自定义清单路径。
流程
通过插入您自己的值并运行以下命令之一来覆盖默认路径列表:
-
将配置文件中的
manifests.kustomizePaths
设置为 <"/opt/alternate/path
">。 在用于 glob 模式的配置文件中将
kustomizePaths
设置为,"/opt/alternative/path.d
mdadm"。manifests: kustomizePaths: - <location> 1
- 1
- 使用
"/opt/alternate/path"
或 glob 模式将每个位置条目设置为准确路径,使用"/opt/alternative/path.d8:0:1::"
。
-
将配置文件中的
要禁用加载清单,请将配置选项设置为空列表。
manifests: kustomizePaths: []
注意配置文件完全会覆盖默认值。如果设置了
kustomizePaths
值,则只使用配置文件中的值。将值设为空列表可禁用清单加载。
1.3. 使用清单示例
本例演示了使用 /etc/microshift/manifests
目录中的 kustomize
清单自动部署 BusyBox 容器。
流程
运行以下命令来创建 BusyBox 清单文件:
定义目录位置:
$ MANIFEST_DIR=/etc/microshift/manifests
创建目录:
$ sudo mkdir -p ${MANIFEST_DIR}
将 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
接下来,运行以下命令来创建
kustomize
清单文件:将 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
运行以下命令重启 MicroShift 以应用清单:
$ sudo systemctl restart microshift
运行以下命令应用清单并启动
busybox
pod:$ oc get pods -n busybox
第 2 章 在 RHEL for Edge 镜像中嵌入 MicroShift 应用程序的选项
您可以在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中嵌入基于微服务的工作负载和应用程序,以便在 MicroShift 集群中运行。嵌入式应用程序可以直接安装在边缘设备上,以便在 air-gapped、断开连接或离线环境中运行。
2.1. 将应用程序 RPM 添加到 rpm-ostree 镜像
如果您的应用程序包含 API、容器镜像和配置文件,如清单等部署,您可以构建应用程序 RPM。然后,您可以在 RHEL for Edge 系统镜像中添加 RPM。
以下是在完全自包含的操作系统镜像中嵌入应用程序或工作负载的流程概述:
- 构建包含应用程序清单的您自己的 RPM。
- 将 RPM 添加到用于安装红帽构建的 MicroShift 的蓝图中。
- 将工作负载容器镜像添加到同一蓝图中。
- 创建可引导 ISO。
有关在 RHEL for Edge 镜像中准备和嵌入应用程序的逐步教程,请使用以下教程:
2.2. 在镜像中添加应用程序清单以离线使用
如果您有一个简单的应用程序,其中包含几个用于部署的文件,如清单,您可以将这些清单直接添加到 RHEL for Edge 系统镜像中。
有关示例,请参阅以下 RHEL for Edge 文档中的"创建自定义文件蓝图自定义"部分:
2.3. 嵌入应用程序供离线使用
如果您的应用程序包含多个文件,您可以嵌入应用程序以离线使用。请参见以下步骤:
2.4. 其他资源
第 3 章 嵌入应用程序供离线使用
您可以在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像中嵌入基于微服务的工作负载和应用程序。嵌入意味着您可以在 air-gapped、断开连接或离线环境中运行 MicroShift 集群的红帽构建。
3.1. 嵌入工作负载容器镜像供离线使用
要在没有网络连接的边缘将容器镜像嵌入到设备中,您必须创建新容器,挂载 ISO,然后将内容复制到文件系统中。
先决条件
- 有对主机的 root 访问权限。
- 应用程序 RPM 已添加到蓝图中。
流程
呈现清单,提取所有容器镜像引用,并通过运行以下命令来将应用程序镜像转换为蓝图容器源:
$ oc kustomize ~/manifests | grep "image:" | grep -oE '[^ ]+$' | while read line; do echo -e "[[containers]]\nsource = \"${line}\"\n"; done >><my_blueprint>.toml
运行以下命令,将更新的蓝图推送到镜像构建器:
$ sudo composer-cli blueprints push <my_blueprint>.toml
如果您的工作负载容器位于私有存储库中,则必须为镜像构建器提供所需的 pull secret:
-
在
/etc/osbuild-worker/osbuild-worker.toml
文件中的osbuilder worker
配置的[containers]
部分中设置auth_file_path
,以指向 pull secret。 如果需要,为 pull secret 创建目录和文件,例如:
目录和文件示例
[containers] auth_file_path = "/<path>/pull-secret.json" 1
- 1
- 使用之前设置的自定义位置来复制和检索镜像。
-
在
运行以下命令来构建容器镜像:
$ sudo composer-cli compose start-ostree <my_blueprint> edge-commit
-
继续您首选的
rpm-ostree
镜像流,如等待构建完成,导出镜像并将其集成到rpm-ostree
存储库或创建可引导 ISO。
3.2. 其他资源
第 4 章 嵌入红帽构建的 MicroShift 应用程序教程
以下教程提供了如何在 RHEL for Edge 镜像中嵌入应用程序以便在各种环境中在 MicroShift 集群中使用的详细示例。
4.1. 嵌入应用程序 RPM 指南
以下教程回顾 MicroShift 安装步骤,并添加用于嵌入应用程序的工作流的描述。如果您已经熟悉 rpm-ostree
系统,如 Red Hat Enterprise Linux for Edge (RHEL for Edge)和 MicroShift,您可以直接进入相关的操作。
4.1.1. 安装工作流查看
嵌入的应用程序需要类似的工作流将 MicroShift 嵌入到 RHEL for Edge 镜像中。
- 下图显示了系统工件(如 RPM、容器和文件)如何添加到蓝图中,并由镜像 composer 创建 ostree 提交。
- 然后,ostree 提交可以遵循 ISO 路径或边缘设备的存储库路径。
- ISO 路径可用于断开连接的环境,而存储库路径通常用于网络通常连接。
嵌入 MicroShift 工作流
查看这些步骤可帮助您了解嵌入应用程序所需的步骤:
- 要在 RHEL for Edge 上嵌入 MicroShift,您需要将 MicroShift 存储库添加到 Image Builder 中。
- 您创建了声明您所需的所有 RPM、容器镜像、文件和自定义的蓝图,包括添加 MicroShift。
-
您已将蓝图添加到镜像构建器,并使用 Image Builder CLI 工具(
composer-cli
)运行构建。此步骤创建rpm-ostree
提交,用于创建容器镜像。此镜像包含 RHEL for Edge。 -
将安装程序蓝图添加到镜像构建器中,以创建
rpm-ostree
镜像(ISO)来从其引导。此构建包含 RHEL for Edge 和 MicroShift。 - 下载了使用 MicroShift 嵌入的 ISO,准备好使用、置备它,然后将其安装到边缘设备中。
4.1.2. 嵌入应用程序 RPM 工作流
设置满足 Image Builder 要求的构建主机后,您可以将应用程序以清单目录的形式添加到镜像。这些步骤后,将应用程序或工作负载嵌入到新 ISO 中最简单的方法是创建自己的包含清单的 RPM。您的应用程序 RPM 包含描述部署的所有配置文件。
以下"嵌入的应用程序工作流"镜像演示了如何将 Kubernetes 应用程序清单和 RPM 规格文件合并到单个应用程序 RPM 构建中。此构建成为工作流中包含的 RPM 工件,用于将 MicroShift 嵌入到 ostree 提交中。
嵌入应用程序工作流
以下流程使用 rpmbuild
工具创建规格文件和本地存储库。规范文件定义了如何构建软件包,将应用程序清单移到 MicroShift 的 RPM 软件包中的正确位置,以便获取它们。然后,该 RPM 软件包被嵌入到 ISO 中。
4.1.3. 准备进行应用程序 RPM
要构建自己的 RPM,请选择您选择的工具,如 rpmbuild
工具,并在主目录中初始化 RPM 构建树。以下是示例步骤。只要您的 RPM 可以被镜像构建器访问,就可以使用您喜欢构建应用程序 RPM 的方法。
先决条件
- 您已设置了满足 Image Builder 系统要求的 Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.2 构建主机。
- 有对主机的 root 访问权限。
流程
运行以下命令,安装
rpmbuild
工具并为其创建 yum 存储库:$ sudo dnf install rpmdevtools rpmlint yum-utils createrepo
运行以下命令,创建构建 RPM 软件包所需的文件树:
$ rpmdev-setuptree
验证
运行以下命令列出确认创建的目录:
$ ls ~/rpmbuild/
输出示例
BUILD RPMS SOURCES SPECS SRPMS
4.1.4. 为应用程序清单构建 RPM 软件包
要构建自己的 RPM,您必须创建一个 spec 文件,将应用程序清单添加到 RPM 软件包中。以下是示例步骤。只要应用程序 RPM 和其他镜像构建元素可供镜像构建器访问,您可以使用您喜欢的方法。
先决条件
- 您已设置了满足 Image Builder 系统要求的 Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.2 构建主机。
- 有对主机的 root 访问权限。
- 构建 RPM 软件包所需的文件树已创建。
流程
在
~/rpmbuild/SPECS
目录中,使用以下模板创建一个文件,如 <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>
- 1
%install
部分在 RPM 软件包/usr/lib/microshift/manifests/
中创建目标目录,并从源主目录~/manifests
复制清单。
重要所有必需的 YAML 文件都必须位于源主目录
~/manifests
中,如果您使用的是 kustomize,则包括kustomize.yaml
文件。运行以下命令,在
~/rpmbuild/RPMS
目录中构建 RPM 软件包:$ rpmbuild -bb ~/rpmbuild/SPECS/<application_workload_manifests.spec>
4.1.5. 在蓝图中添加应用程序 RPM
要将应用程序 RPM 添加到蓝图中,您必须创建一个本地仓库,供 Image Builder 用于创建 ISO。使用这个流程,您的工作负载所需的容器镜像可以通过网络拉取。
先决条件
- 有对主机的 root 访问权限。
-
工作负载或应用程序 RPM 存在于
~/rpmbuild/RPMS
目录中。
流程
运行以下命令来创建本地 RPM 存储库:
$ createrepo ~/rpmbuild/RPMS/
运行以下命令,为 Image Builder 授予对 RPM 存储库的访问权限:
$ sudo chmod a+rx ~
注意您必须确保 Image Builder 具有访问镜像构建所需的所有文件所需的权限,或者构建无法继续。
使用以下模板创建蓝图文件
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
- 1
- 指定创建您选择的位置的路径部分。在后续命令中使用此路径来设置存储库并复制 RPM。
运行以下命令,将存储库添加为镜像构建器的源:
$ sudo composer-cli sources add repo-local-rpmbuild.toml
通过添加以下几行,将 RPM 添加到蓝图中:
… [[packages]] name = "<application_workload_manifests>" 1 version = "*" …
- 1
- 在此处添加工作负载的名称。
运行以下命令,将更新的蓝图推送到镜像构建器:
$ sudo composer-cli blueprints push repo-local-rpmbuild.toml
此时,您可以运行 Image Builder 来创建 ISO,或嵌入容器镜像供离线使用。
要创建 ISO,请运行以下命令启动镜像构建器:
$ sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commit
在这种情况下,容器镜像在启动时由边缘设备通过网络拉取。
4.2. 其他资源
第 5 章 Greenboot 工作负载健康检查脚本
Greenboot 健康检查脚本在边缘设备上很有用,其中直接可服务性有限或不存在。您可以创建健康检查脚本来评估工作负载和应用程序的健康状态。这些额外的健康检查脚本是软件问题检查和自动系统回滚的有用组件。
MicroShift 健康检查脚本包含在 microshift-greenboot
RPM 中。您还可以根据您正在运行的工作负载创建自己的健康检查脚本。例如,您可以编写一个来验证服务是否已启动。
5.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 可以表示崩溃循环。
5.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 小时宽限期。通过将
/
来禁用。etc/greenboot/greenboot.conf
中的GREENBOOT_WATCHDOG_CHECK_ENABLED
修改GREENBOOT_WATCHDOG_CHECK_ENABLED 来禁用此宽限期,也可以通过将 /etc/greenboot/greenboot.conf 中的 GREENBOOT_WATCHDOD=number_hours
变量值改为 false
5.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
目录中。
5.3.1. 关于工作负载健康检查脚本示例
以下示例使用 MicroShift 健康检查脚本作为模板。您可以将这个示例与提供的库一起使用,作为为应用程序创建基本健康检查脚本的指南。
5.3.1.1. 创建健康检查脚本的基本先决条件
- 必须安装工作负载。
- 您必须有 root 访问权限。
5.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
5.4. 测试工作负载健康检查脚本
先决条件
- 有 root 访问权限。
- 已安装工作负载。
- 您已为工作负载创建了健康检查脚本。
- 红帽构建的 MicroShift 服务已启用。
流程
要测试 greenboot 是否在运行健康检查脚本文件,请运行以下命令重启主机:
$ sudo reboot
运行以下命令,检查 greenboot 健康检查的输出:
$ sudo journalctl -o cat -u greenboot-healthcheck.service
注意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.
5.5. 其他资源
第 6 章 Pod 安全身份验证和授权
6.1. 了解并管理 pod 安全准入
Pod 安全准入是 Kubernetes pod 安全标准的实现。使用 pod 安全准入来限制 pod 的行为。
6.2. 安全性上下文约束与 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 特权。但是,在自动标记过程中不会考虑用户权限。
6.2.1. 查看命名空间中的安全性上下文约束
您可以查看给定命名空间中的安全性上下文约束(SCC)权限。
先决条件
-
已安装 OpenShift CLI(
oc
)。
流程
要查看命名空间中的安全性上下文约束,请运行以下命令:
oc get --show-labels namespace <namespace>
6.3. 控制 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
您可以使用 --overwrite 标志在命名空间中反向 pod 安全标签同步的影响。
第 7 章 Operator 在 MicroShift 中如何工作
您可以将 Operator 与 MicroShift 搭配使用,以创建用于监控集群中运行的服务的应用程序。Operator 可以管理应用程序及其资源,如部署数据库或消息总线。作为在集群中运行的自定义软件,可以使用 Operator 来实现和自动化常见操作。
Operator 提供了更本地化的配置体验,并与 Kubernetes API 和 CLI 工具(如 kubectl
和 oc
)集成。Operator 是专为您的应用程序而设计的。Operator 允许您配置组件而不是修改全局配置文件。
MicroShift 应用程序通常预期部署在静态环境中。但是,如果在您的用例中很有用,Operator 就会可用。要确定 Operator 与 MicroShift 的兼容性,请查看 Operator 的文档。
7.1. 如何在 MicroShift 中安装 Operator
为最小化 MicroShift 的影响,Operator 直接使用清单安装,而不使用 Operator Lifecycle Manager (OLM)。您可以在 MicroShift 中使用 kustomize
配置管理工具来部署应用程序。使用相同的步骤使用清单安装 Operator。请参阅 使用 Kustomize 清单来部署应用程序 以获取有关清单的更多信息。