diff --git a/content/post/kubedb-v2024.11.18/index.md b/content/post/kubedb-v2024.11.18/index.md index 89edb39c..44d34160 100644 --- a/content/post/kubedb-v2024.11.18/index.md +++ b/content/post/kubedb-v2024.11.18/index.md @@ -49,18 +49,18 @@ We are thrilled to announce the release of **KubeDB v2024.11.18**. This release - **Autoscaling**: Added autoscaling support for Apache Solr to automatically adjust resources based on workload demands. -- **RotateAuth**: A new Ops Request named `RotateAuth` has been introduced. This feature enables users to rotate the credentials of the database enhancing overall security. It is initially added for Druid, Elasticsearch, Kafka, MongoDB, Postgres, and Solr. +- **RotateAuth**: A new Ops-Request named `RotateAuth` has been introduced. This feature enables users to rotate the credentials of the database, enhancing overall security. It is initially added for Druid, Elasticsearch, Kafka, MongoDB, Postgres, and Solr. - **Authentication**: Authentication support has been introduced for Memcached, providing an additional layer of security by verifying client identities before granting access. -- **New Version Support**: Added support for Druid version `30.0.1` and MongoDB version `8.0.3`. - - **Monitoring**: Added enhanced monitoring feature for KubeDB-managed Cassandra deployments by integrating Grafana dashboards. - **Recommendation Engine**: This release includes important fixes and improvements for the Recommendation Engine. - **Performance Improvement**: This release brings enhancements to controller performance, ensuring more efficient and faster operations. +- **New Version Support**: Support for Druid version `30.0.1` and MongoDB version `8.0.3` has been added. + For detailed changelogs, please refer to the [CHANGELOG](https://github.com/kubedb/CHANGELOG/blob/master/releases/v2024.11.18/README.md). You can now explore the detailed features and updates included in this release. ## Cassandra @@ -85,7 +85,7 @@ With TLS enabled, client applications can securely connect to the Druid cluster, In addition to securing client-to-server communication, **internal communication** among Druid nodes is also encrypted. Furthermore, **connections to external dependencies**, such as metadata storage and deep storage systems, are secured. -To configure TLS/SSL in Druid, KubeDB utilizes cert-manager to issue certificates. Before proceeding with TLS configuration in Druid, ensure that cert-manager is installed in your cluster. You can follow the steps provided [here](https://cert-manager.io/docs/installation/kubectl/) to install cert-manager in your cluster. +To configure TLS/SSL in Druid, KubeDB utilizes `cert-manager` to issue certificates. Before proceeding with TLS configuration in Druid, ensure that cert-manager is installed in your cluster. You can follow the steps provided [here](https://cert-manager.io/docs/installation/kubectl/) to install cert-manager in your cluster. To issue a certificate, cert-manager employs the following Custom Resource (CR): @@ -93,7 +93,7 @@ To issue a certificate, cert-manager employs the following Custom Resource (CR): **Certificate**: cert-manager introduces the concept of Certificates, which define the desired x509 certificate to be renewed and maintained up to date. More details on Certificates can be found [here](https://cert-manager.io/docs/usage/certificate/). -Druid `CRD` Specifications: +Here is the TLS enabled Druid YAML: ```yaml apiVersion: kubedb.com/v1alpha2 @@ -208,6 +208,7 @@ spec: This is an example showing how to add TLS to an existing druid cluster. Reconfigure-TLS also supports features like **Removing TLS**, **Rotating Certificates** or **Changing Issuer**. **RotateAuth** + ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: DruidOpsRequest @@ -219,6 +220,7 @@ spec: databaseRef: name: druid-cluster ``` + It is also possible to provide a username and password through a custom authentication section through `spec.authentication.secretRef.name` of `DruidOpsRequest`. ### New Version Support @@ -345,7 +347,13 @@ We have added a field `.spec.authSecret.activeFrom` to the db yaml which refers ### Authentication -In this release, we are adding `Memcached` authentication support. Before we were connecting to the `Memcached` database without any authentication. From now, we will need username and password to connect with the `Memcached` database. Users can set username and password using a secret or we will create a default one. The Yaml will be like bellow: +In this release, we are introducing authentication support for Memcached. Previously, connections to the Memcached database were made without any authentication. Going forward, a username and password will be required to connect to the Memcached database. + +Users can provide their own username and password using a Kubernetes Secret, or the system will generate default credentials if none are provided. + +Below is an example of the YAML configuration: + +**Authentication Secret**: ```yaml @@ -359,7 +367,7 @@ data: authData: YWxpY2U6Ym9iCg== ``` -And the `Memcached` Yaml will be look like this one: +**`Memcached` YAML**: ```yaml @@ -391,7 +399,7 @@ To issue a certificate, cert-manager employs the following Custom Resource (CR): **Certificate**: cert-manager introduces the concept of Certificates, which define the desired x509 certificate to be renewed and maintained up to date. More details on Certificates can be found here. -`Memcached` CRD Specifications: +Here is the TLS enabled `Memcached` YAML: ```yaml @@ -423,7 +431,7 @@ We are introducing new Ops-Requests for `Memcached` which is Reconfigure TLS. Yo **Reconfigure TLS** -By using Reconfigure TLS Ops-Request, we can add TLS to an existing `Memcached` which is configured without TLS, can remove TLS configuration on existing `Memcached` which is configured with TLS, can rotate the certificates, can change the issuer. The Yaml will be like: +By using Reconfigure TLS Ops-Request, we can add TLS to an existing `Memcached` which is configured without TLS, can remove TLS configuration on existing `Memcached` which is configured with TLS, can rotate the certificates, can change the issuer. The YAML will be like: ```yaml @@ -461,6 +469,7 @@ We are excited to introduce two new Ops-Requests for managing Microsoft SQL Serv **Reconfigure Ops-Request** The `Reconfigure` operation enables you to update the configuration of an existing SQL Server cluster. This can be achieved using a custom configuration secret or by specifying configurations directly in the manifest. + Example 1: Using a Custom Configuration Secret ```yaml @@ -579,8 +588,7 @@ tls: **Updated Fields**: -- Leader Election Configuration: - - The field `spec.leaderElection` is now moved under `spec.topology.availabilityGroup.leaderElection`. +- Leader Election Configuration: The field `spec.leaderElection` is now moved under `spec.topology.availabilityGroup.leaderElection`. Below is the updated structure reflecting these changes: ```yaml @@ -590,24 +598,6 @@ tls: kind: Issuer name: mssqlserver-ca-issuer certificates: - - alias: server - emailAddresses: - - dev@appscode.com - secretName: mssqlserver-server-cert - subject: - organizationalUnits: - - server - organizations: - - kubedb - - alias: client - emailAddresses: - - abc@appscode.com - secretName: mssqlserver-client-cert - subject: - organizationalUnits: - - client - organizations: - - kubedb - alias: endpoint secretName: mssqlserver-endpoint-cert subject: @@ -630,9 +620,7 @@ topology: mode: AvailabilityGroup ``` -**Additional Notes:** -- Use `spec.tls` to configure all TLS/SSL-related settings, including endpoint authentication for Availability Group replicas. -- For leader election, adjust parameters under `spec.topology.availabilityGroup.leaderElection` as needed. +> Note: Use `spec.tls` to configure all TLS/SSL-related settings, including endpoint authentication for Availability Group replicas. ### Configuring MSSQL Environment Variables @@ -670,7 +658,7 @@ spec: In this example, the SQL Server container will run the **Enterprise Edition** of SQL Server. -For a complete list of environment variables and their usage, refer to the [official Microsoft documentation](https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-configure-environment-variables?view=sql-server-2017). +To know more about these environment variables and their usage, refer to the [official Microsoft documentation](https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-configure-environment-variables?view=sql-server-2017). ## MongoDB @@ -842,6 +830,7 @@ spec: ``` If the secret is referenced, the operator will update the .spec.authSecret.name` with the new secret name. Here is the yaml, + New Secret: ```yaml apiVersion: v1 @@ -1072,7 +1061,7 @@ spec: **RotateAuth OpsRequest**: We have also added support for RotateAuth ops request for `Solr` in this release. It will rotate the admin credential of solr. We can provide secret name in the spec.authentication.secretRef.name and ops manager with update the credential of database. -If we don’t provide any secret and the password of the current secret will be updated. +If we don’t provide any secret, then the password of the current secret will be updated. Solr RotateAuth OpsRequest: