ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

Fission 将 OCI 原生包交付作为默认冷启动路径:RFC-0012 全解析

Fission 将 OCI 原生包交付作为默认冷启动路径:RFC-0012 全解析 云原生后端【免费下载链接】fissionFast and Simple Serverless Functions for Kubernetes项目地址https://gitcode.com/gh_mirrors/fi/fission点击查看免费下载Fission 是一个面向 Kubernetes 的 Serverless 函数平台。本文围绕 RFC-0012 展开在 RFC-0001 搭建的 OCI 双路径fetcher 拉取 Path A / kubelet 镜像卷 Path B基础上RFC-0012 通过默认翻转消费者开关、新增构建产物生产者、引入按镜像空闲池回收器三件事把 OCI 变为 Fission v1.27 的默认包交付方式。读完本文你将掌握如何配置packageRegistry、executor.enableOCIImageVolume等关键参数理解Path A / Path B / B-fetcher的路径选择规则、源码级实现原理与升级路径。背景从 RFC-0001 的 opt-in 到 RFC-0012 的默认RFC-0001 首次在 Fission 中引入 OCI 原生交付Package 的Deployment归档可携带新增的OCI字段函数代码以 OCI 镜像形态存在于容器仓库中由 kubelet / 仓库分发和缓存而不是每次为每个 Pod 拉取并解压 tarball。它构建了两条交付路径Path A通用基线Pod 内的 fetcher sidecar 拉取 OCI 镜像将其文件系统解压到共享的/userfunc卷然后走既有的/v2/specialize加载。可在 Kubernetes 1.32当前支持下限上运行保留通用热池。Path BK8s 1.33 的优化路径poolmgr 按(environment image)预热 Pod通过 KEP-4639 的ImageVolumeSource将代码镜像只读挂载到/userfunc特化仅剩加载信号无拉取/解压。kubelet 拉取并缓存层同时解析拉取密钥。但 RFC-0001 留下两个结构性缺口两条路径都只是 opt-in且只有自带预构建镜像的用户才能使用 OCI——因为producer生产者被推迟了fission fn create --code的常规路径buildermgr 构建 →updatePackage写入 storagesvc URL见 pkg/buildermgr/common.go从不产生 OCI 工件。RFC-0012 的决策正是没有 producer 的 OCI 默认 只是对少数人的营销因此其核心是 producer。三件事默认翻转到 OCI 的三个关键动作RFC-0012 用三个可独立交付的动作把 OCI 变成默认消费者翻转Consumer flipexecutor.enableOCIImageVolume默认值改为true让每个符合条件的 OCI 包在集群支持时都走 Path B运行时门控在 k8s 1.33 以下自动降级到 Path A。生产者Producer真正的解锁新增packageRegistrychart 配置块配置后每次成功构建都会把部署归档发布为 digest 固定的单层 OCI 镜像Package 被改写为Archive{Type: oci}。使用fission fn create --code的用户零逐包操作即可获得 OCI 交付。未配置仓库时 tarball 输出仍自动生效。按镜像空闲池回收器Per-image idle pool reaper当每个构建出的包都是自己的镜像时保证每个(env, image)热池不无限累积这是经济性的关键使能器。tarball 路径不废弃——它仍是回退路径也是未配置仓库的安装的默认路径。动机今天的冷启动关键路径tarball与 Path B 的对比以 main 分支验证过的 poolmgr 冷启动关键路径为例Router → executorgetServiceForFunctionRPCpkg/router/resolver_executor.go。Executor 选取热 PodchoosePod并 RPC 到该 Pod 的 fetcher sidecarpkg/executor/executortype/poolmgr/gp_specialize.go。fetcher 通过 HTTP从 storagesvc 下载完整部署归档——每个 Pod 一次每个 Pod 都下载pkg/fetcher/fetcher.go唯一缓存是 Pod 自己的共享卷。在共享卷上解压pkg/fetcher/fetcher.go然后通过环境的/v2/specialize加载。Path B已交付、opt-in把步骤 2–4 替换为一次仅加载的 POST到环境pkg/executor/executortype/poolmgr/oci_specialize.go代码已经由 kubelet 以只读方式挂载、digest 固定并像任何镜像层一样缓存在节点上。同一节点上 N 个特化同一函数的 Pod 只花费一次拉取而不是 N 次下载。采用率结构性受限的原因在于RFC-0001 推迟了 producerBuildKit builder --oci-pushRFC-0001 第 53 行所以只有自带预构建镜像的用户才能用 OCI。常规路径——fission fn create --codebuildermgr 构建updatePackage写 storagesvc URL——从不产生 OCI 工件。目标与非目标目标配置了仓库时每个构建出的包都成为 digest 固定的 OCI 工件无需逐包 opt-in有能力的集群上每个符合条件的 OCI 包默认通过镜像卷Path B交付热池经济性在大量包规模下保持有界空闲池回收补齐 Path B 最大的资格缺口带 Secrets/ConfigMaps 的函数未配置仓库的安装零行为变化tarball 函数零回归。非目标从 Dockerfile / BuildKit 在集群内构建运行时镜像本 RFC 只打包构建输出不新增镜像构建工具链捆绑或运维一个仓库packageRegistry.enabled默认保持false因为 Fission 无法凭空变出一个仓库--deploy file.zip包的 CLI 侧推送不同凭证/信任模型见开放问题仓库保留/GC 工具storagesvc 的archivePruner没有仓库对应物操作员的保留策略适用——已文档化弃用 storagesvc 或 tarball 路径工件签名cosign工件形态兼容——后续工作惰性加载快照器stargz 等。设计构建产物发布 OCI 工件谁推送builder pod 的 fetcher通过扩展的/upload模式。buildermgr 已经把工件处理委托给 builder-pod fetcherpkg/buildermgr/common.go 的fetcherC.Upload(ctx, uploadReq)fetcher 在自己的共享卷上有构建工件且已经链接pkg/oci和 kauth 密钥链。线缆变更pkg/fetcher/types.goArchiveUploadRequest新增OCIPush *OCIPushSpec{Repository, PublishedRepository, PushSecretName, InsecureHosts, FallbackToStorage}。ArchiveUploadResponse新增OCI *fv1.OCIArchive与既有 URLChecksum 字段并列以及OCIPushError。当OCIPush被设置时fetcher 通过新的pkg/oci/push.go推送部署目录zip 前——上传处理器只在ArchivePackage为 true 时归档见 pkg/buildermgr/common.go// PushDirectory publishes dir as a single-layer OCI image and returns its digest. func PushDirectory(ctx context.Context, dir, repoTag string, kc authn.Keychain) (digest string, err error)实际签名为func PushDirectory(ctx context.Context, dir, repo string, opts PushOptions) (imageRef, digest string, err error)pkg/oci/push.goPushOptions携带 Keychain 与 InsecureRegistries。工件形态真正的 OCI 镜像 manifest——empty.Imagemutate.AppendLayers加一层目录内容的 targzip 层置于镜像根最小 config。这刻意不是ORAS 工件 manifestkubelet 镜像卷和 containerd 的镜像存储消费的是镜像 manifest而 pkg/oci/extract.go 的ExtractImage用mutate.Extract扁平化它——构造上对两条消费路径字节兼容。层是确定性的排序遍历、时间戳清零、无属主信息所以重建相同内容得到相同 digest仓库去重 blob符号链接和特殊文件被拒绝Path A 提取器拒绝链接因为它们是逃逸途径发布它们会产生无法消费的工件。Package 改写updatePackagepkg/buildermgr/common.go 及之后是写入构建归档的唯一咽喉点当上传响应携带 OCI 时它写入Archive{Type: ArchiveTypeOCI, OCI: OCIArchive{Image, Digest, ImagePullSecrets: [packageRegistry.pullSecret]}}。digest 总是被设置由推送返回——默认 digest 固定tagrepositoryPrefix/namespace/pkg:short-digest只是人类可读的便利。既有 rollout 机制PackageRef.ResourceVersion 传播、fsCache 失效不受影响Package 更新就是触发器和今天一样。而setPackageOCIPublishConditionpkg/buildermgr/common.go把发布结果记录到 Package 条件publishedTrue/ degradedFalse回退到 tarball/ 无 producer 参与清除过期条件。推送失败packageRegistry.fallbackToStorage默认true→ 记录日志 回退到 storagesvc tarball 上传构建仍成功OCIPublishDegradedPackage 条件浮出降级。设为false时构建失败对需要 OCI 溯源的企业是严格模式。设计把 Path B 翻转为默认消费者侧executor.enableOCIImageVolume在 charts/fission-all/values.yaml 中翻转为true原为false即 values.yaml:235。chart 翻转默认值运行时门控做降级ImageVolumeGatepkg/executor/util/imagevolume.go要求同时满足环境变量ENABLE_OCI_IMAGE_VOLUMEtrue和 k8s ≥ 1.33启动时检测一次vendor 后缀容忍见ImageVolumeSupported对33的TrimRight所以开了标志的 1.32 集群只是跑 Path A——正确且已交付。无需 Helm 版本模板化翻转只是一行 valuesfalse是逃生舱旧默认值。注意ImageVolumeGate的解析细节ENABLE_OCI_IMAGE_VOLUME为空时返回 false值非法会记录错误并保持禁用操作员要求了该功能静默降级不可接受discovery 探测失败同样大声失败。设计Path B 资格补齐——B-fetcher 变体Secrets/ConfigMaps今天getFunctionOCIPoolpkg/executor/executortype/poolmgr/oci.go会把带 Secrets/ConfigMaps 的函数排除在 Path B 之外因为 fetcher 把它们物化到共享卷pkg/fetcher/fetcher.go而 Path B Pod 没有 fetcher。补齐方案第二个 Path B 池变体B-fetcher即 newdeploy 已交付的 Path B 模式pkg/executor/executortype/newdeploy/newdeploy.gofetcher sidecar 留在 Pod 中镜像卷挂载到 fetcher 的 store 路径fetcher 既有的RootStat(storePath)早退跳过拉取。fetcher 仍执行FetchSecretsAndCfgMaps和加载——零新增 fetcher 代码。特化经由 fetcher:8000/specialize而不是loadOnlySpecialize路由。该变体影响 Pod spec所以进入ociPoolHashpkg/executor/executortype/poolmgr/oci.go 的parts切片追加variantfetcher标记保持 RFC-0001 的不变量池哈希覆盖每个影响 Pod spec 的归档字段。资格选择变为有 secrets/configmaps → B-fetcher无 → B-direct今天无 fetcher 的变体。NetworkPolicyexecutor→8000 入站已被允许。被拒绝的备选原生投射卷结构上不可能——池 Pod 在函数身份之前就已存在且按镜像池是每个包而 secrets 是每个函数经特化 payload 中继 secrets把 secret 材料泄漏到 executor 和 HTTP 路径有大小限制——出于安全姿态拒绝。源码中getFunctionOCIPool还展示了永久排他条件env v1、AllowedFunctionsPerContainerInfinite、KeepArchive以及 NotFound 回退 Path A、其他读错误返回让冷启动可见失败并由 router 重试而不是静默钉住错误的池类型。设计按镜像空闲池回收器翻转的前提生产者开启后每个构建出的包都成为自己的池N 个包 ×poolsize热 Pod今天永不收缩只有特化过的Pod被回收空的按镜像池Deployment永远活着。规格每个按镜像池key 含/pkg/executor/executortype/poolmgr/oci.go 的poolKey记录lastActive在创建和每次路由到它的特化时触摸。回收器回合poolmgr 空闲策略/池 reconciler 的扩展在满足以下条件时删除按镜像池没有当前特化的 Pod通过POOL_OCI_IMAGE_HASHPod 标签检查且now − lastActive executor.ociPoolIdleReapTime新值默认 5m与 Pod 空闲超时不同见 charts/fission-all/values.yaml。通用环境池imageHash 永不回收——与今天完全一致。回收 删除池 Deployment 在池锁下删除 map 条目所以并发的GetFuncSvc能干净重建按需池创建本就是冷启动路径。回收后的第一次冷启动付出池创建 kubelet 缓存的拉取——热节点上便宜这正是激进窗口可行的不对称性。永久 Path A 居民与路径选择决策表以下三类函数永久留在 Path A / tarball文档化为永久非 TODO排除项为什么是结构性的Env v1只说 v1 特化契约store 路径是userloadOnlySpecialize发/v2/specialize。遗留且冻结。AllowedFunctionsPerContainerInfinitestore 路径按函数 UID一个共享镜像挂载无法服务它除非按函数建池。这些环境本就按设计摊销冷启动。KeepArchive环境新增JVM 风格环境期望LoadReq.FilePath是归档文件OCI 工件是目录形态镜像卷 subPath 必须是目录RFC-0001 修订。生产者和消费者两侧都排除tarball 输出。路径选择决策表pkg/executor/executortype/poolmgr/oci.go 中getFunctionOCIPool与ociPoolHash的落地实现Package 归档集群函数交付方式url/literaltarball任意任意fetcher 下载不变oci1.33 或标志关任意Path Afetcher OCI 拉取oci≥1.33标志开无 secrets/cfgmapsenv v2非 Infinite非 KeepArchivePath B-direct无 fetcheroci≥1.33标志开有 secrets/cfgmapsPath B-fetchersidecar 仅用于 secretsoci≥1.33标志开env v1 / Infinite / KeepArchivePath A配置一个可复制到 values.yaml 的完整示例RFC-0012 给出的配置骨架与 charts/fission-all/values.yaml 的注释对齐packageRegistry: enabled: false # 生产者主开关无仓库 tarball今天的行为 repositoryPrefix: # 例如 ghcr.io/myorg/fission-packages仓库布局 prefix/namespace/pkg pushSecret: # builder 命名空间中的 dockerconfigjson secret写凭证 pullSecret: # 只读 secret盖印到 Archive.OCI.ImagePullSecrets insecureHosts: # 逗号分隔列表复用 FETCHER_ALLOW_INSECURE_REGISTRIES 语义 fallbackToStorage: true # 推送失败 - tarball OCIPublishDegraded 条件false 构建失败 executor: enableOCIImageVolume: true # 已翻转运行时门控于 k8s 1.33 ociPoolIdleReapTime: 5m # 新按镜像池空闲回收窗口高级publishedPrefixas shipped 中新增的旋钮charts/fission-all/values.yaml把推送端点与记录的消费引用解耦——注册表 split-brain风险 1被 CI 自身证实构建经集群 DNS 推送而 kubelet 拉取 NodePort 名称。同一注册表两个名字digest 在两个名字间固定身份。当节点与 Pod 以不同地址访问注册表时如 NodePort 暴露的集群内注册表在此设置节点可见前缀它被记录到包中而推送仍走repositoryPrefix。CLI 表面默认路径无新标志——生产者是服务端决策这正是特性本身。fission pkg info/getdeploy显示镜像引用 digest逃生舱注解fission.io/package-delivery: tarball让单个包退出生产者。推送与拉取凭证刻意分离最小权限。把现有构建包迁移到 OCI 配置packageRegistry后执行fission pkg rebuild重建会重新推送并改写归档。安全设计默认 digest 固定与边界默认 digest 固定Package 记录推送的 digestkubeletPath B和 fetcherPath Apkg/oci/extract.go都校验它——注册表中的 tag 变更无法改变运行的内容。Path B 上 digest 嵌入镜像引用repo:tagsha256:...见 pkg/executor/util/imagevolume.go 的OCIVolumeReference因为 Path B 没有 fetcher 可校验。注册表内容是代码执行等价物RFC 强制要求文档给出注册表 RBAC 和多租户隔离的prefix/namespace/pkg布局指引。Path A 保留 RFC-0001 交付的提取加固os.Root 限制、符号链接/穿越拒绝、2 GiB 解压上限见 pkg/oci/extract.go。Path A 拉取经集群 DNS 在 fetcher 允许列表下解析Path B 拉取经节点解析器在 containerd 信任配置下解析——注册表 URL 必须节点可解析见风险。推送 secret 只存在于 builder 命名空间fetcher 经既有pkg/oci.Keychainkauth解析它fetcher RBAC 已含secrets: get。延迟分析什么移出了关键路径步骤今天tarballPath AOCI 拉取Path B-directPath B-fetcherRouter → executor RPC✓✓✓✓choosePod✓✓✓✓Executor → fetcher RPC✓✓—✓localhost无下载包传输每 Pod 全量下载每 Pod 注册表拉取—kubelet 缓存挂载—解压✓—拉取时已解压——Secrets 物化fetcherfetchern/a不符合条件fetcher仅 k8s API 获取环境加载/v2/specialize✓✓✓✓Path B 下移出关键路径的部分拉取发生在池创建时由 kubelet 缓存摊销并被包的所有函数共享而不是特化时。生产者把推送时间加到构建墙钟不是冷启动由 Gate B 测量并发布。池回收后的第一次冷启动付出池创建 热节点缓存。失败模式速查失败路径行为构建时注册表宕机生产者推送失败 → tarball 回退 OCIPublishDegraded条件默认或构建失败严格冷启动时注册表宕机Afetcher 拉取失败 → 特化错误 → executor 错误/重试——与今天 storagesvc 宕机对齐冷启动时注册表宕机B池存在不受影响——镜像已挂载在热 Pod 中严格优于今天冷启动时注册表宕机B新池kubelet ImagePullBackOff → 池 ready-wait 超时 → 冷启动报错kubelet 重试恢复后自愈无自动 tarball 回退生产者之后可能没有 tarball——已文档化digest 不匹配A / Bfetcher 拒绝 / kubelet 拒绝固定引用——fail closed镜像从注册表删除两者冷启动失败直到重建注册表保留是操作员职责显式非目标工件 2 GiB 上限Afetcher 拒绝生产者在构建时对超限工件警告Path B 不受影响——kubelet 无此上限executor 重启且带按镜像池BRFC-0001 交付的采纳instanceID 注解补丁adoptPerImagePoolDeployments标志关闭且存在活跃按镜像池B池 reconciler 清理函数下次冷启动回退 Path A推送 secret 轮换生产者下次构建拾取新 secret每次构建解析过期凭证 → 上述推送失败路径兼容性 / 升级所有变更都是增量的既有 url/literal 包及其池不受影响。既有 OCI 包在翻转后自动获得 Path BenableOCIImageVolume: false恢复旧默认。把既有构建包迁移到 OCI 配置packageRegistry后fission pkg rebuild重建会重新推送并改写归档。版本下限不变生产者和 Path A 在 1.32 下限Path B 在 1.33 自门控。当 Fission 自身下限到 1.33 时运行时门控变为遗留。源码验证在池密钥与哈希上的实现RFC-0012 的实现已在代码中落地As shipped 节确认 Phases 1–4 一起落地ociPoolHashpkg/executor/executortype/poolmgr/oci.go覆盖 referencedigest、subPath、pull secrets、fetcher 变体位——两个会产出不同 Pod 的函数永远不会别名到同一池。poolKey/envPoolKeyPrefixMatch同文件 L67-L78按镜像池 key 为envUID/imageHash空哈希 → 纯环境 key字节级等同旧行为。hasFetcherL60-L62普通池总有 fetcherB-direct 永不B-fetcher 保留。镜像卷组装AddImageVolumepkg/executor/util/imagevolume.go卷引用嵌入 digest pinPullIfNotPresent只读挂载subPath 规范化在MergePodSpec之后调用以防运行时 Pod spec 剥离挂载并追加ImagePullSecrets给 kubelet。Producer 配置的 chart 侧管道charts/fission-all/templates/buildermgr/deployment.yamlrequired校验 repositoryPrefix、fallbackToStorage 默认 true、insecureHosts 与 fetcher 的 allowlist 合并后也注入 executor Deploymentcharts/fission-all/templates/executor/deployment.yaml让 1.33 集群上生产包的 Path A 消费也能工作。发布分阶段与验证RFC-0012 的每个阶段都可独立发布已全部落地Phase 1 — 按镜像空闲池回收器触碰poolmgr/gpm.go池 map 记账、空闲策略/池 reconciler、oci.gochartexecutor.ociPoolIdleReapTime。测试回收资格表、与并发GetFuncSvc重建竞争、集成Path B 池在空闲窗口后消失并在下个请求重建。Phase 2 — B-fetcher 变体触碰oci.go变体选择 哈希位、gp_deployment.go复制 newdeploy 模式的 fetcher 保留按镜像 Pod spec、gp.goB-fetcher 池经 fetcher 路由特化。测试TestOCIPathBSecrets。Phase 3 — 消费者默认翻转只触碰values.yaml门控逻辑已交付。测试1.32 腿证明自动降级1.36 腿证明 Path B升级测试。Phase 4 — 生产者pkg/oci/push.go新、pkg/fetcher/types.go Upload 处理器推送模式 回退、pkg/buildermgr/注册表配置管道、updatePackageOCI 写入、OCIPublishDegraded条件、chartpackageRegistry块、KeepArchive 生产者排除。复用 CI 现有的 localhost-NodePort 测试注册表。TestOCIProducerBuild在 v1.36 腿断言全链路。Phase 5 — 文档、UX、迁移带注册表配置的 Quickstart 作为推荐安装迁移指南OCI 包的 spec save/apply 往返基准发布逃生舱注解。落地差异As shipped与已证实风险Phases 1–4 在一个 PR 中一起落地实现与合前审查驱动了以下对提案的差异packageRegistry.publishedPrefix新旋钮解耦推送端点与记录的消费引用。按镜像池默认 poolsize 1环境 poolsize 对按镜像池按 PACKAGE 相乘首个 CI 运行证实了饱和热深度仍是通用池的职责kubelet 缓存重建让按镜像冷启动便宜。推送密钥链跳过 ServiceAccount 解析oci.NoServiceAccountbuilder Pod 以fission-builder运行对 pull 密钥链解析的fission-fetcherSA 没有 RBAC——且 SA imagePullSecrets 是拉取概念推送只经显式推送 secret 认证。回收窗口下限有效按镜像空闲窗口永不短于池的 pod-ready 超时 1m5m 默认恰等于 pod-ready 超时镜像拉取受限的首次冷启动可能在终点线被回收choosePod在 Pod 认领时重新触摸活动时钟。回收驱动的销毁有界30sAPI 中断不会卡死池 actor。生产者可观测性fission_buildermgr_oci_publish_total{resultpublished|degraded} 降级时的 buildermgr 错误日志逐包条件让全舰队注册表中断不可见fission_executor_oci_pool_reap_failures_total保持 Gate C 回收计数器诚实PACKAGE_REGISTRY_ENABLED解析失败与缺失前缀一样硬失败启动。上传失败错误保真fetcher 曾在上传失败时也删除构建工件导致 buildermgr 客户端的 5xx 重试返回 no such file严格模式推送错误被掩盖现在只在成功时删除工件也让重试有意义。前三大风险及缓解注册表端点 split-brain同一 URL 必须被 fetcher 推送集群 DNS、allowlist、fetcher 拉取同、和kubelet节点解析器、containerd 信任都可达/信任。仅集群 DNS 的注册表会让 Path B 失败而构建和 Path A 成功。缓解文档强制节点可解析 URLbuildermgr 记录注册表可达性预检Phase 4 在 kind 和一个托管 provider 上验证。生产者规模下只读、digest 固定的/userfuncopt-in 用户自选生产者把每个构建函数路由到只读挂载__pycache__、JVM scratch、代码旁写文件的环境。缓解Phase 4 早期按支持环境做兼容矩阵驱动排除列表KeepArchive 的来源排除也是生产者侧的不兼容环境直接保持 tarball。池经济性无法收敛N 包 × poolsize×2 变体拆分只由空闲窗口约束假设是 kubelet 缓存重建足够便宜以支持激进窗口。Gate C 证伪应急按镜像池默认poolsize1已作为回退杠杆落地。开放问题tag 保留指引digest 固定消费使 tag 成为装饰操作员可多激进地 GC。按命名空间仓库 vs 扁平布局作为默认提议prefix/namespace/pkg。--deploy包的 CLI 侧推送客户端凭证模型——后续 RFC 或 phase 6。OCIPublishDegraded是否也应作为 buildermgr 上的 Prometheus 指标浮出结论与参考RFC-0012 让 OCI 成为 Fission 的默认冷启动路径配置一个注册表fission fn create --code的每个构建自动获得 digest 固定的 OCI 镜像交付在 1.33 集群上经 kubelet 镜像卷挂载由按镜像池回收器保持热池有界。tarball/storagesvc 路径完整保留未配置注册表的安装零行为变化。想深入实现的读者可继续阅读RFC-0001 原文、RFC-0012 原文、生产者推送核心 pkg/oci/push.go、Path A 提取与加固 pkg/oci/extract.go、池哈希与资格选择 pkg/executor/executortype/poolmgr/oci.go、Path B 门控 pkg/executor/util/imagevolume.go、buildermgr 咽喉 pkg/buildermgr/common.go、wire 类型 pkg/fetcher/types.go以及 chart 配置 charts/fission-all/values.yaml。赞分享云原生后端【免费下载链接】fissionFast and Simple Serverless Functions for Kubernetes项目地址https://gitcode.com/gh_mirrors/fi/fission点击查看免费下载相关推荐终极指南如何通过Upptime智能重试机制实现99.99%网站可用性终极指南如何通过Upptime智能重试机制实现99.99%网站可用性 Upptime是一款基于GitHub Actions的开源监控工具通过智能重试机制和自云原生后端Fission OCI 原生包交付RFC-0001实践指南用容器镜像替代 tarball 分发函数代码Fission OCI 原生包交付RFC 0001实践指南用容器镜像替代 tarball 分发函数代码 Fission 的 RFC 0001 在 Fiss云原生后端Fission 流式调用路径RFC-0008为 Kubernetes Serverless 函数解锁 SSE、分块传输与 WebSocketFission 流式调用路径RFC 0008为 Kubernetes Serverless 函数解锁 SSE、分块传输与 WebSocket 导读 RFC云原生后端上一篇MonoGame字体图集生成BMFont与自定义渲染器终极指南下一篇hexo-theme-3-hexo个性化指南代码高亮、背景图与字体样式深度定制创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表