You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Airgapped/Disconnected Environment Installation Support #2216
There is no official documentation or native support for installing Knative Operator in airgapped/disconnected environments.
Current challenges:
No published list of required container images per Knative version
spec.registry.imagePullSecrets in KnativeServing CR does not propagate to ServiceAccounts (requires manual patching)
No global registry override option: users must configure multiple Helm values and CR fields separately
On OpenShift, users deploy OpenShift Serverless Operator and create a KnativeServing instance; edge/disconnected clusters face the same issues with no streamlined private registry configuration
Persona:
Platform Operator: responsible for deploying and managing Knative on Kubernetes clusters, particularly in enterprise environments with network restrictions.
Exit Criteria
One of the following:
Documentation: Official guide published covering image list per version, mirroring steps, CR configuration, and ServiceAccount patching workarounds
Native support:spec.registry.imagePullSecrets automatically propagates to all relevant ServiceAccounts, and a CLI command exists to list all required images for a given version
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
@itay-nvn-nv Thanks for raising this. I checked the current behavior, and spec.registry.imagePullSecrets is already propagated to the PodSpecs of the managed workloads, such as Deployments and Jobs.
Is there a specific issue caused by imagePullSecrets not being set on the ServiceAccounts?
I think Knative Serving should already be installable in an air-gapped environment with the Operator, as long as the required Serving images are mirrored into an internal registry.
For the managed Serving images, spec.registry.default can point them to the internal registry, for example:
Is there a specific image or resource that still cannot be configured this way?
this is actually the major hurdle i encountered - there is no clear list or "mapping" of all the images required for knative operator, and the available/required tags for each knative version.
In other words, am I correct in understanding that while Airgapped/Disconnected Environment Installation is currently supported, this issue is a request to improve the user experience when using it?
"supported" technically: while you can point the images to be pulled from a local registry, the process of getting them there is not documented and vague.
proper documentation would definitely be of help.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
Activity
github-actions commentedon Mar 31, 2026
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with
/reopen. Mark the issue asfresh by adding the comment
/remove-lifecycle stale.kahirokunn commentedon Apr 23, 2026
/remove-lifecycle stale
kahirokunn commentedon May 5, 2026
@itay-nvn-nv Thanks for raising this. I checked the current behavior, and
spec.registry.imagePullSecretsis already propagated to the PodSpecs of the managed workloads, such as Deployments and Jobs.Is there a specific issue caused by
imagePullSecretsnot being set on the ServiceAccounts?kahirokunn commentedon May 5, 2026
I think Knative Serving should already be installable in an air-gapped environment with the Operator, as long as the required Serving images are mirrored into an internal registry.
For the managed Serving images,
spec.registry.defaultcan point them to the internal registry, for example:https://knative.dev/docs/install/operator/configuring-serving-cr/#private-repository-and-private-secrets
If the internal registry requires authentication, spec.registry.imagePullSecrets can be used as well.
Is there a specific image or resource that still cannot be configured this way?
itay-nvn-nv commentedon May 5, 2026
this is actually the major hurdle i encountered - there is no clear list or "mapping" of all the images required for knative operator, and the available/required tags for each knative version.
took me some trial and error to write the script, you can notice the final image list here: https://github.com/runai-professional-services/knative-airgapped/blob/af308902a5c6d535ed9dd91b3b3d8beb1718bcfe/prepare.sh#L179
kahirokunn commentedon May 7, 2026
In other words, am I correct in understanding that while Airgapped/Disconnected Environment Installation is currently supported, this issue is a request to improve the user experience when using it?
itay-nvn-nv commentedon May 8, 2026
"supported" technically: while you can point the images to be pulled from a local registry, the process of getting them there is not documented and vague.
proper documentation would definitely be of help.
kahirokunn commentedon May 8, 2026
You're absolutely right. This definitely matters. 👍
github-actions commentedon Aug 7, 2026
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with
/reopen. Mark the issue asfresh by adding the comment
/remove-lifecycle stale.kahirokunn commentedon Aug 7, 2026
/remove-lifecycle stale