配置

本页总结最常见的配置面。

Helm Values

platform chart 配置：

• scheduler 和 controller replicas，
• image repositories、tags 和 pull policy，
• imagePullSecrets，
• leader election，
• service accounts 和 RBAC，
• security contexts，
• metrics Services，
• 可选 ServiceMonitor，
• node selectors、tolerations 和 affinity。

应用前可以先渲染 chart 输出：

helm template kruntimes ./charts/kruntimes --namespace kruntimes-system

仅贡献者使用的 Make variables 和 chart validation commands 见 Development Guide 和 Testing Guide 。

Console TLS

Console 随 kruntimes chart 一同安装，并且只暴露 HTTPS。对于本地开发或明确受信任的部署， chart 默认会生成 certificate：

console:
  tls:
    selfSigned: true

要挂载已有 TLS Secret，需要显式选择该来源：

console:
  tls:
    selfSigned: false
    secretName: console-tls

要由 cert-manager 签发 certificate，关闭 chart 生成并引用已有 Issuer 或 ClusterIssuer。该 issuer 本身可以是 cert-manager 的 self-signed issuer。

console:
  tls:
    selfSigned: false
    secretName: console-tls
    certManager:
      enabled: true
      issuerRef:
        name: platform-ca
        kind: ClusterIssuer

selfSigned、已有 Secret 和 certManager.enabled 是互斥选择。Service 始终为 ClusterIP； ingress 或其它对外暴露需要单独配置。

Run Extension API

runExtensionAPI.enabled 独立于始终安装的 Kruntimes Console，默认是 true。它安装 logs.kruntimes.io/v1alpha1 和 sessions.kruntimes.io/v1alpha1 两个 APIService 及独立 backend。这是 krt logs 和 Console 的默认 transport：普通 kubeconfig authentication（包括 client certificate）由 Kubernetes API server 验证。 caller 只需要 logs.kruntimes.io runs/log subresource 的 get；不需要 kruntimes.io/runs get 或 pods/log。

这两个 APIService 是 cluster-scoped，因此同一集群中每个 API group/version 只能有一个 Run extension API backend。若在同一集群安装第二个 kruntimes platform release，应保留拥有该 API 的 release 的 runExtensionAPI.enabled: true，并将其它 release 设为 false。

runExtensionAPI:
  enabled: true

旧的 logAPI values key 仍可覆盖已有 Helm values 文件中的对应设置，但不包括 image：旧镜像只包含日志 API binary。新配置应使用 runExtensionAPI 和 run-extension-apiserver 镜像。

Console 和 krt logs 始终使用该聚合 API。Console 内嵌的 Runtime access API 继续提供 Session 和 Function endpoint，但不再提供 Run logs。

krt session exec 和 krt session attach 也通过 Kubernetes API server 使用 Session subresource。caller 需要指定 kruntimes.io/runs 和 sessions.kruntimes.io/runs/session 的 get 权限。

公开资源列表

namespace、Run、Runtime 和 WorkflowRun 列表默认无需 token 即可查看。该行为由 console.publicRead.enabled 控制；设置为 false 后，所有 API 请求都需要 bearer token：

console:
  publicRead:
    enabled: false

chart 只给 Console ServiceAccount 授予 namespaces、runs、runtimes 和 workflowruns 的 get/list 权限。它们的详情仍必须使用 caller 的 bearer token。日志请求需要 logs.kruntimes.io runs/log subresource 的 get。

Runtime Capacity

Runtime capacity 在 Runtime CRD 中声明：

spec:
  capacity:
    resources:
      runs: 4
      gpu: 1

controller 会把声明的静态 capacity 复制到 Runtime Pod annotations。scheduler 会从 Run state 跟踪快速变化的 active usage。

Runtime Pod Template

Runtime Pod 自定义配置位于 Runtime.spec.template。

spec:
  template:
    spec:
      serviceAccountName: custom-runtime-sa
      nodeSelector:
        workload: kruntimes
      tolerations:
        - key: dedicated
          operator: Equal
          value: runtimes
          effect: NoSchedule

controller 保留 kruntimes 需要的字段。不要覆盖注入的 runtimed container，也不要覆盖 kruntimes 管理的 labels 和 annotations。

Artifact Stores

workloads 将 artifacts 写到 $KRUNTIME_ARTIFACTS_DIR 下，并通过 Runtime artifact store 持久化。

支持的 backends：

• filesystem/PVC，
• S3-compatible object storage。

Run status 在 status.artifactRefs 中存储有界 metadata，而不是完整 artifact contents。

暴露给 Runs 的环境变量

Benchmark Variables

见 Performance Benchmarks 。