配置
第 1 章 使用 MicroShift 配置文件 复制链接链接已复制到粘贴板!
通过一个 YAML 文件,可根据您的偏好、设置和参数自定义 MicroShift 实例。
如果要使用 kustomize 清单以外的工具通过 MicroShift API 进行配置更改或部署应用程序,您必须等待 greenboot 健康检查完成。这可确保,如果 greenboot 将 rpm-ostree 系统回滚回较早的状态,您的更改不会丢失。
1.1. MicroShift YAML 配置文件 复制链接链接已复制到粘贴板!
启动时,MicroShift 会检查系统范围的 /etc/microshift/ 目录,以获取名为 config.yaml 的配置文件。如果目录中不存在配置文件,则使用内置默认值来启动服务。
MicroShift 配置文件必须与 host 和, sometimes, 应用程序和服务设置结合使用。在自定义 MicroShift 集群时,确保每个项目都以 tandem 配置。
1.1.1. 默认设置 复制链接链接已复制到粘贴板!
如果没有创建 config.yaml 文件,则使用默认值。以下示例显示了默认配置设置。
要查看默认值,请运行以下命令:
microshift show-config
$ microshift show-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow YAML 格式输出的默认值
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2. 使用自定义设置 复制链接链接已复制到粘贴板!
要创建自定义配置,请制作 /etc/microshift/ 目录中提供的 config.yaml.default 文件的副本,请将其重命名为 config.yaml。将此文件保存在 /etc/microshift/ 目录中,然后您可以在启动或重启 MicroShift 前更改预期覆盖默认值的支持的设置。
在更改任何配置设置后,重新启动 MicroShift 使其生效。当 MicroShift 启动时,config.yaml 文件是只读的。
1.2.1. 单独的重启 复制链接链接已复制到粘贴板!
可能需要单独重启 MicroShift 集群的应用程序和其他可选服务,以便在集群中应用配置更改。例如,在更改某些网络设置时,您必须停止并重启服务和应用程序 pod 以应用这些更改。如需更多信息,请参阅您要完成的任务的每个步骤。
如果您同时添加您需要的所有配置,您可以最小化系统重启。
1.2.2. MicroShift config.yaml 文件的参数和值 复制链接链接已复制到粘贴板!
下表解释了 MicroShift 配置 YAML 参数以及每个有效值:
| 字段 | 类型 | 描述 |
|---|---|---|
|
|
| 指定 API 服务器公告给集群成员的 IP 地址的字符串。默认值根据服务网络的地址计算。 |
|
|
|
在自动删除前保留日志文件的时长。 |
|
|
|
默认情况下,当 |
|
|
| 保存的日志文件总数。默认情况下,MicroShift 保留 10 个日志文件。创建过量文件时,会删除最旧的文件。可以配置这个值。 |
|
|
|
仅记录读取和写入请求的日志元数据 ;除了 OAuth 访问令牌请求外,不记录请求正文。如果没有指定此字段,则使用 |
|
|
| 使用自定义证书颁发机构定义外部生成的证书和域名。 |
|
|
| 证书的完整路径。 |
|
|
| 证书密钥的完整路径。 |
|
|
| 可选。添加显式 DNS 名称列表。允许前导通配符。如果没有提供名称,则会从证书中提取隐式名称。 |
|
|
完全限定域名(FQDN)、通配符(如 3.0. | API 服务器证书的主题备用名称。sans 表示证书保护的所有域名和 IP 地址。 |
|
|
|
日志详细程度。默认为 |
|
|
| 集群的基域。所有管理的 DNS 记录都是这个基础的子域。 |
|
|
|
默认情况下, |
|
| IP 地址、NIC 名称或多个 | 值默认为主机的整个网络。有效可配置的值是一个列表,可以是单个 IP 地址或 NIC 名称,也可以是多个 IP 地址和 NIC 名称。 |
|
|
|
显示的默认端口。可配置。有效值是 1-65535 范围内的单个唯一端口。 |
|
|
|
显示的默认端口。可配置。有效值是 1-65535 范围内的单个唯一端口。 |
|
|
|
描述如何处理跨命名空间的主机名声明。默认情况下,允许路由在命名空间间声明相同主机名的不同路径。指定 |
|
|
|
路由器状态.默认为 |
|
| 请参阅 MicroShift 低延迟指令 | kubelet 节点代理的 passthrough 配置参数。用于低延迟配置。默认值为 null。 |
|
|
|
用于扫描 |
|
| IP 地址块 |
从中分配 Pod IP 地址的 IP 地址块。IPv4 是默认网络。支持双栈条目。此字段中的第一个条目在 MicroShift 启动后是不可变的。默认范围为 |
|
| IP 地址块 |
Kubernetes 服务的虚拟 IP 地址块。服务的 IP 地址池.IPv4 是默认设置。支持双栈条目。此字段中的第一个条目在 MicroShift 启动后是不可变的。默认范围为 |
|
|
|
端口范围允许用于 |
|
|
| 节点的名称。默认值为 hostname。如果非空,则使用此字符串来识别节点,而不是主机名。此值在 MicroShift 启动后是不可变的。 |
|
| IPv4 地址 | 节点的 IPv4 地址。默认值是默认路由的 IP 地址。 |
|
| IPv6 地址 | 用于双栈配置的节点的 IPv6 地址。无法在单个堆栈中为 IPv4 或 IPv6 配置。默认值为空值或 null。 |
|
|
| 默认值为空。空值或 null 字段默认为 LVMS 部署。 |
|
|
|
默认值为 null 或空数组。null 或空数组默认为部署 |
1.2.3. 使用配置片断 复制链接链接已复制到粘贴板!
如果要配置一个或多个设置,如添加主题备用名称(SAN),您可以使用 /etc/microshift/config.d/ 配置目录来丢弃配置片断 YAML 文件。您必须重启 MicroShift 才能应用新配置。
要返回前面的值,您可以删除配置片断并重启 MicroShift。
1.2.3.1. 配置片断如何工作 复制链接链接已复制到粘贴板!
在运行时,/etc/microshift/config.d 中的 YAML 文件合并到现有的 MicroShift 配置中,无论配置是否为默认值或用户创建的 config.yaml 文件。您不需要创建 config.yaml 文件来使用配置片断。
代码片段目录中的文件按字典顺序排序,并按顺序运行。您可以对代码片段使用数字前缀,以便按您想要的顺序读取每个项。当同一参数有多个 YAML 时,最后一个读取文件具有优先权。
配置片断优先于默认值和自定义 config.yaml 配置文件。
1.2.3.2. 列出配置片断示例 复制链接链接已复制到粘贴板!
列表或数组不会被合并,它们会被覆盖。例如,您可以通过为第一个字段之后读取的同一字段创建额外的片断来替换 SAN 或 SAN 列表:
MicroShift 配置目录内容
-
/etc/microshift/config.yaml.defaultor/etc/microshift/config.yaml
MicroShift 配置片断目录内容示例
-
/etc/microshift/config.d/10-san.yaml /etc/microshift/config.d/20-san.yaml示例
10-san.yaml片断apiServer: subjectAltNames: - host1 - host2apiServer: subjectAltNames: - host1 - host2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 20-san.yaml片断示例apiServer: subjectAltNames: - hostZapiServer: subjectAltNames: - hostZCopy to Clipboard Copied! Toggle word wrap Toggle overflow 配置结果示例
apiServer: subjectAltNames: - hostZapiServer: subjectAltNames: - hostZCopy to Clipboard Copied! Toggle word wrap Toggle overflow
如果要在现有列表中添加值,您可以将其添加到现有片断中。例如,要将 hostZ 添加到现有 SAN 列表中,请编辑您已有的代码片段,而不是创建新端口:
示例 10-san.yaml 片断
apiServer:
subjectAltNames:
- host1
- host2
- hostZ
apiServer:
subjectAltNames:
- host1
- host2
- hostZ
配置结果示例
apiServer:
subjectAltNames:
- host1
- host2
- hostZ
apiServer:
subjectAltNames:
- host1
- host2
- hostZ
1.2.3.3. 对象配置片断示例 复制链接链接已复制到粘贴板!
对象合并在一起。
10-advertiseAddress.yaml 片断示例
apiServer: advertiseAddress: "microshift-example"
apiServer:
advertiseAddress: "microshift-example"
20-audit-log.yaml 片断示例
apiServer:
auditLog:
maxFileAge: 12
apiServer:
auditLog:
maxFileAge: 12
配置结果示例
apiServer:
advertiseAddress: "microshift-example"
auditLog:
maxFileAge: 12
apiServer:
advertiseAddress: "microshift-example"
auditLog:
maxFileAge: 12
1.2.3.4. 混合配置片断示例 复制链接链接已复制到粘贴板!
在本例中,advertiseAddress 和 auditLog.maxFileAge 字段的值都合并到配置中,但只有 c.com 和 d.com subjectAltNames 值会被保留,因为文件名中的编号表示它们具有更高的优先级。
10-advertiseAddress.yaml 片断示例
apiServer: advertiseAddress: "microshift-example"
apiServer:
advertiseAddress: "microshift-example"
20-audit-log.yaml 片断示例
apiServer:
auditLog:
maxFileAge: 12
apiServer:
auditLog:
maxFileAge: 12
30-SAN.yaml 片断示例
apiServer:
subjectAltNames:
- a.com
- b.com
apiServer:
subjectAltNames:
- a.com
- b.com
40-SAN.yaml 片断示例
apiServer:
subjectAltNames:
- c.com
- d.com
apiServer:
subjectAltNames:
- c.com
- d.com
配置结果示例
1.2.4. 配置广告地址网络标记 复制链接链接已复制到粘贴板!
apiserver.advertiseAddress 标志指定将 API 服务器公告给集群成员的 IP 地址。此地址必须可以被集群访问。您可以在此处设置自定义 IP 地址,但还必须将 IP 地址添加到主机接口。自定义此参数 preempts MicroShift,不向 br-ex 网络接口添加默认 IP 地址。
如果您自定义 advertiseAddress IP 地址,请确保集群可在 MicroShift 启动时通过添加 IP 地址到主机接口来访问它。
如果未设置,则默认值将在服务网络后设置为下一个直接子网。例如,当服务网络为 10.43.0.0/16 时,advertiseAddress 被设置为 10.44.0.0/32。
1.2.5. 为 NodePort 服务扩展端口范围 复制链接链接已复制到粘贴板!
serviceNodePortRange 设置扩展可用于 NodePort 服务的端口范围。当需要公开 30000-32767 范围下的特定标准端口时,这个选项很有用。例如,如果您的设备需要公开网络上的 1883/tcp MQ 遥测传输(MQTT)端口,因为客户端设备无法使用不同的端口。
NodePort 可以与系统端口重叠,从而导致系统或 MicroShift 出现故障。
在配置 NodePort 服务范围时请考虑以下几点:
-
不要在没有明确选择了
nodePort的情况下创建任何 NodePort 服务。如果没有指定显式nodePort,则端口由kube-apiserver随机分配,且无法预测。 -
不要为在设备
HostNetwork上公开的系统服务端口、MicroShift 端口或其他服务创建任何 NodePort 服务。 表一指定在扩展端口范围时要避免的端口:
Expand 表 1.2. 避免的端口。 端口 描述 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 章 配置 IPv6 单或双栈网络 复制链接链接已复制到粘贴板!
您可以在单堆栈或双栈网络模式中使用 IPv6 网络协议。
2.1. 使用 MicroShift 的 IPv6 网络 复制链接链接已复制到粘贴板!
MicroShift 服务默认为集群范围的 IPv4 地址系列。但是,支持的平台上提供了 IPv6 单堆栈和 IPv4/IPv6 双栈网络。
- 当您在 MicroShift 配置文件中为 IPv6 设置值并重启服务时,由 OVN-Kubernetes 网络插件管理的设置会自动更新。
- 迁移到双栈网络后,新的和现有的 pod 都启用了双栈网络。
- 如果您需要集群范围的 IPv6 访问,如 control plane 和其他服务,请使用以下配置示例。MicroShift Multus Container Network Interface (CNI)插件可以为 pod 启用 IPv6。
- 对于双栈网络,每个 MicroShift 集群网络和服务网络都支持集群中和服务网络配置参数中的两个值。
第一次启动 MicroShift 前,计划 IPv6。除非将集群从默认的单堆栈迁移到双栈网络,否则不支持将集群切换到不同的 IP 系列。
如果为 IPv6 单一堆栈或 IPv4/IPv6 双堆栈配置网络,您必须重启应用程序 pod 和服务。否则,Pod 和服务仍使用默认 IP 系列配置。
2.2. 配置 IPv6 单堆栈网络 复制链接链接已复制到粘贴板!
您可以通过更新 MicroShift 服务配置文件来使用 IPv6 网络协议。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有对集群的 root 访问权限。
- 集群使用 OVN-Kubernetes 网络插件。
- 主机具有 IPv6 地址和 IPv6 路由,包括默认值。
流程
-
如果您还没有这样做,请在
/etc/microshift/目录中生成提供的config.yaml.default文件的副本,将它重命名为config.yaml。 将新的 MicroShift
config.yaml保留在/etc/microshift/目录中。MicroShift 服务每次启动时都会读取config.yaml文件。注意创建后,
config.yaml文件优先于内置设置。将 MicroShift YAML 的
network部分中的默认值替换为您的有效值。单堆栈 IPv6 网络配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令完成任何其他配置,然后启动 MicroShift:
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,检索节点资源中定义的网络:
oc get node -o jsonpath='{.items[].spec.podCIDRs[]}'$ oc get node -o jsonpath='{.items[].spec.podCIDRs[]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
fd01::/48
fd01::/48Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检索 pod 的状态:
oc get pod -A -o wide
$ oc get pod -A -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来检索服务的状态:
oc get svc -A
$ oc get svc -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. 在 MicroShift 启动前配置 IPv6 双栈网络 复制链接链接已复制到粘贴板!
您可以在启动该服务前,使用配置文件将 MicroShift 集群配置为在支持 IPv4 和 IPv6 地址系列的双栈网络上运行。
- 配置中的第一个 IP 系列是集群中的主要 IP 堆栈。
- 使用双栈网络运行集群后,通过重启双栈来为双栈启用应用程序 pod 和附加服务。
OVN-Kubernetes 网络插件要求 IPv4 和 IPv6 默认路由位于同一个网络设备中。不支持独立网络设备上的 IPv4 和 IPv6 默认路由。
当使用需要 IPv6 的双栈网络时,您无法使用 IPv4 映射 IPv6 地址,如 ::FFFF:198.51.100.1。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有对集群的 root 访问权限。
- 集群使用 OVN-Kubernetes 网络插件。
- 主机同时具有 IPv4 和 IPv6 地址和路由,包括每个地址的默认地址。
- 主机至少有两个 L3 网络,即 IPv4 和 IPv6。
流程
-
如果您还没有这样做,请在
/etc/microshift/目录中生成提供的config.yaml.default文件的副本,将它重命名为config.yaml。 将新的 MicroShift
config.yaml保留在/etc/microshift/目录中。MicroShift 服务每次启动时都会读取config.yaml文件。注意创建后,
config.yaml文件优先于内置设置。如果您还没有启动 MicroShift,请将 MicroShift YAML 的
network部分中的默认值替换为您的有效值。带有网络分配的双栈 IPv6 网络配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,完成任何其他 MicroShift 配置,然后启动 MicroShift:
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 根据需要重置应用 pod 和服务的 IP 系列策略,然后重新启动这些应用 pod 和服务,以启用双栈网络。如需简单示例,请参阅"为应用程序 pod 和服务重置 IP 系列策略"。
验证
您可以按照以下步骤验证所有系统服务和 pod 是否具有两个 IP 地址,每个系列一个:
运行以下命令,检索节点资源中定义的网络:
oc get pod -n openshift-ingress router-default-5b75594b4-w7w6s -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ingress router-default-5b75594b4-w7w6s -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[{"ip":"10.42.0.4"},{"ip":"fd01:0:0:1::4"}][{"ip":"10.42.0.4"},{"ip":"fd01:0:0:1::4"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检索主机网络 pod 定义的网络:
oc get pod -n openshift-ovn-kubernetes ovnkube-master-2fm2k -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ovn-kubernetes ovnkube-master-2fm2k -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}][{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. 将 MicroShift 集群迁移到 IPv6 双栈网络 复制链接链接已复制到粘贴板!
您可以通过在 MicroShift 配置文件中设置两个条目,将单堆栈集群转换为支持 IPv4 和 IPv6 地址系列的双栈网络。
- 配置中的第一个 IP 系列是集群中的主要 IP 堆栈。
- MicroShift 系统 pod 和服务会在 MicroShift 重启时自动更新。
- 在集群迁移到双栈网络并重启时,通过重启双栈网络来启用工作负载 pod 和服务。
OVN-Kubernetes 网络插件要求 IPv4 和 IPv6 默认路由位于同一个网络设备中。不支持独立网络设备上的 IPv4 和 IPv6 默认路由。
当使用需要 IPv6 的双栈网络时,您无法使用 IPv4 映射 IPv6 地址,如 ::FFFF:198.51.100.1。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有对集群的 root 访问权限。
- 集群使用 OVN-Kubernetes 网络插件。
- 主机同时具有 IPv4 和 IPv6 地址和路由,包括每个地址的默认地址。
- 主机至少有两个 L3 网络,即 IPv4 和 IPv6。
流程
-
如果您还没有这样做,请在
/etc/microshift/目录中生成提供的config.yaml.default文件的副本,将它重命名为config.yaml。 将新的 MicroShift
config.yaml保留在/etc/microshift/目录中。MicroShift 服务每次启动时都会读取config.yaml文件。注意创建后,
config.yaml文件优先于内置设置。使用您的有效值在 MicroShift YAML 的
network部分添加 IPv6 配置:警告您必须在重启和迁移后保留相同的第一个条目。对于任何迁移而言,这是正确的:单到双堆栈或双到单一堆栈。如果需要更改第一个条目,则需要完全擦除 etcd 数据库。这可能会导致应用程序数据丢失且不受支持。
-
使用您的有效值,在 MicroShift YAML 的
network部分为第二个网络添加 IPv6 配置。 将网络分配添加到 MicroShift
config.yaml的network部分,以启用将 IPv6 作为二级网络的双堆栈。带有网络分配的双栈 IPv6 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用您的有效值,在 MicroShift YAML 的
运行以下命令完成任何其他配置,然后重启 MicroShift:
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 根据需要重置应用 pod 和服务的 IP 系列策略,然后重新启动这些应用 pod 和服务,以启用双栈网络。如需简单示例,请参阅"为应用程序 pod 和服务重置 IP 系列策略"。
验证
您可以按照以下步骤验证所有系统服务和 pod 是否具有两个 IP 地址,每个系列一个:
运行以下命令,检索 pod 的状态:
oc get pod -A -o wide
$ oc get pod -A -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检索 OVN-K 网络插件定义的网络:
oc get pod -n openshift-ovn-kubernetes ovnkube-master-bltk7 -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ovn-kubernetes ovnkube-master-bltk7 -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}][{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,检索节点资源中定义的网络:
oc get pod -n openshift-ingress router-default-5b75594b4-228z7 -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ingress router-default-5b75594b4-228z7 -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
[{"ip":"10.42.0.3"},{"ip":"fd01:0:0:1::3"}][{"ip":"10.42.0.3"},{"ip":"fd01:0:0:1::3"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要返回单堆栈网络,您可以删除第二个条目到网络,并返回到在迁移到双栈网络之前配置的单个堆栈。
2.5. 为应用 Pod 和服务重置 IP 系列策略 复制链接链接已复制到粘贴板!
在将 MicroShift 配置更新为双栈网络后,PreferSingleStack 默认 ipFamilyPolicy 配置值不会自动更新。要在服务和应用程序 pod 中启用双栈网络,您必须更新 ipFamilyPolicy 值。
先决条件
-
您可以使用 MicroShift
config.yaml来定义带有 IPv6 地址系列的双栈网络。
流程
使用以下示例,将
spec.ipFamilyPolicy字段设置为服务或 pod 中双栈网络的有效值:服务的双栈网络配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必需。双栈网络的有效值为
PreferDualStack和RequireDualStack。设定的值取决于您应用程序的要求。PreferSingleStack是ipFamilyPolicy字段的默认值。
-
重启没有定义
hostNetwork的任何应用 pod。定义了hostNetwork的 Pod 不需要重启来更新ipFamilyPolicy值。
当 ipFamilyPolicy 值被更新时,MicroShift 系统服务和 pod 会被自动更新。
2.6. OVN-Kubernetes IPv6 和双栈限制 复制链接链接已复制到粘贴板!
OVN-Kubernetes 网络插件有以下限制:
对于为双栈网络配置的集群,IPv4 和 IPv6 流量都必须使用与默认网关相同的网络接口。如果不满足此要求,则
ovnkube-node守护进程集中的主机上的容器集进入CrashLoopBackOff状态。如果您使用oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml等命令显示 pod,则status字段包含多个有关默认网关的消息,如以下输出所示:I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一的解析是重新配置主机网络,以便两个 IP 系列都针对默认网关使用相同的网络接口。
对于为双栈网络配置的集群,IPv4 和 IPv6 路由表必须包含默认网关。如果不满足此要求,则
ovnkube-node守护进程集中的主机上的容器集进入CrashLoopBackOff状态。如果您使用oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml等命令显示 pod,则status字段包含多个有关默认网关的消息,如以下输出所示:I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interface
I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interfaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一的解析是重新配置主机网络,以便两个 IP 系列都包含默认网关。
第 3 章 为 MicroShift 集群使用入口控制 复制链接链接已复制到粘贴板!
使用 MicroShift 配置文件中的 ingress 控制器选项,使 pod 和服务可以被集群外部访问。
3.1. 在 MicroShift 中使用入口控制 复制链接链接已复制到粘贴板!
在创建 MicroShift 集群时,集群中运行的每个 pod 和服务都会分配一个 IP 地址。默认情况下,这些 IP 地址可以被其他 pod 和服务访问,但外部客户端无法访问。MicroShift 使用 OpenShift Container Platform IngressController API 的最小实现来启用对集群服务的外部访问。
通过更多配置选项,您可以微调 ingress 来满足特定的需求。要使用增强的入口控制,请更新 MicroShift 配置文件中的参数并重启该服务。Ingress 配置以多种方式很有用,例如:
-
如果您的应用程序开始处理来自客户端的请求,但可以在响应前关闭连接,您可以将配置文件中的
ingress.tuningOptions.serverTimeout参数设置为更高的值,以容纳来自服务器的响应速度。 -
如果路由器有很多连接打开,因为集群中运行的应用程序没有正确关闭连接,您可以将
ingress.tuningOptions.serverTimeout和spec.tuningOptions.serverFinTimeout参数设置为较低值,强制这些连接更早。
3.2. 在 MicroShift 中配置入口控制 复制链接链接已复制到粘贴板!
您可以通过更新 MicroShift 服务配置文件来使用详细的入口控制设置。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有对集群的 root 访问权限。
- 集群使用 OVN-Kubernetes 网络插件。
流程
使用以下两种方式之一应用入口控制设置:
通过在
/etc/microshift/目录中生成提供的文件的副本,将其命名为 config.yaml 并将其保留在源目录中,来更新 MicroShiftconfig.yaml.defaultconfig.yaml配置文件。-
创建后,
config.yaml文件优先于内置设置。每次 MicroShift 服务启动时都会读取配置文件。
-
创建后,
使用配置片段应用您想要的 ingress 控制设置。要做到这一点,创建一个配置片断 YAML 文件,并将其放在
/etc/microshift/config.d/配置中。-
配置片断 YAML 优先于内置设置和
config.yaml配置文件。如需更多信息,请参阅附加资源链接。
-
配置片断 YAML 优先于内置设置和
将 MicroShift YAML 的
network部分中的默认值替换为您的有效值,或将配置片断文件替换为您需要的部分。带有默认值的 Ingress 控制器配置字段
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表 3.1. Ingress 控制器配置字段定义表 参数 描述 defaultHTTPVersion为入口控制器设置 HTTP 版本。HTTP 1.1 的默认值为
1。forwardedHeaderPolicy指定入口控制器何时和如何设置 Forwarded ,
X-,Forwarded-ForX-Forwarded-Host,X-Forwarded-Port,X-Forwarded-Proto, 和X-Forwarded-Proto-VersionHTTP 标头。以下值有效:-
附加,通过指定入口控制器附加它们来保留任何现有的标头。 -
替换,通过指定入口控制器设置标头来删除任何现有标头。 -
IfNone通过指定入口控制器设置标头(如果未设置标头)来设置标头。 -
永不,通过指定 ingress 控制器永远不会设置标头来保留任何现有的标头。
httpCompression定义 HTTP 流量压缩的策略。
-
httpCompression.mimeTypes定义压缩应用到的单个 MIME 类型列表。例如,text/css; charset=utf-8,text/html,text/*,image/svg+xml,application/octet-stream,X-custom/customsub,格式为type/subtype; [;attribute=value]。类型包括:application, image, message, multipart, text, video, 或一个自定义类型,前是X-。要查看 MIME 类型和子类型的完整表示法,请参阅 RFC1341 (IETF Datatracker 文档)。
httpEmptyRequestsPolicy描述在收到请求前连接超时时如何处理 HTTP 连接。此字段允许的值是
Respond和Ignore。默认值为Respond。以下是有效值:-
响应,会导致入口控制器发送 HTTP400或408响应,在启用了访问日志时记录连接,并在适当的指标中统计连接。 -
忽略,在HAproxy配置中添加http-ignore-probes参数。如果字段设置为Ignore,则入口控制器在不发送响应的情况下关闭连接,然后记录连接或递增指标。
通常,空请求连接来自负载均衡器健康探测或 Web 浏览器预先连接,可以安全地忽略。但是,网络错误和端口扫描也可以创建这些空请求,因此将此字段设置为
Ignore可能会妨碍检测或诊断问题,并妨碍入侵尝试检测。logEmptyRequests指定没有接收和记录请求的连接。通常,这些空请求来自负载均衡器健康探测或 Web 浏览器规范连接,如 preconnects。记录这些类型的空请求是不正常的。但是,网络错误和端口扫描也可以创建空请求,因此将此字段设置为
Ignore可能会妨碍检测或诊断问题,并妨碍入侵尝试检测。以下是有效值:
-
日志,表示应记录事件。 -
忽略,该选项在HAproxy配置中设置dontlognull选项。
tuningOptions指定用于调整入口控制器 pod 性能的选项。
-
tuningOptions.clientFinTimeout参数指定连接在等待客户端响应关闭连接时保持打开的时长。默认超时为1s。 -
tuningOptions.clientTimeout参数指定连接在等待客户端响应时保持打开的时长。默认超时为30s。 tuningOptions.headerBufferBytes参数指定为 Ingress Controller 连接会话保留多少内存(以字节为单位)。如果为 Ingress Controller 启用了 HTTP/2,则必须至少为16384。如果没有设置,则默认值为32768字节。重要不建议设置此字段,因为
headerBufferMaxRewriteBytes参数值太小可能会破坏入口控制器。相反,headerBufferMaxRewriteBytes的值太大可能会导致入口控制器使用比必要更多的内存。-
tuningOptions.headerBufferMaxRewriteBytes参数指定从headerBufferBytes为 HTTP 标头重写和附加 Ingress Controller 连接会话应保留多少内存(以字节为单位)。headerBufferMaxRewriteBytes的最小值是4096。headerBufferBytes值必须大于传入的 HTTP 请求的headerBufferMaxRewriteBytes值。 如果没有设置,则默认值为
8192字节。重要不建议设置此字段,因为
headerBufferMaxRewriteBytes参数值太小可能会破坏入口控制器。相反,headerBufferMaxRewriteBytes的值太大可能会导致入口控制器使用比必要更多的内存。-
tuningOptions.healthCheckInterval参数指定路由器在健康检查之间等待的时间。默认值为5s。 -
tuningOptions.serverFinTimeout参数指定连接在等待服务器响应关闭连接时保持打开的时长。默认超时为1s。 -
tuningOptions.serverTimeout参数指定连接在等待服务器响应时保持打开的时长。默认超时为30s。 tuningOptions.threadCount参数指定每个 HAProxy 进程创建的线程数量。创建更多线程可让每个入口控制器 pod 处理更多连接,而代价会增加所使用的系统资源。HAProxy支持最多64个线程。如果此字段为空,则默认值为4个线程。重要不建议设置此字段,因为增加
HAProxy线程数量允许入口控制器 pod 在负载下使用更多 CPU 时间,并防止其他 pod 接收需要执行的 CPU 资源。-
tuningOptions.tlsInspectDelay参数指定路由器可以保存数据以查找匹配的路由的时间。将此值设置为太短可能会导致路由器回退到边缘终止、重新加密或透传路由的默认证书,即使在使用更好匹配的证书时也是如此。默认检查延迟为5s。 -
tuningOptions.tunnelTimeout参数指定隧道连接(包括 websocket)在隧道闲置时保持打开的时长。默认超时为1h。
-
运行以下命令完成任何其他配置,然后启动或重启 MicroShift:
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
在进行 ingress 配置更改并重启 MicroShift 后,您可以检查路由器 Pod 的年龄,以确保应用了更改。
要检查路由器 pod 的状态,请运行以下命令:
oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE router-default-8649b5bf65-w29cn 1/1 Running 0 6m10s
NAME READY STATUS RESTARTS AGE router-default-8649b5bf65-w29cn 1/1 Running 0 6m10sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 4 章 使用 kubeconfig 进行集群访问 复制链接链接已复制到粘贴板!
了解如何将 kubeconfig 文件用于 MicroShift 部署。CLI 工具使用 kubeconfig 文件与集群的 API 服务器通信。这些文件提供身份验证所需的集群详情、IP 地址和其他信息。
4.1. 用于配置集群访问的 kubeconfig 文件 复制链接链接已复制到粘贴板!
MicroShift 中使用的两个 kubeconfig 文件是本地访问和远程访问。每次 MicroShift 启动时,都会生成一组用于本地和远程访问 API 服务器的 kubeconfig 文件。这些文件在 /var/lib/microshift/resources/kubeadmin/ 目录中生成,使用预先存在的配置信息。
每种访问类型都需要使用不同的证书颁发机构(CA)签名的证书。生成一个多个 kubeconfig 文件可满足这一需求。
您可以将适当的 kubeconfig 文件用于每个情况下所需的访问类型,以提供身份验证详情。MicroShift kubeconfig 文件的内容由默认的内置值或 config.yaml 文件决定。
必须存在一个 kubeconfig 文件,集群才能被访问。这些值从内置默认值或 config.yaml (如果创建)应用。
kubeconfig 文件的内容
4.2. 本地访问 kubeconfig 文件 复制链接链接已复制到粘贴板!
本地访问 kubeconfig 文件被写入 /var/lib/microshift/resources/kubeadmin/kubeconfig。此 kubeconfig 文件提供对使用 localhost 的 API 服务器的访问。当您在本地连接集群时,选择这个文件。
用于本地访问的 kubeconfig 内容示例
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://localhost:6443
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://localhost:6443
localhost kubeconfig 文件只能从从同一主机连接到 API 服务器的客户端中使用。文件中的证书不适用于远程连接。
4.2.1. 本地访问 MicroShift 集群 复制链接链接已复制到粘贴板!
使用以下步骤,使用 kubeconfig 文件在本地访问 MicroShift 集群。
先决条件
-
已安装
oc二进制文件。
流程
可选:如果您的 Red Hat Enterprise Linux (RHEL)机器没有
~/.kube/文件夹,请运行以下命令:mkdir -p ~/.kube/
$ mkdir -p ~/.kube/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将生成的本地访问
kubeconfig文件复制到~/.kube/目录中:sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
$ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令更新
~/.kube/config文件的权限:chmod go-r ~/.kube/config
$ chmod go-r ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令验证 MicroShift 是否正在运行:
oc get all -A
$ oc get all -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.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
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://microshift-rhel9:6443
4.3.1. 远程访问自定义 复制链接链接已复制到粘贴板!
可以生成多个远程访问 kubeconfig 文件值来访问使用不同 IP 地址或主机名的集群。额外的 kubeconfig 文件会为 apiServer.subjectAltNames 参数中的每个条目生成。您可以在 IP 连接时从主机复制远程访问 kubeconfig 文件,然后使用它们从其他工作站访问 API 服务器。
4.4. 为远程访问生成额外的 kubeconfig 文件 复制链接链接已复制到粘贴板!
如果您需要比默认远程访问文件提供更多的主机名或 IP 地址,您可以生成额外的 kubeconfig 文件。
您必须重启 MicroShift 才能实现配置更改。
先决条件
-
您已为 MicroShift 创建了
config.yaml。
流程
可选:您可以显示
config.yaml的内容。运行以下命令:cat /etc/microshift/config.yaml
$ cat /etc/microshift/config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:您可以显示远程访问
kubeconfig文件的内容。运行以下命令:cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
$ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要其他远程访问
kubeconfig文件必须包含 MicroShiftconfig.yaml文件中列出的服务器名称之一。其他kubeconfig文件还必须使用相同的 CA 进行验证。要为其他 DNS 名称 SAN 或外部 IP 地址生成额外的
kubeconfig文件,请将您需要的条目添加到apiServer.subjectAltNames字段。在以下示例中,使用的 DNS 名称为alt-name-1,IP 地址为1.2.3.4。带有额外身份验证值的
config.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,重启 MicroShift 以应用配置更改并自动生成您需要的
kubeconfig文件:sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要检查其他远程访问
kubeconfig文件的内容,请将config.yaml中列出的名称或 IP 地址插入到cat命令中。例如,以下示例命令中使用alt-name-1:cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
$ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 选择
kubeconfig文件,其中包含您要用来连接集群的 SAN 或 IP 地址。在本例中,cluster.server字段中包含'alt-name-1' 的kubeconfig是正确的文件。额外
kubeconfig文件的内容clusters: - cluster: certificate-authority-data: <base64 CA> server: https://alt-name-1:6443clusters: - cluster: certificate-authority-data: <base64 CA> server: https://alt-name-1:64431 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig文件值来自apiServer.subjectAltNames配置值。
所有这些参数都作为通用名称(CN)和主题替代名称(SAN)包含在 API 服务器的外部提供证书中。
4.4.1. 打开防火墙以远程访问 MicroShift 集群 复制链接链接已复制到粘贴板!
使用以下步骤打开防火墙,以便远程用户可以访问 MicroShift 集群。必须在 workstation 用户可以访问集群前完成此步骤。
对于此过程,user@microshift 是 MicroShift 主机上的用户,负责设置该机器,使其可以被单独的工作站上的远程用户访问。
先决条件
-
已安装
oc二进制文件。 - 您的帐户具有集群管理特权。
流程
在 MicroShift 主机上以
user@microshift的身份,运行以下命令来打开 Kubernetes API 服务器的防火墙端口 (6443/tcp):sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
[user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
以
user@microshift的身份,输入以下命令验证 MicroShift 是否正在运行:oc get all -A
[user@microshift]$ oc get all -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2. 远程访问 MicroShift 集群 复制链接链接已复制到粘贴板!
使用以下步骤,使用 kubeconfig 文件从远程位置访问 MicroShift 集群。
user@workstation 登录用于远程访问主机计算机。该流程中的 <user> 值是 user@workstation 登录到 MicroShift 主机所使用的用户名。
先决条件
-
已安装
oc二进制文件。 -
user@microshift已打开来自本地主机的防火墙。
流程
以
user@workstation的身份,如果 Red Hat Enterprise Linux (RHEL)机器没有,使用以下命令创建一个~/.kube/文件夹:mkdir -p ~/.kube/
[user@workstation]$ mkdir -p ~/.kube/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以
user@workstation的身份,运行以下命令来为您的 MicroShift 主机的主机名设置变量:MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以
user@workstation的身份,运行以下命令来复制生成的kubeconfig文件,该文件包含您要从运行 MicroShift 的 RHEL 机器连接到本地机器的主机名或 IP 地址:ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意要为此步骤生成
kubeconfig文件,请参阅为远程访问生成额外的 kubeconfig 文件。以
user@workstation的身份,运行以下命令来更新~/.kube/config文件的权限:chmod go-r ~/.kube/config
$ chmod go-r ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
以
user@workstation的身份,输入以下命令验证 MicroShift 是否正在运行:oc get all -A
[user@workstation]$ oc get all -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 5 章 配置自定义证书颁发机构 复制链接链接已复制到粘贴板!
您可以在 MicroShift 服务使用自定义证书颁发机构(CA)来加密连接。
5.1. 自定义证书颁发机构在 MicroShift 中的工作方式 复制链接链接已复制到粘贴板!
默认 API 服务器证书由内部 MicroShift 集群证书颁发机构(CA)发布。默认情况下,集群外的客户端无法验证 API 服务器证书。此证书可以替换为外部由客户端信任的自定义 CA 发布的自定义服务器证书。以下步骤演示了 MicroShift 中的工作流:
- 将证书和密钥复制到主机操作系统中的首选目录中。确保只有 root 用户可以访问这些文件。
通过在 MicroShift
/etc/microshift/config.yaml配置文件中指定证书名称和新的完全限定域名(FQDN)来更新每个自定义 CA 的 MicroShift 配置。每个证书配置都可以包含以下值:
- 证书文件位置是一个必需的值。
包含 API 服务器 DNS 和 IP 地址或 IP 地址范围的一个通用名称。
提示在大多数情况下,MicroShift 为自定义 CA 生成新的
kubeconfig,其中包含您指定的 IP 地址或范围。例外是在为 IP 地址指定通配符时。在这种情况下,MicroShift 会生成一个kubeconfig,其中包含服务器的公共 IP 地址。要使用通配符,您必须使用特定详情更新kubeconfig文件。- 多个主题备用名称(SAN),其中包含 API 服务器 DNS 和 IP 地址或通配符证书。
- 您可以为每个证书提供额外的 DNS 名称。
-
MicroShift 服务重启后,您必须将生成的
kubeconfig文件复制到客户端。 - 在客户端系统上配置额外的 CA。例如,您可以更新 Red Hat Enterprise Linux (RHEL)信任存储中的 CA 捆绑包。
- 证书和密钥从主机上的指定文件位置读取。配置测试和验证通过客户端完成。
- 外部服务器证书不会自动续订。您必须手动轮转外部证书。
如果任何验证失败,MicroShift 服务会跳过自定义配置,并使用默认证书启动。优先级是继续服务不间断。MicroShift 在服务启动时记录错误。常见错误包括过期的证书、缺失的文件或不正确的 IP 地址。
自定义服务器证书必须针对主机操作系统信任根中配置的 CA 数据进行验证。如需更多信息,请参阅 系统范围的信任存储。
5.2. 配置自定义证书颁发机构 复制链接链接已复制到粘贴板!
要使用自定义证书颁发机构(CA)配置外部生成的证书和域名,请将它们添加到 MicroShift /etc/microshift/config.yaml 配置文件中。您还必须配置主机操作系统信任 root。
外部生成的 kubeconfig 文件在 /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig 目录中创建。如果您需要在外部生成的配置之外使用 localhost,请在其默认位置保留原始 kubeconfig 文件。localhost kubeconfig 文件使用自签名证书颁发机构。
先决条件
-
已安装 OpenShift CLI (
oc)。 - 您可以使用具有集群管理角色的用户访问集群。
- 证书颁发机构已发布自定义证书。
-
MicroShift
/etc/microshift/config.yaml配置文件存在。
流程
- 复制您要添加到 MicroShift 主机的信任根中的自定义证书。确保证书和私钥只能被 MicroShift 访问。
对于您需要的每个自定义 CA,使用以下示例
将名为Certificates 的apiServer部分添加到/etc/microshift/config.yamlMicroShift 配置文件中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,重启 {microshift-service} 以应用证书:
systemctl microshift restart
$ systemctl microshift restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
等待几分钟,让系统重新启动并应用自定义服务器。新的
kubeconfig文件在/var/lib/microshift/resources/kubeadmin/目录中生成。 -
将
kubeconfig文件复制到客户端。如果您为 IP 地址指定了通配符,请更新kubeconfig以删除服务器的公共 IP 地址,并使用您要使用的特定通配符范围替换该 IP 地址。 在客户端中,执行以下步骤:
运行以下命令指定要使用的
kubeconfig:export KUBECONFIG=~/custom-kubeconfigs/kubeconfig
$ export KUBECONFIG=~/custom-kubeconfigs/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用复制的
kubeconfig文件的位置作为路径。
使用以下命令检查是否应用了证书:
oc --certificate-authority ~/certs/ca.ca get node
$ oc --certificate-authority ~/certs/ca.ca get nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
oc get node NAME STATUS ROLES AGE VERSION dhcp-1-235-195.arm.example.com Ready control-plane,master,worker 76m v1.30.3
oc get node NAME STATUS ROLES AGE VERSION dhcp-1-235-195.arm.example.com Ready control-plane,master,worker 76m v1.30.3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将新 CA 文件添加到 $KUBECONFIG 环境变量中:
oc config set clusters.microshift.certificate-authority /tmp/certificate-authority-data-new.crt
$ oc config set clusters.microshift.certificate-authority /tmp/certificate-authority-data-new.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,验证新的
kubeconfig文件是否包含新的 CA:oc config view --flatten
$ oc config view --flattenCopy to Clipboard Copied! Toggle word wrap Toggle overflow 外部生成的
kubeconfig文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 外部生成的
kubeconfig文件中不存在certificate-authority-data部分。它通过之前使用的oc config set命令添加。
运行以下命令,验证自定义 API 服务器证书颁发机构的
主题和签发者:curl --cacert /tmp/caCert.pem https://${fqdn_name}:6443/healthz -v$ curl --cacert /tmp/caCert.pem https://${fqdn_name}:6443/healthz -vCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要将生成的
kubeconfig文件中的certificate-authority-data替换为新的rootCA,或者将certificate-authority-data添加到操作系统的信任根中。不要同时使用这两种方法。在操作系统的信任根中配置额外的 CA。例如,在客户端系统上的 RHEL 客户端信任存储中。详情请查看 系统范围的信任存储。
- 建议使用包含 CA 的配置更新证书捆绑包。
-
如果您不想配置证书捆绑包,也可以使用
oc login localhost:8443 --certificate-authority=/path/to/cert.crt命令,但这不是首选的方法。
5.3. 自定义证书保留名称值 复制链接链接已复制到粘贴板!
以下证书问题会导致 MicroShift 动态忽略证书并记录错误:
- 磁盘中不存在证书文件或不可读。
- 证书不可解析。
-
证书会覆盖
SubjectAlternativeNames(SAN)字段中的内部证书 IP 地址或 DNS 名称。在配置 SAN 时不要使用保留的名称。
| 地址 | 类型 | 注释 |
|---|---|---|
|
| DNS | |
|
| IP 地址 | |
|
| IP 地址 | 集群网络 |
|
| IP 地址 | 服务网络 |
| 169.254.169.2/29 | IP 地址 | br-ex Network |
|
| DNS | |
|
| DNS | |
|
| DNS |
5.4. 自定义证书故障排除 复制链接链接已复制到粘贴板!
要排除自定义证书的实施,您可以执行以下步骤。
流程
在 MicroShift 中,确保证书由
kube-apiserver提供,并通过运行以下命令来验证证书路径是否已附加到 the-tls-sni-cert-keyFLAG 中:journalctl -u microshift -b0 | grep tls-sni-cert-key
$ journalctl -u microshift -b0 | grep tls-sni-cert-keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Jan 24 14:53:00 localhost.localdomain microshift[45313]: kube-apiserver I0124 14:53:00.649099 45313 flags.go:64] FLAG: --tls-sni-cert-key="[/home/eslutsky/dev/certs/server.crt,/home/eslutsky/dev/certs/server.key;/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.key;/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.key;/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.key
Jan 24 14:53:00 localhost.localdomain microshift[45313]: kube-apiserver I0124 14:53:00.649099 45313 flags.go:64] FLAG: --tls-sni-cert-key="[/home/eslutsky/dev/certs/server.crt,/home/eslutsky/dev/certs/server.key;/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.key;/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.key;/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端中,运行以下命令来确保
kube-apiserver提供正确的证书:openssl s_client -connect <SNI_ADDRESS>:6443 -showcerts | openssl x509 -text -noout -in - | grep -C 1 "Alternative\|CN"
$ openssl s_client -connect <SNI_ADDRESS>:6443 -showcerts | openssl x509 -text -noout -in - | grep -C 1 "Alternative\|CN"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. 清理和重新创建自定义证书 复制链接链接已复制到粘贴板!
要停止 MicroShift 服务,请清理自定义证书并重新创建自定义证书,请使用以下步骤。
流程
运行以下命令,停止 MicroShift 服务并清理自定义证书:
sudo microshift-cleanup-data --cert
$ sudo microshift-cleanup-data --certCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Stopping MicroShift services Removing MicroShift certificates MicroShift service was stopped Cleanup succeeded
Stopping MicroShift services Removing MicroShift certificates MicroShift service was stopped Cleanup succeededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令重启 MicroShift 服务以重新创建自定义证书:
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6. 其他资源 复制链接链接已复制到粘贴板!
第 6 章 检查 greenboot 脚本状态 复制链接链接已复制到粘贴板!
要使用 kustomize 清单以外的工具通过 MicroShift API 部署应用程序或进行其他更改,您必须等待 greenboot 健康检查完成。这可确保,如果 greenboot 将 rpm-ostree 系统回滚回较早的状态,您的更改不会丢失。
greenboot-healthcheck 服务运行一次,然后退出。在 greenboot 退出并且系统处于健康状态后,您可以继续配置更改和部署。
6.1. 检查 greenboot 健康检查的状态 复制链接链接已复制到粘贴板!
在对系统进行更改或故障排除期间,检查 greenboot 健康检查的状态。您可以使用以下任一命令来帮助确保 greenboot 脚本已完成运行。
流程
要查看健康检查状态的报告,请使用以下命令:
systemctl show --property=SubState --value greenboot-healthcheck.service
$ systemctl show --property=SubState --value greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
start的输出表示 greenboot 检查仍在运行。 -
退出的输出表示检查已通过,reenboot 已退出。当系统处于健康状态时,greenboot 在green.d目录中运行脚本。 -
失败的输出表示检查尚未通过。greenboot 在系统处于此状态时在red.d目录中运行脚本,并可能重启系统。
-
要查看一个报告显示服务的数字退出代码,其中
0表示成功,非零值表示发生了失败,请使用以下命令:systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要查看显示引导状态的报告,如
Boot Status 为 GREEN - Health Check SUCCESS,请使用以下命令:cat /run/motd.d/boot-status
$ cat /run/motd.d/boot-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 7 章 配置审计日志记录策略 复制链接链接已复制到粘贴板!
您可以使用配置值控制 MicroShift 审计日志文件轮转和保留。
7.1. 关于设置审计日志文件的限制 复制链接链接已复制到粘贴板!
使用配置值控制 MicroShift 审计日志文件的轮转和保留有助于防止超过边缘设备的有限存储容量。在这样的设备中,日志记录数据积累可能会限制主机系统或集群工作负载,从而导致设备停止工作。设置审计日志策略有助于确保关键处理空间持续可用。
您设置为限制 MicroShift 审计日志的值可让您强制实施审计日志备份的大小、数字和年龄限制。字段值相互独立处理,无需优先处理。
您可以组合设置字段,为保留的日志定义最大存储限制。例如:
-
将
maxFileSize和maxFiles设置为创建一个日志存储上限。 -
设置
maxFileAge值,以自动删除文件名中时间戳旧的文件,而不考虑maxFiles值。
7.1.1. 默认审计日志值 复制链接链接已复制到粘贴板!
MicroShift 包括以下默认审计日志轮转值:
| 审计日志参数 | 默认设置 | 定义 |
|---|---|---|
|
|
| 在自动删除前保留日志文件的时长。默认值表示,日志文件永远不会根据年龄删除。可以配置这个值。 |
|
|
| 保留的日志文件总数。默认情况下,MicroShift 保留 10 个日志文件。创建过量文件时,会删除最旧的文件。可以配置这个值。 |
|
|
|
默认情况下,当 |
|
|
|
|
如果文件有 10 个或更少,则审计日志保留的最大默认存储使用量为 2000Mb。
如果没有为字段指定值,则使用默认值。如果删除了之前设置的字段值,则会在下一个 MicroShift 服务重启后恢复默认值。
您必须在 Red Hat Enterprise Linux (RHEL)中为应用程序 Pod 生成的日志配置审计日志保留和轮转。这些日志打印到控制台并被保存。确保为 RHEL /var/log/audit/audit.log 文件配置了日志首选项,以维护 MicroShift 集群健康状况。
其他资源
- 为安全环境配置 auditd
- 了解审计日志文件
- 如何使用 logrotate 工具轮转日志文件 (Solutions,自 2024 年 8 月 7 日)
7.2. 关于审计日志策略配置集 复制链接链接已复制到粘贴板!
审计日志配置集定义如何记录发送到 OpenShift API 服务器和 Kubernetes API 服务器的请求。
MicroShift 支持以下预定义的审计策略配置集:
| profile | 描述 |
|---|---|
|
| 仅记录读取和写入请求的日志元数据 ;除了 OAuth 访问令牌请求外,不记录请求正文。这是默认策略。 |
|
|
除了记录所有请求的元数据外,还会记录对 API 服务器的写入请求( |
|
|
除了记录所有请求的元数据外,对 API 服务器的每个读写请求( |
|
| 没有记录请求,包括 OAuth 访问令牌请求和 OAuth 授权令牌请求。 警告
除非完全了解在对问题进行故障排除时无法记录数据的风险,否则不要使用 |
-
敏感资源(如
Secret、Route和OAuthClient对象)仅记录在元数据级别上。
默认情况下,MicroShift 使用 Default 审计日志配置集。您可以使用另一个审计策略配置集来记录请求的具体数据,但注意这会消耗更多资源(如 CPU、内存和 I/O)。
7.3. 配置审计日志值 复制链接链接已复制到粘贴板!
您可以使用 MicroShift 服务配置文件配置审计日志设置。
流程
-
在
/etc/microshift/目录中生成提供的config.yaml.default文件的副本,将它重命名为config.yaml。在/etc/microshift/目录中保留您创建的新的 MicroShiftconfig.yaml。每当 MicroShift 服务启动时,会读取新的config.yaml。创建后,config.yaml文件优先于内置设置。 将 YAML 的
auditLog部分中的默认值替换为您所需的有效值。默认
auditLog配置示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定日志文件要保留的最大时间(以天为单位)。超过这个限制的文件会被删除。在本例中,日志文件超过 7 天后,将被删除。无论实时日志是否达到
maxFileSize字段中指定的最大文件大小,都会删除这些文件。文件年龄由使用轮转日志文件名称写入的时间戳决定,例如audit-2024-05-16T17-03-59.994.log。当值为0时,会禁用限制。 - 2
- 最大审计日志文件大小(以 MB 为单位)。在本例中,文件会在实时日志达到 200 MB 限制时进行轮转。当值设为
0时,会禁用限制。 - 3
- 保留的最大轮转审计日志文件数。达到限制后,日志文件将从最旧的到最新的顺序删除。在本例中,除了当前活跃日志外,值
1会导致只保留 1 个 sizemaxFileSize的文件。当值设为0时,会禁用限制。 - 4
- 仅记录读取和写入请求的日志元数据 ;除了 OAuth 访问令牌请求外,不记录请求正文。如果没有指定此字段,则使用
Default配置集。
可选: 要为日志指定新目录,您可以停止 MicroShift,然后将
/var/log/kube-apiserver目录移到所需的位置:运行以下命令来停止 MicroShift:
sudo systemctl stop microshift
$ sudo systemctl stop microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将
/var/log/kube-apiserver目录移到所需位置:sudo mv /var/log/kube-apiserver <~/kube-apiserver>
$ sudo mv /var/log/kube-apiserver <~/kube-apiserver>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将 <
~/kube-apiserver> 替换为您要使用的目录的路径。
如果为日志指定新目录,请运行以下命令到位于
/var/log/kube-apiserver的自定义目录:sudo ln -s <~/kube-apiserver> /var/log/kube-apiserver
$ sudo ln -s <~/kube-apiserver> /var/log/kube-apiserver1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将 <
~/kube-apiserver> 替换为您要使用的目录的路径。这启用了 sos 报告中的日志集合。
如果要在运行的实例上配置审计日志策略,请输入以下命令重启 MicroShift:
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. 审计日志配置故障排除 复制链接链接已复制到粘贴板!
使用以下步骤对自定义审计日志设置和文件位置进行故障排除。
流程
运行以下命令检查配置的当前值:
sudo microshift show-config --mode effective
$ sudo microshift show-config --mode effectiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
auditLog: maxFileSize: 200 maxFiles: 1 maxFileAge: 7 profile: AllRequestBodiesauditLog: maxFileSize: 200 maxFiles: 1 maxFileAge: 7 profile: AllRequestBodiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令检查
audit.log文件权限:sudo ls -ltrh /var/log/kube-apiserver/audit.log
$ sudo ls -ltrh /var/log/kube-apiserver/audit.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
-rw-------. 1 root root 46M Mar 12 09:52 /var/log/kube-apiserver/audit.log
-rw-------. 1 root root 46M Mar 12 09:52 /var/log/kube-apiserver/audit.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,列出当前日志目录的内容:
sudo ls -ltrh /var/log/kube-apiserver/
$ sudo ls -ltrh /var/log/kube-apiserver/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
total 6.0M -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-16.267.log -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-49.444.log -rw-------. 1 root root 962K Mar 12 10:57 audit.log
total 6.0M -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-16.267.log -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-49.444.log -rw-------. 1 root root 962K Mar 12 10:57 audit.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 8 章 禁用 LVMS CSI 供应商或 CSI 快照 复制链接链接已复制到粘贴板!
您可以将 MicroShift 配置为禁用内置逻辑卷管理器存储(LVMS) Container Storage Interface (CSI)供应商或 CSI 快照功能,以减少运行时资源的使用,如 RAM、CPU 和存储。
8.1. 禁用运行 CSI 快照实现的部署 复制链接链接已复制到粘贴板!
使用以下步骤禁用 CSI 实现 pod 的安装。
此流程适用于在安装和运行 MicroShift 前定义配置文件的用户。如果 MicroShift 已启动,则 CSI 快照实现将正在运行。用户必须按照卸载说明手动删除它。
MicroShift 不会删除 CSI 快照实现 pod。您必须将 MicroShift 配置为在引导过程中禁用 CSI 快照实现 pod 的安装。
流程
通过在
/etc/microshift/config.yaml中的 MicroShift 配置文件的storage部分下输入optionalCsiComponents值来禁用 CSI 快照控制器的安装:# ... storage: {} # ...# ... storage: {}1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 接受的值是:
-
没有定义
可选CsiComponents。 -
使用空值(
[])或单个空字符串元素([""])指定optionalCsiComponents字段。 使用
snapshot-controller、snapshot-webhook或none值之一指定可选CsiComponents。none与所有其他值相互排斥。注意如果
optionalCsiComponents值为空或 null,MicroShift 默认为部署 snapshot-controller 和 snapshot-webhook。
-
没有定义
使用
config.yaml中的支持值指定optionalCsiComponents字段后,运行以下命令启动 MicroShift:sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意MicroShift 重启后不会重新部署禁用的组件。
8.2. 禁用运行 CSI 驱动程序实现的部署 复制链接链接已复制到粘贴板!
使用以下步骤禁用 CSI 实现 pod 的安装。
此流程适用于在安装和运行 MicroShift 前定义配置文件的用户。如果 MicroShift 已启动,则 CSI 驱动程序实现将正在运行。用户必须按照卸载说明手动删除它。
MicroShift 不会删除 CSI 驱动程序实现 pod。您必须将 MicroShift 配置为在引导过程中禁用 CSI 驱动程序实现 pod 的安装。
流程
通过在
/etc/microshift/config.yaml中的 MicroShift 配置文件的storage部分输入驱动程序值来禁用 CSI 驱动程序的安装:# ... storage driver: - "none" # ...
# ... storage driver: - "none"1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 有效值为
none或lvms。
注意默认情况下,
驱动程序值为空或 null,其中 LVMS 被部署。运行以下命令,在
driver字段指定了/etc/microshift/config.yaml文件中的支持值后启动 MicroShift:sudo systemctl enable --now microshift
$ sudo systemctl enable --now microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意MicroShift 在重启操作后不会重新部署禁用的组件。
第 9 章 配置低延迟 复制链接链接已复制到粘贴板!
9.1. 配置低延迟 复制链接链接已复制到粘贴板!
您可以配置和调优低延迟功能,以提高边缘设备上的应用程序性能。
9.1.1. 在 MicroShift 应用程序中降低延迟 复制链接链接已复制到粘贴板!
延迟定义为事件到该事件的响应的时间。您可以在在操作或软件定义的控制系统上运行的 MicroShift 集群中使用低延迟配置和调优,其中边缘设备需要快速响应外部事件。您可以通过将 MicroShift 配置与操作系统调优和工作负载分区结合使用来完全优化低延迟性能。
为管理应用程序设置的 CPU,如 MicroShift 服务、OVS、CRI-O、MicroShift pod 和隔离内核必须包含 all-online CPU。
9.1.1.1. 为 MicroShift 应用程序配置低延迟的工作流 复制链接链接已复制到粘贴板!
要为在 MicroShift 集群中运行的应用程序配置低延迟,您必须完成以下任务:
- 必填
-
安装
microshift-low-latencyRPM。 - 配置工作负载分区。
-
在
/etc/microshift/目录中配置config.yaml文件的kubelet部分。 - 配置并激活 TuneD 配置集。TuneD 是一个 Red Hat Enterprise Linux (RHEL)服务,它监控主机系统并优化特定工作负载的性能。
- 重启主机。
-
安装
- 选填
- 如果使用 x86_64 架构,您可以安装 Red Hat Enterprise Linux for Real Time 9。
9.1.2. 安装 MicroShift 低延迟 RPM 软件包 复制链接链接已复制到粘贴板!
安装 MicroShift 时,默认不会安装低延迟 RPM 软件包。您可以将低延迟 RPM 安装为可选软件包。
先决条件
- 已安装 MicroShift RPM。
- 为 MicroShift 配置工作负载分区。
流程
运行以下命令来安装低延迟 RPM 软件包:
sudo dnf install -y microshift-low-latency
$ sudo dnf install -y microshift-low-latencyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示等待主机重启,直到激活 TuneD 配置集后。重启主机重启 MicroShift 和 CRI-O,它应用低延迟清单并激活 TuneD 配置集。
后续步骤
-
为 MicroShift
config.yaml中的低延迟配置 kubelet 参数。 - 调优操作系统,例如配置并激活 TuneD 配置集。
- 可选:配置 TuneD 配置集的自动激活。
- 可选:如果您使用 x86_64 架构,请安装 Red Hat Enterprise Linux for Real Time (实时内核)。
- 为低延迟准备工作负载。
9.1.3. MicroShift 中的配置 kubelet 参数和值 复制链接链接已复制到粘贴板!
为 MicroShift 集群启用低延迟的第一步是将配置添加到 MicroShift config.yaml 文件中。
先决条件
-
已安装 OpenShift CLI(
oc)。 - 有对集群的 root 访问权限。
-
您在
/etc/microshift/目录中生成提供的config.yaml.default文件的副本,并将它重命名为config.yaml。
流程
将 kubelet 配置添加到 MicroShift
config.yaml文件中:passthrough
kubelet配置示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果您在 kubelet 配置中更改 CPU 或内存管理器,您必须删除缓存之前配置的文件。重启主机以自动删除它们,或者手动删除
/var/lib/kubelet/cpu_manager_state和/var/lib/kubelet/memory_manager_state文件。 - 2
- 要使用的策略的名称。有效值为
none和static。需要启用CPUManager功能门。默认值为none。 - 3
- 一组
key=value对,用于设置额外选项,以微调CPUManager策略的行为。默认值为null。需要启用CPUManager和CPUManagerPolicyOptions功能门。 - 4
- Memory Manager 使用的策略名称。区分大小写。默认值为
none。需要启用MemoryManager功能门。 - 5
- 必需。
reservedSystemCPUs值必须是离线 CPU 的反转,因为组合的值都必须考虑系统中的所有 CPU。这个参数对于划分管理和应用程序工作负载非常重要。使用此参数为主机级别系统和 Kubernetes 守护进程定义静态 CPU 设置,以及中断和计时器。然后,系统中的其余 CPU 专门用于工作负载。 - 6
- 本例中的
reservedMemory[0].limits.memory,1100Mi 的值等于kubeReserved.memory+systemReserved.memory+evictionHard.memory.available。 - 7
evictionHard参数定义 kubelet 在哪些情况下驱除 pod。当您更改evictionHard小节的一个参数的默认值时,其他参数的默认值不会继承,且设置为零。即使您想要只更改一个阈值,也请提供所有阈值。- 8
imagefs是一个文件系统,容器运行时用来存储容器镜像和容器可写入层。在本例中,evictionHard.imagefs.available参数意味着当镜像文件系统的可用空间小于 15% 时 pod 会被驱除。- 9
- 在本例中,
evictionHard.memory.available参数意味着当节点的可用内存下降到 100MiB 时,pod 会被驱除。 - 10
- 在本例中,
evictionHard.nodefs.available参数意味着当节点的主文件系统小于 10% 时,pod 会被驱除。 - 11
- 在本例中,
evictionHard.nodefs.inodesFree参数意味着,在使用节点主文件系统内节点的 15% 时 pod 会被驱除。
验证
-
完成后续步骤并重新启动主机后,您可以使用 root-access 帐户来检查您的设置是否在
/var/lib/microshift/resources/kubelet/config/目录中的config.yaml文件中。
后续步骤
- 启用工作负载分区。
- 调优您的操作系统。例如,配置和激活 TuneD 配置集。
- 可选:配置 TuneD 配置集的自动启用。
- 可选:如果您使用 x86_64 架构,您可以安装 Red Hat Enterprise Linux for Real Time (实时内核)。
- 为低延迟准备 MicroShift 工作负载。
9.1.4. Tuning Red Hat Enterprise Linux 9 复制链接链接已复制到粘贴板!
作为 Red Hat Enterprise Linux (RHEL)系统管理员,您可以使用 TuneD 服务针对各种用例优化 RHEL 的性能配置集。TuneD 监控并优化某些工作负载下的系统性能,包括延迟性能。
- 使用 TuneD 配置集根据不同的用例调优您的系统,如部署低延迟 MicroShift 集群。
- 您可以修改为每个配置集定义的规则,并自定义特定设备的调整。
- 当您切换到另一个配置集或取消激活 TuneD 时,对之前配置集进行的所有更改都会恢复到其原始状态。
- 您还可以将 TuneD 配置为响应设备使用的变化,并调整设置以提高活跃设备的性能并减少不活跃设备的功耗。
9.1.4.1. 配置 MicroShift TuneD 配置集 复制链接链接已复制到粘贴板!
在安装 microshift-low-latency RPM 软件包后,使用 Red Hat Enterprise Linux (RHEL) /etc/tuned/ host 目录中提供的 microshift-baseline-variables.conf 配置文件,将 TuneD 配置集配置为对 MicroShift 工作负载使用低延迟。
先决条件
- 有对集群的 root 访问权限。
-
已安装
microshift-low-latencyRPM 软件包。 - 您的 RHEL 主机已安装了 TuneD。请参阅开始使用 TuneD (RHEL 文档)。
流程
您可以使用
/etc/tuned/目录配置集中的默认microshift-baseline-variables.confTuneD 配置集,或者自行添加更多调整。microshift-baseline-variables.confTuneD 配置集示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 控制应隔离哪些内核。默认情况下,在 MicroShift 中为每个插槽保留 1 个内核,用于内务处理。其他内核被隔离。有效值为核心列表或范围。您可以隔离任何范围,例如:
isolated_cores=2,4-7或isolated_cores=2-23。重要您必须只保留一个
isolated_cores=变量。注意Kubernetes CPU Manager 可以使用任何 CPU 来运行工作负载,但 kubelet 配置中定义的保留 CPU 除外。因此,最好这样做:
- kubelet 保留 CPU 和隔离内核的总和包括所有在线 CPU。
- 隔离内核与 kubelet 配置中定义的保留 CPU 的补充。
- 2
- 巨页的大小。有效值为 2M 或 1G。
- 3
- 其他内核参数,例如
additional_args=console=tty0 console=ttyS0,115200。 - 4
- 设置为 offlined 的 CPU。重要
不得与
isolated_cores重叠。
运行以下命令启用配置集或更改活跃:
sudo tuned-adm profile microshift-baseline
$ sudo tuned-adm profile microshift-baselineCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 重启主机,使内核参数处于活动状态。
验证
可选:您可以读取包含在启动时当前运行内核的参数的
/proc/cmdline文件。cat /proc/cmdline
$ cat /proc/cmdlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
BOOT_IMAGE=(hd0,msdos2)/ostree/rhel-7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/vmlinuz-5.14.0-427.31.1.el9_4.x86_64+rt crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M rd.lvm.lv=rhel/root fips=0 console=ttyS0,115200n8 root=/dev/mapper/rhel-root rw ostree=/ostree/boot.1/rhel/7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/0 skew_tick=1 tsc=reliable rcupdate.rcu_normal_after_boot=1 nohz=on nohz_full=2,4-5 rcu_nocbs=2,4-5 tuned.non_isolcpus=0000000b intel_pstate=disable nosoftlockup hugepagesz=2M hugepages=10
BOOT_IMAGE=(hd0,msdos2)/ostree/rhel-7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/vmlinuz-5.14.0-427.31.1.el9_4.x86_64+rt crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M rd.lvm.lv=rhel/root fips=0 console=ttyS0,115200n8 root=/dev/mapper/rhel-root rw ostree=/ostree/boot.1/rhel/7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/0 skew_tick=1 tsc=reliable rcupdate.rcu_normal_after_boot=1 nohz=on nohz_full=2,4-5 rcu_nocbs=2,4-5 tuned.non_isolcpus=0000000b intel_pstate=disable nosoftlockup hugepagesz=2M hugepages=10Copy to Clipboard Copied! Toggle word wrap Toggle overflow
后续步骤
- 为低延迟准备 MicroShift 工作负载。
- 可选:配置 TuneD 配置集的自动启用。
- 可选:如果您使用 x86_64 架构,您可以安装 Red Hat Enterprise Linux for Real Time (实时内核)。
9.1.4.2. 自动启用 MicroShift TuneD 配置集 复制链接链接已复制到粘贴板!
microshift-low-latency RPM 软件包包含在 microshift-low-latency RPM 软件包中,您可以将它配置为在系统启动时自动启用 TuneD 配置集。如果要在大量设备中安装 MicroShift 时,此功能特别有用。
先决条件
- 在主机上安装了 microshift-low-latency RPM 软件包。
-
您可以在 MicroShift
config.yaml中启用低延迟。 - 您创建了 TuneD 配置集。
-
您已配置了
microshift-baseline-variables.conf文件。
流程
在
/etc/microshift/目录中配置tuned.yaml,例如:tuned.yaml 示例
profile: microshift-baseline reboot_after_apply: True
profile: microshift-baseline1 reboot_after_apply: True2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要当
microshift-tuned.service运行时,主机会被重启,但它不会在部署新提交时重启系统。您必须重启主机以启用新的提交,当microshift-tuned.service在该引导时运行时,系统会再次启动,并检测对配置集和变量的更改。这个双引导可能会影响回滚。确保您调整了在使用自动配置集激活时在回滚前允许的 greenboot 中的重启数量。例如,如果在 greenboot 的回滚前允许 3 个重启,请将该数字增加到 4。如需更多信息,请参阅"附加资源"列表。
输入以下命令启用
microshift-tuned.service在每个系统启动时运行:sudo systemctl enable microshift-tuned.service
$ sudo systemctl enable microshift-tuned.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要如果将
reboot_after_apply设置为True,请确保 TuneD 配置集处于活跃状态,且不会在 MicroShift 服务外激活其他配置集。否则,启动microshift-tuned.service会导致主机重启。运行以下命令启动
microshift-tuned.service:sudo systemctl start microshift-tuned.service
$ sudo systemctl start microshift-tuned.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意microshift-tuned.service使用收集的校验和来检测对所选 TuneD 配置集和变量的更改。如果磁盘中没有 checksum,服务会激活 TuneD 配置集并重启主机。预计首先启动microshift-tuned.service时,主机会重启。
后续步骤
- 可选:如果您使用 x86_64 架构,您可以安装 Red Hat Enterprise Linux for Real Time (实时内核)。
9.1.5. 使用 Red Hat Enterprise Linux for Real Time 复制链接链接已复制到粘贴板!
如果您的工作负载对核心内核功能有严格的低延迟确定性要求,如中断处理和进程调度(在微秒)范围内,您可以使用 Red Hat Enterprise Linux for Real Time (实时内核)。实时内核的目标是提供可预测的响应时间的一致性、低延迟确定性。
在考虑系统调整时,请考虑以下因素:
- 使用实时内核与标准内核一样,系统调优非常重要。
- 在运行作为 RHEL 9 版本的一部分所提供的、未调整的标准内核系统上安装实时内核可能无法获得显著的好处。
- 调优标准内核会获得大约 90% 的延迟。
- 实时内核提供要求最高的工作负载所需的最后 10% 的延迟减少。
虽然低延迟工作负载不需要实时内核,但使用实时内核可以优化低延迟性能。您可以使用 RPM 软件包在主机上安装它,并将其包括在 Red Hat Enterprise Linux for Edge (RHEL for Edge)镜像部署中。
先决条件
- 您有一个红帽订阅,其中包括 Red Hat Enterprise Linux for Real Time (实时内核)。例如,您的主机机器已注册,且 Red Hat Enterprise Linux (RHEL)附加到 RHEL for Real Time 订阅。
- 您使用 x86_64 架构。
流程
运行以下命令来启用实时内核存储库:
sudo subscription-manager repos --enable rhel-9-for-x86_64-rt-rpms
$ sudo subscription-manager repos --enable rhel-9-for-x86_64-rt-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来安装实时内核:
sudo dnf install -y kernel-rt
$ sudo dnf install -y kernel-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令查询实时内核版本:
RTVER=$(rpm -q --queryformat '%{version}-%{release}.%{arch}' kernel-rt | sort | tail -1)$ RTVER=$(rpm -q --queryformat '%{version}-%{release}.%{arch}' kernel-rt | sort | tail -1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,在 GRUB 中进行持久更改,该更改将实时内核指定为默认内核:
sudo grubby --set-default="/boot/vmlinuz-${RTVER}+rt"$ sudo grubby --set-default="/boot/vmlinuz-${RTVER}+rt"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 重启主机以激活实时内核。
后续步骤
- 为低延迟准备 MicroShift 工作负载。
- 可选:使用蓝图在 RHEL for Edge 镜像中安装实时内核。
您可以使用镜像构建器在 RHEL for Edge 镜像部署中包括实时内核。以下示例蓝图部分包括从之前为 MicroShift 集群配置低延迟所需的步骤收集的引用。
先决条件
- 您已在包含 Red Hat Enterprise Linux for Real Time (实时内核)的主机上启用了红帽订阅。
- 您使用 x86_64 架构。
-
您已将
osbuild配置为使用kernel-rt存储库。
在用于构建提交的主机上必须启用包含实时内核的订阅。
流程
在完整的安装蓝图中添加以下示例蓝图,以便在 RHEL for Edge 镜像中安装实时内核:
实时内核的蓝图片断示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
后续步骤
- 完成镜像构建过程。
- 如果您还没有完成为 MicroShift 集群启用低延迟的步骤,请现在完成。使用这些步骤中收集的信息更新蓝图。
- 如果您还没有配置工作负载分区,请现在这样做。
- 为低延迟准备 MicroShift 工作负载。
从以下流程开始,在 RHEL for Edge 镜像中嵌入 MicroShift 来完成构建过程。然后在 RHEL for Edge 镜像中安装 MicroShift 的安装文档中完成剩余的步骤:
9.1.7. 为低延迟准备 MicroShift 工作负载 复制链接链接已复制到粘贴板!
为了利用低延迟,在 MicroShift 上运行的工作负载必须使用 RuntimeClass 功能设置 microshift-low-latency 容器运行时配置。CRI-O RuntimeClass 对象使用 microshift-low-latency RPM 安装,因此只需要配置 pod 注解。
先决条件
-
已安装
microshift-low-latencyRPM 软件包。 - 配置了工作负载分区。
流程
使用以下示例在 pod 规格中设置以下注解:
cpu-load-balancing.crio.io: "disable" irq-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" cpu-load-balancing.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"
cpu-load-balancing.crio.io: "disable" irq-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" cpu-load-balancing.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
oslat测试的 pod 示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意仅在启用了 CPU 管理器静态策略以及带有保证 QoS 使用整个 CPU 的 pod 时,禁用 CPU 负载均衡。否则,禁用 CPU 负载均衡会影响集群中其他容器的性能。
重要要使 pod 具有
GuaranteedQoS 类,在请求和限值中,它必须具有相同的 CPU 和内存值。请参阅 Guaranteed (Kubernetes 上游文档)
镜像蓝图是所需镜像自定义的持久定义,可让您创建多个构建。您不需要为每个镜像构建重新配置蓝图,而是编辑、重建、删除并保存蓝图,以便您可以保留重新构建镜像。
在 RHEL for Edge 镜像中安装实时内核的蓝图示例
9.2. 工作负载分区 复制链接链接已复制到粘贴板!
工作负载分区将节点 CPU 资源划分为不同的 CPU 集。主要目标是限制所有 control plane 组件的 CPU 使用量,为用户的工作负载保留其余设备 CPU 资源。
工作负载分区将保留的 CPU 分配给 MicroShift 服务、集群管理工作负载和基础架构 pod,确保集群部署中剩余的 CPU 不受影响,并只可用于非平台工作负载。
9.2.1. 启用工作负载分区 复制链接链接已复制到粘贴板!
要在 MicroShift 上启用工作负载分区,请进行以下配置更改:
-
更新 MicroShift
config.yaml文件,使其包含 kubelet 配置文件。 - 创建 CRI-O systemd 和配置文件。
- 分别为 MicroShift 和 CRI-O 服务创建和更新 systemd 配置文件。
流程
更新 MicroShift
config.yaml文件,使其包含 kubelet 配置文件,以便为工作负载启用和配置 CPU Manager:在路径
/etc/kubernetes/openshift-workload-pinning中创建 kubelet 配置文件。kubelet 配置指示 kubelet 根据容量和可分配 CPU 修改节点资源。kubelet 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpuset适用于具有 8 个 VCPU (4 个内核)的计算机,并在整个文档中有效。
更新路径
/etc/microshift/config.yaml中的 MicroShift config.yaml 文件。在 MicroShiftconfig.yaml文件中嵌入 kubelet 配置,以便为工作负载启用和配置 CPU Manager。MicroShift
config.yaml示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 CRI-O systemd 和配置文件:
在路径
/etc/crio/crio.conf.d/20-microshift-workload-partition.conf中创建 CRI-O 配置文件,该文件会覆盖11-microshift-ovn.conf文件中已存在的默认配置。CRI-O 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在路径
/etc/systemd/system/crio.service.d/microshift-cpuaffinity.conf中为 CRI-O 创建 systemd 文件。CRI-O systemd 配置示例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
为 MicroShift 和 CRI-O 服务创建并更新带有
CPUAffinity值的 systemd 配置文件:在路径
/etc/systemd/system/microshift.service.d/microshift-cpuaffinity.conf中创建 MicroShift 服务 systemd 文件。MicroShift 将使用 systemdCPUAffinity值进行固定。MicroShift 服务 systemd 配置示例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新 MicroShift ovs-vswitchd systemd 文件中的
CPUAffinity值,该文件路径/etc/systemd/system/ovs-vswitchd.service.d/microshift-cpuaffinity.conf。MicroShift ovs-vswitchd systemd 配置示例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新路径
/etc/systemd/system/ovsdb-server.service.d/microshift-cpuaffinity.conf中的 MicroShift ovsdb-server systemd 文件中的CPUAffinity值MicroShift ovsdb-server systemd 配置示例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow