diff --git a/docs/examples/mssqlserver/update-version/msops-update-ag-cluster.yaml b/docs/examples/mssqlserver/update-version/msops-update-ag-cluster.yaml new file mode 100644 index 000000000..78a9ad965 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/msops-update-ag-cluster.yaml @@ -0,0 +1,13 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-ag-cluster + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-ag-cluster + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml b/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml new file mode 100644 index 000000000..3f4c51368 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml @@ -0,0 +1,13 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-standalone + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-standalone + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml b/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml new file mode 100644 index 000000000..bad6f7bb9 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml @@ -0,0 +1,44 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut diff --git a/docs/examples/mssqlserver/update-version/mssql-standalone.yaml b/docs/examples/mssqlserver/update-version/mssql-standalone.yaml new file mode 100644 index 000000000..512bbeb78 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/mssql-standalone.yaml @@ -0,0 +1,32 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mssqlserver/README.md b/docs/guides/mssqlserver/README.md index 6c5ab86cc..ebd1502f8 100644 --- a/docs/guides/mssqlserver/README.md +++ b/docs/guides/mssqlserver/README.md @@ -20,30 +20,30 @@ Microsoft SQL Server is one of the most popular relational database management s ## Supported Microsoft SQL Server Features -| Features | Availability | -|---------------------------------------------------------------------|:------------:| -| Standalone and Availability Group Cluster (HA configuration) | ✓ | -| Synchronous Replication | ✓ | -| Automatic Failover | ✓ | -| Custom Configuration | ✓ | -| Authentication & Authorization | ✓ | -| Externally manageable Auth Secret | ✓ | -| Instant and Scheduled Backup ([KubeStash](https://kubestash.com/)) | ✓ | -| Continuous Archiving using `wal-g` | ✓ | -| Initialization from WAL archive | ✓ | -| Initializing from Snapshot ([KubeStash](https://kubestash.com/)) | ✓ | -| Reconfigurable Health Checker | ✓ | -| Persistent volume | ✓ | -| Builtin Prometheus Discovery | ✓ | -| Using Prometheus operator | ✓ | -| Automated Version Update | ✓ | -| Automated Vertical Scaling, Volume Expansion | ✓ | -| Automated Horizontal Scaling | ✓ | -| Autoscaler for Compute and Storage Resources | ✓ | -| Reconfiguration | ✓ | -| TLS | ✓ | -| Grafana Dashboards | ✓ | -| Autoscaling (vertically) | ✓ | +| Features | Availability | +|--------------------------------------------------------------------|:------------:| +| Standalone and Availability Group Cluster (HA configuration) | ✓ | +| Synchronous Replication | ✓ | +| Automatic Failover | ✓ | +| Custom Configuration | ✓ | +| Authentication & Authorization | ✓ | +| Externally manageable Auth Secret | ✓ | +| Instant and Scheduled Backup ([KubeStash](https://kubestash.com/)) | ✓ | +| Continuous Archiving using `wal-g` | ✓ | +| Initialization from WAL archive | ✓ | +| Initializing from Snapshot ([KubeStash](https://kubestash.com/)) | ✓ | +| Reconfigurable Health Checker | ✓ | +| Persistent Volume | ✓ | +| Builtin Prometheus Discovery | ✓ | +| Using Prometheus operator | ✓ | +| Automated Version Update | ✓ | +| Automated Vertical Scaling, Volume Expansion | ✓ | +| Automated Horizontal Scaling | ✓ | +| Autoscaling Compute and Storage Resources | ✓ | +| Reconfiguration | ✓ | +| TLS | ✓ | +| Reconfigure TLS | ✓ | +| Grafana Dashboards | ✓ | ## Supported Microsoft SQL Server Versions diff --git a/docs/guides/mssqlserver/reconfigure-tls/overview.md b/docs/guides/mssqlserver/reconfigure-tls/overview.md new file mode 100644 index 000000000..1c3b55d69 --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure-tls/overview.md @@ -0,0 +1,54 @@ +--- +title: Reconfiguring TLS of MSSQLServer Database +menu: + docs_{{ .version }}: + identifier: mg-reconfigure-tls-overview + name: Overview + parent: mg-reconfigure-tls + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfiguring TLS of MSSQLServer Database + +This guide will give an overview on how KubeDB Ops-manager operator reconfigures TLS configuration i.e. add TLS, remove TLS, update issuer/cluster issuer or Certificates and rotate the certificates of a `MSSQLServer` database. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + +## How Reconfiguring MSSQLServer TLS Configuration Process Works + +The following diagram shows how KubeDB Ops-manager operator reconfigures TLS of a `MSSQLServer` database. Open the image in a new tab to see the enlarged version. + +
+  Reconfiguring TLS process of MSSQLServer +
Fig: Reconfiguring TLS process of MSSQLServer
+
+ +The Reconfiguring MSSQLServer TLS process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource Object (CRO). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CRO. + +3. When the operator finds a `MSSQLServer` CR, it creates required number of `PetSets` and related necessary stuff like secrets, services, etc. + +4. Then, in order to reconfigure the TLS configuration of the `MSSQLServer` database the user creates a `MSSQLServerOpsRequest` CR with desired information. + +5. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +6. When it finds a `MSSQLServerOpsRequest` CR, it pauses the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the reconfiguring TLS process. + +7. Then the `KubeDB` Ops-manager operator will add, remove, update or rotate TLS configuration based on the Ops Request yaml. + +8. Then the `KubeDB` Ops-manager operator will restart all the Pods of the database so that they restart with the new TLS configuration defined in the `MSSQLServerOpsRequest` CR. + +9. After the successful reconfiguring of the `MSSQLServer` TLS, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator resumes its usual operations. + +In the next docs, we are going to show a step by step guide on reconfiguring TLS configuration of a MSSQLServer database using `MSSQLServerOpsRequest` CRD. \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure-tls/reconfigure-tls.md b/docs/guides/mssqlserver/reconfigure-tls/reconfigure-tls.md new file mode 100644 index 000000000..dd0eb321d --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure-tls/reconfigure-tls.md @@ -0,0 +1,1006 @@ +--- +title: Reconfigure MSSQLServer TLS/SSL Encryption +menu: + docs_{{ .version }}: + identifier: mg-reconfigure-tls-rs + name: Reconfigure MSSQLServer TLS/SSL Encryption + parent: mg-reconfigure-tls + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfigure MSSQLServer TLS/SSL (Transport Encryption) + +KubeDB supports reconfigure i.e. add, remove, update and rotation of TLS/SSL certificates for existing MSSQLServer database via a MSSQLServerOpsRequest. This tutorial will show you how to use KubeDB to reconfigure TLS/SSL encryption. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Install [`cert-manger`](https://cert-manager.io/docs/installation/) v1.0.0 or later to your cluster to manage your SSL/TLS certificates. + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + + ```bash + $ kubectl create ns demo + namespace/demo created + ``` + +> Note: YAML files used in this tutorial are stored in [docs/examples/mssqlserver](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Add TLS to a MSSQLServer database + +Here, We are going to create a MSSQLServer database without TLS and then reconfigure the database to use TLS. + +### Deploy MSSQLServer without TLS + +In this section, we are going to deploy a MSSQLServer Replicaset database without TLS. In the next few sections we will reconfigure TLS using `MSSQLServerOpsRequest` CRD. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1 +kind: MSSQLServer +metadata: + name: mg-rs + namespace: demo +spec: + version: "4.4.26" + replicas: 3 + replicaSet: + name: rs0 + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mg-replicaset.yaml +mssqlserver.kubedb.com/mg-rs created +``` + +Now, wait until `mg-replicaset` has status `Ready`. i.e, + +```bash +$ kubectl get mg -n demo +NAME VERSION STATUS AGE +mg-rs 4.4.26 Ready 10m + +$ kubectl dba describe mssqlserver mg-rs -n demo +Name: mg-rs +Namespace: demo +CreationTimestamp: Thu, 11 Mar 2021 13:25:05 +0600 +Labels: +Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"kubedb.com/v1","kind":"MSSQLServer","metadata":{"annotations":{},"name":"mg-rs","namespace":"demo"},"spec":{"replicaSet":{"name":"rs0"... +Replicas: 3 total +Status: Ready +StorageType: Durable +Volume: + StorageClass: standard + Capacity: 1Gi + Access Modes: RWO +Paused: false +Halted: false +Termination Policy: Delete + +PetSet: + Name: mg-rs + CreationTimestamp: Thu, 11 Mar 2021 13:25:05 +0600 + Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mg-rs + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com + Annotations: + Replicas: 824639275080 desired | 3 total + Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed + +Service: + Name: mg-rs + Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mg-rs + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com + Annotations: + Type: ClusterIP + IP: 10.96.70.27 + Port: primary 27017/TCP + TargetPort: db/TCP + Endpoints: 10.244.0.63:27017 + +Service: + Name: mg-rs-pods + Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mg-rs + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com + Annotations: + Type: ClusterIP + IP: None + Port: db 27017/TCP + TargetPort: db/TCP + Endpoints: 10.244.0.63:27017,10.244.0.65:27017,10.244.0.67:27017 + +Auth Secret: + Name: mg-rs-auth + Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mg-rs + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com + Annotations: + Type: Opaque + Data: + password: 16 bytes + username: 4 bytes + +AppBinding: + Metadata: + Annotations: + kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"kubedb.com/v1","kind":"MSSQLServer","metadata":{"annotations":{},"name":"mg-rs","namespace":"demo"},"spec":{"replicaSet":{"name":"rs0"},"replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"standard"},"version":"4.4.26"}} + + Creation Timestamp: 2021-03-11T07:26:44Z + Labels: + app.kubernetes.io/component: database + app.kubernetes.io/instance: mg-rs + app.kubernetes.io/managed-by: kubedb.com + app.kubernetes.io/name: mssqlservers.kubedb.com + Name: mg-rs + Namespace: demo + Spec: + Client Config: + Service: + Name: mg-rs + Port: 27017 + Scheme: mssqlserver + Parameters: + API Version: config.kubedb.com/v1alpha1 + Kind: MongoConfiguration + Replica Sets: + host-0: rs0/mg-rs-0.mg-rs-pods.demo.svc,mg-rs-1.mg-rs-pods.demo.svc,mg-rs-2.mg-rs-pods.demo.svc + Stash: + Addon: + Backup Task: + Name: mssqlserver-backup-4.4.6-v6 + Restore Task: + Name: mssqlserver-restore-4.4.6-v6 + Secret: + Name: mg-rs-auth + Type: kubedb.com/mssqlserver + Version: 4.4.26 + +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Successful 14m MSSQLServer operator Successfully created stats service + Normal Successful 14m MSSQLServer operator Successfully created Service + Normal Successful 14m MSSQLServer operator Successfully stats service + Normal Successful 14m MSSQLServer operator Successfully stats service + Normal Successful 13m MSSQLServer operator Successfully stats service + Normal Successful 13m MSSQLServer operator Successfully stats service + Normal Successful 13m MSSQLServer operator Successfully stats service + Normal Successful 13m MSSQLServer operator Successfully stats service + Normal Successful 13m MSSQLServer operator Successfully stats service + Normal Successful 12m MSSQLServer operator Successfully stats service + Normal Successful 12m MSSQLServer operator Successfully patched PetSet demo/mg-rs +``` + +Now, we can connect to this database through [mongo-shell](https://docs.mssqlserver.com/v4.2/mongo/) and verify that the TLS is disabled. + + +```bash +$ kubectl get secrets -n demo mg-rs-auth -o jsonpath='{.data.\username}' | base64 -d +root + +$ kubectl get secrets -n demo mg-rs-auth -o jsonpath='{.data.\password}' | base64 -d +U6(h_pYrekLZ2OOd + +$ kubectl exec -it mg-rs-0 -n demo -- mongo admin -u root -p 'U6(h_pYrekLZ2OOd' +rs0:PRIMARY> db.adminCommand({ getParameter:1, sslMode:1 }) +{ + "sslMode" : "disabled", + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1615468344, 1), + "signature" : { + "hash" : BinData(0,"Xdclj9Y67WKZ/oTDGT/E1XzOY28="), + "keyId" : NumberLong("6938294279689207810") + } + }, + "operationTime" : Timestamp(1615468344, 1) +} +``` + +We can verify from the above output that TLS is disabled for this database. + +### Create Issuer/ ClusterIssuer + +Now, We are going to create an example `Issuer` that will be used to enable SSL/TLS in MSSQLServer. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. + +- Start off by generating a ca certificates using openssl. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca/O=kubedb" +Generating a RSA private key +................+++++ +........................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls mongo-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/mongo-ca created +``` + +Now, Let's create an `Issuer` using the `mongo-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mg-issuer + namespace: demo +spec: + ca: + secretName: mongo-ca +``` + +Let's apply the `YAML` file: + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/issuer.yaml +issuer.cert-manager.io/mg-issuer created +``` + +### Create MSSQLServerOpsRequest + +In order to add TLS to the database, we have to create a `MSSQLServerOpsRequest` CRO with our created issuer. Below is the YAML of the `MSSQLServerOpsRequest` CRO that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-add-tls + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + issuerRef: + name: mg-issuer + kind: Issuer + apiGroup: "cert-manager.io" + certificates: + - alias: client + subject: + organizations: + - mongo + organizationalUnits: + - client + readinessCriteria: + oplogMaxLagSeconds: 20 + objectsCountDiffPercentage: 10 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `mg-rs` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.issuerRef` specifies the issuer name, kind and api group. +- `spec.tls.certificates` specifies the certificates. You can learn more about this field from [here](/docs/guides/mssqlserver/concepts/mssqlserver.md#spectls). + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-add-tls.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-add-tls created +``` + +#### Verify TLS Enabled Successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-add-tls ReconfigureTLS Successful 91s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-add-tls +Name: mops-add-tls +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T13:32:18Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:certificates: + f:issuerRef: + .: + f:apiGroup: + f:kind: + f:name: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T13:32:18Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T13:32:19Z + Resource Version: 488264 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-add-tls + UID: 0024ec16-0d43-4686-a2d7-1cdeb96e41a5 +Spec: + Database Ref: + Name: mg-rs + Tls: + Certificates: + Alias: client + Subject: + Organizational Units: + client + Organizations: + mongo + Issuer Ref: + API Group: cert-manager.io + Kind: Issuer + Name: mg-issuer + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T13:32:19Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T13:32:25Z + Message: Successfully Updated PetSets + Observed Generation: 1 + Reason: TLSAdded + Status: True + Type: TLSAdded + Last Transition Time: 2021-03-11T13:34:25Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T13:34:25Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal PauseDatabase 2m10s KubeDB Ops-manager operator Pausing MSSQLServer demo/mg-rs + Normal PauseDatabase 2m10s KubeDB Ops-manager operator Successfully paused MSSQLServer demo/mg-rs + Normal TLSAdded 2m10s KubeDB Ops-manager operator Successfully Updated PetSets + Normal RestartReplicaSet 10s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal ResumeDatabase 10s KubeDB Ops-manager operator Resuming MSSQLServer demo/mg-rs + Normal ResumeDatabase 10s KubeDB Ops-manager operator Successfully resumed MSSQLServer demo/mg-rs + Normal Successful 10s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, Let's exec into a database primary node and find out the username to connect in a mongo shell, + +```bash +$ kubectl exec -it mg-rs-2 -n demo bash +root@mgo-rs-tls-2:/$ ls /var/run/mssqlserver/tls +ca.crt client.pem mongo.pem +root@mgo-rs-tls-2:/$ openssl x509 -in /var/run/mssqlserver/tls/client.pem -inform PEM -subject -nameopt RFC2253 -noout +subject=CN=root,OU=client,O=mongo +``` + +Now, we can connect using `CN=root,OU=client,O=mongo` as root to connect to the mongo shell of the master pod, + +```bash +root@mgo-rs-tls-2:/$ mongo --tls --tlsCAFile /var/run/mssqlserver/tls/ca.crt --tlsCertificateKeyFile /var/run/mssqlserver/tls/client.pem admin --host localhost --authenticationMechanism MONGODB-X509 --authenticationDatabase='$external' -u "CN=root,OU=client,O=mongo" --quiet +rs0:PRIMARY> +``` + +We are connected to the mongo shell. Let's run some command to verify the sslMode and the user, + +```bash +rs0:PRIMARY> db.adminCommand({ getParameter:1, sslMode:1 }) +{ + "sslMode" : "requireSSL", + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1615472249, 1), + "signature" : { + "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), + "keyId" : NumberLong(0) + } + }, + "operationTime" : Timestamp(1615472249, 1) +} +``` + +We can see from the above output that, `sslMode` is set to `requireSSL`. So, database TLS is enabled successfully to this database. + +## Rotate Certificate + +Now we are going to rotate the certificate of this database. First let's check the current expiration date of the certificate. + +```bash +$ kubectl exec -it mg-rs-2 -n demo bash +root@mg-rs-2:/# openssl x509 -in /var/run/mssqlserver/tls/client.pem -inform PEM -enddate -nameopt RFC2253 -noout +notAfter=Jun 9 13:32:20 2021 GMT +``` + +So, the certificate will expire on this time `Jun 9 13:32:20 2021 GMT`. + +### Create MSSQLServerOpsRequest + +Now we are going to increase it using a MSSQLServerOpsRequest. Below is the yaml of the ops request that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-rotate + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + rotateCertificates: true +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `mg-rs` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.rotateCertificates` specifies that we want to rotate the certificate of this database. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-rotate.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-rotate created +``` + +#### Verify Certificate Rotated Successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-rotate ReconfigureTLS Successful 112s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-rotate +Name: mops-rotate +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T16:17:55Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:rotateCertificates: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T16:17:55Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T16:17:55Z + Resource Version: 521643 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-rotate + UID: 6d96ead2-a868-47d8-85fb-77eecc9a96b4 +Spec: + Database Ref: + Name: mg-rs + Tls: + Rotate Certificates: true + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T16:17:55Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T16:17:55Z + Message: Successfully Added Issuing Condition in Certificates + Observed Generation: 1 + Reason: IssuingConditionUpdated + Status: True + Type: IssuingConditionUpdated + Last Transition Time: 2021-03-11T16:18:00Z + Message: Successfully Issued New Certificates + Observed Generation: 1 + Reason: CertificateIssuingSuccessful + Status: True + Type: CertificateIssuingSuccessful + Last Transition Time: 2021-03-11T16:19:45Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T16:19:45Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal CertificateIssuingSuccessful 2m10s KubeDB Ops-manager operator Successfully Issued New Certificates + Normal RestartReplicaSet 25s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal Successful 25s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, let's check the expiration date of the certificate. + +```bash +$ kubectl exec -it mg-rs-2 -n demo bash +root@mg-rs-2:/# openssl x509 -in /var/run/mssqlserver/tls/client.pem -inform PEM -enddate -nameopt RFC2253 -noout +notAfter=Jun 9 16:17:55 2021 GMT +``` + +As we can see from the above output, the certificate has been rotated successfully. + +## Change Issuer/ClusterIssuer + +Now, we are going to change the issuer of this database. + +- Let's create a new ca certificate and key using a different subject `CN=ca-update,O=kubedb-updated`. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca-updated/O=kubedb-updated" +Generating a RSA private key +..............................................................+++++ +......................................................................................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a new ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls mongo-new-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/mongo-new-ca created +``` + +Now, Let's create a new `Issuer` using the `mongo-new-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mg-new-issuer + namespace: demo +spec: + ca: + secretName: mongo-new-ca +``` + +Let's apply the `YAML` file: + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/new-issuer.yaml +issuer.cert-manager.io/mg-new-issuer created +``` + +### Create MSSQLServerOpsRequest + +In order to use the new issuer to issue new certificates, we have to create a `MSSQLServerOpsRequest` CRO with the newly created issuer. Below is the YAML of the `MSSQLServerOpsRequest` CRO that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-change-issuer + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + issuerRef: + name: mg-new-issuer + kind: Issuer + apiGroup: "cert-manager.io" +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `mg-rs` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.issuerRef` specifies the issuer name, kind and api group. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-change-issuer.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-change-issuer created +``` + +#### Verify Issuer is changed successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-change-issuer ReconfigureTLS Successful 105s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-change-issuer +Name: mops-change-issuer +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T16:27:47Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:issuerRef: + .: + f:apiGroup: + f:kind: + f:name: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T16:27:47Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T16:27:47Z + Resource Version: 523903 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-change-issuer + UID: cdfe8a7d-52ef-466c-a5dd-97e74ad598ca +Spec: + Database Ref: + Name: mg-rs + Tls: + Issuer Ref: + API Group: cert-manager.io + Kind: Issuer + Name: mg-new-issuer + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T16:27:47Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T16:27:52Z + Message: Successfully Issued New Certificates + Observed Generation: 1 + Reason: CertificateIssuingSuccessful + Status: True + Type: CertificateIssuingSuccessful + Last Transition Time: 2021-03-11T16:29:37Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T16:29:37Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal CertificateIssuingSuccessful 2m27s KubeDB Ops-manager operator Successfully Issued New Certificates + Normal RestartReplicaSet 42s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal Successful 42s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, Let's exec into a database node and find out the ca subject to see if it matches the one we have provided. + +```bash +$ kubectl exec -it mg-rs-2 -n demo bash +root@mgo-rs-tls-2:/$ openssl x509 -in /var/run/mssqlserver/tls/ca.crt -inform PEM -subject -nameopt RFC2253 -noout +subject=O=kubedb-updated,CN=ca-updated +``` + +We can see from the above output that, the subject name matches the subject name of the new ca certificate that we have created. So, the issuer is changed successfully. + +## Remove TLS from the Database + +Now, we are going to remove TLS from this database using a MSSQLServerOpsRequest. + +### Create MSSQLServerOpsRequest + +Below is the YAML of the `MSSQLServerOpsRequest` CRO that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-remove + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + remove: true +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `mg-rs` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.remove` specifies that we want to remove tls from this database. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-remove.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-remove created +``` + +#### Verify TLS Removed Successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-remove ReconfigureTLS Successful 105s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-remove +Name: mops-remove +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T16:35:32Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:remove: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T16:35:32Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T16:35:32Z + Resource Version: 525550 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-remove + UID: 99184cc4-1595-4f0f-b8eb-b65c5d0e86a6 +Spec: + Database Ref: + Name: mg-rs + Tls: + Remove: true + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T16:35:32Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T16:35:37Z + Message: Successfully Updated PetSets + Observed Generation: 1 + Reason: TLSRemoved + Status: True + Type: TLSRemoved + Last Transition Time: 2021-03-11T16:37:07Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T16:37:07Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal PauseDatabase 2m5s KubeDB Ops-manager operator Pausing MSSQLServer demo/mg-rs + Normal PauseDatabase 2m5s KubeDB Ops-manager operator Successfully paused MSSQLServer demo/mg-rs + Normal TLSRemoved 2m5s KubeDB Ops-manager operator Successfully Updated PetSets + Normal RestartReplicaSet 35s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal ResumeDatabase 35s KubeDB Ops-manager operator Resuming MSSQLServer demo/mg-rs + Normal ResumeDatabase 35s KubeDB Ops-manager operator Successfully resumed MSSQLServer demo/mg-rs + Normal Successful 35s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, Let's exec into the database primary node and find out that TLS is disabled or not. + +```bash +$ kubectl exec -it -n demo mg-rs-1 -- mongo admin -u root -p 'U6(h_pYrekLZ2OOd' +rs0:PRIMARY> db.adminCommand({ getParameter:1, sslMode:1 }) +{ + "sslMode" : "disabled", + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1615480817, 1), + "signature" : { + "hash" : BinData(0,"CWJngDTQqDhKXyx7WMFJqqUfvhY="), + "keyId" : NumberLong("6938294279689207810") + } + }, + "operationTime" : Timestamp(1615480817, 1) +} +``` + +So, we can see from the above that, output that tls is disabled successfully. + +## Cleaning up + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserver -n demo mg-rs +kubectl delete issuer -n demo mg-issuer mg-new-issuer +kubectl delete mssqlserveropsrequest mops-add-tls mops-remove mops-rotate mops-change-issuer +kubectl delete ns demo +``` + +## Next Steps + +- Detail concepts of [MSSQLServer object](/docs/guides/mssqlserver/concepts/mssqlserver.md). +- Initialize [MSSQLServer with Script](/docs/guides/mssqlserver/initialization/using-script.md). +- Monitor your MSSQLServer database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/mssqlserver/monitoring/using-prometheus-operator.md). +- Monitor your MSSQLServer database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/mssqlserver/monitoring/using-builtin-prometheus.md). +- Use [private Docker registry](/docs/guides/mssqlserver/private-registry/using-private-registry.md) to deploy MSSQLServer with KubeDB. +- Use [kubedb cli](/docs/guides/mssqlserver/cli/cli.md) to manage databases like kubectl for Kubernetes. +- Detail concepts of [MSSQLServer object](/docs/guides/mssqlserver/concepts/mongodb.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mssqlserver/update-version/ag_cluster.md b/docs/guides/mssqlserver/update-version/ag_cluster.md new file mode 100644 index 000000000..25fa4408e --- /dev/null +++ b/docs/guides/mssqlserver/update-version/ag_cluster.md @@ -0,0 +1,352 @@ +--- +title: Updating MSSQLServer Availability Group +menu: + docs_{{ .version }}: + identifier: ms-updating-ag-cluster + name: Availability Group (HA Cluster) + parent: mssql-updating + weight: 30 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Update version of MSSQLServer Availability Group + +This guide will show you how to use `KubeDB` Ops-manager operator to update the version of `MSSQLServer` Availability Group Cluster. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [Availability Group Cluster](/docs/guides/mssqlserver/clustering/ag_cluster.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Updating Overview](/docs/guides/mssqlserver/update-version/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/update-version) directory of [kubedb/docs](https://github.com/kube/docs) repository. + +## Prepare MSSQLServer Availability Group Database + +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/ag-cluster/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +Now, we are going to deploy a `MSSQLServer` availability group with version `2022-cu12`. + +### Deploy MSSQLServer AG Cluster + +In this section, we are going to deploy a MSSQLServer availability group cluster. Then, in the next section we will update the version of the database using `MSSQLServerOpsRequest` CR. + +Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml +mssqlserver.kubedb.com/mssql-ag-cluster created +``` + +Now, wait until `mssql-ag-cluster` created has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +mssql-ag-cluster 2022-cu12 Ready 4m +``` + +We are now ready to apply the `MSSQLServerOpsRequest` CR to update this database. + +### Update MSSQLServer Version + +Here, we are going to update `MSSQLServer` ag cluster from `2022-cu12` to `2022-cu14`. + +#### Create MSSQLServerOpsRequest: + +In order to update the version of the mssql server ag cluster database, we have to create a `MSSQLServerOpsRequest` CR with your desired version that is supported by `KubeDB`. +Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-ag-cluster + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-ag-cluster + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-ag-cluster` MSSQLServer database. +- `spec.type` specifies that we are going to perform `UpdateVersion` on our database. +- `spec.updateVersion.targetVersion` specifies the expected version of the database `2022-cu14`. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/msops-update-ag-cluster .yaml +mssqlserveropsrequest.ops.kubedb.com/msops-update-ag-cluster created +``` + +#### Verify MSSQLServer version updated successfully + +If everything goes well, `KubeDB` Ops-manager operator will update the image of `MSSQLServer` object and related `PetSets` and `Pods`. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-update-ag-cluster UpdateVersion Successful 2m33s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to update the database version. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-update-ag-cluster +Name: msops-update-ag-cluster +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-12T13:38:04Z + Generation: 1 + Resource Version: 333751 + UID: f4977424-0ddc-40bc-a3b7-bc69f5ac6e82 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-ag-cluster + Timeout: 5m + Type: UpdateVersion + Update Version: + Target Version: 2022-cu14 +Status: + Conditions: + Last Transition Time: 2024-11-12T13:38:05Z + Message: MSSQLServer ops-request has started to update version + Observed Generation: 1 + Reason: UpdateVersion + Status: True + Type: UpdateVersion + Last Transition Time: 2024-11-12T13:38:28Z + Message: successfully reconciled the MSSQLServer with updated version + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-12T13:38:33Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-0 + Last Transition Time: 2024-11-12T13:38:33Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-0 + Last Transition Time: 2024-11-12T13:39:08Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-0 + Last Transition Time: 2024-11-12T13:39:13Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-1 + Last Transition Time: 2024-11-12T13:39:13Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-1 + Last Transition Time: 2024-11-12T13:39:48Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-1 + Last Transition Time: 2024-11-12T13:39:53Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-2 + Last Transition Time: 2024-11-12T13:39:53Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-2 + Last Transition Time: 2024-11-12T13:40:28Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-2 + Last Transition Time: 2024-11-12T13:40:33Z + Message: Successfully Restarted MSSQLServer pods + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-12T13:40:33Z + Message: Successfully updated MSSQLServer + Observed Generation: 1 + Reason: UpdateDatabase + Status: True + Type: UpdateDatabase + Last Transition Time: 2024-11-12T13:40:33Z + Message: Successfully updated MSSQLServer version + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 7m49s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-update-ag-cluster + Normal Starting 7m49s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 7m49s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-update-ag-cluster + Normal UpdatePetSets 7m26s KubeDB Ops-manager Operator successfully reconciled the MSSQLServer with updated version + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m21s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m21s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-0 7m16s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-0 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 6m46s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m41s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m41s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-1 6m36s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-1 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m6s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 6m1s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 6m1s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-2 5m56s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-2 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 5m26s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Normal RestartPods 5m21s KubeDB Ops-manager Operator Successfully Restarted MSSQLServer pods + Normal Starting 5m21s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 5m21s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-update-ag-cluster +``` + +Now, we are going to verify whether the `MSSQLServer` and the related `PetSets` and their `Pods` have the new version image. Let's check, + +```bash +$ kubectl get ms -n demo mssql-ag-cluster -o=jsonpath='{.spec.version}{"\n"}' +2022-cu14 + +$ kubectl get petset -n demo mssql-ag-cluster -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04@sha256:c1aa8afe9b06eab64c9774a4802dcd032205d1be785b1fd51e1c0151e7586b74 + +$ kubectl get pods -n demo mssql-ag-cluster-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 +``` + +You can see from above, our `MSSQLServer` ag database cluster has been updated with the new version. So, the updateVersion process is successfully completed. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo mssql-ag-cluster +kubectl delete msops -n demo msops-update-ag-cluster +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/update-version/overview.md b/docs/guides/mssqlserver/update-version/overview.md new file mode 100644 index 000000000..db2847c9b --- /dev/null +++ b/docs/guides/mssqlserver/update-version/overview.md @@ -0,0 +1,54 @@ +--- +title: Updating MSSQLServer Overview +menu: + docs_{{ .version }}: + identifier: ms-updating-overview + name: Overview + parent: mssql-updating + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Updating MSSQLServer version Overview + +This guide will give you an overview on how KubeDB Ops-manager operator update the version of `MSSQLServer` database. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + +## How update version Process Works + +The following diagram shows how KubeDB Ops-manager operator update the version of `MSSQLServer`. Open the image in a new tab to see the enlarged version. + +
+  updating Process of MSSQLServer +
Fig: Updating Process of MSSQLServer
+
+ +The updating process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource (CR). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CR. + +3. When the operator finds a `MSSQLServer` CR, it creates `PetSets` and related necessary resources like secrets, services, etc. + +4. Then, in order to update the version of the `MSSQLServer` the user creates a `MSSQLServerOpsRequest` CR with the desired version. + +5. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +6. When it finds a `MSSQLServerOpsRequest` CR, it halts the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the updating process. + +7. By looking at the target version from `MSSQLServerOpsRequest` CR, `KubeDB` Ops-manager operator updates the images of the `PetSet`. + +8. After successfully updating the `PetSet` and their `Pods` images, the `KubeDB` Ops-manager operator updates the image of the `MSSQLServer` object to reflect the updated state of the database. + +9. After successfully updating of `MSSQLServer` object, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator can resume its usual operations. + +In the next doc, we are going to show a step-by-step guide on updating of a MSSQLServer using UpdateVersion operation. \ No newline at end of file diff --git a/docs/guides/mssqlserver/update-version/standalone.md b/docs/guides/mssqlserver/update-version/standalone.md new file mode 100644 index 000000000..3fa059fd5 --- /dev/null +++ b/docs/guides/mssqlserver/update-version/standalone.md @@ -0,0 +1,306 @@ +--- +title: Updating MSSQLServer Standalone +menu: + docs_{{ .version }}: + identifier: ms-updating-standalone + name: Standalone + parent: mssql-updating + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Update Version of MSSQLServer Standalone + +This guide will show you how to use `KubeDB` Ops-manager operator to update the version of `MSSQLServer` standalone. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Updating Overview](/docs/guides/mssqlserver/update-version/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/update-version) directory of [kubedb/docs](https://github.com/kube/docs) repository. + +### Prepare MSSQLServer Standalone Database + +Now, we are going to deploy a `MSSQLServer` standalone database with version `2022-cu12`. + +### Deploy MSSQLServer Standalone + +In this section, we are going to deploy a MSSQLServer standalone database. Then, in the next section we will update the version of the database using `MSSQLServerOpsRequest` CR. + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + + +### Create MSSSQLServer + +Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/mssql-standalone.yaml +mssqlserver.kubedb.com/mssql-standalone created +``` + +Now, wait until `mssql-standalone` created has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +mssql-standalone 2022-cu12 Ready 3m8s +``` + +We are now ready to apply the `MSSQLServerOpsRequest` CR to update this database. + +### Update MSSQLServer Version + +Here, we are going to update `MSSQLServer` standalone from `2022-cu12` to `2022-cu14`. + +#### Create MSSQLServerOpsRequest: + +In order to update the standalone database, we have to create a `MSSQLServerOpsRequest` CR with our desired version that is supported by `KubeDB`. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-standalone + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-standalone + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-standalone` database. +- `spec.type` specifies that we are going to perform `UpdateVersion` on our database. +- `spec.updateVersion.targetVersion` specifies the expected version of the database `2022-cu14`. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml +mssqlserveropsrequest.ops.kubedb.com/msops-update-standalone created +``` + +#### Verify MSSQLServer version updated successfully : + +If everything goes well, `KubeDB` Ops-manager operator will update the image of `MSSQLServer` object and related `PetSets` and `Pods`. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-update-standalone UpdateVersion Successful 2m28s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to update the database. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-update-standalone +Name: msops-update-standalone +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-12T12:46:07Z + Generation: 1 + Resource Version: 328223 + UID: 7038611f-8ebe-4fb9-8f79-1d73e9669445 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-standalone + Timeout: 5m + Type: UpdateVersion + Update Version: + Target Version: 2022-cu14 +Status: + Conditions: + Last Transition Time: 2024-11-12T12:46:07Z + Message: MSSQLServer ops-request has started to update version + Observed Generation: 1 + Reason: UpdateVersion + Status: True + Type: UpdateVersion + Last Transition Time: 2024-11-12T12:46:16Z + Message: successfully reconciled the MSSQLServer with updated version + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-12T12:46:21Z + Message: get pod; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-standalone-0 + Last Transition Time: 2024-11-12T12:46:21Z + Message: evict pod; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-standalone-0 + Last Transition Time: 2024-11-12T12:48:16Z + Message: check pod running; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-standalone-0 + Last Transition Time: 2024-11-12T12:48:21Z + Message: Successfully Restarted MSSQLServer pods + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-12T12:48:21Z + Message: Successfully updated MSSQLServer + Observed Generation: 1 + Reason: UpdateDatabase + Status: True + Type: UpdateDatabase + Last Transition Time: 2024-11-12T12:48:21Z + Message: Successfully updated MSSQLServer version + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 2m42s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-update-standalone + Normal Starting 2m42s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-standalone + Normal Successful 2m42s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-standalone for MSSQLServerOpsRequest: msops-update-standalone + Normal UpdatePetSets 2m33s KubeDB Ops-manager Operator successfully reconciled the MSSQLServer with updated version + Warning get pod; ConditionStatus:True; PodName:mssql-standalone-0 2m28s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:mssql-standalone-0 2m28s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:mssql-standalone-0 2m23s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:mssql-standalone-0 33s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-standalone-0 + Normal RestartPods 28s KubeDB Ops-manager Operator Successfully Restarted MSSQLServer pods + Normal Starting 28s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-standalone + Normal Successful 28s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-standalone for MSSQLServerOpsRequest: msops-update-standalone +``` + +Now, we are going to verify whether the `MSSQLServer` and the related `PetSets` their `Pods` have the new version image. Let's check, + +```bash +$ kubectl get ms -n demo mssql-standalone -o=jsonpath='{.spec.version}{"\n"}' +2022-cu14 + +$ kubectl get petset -n demo mssql-standalone -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04@sha256:c1aa8afe9b06eab64c9774a4802dcd032205d1be785b1fd51e1c0151e7586b74 + +$ kubectl get pods -n demo mssql-standalone-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 +``` + +You can see from above, our `MSSQLServer` standalone database has been updated with the new version. So, the update process is successfully completed. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo mssql-standalone +kubectl delete msops -n demo msops-update-standalone +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` \ No newline at end of file