This is an automated email from the ASF dual-hosted git repository.
squakez pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel-k.git
The following commit(s) were added to refs/heads/main by this push:
new d64181092 Fix #6895: move multi namespace installation to a new page
d64181092 is described below
commit d641810927139985e0a6dd92b3aad29ca5714695
Author: iamcipherdev <[email protected]>
AuthorDate: Tue Oct 20 08:36:13 2026 +0000
Fix #6895: move multi namespace installation to a new page
The Kustomize/OLM/Helm multi-namespace installation procedures are moved
from installation.adoc to a dedicated installation/multi-namespace.adoc
page, linked from the installation topology section and added to the
Antora nav.
---
docs/modules/ROOT/nav.adoc | 1 +
.../ROOT/pages/installation/installation.adoc | 162 +--------------------
.../{installation.adoc => multi-namespace.adoc} | 117 +--------------
3 files changed, 5 insertions(+), 275 deletions(-)
diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
index dcbf710d4..e1b2e55a6 100644
--- a/docs/modules/ROOT/nav.adoc
+++ b/docs/modules/ROOT/nav.adoc
@@ -8,6 +8,7 @@
** xref:installation/cert-manager.adoc[Configure Cert-Manager]
** xref:installation/keda.adoc[Configure Keda]
** xref:installation/knative.adoc[Configure Knative]
+** xref:installation/multi-namespace.adoc[Multi namespace installation]
** xref:installation/upgrade.adoc[Upgrade]
** xref:installation/uninstalling.adoc[Uninstalling]
** xref:installation/advanced/advanced.adoc[Advanced]
diff --git a/docs/modules/ROOT/pages/installation/installation.adoc
b/docs/modules/ROOT/pages/installation/installation.adoc
index 5b6317e18..05d1ac351 100644
--- a/docs/modules/ROOT/pages/installation/installation.adoc
+++ b/docs/modules/ROOT/pages/installation/installation.adoc
@@ -56,167 +56,7 @@ It's important to notice that when running the single or
multiple namespace oper
NOTE: RBAC custom configuration may vary depending on the installation
methodology.
-[[multi-namespace-kustomize]]
-== Install a multi namespace operator with Kustomize
-
-The repository includes a complete Kustomize example for an operator installed
in one namespace and watching two tenant namespaces. The `multi-namespace`
overlay installs the operator in `operators`, configures `WATCH_NAMESPACE` to
`tenant-a,tenant-b`, and grants the operator's ServiceAccount the required
namespaced permissions in both tenant namespaces. The operator also watches its
own `operators` namespace for the resources it manages there.
-
-The overlay does not create namespaces. Create the operator and tenant
namespaces before applying it:
-
-[source,shell script]
-----
-$ kubectl create namespace operators
-$ kubectl create namespace tenant-a
-$ kubectl create namespace tenant-b
-----
-
-Apply the overlay for the Camel K version you want to install:
-
-[subs=attributes+]
-----
-$ kubectl apply -k
github.com/apache/camel-k/install/overlays/multi-namespace?ref=v{last-released-version}
--server-side
-----
-
-The example creates the `camel-k-operator-tenant-ab` ServiceAccount in
`operators`. Each tenant RoleBinding points to that ServiceAccount across
namespaces, so the binding must be installed in every namespace listed in
`WATCH_NAMESPACE`. Granting the operator access to only one tenant namespace
will leave it unable to reconcile resources in the other namespaces.
-
-Verify the deployment, watched namespaces, and cross-namespace RoleBinding:
-
-[source,shell script]
-----
-$ kubectl -n operators get deployment camel-k-operator-tenant-ab
-$ kubectl -n operators get deployment camel-k-operator-tenant-ab \
- -o
jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="WATCH_NAMESPACE")].value}{"\n"}'
-tenant-a,tenant-b
-$ kubectl -n tenant-a get rolebinding camel-k-operator-tenant-a \
- -o jsonpath='{.subjects[0].namespace}/{.subjects[0].name}{"\n"}'
-operators/camel-k-operator-tenant-ab
-----
-
-The overlay is a two-tenant example. To use different namespaces, copy the
`tenant-a-ns-rbac` and `tenant-b-ns-rbac` overlay directories, change each
`namespace` and `nameSuffix`, update the `WATCH_NAMESPACE` value in
`operator/patch-envvars.yaml`, and add the new directories to the top-level
`kustomization.yaml`. Keep the RoleBinding subject namespace set to `operators`
(or change it together with the operator namespace) and keep its ServiceAccount
name aligned with the operator Deployment.
-
-[[multi-namespace-olm]]
-== Install a multi namespace operator with OLM
-
-The Camel K ClusterServiceVersion supports the OLM `MultiNamespace` install
mode. In this mode, the `OperatorGroup` selects the tenant namespaces and OLM
creates the required namespaced RBAC for the operator ServiceAccount. The
operator namespace is the namespace where the `Subscription`, `OperatorGroup`,
and operator Deployment are installed.
-
-Create the operator and tenant namespaces first:
-
-[source,shell script]
-----
-$ kubectl create namespace operators
-$ kubectl create namespace tenant-a
-$ kubectl create namespace tenant-b
-----
-
-Create an `OperatorGroup` in the operator namespace. An OLM namespace can have
only one `OperatorGroup`; edit the existing group instead of creating a second
one when necessary:
-
-[source,yaml]
-----
-apiVersion: operators.coreos.com/v1
-kind: OperatorGroup
-metadata:
- name: camel-k-multi
- namespace: operators
-spec:
- targetNamespaces:
- - tenant-a
- - tenant-b
-----
-
-Apply the group, then create the Camel K subscription from OperatorHub:
-
-[source,shell script]
-----
-$ kubectl apply -f operatorgroup.yaml
-$ curl -fsSL https://operatorhub.io/install/camel-k.yaml | kubectl apply -f -
-----
-
-The OperatorHub manifest creates a `Subscription` in `operators` using the
`stable-v2` channel and the `operatorhubio-catalog` CatalogSource. If your
cluster uses another catalog, keep the same `MultiNamespace` OperatorGroup and
change the Subscription's `source` and `sourceNamespace` to match that catalog.
-
-Wait for the CSV to succeed and verify the selected namespaces:
-
-[source,shell script]
-----
-$ kubectl -n operators get csv
-$ kubectl -n operators get operatorgroup camel-k-multi \
- -o jsonpath='{.spec.targetNamespaces[*]}{"\n"}'
-tenant-a tenant-b
-----
-
-The operator should now reconcile Integrations in both `tenant-a` and
`tenant-b`, while an Integration in an unlisted namespace remains outside this
OperatorGroup's scope.
-
-[[multi-namespace-helm]]
-== Install a multi namespace operator with Helm
-
-The Helm chart currently exposes two watch modes: the release namespace
(`operator.global=false`) and all namespaces (`operator.global=true`). It does
not accept a static comma-separated namespace list. To run a Helm-installed
operator for selected namespaces, install the chart in the operator namespace
and apply a small RBAC overlay for every tenant namespace.
-
-Install the chart using `camel-k` as the release name so the resource names
below match the commands:
-
-[source,shell script]
-----
-$ helm repo add camel-k https://apache.github.io/camel-k/charts/
-$ helm repo update
-$ kubectl create namespace operators
-$ kubectl create namespace tenant-a
-$ kubectl create namespace tenant-b
-$ helm install camel-k camel-k/camel-k -n operators \
- --set operator.global=false \
- --set operator.env[0].name=REGISTRY_ADDRESS \
- --set operator.env[0].value=<my-registry-address>
-----
-
-Set the watched namespaces on the chart-created Deployment:
-
-[source,shell script]
-----
-$ kubectl -n operators set env deployment/camel-k-operator \
- WATCH_NAMESPACE=tenant-a,tenant-b
-----
-
-The chart's namespaced RBAC is scoped to `operators`. Create one small
Kustomize overlay per tenant. You can use
`install/overlays/multi-namespace/tenant-a-ns-rbac/` and `tenant-b-ns-rbac/` as
templates, or use this equivalent overlay (replace `<tenant-namespace>` for
each tenant):
-
-[source,yaml]
-----
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-namespace: <tenant-namespace>
-resources:
--
github.com/apache/camel-k//pkg/resources/config/rbac/namespaced?ref=v{last-released-version}
-patches:
-- target:
- kind: RoleBinding
- patch: |-
- - op: add
- path: /subjects/0/namespace
- value: operators
- - op: replace
- path: /subjects/0/name
- value: camel-k-operator
-----
-
-The patch points every namespaced RoleBinding at `operators/camel-k-operator`,
the ServiceAccount created by this Helm release. Save the overlay once for
`tenant-a` and once for `tenant-b`, changing only `namespace` and the output
directory.
-
-Apply each tenant overlay after the Helm release:
-
-[source,shell script]
-----
-$ kubectl apply -k ./camel-k-multi-namespace/tenant-a-ns-rbac --server-side
-$ kubectl apply -k ./camel-k-multi-namespace/tenant-b-ns-rbac --server-side
-----
-
-Verify the Deployment setting and the cross-namespace permission before
creating an Integration:
-
-[source,shell script]
-----
-$ kubectl -n operators get deployment camel-k-operator \
- -o
jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="WATCH_NAMESPACE")].value}{"\n"}'
-tenant-a,tenant-b
-$ kubectl auth can-i --as=system:serviceaccount:operators:camel-k-operator \
- -n tenant-a get integrations.camel.apache.org
-yes
-----
-
-Repeat the Deployment patch and re-apply the tenant overlays after a Helm
upgrade, or maintain them as a Helm post-renderer. This keeps the chart release
and the manually managed tenant RBAC in sync.
+For installation procedures where the operator watches multiple namespaces,
see xref:installation/multi-namespace.adoc[Multi namespace installation].
[[bootstrap-configuration]]
== Setup the operator configuration
diff --git a/docs/modules/ROOT/pages/installation/installation.adoc
b/docs/modules/ROOT/pages/installation/multi-namespace.adoc
similarity index 50%
copy from docs/modules/ROOT/pages/installation/installation.adoc
copy to docs/modules/ROOT/pages/installation/multi-namespace.adoc
index 5b6317e18..fed3dcfe4 100644
--- a/docs/modules/ROOT/pages/installation/installation.adoc
+++ b/docs/modules/ROOT/pages/installation/multi-namespace.adoc
@@ -1,60 +1,6 @@
-[[installation]]
-= Camel K operator installation
+= Multi namespace installation
-Camel K allows us to run Camel integrations directly on a Kubernetes cluster.
To use it, you need to be connected to a cloud environment or to a local
cluster created for development purposes (ie, Minikube or Kind).
-
-[[kustomize]]
-== Installation via Kustomize
-
-https://kustomize.io[Kustomize] provides a declarative approach to the
configuration customization of a Camel-K installation. Kustomize works either
with a standalone executable or as a built-in to `kubectl`. The
https://github.com/apache/camel-k/tree/main/install[/install] directory
provides a series of base and overlays configuration that you can use. You can
create your own overlays or customize the one available in the repository to
accommodate your need.
-
-[subs=attributes+]
-----
-$ kubectl apply -k
github.com/apache/camel-k/install/overlays/all-namespaces?ref=v{last-released-version}
--server-side
-----
-
-You can specify as `ref` parameter the version you're willing to install (ie,
`v{last-released-version}`). The command above will install a descoped (global)
operator in the camel namespace. This is the suggested configuration in order
to manage Integrations in all namespaces.
-
-[[helm]]
-== Installation via Helm Hub
-
-Camel K is available in Helm Hub:
-
-```
-$ helm repo add camel-k https://apache.github.io/camel-k/charts/
-$ helm install camel-k camel-k/camel-k -n camel
-```
-
-More instructions on the https://hub.helm.sh/charts/camel-k/camel-k[Camel K
Helm] page.
-
-[[olm]]
-== Installation via Operator Hub
-
-Camel K is also available in Operator Hub. You will need the OLM framework to
be properly installed in your cluster. More instructions on the
https://operatorhub.io/operator/camel-k[Camel K Operator Hub] page.
-
-```
-$ kubectl create -f https://operatorhub.io/install/camel-k.yaml
-```
-
-You can edit the `Subscription` custom resource, setting the channel you want
to use. From Camel K version 2 onward, we're going to provide an installation
channel for each major version we're releasing (ie, `stable-v2`). This will
simplify the upgrade process if you choose to perform an automatic upgrade.
-
-NOTE: Some Kubernetes clusters such as Openshift may let you to perform the
same operation from a GUI as well. Refer to the cluster instruction to learn
how to perform such action from user interface.
-
-[[installation-topology]]
-== Installation topology
-
-When you decide to install the operator, you can decide to install the
following topology:
-
-* Global operator: a single global operator watching all namespaces.
-* Own namespace operator: a namespaces operator watching its own namespace
only.
-* Single namespace operator: an operator installed in a namespace and watching
another namespace.
-* Multi namespace operator: an operator installed in a namespace and watching
multiple namespaces.
-
-The namespace(s) to watch is configured via `WATCH_NAMESPACE` variable in the
operator `Deployment` resource. You can provide an empty value (watch all
namespaces), a single value (watch either the own namespace or any other
namespace) or a comma separated value (watching as many namespaces as provided).
-
-It's important to notice that when running the single or multiple namespace
operator, you _may_ need to provide the RBACs which are expected by the
operator to run properly. For such a configuration you can take as a reference
the `Kustomize` examples available in `/install/overlays/single-namespace/` and
`/install/overlays/multi-namespace/`. The last topology is probably the most
secure as it will avoid the operator to access to any resource outside those
namespaces for which you've pro [...]
-
-NOTE: RBAC custom configuration may vary depending on the installation
methodology.
+A multi namespace operator is installed in one namespace and watches multiple
tenant namespaces. The procedures below cover the supported installation
methods.
[[multi-namespace-kustomize]]
== Install a multi namespace operator with Kustomize
@@ -216,61 +162,4 @@ $ kubectl auth can-i
--as=system:serviceaccount:operators:camel-k-operator \
yes
----
-Repeat the Deployment patch and re-apply the tenant overlays after a Helm
upgrade, or maintain them as a Helm post-renderer. This keeps the chart release
and the manually managed tenant RBAC in sync.
-
-[[bootstrap-configuration]]
-== Setup the operator configuration
-
-Each installation method have its proper way to setup configuration. A common
one is the creation of a `Configmap` named
`camel-k-operator-configmap-configuration` and a `Secret` named
`camel-k-operator-secret-configuration` in the same namespace where the
operator is installed. If available, the operator will read the environment
variable from these resources.
-
-[[verify]]
-== Verify that the operator is up and running
-
-In order to verify that the operator is up and running, you should be able to
see a Camel K operator `Pod` running in the namespace used, for example:
-
-```
-kubectl get pods -n camel
-NAME READY STATUS RESTARTS AGE
-camel-k-operator-5b686db99f-c2k2s 1/1 Running 0 3m46s
-```
-
-[[test]]
-== Run some integration
-
-Once you've completed any of the above installation procedure, you'll be ready
to xref:running/running.adoc[run some integrations].
-
-[[special-requirements]]
-== Special clusters requirements
-
-Camel K installation is usually straightforward, but for certain cluster types
you need to apply specific configuration settings before installing it. You
need customized instructions for the following cluster types:
-
-- xref:installation/platform/gke.adoc[Google Kubernetes Engine (GKE)]
-- xref:installation/platform/iks.adoc[IBM Kubernetes Services (IKS)]
-
-[[registry]]
-== Development container registry configuration
-
-Camel K needs a container registry in order to push the generated Camel
applications and Kubernetes needs the same registry to pull and run them live.
The project offers a default development container registry that will simplify
quick starts, demo and testing. When running the project for the first time or
in a local environment you shouldn't worry as it will be completely transparent
to you. The development registry is controlled through the following
environment variables configuration:
-
-[cols="1,3,2", options="header"]
-|===
-| Name | Description | Default Value
-
-| ENABLE_DEV_REGISTRY
-| Run a demo container registry application in the same namespace as the Camel
K Operator.
-| true
-
-| ENABLE_DEV_REGISTRY_SECRET
-| Whether to secure the demo container registry with a default test user
(`admin/password`). In this case you need to provide a secret in the
Integration namespace and use the `pull-secret` trait configuration. Be aware
that the operator will store a secret named `ck-dev-registry` in the same
namespace where it is installed. You may copy and use it in your Integration
namespace for local development purposes.
-| false
-
-|===
-
-When ready to move to a real enterprise installation you will need to turn the
flag off (or remove it) and provide a proper
xref:installation/registry.adoc[production ready registry configuration].
-
-NOTE: if you don't remove the `ENABLE_DEV_REGISTRY` parameter, the operator
will overwrite any registry configuration at startup with its internal demo
registry.
-
-[[fine-tuning]]
-== Fine Tuning
-
-Camel K installation can be configured with certain special settings available
for experienced users. You can manage resources such as limiting memory and
CPU, provide a policy for `Pod` scheduling and `Toleration`. Please have a look
at xref:installation/advanced/advanced.adoc[Camel K fine tuning] to learn more
about advanced configuration.
+Repeat the Deployment patch and re-apply the tenant overlays after a Helm
upgrade, or maintain them as a Helm post-renderer. This keeps the chart release
and the manually managed tenant RBAC in sync.
\ No newline at end of file
