{"id":11747,"date":"2018-10-04T06:27:29","date_gmt":"2018-10-04T04:27:29","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/first-steps-into-sql-server-2019-availability-groups-on-k8s\/"},"modified":"2018-10-04T06:27:29","modified_gmt":"2018-10-04T04:27:29","slug":"first-steps-into-sql-server-2019-availability-groups-on-k8s","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/first-steps-into-sql-server-2019-availability-groups-on-k8s\/","title":{"rendered":"First steps into SQL Server 2019 availability groups on K8s"},"content":{"rendered":"

A couple of weeks ago, Microsoft announced the first public CTP version of next SQL Server version\u00a0(CTP2)<\/a>. It is not a surprise, the SQL Server vNext becomes SQL Server 2019 and there are a plenty of enhancements as well as new features to discover. But for now, let\u2019s start with likely one of my favorites: availability groups on Kurbernetes (aka K8s). As far I may see from customers and hear from my colleagues as well, we assist to a strong adoption of K8s with OpenShift as a main driver. I would not be surprised to see some SQL Server pods at customer shops in a near future, especially with the support of availability groups on K8s. From my opinion, that is definitely something that was missing in the previous for microservices architectures or not, for either quality or production environments.<\/p>\n

\"blog<\/a><\/p>\n

Well, I decided to learn more about this new feature but let\u2019s say this write-up concerns the CTP 2.0 version and chances are things will likely change in the future. So, don\u2019t focus strictly on my words or commands I\u2019m using in this blog post.<\/p>\n

It is some time since I used the Service Azure Kubernetes (AKS) and I already wrote about it in a previous blog post<\/a>. I used the same environment to deploy my first availability group on K8s. It was definitely an interesting experience because it involved getting technical skills about K8s infrastructure.<\/p>\n

So, let\u2019s set briefly the context with my K8s cluster on Azure that is composed of 3 agent nodes as shown below:<\/p>\n

$ kubectl get nodes -o wide\nNAME                       STATUS    ROLES     AGE       VERSION   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME\naks-nodepool1-78763348-0   Ready     agent     126d      v1.9.6    <none>        Ubuntu 16.04.4 LTS   4.13.0-1016-azure   docker:\/\/1.13.1\naks-nodepool1-78763348-1   Ready     agent     126d      v1.9.6    <none>        Ubuntu 16.04.4 LTS   4.13.0-1016-azure   docker:\/\/1.13.1\naks-nodepool1-78763348-2   Ready     agent     35d       v1.9.6    <none>        Ubuntu 16.04.5 LTS   4.15.0-1023-azure   docker:\/\/1.13.1<\/pre>\n
 <\/p>\n
I also used a custom namespace – agdev – to scope my availability group resources names.<\/p>\n
$ kubectl get ns\nNAME           STATUS        AGE\nag1            Terminating   23h\nagdev          Active        10h\nazure-system   Active        124d\ndefault        Active        124d\nkube-public    Active        124d\nkube-system    Active        124d<\/pre>\n
 <\/p>\n
Referring to the Microsoft documentation<\/a>, the SQL secrets (including master key and SA password secrets) are ready for use:<\/p>\n
$ kubectl get secret sql-secrets -n agdev\nNAME                   TYPE                                  DATA      AGE\nsql-secrets            Opaque                                2         1d\n\n$ kubectl describe secret sql-secrets -n agdev\nName:         sql-secrets\nNamespace:    default\nLabels:       <none>\nAnnotations:  <none>\n\nType:  Opaque\n\nData\n====\nmasterkeypassword:  14 bytes\nsapassword:         14 bytes<\/pre>\n
 <\/p>\n