设置

设置分布式 k6

故障排除

开源

故障排除

本主题包含帮助你排除 k6 Operator 常见问题的说明。

如何排除故障

本地测试你的脚本

在使用 k6 Operator 运行脚本之前，务必先在本地运行你的脚本

k6 run script.js

如果你使用环境变量或 CLI 选项，也一并传入

MY_ENV_VAR=foo k6 run script.js --tag my_tag=bar

这样可以确保脚本语法正确，并且能够被 k6 解析。此外，在本地运行可以帮助你检查配置的选项是否符合预期。如果在 k6 run 的输出中有任何错误或意外结果，请在将脚本部署到其他位置之前确保修复它们。

`TestRun` 部署

Pod

如果创建一个 TestRun 自定义资源 (CR) 并设置 parallelism: n，会存在某些重复模式

将会创建 n + 2 个 Job（以及对应的 Pod）：initializer、starter 和 n 个 runner。
如果这些 Job 中有任何一个未能部署 Pod，则该 Job 肯定有问题。这里有一些可以帮助的命令
bash
```
kubectl get jobs -A
kubectl describe job mytest-initializer
```
如果其中一个 Pod 已部署但以 Error 结束，你可以使用以下命令查看其日志
bash
```
kubectl logs mytest-initializer-xxxxx
```

如果 Pod 看似正常运行但未产生预期结果，且日志中信息不足，你可以在 TestRun 规范中使用 k6 的详细选项

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: k6-sample
spec:
  parallelism: 2
  script:
    configMap:
      name: 'test'
      file: 'test.js'
  arguments: --verbose

k6 Operator

另一个信息来源是 k6 Operator 本身。它默认作为 Kubernetes Deployment 部署，replicas: 1。它的日志以及对上一节 Pod 的观察通常包含足够的信息来帮助你诊断任何问题。使用标准部署时，可以使用以下命令查看 k6 Operator 的日志

kubectl -n k6-operator-system -c manager logs k6-operator-controller-manager-xxxxxxxx-xxxxx

检查 `TestRun` 资源

部署 TestRun CR 后，你可以像检查任何其他资源一样检查它

kubectl describe testrun my-testrun

首先，检查规范是否符合预期。然后，查看当前状态

Status:
  Conditions:
    Last Transition Time:  2024-01-17T10:30:01Z
    Message:
    Reason:                CloudTestRunFalse
    Status:                False
    Type:                  CloudTestRun
    Last Transition Time:  2024-01-17T10:29:58Z
    Message:
    Reason:                TestRunPreparation
    Status:                Unknown
    Type:                  TestRunRunning
    Last Transition Time:  2024-01-17T10:29:58Z
    Message:
    Reason:                CloudTestRunAbortedFalse
    Status:                False
    Type:                  CloudTestRunAborted
    Last Transition Time:  2024-01-17T10:29:58Z
    Message:
    Reason:                CloudPLZTestRunFalse
    Status:                False
    Type:                  CloudPLZTestRun
  Stage:                   error

如果 Stage 等于 error，你可以检查 k6 Operator 的日志。

条件也可以作为信息来源，但如果前面的步骤不足以诊断问题，才应使用它。请注意，以 Cloud 前缀开头的条件仅在 k6 Cloud 测试运行设置中重要，例如云输出和 PLZ 测试运行。

常见场景

环境变量问题

有关如何将环境变量传递给 k6 Operator 的详细信息，请参阅环境变量。

标签不工作

标签是使用 k6 Operator 时相当常见的错误来源。例如，以下标签会导致解析错误

  arguments: --tag product_id="Test A"
  # or
  arguments: --tag foo=\"bar\"

你可以在 initializer 或 runner Pod 的日志中看到这些错误，例如

time="2024-01-11T11:11:27Z" level=error msg="invalid argument \"product_id=\\\"Test\" for \"--tag\" flag: parse error on line 1, column 12: bare \" in non-quoted-field"

这是字符转义的常见问题。你可以在 k6 Operator 仓库中找到一个议题，你可以对其点赞。

Initializer 记录了错误，但与标签无关

这可能是由于未注意准备步骤造成的。你可以使用以下命令来帮助诊断脚本问题

k6 inspect --execution-requirements script.js

该命令是 initializer Pod 执行的缩短版本。如果该命令产生错误，则说明脚本本身有问题，应在 k6 Operator 外部解决。错误本身可能包含错误的提示，例如语法错误。

如果独立的 k6 inspect --execution-requirements 成功执行，那么很可能是你的 Kubernetes 设置特有的 TestRun 部署问题。这里有几点建议

检查 initializer Pod 的输出：它是 k6 进程记录的还是其他什么？
- :information_source: k6 Operator 要求 initializer 日志仅包含 k6 inspect 的输出。如果存在任何其他日志行，则 k6 Operator 将无法解析并导致测试无法启动。有关更多详细信息，请参阅此议题。
检查 initializer Job 和 Pod 中的事件，它们可能包含有关错误的其他提示。

不存在的 ServiceAccount

ServiceAccount 可以在 PrivateLoadZone 中定义为 serviceAccountName，在 TestRun CRD 中定义为 runner.serviceAccountName。如果指定的 ServiceAccount 不存在，k6 Operator 将成功创建 Job，但相应的 Pod 将无法部署，并且 k6 Operator 将无限期等待 Pod 变为 Ready。此错误在 Job 的事件中最为明显

kubectl describe job plz-test-xxxxxx-initializer
...
Events:
  Warning  FailedCreate  57s (x4 over 2m7s)  job-controller  Error creating: pods "plz-test-xxxxxx-initializer-" is forbidden: error looking up service account plz-ns/plz-sa: serviceaccount "plz-sa" not found

k6 Operator 不会尝试自行分析此类场景，但你可以参考以下议题以获取改进。

如何修复

要解决此问题，必须更正错误的 serviceAccountName，并重新部署 TestRun 或 PrivateLoadZone 资源。

不存在的 `nodeSelector`

nodeSelector 可以在 PrivateLoadZone 中定义为 nodeSelector，在 TestRun CRD 中定义为 runner.nodeSelector。

这种情况与ServiceAccount 非常相似：Pod 创建会失败，但错误略有不同

kubectl describe pod plz-test-xxxxxx-initializer-xxxxx
...
Events:
  Warning  FailedScheduling  48s (x5 over 4m6s)  default-scheduler  0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector.

如何修复

要解决此问题，必须更正错误的 nodeSelector 并重新部署 TestRun 或 PrivateLoadZone 资源。

资源不足

当集群没有足够的资源来部署 runner 时，可能会发生相关问题。为 runner 设置较小的 CPU 和内存限制，或使用 nodeSelector、runner.affinity 或 runner.topologySpreadConstraints 等选项，并且没有与规范匹配的节点集时，遇到此问题的可能性更大。另外，如果测试需要大量 runner（通过 TestRun 中的 parallelism 或在 PLZ 测试运行期间），并且集群自动伸缩对节点的最大数量有限制，无法及时或完全提供所需的资源，也可能发生这种情况。

这种情况与前两种情况有些相似：k6 Operator 将无限期等待，可以通过 Job 和 Pod 中的事件进行监控。如果可以在运行时解决资源不足的问题，例如通过添加更多节点，k6 Operator 将尝试继续执行测试运行。

runner Pod OOM

如果至少有一个 runner Pod 发生 OOM，整个测试将会卡住，并且必须手动删除

kubectl -f my-test.yaml delete
# or
kubectl delete testrun my-test

如果发生 OOM，检查 k6 脚本以了解该脚本需要什么样的资源使用情况是合理的。k6 脚本可能会被改进以提高性能。然后，在 TestRun CRD 中相应地设置 spec.runner.resources，或在 PrivateLoadZone CRD 中设置 spec.resources。

PrivateLoadZone: 订阅错误

如果你的 Grafana Cloud k6 订阅有问题，日志中会显示 400 错误，并附带详细说明问题的消息。例如

"Received error `(400) You have reached the maximum Number of private load zones your organization is allowed to have. Please contact support if you want to create more.`. Message from server ``"

要解决此问题，请检查你在 Grafana Cloud k6 中的组织设置或联系支持部门。

PrivateLoadZone: 错误的令牌

身份验证令牌可能存在两个主要问题

如果令牌未创建，或创建位置错误，日志将显示以下错误

Failed to load k6 Cloud token	{"namespace": "plz-ns", "name": "my-plz", "reconcileID": "67c8bc73-f45b-4c7f-a9ad-4fd0ffb4d5f6", "name": "token-with-wrong-name", "secretNamespace": "plz-ns", "error": "Secret \"token-with-wrong-name\" not found"}