Deploy on Oracle Kubernetes Engine (OKE)
The reference-validated knext deployment path — OKE with OCI Object Storage (S3-compatible) and the Kourier ingress-class fix.
OKE has been validated end-to-end with scale-to-zero and bytecode caching verified on a live cluster, so this guide is a tested path. The general control-plane install is on Operator & the NextApp CRD; the prerequisites and config walkthrough are in Getting started. This page covers only the OCI-specific pieces.
1 · Create the cluster
Create an OKE cluster (managed nodes), then fetch a kubeconfig. OKE kubeconfigs use the OCI CLI's
session-token auth — the kubeconfig invokes oci ce cluster generate-token, so the OCI CLI
must be installed and authenticated on whoever runs kubectl:
oci ce cluster create-kubeconfig \
--cluster-id <cluster-ocid> \
--file ~/.kube/config \
--region <region> \
--token-version 2.0.0For the bytecode-cache PVC, knext needs a StorageClass that provisions writable volumes. On OKE
the OCI Block Volume provisioner ships as the oci-bv StorageClass:
kubectl get storageclass oci-bv2 · Install Knative, Kourier, cert-manager, and the operator
Follow Operator & the NextApp CRD for the one-command bundle install. The prerequisites — Knative Serving + Kourier, cert-manager, and a StorageClass — are listed in Getting started.
The Kourier ingress-class is the OKE gotcha. If knext apps are unreachable through the ingress,
the cause is usually that Knative Serving's config-network ConfigMap (namespace
knative-serving) left ingress-class unset, so Serving never programmed routes against
Kourier. The operator's install bundle ships a declarative config-network ConfigMap that pins
ingress-class: kourier.ingress.networking.knative.dev (the full controller-qualified form — the
short kourier.knative.dev form does not match and leaves routes unprogrammed). Apply the
bundle with kubectl apply --server-side so this ConfigMap merges into the one Knative Serving
owns rather than clobbering it.
3 · Storage — OCI Object Storage via the s3 provider
knext storage accepts exactly gcs, s3, and minio (see
Multi-cloud deploy). OCI Object Storage exposes an S3-compatible endpoint,
so use provider: 's3' with the OCI S3-compat endpoint and a Customer Secret Key (an
S3-compatible access-key/secret pair you generate against your OCI user).
The OCI S3-compat endpoint format is:
https://<namespace>.compat.objectstorage.<region>.oraclecloud.comwhere <namespace> is your tenancy's Object Storage namespace. Alternatively, run self-hosted
MinIO in-cluster and use provider: 'minio'.
4 · Cache — Redis
ISR / data cache uses Redis (cache.provider: 'redis'). Point cache.url at OCI Cache (managed
Redis) or a self-hosted Redis Service. cache.url is required when the provider is redis.
5 · Registry — OCIR
Push the app image to OCI Registry (OCIR), e.g.
<region-key>.ocir.io/<tenancy-namespace>/<repo>. The operator rejects any image that is not
digest-pinned (@sha256:…); kn-next deploy resolves the digest automatically.
6 · Complete kn-next.config.ts
import type { KnativeNextConfig } from '@knext/core';
const config: KnativeNextConfig = {
name: 'storefront',
registry: '<region-key>.ocir.io/<tenancy-namespace>/storefront',
storage: {
provider: 's3', // OCI Object Storage is S3-compatible
bucket: 'storefront-assets',
region: '<region>', // e.g. us-ashburn-1
endpoint:
'https://<namespace>.compat.objectstorage.<region>.oraclecloud.com',
publicUrl:
'https://<namespace>.compat.objectstorage.<region>.oraclecloud.com/storefront-assets',
// S3-compatible access key / secret (an OCI Customer Secret Key). Prefer
// injecting these via env/Secrets rather than committing them.
accessKey: process.env.OCI_S3_ACCESS_KEY,
secretKey: process.env.OCI_S3_SECRET_KEY,
},
cache: {
provider: 'redis',
url: process.env.REDIS_URL || 'redis://storefront-redis.default.svc.cluster.local:6379',
keyPrefix: 'storefront',
},
scaling: { minScale: 0, maxScale: 20 }, // minScale 0 = scale to zero
};
export default config;7 · Deploy and verify scale-to-zero
kn-next deploy --registry <region-key>.ocir.io/<tenancy-namespace>/storefrontkn-next deploy builds the standalone image, pushes it (resolving the digest), and applies the
NextApp CR; the operator reconciles it into a Knative Service. Confirm the service scales to zero
when idle:
# After the idle window, the app's pods should be gone:
kubectl get pods -l serving.knative.dev/service=storefront
# (no resources) — the ksvc scaled to zero
# The next request cold-starts a pod; the URL resolves either way:
kubectl get ksvc storefront -o jsonpath='{.status.url}'A cold request reprovisions a pod; the bytecode cache (when
spec.cache.enableBytecodeCache is set) shortens that cold start by reusing the persisted V8
compile cache. See Bytecode caching and Scale to zero.
Deploy on Azure Kubernetes Service (AKS)
Run knext on AKS with MinIO (or an S3 gateway) for assets, Azure Cache for Redis, and ACR — Azure Blob is not a knext storage provider.
Deploy on RedHat OpenShift (on-premise)
Run knext on on-prem OpenShift via the OpenShift Serverless operator, self-hosted MinIO and Redis, and an internal registry.