SQL Server pods with PersistentVolumeClaim - sql-server

This is the scenario: a SQL Server linux kubernetes setup with minikube.
It runs fine with default settings, databases/tables are created no problem.
But the database files should not be stored within the container so a PersistentVolumeClaim was added and the pod config changed to use the claim and mount /var/opt/mssql to /sqldata on the minikube VM.
apiVersion: v1
kind: PersistentVolume
metadata:
name: sqldata
spec:
capacity:
storage: 1Gi
storageClassName: sqlserver
accessModes:
- ReadWriteMany
hostPath:
path: "/sqldata"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: dbclaim
spec:
accessModes:
- ReadWriteMany
storageClassName: sqlserver
resources:
requests:
storage: 1Gi
apiVersion: v1
kind: Pod
spec:
initContainers:
- name: volume-permissions
image: busybox
command: ["sh", "-c", "chown -R 10001:0 /var/opt/mssql"]
volumeMounts:
- mountPath: "/var/opt/mssql"
name: sqldata-storage
volumes:
- name: sqldata-storage
persistentVolumeClaim:
claimName: dbclaim
containers:
- image: mcr.microsoft.com/mssql/server
name: foo
env:
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
valueFrom:
secretKeyRef:
name: sql-password
key: sa_password
- name: MSSQL_PID
value: Developer
volumeMounts:
- mountPath: "/var/opt/mssql/data"
name: sqldata-storage
Also tried image: microsoft/mssql-server-linux
chown -R 10001:0 /var/opt/mssql
is called in initcontainer to give mssql user access to the host VM's directory.
But what happens now is that the sql server pod starts up and after a minute or two it stops with a CrashloopBackoff.
The logfile from the pod says:
2020-08-02 14:33:57.55 Server Registry startup parameters:
-d /var/opt/mssql/data/master.mdf
-l /var/opt/mssql/data/mastlog.ldf
-e /var/opt/mssql/log/errorlog 2020-08-02 14:33:57.78 Server Error 87(The parameter is incorrect.) occurred while opening file
'/var/opt/mssql/data/master.mdf' to obtain configuration information
at startup. An invalid startup option might have caused the error.
Verify your startup options, and correct or remove them if necessary
Logging into the minikube VM, it looks like sql server does have access as the master table etc is created in the actual mounted directory although only owner permissions are set which is 10001:
$ ls -l /sqldata
-rw-r----- 1 10001 root 4194304 Aug 9 06:51 master.mdf
What to check for to get it running like this?

I have managed to run this. The only thing that I changed from your spec is removing the storageclassName from the Persistent Volume and PersistentVolumeClaim. This is because I didn't have a storage class created so not specifying the storage class will use the default one.
Here is yaml I run.
#pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: sqldata
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
hostPath:
path: "/sqldata"
#pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: dbclaim
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
#sqlserver.yaml
apiVersion: v1
kind: Pod
metadata:
name: sqlserver
spec:
initContainers:
- name: volume-permissions
image: busybox
command: ["sh", "-c", "chown -R 10001:0 /var/opt/mssql"]
volumeMounts:
- mountPath: "/var/opt/mssql"
name: sqldata-storage
volumes:
- name: sqldata-storage
persistentVolumeClaim:
claimName: dbclaim
containers:
- image: mcr.microsoft.com/mssql/server
name: foo
volumeMounts:
- mountPath: "/var/opt/mssql/data"
name: sqldata-storage
env:
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
valueFrom:
secretKeyRef:
name: sql-password
key: sa_password
- name: MSSQL_PID
value: Developer
This is how I created a secret
kubectl create secret generic sql-password --from-literal=sa_password=Passw0rd
Here is the output of describing the pod.
vagrant#kubemaster:~$ kubectl describe pod sqlserver
Name: sqlserver
Namespace: default
Priority: 0
Node: kubenode02/192.168.56.4
Start Time: Thu, 13 Aug 2020 20:10:06 +0000
Labels: <none>
Annotations: <none>
Status: Running
IP: 10.36.0.2
IPs:
IP: 10.36.0.2
Init Containers:
volume-permissions:
Container ID: docker://dbc81ddda15aa5af4b56085ee1923b530f1154ba147c589dcc76fb80121c2d0a
Image: busybox
Image ID: docker-pullable://busybox#sha256:4f47c01fa91355af2865ac10fef5bf6ec9c7f42ad2321377c21e844427972977
Port: <none>
Host Port: <none>
Command:
sh
-c
chown -R 10001:0 /var/opt/mssql
State: Terminated
Reason: Completed
Exit Code: 0
Started: Thu, 13 Aug 2020 20:10:11 +0000
Finished: Thu, 13 Aug 2020 20:10:11 +0000
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/opt/mssql from sqldata-storage (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-w9t6t (ro)
Containers:
foo:
Container ID: docker://f43e9321d85daa1b5695dc2944f42a4e12db34b97ba0f333d8a8b9afeace0f31
Image: mcr.microsoft.com/mssql/server
Image ID: docker-pullable://mcr.microsoft.com/mssql/server#sha256:1a69a5e5f7b00feae9edab6bd72e2f6fd5bbb4e74e4ca46e3cc46f1b911e1305
Port: <none>
Host Port: <none>
State: Running
Started: Thu, 13 Aug 2020 20:10:14 +0000
Ready: True
Restart Count: 0
Environment:
ACCEPT_EULA: Y
SA_PASSWORD: <set to the key 'sa_password' in secret 'sql-password'> Optional: false
MSSQL_PID: Developer
Mounts:
/var/opt/mssql/data from sqldata-storage (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-w9t6t (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
sqldata-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: dbclaim
ReadOnly: false
default-token-w9t6t:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-w9t6t
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned default/sqlserver to kubenode02
Normal Pulling 84s kubelet, kubenode02 Pulling image "busybox"
Normal Pulled 80s kubelet, kubenode02 Successfully pulled image "busybox"
Normal Created 80s kubelet, kubenode02 Created container volume-permissions
Normal Started 80s kubelet, kubenode02 Started container volume-permissions
Normal Pulling 79s kubelet, kubenode02 Pulling image "mcr.microsoft.com/mssql/server"
Normal Pulled 78s kubelet, kubenode02 Successfully pulled image "mcr.microsoft.com/mssql/server"
Normal Created 78s kubelet, kubenode02 Created container foo
Normal Started 77s kubelet, kubenode02 Started container foo
vagrant#kubemaster:~$
And here is logs from the pod.
vagrant#kubemaster:~$ kubectl logs sqlserver
SQL Server 2019 will run as non-root by default.
This container is running as user mssql.
Your master database file is owned by mssql.
To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
2020-08-13 20:10:17.89 Server Setup step is FORCE copying system data file 'C:\templatedata\model_replicatedmaster.mdf' to '/var/opt/mssql/data/model_replicatedmaster.mdf'.
2020-08-13 20:10:17.96 Server Setup step is FORCE copying system data file 'C:\templatedata\model_replicatedmaster.ldf' to '/var/opt/mssql/data/model_replicatedmaster.ldf'.
2020-08-13 20:10:17.96 Server Setup step is FORCE copying system data file 'C:\templatedata\model_msdbdata.mdf' to '/var/opt/mssql/data/model_msdbdata.mdf'.
2020-08-13 20:10:17.97 Server Setup step is FORCE copying system data file 'C:\templatedata\model_msdblog.ldf' to '/var/opt/mssql/data/model_msdblog.ldf'.
2020-08-13 20:10:18.06 Server Microsoft SQL Server 2019 (RTM-CU6) (KB4563110) - 15.0.4053.23 (X64)
Jul 25 2020 11:26:55
Copyright (C) 2019 Microsoft Corporation
Developer Edition (64-bit) on Linux (Ubuntu 18.04.4 LTS) <X64>
2020-08-13 20:10:18.07 Server UTC adjustment: 0:00
2020-08-13 20:10:18.07 Server (c) Microsoft Corporation.
2020-08-13 20:10:18.07 Server All rights reserved.
2020-08-13 20:10:18.07 Server Server process ID is 36.
2020-08-13 20:10:18.07 Server Logging SQL Server messages in file '/var/opt/mssql/log/errorlog'.
2020-08-13 20:10:18.07 Server Registry startup parameters:
-d /var/opt/mssql/data/master.mdf
-l /var/opt/mssql/data/mastlog.ldf
-e /var/opt/mssql/log/errorlog
2020-08-13 20:10:18.08 Server SQL Server detected 1 sockets with 2 cores per socket and 2 logical processors per socket, 2 total logical processors; using 2 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
2020-08-13 20:10:18.09 Server SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required.
2020-08-13 20:10:18.09 Server Detected 1594 MB of RAM. This is an informational message; no user action is required.
2020-08-13 20:10:18.09 Server Using conventional memory in the memory manager.
2020-08-13 20:10:18.09 Server Page exclusion bitmap is enabled.
2020-08-13 20:10:18.12 Server Buffer pool extension is not supported on Linux platform.
2020-08-13 20:10:18.12 Server Buffer Pool: Allocating 262144 bytes for 180348 hashPages.
2020-08-13 20:10:18.34 Server Buffer pool extension is already disabled. No action is necessary.
2020-08-13 20:10:18.90 Server Successfully initialized the TLS configuration. Allowed TLS protocol versions are ['1.0 1.1 1.2']. Allowed TLS ciphers are ['ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA'].
2020-08-13 20:10:18.94 Server Query Store settings initialized with enabled = 1,
2020-08-13 20:10:18.96 Server The maximum number of dedicated administrator connections for this instance is '1'
2020-08-13 20:10:18.97 Server Node configuration: node 0: CPU mask: 0x0000000000000003:0 Active CPU mask: 0x0000000000000003:0. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.
2020-08-13 20:10:18.98 Server Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required.
2020-08-13 20:10:19.01 Server In-Memory OLTP initialized on lowend machine.
2020-08-13 20:10:19.05 Server [INFO] Created Extended Events session 'hkenginexesession'
2020-08-13 20:10:19.06 Server Database Instant File Initialization: enabled. For security and performance considerations see the topic 'Database Instant File Initialization' in SQL Server Books Online. This is an informational message only. No user action is required.
ForceFlush is enabled for this instance.
2020-08-13 20:10:19.09 Server Total Log Writer threads: 1. This is an informational message; no user action is required.
2020-08-13 20:10:19.12 Server clflushopt is selected for pmem flush operation.
2020-08-13 20:10:19.14 Server Software Usage Metrics is disabled.
2020-08-13 20:10:19.16 Server CLR version v4.0.30319 loaded.
2020-08-13 20:10:19.18 spid8s [1]. Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-08-13 20:10:19.18 spid8s Starting up database 'master'.
ForceFlush feature is enabled for log durability.
2020-08-13 20:10:19.61 Server Common language runtime (CLR) functionality initialized.
2020-08-13 20:10:19.76 spid8s Service Master Key could not be decrypted using one of its encryptions. See sys.key_encryptions for details.
2020-08-13 20:10:19.77 spid8s An error occurred during Service Master Key initialization. SQLErrorCode=33095, State=8, LastOsError=0.
2020-08-13 20:10:19.91 spid8s Resource governor reconfiguration succeeded.
2020-08-13 20:10:19.91 spid8s SQL Server Audit is starting the audits. This is an informational message. No user action is required.
2020-08-13 20:10:19.92 spid8s SQL Server Audit has started the audits. This is an informational message. No user action is required.
2020-08-13 20:10:20.00 spid8s SQL Trace ID 1 was started by login "sa".
2020-08-13 20:10:20.03 spid8s Server name is 'sqlserver'. This is an informational message only. No user action is required.
2020-08-13 20:10:20.07 spid23s Always On: The availability replica manager is starting. This is an informational message only. No user action is required.
2020-08-13 20:10:20.08 spid23s Always On: The availability replica manager is waiting for the instance of SQL Server to allow client connections. This is an informational message only. No user action is required.
2020-08-13 20:10:20.08 spid8s [4]. Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-08-13 20:10:20.11 spid10s [32767]. Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-08-13 20:10:20.12 spid8s Starting up database 'msdb'.
2020-08-13 20:10:20.13 spid10s Starting up database 'mssqlsystemresource'.
2020-08-13 20:10:20.14 spid10s The resource database build version is 15.00.4053. This is an informational message only. No user action is required.
2020-08-13 20:10:20.19 spid22s A self-generated certificate was successfully loaded for encryption.
2020-08-13 20:10:20.21 spid22s Server is listening on [ 0.0.0.0 <ipv4> 1433].
2020-08-13 20:10:20.22 Server Server is listening on [ ::1 <ipv6> 1434].
2020-08-13 20:10:20.22 Server Server is listening on [ 127.0.0.1 <ipv4> 1434].
2020-08-13 20:10:20.23 Server Dedicated admin connection support was established for listening locally on port 1434.
2020-08-13 20:10:20.25 spid22s Server is listening on [ ::1 <ipv6> 1431].
2020-08-13 20:10:20.25 spid10s [3]. Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-08-13 20:10:20.26 spid22s Server is listening on [ 127.0.0.1 <ipv4> 1431].
2020-08-13 20:10:20.26 spid10s Starting up database 'model'.
2020-08-13 20:10:20.28 spid22s SQL Server is now ready for client connections. This is an informational message; no user action is required.
2020-08-13 20:10:20.57 spid10s Clearing tempdb database.
2020-08-13 20:10:20.94 spid10s [2]. Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-08-13 20:10:20.95 spid10s Starting up database 'tempdb'.
2020-08-13 20:10:21.21 spid10s The tempdb database has 1 data file(s).
2020-08-13 20:10:21.22 spid23s The Service Broker endpoint is in disabled or stopped state.
2020-08-13 20:10:21.23 spid23s The Database Mirroring endpoint is in disabled or stopped state.
2020-08-13 20:10:21.24 spid8s Recovery is complete. This is an informational message only. No user action is required.
2020-08-13 20:10:21.26 spid23s Service Broker manager has started.
vagrant#kubemaster:~$
Here is how I checked if the persistent volume works by creating the test file "test file" inside the mounted path /var/opt/mysql/data and delete the pod and created it again. You can still find the test file I created in the same path.
vagrant#kubemaster:~$ kubectl exec -ti sqlserver -- /bin/bash
mssql#sqlserver:/$
mssql#sqlserver:/$ cd /var/opt/mssql/data/
mssql#sqlserver:/var/opt/mssql/data$ ls -lrt
total 72068
-rw-r----- 1 mssql root 256 Aug 13 19:28 Entropy.bin
-rw-r----- 1 mssql root 14090240 Aug 13 20:06 msdbdata.mdf
-rw-r----- 1 mssql root 4194304 Aug 13 20:10 model_replicatedmaster.mdf
-rw-r----- 1 mssql root 524288 Aug 13 20:10 model_replicatedmaster.ldf
-rw-r----- 1 mssql root 14090240 Aug 13 20:10 model_msdbdata.mdf
-rw-r----- 1 mssql root 524288 Aug 13 20:10 model_msdblog.ldf
-rw-r----- 1 mssql root 4194304 Aug 13 20:10 master.mdf
-rw-r----- 1 mssql root 524288 Aug 13 20:10 msdblog.ldf
-rw-r----- 1 mssql root 8388608 Aug 13 20:10 modellog.ldf
-rw-r----- 1 mssql root 8388608 Aug 13 20:10 model.mdf
-rw-r----- 1 mssql root 8388608 Aug 13 20:10 templog.ldf
-rw-r----- 1 mssql root 8388608 Aug 13 20:10 tempdb.mdf
-rw-r----- 1 mssql root 2097152 Aug 13 20:10 mastlog.ldf
mssql#sqlserver:/var/opt/mssql/data$
mssql#sqlserver:/var/opt/mssql/data$ touch testfile
mssql#sqlserver:/var/opt/mssql/data$ exit
exit
vagrant#kubemaster:~$ kubectl delete pod sqlserver
pod "sqlserver" deleted
vagrant#kubemaster:~$ kubectl create -f sqlserver.yaml
pod/sqlserver created
vagrant#kubemaster:~$
vagrant#kubemaster:~$ kubectl exec -ti sqlserver -- /bin/bash
mssql#sqlserver:/$
mssql#sqlserver:/$ ls -lrt /var/opt/mssql/data/
total 72068
-rw-r----- 1 mssql root 256 Aug 13 19:28 Entropy.bin
-rw-r--r-- 1 mssql root 0 Aug 13 20:17 testfile
-rw-r----- 1 mssql root 14090240 Aug 13 20:17 msdbdata.mdf
-rw-r----- 1 mssql root 4194304 Aug 13 20:18 model_replicatedmaster.mdf
-rw-r----- 1 mssql root 524288 Aug 13 20:18 model_replicatedmaster.ldf
-rw-r----- 1 mssql root 14090240 Aug 13 20:18 model_msdbdata.mdf
-rw-r----- 1 mssql root 524288 Aug 13 20:18 model_msdblog.ldf
-rw-r----- 1 mssql root 4194304 Aug 13 20:18 master.mdf
-rw-r----- 1 mssql root 524288 Aug 13 20:18 msdblog.ldf
-rw-r----- 1 mssql root 8388608 Aug 13 20:18 modellog.ldf
-rw-r----- 1 mssql root 8388608 Aug 13 20:18 model.mdf
-rw-r----- 1 mssql root 8388608 Aug 13 20:18 templog.ldf
-rw-r----- 1 mssql root 8388608 Aug 13 20:18 tempdb.mdf
-rw-r----- 1 mssql root 2097152 Aug 13 20:18 mastlog.ldf
mssql#sqlserver:/$
mssql#sqlserver:/$ exit
exit
vagrant#kubemaster:~$

The problem is in your mountPath.
Can you please try and change it to /var/opt/mssql/data?
containers:
- image: mcr.microsoft.com/mssql/server
name: foo
volumeMounts:
- mountPath: "/var/opt/mssql/data"
name: sqldata-storage

I could not comment but, creating a PV and PVC without the storageClassName breaks the link between the two constructs, you will note that the PVC will create a dynamic PV that is then bound to the default Storage Class. This is especially true when running docker desktop with kubernetes turned on as the orchestrator. I had the same issue on my local install where I wanted to run everything hosted out of docker.

Related

Login failed for user SA, when connecting to SQL Server Docker container, deployed in Kubernetes

I'm following this tutorial on Microservices
https://www.youtube.com/watch?v=DgVjEo3OGBI
At some point, I deploy a SQL Server image in Kubernetes, using this Yaml file:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mssql-depl
spec:
replicas: 1
selector:
matchLabels:
app: mssql
template:
metadata:
labels:
app: mssql
spec:
containers:
- name: mssql
image: mcr.microsoft.com/mssql/server:2019-latest
ports:
- containerPort: 1433
env:
- name: MSSQL_PID
value: "Express"
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
valueFrom:
secretKeyRef:
name: mssql5
key: SA_PASSWORD
volumeMounts:
- mountPath: /var/opt/mssql/data
name: mssqldb
volumes:
- name: mssqldb
persistentVolumeClaim:
claimName: mssql-claim
---
apiVersion: v1
kind: Service
metadata:
name: mssql-clusterip-srv
spec:
type: ClusterIP
selector:
app: mssql
ports:
- name: mssql
protocol: TCP
port: 1433
targetPort: 1433
---
apiVersion: v1
kind: Service
metadata:
name: mssql-loadbalancer
spec:
type: LoadBalancer
selector:
app: mssql
ports:
- protocol: TCP
port: 1433
targetPort: 1433
And the PVC.yaml:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mssql-claim
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 200Mi
I then create a secret in Kubernets, holding the password for the SQL Server sa account, and this secret is then used in the Yaml file.
kubectl create secret generic mssql5 --from-literal=SA_PASSWORD="MyC0m9l&xPassw0rd"
It should then be possible to connect directly to the SQL Server container on localhost port 1433, using the sa account and the password.
However, I get the "Login failed for user SA" error when trying to connect. I've tried everything, including changing SA_PASSWORD to MSSQL_SA_PASSWORD, changing the complexity of the password, enabling login for the sa user in SQL Server, which was disabled before and googled like I've never googled before. TCP/IP setting is enabled in SQL Server configuration manager. I cannot get access. Can anyone shed some light on this issue?
if you turn off that service then it will work
TL;DR The solution to this particular problem was that https://stackoverflow.com/users/52045/soeren had an instance of SQL Server running on their computer that intercepted port 1433 requests before hitting K8s. Disabling the SQL Server instance on computer solved the problem and port 1433 traffic routed to K8s load balancer.
Original solution follows...
I have copy/pasted your YAML verbatim above into files deployment.yaml and pvc.yaml respectively and then run these commands.
kubectl create -f pvc.yaml
kubectl create secret generic mssql5 --from-literal=SA_PASSWORD="MyC0m9l&xPassw0rd"
kubectl create -f deployment.yaml
I can connect via localhost and create database.
Conclusion is that your YAML looks fine.
If I then delete/create the deployment again...
kubectl delete -f deployment.yaml
kubectl create-f deployment.yaml
..the SSMS connection still works and the Test database persists.
The only change I would personally make is from - mountPath: /var/opt/mssql/data to - mountPath: /var/opt/mssql/ in deployment.yaml so that your entire mssql path is persisted.
As you are including the /data folder this means that the logs and secrets folders are still within the POD and not the persisted volume. This might explain the ldf log file permissions issue you mentioned above?
So, next I investigated the persisted volume kubectl describe pv and on my system it is showing the following:
Type: HostPath (bare host directory volume)
Path: /var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4
I'm guessing you are using hostPath, which will store the files on the containing node/host. I'm using Docker Kubernetes as opposed to minikube. A single node cluster.
If you shell into the node (as opposed to the POD) as root thus:
docker run -it --rm --privileged --pid=host justincormack/nsenter1
You can cd /var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4 to see the mounted volume for your persisted volume claim.
You should see something like:
/ # cd /var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4
/var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4 # ls -l
total 89348
-rw-r----- 1 10001 root 256 Feb 14 17:33 Entropy.bin
-rw-r----- 1 10001 root 8388608 Feb 14 17:36 Test.mdf
-rw-r----- 1 10001 root 8388608 Feb 14 17:55 Test_log.ldf
-rw-r----- 1 10001 root 4653056 Feb 14 17:54 master.mdf
-rw-r----- 1 10001 root 2097152 Feb 14 18:00 mastlog.ldf
-rw-r----- 1 10001 root 8388608 Feb 14 17:49 model.mdf
-rw-r----- 1 10001 root 14090240 Feb 14 17:49 model_msdbdata.mdf
-rw-r----- 1 10001 root 524288 Feb 14 17:49 model_msdblog.ldf
-rw-r----- 1 10001 root 524288 Feb 14 17:49 model_replicatedmaster.ldf
-rw-r----- 1 10001 root 4653056 Feb 14 17:49 model_replicatedmaster.mdf
-rw-r----- 1 10001 root 8388608 Feb 14 17:49 modellog.ldf
-rw-r----- 1 10001 root 14090240 Feb 14 17:36 msdbdata.mdf
-rw-r----- 1 10001 root 524288 Feb 14 17:49 msdblog.ldf
-rw-r----- 1 10001 root 8388608 Feb 14 17:49 tempdb.mdf
-rw-r----- 1 10001 root 8388608 Feb 14 17:55 templog.ldf
If you had mapped mssql only above you will see data, logs and secrets subdirectories.
Obviously, replace your PVC with your name.
So again, in conclusion your YAML looks fine. I therefore suspect that you have got something lingering around from previous attempts.
The only other issue that has cropped up with me is that sometimes it's better to use single quotes with PowerShell and double quotes with cmd prompt.
Have you checked your pods are running OK and that the config is being read OK? (replace pod id with yours)
kubectl get pods
kubectl describe pod mssql-depl-7777487cf7-w9gj5
Beyond that...I'm sure it's something to do with what's been left behind from previous testing that needs to be cleaned up.
Original answer below for completeness...
Have you tried clearing everything down (using a namespace makes this easier).
I have noticed that if you're using a persisted volume claim the master.mdf may hold an old password (SELECT * FROM master.dbo.syslogins) as the master.mdf isn't recreated fresh as it would be with a non persisted volume.
As an experiment, when I had everything working, I deleted the deployment but left the persisted volume claim.
I deleted the SA_PASSWORD secret and recreated it with a different password and then applied the deployment again.
I was able to connect to SQL from SSMS on 1433 using the old password even though the new POD contained the new password in the environment variable SA_PASSWORD.
In conclusion, I would try to clear your persisted volume claim and start again so that the master/msdb databases are recreated.
It's worth a try?
Incidentally, NodePort is all you need and not ClusterIP and LoadBalancer for your service (this obviously depends on your cluster environment. I presumed you're using minikube or local Docker?)

Kubernetes not waiting for reactjs to load

I have a GKE cluster. I am trying to deploy a reactjs frontend app but it seems like kubernetes is restarting the pod before it can totally load. I can run the container manually with docker and the app loads successfully but it takes a long time to load (10 minutes) I think because I am using the most basic servers in GCP.
I am trying to use probes for kubernetes to wait until app is app and running. I can not make it work. Is there any other way to tell kubernetes to wait for app startup? Thank you
this is my deploy file:
kind: Deployment
metadata:
labels:
app: livenessprobe
name: livenessprobe
spec:
replicas: 1
selector:
matchLabels:
app: livenessprobe
template:
metadata:
labels:
app: livenessprobe
spec:
containers:
- image: mychattanooga:v1
name: mychattanooga
livenessProbe:
httpGet:
path: /healthz
port: 3000
initialDelaySeconds: 99
periodSeconds: 30
resources: {}
The pod restart every 5 seconds or so and then I get crashLoopBackOff and restarts again .....
kubectl get events:
assigned default/mychattanooga-85f44599df-t6tnr to gke-cluster-2-default-pool-054176ff-wsp6
13m Normal Pulled pod/mychattanooga-85f44599df-t6tnr Container im
age "#####/mychattanooga#sha256:03dd2d6ef44add5c9165410874cee9155af645f88896e5d5cafb883265c
3d4c9" already present on machine
13m Normal Created pod/mychattanooga-85f44599df-t6tnr Created cont
ainer mychattanooga-sha256-1
13m Normal Started pod/mychattanooga-85f44599df-t6tnr Started cont
ainer mychattanooga-sha256-1
13m Warning BackOff pod/mychattanooga-85f44599df-t6tnr Back-off res
tarting failed container
kubectl describe pod:
Name: livenessprobe-5f9b566f76-dqk5s
Namespace: default
Priority: 0
Node: gke-cluster-2-default-pool-054176ff-wsp6/10.142.0.2
Start Time: Wed, 01 Jul 2020 04:01:22 -0400
Labels: app=livenessprobe
pod-template-hash=5f9b566f76
Annotations: kubernetes.io/limit-ranger: LimitRanger plugin set: cpu request for container mychattanooga
Status: Running
IP: 10.36.0.58
IPs: <none>
Controlled By: ReplicaSet/livenessprobe-5f9b566f76
Containers:
mychattanooga:
Container ID: docker://cf33dafd0bb21fa7ddc86d96f7a0445d6d991e3c9f0327195db355f1b3aca526
Image: #####/mychattanooga:v1
Image ID: docker-pullable://gcr.io/operational-datastore/mychattanooga#sha256:03dd2d6ef44add5c9165410874
cee9155af645f88896e5d5cafb883265c3d4c9
Port: <none>
Host Port: <none>
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Started: Wed, 01 Jul 2020 04:04:35 -0400
Finished: Wed, 01 Jul 2020 04:04:38 -0400
Ready: False
Restart Count: 5
Requests:
cpu: 100m
Liveness: http-get http://:3000/healthz delay=999s timeout=1s period=300s #success=1 #failure=3
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-zvncw (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
default-token-zvncw:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-zvncw
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4m46s default-scheduler Successfully assi
gned default/livenessprobe-5f9b566f76-dqk5s to gke-cluster-2-default-pool-054176ff-wsp6
Normal Pulled 3m10s (x5 over 4m45s) kubelet, gke-cluster-2-default-pool-054176ff-wsp6 Container image "
#######/mychattanooga:v1" already present on machine
Normal Created 3m10s (x5 over 4m45s) kubelet, gke-cluster-2-default-pool-054176ff-wsp6 Created container
mychattanooga
Normal Started 3m10s (x5 over 4m45s) kubelet, gke-cluster-2-default-pool-054176ff-wsp6 Started container
mychattanooga
Warning BackOff 2m43s (x10 over 4m38s) kubelet, gke-cluster-2-default-pool-054176ff-wsp6 Back-off restarti
ng failed container
this is my Dcokerfile:
FROM node:latest
# Copy source code
COPY source/ /opt/app
# Change working directory
WORKDIR /opt/app
# install stuff
RUN npm install
# Expose API port to the outside
EXPOSE 3000
# Launch application
CMD ["npm", "start"]
From the docs here you can protect slow starting containers with startup probes.
Sometimes, you have to deal with legacy applications that might require an additional startup time on their first initialization. In such cases, it can be tricky to set up liveness probe parameters without compromising the fast response to deadlocks that motivated such a probe. The trick is to set up a startup probe with the same command, HTTP or TCP check, with a failureThreshold * periodSeconds long enough to cover the worse case startup time
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
I got it working by downgrading to react-scripts 3.4.0
The crashLoopBackOff was caused by webpackDevServer Issue
After downgrading, I added these fields in deployment container
stdin: true
tty: true
I hope you got it working.
Add this to your deployment file
containers:
- image: mychattanooga:v1
name: mychattanooga
readinessProbe:
tcpSocket:
port: 3000
initialDelaySeconds: 20
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 3
livenessProbe:
tcpSocket:
port: 3000
initialDelaySeconds: 15
periodSeconds: 20

User and database are not initialised though environment variables while deploying postgres in kubernetes

When I am trying to deploy postgres over kubernetes, I have populated all the required environment variables such as POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DATABASE, etc. through the creation of configmap and secret files. Container is successfully deployed and I can open into its terminal through the 'kubectl exec' command. When I run the 'env' command, it is seen that all the environment variables supplied during deployment are successfully set accordingly. But when I try to run :
psql -U testuser -d testdb
It gives two types of errors:
psql: could not connect to server: FATAL: role 'testuser' does not exist
psql: could not connect to server: FATAL: database 'testdb' does not exist
After doing a lot of research, I found that even after setting the environment variables, the user and database do not get initialised. Therefore, I created an init.sql file and added it to docker-entrypoint-initdb.d to build a custom image, push it to docker hub and deploy postgres through that image in kubernetes.
init.sql file content:
CREATE USER testuser WITH SUPERUSER PASSWORD test;
CREATE DATABASE testdb;
GRANT ALL PRIVILEGES ON DATABASE testdb TO testuser;
Dockerfile content:
FROM postgres:latest
ADD init.sql /docker-entrypoint-initdb.d/
EXPOSE 5432
Still, I get the same error. user and database are not getting initialised... please help me out with this
UPDATE:
Logs:
PostgreSQL Database directory appears to contain a database; Skipping initialization
2020-04-15 09:50:06.855 UTC [1] LOG: starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2020-04-15 09:50:06.855 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2020-04-15 09:50:06.855 UTC [1] LOG: listening on IPv6 address "::", port 5432
2020-04-15 09:50:07.000 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2020-04-15 09:50:07.204 UTC [26] LOG: database system was interrupted; last known up at 2020-04-15 09:50:02 UTC
2020-04-15 09:50:07.781 UTC [26] LOG: database system was not properly shut down; automatic recovery in progress
2020-04-15 09:50:07.815 UTC [26] LOG: invalid record length at 0/16453B0: wanted 24, got 0
2020-04-15 09:50:07.815 UTC [26] LOG: redo is not required
2020-04-15 09:50:08.034 UTC [1] LOG: database system is ready to accept connections
Here, it is already mentioned 'Skipping initialisation'
can you try with this shell script ? file name : init-user-db.sh
#!/bin/bash
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-EOSQL
CREATE USER docker;
CREATE DATABASE docker;
GRANT ALL PRIVILEGES ON DATABASE docker TO docker;
EOSQL
Docker file something like this
FROM postgres:latest
ADD init-user-db.sh /docker-entrypoint-initdb.d/init-user-db.sh
EXPOSE 5432
EDIT : 1
apiVersion: apps/v1
kind: StatefulSet
metadata:
spec:
podManagementPolicy: OrderedReady
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: postgres
serviceName: postgres
template:
metadata:
creationTimestamp: null
labels:
app: postgres
spec:
containers:
- env:
- name: POSTGRES_USER
value: root
- name: POSTGRES_PASSWORD
value: <Password>
- name: POSTGRES_DB
value: <DB name>
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
image: postgres:9.5
imagePullPolicy: IfNotPresent
name: postgres
ports:
- containerPort: 5432
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/lib/postgresql/data
name: postgres-data
subPath: pgdata
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 60
updateStrategy:
rollingUpdate:
partition: 0
type: RollingUpdate
volumeClaimTemplates:
- metadata:
creationTimestamp: null
name: postgres-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
volumeMode: Filesystem
status:
phase: Pending

Kafka-Connect For MSSQL Invalid value java.sql.SQLException: No suitable driver found for for configuration

I am trying to connect kafka-connect to my local mssql with localhost:3030
I am receiving this error when I try to make a new connection for mssql. in centos 7(linux). Mssql data is from an external IP(windows), my consumer is inside of linux environment.
"No suitable driver found for configuration".
connect-distributed.properties is shown below;
plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors,
I added "ojdbc7-12.1.0.2.jar" file under /opt/connectors/kafka-connect-jdbc/ but still I am receiving error messages. I dont know what is wrong.
Also my connect-console-source.properties
name=source-sqlserver-user
connector.class=io.confluent.connect.jdbc.JdbcSourceConnector
tasks.max=1
topic.prefix=my-timestamp
connection.url=jdbc:sqlserver://externalIP;database=database;username=username;password=password
version: '2'
services:
kafka-cluster:
image: landoop/fast-data-dev:cp3.3.0
environment:
ADV_HOST: 127.0.0.1
RUNTESTS: 0
ports:
- 2181:2181 # Zookeeper
- 3030:3030 # Landoop UI
- 8081-8083:8081-8083 # REST Proxy, Schema Registry, Kafka Connect ports
- 9581-9585:9581-9585 # JMX Ports
- 9092:9092 # Kafka Broker
ojdbc7-12.1.0.2.jar is the JDBC driver for Oracle.
For MS SQL you need the MS SQL JDBC driver
Edit: Since you're using Docker to run Kafka Connect, you need to make the JDBC JAR file available to the Kafka Connect worker before it runs. You can't just run the Docker container and copy the JDBC driver into it, because you need to restart Kafka Connect afterwards.
To workaround this, you can mount the JAR from your local machine to the relevant path in the container. The relevant path is whereever the Kafka Connect JDBC jar is. Looking at the fast-data-dev image it's in
root#fast-data-dev / $ ls -l /opt/confluent-3.3.0/share/java/kafka-connect-jdbc
total 6544
-rw-r--r-- 1 root root 133842 Jul 28 2017 kafka-connect-jdbc-3.3.0.jar
-rw-r--r-- 1 root root 658466 Jul 28 2017 postgresql-9.4-1206-jdbc41.jar
-rw-r--r-- 1 root root 5575351 Jul 28 2017 sqlite-jdbc-3.8.11.2.jar
So you can run
docker run --rm --net=host --volume ~/Downloads/mssql-jdbc-7.4.1.jre8.jar:/opt/confluent-3.3.0/share/java/kafka-connect-jdbc/mssql-jdbc-7.4.1.jre8.jar landoop/fast-data-dev:cp3.3.0
or mount it in your Docker Compose with a volumes config:
version: '2'
services:
kafka-cluster:
image: landoop/fast-data-dev:cp3.3.0
environment:
ADV_HOST: 127.0.0.1
RUNTESTS: 0
ports:
- 2181:2181 # Zookeeper
- 3030:3030 # Landoop UI
- 8081-8083:8081-8083 # REST Proxy, Schema Registry, Kafka Connect ports
- 9581-9585:9581-9585 # JMX Ports
- 9092:9092 # Kafka Broker
volumes:
- ~/Downloads/mssql-jdbc-7.4.1.jre8.jar:/opt/confluent-3.3.0/share/java/kafka-connect-jdbc/mssql-jdbc-7.4.1.jre8.jar
It's worth noting that Confluent Platform 3.3.0 is really old - the latest is 5.3.1. If you want to see an up-to-date example of running Kafka, Kafka Connect, SQL Server etc with JDBC driver automatically set up see this example here.

Connect to SQL Server in local machine (host) from docker using host.docker.internal

I'm trying to connect to my SQL Server instance running in my local computer using host.docker.internal (as recommended in https://docs.docker.com/docker-for-windows/networking/#use-cases-and-workarounds)
The host.docker.internal is successfully resolved to an IP, and it's ping-able
And I've opened up the port 1433 in my firewall configuration
Error message
Connection refused 192.168.65.2:1433
My connection string
Data Source=host.docker.internal,1433;Initial Catalog=;Persist Security Info=False;User ID=;Password=;MultipleActiveResultSets=True;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
docker version
Client:
Version: 18.03.1-ce
API version: 1.37
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:12:48 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.1-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:22:38 2018
OS/Arch: linux/amd64
Experimental: true
Docker for windows version
If anyone have similar problem, here's how I solve it
Open SQL Server Configuration Manager
Enable TCP/IP in Server Network Configuration
Restart SQL Service Service
If it's still not working, there are a few more things to check
Firewall (open port 1433)
Enable remote connections to your sql server

Resources