Kubernetes：探针、密钥、固定版本和迁移

在 Kubernetes 上运行 ObjectOS 镜像 —— 一个参考 Deployment、在正确端点上的正确探针、来自 Secret 的密钥，以及在各副本之间必须保持一致的内容。

没有 Helm chart，也没有官方清单集。镜像在 Kubernetes 上无需修改即可运行，所以本页给出一个最小参考，以及你的清单必须保持的属性 —— 每一项都是运行时所依赖或强制执行的东西。Docker 上的一切都同样适用：同一个镜像、同样的变量、同样的升级规则。

参考 Deployment

Community 镜像的一个副本，密钥来自一个 Secret，每个探针各有自己的端点：

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: objectos
spec:
  replicas: 1
  selector:
    matchLabels: { app: objectos }
  template:
    metadata:
      labels: { app: objectos }
    spec:
      containers:
        - name: objectos
          image: registry.example.com/crm:2.2.2   # your image FROM ghcr.io/objectstack-ai/objectstack:X.Y.Z
          ports:
            - containerPort: 8080
          envFrom:
            - secretRef:
                name: objectos-secrets   # OS_DATABASE_URL, OS_AUTH_SECRET, OS_SECRET_KEY
          livenessProbe:
            httpGet: { path: /api/v1/health, port: 8080 }
            periodSeconds: 30
          readinessProbe:
            httpGet: { path: /api/v1/ready, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: objectos
spec:
  selector: { app: objectos }
  ports:
    - port: 80
      targetPort: 8080

需要保持的属性

镜像被精确固定

按 @sha256: 摘要引用镜像，并在旁边写上读取它时对应的确切版本，绝不使用滚动标签。在编排器上，这比在单台主机上更重要：拉取策略加上会移动的标签，意味着"同一个" Deployment 的两个 Pod 可能运行不同的构建。滚动标签随每次发布而移动，确切的版本标签在该版本被重新构建时也会移动；参见Docker → 固定镜像。

探针指向正确的端点

/api/v1/health 是存活探针。/api/v1/ready 是就绪探针。在运行时启动期间、关闭期间，以及任何数据驱动停止响应时，就绪端点都会返回 503 —— 这样滚动重启可以干净地排空，而失去数据库的 Pod 会离开 Service 的端点，而不是返回错误。

不要把就绪检查放到存活探针上。否则一次数据库故障会同时重启所有 Pod，而这并不能让数据库恢复，配置故障也会表现为 CrashLoopBackOff，而不是故障本身。数据库恢复后，Pod 会自行恢复：就绪探针在数据库不可用时把它们排空，之后再重新接纳它们。

密钥来自 Secret

OS_AUTH_SECRET 和 OS_SECRET_KEY 应放在一个 Secret 中，只生成一次，并由每个 Pod 挂载 —— 绝不按 Pod 生成，绝不烘焙进镜像。一个自己生成加密密钥的 Pod 会在下次重新调度时丢失它，用它加密的所有密钥也随之丢失。

业务数据存放在集群之外

把部署指向一个托管的 PostgreSQL。集群内的持久卷并不是业务数据该待的地方。

Community 上只用一个副本

Community 上的协调是进程内的，所以保持 replicas: 1。声明更多副本（OS_CLUSTER_REPLICAS 大于 1）在没有许可证时会拒绝启动。多节点是一项企业版许可证能力，而 Enterprise 套件目前只运行一个副本 —— 见下文。

入口

在边缘终止 TLS，并把 OS_AUTH_URL 和 OS_TRUSTED_ORIGINS 设为公网地址。在 OS_CORS_ORIGIN 中显式列出跨源前端；绝不把通配符源与携带凭据的请求一起使用。当运行时位于代理之后时，确保代理用它自己的 forwarded-for 头替换客户端提供的任何同类头 —— 速率限制和审计轨迹都依赖于调用者身份是可信的。

企业版额外提供

我们提供的是 Compose 技术栈，而不是 Helm chart 或 Kubernetes 清单。你的版本中附带的部署包才是受支持、经过测试的配置。在 Kubernetes 上，清单要你自己组装，所以也要重现该技术栈的这些属性。编排器不会改变部署有权获得的任何东西。

镜像按摘要固定

在 Pod spec 中按 @sha256: 摘要引用企业版镜像。拉取镜像需要一个保存你的许可证镜像仓库凭据的拉取密钥。

迁移在副本提供服务之前运行一次，并运行到完成

Compose 技术栈运行一个一次性的迁移容器，它必须在任何应用副本启动之前完成。在 Kubernetes 上，这是一个 Job（或等效的服务前钩子），而不是每个副本上的 init 容器 —— 关键在于模式变更只运行一次，而不是每个副本并行各运行一次。镜像正是为此支持一种"迁移后退出"的模式；部署包中点名了对应的变量。

每个副本都使用完全相同的密钥

目前请让 Enterprise 套件保持一个副本。 它没有接入集群驱动，声明多于一个副本（OS_CLUSTER_REPLICAS 大于 1）会按设计拒绝启动：进程内协调器不会在副本之间共享锁、计数器或发布 / 订阅。多节点通过许可证合同（maxNodes）激活，并不是高可用承诺；如果你需要，请联系销售。无论副本数是多少：

使用一个共享的加密密钥（OS_SECRET_KEY）。没有它，每个副本会自己生成一个，而这些密钥会互不相同。
认证密钥同样必须在运行时所在的每个地方都完全相同。

许可证和云端姿态作用于整个部署

许可证密钥、许可证模式和云端姿态设置都是部署身份的一部分。它们在每个副本中都必须相同，其受支持的组合会在启动时检查 —— 不匹配的 Pod 不会降级运行，而是直接退出。组合参见物理隔离。

滚动升级就是更换摘要

升级就是更换镜像摘要，并让迁移 Job 在新副本提供服务之前运行到完成。模式迁移只能向前：回滚镜像并不会回滚模式，所以先做备份，并保留上一个摘要以便回滚。应用本身如果以已发布产物的形式交付，则独立于镜像进行版本管理 —— 参见部署中的运行形态。

Kubernetes

本页内容