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 版本。

5.12. 对 Compliance Operator 进行故障排除

5.12.1. 扫描剖析

5.12.1.1. 合规性源

5.12.1.2. ScanSetting 和 ScanSettingBinding 对象生命周期和调试

5.12.1.3. ComplianceSuite 自定义资源生命周期和调试

5.12.1.4. ComplianceScan 自定义资源生命周期和调试

5.12.1.4.1. 待处理阶段

5.12.1.4.2. 启动阶段

5.12.1.4.3. 运行阶段

5.12.1.4.4. 聚合阶段

5.12.1.4.5. 完成阶段

5.12.1.5. ComplianceRemediation 控制器生命周期和调试

5.12.1.6. 有用的标签

5.12.2. 增加 Compliance Operator 资源限值

5.12.3. 配置 Operator 资源限制

5.12.4. 获取支持

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links