A really handy feature in Kubernetes is port forwarding. This can be used to narrow down an issue when connections are failing to SQL Server running in a cluster.
Say we have deployed the following to a Kubernetes cluster: –
apiVersion: apps/v1beta1 kind: Deployment metadata: name: sqlserver spec: replicas: 1 template: metadata: labels: name: sqlserver spec: containers: - name: sqlserver1 image: mcr.microsoft.com/mssql/server:2019-RC1-ubuntu ports: - containerPort: 1433 env: - name: SA_PASSWORD value: "Testing1122" - name: ACCEPT_EULA value: "Y" --- apiVersion: v1 kind: Service metadata: name: sqlserver-service spec: ports: - name: sqlserver port: 1433 targetPort: 1433 selector: name: sqlserver type: LoadBalancer
This will create the following in the Kubernetes cluster: –
The load balanced service’s IP can be usually be used to connect into the SQL instance running in the pod, but what if we’re unable to connect? Does the issue lie with the service or the pod?
In order to narrow this down, port forwarding can be used to directly connect to the pod: –
kubectl port-forward pod/sqlserver-889b56d7b-nb2b4 15789:1433
This will allow us to use 127.0.0.1,15789 (localhost won’t work) and connect from our local machine to the pod running in the Kubernetes cluster (in a separate window): –
mssql-cli -S 127.0.0.1,15789 -U sa
We can use the same port to connect via ADS and SSMS as well: –
If a connection can be established to the pod via the forwarded port then we know that the issue doesn’t lie with the pod but with the service or the connection from the service to the pod.
Thanks for reading!