From b489d8cf66a14958046060ac70458bfcc6e4fd80 Mon Sep 17 00:00:00 2001 From: kahirokunn Date: Thu, 28 May 2026 11:28:34 +0900 Subject: [PATCH 1/2] Update multi-cluster docs for secretreader v0.1.2 Signed-off-by: kahirokunn --- ...native-to-remote-clusters-with-operator.md | 9 ++-- .../operator/multi-cluster-deployment.md | 47 ++++++++++++------- 2 files changed, 35 insertions(+), 21 deletions(-) diff --git a/docs/blog/articles/deploying-knative-to-remote-clusters-with-operator.md b/docs/blog/articles/deploying-knative-to-remote-clusters-with-operator.md index 998bc9407b..8dfa40300c 100644 --- a/docs/blog/articles/deploying-knative-to-remote-clusters-with-operator.md +++ b/docs/blog/articles/deploying-knative-to-remote-clusters-with-operator.md @@ -77,16 +77,17 @@ knative_operator: - name: secretreader execConfig: apiVersion: client.authentication.k8s.io/v1 - command: /credential-plugin/secretreader-plugin + command: /access-plugins/secretreader/bin/secretreader-plugin + interactiveMode: Never provideClusterInfo: true plugins: - name: secretreader - image: registry.k8s.io/cluster-inventory-api/secretreader:v0.1.1 - mountPath: /credential-plugin + image: registry.k8s.io/cluster-inventory-api/secretreader:v0.1.2 + mountPath: /access-plugins/secretreader remoteDeploymentsPollInterval: 10s ``` -The provider name in `accessProvidersConfig.providers[].name` must match the plugin name in `plugins[].name`. The Operator uses that name to connect the `ClusterProfile` access provider entry to the credential plugin configuration. +The provider name in `accessProvidersConfig.providers[].name` must match the access provider name in `ClusterProfile` status. The `execConfig.command` points to the plugin binary mounted from the image volume. If you do not use Helm, you can patch an existing Operator Deployment. The important pieces are the same: mount the access provider configuration, mount the credential plugin binary, and start the Operator with `--clusterprofile-provider-file`. diff --git a/docs/versioned/install/operator/multi-cluster-deployment.md b/docs/versioned/install/operator/multi-cluster-deployment.md index 9518355f49..f5339497f8 100644 --- a/docs/versioned/install/operator/multi-cluster-deployment.md +++ b/docs/versioned/install/operator/multi-cluster-deployment.md @@ -37,8 +37,8 @@ Before you deploy Knative to a remote cluster, you must have: - The Cluster Inventory API `ClusterProfile` CRD installed on the hub cluster. See the installation instructions in the [kubernetes-sigs/cluster-inventory-api](https://github.com/kubernetes-sigs/cluster-inventory-api) repository. - Network connectivity from the hub cluster to each spoke cluster's API server. If the hub cannot reach a spoke directly, use a reverse tunnel such as the OCM cluster-proxy. - A credential plugin that implements the Cluster Inventory API access provider interface. The upstream `kubernetes-sigs/cluster-inventory-api` project publishes two plugins: - - `registry.k8s.io/cluster-inventory-api/secretreader:v0.1.1` reads a bearer token from a `Secret`'s `data.token` field. - - `registry.k8s.io/cluster-inventory-api/kubeconfig-secretreader:v0.1.1` reads a complete kubeconfig from a `Secret`. + - `registry.k8s.io/cluster-inventory-api/secretreader:v0.1.2` reads a bearer token from a `Secret`'s `data.token` field. + - `registry.k8s.io/cluster-inventory-api/kubeconfig-secretreader:v0.1.2` reads a complete kubeconfig from a `Secret`. Pick whichever matches the credential format you intend to use, or use a plugin from another source. - RBAC permissions on each spoke cluster that let the credential returned by the plugin create and manage Knative resources. See [Spoke RBAC requirements](#spoke-rbac-requirements). @@ -76,16 +76,17 @@ knative_operator: - name: secretreader execConfig: apiVersion: client.authentication.k8s.io/v1 - command: /credential-plugin/secretreader-plugin + command: /access-plugins/secretreader/bin/secretreader-plugin + interactiveMode: Never provideClusterInfo: true plugins: - name: secretreader - image: registry.k8s.io/cluster-inventory-api/secretreader:v0.1.1 - mountPath: /credential-plugin + image: registry.k8s.io/cluster-inventory-api/secretreader:v0.1.2 + mountPath: /access-plugins/secretreader remoteDeploymentsPollInterval: 10s ``` -The value of `accessProvidersConfig.providers[].name` must match the value of `plugins[].name`; the Operator uses the name to bind a plugin binary to its exec configuration. +The value of `accessProvidersConfig.providers[].name` must match the `ClusterProfile` status provider name. The `execConfig.command` must point to a binary under one of the configured `plugins[].mountPath` values. Apply the values with `helm upgrade --install`: @@ -120,7 +121,8 @@ If you do not use Helm, add multi-cluster support to an Operator that is already "name": "secretreader", "execConfig": { "apiVersion": "client.authentication.k8s.io/v1", - "command": "/credential-plugin/secretreader-plugin", + "command": "/access-plugins/secretreader/bin/secretreader-plugin", + "interactiveMode": "Never", "provideClusterInfo": true } } @@ -148,12 +150,19 @@ If you do not use Helm, add multi-cluster support to an Operator that is already args: - --clusterprofile-provider-file=/etc/cluster-inventory/config.json volumeMounts: - - name: credential-plugin - mountPath: /credential-plugin + - name: access-config + mountPath: /etc/cluster-inventory + readOnly: true + - name: secretreader + mountPath: /access-plugins/secretreader + readOnly: true volumes: - - name: credential-plugin + - name: access-config + configMap: + name: clusterprofile-provider-file + - name: secretreader image: - reference: /: + reference: registry.k8s.io/cluster-inventory-api/secretreader:v0.1.2 pullPolicy: IfNotPresent ``` @@ -175,7 +184,7 @@ A `ClusterProfile` resource on the hub describes one spoke. Register it in one o ### Register a ClusterProfile manually -Manual registration prepares the spoke first, then publishes its endpoint and credentials on the hub. The examples below use the `secretreader` plugin (`registry.k8s.io/cluster-inventory-api/secretreader:v0.1.1`); replace image references and configuration fields with those required by the plugin you choose. +Manual registration prepares the spoke first, then publishes its endpoint and credentials on the hub. The examples below use the `secretreader` plugin (`registry.k8s.io/cluster-inventory-api/secretreader:v0.1.2`); replace image references and configuration fields with those required by the plugin you choose. 1. On the spoke cluster, create a `ServiceAccount`, the required permissions, and a token `Secret`: @@ -214,17 +223,17 @@ Manual registration prepares the spoke first, then publishes its endpoint and cr - For GKE, run `gcloud container clusters describe --zone --format='value(endpoint)'`. {% endraw %} - The `kubectl get ... -o jsonpath='{.data.ca\.crt}'` output is already base64-encoded. Paste this string as-is into the `ClusterProfile` status `certificateAuthorityData` field shown in Step 5. + The `kubectl get ... -o jsonpath='{.data.ca\.crt}'` output is already base64-encoded. Paste this string as-is into the `ClusterProfile` status `certificate-authority-data` field shown in Step 5. 3. On the hub cluster, create a `Secret` that the credential plugin reads: ```bash - kubectl create secret generic spoke-cluster-1-credentials \ - --namespace fleet-system \ + kubectl create secret generic spoke-cluster-1 \ + --namespace knative-operator \ --from-literal=token= ``` - The `secretreader` plugin reads the bearer token from the `data.token` field of this `Secret`. The CA certificate is provided separately through the `ClusterProfile` status in Step 5. If you use `kubeconfig-secretreader` or another plugin, store the credentials in the `Secret` according to that plugin's documentation. + The `secretreader` plugin reads the bearer token from the `data.token` field of a `Secret` in the Operator namespace. The Secret name must match the `clusterName` value in the `ClusterProfile` status extension shown in Step 5. The CA certificate is provided separately through the `ClusterProfile` status. If you use `kubeconfig-secretreader` or another plugin, store the credentials in the `Secret` according to that plugin's documentation. 4. On the hub cluster, apply the `ClusterProfile` spec: @@ -266,7 +275,11 @@ Manual registration prepares the spoke first, then publishes its endpoint and cr - name: secretreader cluster: server: https://:6443 - certificateAuthorityData: + certificate-authority-data: + extensions: + - name: client.authentication.k8s.io/exec + extension: + clusterName: spoke-cluster-1 ``` !!! important From a23af67e7da77f6568e45a64e21fd8cd856d00d3 Mon Sep 17 00:00:00 2001 From: kahirokunn Date: Thu, 28 May 2026 12:43:23 +0900 Subject: [PATCH 2/2] Fix Netlify deploy preview build Signed-off-by: kahirokunn --- hack/build.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hack/build.sh b/hack/build.sh index 1a17d2e721..6512613403 100755 --- a/hack/build.sh +++ b/hack/build.sh @@ -75,8 +75,8 @@ curl -f -L --show-error https://raw.githubusercontent.com/knative/eventing/main/ echo -e "\nsamples_branch: main\nversion: development\ndoc_base: /docs/versioned/" >> "$TEMP/content/docs/versioned/.meta.yml" versionjson="{\"version\": \"versioned\", \"title\": \"(Pre-release)\", \"aliases\": [\"\"]}" -# Temporarily force BUILD_VERSIONS (for previews), while this rewrite is testing. -BUILD_VERSIONS="yes" +# Build all versions by default, but allow deploy previews to opt out. +: "${BUILD_VERSIONS:=yes}" if [ "$BUILD_VERSIONS" != "no" ]; then mv $TEMP/content/docs/versioned $TEMP/content/docs/development