Airgapped/Disconnected Environment Installation Support

[itay-nvn-nv]

Problem

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:

1. Documentation: Official guide published covering image list per version, mirroring steps, CR configuration, and ServiceAccount patching workarounds
2. 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

Time Estimate (optional):

• Documentation only: 2-3 developer-days
• Native imagePullSecrets propagation fix: 3-5 developer-days
• Image list CLI tooling: 2-3 developer-days

Additional context (optional)

I've documented a working workaround here: https://github.com/runai-professional-services/knative-airgapped, this could serve as a reference for official documentation.

[github-actions]

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.

[kahirokunn]

/remove-lifecycle stale

[kahirokunn]

@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?

[kahirokunn]

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:

https://knative.dev/docs/install/operator/configuring-serving-cr/#private-repository-and-private-secrets

spec:
  registry:
    default: registry.internal.example.com/knative/${NAME}:1.22.0

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]

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.

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]

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]

"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]

You're absolutely right. This definitely matters. 👍

[github-actions]

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.

[kahirokunn]

/remove-lifecycle stale