diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index e96b68c595..3ac02d05ad 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -66,7 +66,6 @@ ** xref:deploy:redpanda/index.adoc[Redpanda] *** xref:deploy:redpanda/kubernetes/index.adoc[Kubernetes] **** xref:deploy:redpanda/kubernetes/k-deployment-overview.adoc[Overview] -**** xref:deploy:redpanda/kubernetes/k-25.2-beta.adoc[Try v25.2] **** xref:deploy:redpanda/kubernetes/get-started-dev.adoc[Get Started] ***** xref:deploy:redpanda/kubernetes/aks-guide.adoc[Azure AKS] ***** xref:deploy:redpanda/kubernetes/eks-guide.adoc[Amazon EKS] @@ -130,9 +129,10 @@ **** xref:manage:kubernetes/security/tls/index.adoc[TLS Encryption] ***** xref:manage:kubernetes/security/tls/k-cert-manager.adoc[Use cert-manager] ***** xref:manage:kubernetes/security/tls/k-secrets.adoc[Use Secrets] -**** xref:manage:kubernetes/security/authentication/index.adoc[Authentication] +**** xref:manage:kubernetes/security/authentication/index.adoc[Authentication and Authorization] ***** xref:manage:kubernetes/security/authentication/k-authentication.adoc[Enable Authentication] -***** xref:manage:kubernetes/security/authentication/k-user-controller.adoc[Manage Users and ACLs] +***** xref:manage:kubernetes/security/authentication/k-user-controller.adoc[Manage Users and ACLs (Operator)] +***** xref:manage:kubernetes/security/authorization/k-role-controller.adoc[Manage Roles and ACLs (Operator)] **** xref:manage:kubernetes/security/k-audit-logging.adoc[Audit Logging] *** xref:manage:kubernetes/k-rack-awareness.adoc[Rack Awareness] *** xref:manage:kubernetes/k-remote-read-replicas.adoc[Remote Read Replicas] diff --git a/modules/console/pages/config/analytics.adoc b/modules/console/pages/config/analytics.adoc index 74dce6238e..2ecc5daa49 100644 --- a/modules/console/pages/config/analytics.adoc +++ b/modules/console/pages/config/analytics.adoc @@ -72,20 +72,18 @@ When Redpanda Console is part of the Redpanda Helm chart or Operator: Operator:: + [,yaml] -.`redpanda-cluster`.yaml +.`redpanda-console`.yaml ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - analytics: - enabled: false + clusterRef: + name: redpanda + config: + analytics: + enabled: false ---- Helm:: diff --git a/modules/console/pages/config/configure-console.adoc b/modules/console/pages/config/configure-console.adoc index 7ce81546e4..8453f825de 100644 --- a/modules/console/pages/config/configure-console.adoc +++ b/modules/console/pages/config/configure-console.adoc @@ -3,7 +3,6 @@ :page-aliases: console:reference/config.adoc, reference:console/config.adoc :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/configure-console.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] Redpanda Console loads configuration properties from three sources, in the following order of precedence: @@ -79,35 +78,31 @@ Operator:: Configure Redpanda Console in the `console` section of your Redpanda custom resource: + [,yaml] -.`redpanda-cluster`.yaml +.`redpanda-console`.yaml ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - #kafka: - #brokers: [] # Auto-configured to connect to this Redpanda cluster - server: - listenPort: 8080 - auditLog: - enabled: false # default; set to true to write audit logs to stdout - additionalHeaders: # specifies HTTP headers to include in audit logs - - "X-Forwarded-For" - - "User-Agent" - # Add any other Redpanda Console configuration here + clusterRef: + name: redpanda # Reference to your Redpanda cluster + config: + server: + listenPort: 8080 + auditLog: + enabled: false + additionalHeaders: + - "X-Forwarded-For" + - "User-Agent" + # Add any other Redpanda Console configuration here ---- + Apply the configuration: + [,bash] ---- -kubectl apply -f redpanda-cluster.yaml --namespace +kubectl apply -f redpanda-console.yaml --namespace ---- Helm:: @@ -122,7 +117,7 @@ console: console: config: #kafka: - #brokers: [] # Auto-configured to connect to this Redpanda cluster + #brokers: [] # You can leave this empty. The chart is already auto-configured to connect to your Redpanda cluster server: listenPort: 8080 auditLog: diff --git a/modules/console/pages/config/connect-to-redpanda.adoc b/modules/console/pages/config/connect-to-redpanda.adoc index cbf335d03b..3f788601f1 100644 --- a/modules/console/pages/config/connect-to-redpanda.adoc +++ b/modules/console/pages/config/connect-to-redpanda.adoc @@ -2,7 +2,6 @@ :description: Learn how to configure Redpanda Console to connect to a Redpanda cluster and ensure communication with your Redpanda brokers. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/connect-to-redpanda.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] Redpanda Console connects to your Redpanda cluster using dedicated configuration blocks for the Kafka API, Schema Registry API, and Admin API. Each connection serves a different purpose: @@ -56,7 +55,21 @@ kafka: Kubernetes embedded:: + -- -When Redpanda Console is deployed as part of the Redpanda Helm chart or Operator, no additional connection configuration is required. The chart or Operator automatically configures Redpanda Console to connect to the Redpanda cluster. Only configure the `kafka` block if you need to override the default connection settings (for example, to connect to a different cluster or use custom authentication). +[tabs] +==== +Operator:: ++ +When deploying Redpanda Console with the Redpanda Operator, you can connect Console to your Redpanda cluster in two ways: + +- **clusterRef:** Reference the Redpanda cluster by name for automatic connection. This is the recommended approach for most users. +- **staticConfiguration:** Manually specify connection details for Kafka, Admin API, and Schema Registry if you need custom settings. + +The Operator will automatically configure Console to connect to the referenced cluster when using `clusterRef`. Use `staticConfiguration` only if you need to override the default connection or connect to a different cluster. + +Helm chart:: ++ +Redpanda Console is automatically configured to connect to the Redpanda cluster managed by the Helm chart. No additional connection configuration is required. Only configure the `kafka` block if you need to override the default connection settings (for example, to connect to a different cluster or use custom authentication). +==== -- Kubernetes standalone:: + diff --git a/modules/console/pages/config/deserialization.adoc b/modules/console/pages/config/deserialization.adoc index 0d3f39ede6..ded6c24a55 100644 --- a/modules/console/pages/config/deserialization.adoc +++ b/modules/console/pages/config/deserialization.adoc @@ -2,7 +2,6 @@ :description: Learn how to configure Redpanda Console to use Schema Registry, Protobuf files, and other deserialization methods to ensure your data is correctly interpreted and displayed. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/deserialization.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] Redpanda Console provides tools for deserializing and inspecting messages in Kafka topics. This topic explains how to configure Redpanda Console to use Schema Registry, Protobuf files, and other deserialization methods to ensure your data is correctly interpreted and displayed. @@ -91,22 +90,20 @@ Operator:: .`redpanda-cluster`.yaml ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - serde: - protobuf: - enabled: true - mappings: - - topicName: address-v1 - valueProtoType: fake_models.Address # The full Protobuf type name - # keyProtoType: Not specified because the key is a plain string + clusterRef: + name: redpanda + config: + serde: + protobuf: + enabled: true + mappings: + - topicName: address-v1 + valueProtoType: fake_models.Address + # keyProtoType: Not specified because the key is a plain string ---- Helm:: @@ -198,27 +195,25 @@ Operator:: [,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - serde: - protobuf: - enabled: true - mappings: - - topicName: orders - valueProtoType: fake_models.Order - keyProtoType: fake_models.OrderKey - fileSystem: - enabled: true - refreshInterval: 5m - paths: - - /etc/protos + clusterRef: + name: redpanda + config: + serde: + protobuf: + enabled: true + mappings: + - topicName: orders + valueProtoType: fake_models.Order + keyProtoType: fake_models.OrderKey + fileSystem: + enabled: true + refreshInterval: 5m + paths: + - /etc/protos ---- Helm:: @@ -324,30 +319,28 @@ Operator:: [,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - serde: - protobuf: - enabled: true - mappings: - - topicName: orders - valueProtoType: fake_models.Order - keyProtoType: fake_models.OrderKey - git: - enabled: true - repository: - url: https://github.com/myorg/kafka-proto-files.git - branch: master - refreshInterval: 10m - paths: - - ./ + clusterRef: + name: redpanda + config: + serde: + protobuf: + enabled: true + mappings: + - topicName: orders + valueProtoType: fake_models.Order + keyProtoType: fake_models.OrderKey + git: + enabled: true + repository: + url: https://github.com/myorg/kafka-proto-files.git + branch: master + refreshInterval: 10m + paths: + - ./ ---- Helm:: @@ -491,37 +484,35 @@ Operator:: [,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - extraEnv: - - name: SERDE_PROTOBUF_GIT_BASICAUTH_USERNAME - value: token - extraEnvFrom: - - secretRef: - name: protobuf-git-auth - console: - config: - serde: - protobuf: - enabled: true - mappings: - - topicName: - valueProtoType: - git: - enabled: true - repository: - url: https://github.com//.git - branch: - refreshInterval: 10m - paths: - - ./ - basicAuth: - enabled: true + clusterRef: + name: redpanda + extraEnv: + - name: SERDE_PROTOBUF_GIT_BASICAUTH_USERNAME + value: token + extraEnvFrom: + - secretRef: + name: protobuf-git-auth + config: + serde: + protobuf: + enabled: true + mappings: + - topicName: + valueProtoType: + git: + enabled: true + repository: + url: https://github.com//.git + branch: + refreshInterval: 10m + paths: + - ./ + basicAuth: + enabled: true ---- Helm:: @@ -695,30 +686,29 @@ Operator:: [,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - extraVolumeMounts: - - name: git-ssh - mountPath: /etc/git-ssh - readOnly: true - extraVolumes: - - name: git-ssh - secret: - secretName: protobuf-git-ssh - extraEnv: - - name: SERDE_PROTOBUF_GIT_SSH_ENABLED - value: "true" - - name: SERDE_PROTOBUF_GIT_SSH_USERNAME - value: git - - name: SERDE_PROTOBUF_GIT_SSH_PRIVATEKEYFILEPATH - value: /etc/git-ssh/privateKey - - name: SERDE_PROTOBUF_GIT_SSH_PASSPHRASE - value: + clusterRef: + name: redpanda + extraVolumeMounts: + - name: git-ssh + mountPath: /etc/git-ssh + readOnly: true + extraVolumes: + - name: git-ssh + secret: + secretName: protobuf-git-ssh + extraEnv: + - name: SERDE_PROTOBUF_GIT_SSH_ENABLED + value: "true" + - name: SERDE_PROTOBUF_GIT_SSH_USERNAME + value: git + - name: SERDE_PROTOBUF_GIT_SSH_PRIVATEKEYFILEPATH + value: /etc/git-ssh/privateKey + - name: SERDE_PROTOBUF_GIT_SSH_PASSPHRASE + value: ---- Helm:: @@ -849,7 +839,6 @@ serde: Kubernetes embedded:: + -- -When using the Redpanda Operator or the Redpanda Helm chart, configure MessagePack deserialization through the cluster configuration: [tabs] ==== @@ -858,19 +847,18 @@ Operator:: [,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - serde: - messagePack: - enabled: true - topicNames: ["/.*/"] + clusterRef: + name: redpanda + config: + serde: + messagePack: + enabled: true + topicNames: + - "/.*/" ---- Helm:: diff --git a/modules/console/pages/config/enterprise-license.adoc b/modules/console/pages/config/enterprise-license.adoc index 991c8e27db..c2832398b2 100644 --- a/modules/console/pages/config/enterprise-license.adoc +++ b/modules/console/pages/config/enterprise-license.adoc @@ -2,7 +2,6 @@ :description: Learn how to apply or update a license key to Redpanda Console. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/enterprise-license.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] To enable xref:get-started:licensing/overview.adoc#console[enterprise features for Redpanda Console], you must have an Enterprise Edition license to load at startup. This guide explains how to configure Redpanda Console to load the license key from its local configuration. diff --git a/modules/console/pages/config/http-path-rewrites.adoc b/modules/console/pages/config/http-path-rewrites.adoc index 1c56c87d02..0b4a11cd13 100644 --- a/modules/console/pages/config/http-path-rewrites.adoc +++ b/modules/console/pages/config/http-path-rewrites.adoc @@ -3,7 +3,6 @@ :page-aliases: console:features/http-path-rewrites.adoc, manage:console/http-path-rewrites.adoc :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/http-path-rewrites.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] If you want to host Redpanda Console under a subpath rather than the root path, you need to configure HTTP path rewrites. This allows you to serve Redpanda Console under a subpath of your domain, such as `+https://my-company.com/redpanda/console+`, instead of directly from `+https://my-company.com+`. This type of configuration is often necessary when: @@ -128,18 +127,16 @@ Operator:: + ```yaml apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - console: - config: - server: - setBasePathFromXForwardedPrefix: true - stripPrefix: true + clusterRef: + name: redpanda + config: + server: + setBasePathFromXForwardedPrefix: true + stripPrefix: true ``` Helm:: diff --git a/modules/console/pages/config/kafka-connect.adoc b/modules/console/pages/config/kafka-connect.adoc index df5818cd53..4a0f71a836 100644 --- a/modules/console/pages/config/kafka-connect.adoc +++ b/modules/console/pages/config/kafka-connect.adoc @@ -5,7 +5,6 @@ include::shared:partial$community-supported-kc.adoc[] -include::console:partial$operator-console-version-note.adoc[] Redpanda Console provides a user interface that lets you manage multiple Kafka Connect clusters. You can inspect or patch connectors; restart, pause, and resume connector tasks; and delete connectors. @@ -58,30 +57,28 @@ When Redpanda Console is part of the Redpanda Helm chart or Operator: Operator:: + [,yaml] -.`redpanda-cluster`.yaml +.`redpanda-console`.yaml ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: + clusterRef: + name: redpanda + config: + kafkaConnect: enabled: true - console: - config: - kafkaConnect: - enabled: true - clusters: - - name: datawarehouse # Required field, will be used as identifier in the frontend - url: http://dwh-connect.mycompany.com:8083 - tls: - enabled: false # Trusted certs are still allowed by default - username: admin - # password: - - name: analytics # Required field, will be used as identifier in the frontend - url: http://analytics.mycompany.com:8083 - # No auth configured on that cluster, hence no username/password set + clusters: + - name: datawarehouse + url: http://dwh-connect.mycompany.com:8083 + tls: + enabled: false + username: admin + # password: (add if needed) + - name: analytics + url: http://analytics.mycompany.com:8083 + # No auth configured on this cluster ---- Helm:: diff --git a/modules/console/pages/config/security/authentication.adoc b/modules/console/pages/config/security/authentication.adoc index cd45245211..9592ed7bac 100644 --- a/modules/console/pages/config/security/authentication.adoc +++ b/modules/console/pages/config/security/authentication.adoc @@ -4,7 +4,6 @@ :page-categories: Security, Management, Redpanda Console :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/security/authentication.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] // ========================AUTOMATED TESTS=================================== diff --git a/modules/console/pages/config/security/authorization.adoc b/modules/console/pages/config/security/authorization.adoc index b8877336eb..5ab60faff9 100644 --- a/modules/console/pages/config/security/authorization.adoc +++ b/modules/console/pages/config/security/authorization.adoc @@ -4,7 +4,6 @@ :page-categories: Security, Management, Redpanda Console :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/security/authorization.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] [NOTE] ==== diff --git a/modules/console/pages/config/security/index.adoc b/modules/console/pages/config/security/index.adoc index 050c4efc13..0071a5d8a7 100644 --- a/modules/console/pages/config/security/index.adoc +++ b/modules/console/pages/config/security/index.adoc @@ -4,4 +4,3 @@ :page-layout: index :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/security/index.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] diff --git a/modules/console/pages/config/security/tls-termination.adoc b/modules/console/pages/config/security/tls-termination.adoc index c37d2d7a65..553404adf1 100644 --- a/modules/console/pages/config/security/tls-termination.adoc +++ b/modules/console/pages/config/security/tls-termination.adoc @@ -5,7 +5,6 @@ :page-exclude-related-labs: true :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/security/tls-termination.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] To secure Redpanda Console using TLS (Transport Layer Security), you can either let Redpanda Console handle TLS termination or you can offload it to an upstream component, such as a reverse proxy or a cloud HTTPS load balancer. TLS termination refers to the process of decrypting incoming TLS-encrypted traffic. Choosing the right approach depends on various factors, such as your application's traffic load, the complexity of your infrastructure, security requirements, and resource availability: diff --git a/modules/console/pages/config/topic-documentation.adoc b/modules/console/pages/config/topic-documentation.adoc index ca221fe568..f292de40fe 100644 --- a/modules/console/pages/config/topic-documentation.adoc +++ b/modules/console/pages/config/topic-documentation.adoc @@ -3,7 +3,6 @@ :page-aliases: console:features/topic-documentation.adoc, manage:console/topic-documentation.adoc :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:config/topic-documentation.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] You can embed topic documentation into the Redpanda Console user interface by providing access to a public or private Git repository that hosts the documentation files in Markdown format. @@ -68,23 +67,21 @@ Operator:: [source,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: + clusterRef: + name: redpanda + config: console: - enabled: true - console: - config: - console: - topicDocumentation: - git: - enabled: true - repository: - url: https://github.com//.git - branch: - baseDirectory: + topicDocumentation: + git: + enabled: true + repository: + url: https://github.com//.git + branch: + baseDirectory: ---- Helm:: @@ -214,32 +211,30 @@ Operator:: [source,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: + clusterRef: + name: redpanda + extraEnv: + - name: TOPICDOCUMENTATION_GIT_BASICAUTH_USERNAME + value: token + extraEnvFrom: + - secretRef: + name: topic-doc-git-auth + config: console: - enabled: true - extraEnv: - - name: TOPICDOCUMENTATION_GIT_BASICAUTH_USERNAME - value: token - extraEnvFrom: - - secretRef: - name: topic-doc-git-auth - console: - config: - console: - topicDocumentation: - git: - enabled: true - repository: - url: https://github.com//.git - branch: - baseDirectory: - refreshInterval: 10m - basicAuth: - enabled: true + topicDocumentation: + git: + enabled: true + repository: + url: https://github.com//.git + branch: + baseDirectory: + refreshInterval: 10m + basicAuth: + enabled: true ---- Helm:: @@ -385,30 +380,29 @@ Operator:: [source,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda +kind: Console metadata: - name: redpanda + name: redpanda-console spec: - clusterSpec: - console: - enabled: true - extraVolumeMounts: - - name: git-ssh - mountPath: /etc/git-ssh - readOnly: true - extraVolumes: - - name: git-ssh - secret: - secretName: topic-doc-git-ssh - extraEnv: - - name: TOPICDOCUMENTATION_GIT_SSH_ENABLED - value: "true" - - name: TOPICDOCUMENTATION_GIT_SSH_USERNAME - value: git - - name: TOPICDOCUMENTATION_GIT_SSH_PRIVATEKEYFILEPATH - value: /etc/git-ssh/privateKey - - name: TOPICDOCUMENTATION_GIT_SSH_PASSPHRASE - value: + clusterRef: + name: redpanda + extraVolumeMounts: + - name: git-ssh + mountPath: /etc/git-ssh + readOnly: true + extraVolumes: + - name: git-ssh + secret: + secretName: topic-doc-git-ssh + extraEnv: + - name: TOPICDOCUMENTATION_GIT_SSH_ENABLED + value: "true" + - name: TOPICDOCUMENTATION_GIT_SSH_USERNAME + value: git + - name: TOPICDOCUMENTATION_GIT_SSH_PRIVATEKEYFILEPATH + value: /etc/git-ssh/privateKey + - name: TOPICDOCUMENTATION_GIT_SSH_PASSPHRASE + value: ---- Helm:: diff --git a/modules/console/pages/index.adoc b/modules/console/pages/index.adoc index 5b63d2e121..c55aa249da 100644 --- a/modules/console/pages/index.adoc +++ b/modules/console/pages/index.adoc @@ -3,7 +3,6 @@ :page-aliases: console:index/index.adoc, console:features/index.adoc, reference:console/index.adoc :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:index.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] Redpanda Console is a web interface for managing and interacting with Redpanda clusters. Built to provide a seamless experience for developers working with streaming data, Redpanda Console simplifies tasks associated with managing data streams, offering a UI that helps you monitor, troubleshoot, and optimize your streaming workloads. diff --git a/modules/console/pages/ui/add-license.adoc b/modules/console/pages/ui/add-license.adoc index 2cd81d6ace..2800d5787a 100644 --- a/modules/console/pages/ui/add-license.adoc +++ b/modules/console/pages/ui/add-license.adoc @@ -2,7 +2,6 @@ :description: Learn how to manage Enterprise Edition licenses in Redpanda Console. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/add-license.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] You can add or update an xref:get-started:licensing/overview.adoc#console[Enterprise Edition license] for both Redpanda and Redpanda Console directly through the Redpanda Console UI. diff --git a/modules/console/pages/ui/check-license.adoc b/modules/console/pages/ui/check-license.adoc index 87ca35e215..a715f5e5d3 100644 --- a/modules/console/pages/ui/check-license.adoc +++ b/modules/console/pages/ui/check-license.adoc @@ -2,7 +2,6 @@ :description: Learn how to check the status of your Redpanda Enterprise Edition license using the Redpanda Console. This topic includes steps to check license details and understand license warnings. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/check-license.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] You can check the expiration date of a license on the **Cluster Overview** page in Redpanda Console, under the **Licensing** section. diff --git a/modules/console/pages/ui/data-transforms.adoc b/modules/console/pages/ui/data-transforms.adoc index f101390f8a..727ebd05ea 100644 --- a/modules/console/pages/ui/data-transforms.adoc +++ b/modules/console/pages/ui/data-transforms.adoc @@ -2,7 +2,6 @@ :description: Use {ui} to monitor the status and performance metrics of your transform functions. You can also view detailed logs and delete transform functions when they are no longer needed. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/data-transforms.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] // tag::single-source[] diff --git a/modules/console/pages/ui/edit-topic-configuration.adoc b/modules/console/pages/ui/edit-topic-configuration.adoc index 55fd8dcf97..75dcd24042 100644 --- a/modules/console/pages/ui/edit-topic-configuration.adoc +++ b/modules/console/pages/ui/edit-topic-configuration.adoc @@ -3,7 +3,6 @@ :description: Learn how to use {ui} to edit the configuration of existing topics in a cluster. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/edit-topic-configuration.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] // tag::single-source[] diff --git a/modules/console/pages/ui/generate-bundle.adoc b/modules/console/pages/ui/generate-bundle.adoc index 38f2955040..902dfd7ccf 100644 --- a/modules/console/pages/ui/generate-bundle.adoc +++ b/modules/console/pages/ui/generate-bundle.adoc @@ -2,7 +2,6 @@ :description: Learn how to generate, download, and delete debug bundles in Redpanda Console for comprehensive cluster diagnostics. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/generate-bundle.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] [NOTE] ==== diff --git a/modules/console/pages/ui/programmable-push-filters.adoc b/modules/console/pages/ui/programmable-push-filters.adoc index 00601bc060..a003448197 100644 --- a/modules/console/pages/ui/programmable-push-filters.adoc +++ b/modules/console/pages/ui/programmable-push-filters.adoc @@ -4,7 +4,6 @@ :description: Learn how to filter Kafka records using custom JavaScript code within {ui}. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/programmable-push-filters.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] // tag::single-source[] diff --git a/modules/console/pages/ui/record-deserialization.adoc b/modules/console/pages/ui/record-deserialization.adoc index a957fdd856..30431c1a39 100644 --- a/modules/console/pages/ui/record-deserialization.adoc +++ b/modules/console/pages/ui/record-deserialization.adoc @@ -3,7 +3,6 @@ :description: Learn how {ui} deserializes messages. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/record-deserialization.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] // tag::single-source[] diff --git a/modules/console/pages/ui/schema-reg.adoc b/modules/console/pages/ui/schema-reg.adoc index a99e24811d..c20caed43a 100644 --- a/modules/console/pages/ui/schema-reg.adoc +++ b/modules/console/pages/ui/schema-reg.adoc @@ -4,7 +4,6 @@ :description: Learn how to perform common Schema Registry management operations in the {ui}. :page-context-switcher: [{"name": "Redpanda Console v2.x", "to": "24.3@ROOT:console:ui/schema-reg.adoc" },{"name": "Redpanda Console v3.x", "to": "current" } ] -include::console:partial$operator-console-version-note.adoc[] // tag::single-source[] diff --git a/modules/console/partials/operator-console-version-note.adoc b/modules/console/partials/operator-console-version-note.adoc deleted file mode 100644 index 89fa53afd3..0000000000 --- a/modules/console/partials/operator-console-version-note.adoc +++ /dev/null @@ -1,21 +0,0 @@ -.The Redpanda Operator deploys Redpanda Console v2.x, not v3.x. -[%collapsible] -==== -Redpanda Console v3 is **not yet available when deploying with the Redpanda Operator**. The Redpanda Operator continues to deploy Redpanda Console v2. To try Redpanda Console v3 in Kubernetes, you can xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[deploy Redpanda using the Redpanda Helm chart] instead of the Redpanda Operator. - -Redpanda Console configuration syntax varies by major version. Before configuring, determine which version you're using: - -[source,shell] ----- -# Check console version from deployment -kubectl get deployment -n redpanda-console -o jsonpath='{.spec.template.spec.containers[0].image}' - -# Or check from running pod -kubectl get pod -n -l app.kubernetes.io/name=console -o jsonpath='{.items[0].spec.containers[0].image}' - -# Or check from console logs -kubectl logs -n -l app.kubernetes.io/name=console | grep "started Redpanda Console" ----- - -If you see output like `redpandadata/console:v2.8.0`, you're using Redpanda Console v2.x. If you see `redpandadata/console:v3.0.0`, you're using Redpanda Console v3.x. -==== diff --git a/modules/deploy/pages/redpanda/kubernetes/k-25.2-beta.adoc b/modules/deploy/pages/redpanda/kubernetes/k-25.2-beta.adoc deleted file mode 100644 index 6002d8efae..0000000000 --- a/modules/deploy/pages/redpanda/kubernetes/k-25.2-beta.adoc +++ /dev/null @@ -1,332 +0,0 @@ -= Try the 25.2 Beta of the Redpanda Operator -:page-beta: true -:description: Deploy the 25.2 beta release of the Redpanda Operator. This version of the Redpanda Operator is cluster scope so a single instance of the Operator can manage multiple Redpanda resources in different namespaces. - -{description} - -This beta version is available for testing and feedback. It is not supported by Redpanda and should not be used in production environments. To give feedback on beta releases, reach out to the Redpanda team in https://redpanda.com/slack[Redpanda Community Slack^]. - -== Prerequisites - -Make sure that your Kubernetes cluster meets the xref:./k-requirements.adoc[requirements]. - -== Deploy Redpanda Operator v25.2.1-beta1 in cluster scope - -To deploy the Redpanda Operator in cluster scope (managing Redpanda resources across all namespaces), do the following: - -. Make sure that you have permission to install custom resource definitions (CRDs): -+ -```bash -kubectl auth can-i create CustomResourceDefinition --all-namespaces -``` -+ -You should see `yes` in the output. -+ -You need these cluster-level permissions to install glossterm:cert-manager[^] and Redpanda Operator CRDs in the next steps. - -. Install cert-manager: -+ -```bash -helm repo add jetstack https://charts.jetstack.io -helm repo update -helm install cert-manager jetstack/cert-manager \ - --set crds.enabled=true \ - --namespace cert-manager \ - --create-namespace -``` -+ -TLS is enabled by default and cert-manager is used to manage TLS certificates. - -. Deploy the Redpanda Operator: -+ -[,bash,subs="attributes+"] ----- -helm repo add redpanda https://charts.redpanda.com -helm upgrade --install redpanda-controller redpanda/operator \ - --namespace \ - --create-namespace \ - --version {operator-beta-tag} \ - --set crds.enabled=true ----- - -. Ensure that the Deployment is successfully rolled out: -+ -```bash -kubectl --namespace rollout status --watch deployment/redpanda-controller-operator -``` -+ -[.no-copy] ----- -deployment "redpanda-controller-operator" successfully rolled out ----- - -. Define a xref:reference:k-crd.adoc[Redpanda custom resource] to deploy a Redpanda cluster. -+ -.`redpanda-cluster.yaml` -[,yaml,subs="attributes+"] ----- -apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda -metadata: - name: redpanda - namespace: <1> ----- -+ -<1> Add your namespace. - -. If you want to use enterprise features in Redpanda, add the details of a Secret that stores your Enterprise Edition license key. -+ -.`redpanda-cluster.yaml` -[,yaml,subs="attributes+"] ----- -apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda -metadata: - name: redpanda - namespace: -spec: - clusterSpec: - enterprise: - licenseSecretRef: - name: - key: ----- -+ -For details, see xref:get-started:licensing/add-license-redpanda/kubernetes.adoc[]. - -. Apply the Redpanda resource: -+ -```bash -kubectl apply -f redpanda-cluster.yaml -``` - -. Wait for the Redpanda Operator to deploy the cluster: -+ -```bash -kubectl get redpanda --namespace --watch -``` -+ -[.no-copy] ----- -NAME READY STATUS -redpanda True Redpanda reconciliation succeeded ----- -+ -This step may take a few minutes. You can watch for new Pods to make sure that the deployment is progressing: -+ -```bash -kubectl get pod --namespace -``` -+ -If it's taking too long, see xref:manage:kubernetes/troubleshooting/k-troubleshoot.adoc[Troubleshooting]. - -=== Deploy multiple Redpanda clusters - -You can deploy more than one Redpanda cluster in the same Kubernetes cluster by using a different namespace and unique node ports. - -. Define a new Redpanda resource in a unique namespace. -+ -NOTE: Make sure to also use unique node ports for the listeners in your Redpanda resource so that they don't conflict with any existing node ports in your other Redpanda clusters. -+ -.`redpanda-cluster-two.yaml` -[source,yaml,subs="attributes+"] ----- -apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda -metadata: - name: redpanda-two - namespace: -spec: - clusterSpec: - listeners: - kafka: - external: - default: - advertisedPorts: [31093] - admin: - external: - default: - advertisedPorts: [31645] - http: - external: - default: - advertisedPorts: [30083] - rpc: - port: 33146 - schemaRegistry: - external: - default: - advertisedPorts: [30084] ----- - -. Apply the Redpanda resource: -+ -```bash -kubectl apply -f redpanda-cluster-two.yaml -``` - -== Deploy Redpanda Operator v25.2.1-beta1 in namespace scope - -To deploy the Redpanda Operator in namespace scope (managing only resources within its deployment namespace), do the following: - -. Make sure that you have permission to install custom resource definitions (CRDs): -+ -```bash -kubectl auth can-i create CustomResourceDefinition --all-namespaces -``` -+ -You should see `yes` in the output. -+ -You need these cluster-level permissions to install glossterm:cert-manager[^] and Redpanda Operator CRDs in the next steps. - -. Install cert-manager: -+ -```bash -helm repo add jetstack https://charts.jetstack.io -helm repo update -helm install cert-manager jetstack/cert-manager \ - --set crds.enabled=true \ - --namespace cert-manager \ - --create-namespace -``` -+ -TLS is enabled by default and cert-manager is used to manage TLS certificates. - -. Deploy the Redpanda Operator: -+ -[,bash,subs="attributes+"] ----- -helm upgrade --install redpanda-controller redpanda/operator \ - --namespace \ - --create-namespace \ - --version {latest-operator-version} \ - --set crds.enabled=true \ - --set 'additionalCmdFlags=["--namespace="]' <1> ----- -+ -<1> This flag restricts the Redpanda Operator to manage resources only within the specified namespace. -+ -WARNING: Do not run multiple Redpanda Operators in different scopes (cluster and namespace scope) in the same cluster as this can cause resource conflicts. - -. Ensure that the Deployment is successfully rolled out: -+ -```bash -kubectl --namespace rollout status --watch deployment/redpanda-controller-operator -``` -+ -[.no-copy] ----- -deployment "redpanda-controller-operator" successfully rolled out ----- - -. Define a xref:reference:k-crd.adoc[Redpanda custom resource] to deploy a Redpanda cluster in the same namespace as the namespace-scoped Redpanda Operator. -+ -.`redpanda-cluster.yaml` -[,yaml,subs="attributes+"] ----- -apiVersion: cluster.redpanda.com/v1alpha2 -kind: Redpanda -metadata: - name: redpanda - namespace: ----- - -. Apply the Redpanda resource: -+ -```bash -kubectl apply -f redpanda-cluster.yaml -``` - -. Wait for the Redpanda Operator to deploy the cluster: -+ -```bash -kubectl get redpanda --namespace --watch -``` -+ -[.no-copy] ----- -NAME READY STATUS -redpanda True Redpanda reconciliation succeeded ----- -+ -This step may take a few minutes. You can watch for new Pods to make sure that the deployment is progressing: -+ -```bash -kubectl get pod --namespace -``` -+ -If it's taking too long, see xref:manage:kubernetes/troubleshooting/k-troubleshoot.adoc[Troubleshooting]. - -== Uninstall Redpanda - -When you finish testing Redpanda, you can uninstall it from your Kubernetes cluster. - -Follow the steps in **exact order** to avoid race conditions between -the Redpanda Operator's reconciliation loop and Kubernetes garbage collection. - -. Delete all Redpanda-related custom resources: -+ -[,bash,role="no-wrap"] ----- -kubectl delete users --namespace --all -kubectl delete topics --namespace --all -kubectl delete schemas --namespace --all -kubectl delete redpanda --namespace --all ----- - -. Make sure requests for those resources return no results. For example, if you had a Redpanda cluster named `redpanda` in the namespace ``, run: -+ -[,bash] ----- -kubectl get redpanda --namespace ----- - -. Uninstall the Redpanda Operator Helm release: -+ -[,bash] ----- -helm uninstall redpanda-controller --namespace ----- -+ -Helm does not uninstall CRDs by default when using `helm uninstall` to avoid accidentally deleting existing custom resources. - -. Remove the CRDs. -.. List all Redpanda CRDs installed by the operator: -+ -[,bash] ----- -kubectl api-resources --api-group='cluster.redpanda.com' ----- -+ -This command displays all CRDs defined by the Redpanda Operator. For example: -+ -[,bash,role="no-wrap"] ----- -NAME SHORTNAMES APIVERSION NAMESPACED KIND -redpandas rp cluster.redpanda.com/v1alpha2 true Redpanda -schemas sc cluster.redpanda.com/v1alpha2 true Schema -topics cluster.redpanda.com/v1alpha2 true Topic -users rpu cluster.redpanda.com/v1alpha2 true User ----- - -.. Delete the CRDs: -+ -[,bash] ----- -kubectl get crds -o name | grep cluster.redpanda.com | xargs kubectl delete ----- -+ -This command lists all CRDs with the `cluster.redpanda.com` domain suffix and deletes them, ensuring only Redpanda CRDs are removed. Helm does not delete CRDs automatically to prevent data loss, so you must run this step manually. - -. (Optional) Delete any leftover PVCs or Secrets in the namespace: -+ -CAUTION: The following command deletes all PVCs and Secrets in the namespace, which may remove unrelated resources if the namespace is shared with other applications. -+ -[,bash] ----- -kubectl delete pvc,secret --all --namespace ----- - -== Next steps - -To give feedback about this beta version, reach out to the Redpanda team in https://redpanda.com/slack[Redpanda Community Slack^]. diff --git a/modules/deploy/pages/redpanda/kubernetes/k-deployment-overview.adoc b/modules/deploy/pages/redpanda/kubernetes/k-deployment-overview.adoc index a881637748..43d8270224 100644 --- a/modules/deploy/pages/redpanda/kubernetes/k-deployment-overview.adoc +++ b/modules/deploy/pages/redpanda/kubernetes/k-deployment-overview.adoc @@ -41,7 +41,7 @@ To deploy Redpanda in Kubernetes, you can choose between Helm for its simplicity | Multi-tenancy management | ✅ | ⚠️ -| Helm requires separate releases to manage multiple clusters, making management more complex. The Redpanda Operator simplifies this through declarative custom resources. +| Helm requires separate releases to manage multiple clusters, making management more complex. The Redpanda Operator simplifies multi-tenancy by managing clusters across different namespaces from a single operator instance. |=== @@ -50,7 +50,7 @@ TIP: If you are already using the Redpanda Helm chart and want to migrate to the [[helm-and-redpanda-operator]] === Redpanda Operator -The Redpanda Operator is designed for production-grade Redpanda deployments, offering enhanced lifecycle management, automation, and GitOps compatibility. +The Redpanda Operator is designed for production-grade Redpanda deployments, offering enhanced lifecycle management, automation, and GitOps compatibility. The Redpanda Operator defaults to cluster scope, enabling it to manage multiple Redpanda clusters across different namespaces from a single operator instance. The Redpanda Operator directly reconciles Redpanda resources, performing tasks such as installations, updates, and cleanup. diff --git a/modules/deploy/pages/redpanda/kubernetes/k-production-deployment.adoc b/modules/deploy/pages/redpanda/kubernetes/k-production-deployment.adoc index c8b14db923..393ac88948 100644 --- a/modules/deploy/pages/redpanda/kubernetes/k-production-deployment.adoc +++ b/modules/deploy/pages/redpanda/kubernetes/k-production-deployment.adoc @@ -1,7 +1,7 @@ = Deploy Redpanda for Production in Kubernetes :description: Deploy a Redpanda cluster in Kubernetes. :tags: ["Kubernetes"] -:page-aliases: deploy:deployment-option/self-hosted/kubernetes/kubernetes-best-practices.adoc, deploy:deployment-option/self-hosted/kubernetes/redpanda-cluster-recommendations.adoc, deploy:deployment-option/self-hosted/kubernetes/kubernetes-deploy.adoc, deploy:deployment-option/self-hosted/kubernetes/k-25.1-beta.adoc, deploy:deployment-option/self-hosted/kubernetes/k-production-deployment.adoc +:page-aliases: deploy:deployment-option/self-hosted/kubernetes/kubernetes-best-practices.adoc, deploy:deployment-option/self-hosted/kubernetes/redpanda-cluster-recommendations.adoc, deploy:deployment-option/self-hosted/kubernetes/kubernetes-deploy.adoc, deploy:deployment-option/self-hosted/kubernetes/k-25.1-beta.adoc, deploy:deployment-option/self-hosted/kubernetes/k-production-deployment.adoc, deploy:redpanda/kubernetes/k-25.2-beta.adoc :page-toclevels: 1 :env-kubernetes: true :page-categories: Deployment, GitOps @@ -18,7 +18,7 @@ You must already have a ConfigMap that stores your `io-config.yaml` file. See xr To deploy Redpanda and Redpanda Console, you can use the following tools: -- *Redpanda Operator*: The Redpanda Operator extends Kubernetes with custom resource definitions (CRDs), allowing you to define Redpanda clusters as native Kubernetes resources. The resource that the Redpanda Operator uses to represent a Redpanda cluster is the Redpanda resource. +- *Redpanda Operator*: The Redpanda Operator extends Kubernetes with custom resource definitions (CRDs), allowing you to define Redpanda clusters as native Kubernetes resources. The resource that the Redpanda Operator uses to represent a Redpanda cluster is the Redpanda resource. The Redpanda Operator can be deployed in either cluster scope (managing resources across all namespaces) or namespace scope (managing resources within a single namespace). - *Helm*: https://helm.sh/docs[Helm^] is a package manager for Kubernetes, which simplifies the process of defining, installing, and upgrading Kubernetes applications. Helm uses charts, a collection of files that describe a related set of Kubernetes resources, to deploy applications in a Kubernetes cluster. TIP: For more details about the differences between these two methods, see xref:deploy:redpanda/kubernetes/k-deployment-overview.adoc[]. @@ -29,7 +29,12 @@ Operator:: + -- -NOTE: The Redpanda Operator is namespace scoped. You must install the Redpanda Operator in the same namespace as your Redpanda resource (Redpanda cluster). +The Redpanda Operator can be deployed in two different scopes: + +- *Cluster scope* (recommended): The Redpanda Operator manages Redpanda resources across all namespaces in your Kubernetes cluster. This provides centralized management and is ideal for production environments. +- *Namespace scope*: The Redpanda Operator manages Redpanda resources only within a specific namespace. This provides better isolation and is suitable when you need strict namespace boundaries. + +WARNING: Do not run multiple Redpanda Operators in different scopes (cluster and namespace scope) in the same cluster as this can cause resource conflicts. . Make sure that you have permission to install custom resource definitions (CRDs): + @@ -54,7 +59,7 @@ helm install cert-manager jetstack/cert-manager \ + The Redpanda Helm chart enables TLS by default and uses cert-manager to manage TLS certificates. -. Deploy the Redpanda Operator. +. Deploy the Redpanda Operator in your chosen scope: + include::deploy:partial$kubernetes/deploy-operator.adoc[] @@ -78,6 +83,7 @@ apiVersion: cluster.redpanda.com/v1alpha2 kind: Redpanda metadata: name: redpanda + namespace: spec: clusterSpec: #enterprise: @@ -99,6 +105,7 @@ spec: ---- + - `metadata.name`: Name to assign the Redpanda cluster. +- `metadata.namespace`: For cluster-scoped deployment, specify any namespace. For namespace-scoped deployment, must be the same namespace where the Redpanda Operator is deployed. - xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-api-redpanda-v1alpha2-redpandaclusterspec[`spec.clusterSpec`]: This is where you can override default values in the Redpanda Helm chart. Here, you mount the <> to the Pods that run Redpanda. For other configuration details, see <>. - `spec.clusterSpec.enterprise`: If you want to use enterprise features in Redpanda, uncomment this section and add the details of a Secret that stores your Enterprise Edition license key. For details, see xref:get-started:licensing/index.adoc[]. - `spec.clusterSpec.image.tag`: Deploys the latest version of Redpanda. @@ -107,15 +114,13 @@ spec: . Apply the Redpanda resource: + ```bash -kubectl apply -f redpanda-cluster.yaml --namespace +kubectl apply -f redpanda-cluster.yaml ``` -+ -NOTE: The Redpanda resource must be deployed in the same namespace as the Redpanda Operator. Each new deployment of Redpanda requires a separate namespace. . Wait for the Redpanda Operator to deploy Redpanda using the Helm chart: + ```bash -kubectl get redpanda --namespace --watch +kubectl get redpanda --namespace --watch ``` + [.no-copy] @@ -127,7 +132,7 @@ redpanda True Redpanda reconciliation succeeded This step may take a few minutes. You can watch for new Pods to make sure that the deployment is progressing: + ```bash -kubectl get pod --namespace +kubectl get pod --namespace ``` + If it's taking too long, see xref:manage:kubernetes/troubleshooting/k-troubleshoot.adoc[Troubleshooting]. @@ -135,7 +140,7 @@ If it's taking too long, see xref:manage:kubernetes/troubleshooting/k-troublesho . Verify that each Redpanda broker is scheduled on only one Kubernetes node: + ```bash -kubectl get pod --namespace \ +kubectl get pod --namespace \ -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -l \ app.kubernetes.io/component=redpanda-statefulset ``` @@ -250,6 +255,160 @@ example-worker redpanda-2 -- ==== +== Deploy multiple Redpanda clusters + +You can deploy multiple Redpanda clusters in the same Kubernetes cluster. This is useful for creating separate environments (such as production, staging, and development) or for organizing clusters by application or team. + +[tabs] +==== +Operator:: ++ +-- + +When using the Redpanda Operator, you can deploy multiple Redpanda clusters by creating separate Redpanda custom resources. + +*Requirements:* + +- Use a cluster-scoped Redpanda Operator deployment (recommended) or separate namespace-scoped operators in different namespaces +- Each cluster must be deployed in a unique namespace +- Configure unique external port numbers for each cluster to avoid conflicts + +. Create a second Redpanda cluster in a different namespace: ++ +.`redpanda-cluster-two.yaml` +[,yaml,subs="attributes+"] +---- +apiVersion: cluster.redpanda.com/v1alpha2 +kind: Redpanda +metadata: + name: redpanda-staging + namespace: redpanda-staging +spec: + clusterSpec: + image: + tag: {latest-redpanda-tag} + listeners: + kafka: + external: + default: + advertisedPorts: [31093] <1> + admin: + external: + default: + advertisedPorts: [31645] <1> + http: + external: + default: + advertisedPorts: [30083] <1> + rpc: + port: 33146 <1> + schemaRegistry: + external: + default: + advertisedPorts: [30084] <1> + statefulset: + extraVolumes: |- + - name: redpanda-io-config + configMap: + name: redpanda-io-config + extraVolumeMounts: |- + - name: redpanda-io-config + mountPath: /etc/redpanda-io-config + additionalRedpandaCmdFlags: + - "--io-properties-file=/etc/redpanda-io-config/io-config.yaml" +---- ++ +<1> Configure unique port numbers for each cluster to avoid conflicts. Ensure these ports don't conflict with your first cluster's configuration. + +. Apply the second Redpanda resource: ++ +```bash +kubectl apply -f redpanda-cluster-two.yaml +``` + +. Wait for the second cluster to be ready: ++ +```bash +kubectl get redpanda --namespace redpanda-staging --watch +``` + +-- +Helm:: ++ +-- + +When using Helm, deploy multiple Redpanda clusters by using separate namespaces and unique release names for each deployment. + +*Requirements:* + +- Each cluster must be deployed in a unique namespace +- Use unique Helm release names for each deployment +- Configure unique external port numbers for each cluster to avoid conflicts + +. Create configuration values for your second cluster: ++ +.`redpanda-staging-values.yaml` +[,yaml,subs="attributes+"] +---- +image: + tag: {latest-redpanda-tag} +nameOverride: 'redpanda-staging' +fullnameOverride: 'redpanda-staging' +listeners: + kafka: + external: + default: + advertisedPorts: [31093] <1> + admin: + external: + default: + advertisedPorts: [31645] <1> + http: + external: + default: + advertisedPorts: [30083] <1> + rpc: + port: 33146 <1> + schemaRegistry: + external: + default: + advertisedPorts: [30084] <1> +statefulset: + extraVolumes: |- + - name: redpanda-io-config + configMap: + name: redpanda-io-config + extraVolumeMounts: |- + - name: redpanda-io-config + mountPath: /etc/redpanda-io-config + additionalRedpandaCmdFlags: + - "--io-properties-file=/etc/redpanda-io-config/io-config.yaml" +---- ++ +<1> Configure unique port numbers for each cluster to avoid conflicts. Ensure these ports don't conflict with your first cluster's configuration. + +. Install the second Redpanda cluster using a unique release name and namespace: ++ +[source,bash,subs="attributes+"] +---- +helm install redpanda-staging redpanda/redpanda \ + --version {latest-redpanda-helm-chart-version} \ + --namespace redpanda-staging \ + --create-namespace \ + --values redpanda-staging-values.yaml +---- + +. Wait for the second cluster to be ready: ++ +```bash +kubectl --namespace redpanda-staging rollout status statefulset redpanda-staging --watch +``` + +-- +==== + +IMPORTANT: When deploying multiple clusters, ensure that external listener ports are unique across all clusters to prevent conflicts. Also consider resource allocation and node capacity when planning multiple cluster deployments. + [[config]] == Production considerations @@ -593,7 +752,6 @@ rbac: annotations: {} ---- -NOTE: If you use the Redpanda Operator, you must also deploy the Redpanda Operator Helm chart with `rbac.createRPKBundleCRs` set to `true` to give it the required roles. See also: xref:manage:kubernetes/k-rack-awareness.adoc[] diff --git a/modules/deploy/partials/kubernetes/deploy-operator.adoc b/modules/deploy/partials/kubernetes/deploy-operator.adoc index 314f94489e..dfb8419915 100644 --- a/modules/deploy/partials/kubernetes/deploy-operator.adoc +++ b/modules/deploy/partials/kubernetes/deploy-operator.adoc @@ -1,4 +1,7 @@ +:latest-operator-version: 25.2.0 ifdef::latest-operator-version[] +.. To deploy in cluster scope, use: ++ [,bash,subs="attributes+"] ---- helm repo add redpanda https://charts.redpanda.com @@ -13,15 +16,21 @@ helm upgrade --install redpanda-controller redpanda/operator \ <1> This flag specifies the exact version of the Redpanda Operator Helm chart to use for deployment. By setting this value, you pin the chart to a specific version, which prevents automatic updates that might introduce breaking changes or new features that have not been tested in your environment. <2> This flag ensures that the CRDs are installed as part of the Redpanda Operator deployment. + -:note-caption: Older versions of the Redpanda Operator -+ -[NOTE] -======== -The `--set crds.enabled=true` flag is only supported in Redpanda Operator **v25.1.1 and later**. +This command deploys the Redpanda Operator in cluster scope (default in v25.2+), allowing it to manage Redpanda clusters across multiple namespaces. -If you deploy an earlier version (such as v2.4.x), you must install the CRDs separately. See the xref:25.1@ROOT:deploy:deployment-option/self-hosted/kubernetes/k-production-deployment.adoc[v2.4.x deployment documentation] for more information. -======== -:note-caption: Note +.. To deploy in namespace scope (managing only resources within its deployment namespace), use: ++ +[,bash,subs="attributes+"] +---- +helm upgrade --install redpanda-controller redpanda/operator \ + --namespace \ + --create-namespace \ + --version {latest-operator-version} \ + --set crds.enabled=true \ + --set 'additionalCmdFlags=["--namespace="]' <1> +---- ++ +<1> This flag restricts the Redpanda Operator to manage resources only within the specified namespace. endif::[] ifndef::latest-operator-version[] [,bash,subs="attributes+"] diff --git a/modules/get-started/pages/release-notes/helm-charts.adoc b/modules/get-started/pages/release-notes/helm-charts.adoc index 9f083d1121..99900fdc5a 100644 --- a/modules/get-started/pages/release-notes/helm-charts.adoc +++ b/modules/get-started/pages/release-notes/helm-charts.adoc @@ -12,92 +12,57 @@ See also: * xref:upgrade:k-compatibility.adoc[] * xref:upgrade:k-rolling-upgrade.adoc[] -== Redpanda chart v25.1.1 (GA) +== Redpanda chart v25.2.1 -link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.1.x/charts/redpanda/CHANGELOG.md[Changelog^]. +link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.2.x/charts/redpanda/CHANGELOG.md[Changelog^]. -=== Redpanda Console v3 +=== New chart-wide podTemplate field -This version deploys Redpanda Console v3, which includes unified authentication and authorization between the Redpanda Console and Redpanda, including user impersonation. For more information, see xref:console:config/security/authentication.adoc[]. +You can now use the chart-wide `podTemplate` field to control Pod attributes across all components. This field has lower precedence than `statefulset.podTemplate` and `post_install_job.podTemplate` but will be merged with them. -This version does not support Redpanda Console v2. +Additionally, `podTemplate` fields now support template expressions within string fields, allowing you to use Helm templating for dynamic values: -Before upgrading, migrate your Redpanda Console v2 configuration to the new v3 format. For more information, see xref:migrate:console-v3.adoc[]. - -=== Schema validation - -The Redpanda Helm chart now includes stricter schema validation to ensure configurations conform to expected standards. With schema validation enabled, you must ensure your overrides include valid fields. - -=== Removed fields - -The following deprecated fields have been removed from the Helm values. Before upgrading, review your configurations and replace the removed fields with their replacements. For the list of removed fields, see the link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.1.x/charts/redpanda/CHANGELOG.md[changelog^]. - -=== Updated versioning scheme - -An updated versioning scheme now better supports and tracks compatible Redpanda versions, ensuring smoother upgrades and improved compatibility management. - -See also: xref:upgrade:k-compatibility.adoc[]. - -=== Kafka Connect integration removed from Helm chart - -Starting with version 25.1.x of the Redpanda Helm chart, Kafka Connect is no longer bundled as a subchart. - -If you require Kafka Connect, you must install the `connectors` Helm chart separately after deploying Redpanda. - -For instructions, see xref:deploy:kafka-connect/k-deploy-kafka-connect.adoc[]. - -To check if you're currently using Redpanda's managed Kafka Connect, run: - -[,bash] +[,yaml] ---- -kubectl get pod -l app.kubernetes.io/name=connectors --namespace +podTemplate: + annotations: + "release-name": '{{ .Release.Name }}' ---- -NOTE: For stream processing on Kubernetes, consider using xref:redpanda-connect:get-started:quickstarts/helm-chart.adoc[Redpanda Connect]. It offers a simplified, scalable alternative to Kafka Connect for building data pipelines with a supported Kubernetes integration. +This compensates for functionality lost with the removal of fields like `extraVolumes`, while being more maintainable and less error prone. -=== Reference Kubernetes Secrets and ConfigMaps for Redpanda cluster configuration +=== Improved config-watcher sidecar -You can now set any Redpanda cluster configuration property using the new `extraClusterConfiguration` field. This allows you to reference values from Kubernetes Secrets or ConfigMaps. For example, use this field to inject sensitive credentials or reuse shared configurations across features like Tiered Storage, Iceberg, and disaster recovery. +The config-watcher sidecar is now a dedicated Go binary that handles user management and simplifies cluster health checks. Health checks no longer fail when the sole issue is that other nodes in the cluster are unavailable. -This enhancement improves: +=== rpk debug bundle now works by default -- Security: Avoid hardcoding secrets in Helm values or manifests. +The chart now creates `Roles` and `RoleBindings` that satisfy the requirements for running `rpk debug bundle --namespace` from any Redpanda Pod. These permissions may be disabled by setting `rbac.rpkDebugBundle=false`. -- Reusability: Centralize common values used by multiple features. +The Redpanda container now always has a Kubernetes ServiceAccount token mounted to ensure `rpk debug bundle` can be executed successfully. -- Maintainability: Better integrate with GitOps workflows and Kubernetes-native resource management. +=== ServiceAccount creation now enabled by default -See xref:manage:kubernetes/k-configure-helm-chart.adoc#extra-cluster-config[Set Redpanda cluster properties from Kubernetes Secrets or ConfigMaps]. +The `serviceAccount.create` field now defaults to `true`. Previously, the chart used the `default` ServiceAccount and extended it with all bindings. -== Redpanda chart v5.10.x +=== Stricter schema validation -=== Ability to change StatefulSet replicas without restarting brokers +Any unexpected values now result in a validation error. Previously, unexpected values would have been silently ignored. -Starting in v5.10.1, the Redpanda Helm chart allows you to increase or decrease the number of replicas in a StatefulSet without restarting existing brokers. This ability is useful for scaling your cluster up or down without downtime. +Ensure your Helm values only include valid fields before upgrading. -== Redpanda chart v5.9.x +=== Redpanda Console v3.1.0 -=== Sidecar for broker decommissioning and PVC cleanup +The Console dependency has been updated to v3.1.0. The Console integration (`console.enabled=true`) now uses the chart-managed bootstrap user rather than the first user from `auth.sasl.users`. -Version v5.9.21 of the Redpanda Helm chart introduces two new sidecar-based controllers to manage broker decommissioning and persistent volume cleanup: +=== Deprecated Helm values -- xref:manage:kubernetes/k-decommission-brokers.adoc#Automated[BrokerDecommissioner]: Detects **non-graceful broker failures**, such as node crashes, and **triggers automated decommissioning**. -- xref:manage:kubernetes/k-nodewatcher.adoc[PVCUnbinder]: Ensures **persistent volume claims (PVCs) are properly unbound and cleaned up** after broker removal. +The following Helm values are deprecated and will be removed in a future release: -The NodeWatcher and Decommission controllers are deprecated and replaced by a single sidecar. To enable the equivalent of the controllers, set the `enabled` flag to `true` in your Redpanda custom resource. For example: +* `statefulset.sidecars.controllers.image`: Use `statefulset.sidecars.image` instead +* `statefulset.sideCars.controllers.createRBAC`: Use `rbac.enabled` or per-controller settings instead +* `statefulset.sideCars.controllers.run`: Use individual controller enabled fields instead -[,yaml] ----- -statefulset: - sideCars: - brokerDecommissioner: - enabled: true - decommissionAfter: 60s - pvcUnbinder: - enabled: true - unbindAfter: 60s -rbac: - enabled: true ----- +=== Removed Helm values -If you previously relied on the NodeWatcher or Decommission controllers, switch to the new sidecars for improved stability and control. +Several fields have been removed in favor of using `podTemplate`. Before upgrading, review your configurations and migrate removed fields to their `podTemplate` equivalents. For the complete list of removed fields and their replacements, see the link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.2.x/charts/redpanda/CHANGELOG.md[changelog^]. diff --git a/modules/get-started/pages/release-notes/operator.adoc b/modules/get-started/pages/release-notes/operator.adoc index 18cede9410..5c1c659b98 100644 --- a/modules/get-started/pages/release-notes/operator.adoc +++ b/modules/get-started/pages/release-notes/operator.adoc @@ -9,11 +9,10 @@ See also: * xref:upgrade:k-compatibility.adoc[] * xref:upgrade:k-rolling-upgrade.adoc[] -== Redpanda Operator v25.2.x (beta) -link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.2.x/operator/CHANGELOG.md[Changelog^]. +== Redpanda Operator v25.2.x -See also: xref:deploy:redpanda/kubernetes/k-25.2-beta.adoc[]. +link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.2.x/operator/CHANGELOG.md[Changelog^] === Cluster scope by default @@ -25,164 +24,42 @@ Starting in v25.2, the Redpanda Operator defaults to cluster scope instead of na * **Cross-namespace management**: Deploy the operator in a dedicated namespace (such as `redpanda-system`) while managing clusters in application namespaces. * **Simplified RBAC for debug bundles**: The Redpanda Operator now provides all required permissions for `rpk` debug bundle collection by default. The `rbac.createRPKBundleCRs` flag is no longer needed. -== Redpanda Operator v25.1.x (GA) +==== Migration considerations -link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.1.x/operator/CHANGELOG.md[Changelog^] +If you're upgrading from a previous version that used namespace-scoped operators: -=== Redpanda Console v3 +* **No manual steps required**: The Redpanda Operator automatically reconciles existing Redpanda clusters across namespaces. +* **New deployments default to cluster scope**: Regardless of which namespace you deploy the Redpanda Operator to (including `default`). +* **Delete extra Redpanda Operator deployments**: After upgrading, ensure only one Redpanda Operator remains in the cluster (the one running in cluster scope). Use `helm uninstall` to remove any other Redpanda Operator deployments from previous namespace-scoped installations. -Redpanda Console v3 is **not yet available when deploying with the Redpanda Operator**, due to pending CRD updates. The Redpanda Operator continues to deploy Redpanda Console v2. xref:24.3@ROOT:console:index.adoc[View the Redpanda Console v2 documentation]. +To maintain namespace scope, use the `--set 'additionalCmdFlags=["--namespace="]'` flag when installing or upgrading the Redpanda Operator. The `--namespace` flag in the helm command only specifies which namespace to deploy the Redpanda Operator into and does not affect its operational scope. -To try Redpanda Console v3 in Kubernetes, you can xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[deploy Redpanda using the Redpanda Helm chart] instead of the Redpanda Operator. Redpanda Console v3 introduces support for unified authentication and authorization with Redpanda, including user impersonation. +WARNING: Do not run multiple Redpanda Operators in different scopes (cluster and namespace scope) in the same cluster as this can cause resource conflicts. -=== Multiple Operator instances (deprecated) +==== RBAC requirements -Support for deploying multiple instances of the Redpanda Operator in a single Kubernetes cluster is **deprecated** starting in Redpanda Operator v25.1.x. This feature will be removed in v25.2.x. +Important RBAC considerations for v25.2+: -If you currently run multiple Operator instances, plan to migrate to a single Operator instance per Kubernetes cluster before upgrading to v25.2.x. +* **ClusterRole permissions always required**: Regardless of whether you use cluster or namespace scope, the Redpanda Operator always needs ClusterRole permissions. +* **Automatic configuration**: These permissions are automatically configured when you install the Redpanda Operator. -=== Flux removed +=== Declarative role management -This release removes Flux and its CRDs. The Redpanda Operator now manages all resources. The `chartRef.useFlux` configuration is still available for backwards compatibility but *must* be set to `false`. +Redpanda Operator v25.2.x now includes a RedpandaRole custom resource. The RedpandaRole resource allows you to declaratively manage Redpanda roles and permissions in Kubernetes, making it easier to control access and automate security policies for your Redpanda clusters. See the xref:manage:kubernetes/security/authorization/k-role-controller.adoc[RedpandaRole documentation] for details. -=== Schema validation +=== Redpanda Console v3 support (Console CRD) -The Redpanda custom resource definition (CRD) now includes stricter schema validation to ensure configurations conform to expected standards. With this new schema validation enabled, you must ensure your Redpanda CRD configurations include valid fields. +Redpanda Operator v25.2.x introduces support for Redpanda Console v3 through the new Console resource. This allows you to deploy and manage Redpanda Console v3 instances directly from the Redpanda Operator. -For example, given the values: +The `console` stanza in the Redpanda resource is deprecated and will be removed in a future release. -[,yaml] ----- -statefulset: - replicas: "Not a number" - pandas: - there-is: a-typo-in-this-field ----- +Existing deployments that use the `console` stanza in the Redpanda resource will be automatically migrated to the Console resource. The migration happens automatically when you upgrade to v25.2.x. -In previous versions, you'd get an error about `statefulset.replicas` needing to be a number but no error about `pandas` being an invalid field. In v25.1.x, you'll get an error about `statefulset.replicas` needing to be a number and an error that `pandas` isn't an allowed field. +If you manage your resources in version control, you should: -=== Removed fields +. Fetch and commit the migrated Console CR after the migration completes. +. Remove the `console` stanza from your Redpanda resource after the Console CR is committed to avoid configuration conflicts. Removing the stanza will not affect the migrated Console CR. -Deprecated fields have been removed from the CRD. Before upgrading, review your configurations and replace the removed fields with their replacements. For the list of removed fields, see the link:https://github.com/redpanda-data/redpanda-operator/blob/release/v25.1.x/operator/CHANGELOG.md[changelog^]. +The Redpanda Operator handles the migration process from version 2 of Redpanda Console to version 3. If any configurations cannot be migrated, the Redpanda Operator displays warnings in the `warnings` field of the Console resource. If you need to manually migrate any configurations, refer to the xref:migrate:console-v3.adoc[migration guide]. -=== Updated versioning scheme - -An updated versioning scheme now better supports and tracks compatible Redpanda versions, ensuring smoother upgrades and improved compatibility management. - -See also: xref:upgrade:k-compatibility.adoc[]. - -=== Unified Helm installation of Redpanda Operator and CRDs - -Starting in Redpanda Operator v25.1.1, you can install both the Redpanda Operator and its required custom resource definitions (CRDs) using a single Helm command: - -[,bash,subs="attributes+"] ----- -helm repo add redpanda https://charts.redpanda.com -helm repo update -helm upgrade --install redpanda-controller redpanda/operator \ - --namespace \ - --create-namespace \ - --version {latest-operator-version} \ - --set crds.enabled=true ----- - -=== Kafka Connect integration removed from Helm chart - -Starting with version 25.1.x of the Redpanda Helm chart, Kafka Connect is no longer bundled as a subchart. - -If you require Kafka Connect, you must install the `connectors` Helm chart separately after deploying Redpanda. - -For instructions, see xref:deploy:kafka-connect/k-deploy-kafka-connect.adoc[]. - -To check if you're currently using Redpanda's managed Kafka Connect, run: - -[,bash] ----- -kubectl get pod -l app.kubernetes.io/name=connectors --namespace ----- - -NOTE: For stream processing on Kubernetes, consider using xref:redpanda-connect:get-started:quickstarts/helm-chart.adoc[Redpanda Connect]. It offers a simplified, scalable alternative to Kafka Connect for building data pipelines with a supported Kubernetes integration. - -=== Reference Kubernetes Secrets and ConfigMaps for Redpanda cluster configuration - -You can now set any Redpanda cluster configuration property using the new `extraClusterConfiguration` field. This allows you to reference values from Kubernetes Secrets or ConfigMaps. For example, use this field to inject sensitive credentials or reuse shared configurations across features like Tiered Storage, Iceberg, and disaster recovery. - -This enhancement improves: - -- Security: Avoid hardcoding secrets in Helm values or manifests. - -- Reusability: Centralize common values used by multiple features. - -- Maintainability: Better integrate with GitOps workflows and Kubernetes-native resource management. - -See xref:manage:kubernetes/k-configure-helm-chart.adoc#extra-cluster-config[Set Redpanda cluster properties from Kubernetes Secrets or ConfigMaps]. - -== Redpanda Operator v2.4.x - -link:https://github.com/redpanda-data/redpanda-operator/blob/release/v2.4.x/operator/CHANGELOG.md[Changelog^]. - -=== Flux disabled by default - -In version v2.3.x the `chartRef.useFlux` configuration was in beta and set to `true` by default. Starting from version v2.4.1, the `chartRef.useFlux:false` configuration is both GA and the default. - -*Breaking change:* If you depend on Flux, explicitly set `chartRef.useFlux: true` in your configuration. - -Example: - -[,yaml] ----- -spec: - chartRef: - useFlux: true ----- - -If you upgrade to v2.4.x from an older version in which Flux was explicitly enabled, Flux remains in use. If Flux was explicitly disabled, it remains disabled after an upgrade unless you explicitly enable it. - -=== Smarter Kubernetes rolling restarts and upgrades - -This release improves how brokers are marked healthy, reducing unnecessary stalls during upgrades, especially under load. - -=== Ability to change StatefulSet replicas without restarting brokers - -Starting in v2.4.1, the Redpanda Operator allows you to increase or decrease the number of replicas in a StatefulSet without restarting existing brokers. This ability is useful for scaling your cluster up or down without downtime. - -=== Unified versioning for the Redpanda Operator Helm chart - -Starting with Redpanda Operator v2.4.1, the Helm chart versioning has been streamlined so that the chart version is always identical to the Redpanda Operator's version. The `version` field now matches the `appVersion` field. - -This unified versioning approach simplifies the upgrade process, ensuring that you always deploy the chart corresponding to your desired version of the Redpanda Operator. - -== Redpanda Operator v2.3.x - -link:https://github.com/redpanda-data/redpanda-operator/blob/release/v2.3.x/operator/CHANGELOG.md[Changelog^]. - -=== Declarative schema management - -The Redpanda Operator now supports declarative schema management using the Schema custom resource, starting in version v2.3.0. This feature allows you to: - -- Define, create, and manage Avro, Protobuf, and JSON schemas declaratively. -- Enforce schema compatibility and evolution policies directly in Kubernetes. -- Automate schema lifecycle management alongside Redpanda deployments. - -To learn more, see the xref:manage:kubernetes/k-schema-controller.adoc[Schema custom resource documentation]. - -=== Use Redpanda Operator without Flux - -The Redpanda Operator now supports the `chartRef.useFlux` flag, giving you control over resource management, starting in version v2.3.0. - -- `chartRef.useFlux: false`: Directly manages resources within the Redpanda Operator, bypassing Flux. -- `chartRef.useFlux: true`: Delegates Redpanda resource management to Flux controllers through HelmRelease resources. - -This flag is in beta and set to `true` by default. If you want to use the Redpanda Operator without Flux, set `chartRef.useFlux: false` in your configuration. - -== Redpanda Operator v2.2.x - -=== Declarative user and ACL management - -The Redpanda Operator now supports declarative management of users and access control lists (ACLs) using the new User custom resource, starting in version v2.2.2. This feature allows you to: - -- Create and manage Redpanda users and their authentication settings. -- Define and manage ACLs to control access to Redpanda resources. -- Automatically reconcile changes to users and ACLs using the Redpanda Operator. - -To learn more, see the xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User custom resource documentation]. +All configuration and management of Redpanda Console should be done through the Console CR. See xref:console:config/configure-console.adoc[]. \ No newline at end of file diff --git a/modules/manage/pages/kubernetes/k-manage-resources.adoc b/modules/manage/pages/kubernetes/k-manage-resources.adoc index 0129eb08ff..72a40cc770 100644 --- a/modules/manage/pages/kubernetes/k-manage-resources.adoc +++ b/modules/manage/pages/kubernetes/k-manage-resources.adoc @@ -361,31 +361,33 @@ statefulset: limits: cpu: # Matches the request memory: # Matches the request - initContainers: - tuning: - resources: - requests: - cpu: - memory: - limits: - cpu: # Matches the request - memory: # Matches the request - setTieredStorageCacheDirOwnership: - resources: - requests: - cpu: - memory: - limits: - cpu: # Matches the request - memory: # Matches the request - configurator: - resources: - requests: - cpu: - memory: - limits: - cpu: # Matches the request - memory: # Matches the request + podTemplate: + spec: + initContainers: + - name: tuning + resources: + requests: + cpu: + memory: + limits: + cpu: # Matches the request + memory: # Matches the request + - name: set-tiered-storage-cache-dir-ownership + resources: + requests: + cpu: + memory: + limits: + cpu: # Matches the request + memory: # Matches the request + - name: configurator + resources: + requests: + cpu: + memory: + limits: + cpu: # Matches the request + memory: # Matches the request ---- + ```bash @@ -403,20 +405,10 @@ helm upgrade --install redpanda redpanda/redpanda --namespace --crea --set statefulset.sideCars.configWatcher.resources.requests.cpu= \ --set statefulset.sideCars.configWatcher.resources.requests.memory= \ --set statefulset.sideCars.configWatcher.resources.limits.cpu= \ - --set statefulset.sideCars.configWatcher.resources.limits.memory= \ - --set statefulset.initContainers.tuning.resources.requests.cpu= \ - --set statefulset.initContainers.tuning.resources.requests.memory= \ - --set statefulset.initContainers.tuning.resources.limits.cpu= \ - --set statefulset.initContainers.tuning.resources.limits.memory= \ - --set statefulset.initContainers.setTieredStorageCacheDirOwnership.resources.requests.cpu= \ - --set statefulset.initContainers.setTieredStorageCacheDirOwnership.resources.requests.memory= \ - --set statefulset.initContainers.setTieredStorageCacheDirOwnership.resources.limits.cpu= \ - --set statefulset.initContainers.setTieredStorageCacheDirOwnership.resources.limits.memory= \ - --set statefulset.initContainers.configurator.resources.requests.cpu= \ - --set statefulset.initContainers.configurator.resources.requests.memory= \ - --set statefulset.initContainers.configurator.resources.limits.cpu= \ - --set statefulset.initContainers.configurator.resources.limits.memory= + --set statefulset.sideCars.configWatcher.resources.limits.memory= ``` ++ +NOTE: Init container resources must be configured using a values file with the `statefulset.podTemplate.spec.initContainers` structure. See the `--values` example above. ==== -- diff --git a/modules/manage/pages/kubernetes/k-manage-topics.adoc b/modules/manage/pages/kubernetes/k-manage-topics.adoc index 73a38a52eb..aadc9ece3b 100644 --- a/modules/manage/pages/kubernetes/k-manage-topics.adoc +++ b/modules/manage/pages/kubernetes/k-manage-topics.adoc @@ -25,36 +25,53 @@ For details about ACLs, see xref:security/authorization/index.adoc[]. == Create a topic -You can create a topic using a Topic resource: - -[,yaml,lines=4+6+10-15] +. Define a topic using the Topic resource. Here's a basic example configuration: ++ +.`topic.yaml` +[,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: - name: + name: + namespace: spec: - kafkaApiSpec: - brokers: [] - tls: {} - sasl: {} - partitions: - replicationFactor: + cluster: + clusterRef: + name: + partitions: + replicationFactor: additionalConfig: {} - metricsNamespace: - overwriteTopicName: - interval: ---- - -- xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topicspec[`metadata.name`] (*required*): The name of the Topic resource. If the <> property is not set, the name of the Topic resource is also given to the topic in Redpanda. ++ +Replace the following placeholders: ++ +- ``: The name of the Topic resource. If the <> property is not set, the name of the Topic resource is also given to the topic in Redpanda. + Valid names must consist of lowercase alphanumeric characters, hyphens (-), or periods (.). Names cannot start or end with a non-alphanumeric character. Underscores (_) are not allowed. For example, `chat-room` is a valid name, whereas `chat_room` is not. To use other characters such as underscores in your topic names, use the <> property. ++ +- ``: The namespace in which to deploy the Topic resource. The Topic resource must be deployed in the same namespace as the Redpanda resource defined in `clusterRef.name`. +- ``: The name of the Redpanda resource that defines the Redpanda cluster in which you want to create the topic. +- ``: The number of topic shards distributed across the brokers in a Redpanda cluster. This value cannot be decreased post-creation. Overrides the default cluster property xref:reference:cluster-properties.adoc#default_topic_partitions[`default_topic_partitions`]. +- ``: Specifies the number of topic replicas. The value must be an odd number. Overrides the default cluster property xref:reference:cluster-properties.adoc#default_topic_replications[`default_topic_replications`]. -- xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-kafkaapispec[`spec.kafkaApiSpec`] (*required*): Configuration details for connecting to Redpanda brokers. +. Apply the manifest: ++ +[,bash] +---- +kubectl apply -f topic.yaml --namespace +---- ++ +When the manifest is applied, the topic will be created in your Redpanda cluster. -- xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topicspec[`spec.partitions`]: The number of topic shards distributed across the brokers in a Redpanda cluster. This value cannot be decreased post-creation. Overrides the default cluster property xref:reference:cluster-properties.adoc#default_topic_partitions[`default_topic_partitions`]. +. Check the status of the Topic resource using the following command: ++ +[,bash] +---- +kubectl get topic --namespace +---- -- xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topicspec[`spec.replicationFactor`]: Specifies the number of topic replicas. The value must be an odd number. Overrides the default cluster property xref:reference:cluster-properties.adoc#default_topic_replications[`default_topic_replications`]. +Additional configuration options: - xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topicspec[`spec.additionalConfig`]: A map of any topic-specific configuration options. See xref:reference:topic-properties.adoc[]. @@ -64,50 +81,110 @@ Valid names must consist of lowercase alphanumeric characters, hyphens (-), or p - xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topicspec[`spec.interval`]: Sets the reconciliation interval for the topic controller. Default is 3 seconds (`3s`). -The default settings are best suited to a one-broker cluster in a development environment. To learn how to modify the default values in the configuration file, see xref:manage:cluster-maintenance/cluster-property-configuration.adoc[Configure Cluster Properties]. Even if you set default values that work for most topics, you may still want to change some properties for a specific topic. +You can find all configuration options for the Topic resource in the xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topic[CRD reference]. -=== Example Topic resource +== Topic examples -This example creates a topic called `chat-room`. -The `kafkaApiSpec` property configures the connection to a Redpanda cluster using the defaults in the Redpanda Helm chart. +This example demonstrates how to create a basic topic in your Redpanda cluster. + +.`topic.yaml` +[,yaml,indent=0] +---- +include::manage:example$kubernetes/topic-crds.feature[tags=basic-topic-example,indent=0] +---- + +Apply the manifest: + +[,bash] +---- +kubectl apply -f topic.yaml --namespace +---- + +Replace `` with the namespace in which you deployed the Redpanda cluster. + +== Choose a cluster connection method + +When creating a Topic resource, you can connect to your Redpanda cluster in two ways: + +- **clusterRef**: Reference the Redpanda cluster by name for automatic connection. This is the recommended approach for most users. +- **staticConfiguration**: Manually specify connection details for Kafka and Admin API if you need custom settings. + +The Redpanda Operator automatically configures the Topic controller to connect to the referenced cluster when using `clusterRef`. Use `staticConfiguration` only if you need to: + +* Override the default connection settings +* Connect to a Redpanda cluster not managed by the Redpanda Operator +* Use custom TLS or SASL authentication settings + +=== Use clusterRef (recommended) + +The `clusterRef` method automatically discovers connection details from the referenced Redpanda resource: -.`example-topic.yaml` [,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: - name: chat-room + name: example-topic + namespace: spec: + cluster: + clusterRef: + name: partitions: 3 replicationFactor: 3 - additionalConfig: - cleanup.policy: "compact" - kafkaApiSpec: - brokers: - - "redpanda-0.redpanda..svc.cluster.local:9093" - - "redpanda-1.redpanda..svc.cluster.local:9093" - - "redpanda-2.redpanda..svc.cluster.local:9093" - tls: - caCertSecretRef: - name: "redpanda-default-cert" - key: "ca.crt" ---- -[,bash] +=== Use staticConfiguration + +The `staticConfiguration` method requires manually specifying all connection details: + +[,yaml] ---- -kubectl apply -f example-topic.yaml --namespace +apiVersion: cluster.redpanda.com/v1alpha2 +kind: Topic +metadata: + name: example-topic + namespace: +spec: + cluster: + staticConfiguration: + kafka: + brokers: + - "redpanda-0.redpanda..svc.cluster.local:9093" + - "redpanda-1.redpanda..svc.cluster.local:9093" + - "redpanda-2.redpanda..svc.cluster.local:9093" + tls: + caCertSecretRef: + name: "redpanda-default-cert" + key: "ca.crt" + sasl: + username: "admin" + passwordSecretRef: + name: "redpanda-admin-password" + key: "password" + mechanism: "SCRAM-SHA-256" + admin: + urls: + - "http://redpanda-0.redpanda..svc.cluster.local:9644" + - "http://redpanda-1.redpanda..svc.cluster.local:9644" + - "http://redpanda-2.redpanda..svc.cluster.local:9644" + tls: + caCertSecretRef: + name: "redpanda-default-cert" + key: "ca.crt" + partitions: 3 + replicationFactor: 3 ---- -Replace `` with the namespace in which you deployed Redpanda. +For all available configuration options, see the xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-clustersource[ClusterSource reference]. -=== Choose the number of partitions +== Choose the number of partitions A partition acts as a log file where topic data is written. Dividing topics into partitions allows producers to write messages in parallel and consumers to read messages in parallel. The higher the number of partitions, the greater the throughput. TIP: As a general rule, select a number of partitions that corresponds to the maximum number of consumers in any consumer group that will consume the data. -=== Choose the replication factor +== Choose the replication factor Replicas are copies of partitions that are distributed across different brokers, so if one broker goes down, other brokers still have a copy of the data. The default replication factor in the cluster configuration is set to 1. @@ -115,7 +192,7 @@ By choosing a replication factor greater than 1, you ensure that each partition NOTE: The replication factor must be an odd number. Redpanda Data recommends a replication factor of 3 for most use cases. -=== Choose the cleanup policy +== Choose the cleanup policy The cleanup policy determines how to manage the partition log files when they reach a certain size: @@ -127,7 +204,7 @@ If the cleanup policy is `delete` or `compact,delete` you can < spec: + cluster: + clusterRef: + name: additionalConfig: redpanda.iceberg.mode: "" <.> - kafkaApiSpec: - brokers: - - "redpanda-0.redpanda..svc.cluster.local:9093" - tls: - caCertSecretRef: - name: "redpanda-default-cert" - key: "ca.crt" ---- <.> Supported modes: @@ -174,7 +248,7 @@ Apply the resource to your Kubernetes cluster: kubectl apply -f iceberg-topic.yaml --namespace ---- -=== Configure write caching +== Configure write caching Write caching is a relaxed mode of xref:develop:produce-data/configure-producers.adoc#acksall[`acks=all`] that provides better performance at the expense of durability. It acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. This provides lower latency while still ensuring that a majority of brokers acknowledge the write. @@ -184,7 +258,7 @@ NOTE: For clusters in xref:reference:rpk/rpk-redpanda/rpk-redpanda-mode.adoc#dev Only enable write caching on workloads that can tolerate some data loss in the case of multiple, simultaneous broker failures. Leaving write caching disabled safeguards your data against complete data center or availability zone failures. -==== Configure at cluster level +=== Configure at cluster level To enable write caching by default in all user topics, set the cluster-level property xref:reference:cluster-properties.adoc#write_caching_default[`write_caching_default`]: @@ -247,7 +321,7 @@ helm upgrade --install redpanda redpanda/redpanda --namespace --crea With `write_caching` enabled at the cluster level, Redpanda fsyncs to disk according to xref:reference:cluster-properties.adoc#raft_replica_max_pending_flush_bytes[`raft_replica_max_pending_flush_bytes`] and xref:reference:cluster-properties.adoc#raft_replica_max_flush_delay_ms[`raft_replica_max_flush_delay_ms`], whichever is reached first. -==== Configure at topic level +=== Configure at topic level To override the cluster-level setting at the topic level, set the topic-level property xref:reference:topic-properties.adoc#writecaching[`write.caching`]: @@ -258,20 +332,15 @@ apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: name: chat-room + namespace: spec: + cluster: + clusterRef: + name: partitions: 3 replicationFactor: 3 additionalConfig: write.caching: true - kafkaApiSpec: - brokers: - - "redpanda-0.redpanda..svc.cluster.local:9093" - - "redpanda-1.redpanda..svc.cluster.local:9093" - - "redpanda-2.redpanda..svc.cluster.local:9093" - tls: - caCertSecretRef: - name: "redpanda-default-cert" - key: "ca.crt" ---- With `write.caching` enabled at the topic level, Redpanda fsyncs to disk according to xref:reference:topic-properties.adoc#flushms[`flush.ms`] and xref:reference:topic-properties.adoc#flushbytes[`flush.bytes`], whichever is reached first. @@ -371,7 +440,7 @@ items: metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"cluster.redpanda.com/v1alpha2","kind":"Topic","metadata":{"annotations":{},"name":"chat-room","namespace":"redpanda"},"spec":{"additionalConfig":{"cleanup.policy":"compact"},"kafkaApiSpec":{"brokers":["redpanda-0.redpanda.redpanda.svc.cluster.local:9093","redpanda-1.redpanda.redpanda.svc.cluster.local:9093","redpanda-2.redpanda.redpanda.svc.cluster.local:9093"],"tls":{"caCertSecretRef":{"key":"ca.crt","name":"redpanda-default-cert"}}},"partitions":3,"replicationFactor":3}} + {"apiVersion":"cluster.redpanda.com/v1alpha2","kind":"Topic","metadata":{"annotations":{},"name":"chat-room","namespace":"redpanda"},"spec":{"additionalConfig":{"cleanup.policy":"compact"},"cluster":{"clusterRef":{"name":"redpanda"}},"partitions":3,"replicationFactor":3}} creationTimestamp: "2023-10-04T10:51:20Z" finalizers: - operator.redpanda.com/finalizer @@ -384,15 +453,9 @@ items: additionalConfig: cleanup.policy: compact interval: 3s - kafkaApiSpec: - brokers: - - redpanda-0.redpanda.redpanda.svc.cluster.local:9093 - - redpanda-1.redpanda.redpanda.svc.cluster.local:9093 - - redpanda-2.redpanda.redpanda.svc.cluster.local:9093 - tls: - caCertSecretRef: - key: ca.crt - name: redpanda-default-cert + cluster: + clusterRef: + name: redpanda partitions: 3 replicationFactor: 3 status: @@ -561,7 +624,7 @@ To update a topic, edit the Topic resource configuration, and apply the changes. CAUTION: Do not use `rpk` or any other Kafka clients to edit topics that you created using the Topic resource. The topic controller monitors the Redpanda cluster for changes to topics. If you use a Kafka client to edit the topic, the topic controller detects those changes as a drift from the desired state and attempts to reconcile those changes by reverting them to match the Topic resource's state. -The following example changes the cleanup policy for the `chat-room` topic: +The following example changes the cleanup policy for a topic: .`example-topic.yaml` [,yaml,lines=8-9] @@ -569,21 +632,16 @@ The following example changes the cleanup policy for the `chat-room` topic: apiVersion: cluster.redpanda.com/v1alpha2 kind: Topic metadata: - name: chat-room + name: + namespace: spec: + cluster: + clusterRef: + name: partitions: 3 replicationFactor: 3 additionalConfig: cleanup.policy: "delete" - kafkaApiSpec: - brokers: - - "redpanda-0.redpanda..svc.cluster.local:9093" - - "redpanda-1.redpanda..svc.cluster.local:9093" - - "redpanda-2.redpanda..svc.cluster.local:9093" - tls: - caCertSecretRef: - name: "redpanda-default-cert" - key: "ca.crt" ---- [,bash] @@ -591,7 +649,7 @@ spec: kubectl apply -f example-topic.yaml --namespace ---- -To set a property back to its default value, remove it from the Redpanda resource. +To set a property back to its default value, remove it from the Topic resource. == Delete a topic diff --git a/modules/manage/pages/kubernetes/k-rack-awareness.adoc b/modules/manage/pages/kubernetes/k-rack-awareness.adoc index ab7377dee4..65eb182b14 100644 --- a/modules/manage/pages/kubernetes/k-rack-awareness.adoc +++ b/modules/manage/pages/kubernetes/k-rack-awareness.adoc @@ -17,7 +17,6 @@ You must have the following: * https://kubernetes.io/docs/tasks/tools/#kubectl[Kubectl^]: Ensure you have the `kubectl` command-line tool installed and configured to communicate with your cluster. -* If you use the xref:deploy:deployment-option/self-hosted/kubernetes/kubernetes-deploy.adoc[Redpanda Operator], you must deploy it with the `--set rbac.createRPKBundleCRs=true` flag to give it the required ClusterRoles to read node labels and annotations. == Annotate or label Node resources diff --git a/modules/manage/pages/kubernetes/k-rolling-restart.adoc b/modules/manage/pages/kubernetes/k-rolling-restart.adoc index 6643cfd337..c0c9668ba0 100644 --- a/modules/manage/pages/kubernetes/k-rolling-restart.adoc +++ b/modules/manage/pages/kubernetes/k-rolling-restart.adoc @@ -37,7 +37,7 @@ The Pod is then terminated and restarted due to the default rolling update polic The default `terminationGracePeriod` is 90 seconds, which should be long enough for maintenance mode to finish in large clusters. You can test different values in a development environment. To configure the `terminationGracePeriod`, -use the xref:reference:k-redpanda-helm-spec.adoc#statefulsetterminationgraceperiodseconds[`statefulset.terminationGracePeriodSeconds`] setting. +use the `statefulset.podTemplate.spec.terminationGracePeriodSeconds` setting. ==== . The `postStart` hook is executed immediately after a container is created. The `postStart` hook takes the broker out of maintenance mode. This action re-integrates the broker into the cluster, allowing it to start handling requests and participate in the cluster's operations again. diff --git a/modules/manage/pages/kubernetes/security/authentication/index.adoc b/modules/manage/pages/kubernetes/security/authentication/index.adoc index b8ac87f4f1..74badb6dbb 100644 --- a/modules/manage/pages/kubernetes/security/authentication/index.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/index.adoc @@ -1,6 +1,6 @@ -= Authentication for Redpanda in Kubernetes += Authentication and Authorization for Redpanda in Kubernetes :page-layout: index -:description: Learn how to configure authentication for Redpanda in Kubernetes using Helm values or the User resource with the Redpanda Operator. +:description: Learn how to configure authentication and authorization for Redpanda in Kubernetes using Helm values or the User resource with the Redpanda Operator. :page-aliases: security:sasl-kubernetes.adoc, manage:kubernetes/security/sasl-kubernetes.adoc, security:kubernetes-sasl.adoc, manage:kubernetes/security/authentication/sasl-kubernetes.adoc, reference:redpanda-operator/kubernetes-mtls.adoc, reference:redpanda-operator/kubernetes-sasl.adoc -Redpanda offers two methods to manage authentication in a Kubernetes environment. These options allow administrators to control user access and permissions, ensuring secure communication with the Redpanda cluster. \ No newline at end of file +Redpanda offers two methods to manage authentication and authorization in a Kubernetes environment. These options allow administrators to control user access and permissions, ensuring secure communication with the Redpanda cluster. \ No newline at end of file diff --git a/modules/manage/pages/kubernetes/security/authentication/k-user-controller.adoc b/modules/manage/pages/kubernetes/security/authentication/k-user-controller.adoc index 5c46594f18..5063b1420f 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-user-controller.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-user-controller.adoc @@ -5,6 +5,8 @@ With the Redpanda Operator, you can declaratively create and manage Redpanda users and glossterm:ACL[,access control lists (ACLs)] using xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[User custom resources] (resources) in Kubernetes. Each User resource is mapped to a user in your Redpanda cluster. The user controller, a component of the Redpanda Operator, keeps the corresponding user in sync with the User resource. +For role-based access control where you want to define permissions once and apply them to multiple users, see xref:manage:kubernetes/security/authorization/k-role-controller.adoc[Manage Roles and ACLs]. + == Prerequisites You must have the following: @@ -267,8 +269,32 @@ Deleting a User resource will have different impacts depending on how it is conf - **Authorization-only**: When a User resource that manages only ACLs is deleted, the ACLs are removed, but the user remains in the cluster. - **Full user management (both authentication and authorization)**: When the resource manages both users and ACLs, the user and its associated ACLs are removed. +== Best practices + +When working with User resources, consider the following best practices: + +=== User design + +- *Principle of least privilege*: Grant only the minimum permissions necessary for users to perform their tasks. +- *Descriptive usernames*: Use clear, consistent naming conventions that identify the user's purpose or role. +- *Avoid shared accounts*: Create individual user accounts rather than sharing credentials between multiple people or applications. + +=== Permission management + +- *Consider roles for shared permissions*: When multiple users need the same set of permissions, consider using xref:manage:kubernetes/security/authorization/k-role-controller.adoc[RedpandaRole resources] instead of duplicating ACLs across individual User resources. +- *User-specific permissions*: Use User resource ACLs for permissions that are specific to individual users and don't need to be shared. +- *Avoid conflicts*: If using both Role and User resources, be careful not to create conflicting ACLs for the same users. + +=== Secret management + +- *Use Kubernetes Secrets*: Store passwords in Kubernetes Secrets rather than hardcoding them in manifests. +- *Regular rotation*: Implement a regular password rotation strategy for production environments. + == Suggested reading * xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[User resource] * xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userlist[UserList resource] -* xref:manage:kubernetes/security/authentication/k-authentication.adoc[] \ No newline at end of file +* xref:manage:kubernetes/security/authorization/k-role-controller.adoc[Manage Roles and ACLs] +* xref:manage:kubernetes/security/authentication/k-authentication.adoc[] +* xref:manage:security/authorization/rbac.adoc[Role-Based Access Control (RBAC)] +* xref:manage:security/authorization/acl.adoc[Access Control Lists (ACLs)] \ No newline at end of file diff --git a/modules/manage/pages/kubernetes/security/authorization/k-role-controller.adoc b/modules/manage/pages/kubernetes/security/authorization/k-role-controller.adoc new file mode 100644 index 0000000000..89ce6e0c08 --- /dev/null +++ b/modules/manage/pages/kubernetes/security/authorization/k-role-controller.adoc @@ -0,0 +1,223 @@ += Manage Roles with the Redpanda Operator +:description: Use the RedpandaRole resource to declaratively create and manage roles as part of a Redpanda deployment. Each RedpandaRole resource defines a set of permissions that can be assigned to multiple users, providing role-based access control (RBAC) for your Redpanda cluster. +:page-categories: Management, Security +:env-kubernetes: true + +With the Redpanda Operator, you can declaratively create and manage Redpanda roles using xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[RedpandaRole custom resources] (resources) in Kubernetes. Each RedpandaRole resource defines a set of permissions that can be assigned to multiple users, providing role-based access control (RBAC) for your Redpanda cluster. The role controller, a component of the Redpanda Operator, keeps the corresponding Redpanda role in sync with the RedpandaRole resource. + +NOTE: RedpandaRole resources do not create users. Users must already exist in the Redpanda cluster before they can be assigned to roles, unless they are OIDC principals. OIDC principals do not need to be created as users in the cluster. Use xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User resources] to create and manage Redpanda users. + +== What are roles and why use them? + +Think of roles like job titles in a company. Instead of giving each employee individual permissions for every door, system, and resource, you create job titles (roles) like "Developer," "Manager," or "Security Guard." Each job title comes with a specific set of permissions, and you assign employees to those job titles. + +In Redpanda, roles work the same way: + +* **Without roles**: You set up permissions individually for each user. If you have 10 developers who all need the same access to certain topics, you configure the same permissions 10 times. + +* **With roles**: You create a "Developer" role once with all the necessary permissions, then assign all 10 developers to that role. When you need to change what developers can access, you update the role once instead of updating 10 individual users. + +== Prerequisites + +You must have the following: + +* *Kubectl*: Ensure you have the https://kubernetes.io/docs/tasks/tools/#kubectl[kubectl^] command-line tool installed and configured to communicate with your cluster. +* *Redpanda Operator*: Ensure you have at least version 25.2 of the xref:deploy:deployment-option/self-hosted/kubernetes/k-production-deployment.adoc[Redpanda Operator]. +* *Redpanda cluster with SASL enabled*: Ensure you have a Redpanda resource deployed with xref:manage:kubernetes/security/authentication/k-authentication.adoc#enable[SASL authentication enabled]. +* *Existing users*: If you plan to assign users to roles, ensure the users already exist in your Redpanda cluster. You can create users using xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User resources]. + +== Create a role + +You can use the RedpandaRole resource to: + +- <> +- <> +- <> + +Each Role instance is responsible for managing both the role membership (principals) and the role's ACLs within the Redpanda cluster. You cannot use one RedpandaRole resource to manage the principals and another resource to manage the ACLs. Only one Role instance is allowed per role in the Redpanda cluster. + +[[with-authorization]] +=== Create a role with authorization rules + +- *Use case*: You want to create a role that defines permissions and assign users to inherit those permissions. This is the most common use case for role-based access control, where you define permissions once and apply them to multiple users. +- *What happens when deleted*: Both the role and its associated ACLs are removed. Users assigned to the role lose the permissions granted by this role but retain any other permissions they have. + +This example shows how to create a role with both principals and authorization rules. + +.`read-only-role.yaml` +[,yaml,indent=0] +---- +include::manage:example$kubernetes/role-crds.feature[tags=manage-roles-with-authorization,indent=0] +---- + +[[with-principals]] +=== Create a role with principals + +- *Use case*: You want to create a role and assign users (principals) to it. This is useful for grouping users together without necessarily defining permissions at the role level, allowing you to manage group membership centrally. +- *What happens when deleted*: The role is deleted, but users assigned to the role remain in the cluster. Any ACLs defined at the user level are unaffected. + +This example shows how to create a role and assign principals to it. + +.`admin-role.yaml` +[,yaml,indent=0] +---- +include::manage:example$kubernetes/role-crds.feature[tags=manage-roles-with-principals,indent=0] +---- + +[[authorization-only]] +=== Create authorization rules for an existing role + +- *Use case*: You want to manage ACLs for an existing role in the Redpanda cluster, but not modify the role's membership. Use this option if role membership is managed by another process or tool, and you only want to control what resources the role can access. +- *What happens when deleted*: The ACLs are removed, but the role and its members remain. This is useful when you want to revoke permissions but retain the role structure for future use. + +This example shows how to manage only the ACLs for an existing role in the Redpanda cluster. + +.`authorization-only-role.yaml` +[,yaml,indent=0] +---- +include::manage:example$kubernetes/role-crds.feature[tags=manage-authz-only-roles,indent=0] +---- + +== Configuration + +The following sections provide guidance on setting up role membership, managing authorization rules, and defining ACLs within your Kubernetes environment. These recommendations ensure proper role management while minimizing manual interventions and preventing potential security issues. + +You can find all configuration options for the RedpandaRedpandaRole resource in the xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[CRD reference]. + +=== Choose a role name + +The `metadata.name` field in the RedpandaRedpandaRole resource is used to specify the role name. Keep in mind the following best practices when choosing a role name: + +- *Unique*: Ensure each role has a unique name to avoid conflicts. The role name must be unique within the Redpanda cluster. +- *Descriptive*: Choose a name that identifies the purpose or permissions of the role. For example, use names like `data-readers` or `topic-admins`. +- *Stable*: Avoid changing role names frequently. Role names are tied to authorization rules (ACLs) and user assignments. Renaming a role involves deleting and recreating the role. + +[,yaml] +---- +metadata: + name: read-only-role +---- + +In this example, `read-only-role` is the role name, which will be referenced in authorization rules and user assignments. + +=== Configure principals + +The xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolespec[`spec.principals`] field allows you to specify which users are assigned to the role. Principals are specified in the format `User:`. + +IMPORTANT: Users must already exist in the Redpanda cluster before they can be assigned to a role. The RedpandaRole resource does not create users that don't exist. + +[source,yaml] +---- +spec: + principals: + - User:alice + - User:bob +---- + +When users are assigned to a role, they inherit all the permissions defined in the role's ACLs. If a role has no ACLs defined, the users gain no additional permissions from the role membership. + +=== Define authorization rules + +The xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-roleauthorizationspec[`spec.authorization`] field allows you to manage ACLs for the role. ACLs define the permissions that all members of the role have over specific resources in Redpanda, such as topics, consumer groups, and clusters. + +You can define ACLs for a role by specifying which resources members can access and the operations they are permitted to perform. Here's an example configuration for managing ACLs: + +[source,yaml] +---- +spec: + authorization: + acls: + - type: allow + resource: + type: topic + name: public- + patternType: prefixed + operations: [Read, Describe] +---- + +- `type`: Defines whether the ACL allows or denies access. Acceptable values: `allow`, `deny`. +- `resource.type`: Specifies the resource type. Acceptable values: `topic`, `group`, `cluster`, `transactionalId`. +- `patternType`: Specifies how the resource name is interpreted. Acceptable values: `literal`, `prefixed`. Default: `literal`. ++ +TIP: Using `literal` names for resources ensures that only the exact resources you intend are accessible. Use `prefixed` patterns cautiously to avoid accidental permission grants. +- `operations`: Lists the allowed operations, such as `Read`, `Write`, `Create`, and `Delete`. + +You can find all configuration options for authorization in the xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-roleauthorizationspec[RoleAuthorizationSpec] of the CRD reference. + +For more details about ACLs, including supported operations and resources in Redpanda, see xref:manage:security/authorization/acl.adoc[]. + +== Deploy a RedpandaRole resource + +To deploy a RedpandaRole resource, apply the manifest to the same namespace as your Redpanda cluster: + +[,bash] +---- +kubectl apply -f .yaml --namespace +---- + +- Replace `` with the filename of your manifest. +- Replace `` with the namespace in which you deployed Redpanda. + +== Verify a role + +After deploying a RedpandaRole resource, verify that the Redpanda Operator reconciled it: + +[,bash] +---- +kubectl logs -l app.kubernetes.io/name=operator -c manager --namespace +---- + +== Update a role + +To update a role, edit the RedpandaRole resource configuration and apply the changes. + +[,bash] +---- +kubectl apply -f .yaml --namespace +---- + +== Delete a role + +To delete a role, delete the RedpandaRole resource: + +[,bash] +---- +kubectl delete -f .yaml --namespace +---- + +When a RedpandaRole resource is deleted, its underlying data is removed as well. If the role has ACLs, those ACLs are also removed. + +Deleting a RedpandaRole resource has different impacts depending on how it is configured: + +- **Principals-only**: When a RedpandaRole resource that manages only principals is deleted, the role is removed from the cluster. However, any ACLs not managed by the same resource will remain in place. +- **Authorization-only**: When a RedpandaRole resource that manages only ACLs is deleted, the ACLs are removed, but the role and its members remain in the cluster. +- **Full role management (both principals and authorization)**: When the resource manages both membership and ACLs, the role and its associated ACLs are removed. + +== Best practices + +When working with RedpandaRole resources, consider the following best practices: + +=== Role design + +- *Principle of least privilege*: Grant only the minimum permissions necessary for users to perform their tasks. +- *Logical grouping*: Create roles that align with job functions or responsibilities rather than individual users. +- *Naming conventions*: Use consistent, descriptive names that indicate the role's purpose, such as `topic-readers` or `admin-users`. + +=== Permission management + +- *Prefer role-based over user-based ACLs*: When possible, assign permissions to roles rather than individual users to simplify management. +- *Use specific resource patterns*: Prefer `literal` patterns over `prefixed` patterns unless you specifically need pattern matching. +- *Regular reviews*: Periodically review role permissions to ensure they remain appropriate and necessary. + +=== Integration with User resources + +- *Consistent management*: If you're using both Role and User resources, establish clear guidelines about which permissions are managed at the role level versus the user level. +- *Avoid conflicts*: Be careful not to create conflicting ACLs between Role and User resources for the same users. + +== Suggested reading + +* xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[RedpandaRole resource] +* xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolelist[RoleList resource] +* xref:manage:kubernetes/security/authentication/k-user-controller.adoc[Manage Users and ACLs] +* xref:manage:security/authorization/rbac.adoc[Role-Based Access Control (RBAC)] +* xref:manage:security/authorization/acl.adoc[Access Control Lists (ACLs)] diff --git a/modules/migrate/pages/console-v3.adoc b/modules/migrate/pages/console-v3.adoc index 1568dd4d45..0a58481eca 100644 --- a/modules/migrate/pages/console-v3.adoc +++ b/modules/migrate/pages/console-v3.adoc @@ -11,6 +11,268 @@ For details on the new authentication and authorization system, see xref:console TIP: Use the <> to convert your v2 configuration to v3 format. +== Choose your migration path + +Your migration approach depends on how you deploy Redpanda Console. + +=== Kubernetes with Redpanda Operator + +The operator automatically migrates most v2 configurations when you upgrade. Review the <> section to understand what's handled automatically and what requires manual intervention. + +=== Other deployment methods + +Manually migrate your configuration using this guide and the <>. Start with <>. + +== Pre-migration checklist + +Review your v2 configuration and check which of these breaking changes apply to you: + +* [ ] Have you configured Console with authentication? You must choose a v3 strategy. See <>. +* [ ] Do you use OIDC groups for authorization? They are not supported in v3. See <>. +* [ ] Do you configure more than one OIDC provider? You can use only one provider in v3. See <>. +* [ ] Is your Schema Registry configured under `kafka.schemaRegistry`? Move the configuration to the top level in v3. See <>. +* [ ] Are your role bindings in a separate file? Move role bindings to inline configuration in v3. See <>. + +=== Authentication decision + +You must decide on your v3 authentication strategy before migrating. + +==== User impersonation (recommended) + +Use this option when you want each user's Console session to use their own Redpanda credentials. + +Console role bindings are ignored. Authorization happens in Redpanda with ACLs. Users must be provisioned in Redpanda. + +==== Static credentials + +Use this option when you want Console to use a shared service account to access Redpanda. + +Console role bindings still apply. One set of credentials is used for all backend API calls. + +NOTE: For most deployments, user impersonation provides better security and auditability. + +=== Track your migration progress + +Use this checklist to track your migration: + +[%interactive] +* [ ] Reviewed <> +* [ ] Decided on <> (impersonation or static credentials) +* [ ] Tested configuration with <> +* [ ] Updated <> +* [ ] Migrated <> (if applicable) +* [ ] Configured <> (if using impersonation) +* [ ] Updated <> +* [ ] Updated <> +* [ ] Deployed updated configuration +* [ ] Validated <> +* [ ] Validated <> (topics, groups, Schema Registry) +* [ ] Reviewed and resolved all <> (Kubernetes deployments) + +== Automatic migration in Kubernetes + +When you deploy Redpanda Console v3 using the Redpanda Operator, the operator automatically attempts to migrate your v2 configuration from the Redpanda custom resource's `console` stanza to the new Console custom resource. The migration process handles as many configuration mappings as possible, but some features require manual intervention. + +IMPORTANT: The automatic migration only applies when transitioning from the Redpanda CRD's `console` stanza to the Console CRD. If you directly configure the Console CRD yourself, no automatic migration or normalization is performed. + +=== Migration workflow + +When you upgrade to Console v3 with the Redpanda Operator: + +. The operator attempts automatic migration using the mappings described in <> +. Warnings are generated for unsupported configurations and added to the Console custom resource +. You review the warnings and manually configure unsupported features +. You validate that authentication and authorization work as expected + +=== Check for migration warnings + +Before reviewing the migration details, check if your Console custom resource has warnings: + +[,bash] +---- +kubectl get console -n -o jsonpath='{.spec.warnings}' +---- + +If you see warnings, they indicate configurations that need your attention. Common warnings and their solutions are documented in <>. + +If you don't see warnings, review the <> to verify the automatic migration matches your expectations, especially around authentication strategy (impersonation vs static credentials). + +=== Supported configuration mappings + +The operator automatically migrates the following configuration fields: + +.Authentication settings +[cols="2,2,3"] +|=== +|v2 Configuration |v3 Configuration |Notes + +|`login.jwtSecret` +|`authentication.jwtSigningKey` +|Direct mapping + +|`login.useSecureCookies` +|`authentication.useSecureCookies` +|Direct mapping + +|`login.plain` +|`authentication.basic` +|Direct mapping + +|`login.[provider]` +|`authentication.oidc` +|Only one provider is selected if multiple are configured. See <>. +|=== + +.Schema Registry settings +[cols="2,2,3"] +|=== +|v2 Configuration |v3 Configuration |Notes + +|`kafka.schemaRegistry.username` +|`schemaRegistry.authentication.basic.username` +|Moved to top-level `schemaRegistry` stanza + +|`kafka.schemaRegistry.password` +|`schemaRegistry.authentication.basic.password` +|Moved to top-level `schemaRegistry` stanza + +|`kafka.schemaRegistry.bearerToken` +|`schemaRegistry.authentication.bearerToken` +|Moved to top-level `schemaRegistry` stanza + +|`kafka.schemaRegistry.*` +|`schemaRegistry.*` +|`impersonateUser` automatically set to `true` when credentials are absent + +|`kafka.schemaRegistry.*` (other settings) +|`schemaRegistry.*` +|All remaining Schema Registry configuration migrated to top level +|=== + +.Kafka and serialization settings +[cols="2,2,3"] +|=== +|v2 Configuration |v3 Configuration |Notes + +|`kafka.protobuf` +|`serde.protobuf` +|Moved to dedicated `serde` stanza + +|`kafka.cbor` +|`serde.cbor` +|Moved to dedicated `serde` stanza + +|`kafka.messagePack` +|`serde.messagePack` +|Moved to dedicated `serde` stanza + +|`console.maxDeserializationPayloadSize` +|`serde.maxDeserializationPayloadSize` +|Moved to `serde` stanza + +|N/A +|`kafka.sasl.enabled` and `kafka.sasl.impersonateUser` +|Both set to `true` by default in v3 +|=== + +.Other mappings +[cols="2,2,3"] +|=== +|v2 Configuration |v3 Configuration |Notes + +|`connect` +|`kafkaConnect` +|Renamed + +|`redpanda.adminApi` credentials +|`redpanda.adminApi.authentication.basic.*` +|Converted to structured authentication + +|Role bindings (user subjects) +|`authorization.roleBindings` +|Only user subjects are migrated. Group subjects are removed with warnings. +|=== + +=== Unsupported features + +The following v2 features are not supported in v3 and cannot be automatically migrated. The operator generates warnings when it encounters these configurations. + +==== Multiple OIDC providers + +[cols="1,2,2",options="header"] +|=== +|What changed |Impact |Action required + +|V2 allowed multiple OIDC providers (Google, GitHub, Keycloak, Okta, generic OIDC). V3 supports only one. +|Operator selects one provider; others are discarded +|Review selected provider in warnings. If you need additional authentication methods, configure them separately. +|=== + +.Example warning +[.no-copy] +---- +Elected 'github' as OIDC provider out of [github, google, keycloak, oidc]. Only one provider is supported in v3. +---- + +==== OIDC groups and realms + +Breaking change with significant migration effort required. + +[cols="1,2,2",options="header"] +|=== +|What changed |Impact |Action required + +|OIDC-based group authorization removed. `realm` and `directory` fields removed from OIDC provider configurations. +|Group-based access control no longer works +|Map OIDC groups to Redpanda RBAC roles. Provision users in Redpanda with appropriate ACLs. See <>. +|=== + +.Example warnings +[.no-copy] +---- +Removed 'realm' from 'oidc'. OIDC groups are not supported in v3. Create Roles in Redpanda instead. + +Removed 'directory' from 'oidc'. OIDC groups are not supported in v3. Create Roles in Redpanda instead. +---- + +==== Group-based role bindings + +[cols="1,2,2",options="header"] +|=== +|What changed |Impact |Action required + +|V2 role bindings could include group subjects. V3 only supports user subjects. +|Group subjects are removed from role bindings during migration +|If using impersonation: Provision individual users with ACLs in Redpanda. If using static credentials: Create individual user role bindings. +|=== + +.Example warning +[.no-copy] +---- +Removed group subject from role binding 'viewer'. Groups are not supported in v3. +---- + +=== Manual configuration steps + +After the operator completes automatic migration, review any warnings and complete the manual configuration steps: + +. Check for warnings: ++ +[,bash] +---- +kubectl get console -n -o jsonpath='{.spec.warnings}' +---- + +. Review each warning against the <> section above + +. Complete the required actions for each unsupported feature + +. Update your Console custom resource with any manual configuration changes + +. Validate the migration using the steps in <> + +For details on the `warnings` field structure, see xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[ConsoleSpec]. + == Authentication and authorization migration In v2, authentication and authorization was handled by the Redpanda Console. In v3, Redpanda Console uses the same authentication and authorization system as Redpanda. This change unifies the authentication and authorization model across Redpanda and Redpanda Console, enabling a more consistent and secure experience. @@ -147,7 +409,7 @@ login: ---- .V3 Google OIDC -[source,yaml,role="no-wrap"] +[,yaml,role="no-wrap"] ---- kafka: sasl: @@ -169,18 +431,29 @@ authentication: <2> Redpanda requires a JWT-encoded access token for authentication. While most identity providers issue JWTs, some (like Google) follow the OAuth spec and issue opaque tokens instead. Since Redpanda relies on JWTs to introspect the audience and subject, providers that do not support JWT access tokens cannot be used for authentication. -=== Role bindings +=== Role bindings migration -In Redpanda Console v2, role bindings could be configured in a separate file. In v3, role bindings are configured directly in the `authorization.roleBindings` stanza of the main configuration file. +In v3, role bindings continue to control access to Redpanda Console when using static credentials. However, with user impersonation enabled, role bindings are ignored, and authorization is handled directly by Redpanda using ACLs. -If you do **not** use impersonation, you can continue to use role bindings to control access within Redpanda Console. Each role binding maps users to roles in Redpanda Console using their login type and identity. +[cols="1,2",options="header"] +|=== +|Authentication strategy |Role bindings behavior + +|User impersonation +|Role bindings are ignored. Authorization is handled by Redpanda ACLs. + +|Static credentials +|Role bindings apply to control Console access. +|=== + +==== Configuration location change -Here is an example of how to migrate role bindings from a separate file to the main configuration: +In v2, role bindings could be configured in a separate file. In v3, role bindings are configured directly in the `authorization.roleBindings` stanza of the main configuration file. [.side-by-side] -- .V2 role bindings -[source,yaml,role="no-wrap"] +[,yaml,role="no-wrap"] ---- enterprise: rbac: @@ -199,7 +472,7 @@ roleBindings: ---- .V3 role bindings -[source,yaml,role="no-wrap"] +[,yaml,role="no-wrap"] ---- authorization: roleBindings: @@ -210,6 +483,15 @@ authorization: ---- -- +==== Group subject removal + +Breaking change: V2 role bindings could reference group subjects (from OIDC providers). V3 only supports user subjects. + +If you use OIDC groups for authorization, you must <>. + +During automatic migration in Kubernetes, group subjects are removed and warnings are generated. See <>. + +[[migrate-acls]] ==== Migrate Redpanda Console roles to Redpanda ACLs If you are using *impersonation* in v3, `roleBindings` are ignored. Instead, access is controlled by Redpanda using ACLs and RBAC. @@ -261,9 +543,13 @@ For details, see: - xref:manage:security/authorization/acl.adoc[] - xref:console:config/security/authorization.adoc[] -== Schema Registry migration +== Configuration structure changes + +V3 reorganizes several configuration sections to create a clearer structure. This section covers the changes to Schema Registry, serialization settings, and Kafka Connect. -In v2, the Schema Registry configuration was nested under the `kafka` stanza. In v3, this configuration is now a top-level stanza. +=== Schema Registry moves to top level + +In v2, the Schema Registry configuration was nested under the `kafka` stanza. In v3, this configuration is now a top-level stanza with structured authentication. [.side-by-side] -- @@ -292,7 +578,7 @@ kafka: ---- .V3 Schema Registry -[source,yaml,role="no-wrap"] +[,yaml,role="no-wrap"] ---- schemaRegistry: enabled: true @@ -313,9 +599,13 @@ schemaRegistry: ---- -- -== Serde and Kafka Connect migration +=== Serialization consolidated under serde + +In v3, all serialization settings are consolidated under the `serde` stanza. The `console.maxDeserializationPayloadSize` setting moves to the `serde` configuration. -In v3, all serialization settings are consolidated under the `serde` stanza. The connect configuration has been renamed to `kafkaConnect`, and the `console.maxDeserializationPayloadSize` setting is now part of the `serde` configuration. +=== Kafka Connect renamed to kafkaConnect + +The `connect` configuration stanza is renamed to `kafkaConnect` for clarity. [.side-by-side] -- @@ -338,7 +628,7 @@ connect: ---- .V3 serde and Kafka Connect -[source,yaml,role="no-wrap"] +[,yaml,role="no-wrap"] ---- serde: maxDeserializationPayloadSize: 20480 @@ -362,6 +652,122 @@ After updating your configuration, verify that: - Users can log in using the new authentication settings. - API calls to Kafka, Schema Registry, and the Admin API are authenticated correctly. +=== Check migration warnings in Kubernetes + +If you're deploying Redpanda Console using the Redpanda Operator, the Console custom resource includes a `warnings` field that reports any v2 configuration settings that could not be automatically migrated to v3. + +To check for migration warnings: + +[,bash] +---- +kubectl get console -n -o jsonpath='{.spec.warnings}' +---- + +If warnings are present, they describe which fields from your v2 configuration require manual intervention. Review these warnings and update your Console configuration accordingly. For a comprehensive list of automatically migrated configurations and unsupported features that generate warnings, see <>. For details on the `warnings` field, see xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[ConsoleSpec]. + +== Troubleshooting + +=== Users cannot log in after migration + +If users are unable to log in after migration, review the following common causes and solutions. + +==== Users not provisioned in Redpanda + +When using impersonation, users must exist in Redpanda as SASL/SCRAM users. + +To create a user in Redpanda, use the following command: + +[,bash] +---- +rpk security user create alice -p +---- + +For more information, see xref:manage:security/authentication.adoc[]. + +==== OIDC provider mismatch + +If you had multiple OIDC providers in v2, only one was selected during migration. + +Check which provider was selected: + +[,bash] +---- +kubectl get console -o jsonpath='{.spec.warnings}' +---- + +Review the warning message and ensure your users are authenticating with the selected provider. + +==== JWT token requirement not met + +Some identity providers (like Google) issue opaque tokens instead of JWT tokens. Redpanda requires JWT-encoded access tokens. + +To resolve this, use an identity provider that issues JWT access tokens, or configure your provider to issue JWTs. See <> for details. + +=== Users can log in but cannot access resources + +If users can log in but cannot access topics, consumer groups, or Schema Registry, review the following common causes and solutions. + +==== Missing ACLs with user impersonation + +When using user impersonation, user credentials are forwarded to Redpanda. Users must have appropriate ACLs configured in Redpanda. + +To check and create ACLs: + +[,bash] +---- +# Check existing ACLs for user +rpk security acl list --principal User:alice + +# Grant read access to topics +rpk security acl create \ + --allow-principal User:alice \ + --operation read,describe \ + --topic '*' + +# Grant access to consumer groups +rpk security acl create \ + --allow-principal User:alice \ + --operation read,describe \ + --group '*' +---- + +For more information on mapping Console roles to Redpanda ACLs, see <>. + +==== Role bindings not migrated correctly + +When using static credentials, verify that role bindings are correctly configured in the `authorization.roleBindings` stanza. + +To resolve this, review your v3 configuration and ensure role bindings match your v2 configuration. See <>. + +=== Schema Registry or Kafka Connect not working + +If Schema Registry or Kafka Connect API calls fail after migration, review the following common causes and solutions. + +==== Configuration location changed + +Schema Registry and Kafka Connect configuration moved to different locations in v3. + +To resolve this, verify that: + +* Schema Registry configuration is at the top level under `schemaRegistry`, not under `kafka.schemaRegistry` +* Kafka Connect configuration is under `kafkaConnect`, not `connect` +* Authentication is configured under `schemaRegistry.authentication` with the new structure + +See <> for examples. + +==== Impersonation settings incorrect + +If impersonation is enabled but not configured correctly, API calls may fail. + +To resolve this, ensure `impersonateUser` settings match your authentication strategy: + +* For user impersonation: Set `schemaRegistry.authentication.impersonateUser: true` +* For static credentials: Set `impersonateUser: false` and configure static credentials + +=== Migration warnings persist after manual fixes (Kubernetes) + +Warnings in the Console CR are informational and indicate what was changed during migration. They do not automatically clear after you resolve the issues. You can safely ignore warnings once you've addressed the underlying configuration problems and validated that Console works correctly. + [[migrator]] == Redpanda Console migration tool diff --git a/modules/migrate/pages/kubernetes/helm-to-operator.adoc b/modules/migrate/pages/kubernetes/helm-to-operator.adoc index 5b59da8b85..f12188186f 100644 --- a/modules/migrate/pages/kubernetes/helm-to-operator.adoc +++ b/modules/migrate/pages/kubernetes/helm-to-operator.adoc @@ -16,14 +16,13 @@ kind: Redpanda metadata: name: spec: - chartRef: - chartVersion: clusterSpec: + image: + tag: ``` - `metadata.name`: Name to assign the Redpanda cluster. This name is also assigned to the Helm release. -- xref:reference:k-crd.adoc#chartref[`spec.chartRef`]: Information about the Helm chart that will be used to deploy Redpanda. -- xref:reference:k-crd.adoc#chartversion[`spec.chartRef.chartversion`]: The version of the Helm chart values that the Redpanda CRD is compatible with. +- `spec.clusterSpec.image.tag`: The version of Redpanda to deploy (for example, `v25.2.1`). Starting from operator v25.1.1, the operator bundles Helm charts internally and automatically selects the appropriate chart version. - xref:reference:k-crd.adoc#redpandaclusterspec[`spec.clusterSpec`]: This is where you can configure the Redpanda CRD with your values overrides from the Redpanda Helm chart. == Supported migration paths @@ -88,7 +87,7 @@ You should see `yes` in the output. + You need these cluster-level permissions to install the Redpanda Operator CRDs in the next steps. -. Install the Redpanda Operator *in the same namespace as your Redpanda Helm chart*: +. Install the Redpanda Operator. Starting in v25.2, the Redpanda Operator can manage Redpanda clusters in any namespace: + include::deploy:partial$kubernetes/deploy-operator.adoc[] @@ -118,27 +117,27 @@ metadata: creationTimestamp: null name: <1> spec: - chartRef: - chartVersion: <2> clusterSpec: + image: + tag: <2> <3> ---- + -- <1> Replace with your Helm release name. -<2> Replace with your chart version. +<2> Specify the Redpanda version to deploy (for example, `v25.2.1`). The operator automatically uses the appropriate Helm chart version for the specified Redpanda version. + [NOTE] ==== -- Choose a `chartVersion` that the current Operator's CRDs support. For example, 5.9.x or 5.10.x if you're using Operator v2.4.x. See xref:upgrade:k-compatibility.adoc[]. -- If your existing Helm deployment is on version 5.8.x or below, you must first upgrade the chart using Helm before creating the Redpanda resource. +- Starting from operator v25.1.1, the `chartRef` fields (including `chartRef.chartVersion`) are deprecated. The operator bundles Helm charts internally. +- If your existing Helm deployment is on an older version, verify compatibility in xref:upgrade:k-compatibility.adoc[] before migrating. ==== <3> Replace with your chart overrides. + -TIP: The Redpanda CRD is compatible with the version of the Helm chart defined in the operator. For details on the structure and configuration options of the Redpanda custom resource, refer to the xref:reference:k-crd.adoc#redpandaclusterspec[Redpanda Operator CRD reference]. +TIP: For details on the structure and configuration options of the Redpanda custom resource, refer to the xref:reference:k-crd.adoc#redpandaclusterspec[Redpanda Operator CRD reference]. -- -. Adopt the Redpanda cluster by creating an instance of the Redpanda custom resource in the same namespace as the Redpanda Operator: +. Adopt the Redpanda cluster by creating an instance of the Redpanda custom resource: + ```bash kubectl apply -f redpanda-cluster.yaml --namespace diff --git a/modules/reference/pages/k-crd.adoc b/modules/reference/pages/k-crd.adoc index 73cfd173cc..ca0197100b 100644 --- a/modules/reference/pages/k-crd.adoc +++ b/modules/reference/pages/k-crd.adoc @@ -4,27 +4,61 @@ :description: Custom resource definitions for Redpanda resources. Use the Redpanda resources to create and manage Redpanda clusters, users and topics with the Redpanda Operator. :page-aliases: reference:k-topic-crd.adoc - -Package v1alpha2 defines the v1alpha2 schema for the Redpanda API. It is part of an evolving API architecture, representing an initial stage that may be subject to change based on user feedback and further development. - .Resource Types +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-console[$$Console$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpanda[$$Redpanda$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandarole[$$RedpandaRole$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schema[$$Schema$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topic[$$Topic$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[$$User$$] +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclaccessfilter"] +== ACLAccessFilter + +Filter an ACL based on its access type, operation, principal, and host. + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclfilter[$$ACLFilter$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`host`* __string__ | The host to match. If not set, will default to match all hosts + +with the specified `operation` and `permissionType`. Note that + +the asterisk `*` is literal and matches hosts that are set to `*` + +| *`operation`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-acloperation[$$ACLOperation$$]__ | The ACL operation to match + +| *`permissionType`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-acltype[$$ACLType$$]__ | The permission type + +| *`principal`* __string__ | The name of the principal, if not set will default to match + +all principals with the specified `operation` and `permissionType` + +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-acloperation"] == ACLOperation (string) ACLOperation specifies the type of operation for an ACL. +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclaccessfilter[$$ACLAccessFilter$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclrule[$$ACLRule$$] + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcefilter"] +== ACLResourceFilter .Appears in: -- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclrule[$$ACLRule$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclfilter[$$ACLFilter$$] +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`name`* __string__ | +| *`patternType`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-patterntype[$$PatternType$$]__ | +| *`resourceType`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-resourcetype[$$ResourceType$$]__ | +|=== [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcespec"] @@ -68,6 +102,7 @@ Validations taken from https://cwiki.apache.org/confluence/pages/viewpage.action .Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-roleauthorizationspec[$$RoleAuthorizationSpec$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userauthorizationspec[$$UserAuthorizationSpec$$] [cols="25a,75a", options="header"] @@ -101,6 +136,7 @@ ACLType specifies the type, either allow or deny of an ACL rule. .Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclaccessfilter[$$ACLAccessFilter$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclrule[$$ACLRule$$] @@ -118,10 +154,19 @@ Admin configures settings for the Admin API listeners. [cols="25a,75a", options="header"] |=== | Field | Description -| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listener. + -| *`port`* __integer__ | Specifies the container port number for the internal listener. + -| *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + +| *`enabled`* __boolean__ | Specifies whether this Listener is enabled. + +| *`authenticationMethod`* __string__ | Specifies the authentication method for this listener. For example, 'mtls_identity', `sasl` or `http_basic`. + | *`appProtocol`* __string__ | +| *`port`* __integer__ | Specifies the container port number for this listener. + +| *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + +| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of + +Services. This field accepts a string template that dynamically + +constructs Service addresses based on various parameters such as Service + +name and port number. + +For historical backwards compatibility, this field is present on both + +internal and external listeners. However, it is ignored when specified + +on internal listeners. + +| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listeners. + |=== @@ -210,6 +255,24 @@ Auth configures authentication in the Helm values. See https://docs.redpanda.com |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-authenticationsecrets"] +== AuthenticationSecrets + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`jwtSigningKey`* __string__ | +| *`oidc`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-oidcloginsecrets[$$OIDCLoginSecrets$$]__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-authorizationtype"] == AuthorizationType (string) @@ -224,6 +287,28 @@ AuthorizationType specifies the type of authorization to use in creating a user. +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-autoscaling"] +== AutoScaling + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`enabled`* __boolean__ | +| *`minReplicas`* __integer__ | +| *`maxReplicas`* __integer__ | +| *`targetCPUUtilizationPercentage`* __integer__ | +| *`targetMemoryUtilizationPercentage`* __integer__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-bootstrapuser"] == BootstrapUser @@ -370,6 +455,10 @@ ClusterRef represents a reference to a cluster that is being targeted. [cols="25a,75a", options="header"] |=== | Field | Description +| *`group`* __string__ | Group is used to override the object group that this reference points to. + +If unspecified, defaults to "cluster.redpanda.com". + +| *`kind`* __string__ | Kind is used to override the object kind that this reference points to. + +If unspecified, defaults to "Redpanda". + | *`name`* __string__ | Name specifies the name of the cluster being referenced. + |=== @@ -384,6 +473,8 @@ ClusterSource defines how to connect to a particular Redpanda cluster. .Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolespec[$$RoleSpec$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schemaspec[$$SchemaSpec$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-topicspec[$$TopicSpec$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-userspec[$$UserSpec$$] @@ -492,8 +583,11 @@ ConfigWatcher configures a sidecar that watches for changes to the Secret in `au | Field | Description | *`enabled`* __boolean__ | Specifies whether the sidecar is enabled. + | *`extraVolumeMounts`* __string__ | Specifies additional volumes to mount to the sidecar. + +DEPRECATED: Use sideCars.extraVolumeMounts + | *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | Specifies resource requests for the sidecar container. + +DEPRECATED: Use sideCars.resources + | *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | Specifies the container's security context, including privileges and access levels of the container and its processes. + +DEPRECATED: Use sideCars.securityContext + |=== @@ -595,6 +689,36 @@ never used. Prefer Create. + |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-console"] +== Console + +Redpanda defines the CRD for Redpanda clusters. + + + + + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`apiVersion`* __string__ | `cluster.redpanda.com/v1alpha2` +| *`kind`* __string__ | `Console` +| *`kind`* __string__ | Kind is a string value representing the REST resource this object represents. + +Servers may infer this from the endpoint the client submits requests to. + +Cannot be updated. + +In CamelCase. + +More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds + +| *`apiVersion`* __string__ | APIVersion defines the versioned schema of this representation of an object. + +Servers should convert recognized schemas to the latest internal value, and + +may reject unrecognized values. + +More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources + +| *`metadata`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectmeta-v1-meta[$$ObjectMeta$$]__ | Refer to the Kubernetes API documentation for fields of `metadata`. + +| *`spec`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$]__ | +| *`status`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolestatus[$$ConsoleStatus$$]__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolecreateobj"] == ConsoleCreateObj @@ -612,6 +736,140 @@ ConsoleCreateObj represents configuration options for creating Kubernetes object |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec"] +== ConsoleSpec + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-console[$$Console$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`replicaCount`* __integer__ | +| *`image`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-image[$$Image$$]__ | +| *`imagePullSecrets`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#localobjectreference-v1-core[$$LocalObjectReference$$] array__ | +| *`automountServiceAccountToken`* __boolean__ | +| *`serviceAccount`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceaccountconfig[$$ServiceAccountConfig$$]__ | +| *`commonLabels`* __object (keys:string, values:string)__ | +| *`annotations`* __object (keys:string, values:string)__ | +| *`podAnnotations`* __object (keys:string, values:string)__ | +| *`podLabels`* __object (keys:string, values:string)__ | +| *`podSecurityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#podsecuritycontext-v1-core[$$PodSecurityContext$$]__ | +| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | +| *`service`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceconfig[$$ServiceConfig$$]__ | +| *`ingress`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingressconfig[$$IngressConfig$$]__ | +| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | +| *`autoscaling`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-autoscaling[$$AutoScaling$$]__ | +| *`nodeSelector`* __object (keys:string, values:string)__ | +| *`tolerations`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#toleration-v1-core[$$Toleration$$] array__ | +| *`affinity`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#affinity-v1-core[$$Affinity$$]__ | +| *`topologySpreadConstraints`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#topologyspreadconstraint-v1-core[$$TopologySpreadConstraint$$] array__ | +| *`priorityClassName`* __string__ | +| *`config`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#rawextension-runtime-pkg[$$RawExtension$$]__ | +| *`extraEnv`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#envvar-v1-core[$$EnvVar$$] array__ | +| *`extraEnvFrom`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#envfromsource-v1-core[$$EnvFromSource$$] array__ | +| *`extraVolumes`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#volume-v1-core[$$Volume$$] array__ | +| *`extraVolumeMounts`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#volumemount-v1-core[$$VolumeMount$$] array__ | +| *`extraContainers`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#container-v1-core[$$Container$$] array__ | +| *`extraContainerPorts`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#containerport-v1-core[$$ContainerPort$$] array__ | +| *`secretMounts`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretmount[$$SecretMount$$] array__ | +| *`secret`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$]__ | +| *`licenseSecretRef`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#secretkeyselector-v1-core[$$SecretKeySelector$$]__ | +| *`livenessProbe`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#probe-v1-core[$$Probe$$]__ | +| *`readinessProbe`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#probe-v1-core[$$Probe$$]__ | +| *`deployment`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-deploymentconfig[$$DeploymentConfig$$]__ | +| *`strategy`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#deploymentstrategy-v1-apps[$$DeploymentStrategy$$]__ | +| *`cluster`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-clustersource[$$ClusterSource$$]__ | +| *`warnings`* __string array__ | Human-readable warnings generated by the automatic migration of a Redpanda Console v2 configuration to v3. + + + +If warnings are present, they describe which fields from the original v2 configuration could not be automatically migrated and require manual intervention. These warnings help identify configuration elements that need your attention during the upgrade process. + + + +This is a read-only field. Setting this field has no effect. + +For information about migrating from Console v2 to v3, see xref:migrate:console-v3.adoc[]. + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolestatus"] +== ConsoleStatus + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-console[$$Console$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`observedGeneration`* __integer__ | The generation observed by the Console controller. + +| *`replicas`* __integer__ | Total number of non-terminating Pods targeted by this Console's Deployment. + +| *`updatedReplicas`* __integer__ | Total number of non-terminating pods targeted by this Console's Deployment that have the desired template spec. + +| *`readyReplicas`* __integer__ | Total number of non-terminating pods targeted by this Console's Deployment with a Ready Condition. + +| *`availableReplicas`* __integer__ | Total number of available non-terminating pods (ready for at least minReadySeconds) targeted by this Console's Deployment. + +| *`unavailableReplicas`* __integer__ | Total number of unavailable pods targeted by this deployment. This is the total number of + +pods that are still required for the deployment to have 100% available capacity. They may + +either be pods that are running but not yet available or pods that still have not been created. + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues"] +== ConsoleValues + +ConsoleValues is a CRD friendly equivalent of [console.PartialValues]. Any +member that is optional at the top level, either by being a pointer, map, or +slice, is NOT further partial-ized. This allows us to enforce validation +constraints without accidentally polluting the defaults of the chart. + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`replicaCount`* __integer__ | +| *`image`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-image[$$Image$$]__ | +| *`imagePullSecrets`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#localobjectreference-v1-core[$$LocalObjectReference$$] array__ | +| *`automountServiceAccountToken`* __boolean__ | +| *`serviceAccount`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceaccountconfig[$$ServiceAccountConfig$$]__ | +| *`commonLabels`* __object (keys:string, values:string)__ | +| *`annotations`* __object (keys:string, values:string)__ | +| *`podAnnotations`* __object (keys:string, values:string)__ | +| *`podLabels`* __object (keys:string, values:string)__ | +| *`podSecurityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#podsecuritycontext-v1-core[$$PodSecurityContext$$]__ | +| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | +| *`service`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceconfig[$$ServiceConfig$$]__ | +| *`ingress`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingressconfig[$$IngressConfig$$]__ | +| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | +| *`autoscaling`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-autoscaling[$$AutoScaling$$]__ | +| *`nodeSelector`* __object (keys:string, values:string)__ | +| *`tolerations`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#toleration-v1-core[$$Toleration$$] array__ | +| *`affinity`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#affinity-v1-core[$$Affinity$$]__ | +| *`topologySpreadConstraints`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#topologyspreadconstraint-v1-core[$$TopologySpreadConstraint$$] array__ | +| *`priorityClassName`* __string__ | +| *`config`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#rawextension-runtime-pkg[$$RawExtension$$]__ | +| *`extraEnv`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#envvar-v1-core[$$EnvVar$$] array__ | +| *`extraEnvFrom`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#envfromsource-v1-core[$$EnvFromSource$$] array__ | +| *`extraVolumes`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#volume-v1-core[$$Volume$$] array__ | +| *`extraVolumeMounts`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#volumemount-v1-core[$$VolumeMount$$] array__ | +| *`extraContainers`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#container-v1-core[$$Container$$] array__ | +| *`extraContainerPorts`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#containerport-v1-core[$$ContainerPort$$] array__ | +| *`secretMounts`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretmount[$$SecretMount$$] array__ | +| *`secret`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$]__ | +| *`licenseSecretRef`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#secretkeyselector-v1-core[$$SecretKeySelector$$]__ | +| *`livenessProbe`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#probe-v1-core[$$Probe$$]__ | +| *`readinessProbe`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#probe-v1-core[$$Probe$$]__ | +| *`deployment`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-deploymentconfig[$$DeploymentConfig$$]__ | +| *`strategy`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#deploymentstrategy-v1-apps[$$DeploymentStrategy$$]__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-containerresources"] == ContainerResources @@ -648,6 +906,25 @@ CredentialSecretRef can be used to set cloud_storage_secret_key from referenced |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-deploymentconfig"] +== DeploymentConfig + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`command`* __string array__ | +| *`extraArgs`* __string array__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-enablable"] == Enablable @@ -760,12 +1037,19 @@ ExternalListener configures settings for the external listeners. [cols="25a,75a", options="header"] |=== | Field | Description -| *`enabled`* __boolean__ | -| *`authenticationMethod`* __string__ | Specifies the authentication method for the external listener. For example, 'mtls_identity' or `sasl`. + -| *`port`* __integer__ | Specifies the container port number for the external listener. + -| *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the external listener. + +| *`enabled`* __boolean__ | Specifies whether this Listener is enabled. + +| *`authenticationMethod`* __string__ | Specifies the authentication method for this listener. For example, 'mtls_identity', `sasl` or `http_basic`. + +| *`appProtocol`* __string__ | +| *`port`* __integer__ | Specifies the container port number for this listener. + +| *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + +| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of + +Services. This field accepts a string template that dynamically + +constructs Service addresses based on various parameters such as Service + +name and port number. + +For historical backwards compatibility, this field is present on both + +internal and external listeners. However, it is ignored when specified + +on internal listeners. + | *`advertisedPorts`* __integer array__ | Specifies the network port that the external Service listens on. + -| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of Services. This field accepts a string template that dynamically constructs Service addresses based on various parameters such as Service name and port number. + | *`nodePort`* __integer__ | |=== @@ -787,6 +1071,18 @@ ExternalService allows you to enable or disable the creation of an external Serv |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-filtertype"] +== FilterType (string) + +FilterType specifies the type, either include or exclude of a consumer group filter. + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-namefilter[$$NameFilter$$] + + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-fsvalidator"] == FsValidator @@ -820,13 +1116,100 @@ HTTP configures settings for the HTTP Proxy listeners. [cols="25a,75a", options="header"] |=== | Field | Description -| *`authenticationMethod`* __string__ | Specifies the authentication method for the external listener. For example, 'mtls_identity' or `sasl`. + -| *`enabled`* __boolean__ | Specifies whether the HTTP Proxy is enabled. + -| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listener. + -| *`kafkaEndpoint`* __string__ | Configures the listener to use for HTTP connections. For example `default` for the internal listener. + -| *`port`* __integer__ | Specifies the container port number for the internal listener. + +| *`enabled`* __boolean__ | Specifies whether this Listener is enabled. + +| *`authenticationMethod`* __string__ | Specifies the authentication method for this listener. For example, 'mtls_identity', `sasl` or `http_basic`. + +| *`appProtocol`* __string__ | +| *`port`* __integer__ | Specifies the container port number for this listener. + | *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + -| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of Services. This field accepts a string template that dynamically constructs Service addresses based on various parameters such as Service name and port number. + +| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of + +Services. This field accepts a string template that dynamically + +constructs Service addresses based on various parameters such as Service + +name and port number. + +For historical backwards compatibility, this field is present on both + +internal and external listeners. However, it is ignored when specified + +on internal listeners. + +| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listeners. + +| *`kafkaEndpoint`* __string__ | Configures the listener to use for HTTP connections. For example `default` for the internal listener. + +deprecated and not respected. + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-image"] +== Image + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`registry`* __string__ | +| *`repository`* __string__ | +| *`pullPolicy`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#pullpolicy-v1-core[$$PullPolicy$$]__ | +| *`tag`* __string__ | +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingressconfig"] +== IngressConfig + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`enabled`* __boolean__ | +| *`className`* __string__ | +| *`annotations`* __object (keys:string, values:string)__ | +| *`hosts`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingresshost[$$IngressHost$$] array__ | +| *`tls`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#ingresstls-v1-networking[$$IngressTLS$$] array__ | +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingresshost"] +== IngressHost + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingressconfig[$$IngressConfig$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`host`* __string__ | +| *`paths`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingresspath[$$IngressPath$$] array__ | +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingresspath"] +== IngressPath + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-ingresshost[$$IngressHost$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`path`* __string__ | +| *`pathType`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#pathtype-v1-networking[$$PathType$$]__ | |=== @@ -902,11 +1285,19 @@ Kafka configures settings for the Kafka API listeners. [cols="25a,75a", options="header"] |=== | Field | Description -| *`authenticationMethod`* __string__ | Specifies the authentication method for the external listener. For example, 'mtls_identity' or `sasl`. + -| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listener. + -| *`port`* __integer__ | Specifies the container port number for the internal listener. + +| *`enabled`* __boolean__ | Specifies whether this Listener is enabled. + +| *`authenticationMethod`* __string__ | Specifies the authentication method for this listener. For example, 'mtls_identity', `sasl` or `http_basic`. + +| *`appProtocol`* __string__ | +| *`port`* __integer__ | Specifies the container port number for this listener. + | *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + -| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of Services. This field accepts a string template that dynamically constructs Service addresses based on various parameters such as Service name and port number. + +| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of + +Services. This field accepts a string template that dynamically + +constructs Service addresses based on various parameters such as Service + +name and port number. + +For historical backwards compatibility, this field is present on both + +internal and external listeners. However, it is ignored when specified + +on internal listeners. + +| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listeners. + |=== @@ -1027,6 +1418,28 @@ KafkaSASLOAuthBearer is the config struct for the SASL OAuthBearer mechanism |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-kafkasecrets"] +== KafkaSecrets + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`saslPassword`* __string__ | +| *`awsMskIamSecretKey`* __string__ | +| *`tlsCa`* __string__ | +| *`tlsCert`* __string__ | +| *`tlsKey`* __string__ | +| *`tlsPassphrase`* __string__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-licensesecretref"] == LicenseSecretRef @@ -1045,6 +1458,38 @@ LicenseSecretRef is deprecated. Use `EnterpriseLicenseSecretRef` instead. |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listener"] +== Listener + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-admin[$$Admin$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-http[$$HTTP$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-kafka[$$Kafka$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schemaregistry[$$SchemaRegistry$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`enabled`* __boolean__ | Specifies whether this Listener is enabled. + +| *`authenticationMethod`* __string__ | Specifies the authentication method for this listener. For example, 'mtls_identity', `sasl` or `http_basic`. + +| *`appProtocol`* __string__ | +| *`port`* __integer__ | Specifies the container port number for this listener. + +| *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + +| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of + +Services. This field accepts a string template that dynamically + +constructs Service addresses based on various parameters such as Service + +name and port number. + +For historical backwards compatibility, this field is present on both + +internal and external listeners. However, it is ignored when specified + +on internal listeners. + +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls"] == ListenerTLS @@ -1057,6 +1502,7 @@ ListenerTLS configures TLS configuration for each listener in the Helm values. - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-http[$$HTTP$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-kafka[$$Kafka$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listener[$$Listener$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rpc[$$RPC$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schemaregistry[$$SchemaRegistry$$] @@ -1195,38 +1641,22 @@ Monitoring configures monitoring resources for Redpanda. See https://docs.redpan |=== -[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-nodepoolstatus"] -== NodePoolStatus -NodePoolStatus defines the observed state of any node pools tied to this cluster + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-oidcloginsecrets"] +== OIDCLoginSecrets + + .Appears in: -- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandastatus[$$RedpandaStatus$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-authenticationsecrets[$$AuthenticationSecrets$$] [cols="25a,75a", options="header"] |=== | Field | Description -| *`name`* __string__ | Name is the name of the pool + -| *`replicas`* __integer__ | Replicas is the number of actual replicas currently across + -the node pool. This differs from DesiredReplicas during + -a scaling operation, but should be the same once the cluster + -has quiesced. + -| *`desiredReplicas`* __integer__ | DesiredReplicas is the number of replicas that ought to be + -run for the cluster. It combines the desired replicas across + -all node pools. + -| *`outOfDateReplicas`* __integer__ | OutOfDateReplicas is the number of replicas that don't currently + -match their node pool definitions. If OutOfDateReplicas is not 0 + -it should mean that the operator will soon roll this many pods. + -| *`upToDateReplicas`* __integer__ | UpToDateReplicas is the number of replicas that currently match + -their node pool definitions. + -| *`condemnedReplicas`* __integer__ | CondemnedReplicas is the number of replicas that will be decommissioned + -as part of a scaling down operation. + -| *`readyReplicas`* __integer__ | ReadyReplicas is the number of replicas whose readiness probes are + -currently passing. + -| *`runningReplicas`* __integer__ | RunningReplicas is the number of replicas that are actively in a running + -state. + +| *`clientSecret`* __string__ | |=== @@ -1246,6 +1676,7 @@ Password specifies a password for the user. | *`value`* __string__ | Value is a hardcoded value to use for the given password. It should only be used for testing purposes. + In production, use ValueFrom. + | *`valueFrom`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-passwordsource[$$PasswordSource$$]__ | ValueFrom specifies a source for a password to be fetched from when specifying or generating user credentials. + +| *`noGenerate`* __boolean__ | NoGenerate when set to true does not create kubernetes secret when ValueFrom points to none-existent secret. + |=== @@ -1277,7 +1708,9 @@ PatternType specifies the type of pattern applied for ACL resource matching. .Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcefilter[$$ACLResourceFilter$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcespec[$$ACLResourceSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-namefilter[$$NameFilter$$] @@ -1358,6 +1791,60 @@ PodTemplate will pass label and annotation to Statefulset Pod template. |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-poolconfigurator"] +== PoolConfigurator + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-poolinitcontainers[$$PoolInitContainers$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`additionalCLIArgs`* __string array__ | Chart default: [] + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-poolfsvalidator"] +== PoolFSValidator + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-poolinitcontainers[$$PoolInitContainers$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`enabled`* __boolean__ | Chart default: false + +| *`expectedFS`* __string__ | Chart default: xfs + +|=== + + + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-poolsetdatadirownership"] +== PoolSetDataDirOwnership + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-poolinitcontainers[$$PoolInitContainers$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`enabled`* __boolean__ | Chart default: false + +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-postinstalljob"] == PostInstallJob @@ -1464,8 +1951,10 @@ RPControllers configures additional controllers that can be deployed as sidecars |=== | Field | Description | *`enabled`* __boolean__ | Specifies whether the Controllers are enabled. + -| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | -| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | +| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | Specifies resource requests for the sidecar container. + +DEPRECATED: Use sideCars.resources + +| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | Specifies the container's security context, including privileges and access levels of the container and its processes. + +DEPRECATED: Use sideCars.securityContext + | *`image`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaimage[$$RedpandaImage$$]__ | | *`healthProbeAddress`* __string__ | | *`metricsAddress`* __string__ | @@ -1545,6 +2034,26 @@ More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api- |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaadminapisecrets"] +== RedpandaAdminAPISecrets + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandasecrets[$$RedpandaSecrets$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`password`* __string__ | +| *`tlsCa`* __string__ | +| *`tlsCert`* __string__ | +| *`tlsKey`* __string__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaclusterspec"] == RedpandaClusterSpec @@ -1574,6 +2083,7 @@ For descriptions and default values, see xref:k-redpanda-helm-spec.adoc[]. | *`enterprise`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-enterprise[$$Enterprise$$]__ | Defines an Enterprise license. + | *`rackAwareness`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rackawareness[$$RackAwareness$$]__ | Defines rack awareness settings. + | *`console`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaconsole[$$RedpandaConsole$$]__ | Defines Redpanda Console settings. + +Deprecated: Use the dedicated Console CRD. + | *`connectors`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaconnectors[$$RedpandaConnectors$$]__ | Defines Redpanda Connector settings. + Deprecated, ignored, and unused as of v25.1.1 + | *`auth`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-auth[$$Auth$$]__ | Defines authentication settings for listeners. + @@ -1775,6 +2285,53 @@ Defined by the `--reserve-memory` parameter. Represents the memory available for |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandarole"] +== RedpandaRole + +RedpandaRole defines the CRD for a Redpanda role. + + + + + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`apiVersion`* __string__ | `cluster.redpanda.com/v1alpha2` +| *`kind`* __string__ | `RedpandaRole` +| *`kind`* __string__ | Kind is a string value representing the REST resource this object represents. + +Servers may infer this from the endpoint the client submits requests to. + +Cannot be updated. + +In CamelCase. + +More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds + +| *`apiVersion`* __string__ | APIVersion defines the versioned schema of this representation of an object. + +Servers should convert recognized schemas to the latest internal value, and + +may reject unrecognized values. + +More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources + +| *`metadata`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectmeta-v1-meta[$$ObjectMeta$$]__ | Refer to the Kubernetes API documentation for fields of `metadata`. + +| *`spec`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolespec[$$RoleSpec$$]__ | Defines the desired state of the Redpanda role. + +| *`status`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolestatus[$$RoleStatus$$]__ | Represents the current status of the Redpanda role. + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandasecrets"] +== RedpandaSecrets + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`adminApi`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaadminapisecrets[$$RedpandaAdminAPISecrets$$]__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaspec"] == RedpandaSpec @@ -1809,8 +2366,6 @@ RedpandaStatus defines the observed state of Redpanda | *`conditions`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#condition-v1-meta[$$Condition$$] array__ | Conditions holds the conditions for the Redpanda. + | *`license`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandalicensestatus[$$RedpandaLicenseStatus$$]__ | LicenseStatus contains information about the current state of any + installed license in the Redpanda cluster. + -| *`nodePools`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-nodepoolstatus[$$NodePoolStatus$$] array__ | NodePools contains information about the node pools associated + -with this cluster. + | *`configVersion`* __string__ | ConfigVersion contains the configuration version written in + Redpanda used for restarting broker nodes as necessary. + | *`observedGeneration`* __integer__ | Specifies the last observed generation. + @@ -1838,6 +2393,8 @@ deprecated + |=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-resourcetemplate"] == ResourceTemplate @@ -1864,6 +2421,7 @@ ResourceType specifies the type of resource an ACL is applied to. .Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcefilter[$$ACLResourceFilter$$] - xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcespec[$$ACLResourceSpec$$] @@ -1911,6 +2469,67 @@ and `Requests`. |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-roleauthorizationspec"] +== RoleAuthorizationSpec + +RoleAuthorizationSpec defines authorization rules for this role. + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolespec[$$RoleSpec$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`acls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclrule[$$ACLRule$$] array__ | List of ACL rules which should be applied to this role. + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolespec"] +== RoleSpec + +RoleSpec defines the configuration of a Redpanda role. + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandarole[$$RedpandaRole$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`cluster`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-clustersource[$$ClusterSource$$]__ | ClusterSource is a reference to the cluster where the role should be created. + +It is used in constructing the client created to configure a cluster. + +| *`principals`* __string array__ | Principals defines the list of users assigned to this role. + +Format: Type:Name (e.g., User:john, User:jane). If type is omitted, defaults to User. + +| *`authorization`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-roleauthorizationspec[$$RoleAuthorizationSpec$$]__ | Authorization rules defined for this role. If specified, the operator will manage ACLs for this role. + +If omitted, ACLs should be managed separately using Redpanda's ACL management. + +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rolestatus"] +== RoleStatus + +RoleStatus defines the observed state of a Redpanda role + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandarole[$$RedpandaRole$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`observedGeneration`* __integer__ | Specifies the last observed generation. + +| *`conditions`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#condition-v1-meta[$$Condition$$] array__ | Conditions holds the conditions for the Redpanda role. + +| *`managedAcls`* __boolean__ | ManagedACLs returns whether the role has managed ACLs that need + +to be cleaned up. + +| *`managedRole`* __boolean__ | ManagedRole returns whether the role has been created in Redpanda and needs + +to be cleaned up. + +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-sasl"] == SASL @@ -2012,12 +2631,21 @@ SchemaRegistry configures settings for the Schema Registry listeners. [cols="25a,75a", options="header"] |=== | Field | Description -| *`authenticationMethod`* __string__ | Specifies the authentication method for the external listener. For example, 'mtls_identity' or `sasl`. + -| *`enabled`* __boolean__ | Specifies whether the Schema Registry is enabled. + -| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listener. + -| *`kafkaEndpoint`* __string__ | Configures the listener to use for HTTP connections. For example `default` for the internal listener. + -| *`port`* __integer__ | Specifies the container port number for the internal listener. + +| *`enabled`* __boolean__ | Specifies whether this Listener is enabled. + +| *`authenticationMethod`* __string__ | Specifies the authentication method for this listener. For example, 'mtls_identity', `sasl` or `http_basic`. + +| *`appProtocol`* __string__ | +| *`port`* __integer__ | Specifies the container port number for this listener. + | *`tls`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$]__ | Configures TLS settings for the internal listener. + +| *`prefixTemplate`* __string__ | Specifies the template used for generating the advertised addresses of + +Services. This field accepts a string template that dynamically + +constructs Service addresses based on various parameters such as Service + +name and port number. + +For historical backwards compatibility, this field is present on both + +internal and external listeners. However, it is ignored when specified + +on internal listeners. + +| *`external`* __object (keys:string, values:xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-externallistener[$$ExternalListener$$])__ | Defines settings for the external listeners. + +| *`kafkaEndpoint`* __string__ | Configures the listener to use for HTTP connections. For example `default` for the internal listener. + +deprecated and not respected. + |=== @@ -2041,6 +2669,27 @@ SchemaRegistrySASL configures credentials to connect to Redpanda cluster that ha |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schemaregistrysecrets"] +== SchemaRegistrySecrets + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`bearerToken`* __string__ | +| *`password`* __string__ | +| *`tlsCa`* __string__ | +| *`tlsCert`* __string__ | +| *`tlsKey`* __string__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schemaregistryspec"] == SchemaRegistrySpec @@ -2115,6 +2764,30 @@ SchemaType specifies the type of the given schema. +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig"] +== SecretConfig + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`create`* __boolean__ | +| *`kafka`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-kafkasecrets[$$KafkaSecrets$$]__ | +| *`authentication`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-authenticationsecrets[$$AuthenticationSecrets$$]__ | +| *`license`* __string__ | +| *`redpanda`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandasecrets[$$RedpandaSecrets$$]__ | +| *`serde`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serdesecrets[$$SerdeSecrets$$]__ | +| *`schemaRegistry`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-schemaregistrysecrets[$$SchemaRegistrySecrets$$]__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretkeyref"] == SecretKeyRef @@ -2141,6 +2814,28 @@ More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/nam |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretmount"] +== SecretMount + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`name`* __string__ | +| *`secretName`* __string__ | +| *`path`* __string__ | +| *`subPath`* __string__ | +| *`defaultMode`* __integer__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretref"] == SecretRef @@ -2177,6 +2872,23 @@ SecretRef configures the Secret resource that contains existing TLS certificates |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serdesecrets"] +== SerdeSecrets + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-secretconfig[$$SecretConfig$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`protobufGitBasicAuthPassword`* __string__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-service"] == Service @@ -2215,6 +2927,48 @@ ServiceAccount configures Service Accounts. |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceaccountconfig"] +== ServiceAccountConfig + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`automountServiceAccountToken`* __boolean__ | +| *`annotations`* __object (keys:string, values:string)__ | +| *`name`* __string__ | +|=== + + +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceconfig"] +== ServiceConfig + + + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolespec[$$ConsoleSpec$$] +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-consolevalues[$$ConsoleValues$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`type`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#servicetype-v1-core[$$ServiceType$$]__ | +| *`port`* __integer__ | +| *`nodePort`* __integer__ | +| *`targetPort`* __integer__ | +| *`annotations`* __object (keys:string, values:string)__ | +|=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-serviceinternal"] == ServiceInternal @@ -2283,8 +3037,10 @@ SideCarObj represents a generic sidecar object. This is a placeholder for now. |=== | Field | Description | *`enabled`* __boolean__ | -| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | -| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | +| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | Specifies resource requests for the sidecar container. + +DEPRECATED: Use sideCars.resources + +| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | Specifies the container's security context, including privileges and access levels of the container and its processes. + +DEPRECATED: Use sideCars.securityContext + |=== @@ -2302,6 +3058,10 @@ SideCars configures the additional sidecar containers that run alongside the mai |=== | Field | Description | *`image`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-redpandaimage[$$RedpandaImage$$]__ | +| *`extraVolumeMounts`* __string__ | Specifies additional volumes to mount to the sidecar. + +| *`resources`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcerequirements-v1-core[$$ResourceRequirements$$]__ | Specifies resource requests for the sidecar container. + +| *`securityContext`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#securitycontext-v1-core[$$SecurityContext$$]__ | Specifies the container's security context, including privileges and access levels of the container and its processes. + +| *`args`* __string array__ | | *`configWatcher`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-configwatcher[$$ConfigWatcher$$]__ | Configures the `config-watcher` sidecar. The `config-watcher` sidecar polls the Secret resource in `auth.sasl.secretRef` for changes and triggers a rolling upgrade to add the new superusers to the Redpanda cluster. + | *`rpkStatus`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-sidecarobj[$$SideCarObj$$]__ | | *`controllers`* __xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rpcontrollers[$$RPControllers$$]__ | @@ -2431,6 +3191,8 @@ TLS configures TLS in the Helm values. See https://docs.redpanda.com/current/man |=== + + [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-tiered"] == Tiered @@ -2619,6 +3381,23 @@ TopologySpreadConstraints configures topology spread constraints to control how |=== +[id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-truststore"] +== TrustStore + +TrustStore is a mapping from a value on either a Secret or ConfigMap to the +`truststore_path` field of a listener. + + + +.Appears in: +- xref:{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-listenertls[$$ListenerTLS$$] + +[cols="25a,75a", options="header"] +|=== +| Field | Description +| *`configMapKeyRef`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#configmapkeyselector-v1-core[$$ConfigMapKeySelector$$]__ | +| *`secretKeyRef`* __link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#secretkeyselector-v1-core[$$SecretKeySelector$$]__ | +|=== [id="{anchor_prefix}-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-tuning"] diff --git a/modules/troubleshoot/partials/debug-bundle/generate-rpk.adoc b/modules/troubleshoot/partials/debug-bundle/generate-rpk.adoc index 246a6db53b..ad103dc9c8 100644 --- a/modules/troubleshoot/partials/debug-bundle/generate-rpk.adoc +++ b/modules/troubleshoot/partials/debug-bundle/generate-rpk.adoc @@ -48,7 +48,7 @@ spec: kubectl apply -f redpanda-cluster.yaml --namespace ``` -NOTE: You must deploy the Redpanda Operator with the `--set rbac.createRPKBundleCRs=true` flag to give it the required ClusterRoles. + -- Helm:: diff --git a/modules/troubleshoot/partials/errors-and-solutions.adoc b/modules/troubleshoot/partials/errors-and-solutions.adoc index a06ea4f0cf..cce84a11e6 100644 --- a/modules/troubleshoot/partials/errors-and-solutions.adoc +++ b/modules/troubleshoot/partials/errors-and-solutions.adoc @@ -245,18 +245,7 @@ helm repo update //end::deployment-name-exists[] -//tag::deployment-forbidden-debug-bundle[] -=== redpanda-rpk-debug-bundle is forbidden -If you see this error, your Redpanda Operator's RBAC settings are out of sync with the Pod-level RBAC in the Redpanda resource: - -[.no-copy] ----- -… forbidden: user "…-operator" … attempting to grant RBAC permissions not currently held … ----- - -To fix this error, make sure you haven't disabled xref:reference:k-operator-helm-spec.adoc#rbac-createrpkbundlecrs[`rbac.createRPKBundleCRs`] in the Redpanda Operator chart while still leaving xref:reference:k-crd.adoc#k8s-api-git.colasdn.top-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-rbac[`spec.clusterSpec.rbac.rpkDebugBundle`] enabled in your Redpanda resource. Either enable both or disable both. -//end::deployment-forbidden-debug-bundle[] //tag::deployment-data-dir-not-writable[] === Fatal error during checker "Data directory is writable" execution diff --git a/modules/upgrade/pages/k-compatibility.adoc b/modules/upgrade/pages/k-compatibility.adoc index b6e02b75ee..54d64bf6d9 100644 --- a/modules/upgrade/pages/k-compatibility.adoc +++ b/modules/upgrade/pages/k-compatibility.adoc @@ -13,7 +13,7 @@ The Redpanda Helm chart and Redpanda Operator are versioned and tested alongside Starting from version 25.1.1, the Redpanda Operator and Redpanda Helm chart follow a new versioning scheme aligned with Redpanda core releases: -- `v25.1` refers to the Redpanda core feature release deployed by default. +- `25.1` refers to the Redpanda core feature release deployed by default. - The patch version denotes the patch version for either the operator or Helm chart. It is not the patch version of Redpanda core. @@ -37,11 +37,17 @@ Redpanda Core has no direct dependency on Kubernetes. Compatibility is influence |=== |Redpanda Core / `rpk` |Helm Chart |Operator Helm Chart |Operator |Helm CLI |Kubernetes -.1+|25.2.x +.2+|25.2.x +|25.2.x +|25.2.x +|25.2.x +|3.12+ +d|1.30.x - 1.33.x{fn-k8s-compatibility} + +|25.1.x +|25.1.x |25.1.x -|25.2-beta1, 25.1.x -|25.2-beta1, 25.1.x |3.12+ d|1.28.x - 1.33.x{fn-k8s-compatibility} @@ -123,12 +129,12 @@ Upgrading the Helm chart may also upgrade Redpanda Console. Because of this buil |Redpanda Console |Helm Chart |Operator |v3.x.x -|25.1.x +|25.2.x, 25.1.x |Not yet supported |v2.x.x |5.10.1, 5.9.x, 5.8.x -|25.1.x, 2.4.x, 2.3.x, 2.2.x +|25.2.x, 25.1.x, 2.4.x, 2.3.x, 2.2.x |=== diff --git a/modules/upgrade/pages/k-rolling-upgrade.adoc b/modules/upgrade/pages/k-rolling-upgrade.adoc index 9a04ce8540..6d5bc56821 100644 --- a/modules/upgrade/pages/k-rolling-upgrade.adoc +++ b/modules/upgrade/pages/k-rolling-upgrade.adoc @@ -98,9 +98,12 @@ Under-replicated partitions: [] <3> [[upgrade]] == Perform a rolling upgrade -Performing a rolling upgrade allows you to update the version of Redpanda managed by the Redpanda Helm chart without downtime. This process ensures that each broker is sequentially updated and restarted, minimizing the impact on your environment. +Performing a rolling upgrade allows you to update the version of Redpanda without downtime. This process ensures that each broker is sequentially updated and restarted, minimizing the impact on your environment. -You can use two methods to upgrade a Redpanda cluster in Kubernetes. The first method is to upgrade the Helm release to a newer version of the Redpanda Helm chart that uses the desired Redpanda version as a default. The second method is to update the existing Helm release to use a newer Redpanda image. The first method is preferred because upgrading the entire chart ensures that any new parameters required to configure the cluster are defined. +The upgrade process depends on your deployment method: + +- **Redpanda Operator**: Update the Redpanda custom resource to specify a new Helm chart version or Redpanda image tag. The operator manages the upgrade process. +- **Helm**: Either upgrade to a newer version of the Redpanda Helm chart (recommended) or update the Redpanda image tag in your existing Helm release. Upgrading the chart is preferred because it ensures that any new configuration parameters are included. Upgrading a Redpanda cluster in Kubernetes triggers a sequential restart of the Pods managed by the StatefulSet. During each broker's restart, the following steps occur: @@ -114,18 +117,50 @@ Operator:: + -- -. xref:upgrade:k-compatibility.adoc[Review the Kubernetes compatibility matrix] and determine the version of the Redpanda Operator that is compatible with the Helm chart version you plan to use. The Redpanda Operator must be able to understand and manage the Helm chart and the Redpanda version you are deploying. If you need to upgrade, see xref:upgrade:k-upgrade-operator.adoc[]. +. xref:upgrade:k-compatibility.adoc[Review the Kubernetes compatibility matrix] and https://github.com/redpanda-data/redpanda-operator/releases[review the Redpanda Operator release notes^] to determine the version of the Redpanda Operator that is compatible with the Helm chart and Redpanda version you plan to use. ++ +The Redpanda Operator and Helm chart follow the same versioning scheme as Redpanda core (for example, operator version 25.1.1 deploys Redpanda 25.1 by default). Each operator version supports the corresponding Redpanda version ±1 minor version. -. Check the default Redpanda version of a chart to make sure that it uses the version that you want to upgrade your cluster to. +. If you need to upgrade the Redpanda Operator: ++ +.. Back up your current Helm values for the Redpanda Operator: + [source,bash] ---- -helm show chart --version redpanda/redpanda | grep "appVersion" +helm get values redpanda-controller --namespace > redpanda-operator-values-backup.yaml ---- + +.. Upgrade the Redpanda Operator to a version compatible with your target Redpanda version: + -Replace `` with the version number of a newer chart. +[source,bash] +---- +helm repo add redpanda https://charts.redpanda.com +helm repo update +helm upgrade redpanda-controller redpanda/operator \ + --namespace \ + --version \ + --set crds.enabled=true +---- ++ +Replace `` with the version of the Redpanda Operator you want to upgrade to. -. Upgrade the Redpanda version by either updating the Helm chart version or the Redpanda image. +.. Verify that the operator deployment is successfully rolled out: ++ +[source,bash] +---- +kubectl --namespace rollout status --watch deployment/redpanda-controller-operator +---- ++ +.Expected output +[%collapsible] +==== +[.no-copy] +---- +deployment "redpanda-controller-operator" successfully rolled out +---- +==== + +. Upgrade the Redpanda cluster by updating the Redpanda image tag in your Redpanda resource: + .`redpanda-cluster.yaml` [source,yaml] @@ -135,20 +170,18 @@ kind: Redpanda metadata: name: redpanda spec: - chartRef: - chartVersion: <1> clusterSpec: image: - # Optional - tag: <2> + tag: <1> statefulset: # Optional - terminationGracePeriodSeconds: <3> + podTemplate: + spec: + terminationGracePeriodSeconds: <2> ---- + -<1> The version of the Redpanda Helm chart to deploy. -<2> If you need to upgrade to an intermediate version of Redpanda, use this setting to specify the version of Redpanda to deploy. This version overrides the default one in the Helm chart. Replace `` with a valid version tag. -<3> The xref:reference:k-redpanda-helm-spec.adoc#statefulsetterminationgraceperiodseconds[`statefulset.terminationGracePeriodSeconds`] setting defines how long Kubernetes will wait for the broker to shut down gracefully before forcefully terminating it. The default value is 90 seconds, which is enough for most clusters, but might require adjustment based on your workload. Modify this setting in your Helm values file if your Redpanda brokers have high loads or hold large amounts of data, as they might need more time to shut down gracefully. +<1> The version of Redpanda to deploy (for example, `v25.2.1`). The operator automatically uses the appropriate Helm chart version for the specified Redpanda version. +<2> The `statefulset.podTemplate.spec.terminationGracePeriodSeconds` setting defines how long Kubernetes will wait for the broker to shut down gracefully before forcefully terminating it. The default value is 90 seconds, which is enough for most clusters, but might require adjustment based on your workload. Modify this setting if your Redpanda brokers have high loads or hold large amounts of data, as they might need more time to shut down gracefully. . Apply the Redpanda resource to deploy the Redpanda cluster: + @@ -189,11 +222,13 @@ You'll need to apply these overrides in the next step. image: tag: <1> statefulset: - terminationGracePeriodSeconds: <2> + podTemplate: + spec: + terminationGracePeriodSeconds: <2> ---- + <1> If you need to upgrade to an intermediate version of Redpanda, use this setting to specify the version of Redpanda to deploy. This version overrides the default one in the Helm chart. Replace `` with a valid version tag. -<2> The xref:reference:k-redpanda-helm-spec.adoc#statefulsetterminationgraceperiodseconds[`statefulset.terminationGracePeriodSeconds`] setting defines how long Kubernetes will wait for the broker to shut down gracefully before forcefully terminating it. The default value is 90 seconds, which is enough for most clusters, but might require adjustment based on your workload. Modify this setting in your Helm values file if your Redpanda brokers have high loads or hold large amounts of data, as they might need more time to shut down gracefully. +<2> The `statefulset.podTemplate.spec.terminationGracePeriodSeconds` setting defines how long Kubernetes will wait for the broker to shut down gracefully before forcefully terminating it. The default value is 90 seconds, which is enough for most clusters, but might require adjustment based on your workload. Modify this setting in your Helm values file if your Redpanda brokers have high loads or hold large amounts of data, as they might need more time to shut down gracefully. . If your current chart uses Redpanda Console v2, migrate your configuration to the new v3 format before upgrading to 25.1.x. For more information, see xref:migrate:console-v3.adoc[]. @@ -249,6 +284,17 @@ kubectl exec --namespace -c redpanda -- \ rpk redpanda admin brokers list ``` +. If you upgraded from operator v25.1.x to v25.2.x or later, check for Console migration warnings: ++ +When upgrading across this version boundary, Redpanda Console is automatically upgraded from v2 to v3. The operator attempts to migrate your Console configuration automatically. If any configuration settings cannot be migrated, warnings are added to the Console custom resource. ++ +[,bash] +---- +kubectl get console --namespace -o jsonpath='{.spec.warnings}' +---- ++ +If warnings are present, review them and manually update your Console configuration as needed. For details about migrating to Console v3, see xref:migrate:console-v3.adoc[]. + == Roll back If something does not go as planned during a rolling upgrade, you can roll back to the original version as long as you have not upgraded all brokers. diff --git a/modules/upgrade/pages/k-upgrade-operator.adoc b/modules/upgrade/pages/k-upgrade-operator.adoc index 5c28bcf83d..56e802324c 100644 --- a/modules/upgrade/pages/k-upgrade-operator.adoc +++ b/modules/upgrade/pages/k-upgrade-operator.adoc @@ -1,26 +1,28 @@ = Upgrade the Redpanda Operator -:description: Upgrading the Redpanda Operator ensures your deployment benefits from the latest features, fixes, and improvements. Follow these steps carefully to ensure a successful upgrade. -// Unset this attribute so that we don't pre-fill the version in code snippets -:!latest-operator-version: +:description: Upgrading the Redpanda Operator ensures your deployment benefits from the latest features, fixes, and improvements. -{description} +Starting from version 25.1.1, the Redpanda Operator follows the same versioning scheme as Redpanda core releases. When you upgrade Redpanda, you typically also upgrade the Redpanda Operator to ensure compatibility. -. Make sure to https://github.com/redpanda-data/redpanda-operator/releases[review the release notes^] to understand any significant changes, bug fixes, or potential disruptions that could affect your existing deployment. +For complete upgrade instructions, including how to upgrade both the Redpanda Operator and your Redpanda cluster, see xref:upgrade:k-rolling-upgrade.adoc[]. -. xref:upgrade:k-compatibility.adoc[Review the Kubernetes compatibility matrix] and determine the version of the Redpanda Operator that is compatible with the Helm chart version you plan to use. The Redpanda Operator must be able to understand and manage the Helm chart and the Redpanda version you are deploying. +== Operator-only upgrades -. Back up your current Helm values for the Redpanda Operator Helm chart: +In some cases, you might need to upgrade only the Redpanda Operator without upgrading your Redpanda cluster. For example, you might need to apply a patch release that fixes an operator bug. + +To upgrade only the operator: + +. https://github.com/redpanda-data/redpanda-operator/releases[Review the Redpanda Operator release notes^] and xref:upgrade:k-compatibility.adoc[the Kubernetes compatibility matrix]. + +. Back up your current Helm values: + [source,bash] ---- helm get values redpanda-controller --namespace > redpanda-operator-values-backup.yaml ---- -+ -You'll need to apply these overrides in the next step. -. Upgrade the Redpanda Operator. Replace `` with the version of the Redpanda Operator you want to upgrade to. +. Upgrade the Redpanda Operator: + -[,bash,subs="attributes+"] +[source,bash] ---- helm repo add redpanda https://charts.redpanda.com helm repo update @@ -30,26 +32,22 @@ helm upgrade redpanda-controller redpanda/operator \ --set crds.enabled=true ---- + -This command: -+ -- Pins the upgrade to a specific version of Redpanda Operator. -- Ensures the latest CRDs are applied as part of the upgrade. -+ -CAUTION: Omitting custom overrides may result in a broken or partial deployment. +Replace `` with the version of the Redpanda Operator you want to upgrade to. + +CAUTION: Make sure to include any custom overrides from your backup file to prevent a broken or partial deployment. - -. Ensure that the Deployment is successfully rolled out: +. Verify that the deployment is successfully rolled out: + -```bash +[source,bash] +---- kubectl --namespace rollout status --watch deployment/redpanda-controller-operator -``` +---- + +.Expected output +[%collapsible] +==== [.no-copy] ---- deployment "redpanda-controller-operator" successfully rolled out ---- - -== Next steps - -xref:upgrade:k-rolling-upgrade.adoc[] +==== diff --git a/tests/setup-tests/fetch-versions-and-rpk.json b/tests/setup-tests/fetch-versions-and-rpk.json index 794c2af4ae..27c76d8c56 100644 --- a/tests/setup-tests/fetch-versions-and-rpk.json +++ b/tests/setup-tests/fetch-versions-and-rpk.json @@ -56,7 +56,7 @@ "description": "Use doc-tools to install any additional test dependencies.", "runShell": { "command": "npx doc-tools install-test-dependencies", - "timeout": 300000 + "timeout": 420000 } }, {