5.12. 对 Compliance Operator 进行故障排除
本节介绍如何对 Compliance Operator 进行故障排除。该信息可用于诊断问题或在错误报告中提供信息。一些常规提示:
出现重大事件时,Compliance Operator 会发出 Kubernetes 事件。您可以使用以下命令查看集群中的所有事件:
$ oc get events -n openshift-compliance
或者使用以下命令查看 Scan 等对象的事件:
$ oc describe -n openshift-compliance compliancescan/cis-compliance
Compliance Operator 由多个控制器组成,大约每个 API 对象一个。仅过滤对应于有问题的 API 对象的控制器很有用。如果无法应用
ComplianceRemediation
,请查看remediationctrl
控制器中的信息。可以通过使用jq
进行解析来过滤单个控制器中的信息:$ oc -n openshift-compliance logs compliance-operator-775d7bddbd-gj58f \ | jq -c 'select(.logger == "profilebundlectrl")'
在 UTC 中,自 UNIX 时间戳以来的时间戳以秒为单位记录。要将其转换为人类可读的日期,请使用
date -d @timestamp --utc
,例如:$ date -d @1596184628.955853 --utc
-
很多自定义资源允许设置
debug
选项,最重要的是ComplianceSuite
和ScanSetting
。启用此选项会增加 OpenSCAP 扫描程序 Pod 以及其他一些帮助程序 Pod 的详细程度。 -
如果单个规则意外传递或失败,则仅使用该规则运行单次扫描或 suite 从相应的
ComplianceCheckResult
对象中查找规则 ID 并将其用作Scan
CR 中的rule
属性值会很有帮助。然后再启用debug
选项,扫描程序 Pod 中的scanner
容器日志会显示原始 OpenSCAP 日志。
5.12.1. 扫描剖析
以下各节概述了 Compliance Operator 扫描的组件和阶段。
5.12.1.1. 合规性源
合规性内容存储在从 ProfileBundle
对象生成的 Profile
对象中。Compliance Operator 为集群创建一个 ProfileBundle
对象,并为集群节点创建另一个对象。
$ oc get -n openshift-compliance profilebundle.compliance
$ oc get -n openshift-compliance profile.compliance
ProfileBundle
对象由带有 Bundle
名称标签的部署处理。要使用 Bundle
排除问题,可以查找部署并查看部署中的 Pod 日志:
$ oc logs -n openshift-compliance -lprofile-bundle=ocp4 -c profileparser
$ oc get -n openshift-compliance deployments,pods -lprofile-bundle=ocp4
$ oc logs -n openshift-compliance pods/<pod-name>
$ oc describe -n openshift-compliance pod/<pod-name> -c profileparser
5.12.1.2. ScanSetting 和 ScanSettingBinding 对象生命周期和调试
通过有效的合规性内容源,可以使用高级 ScanSetting
和 ScanSettingBinding
对象来生成 ComplianceSuite
和 ComplianceScan
对象:
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: my-companys-constraints debug: true # For each role, a separate scan will be created pointing # to a node-role specified in roles roles: - worker --- apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: my-companys-compliance-requirements profiles: # Node checks - name: rhcos4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 # Cluster checks - name: ocp4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: my-companys-constraints kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
ScanSetting
和 ScanSettingBinding
对象均由标记为 logger=scansettingbindingctrl
的同一控制器处理。这些对象没有状态。任何问题都以事件的形式传递:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuiteCreated 9m52s scansettingbindingctrl ComplianceSuite openshift-compliance/my-companys-compliance-requirements created
现在创建一个 ComplianceSuite
对象。流继续协调新创建的 ComplianceSuite
。
5.12.1.3. ComplianceSuite 自定义资源生命周期和调试
ComplianceSuite
CR 是一个围绕 ComplianceScan
CR 的 wrapper。ComplianceSuite
CR 由标记为 logger=suitectrl
的控制器处理。该控制器处理从 Suite 创建 Scan 的过程,将单个扫描状态协调并整合为一个 Suite 状态。如果将 Suite 设置为定期执行,suitectrl
也会处理创建 CronJob
CR 的事件,该 CR 在初始运行完成后会在 Suite 中重新运行 Scan:
$ oc get cronjobs
输出示例
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE <cron_name> 0 1 * * * False 0 <none> 151m
对于最重要的问题,会发出事件。使用 oc describe compliancesuites/<name>
查看它们。Suite
对象还有一个 Status
子资源,当属于这个 Suite
的任何 Scan
对象更新其 Status 子资源时,这个子资源会更新。创建所有预期扫描后,控制会被传递给扫描控制器。
5.12.1.4. ComplianceScan 自定义资源生命周期和调试
ComplianceScan
CR 由 scanctrl
控制器处理。这也是进行实际扫描以及创建扫描结果的地方。每次扫描都经过几个阶段:
5.12.1.4.1. 待处理阶段
在此阶段验证扫描是否正确。如果存储大小等参数无效,则扫描会转换为 DONE,并包含 ERROR 结果,否则进入启动阶段。
5.12.1.4.2. 启动阶段
在此阶段,一些配置映射包含扫描程序 Pod 的环境或直接包含扫描程序 Pod 要评估的脚本。列出配置映射:
$ oc -n openshift-compliance get cm \ -l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=
扫描程序 pod 将使用这些配置映射。如果您需要修改扫描程序行为,更改扫描程序调试级别或打印原始结果,修改配置映射是一种好方法。随后,每次扫描都会创建一个持久性卷声明,以存储原始 ARF 结果:
$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
PVC 由每次扫描进行的 ResultServer
部署挂载。ResultServer
是一个简单的 HTTP 服务器,单个扫描程序 Pod 会将完整 ARF 结果上传到其中。每个服务器都可以在不同节点中运行。完整 ARF 结果可能非常大,您不能假定可以创建同时从多个节点挂载的卷。扫描完成后,ResultServer
部署会缩减。包含原始结果的 PVC 可从另一个自定义 Pod 挂载,并可获取或检查结果。扫描程序 Pod 和 ResultServer
之间的流量受 mutual TLS 协议保护。
最后,扫描程序 Pod 在此阶段启动;一个扫描程序 Pod 用于一个 Platform
扫描实例,每个匹配节点的一个扫描程序 Pod 用于一个 node
扫描实例。每节点 Pod 使用节点名称标识。每个 Pod 始终使用 ComplianceScan
名称标识:
$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels
输出示例
NAME READY STATUS RESTARTS AGE LABELS rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod 0/2 Completed 0 39m compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner
+ 扫描然后进入 Running 阶段。
5.12.1.4.3. 运行阶段
运行阶段会等待扫描程序 Pod 完成。运行阶段使用以下术语和进程:
-
init 容器:有一个名为
content-container
的 init 容器。它运行 contentImage 容器,并执行单个命令,该命令将 contentFile 复制到与这个 Pod 中其他容器共享的/content
目录中。 -
scanner:此容器运行扫描。对于节点扫描,该容器将节点文件系统作为
/host
挂载,并挂载 init 容器交付的内容。该容器还挂载启动阶段创建的entrypoint
ConfigMap
并执行它。入口点ConfigMap
中的默认脚本执行 OpenSCAP,并将结果文件存储在 Pod 容器之间共享的/results
目录中。可查看此 Pod 中的日志以确定 OpenSCAP 扫描程序检查了哪些内容。可使用debug
标记查看更详细的输出。 logcollector:logcollector 容器会等待扫描程序容器完成。然后,它会将完整的 ARF 结果上传到
ResultServer
,并以ConfigMap
的形式单独上传 XCCDF 结果以及扫描结果和 OpenSCAP 结果代码。这些结果配置映射使用扫描名称 (compliance.openshift.io/scan-name=rhcos4-e8-worker
) 进行标记:$ oc describe cm/rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod
输出示例
Name: rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod Namespace: openshift-compliance Labels: compliance.openshift.io/scan-name-scan=rhcos4-e8-worker complianceoperator.openshift.io/scan-result= Annotations: compliance-remediations/processed: compliance.openshift.io/scan-error-msg: compliance.openshift.io/scan-result: NON-COMPLIANT OpenSCAP-scan-result/node: ip-10-0-169-90.eu-north-1.compute.internal Data ==== exit-code: ---- 2 results: ---- <?xml version="1.0" encoding="UTF-8"?> ...
用于 Platform
扫描的扫描程序 Pod 类似,以下情况除外:
-
名为
api-resource-collector
的一个额外 init 容器读取由 content-container init 容器提供的 OpenSCAP 内容,确定内容需要检查的 API 资源,并将这些 API 资源存储到scanner
容器将从中读取它们的共享目录中。 -
scanner
容器不需要挂载主机文件系统。
扫描程序 Pod 完成后,扫描将进入聚合阶段。
5.12.1.4.4. 聚合阶段
在聚合阶段,扫描控制器会生成另一个名为聚合器 Pod 的 Pod。它的目的是获取生成的 ConfigMap
对象,读取结果,并为每个检查结果创建对应的 Kubernete 对象。如果可自动补救检查失败,将创建一个 ComplianceRemediation
对象。为了提供人类可读的检查和补救元数据,聚合器 Pod 也会使用 init 容器挂载 OpenSCAP 内容。
当一个配置映射由聚合器 Pod 处理时,会使用 compliance-remediations/processed
标签进行标识。这个阶段会生成 ComplianceCheckResult
对象:
$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
输出示例
NAME STATUS SEVERITY rhcos4-e8-worker-accounts-no-uid-except-zero PASS high rhcos4-e8-worker-audit-rules-dac-modification-chmod FAIL medium
和 ComplianceRemediation
对象:
$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
输出示例
NAME STATE rhcos4-e8-worker-audit-rules-dac-modification-chmod NotApplied rhcos4-e8-worker-audit-rules-dac-modification-chown NotApplied rhcos4-e8-worker-audit-rules-execution-chcon NotApplied rhcos4-e8-worker-audit-rules-execution-restorecon NotApplied rhcos4-e8-worker-audit-rules-execution-semanage NotApplied rhcos4-e8-worker-audit-rules-execution-setfiles NotApplied
创建这些 CR 后,聚合器 Pod 将退出,扫描进入完成阶段。
5.12.1.4.5. 完成阶段
在最后的扫描阶段,会根据需要清理扫描资源,如果扫描是一次性的,ResultServer
部署会被缩减,如果扫描是连续性的,会被删除;下一个扫描实例将重新创建部署。
也可以在完成阶段通过注解来触发扫描重新运行:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
扫描到达完成阶段后,除非将补救设置为使用 autoApplyRemediations: true
自动应用,否则不会自动执行任何其他操作。OpenShift Container Platform 管理员现在将审阅补救并根据需要应用它们。如果将补救设置为自动应用,ComplianceSuite
控制器会在完成阶段接管,暂停扫描映射到的机器配置池,并一次性应用所有补救。如果应用了补救,ComplianceRemediation
控制器将接管。
5.12.1.5. ComplianceRemediation 控制器生命周期和调试
示例扫描报告了一些结果。通过将 apply
属性切换为 true
可启用其中一个补救:
$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge
ComplianceRemediation
控制器 (logger=remediationctrl
) 协调修改后的对象。协调的结果是会更改已协调补救对象的状态,也会更改包含所有已应用补救的已渲染的每套件 MachineConfig
对象。
MachineConfig
对象始终以 75-
开头,并以扫描和套件命名:
$ oc get mc | grep 75-
输出示例
75-rhcos4-e8-worker-my-companys-compliance-requirements 3.2.0 2m46s
当前包含 mc
的补救列在机器配置的注解中:
$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements
输出示例
Name: 75-rhcos4-e8-worker-my-companys-compliance-requirements Labels: machineconfiguration.openshift.io/role=worker Annotations: remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:
ComplianceRemediation
控制器的算法如下:
- 所有当前应用的补救都读取到初始补救集合中。
- 如果要应用协调后的补救,会将其添加到该集合中。
-
MachineConfig
对象从集合中渲染,并使用集合中的补救名称进行注解。如果集合为空(未应用最后一个补救),将删除渲染的MachineConfig
对象。 - 只有渲染的机器配置与集群中已应用的 MC 不同时,才会更新(或创建,或删除)应用的 MC。
-
创建或修改
MachineConfig
对象会触发与machineconfiguration.openshift.io/role
标签匹配的节点重新引导 - 请参阅 MachineConfig Operator 文档以了解更多详细信息。
根据需要更新渲染的机器配置并更新协调的补救对象状态后,补救循环即告终止。在本例中,应用补救会触发重新引导。重新引导后,注解扫描以重新运行它:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
扫描将运行并完成。检查补救是否通过:
$ oc -n openshift-compliance \ get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod
输出示例
NAME STATUS SEVERITY rhcos4-e8-worker-audit-rules-dac-modification-chmod PASS medium
5.12.1.6. 有用的标签
Compliance Operator 生成的每个 pod 都专门使用其所属的扫描及其工作来标识。扫描标识符使用 compliance.openshift.io/scan-name
标签进行标识。工作负载标识符使用 workload
标签进行标识。
Compliance Operator 调度以下工作负载:
- scanner:执行合规性扫描。
- resultserver:存储合规性扫描的原始结果。
- aggregator:汇总结果,检测不一致和输出结果对象(检查结果和补救)。
- suitererunner:将标记一个要重新运行的套件(设定时间表时)。
- profileparser:解析数据流并创建适当的配置集、规则和变量。
需要对某个工作负载进行调试和记录日志时,请运行:
$ oc logs -l workload=<workload_name> -c <container_name>
5.12.2. 增加 Compliance Operator 资源限值
在某些情况下,Compliance Operator 可能需要的内存超过默认限制允许的数量。缓解此问题的最佳方法是设置自定义资源限制。
要增加扫描程序 Pod 的默认内存和 CPU 限值,请参阅 'ScanSetting' 自定义资源。
流程
要将 Operator 的内存限值增加到 500 Mi,请创建名为
co-memlimit-patch.yaml
的以下补丁文件:spec: config: resources: limits: memory: 500Mi
应用补丁文件:
$ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
5.12.3. 配置 Operator 资源限制
resources
字段为 Operator Lifecycle Manager (OLM) 创建的 Pod 中所有容器定义资源约束。
此流程中应用的资源约束会覆盖现有的资源限制。
流程
通过编辑
Subscription
对象,注入 0.25 cpu 和 64 Mi 内存的请求,以及每个容器 0.5 cpu 和 128 Mi 内存:kind: Subscription metadata: name: custom-operator spec: package: etcd channel: alpha config: resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
5.12.4. 获取支持
如果您在执行本文档所述的某个流程或 OpenShift Container Platform 时遇到问题,请访问 红帽客户门户网站。通过红帽客户门户网站:
- 搜索或者浏览红帽知识库,了解与红帽产品相关的文章和解决方案。
- 提交问题单给红帽支持。
- 访问其他产品文档。
要识别集群中的问题,您可以在 OpenShift Cluster Manager 中使用 Insights。Insights 提供了问题的详细信息,并在有可用的情况下,提供了如何解决问题的信息。
如果您对本文档有任何改进建议,或发现了任何错误,请为相关文档组件提交 JIRA 问题。请提供具体详情,如章节名称和 OpenShift Container Platform 版本。