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

配置

Red Hat build of MicroShift 4.15

配置 MicroShift

Red Hat OpenShift Documentation Team

摘要

本文档提供有关配置 MicroShift 的说明。

第 1 章 配置工具的工作方式
复制链接

通过一个 YAML 文件，可根据您的偏好、设置和参数自定义 MicroShift 实例。

注意

如果要使用 kustomize 清单以外的工具通过 MicroShift API 进行配置更改或部署应用程序，您必须等待 greenboot 健康检查完成。这可确保，如果 greenboot 将 rpm-ostree 系统回滚回较早的状态，您的更改不会丢失。

1.1. 默认设置
复制链接

如果没有创建 config.yaml 文件，则使用默认值。以下示例显示了默认配置设置。

  • 要查看默认值，请运行以下命令： 

    $ microshift show-config
    Copy to Clipboard Toggle word wrap

    YAML 格式的默认值示例

    dns:
  baseDomain: microshift.example.com
    1 
    
network:
  clusterNetwork:
    - 10.42.0.0/16
    2 
    
  serviceNetwork:
    - 10.43.0.0/16
    3 
    
  serviceNodePortRange: 30000-32767
    4 
    
node:
  hostnameOverride: ""
    5 
    
  nodeIP: ""
    6 
    
apiServer:
  advertiseAddress: 10.44.0.0/32
    7 
    
  subjectAltNames: []
    8 
    
debugging:
  logLevel: "Normal"
    9
    Copy to Clipboard Toggle word wrap

    1
    集群的基域。所有管理的 DNS 记录都将是这个基础的子域。
    2
    从中分配 Pod IP 地址的 IP 地址块。
    3
    Kubernetes 服务的虚拟 IP 地址块。
    4
    端口范围允许用于 NodePort 类型的 Kubernetes 服务。
    5
    节点的名称。默认值为 hostname。
    6
    节点的 IP 地址。默认值是默认路由的 IP 地址。
    7
    指定 API 服务器公告给集群成员的 IP 地址的字符串。默认值根据服务网络的地址计算。
    8
    API 服务器证书的主题备用名称。
    9
    日志详细程度。此字段的有效值为 Normal,Debug,Trace, 或 TraceAll。

1.2. 使用 YAML 配置文件
复制链接

在启动时，MicroShift 会在系统范围的 /etc/microshift/ 目录中搜索名为 config.yaml 的配置文件。要使用自定义配置，您必须创建配置文件并指定在启动 MicroShift 前覆盖默认值的设置。

1.2.1. 自定义设置
复制链接

要创建自定义配置，您必须在 /etc/microshift/ 目录中创建 config.yaml 文件，然后在启动或重启 MicroShift 前更改要覆盖默认值的设置。

重要

在更改任何配置设置后，重新启动 MicroShift 使其生效。config.yaml 文件仅在 MicroShift 启动时读取。

1.2.2. 配置公告地址网络标记
复制链接

apiserver.advertiseAddress 标志指定要将 API 服务器公告给集群成员的 IP 地址。集群必须可以访问这个地址。您可以在此处设置自定义 IP 地址，但还必须将 IP 地址添加到主机接口。自定义此参数会抢占 MicroShift，将默认 IP 地址添加到 br-ex 网络接口。

重要

如果自定义 advertiseAddress IP 地址，请通过将 IP 地址添加到主机接口来确保集群可在 MicroShift 启动时被集群访问。

如果未设置，则默认值会在服务网络后设置为下一个即时子网。例如，当服务网络为 10.43.0.0/16 时，广告地址 被设置为 10.44.0.0/32。

1.2.3. 为 NodePort 服务扩展端口范围
复制链接

serviceNodePortRange 设置扩展可用于 NodePort 服务的端口范围。当需要公开 30000-32767 范围下的特定标准端口时，这个选项很有用。例如，如果您的设备需要公开网络上的 1883/tcp MQ 遥测传输(MQTT)端口，因为客户端设备无法使用不同的端口。

重要

NodePort 可以与系统端口重叠，从而导致系统或 MicroShift 出现故障。

配置 NodePort 服务范围时请考虑以下几点：

  • 不要在没有明确选择了 nodePort 的情况下创建任何 NodePort 服务。如果没有指定显式 nodePort，则 kube-apiserver 会随机分配端口，且无法预测。
  • 不要为在设备 HostNetwork 上公开的系统服务端口、MicroShift 端口或其他服务创建任何 NodePort 服务。

  • 表一指定在扩展端口范围时要避免的端口：

    Expand
    表 1.1. 避免的端口。
    端口描述

    22/tcp

    SSH 端口

    80/tcp

    OpenShift Router HTTP 端点

    443/tcp

    OpenShift Router HTTPS 端点

    1936/tcp

    openshift-router 的指标服务，目前不会公开

    2379/tcp

    etcd 端口

    2380/tcp

    etcd 端口

    6443

    kubernetes API

    8445/tcp

    openshift-route-controller-manager

    9537/tcp

    cri-o 指标

    10250/tcp

    kubelet

    10248/tcp

    kubelet healthz port

    10259/tcp

    kube 调度程序

第 2 章 使用 kubeconfig 的集群访问权限
复制链接

了解 kubeconfig 文件如何与 MicroShift 部署一起使用。CLI 工具使用 kubeconfig 文件与集群的 API 服务器通信。这些文件提供集群详情、IP 地址以及身份验证所需的其他信息。

2.1. 用于配置集群访问的 kubeconfig 文件
复制链接

MicroShift 中使用的两种 kubeconfig 文件是本地访问和远程访问。每次 MicroShift 启动时，都会生成一组用于本地和远程访问 API 服务器的 kubeconfig 文件。这些文件使用预先存在的配置信息在 /var/lib/microshift/resources/kubeadmin/ 目录中生成。

每个访问类型都需要不同的身份验证证书，由不同的证书颁发机构(CA)签名。生成多个 kubeconfig 文件来满足这一需求。

您可以将适当的 kubeconfig 文件用于每个情况下所需的访问类型，以提供身份验证详情。MicroShift kubeconfig 文件的内容由默认的内置值或 config.yaml 文件决定。

注意

kubeconfig 文件必须存在，集群才能访问。这些值从内置默认值或 config.yaml 应用（如果创建了）。

kubeconfig 文件的内容示例

/var/lib/microshift/resources/kubeadmin/
├── kubeconfig
1 

├── alt-name-1
2 

│   └── kubeconfig
├── 1.2.3.4
3 

│   └── kubeconfig
└── microshift-rhel9
4 

    └── kubeconfig
Copy to Clipboard Toggle word wrap

1
本地主机名。主机的主 IP 地址始终是默认值。
2
API 服务器证书的主题备用名称。
3
DNS 名称。
4
MicroShift 主机名。

2.2. 本地访问 kubeconfig 文件
复制链接

本地访问 kubeconfig 文件被写入 /var/lib/microshift/resources/kubeadmin/kubeconfig。此 kubeconfig 文件可使用 localhost 访问 API 服务器。当您在本地连接集群时，选择此文件。

用于本地访问的 kubeconfig 的内容示例

clusters:
- cluster:
    certificate-authority-data: <base64 CA>
    server: https://localhost:6443
Copy to Clipboard Toggle word wrap

localhost kubeconfig 文件只能从从同一主机上连接到 API 服务器的客户端使用。文件中的证书不适用于远程连接。

2.2.1. 本地访问 MicroShift 集群
复制链接

使用以下步骤使用 kubeconfig 文件在本地访问 MicroShift 集群。

先决条件

  • 已安装 oc 二进制文件。

流程

  1. 可选：如果您的 RHEL 机器没有 ~/.kube/ 文件夹，请运行以下命令： 

    $ mkdir -p ~/.kube/
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令，将生成的本地访问 kubeconfig 文件复制到 ~/.kube/ 目录中： 

    $ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
    Copy to Clipboard Toggle word wrap

  3. 运行以下命令更新 ~/.kube/config 文件的权限： 

    $ chmod go-r ~/.kube/config
    Copy to Clipboard Toggle word wrap

验证

  • 输入以下命令验证 MicroShift 是否正在运行： 

    $ oc get all -A
    Copy to Clipboard Toggle word wrap

2.3. 远程访问 kubeconfig 文件
复制链接

当 MicroShift 集群从外部源连接到 API 服务器时，会使用 SAN 字段中所有替代名称的证书进行验证。MicroShift 使用 hostname 值为外部访问生成默认的 kubeconfig。默认值在默认的 kubeconfig 文件的 < node.hostnameOverride> , <node.nodeIP > 和 api.<dns.baseDomain > 参数值中设置。

/var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig 文件使用机器的 hostname 或 node.hostnameOverride（如果设置了这个选项）来访问 API 服务器。kubeconfig 文件的 CA 可以在外部访问时验证证书。

用于远程访问的默认 kubeconfig 文件的内容示例

clusters:
- cluster:
    certificate-authority-data: <base64 CA>
    server: https://microshift-rhel9:6443
Copy to Clipboard Toggle word wrap

2.3.1. 远程访问自定义
复制链接

可以生成多个远程访问 kubeconfig 文件值来访问具有不同 IP 地址或主机名的集群。为 apiServer.subjectAltNames 参数中的每个条目生成额外的 kubeconfig 文件。您可以在 IP 连接期间从主机复制 kubeconfig 文件，然后使用它们从其他工作站访问 API 服务器。

2.4. 为远程访问生成额外的 kubeconfig 文件
复制链接

如果需要更多主机名或 IP 地址超过默认的远程访问文件提供，您可以生成额外的 kubeconfig 文件。

重要

您必须重启 MicroShift 才能实现配置更改。

先决条件

  • 您已为 MicroShift 创建了一个 config.yaml。

流程

  1. 可选： 您可以显示 config.yaml 的内容。运行以下命令: 

    $ cat /etc/microshift/config.yaml
    Copy to Clipboard Toggle word wrap

  2. 可选： 您可以显示远程访问 kubeconfig 文件的内容。运行以下命令: 

    $ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
    Copy to Clipboard Toggle word wrap
    重要

    其他远程访问 kubeconfig 文件必须包含 MicroShift config.yaml 文件中列出的服务器名称之一。其他 kubeconfig 文件还必须使用相同的 CA 进行验证。

  3. 要为额外的 DNS 名称 SAN 或外部 IP 地址生成额外的 kubeconfig 文件，请将您需要的条目添加到 apiServer.subjectAltNames 字段。在以下示例中，所用的 DNS 名称为 alt-name-1，IP 地址为 1.2.3.4。

    带有额外身份验证值的 config.yaml 示例

    dns:
  baseDomain: example.com
node:
  hostnameOverride: "microshift-rhel9"
    1 
    
  nodeIP: 10.0.0.1
apiServer:
  subjectAltNames:
  - alt-name-1
    2 
    
  - 1.2.3.4
    3
    Copy to Clipboard Toggle word wrap

    1
    主机名
    2
    DNS 名称
    3
    IP 地址或范围

  4. 运行以下命令，重启 MicroShift 以应用配置更改并自动生成您需要的 kubeconfig 文件： 

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap

  5. 要检查额外的远程访问 kubeconfig 文件的内容，请将 config.yaml 中列出的名称或 IP 地址插入到 cat 命令中。例如，以下示例命令中使用 alt-name-1 ： 

    $ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
    Copy to Clipboard Toggle word wrap

  6. 选择 kubeconfig 文件，以使用其中包含您要用于连接集群的 SAN 或 IP 地址。在本例中，在 cluster.server 字段中包含'alt-name-1' 的 kubeconfig 是正确的文件。

    其他 kubeconfig 文件的内容示例

    clusters:
- cluster:
    certificate-authority-data: <base64 CA>
    server: https://alt-name-1:6443
    1
    Copy to Clipboard Toggle word wrap

    1
    /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig 文件值来自 apiServer.subjectAltNames 配置值。
注意

所有这些参数都作为通用名称(CN)和主题备用名称(SAN)包含在 API 服务器的外部服务证书中。

2.4.1. 打开防火墙以远程访问 MicroShift 集群
复制链接

使用以下步骤打开防火墙，以便远程用户可以访问 MicroShift 集群。必须在 workstation 用户可以访问集群前完成此步骤。

对于此过程，user@microshift 是 MicroShift 主机上的用户，负责设置该机器，使其可以被单独的工作站上的远程用户访问。

先决条件

  • 已安装 oc 二进制文件。
  • 您的帐户具有集群管理特权。

流程

  • 在 MicroShift 主机上以 user@microshift 的身份，运行以下命令来打开 Kubernetes API 服务器的防火墙端口 (6443/tcp)： 

    [user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

验证

  • 以 user@microshift 的身份，输入以下命令验证 MicroShift 是否正在运行： 

    [user@microshift]$ oc get all -A
    Copy to Clipboard Toggle word wrap

2.4.2. 远程访问 MicroShift 集群
复制链接

使用以下步骤通过 kubeconfig 文件从远程工作站访问 MicroShift 集群。

user@workstation 登录用于远程访问主机计算机。该流程中的 <user> 值是 user@workstation 登录到 MicroShift 主机所使用的用户名。

先决条件

  • 已安装 oc 二进制文件。
  • user@microshift 已从本地主机打开防火墙。

流程

  1. 以 user@workstation 的身份，运行以下命令，创建 ~/.kube/ 文件夹： 

    [user@workstation]$ mkdir -p ~/.kube/
    Copy to Clipboard Toggle word wrap

  2. 以 user@workstation 的身份，运行以下命令来为您的 MicroShift 主机的主机名设置变量： 

    [user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
    Copy to Clipboard Toggle word wrap

  3. 以 user@workstation 的身份，通过运行以下命令复制生成的 kubeconfig 文件，其中包含您要从运行 MicroShift 的 RHEL 机器连接到您的本地机器的主机名或 IP 地址： 

    [user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
    Copy to Clipboard Toggle word wrap
注意

要为此步骤生成 kubeconfig 文件，请参阅附加资源部分中的"生成额外 kubeconfig 文件以进行远程访问"。

  1. 以 user@workstation 的身份，运行以下命令来更新 ~/.kube/config 文件的权限： 

    $ chmod go-r ~/.kube/config
    Copy to Clipboard Toggle word wrap

验证

  • 以 user@workstation 的身份，输入以下命令验证 MicroShift 是否正在运行： 

    [user@workstation]$ oc get all -A
    Copy to Clipboard Toggle word wrap

第 3 章 检查 greenboot 脚本状态
复制链接

要使用 kustomize 清单以外的工具通过 MicroShift API 部署应用程序或进行其他更改，您必须等待 greenboot 健康检查完成。这可确保，如果 greenboot 将 rpm-ostree 系统回滚回较早的状态，您的更改不会丢失。

greenboot-healthcheck 服务会运行一个时间，然后退出。在 greenboot 退出并且系统处于健康状态后，您可以继续配置更改和部署。

3.1. 检查 greenboot 健康检查的状态
复制链接

在对系统进行更改或故障排除期间，检查 greenboot 健康检查的状态。您可以使用以下任一命令来帮助确保 greenboot 脚本已完成运行。

流程

  • 要查看健康检查状态的报告，请使用以下命令： 

    $ systemctl show --property=SubState --value greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap
    • start 的输出表示 greenboot 检查仍在运行。
    • 退出 的输出表示检查已通过，reenboot 已退出。当系统处于健康状态时，greenboot 在 green.d 目录中运行脚本。
    • 失败 的输出意味着检查还没有通过。greenboot 在系统处于此状态时在 red.d 目录中运行脚本，并可能重启系统。

  • 要查看显示服务的数字退出代码的报告，其中 0 表示成功，非零值表示发生失败，请使用以下命令： 

    $ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap

  • 要查看显示引导状态的消息的报告，如 Boot Status 为 GREEN - Health Check SUCCESS，请使用以下命令： 

    $ cat /run/motd.d/boot-status
    Copy to Clipboard Toggle word wrap

法律通告
复制链接

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