Connect to local SQL Server Express database from inside minikube cluster - sql-server

I'm trying to access my SQL Server Express database hosted on my local machine from inside a minikube pod. I tried to follow the idea describe on kubernetes official doc. While I am inspecting my container I found out that my application got crashed every time I am creating POD because the application is unable to connect to the local database.
This is my config:
apiVersion: v1
kind: Service
metadata:
name: sqlserver-svc
spec:
ports:
- protocol: TCP
port: 1443
targetPort: 1433
===========================
apiVersion: v1
kind: Endpoints
metadata:
name: sqlserver-svc
subsets:
- addresses:
- ip: 192.168.0.101
ports:
- port: 1433
======== Application container ==========
apiVersion: v1
kind: Pod # object type -> that will reside kubernetes cluster
metadata:
name: api-pod
labels:
component: web
spec:
containers:
- name: api
image: nayan2/simptekapi
ports:
- containerPort: 5000
env:
- name: DATABASE_HOST
value: "sqlserver-svc:1443\\SQLEXPRESS"
- name: DATABASE_PORT
value: '1433'
- name: DATABASE_USER
value: sa
- name: DATABASE_PW
value: 1234
- name: JWT_SECRET
value: sec
- name: NODE_ENV
value: production
================================
apiVersion: v1
kind: Service
metadata:
name: api-node-port
spec:
type: NodePort
ports:
- port: 4200
targetPort: 5000
nodePort: 31515
selector:
component: web
It is obvious that I am doing something wrong. I am relatively new with docker/container and Kubernetes technology. Still learning. Can anybody help me with this??

Related

Deploying SQL Server in Kubernetes: context deadline exceeded while pulling mssql image attempt

When I'm trying to run SQL Server in kubernetes with the mcr.microsoft.com/mssql/server image in minikube cluster in several seconds I'm getting the following in logs:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 38h (x77 over 47h) kubelet Pulling image "mcr.microsoft.com/mssql/server"
Normal BackOff 38h (x1658 over 47h) kubelet Back-off pulling image "mcr.microsoft.com/mssql/server"
Warning Failed 38h (x79 over 47h) kubelet Failed to pull image "mcr.microsoft.com/mssql/server": rpc error: code = Unknown desc = context deadline exceeded
Pulling and running the image in docker desktop works fine.
What I've already tried:
Specifying a tag like :2019-latest;
Specifying an imagePullPolicy like IfNotPresent or Never. Seems like even after pulling the image via powershell directly kubernetes doesn't see it locally (but docker does).
I suspect the reason is that the image is too large and kubernetes has too short timeout settings by default. But I'm a newbie with kubernetes and haven't checked this yet. At least, I don't see anything about it in SQL Server examples.
Here's the deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mssql-deployment
namespace: mynamespace
spec:
replicas: 1
selector:
matchLabels:
app: mssql
strategy:
type: Recreate
template:
metadata:
labels:
app: mssql
spec:
terminationGracePeriodSeconds: 10
containers:
- image: mcr.microsoft.com/mssql/server
name: mssql
env:
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
valueFrom:
secretKeyRef:
name: mssql
key: SA_PASSWORD
ports:
- containerPort: 1433
name: mssql
securityContext:
privileged: true
volumeMounts:
- name: mssqldb
mountPath: /var/opt/mssql
volumes:
- name: mssqldb
persistentVolumeClaim:
claimName: mysql-pv-claim
service.yaml
apiVersion: v1
kind: Service
metadata:
name: mssql-deployment
namespace: mynamespace
spec:
ports:
- protocol: TCP
port: 1433
targetPort: 1433
selector:
app: mssql
type: LoadBalancer
pvc.yaml:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Could you, please, help me figure out what I'm doing wrong? Let me know if you need more details.
Thank you!

ImagePullBack pod status in Kubernetes when pulling public image (MS SQL Server Express)

I'm following Les Jackson's tutorial to microservices and got stuck at 05:30:00 while creating a deployment for a ms sql server. I've written the deployment file just as shown on the yt video:
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:2017-latest
ports:
- containerPort: 1433
env:
- name: MSSQL_PID
value: "Express"
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
valueFrom:
secretKeyRef:
name: mssql
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 # this is default port for mssql
targetPort: 1433
---
apiVersion: v1
kind: Service
metadata:
name: mssql-loadbalancer
spec:
type: LoadBalancer
selector:
app: mssql
ports:
- protocol: TCP
port: 1433 # this is default port for mssql
targetPort: 1433
The persistent volume claim:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mssql-claim
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 200Mi
But when I apply this deployment, the pod ends up with ImagePullBackOff status:
commands-depl-688f77b9c6-vln5v 1/1 Running 0 2d21h
mssql-depl-5cd6d7d486-m8nw6 0/1 ImagePullBackOff 0 4m54s
platforms-depl-6b6cf9b478-ktlhf 1/1 Running 0 2d21h
kubectl describe pod
Name: mssql-depl-5cd6d7d486-nrrkn
Namespace: default
Priority: 0
Node: docker-desktop/192.168.65.4
Start Time: Thu, 28 Jul 2022 12:09:34 +0200
Labels: app=mssql
pod-template-hash=5cd6d7d486
Annotations: <none>
Status: Pending
IP: 10.1.0.27
IPs:
IP: 10.1.0.27
Controlled By: ReplicaSet/mssql-depl-5cd6d7d486
Containers:
mssql:
Container ID:
Image: mcr.microsoft.com/mssql/server:2017-latest
Image ID:
Port: 1433/TCP
Host Port: 0/TCP
State: Waiting
Reason: ImagePullBackOff
Ready: False
Restart Count: 0
Environment:
MSSQL_PID: Express
ACCEPT_EULA: Y
SA_PASSWORD: <set to the key 'SA_PASSWORD' in secret 'mssql'> Optional: false
Mounts:
/var/opt/mssql/data from mssqldb (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube- api-access-xqzks (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
mssqldb:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mssql-claim
ReadOnly: false
kube-api-access-xqzks:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not- ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 3m42s default-scheduler Successfully assigned default/mssql-depl-5cd6d7d486-nrrkn to docker-desktop
Warning Failed 102s kubelet Failed to pull image "mcr.microsoft.com/mssql/server:2017-latest": rpc error: code = Unknown desc = context deadline exceeded
Warning Failed 102s kubelet Error: ErrImagePull
Normal BackOff 102s kubelet Back-off pulling image "mcr.microsoft.com/mssql/server:2017-latest"
Warning Failed 102s kubelet Error: ImagePullBackOff
Normal Pulling 87s (x2 over 3m41s) kubelet Pulling image "mcr.microsoft.com/mssql/server:2017-latest"
In the events it shows
"rpc error: code = Unknown desc = context deadline exceeded"
But it doesn't tell me anything and resources on troubleshooting this error don't include such error.
I'm using kubernetes on docker locally.
I've researched that this issue can happen when pulling the image from a private registry, but this is public one, right here. I copy pasted the image path to be sure, I tried with different ms sql version, but to no avail.
Can someone be so kind and show me the right direction I should go / what should I try to get this to work? It worked just fine on the video :(
I fixed it by manually pulling the image via docker pull mcr.microsoft.com/mssql/server:2017-latest and then deleting and re-applying the deployment.
I my case, I needed to pull the image "to minikube" using minikube ssh docker pull <the_image>
Then I can apply my deployment without errors.
Source: https://github.com/kubernetes/minikube/issues/14806

Tanzu Kubernetes NotAuthenticated is set on the volume on virtualmachine

Thanks for any help on this.
I'm running a Tanzu kubernetes cluster, brand new in a dev environment. I'm trying to install MS SQL Server 2019 and am hitting a wall with this error once I apply the manifest.
The SQLserver pod fails with this:
ltkc-workers-mpqdb-556696d6f6-rhpsw
Warning FailedMount 50s kubelet, sqltkc-workers-mpqdb-556696d6f6-rhpsw Unable to attach or mount volumes: unmounted volumes=[mssql-persistent-storage], unattached volumes=[default-token-qzt5k mssql-persistent-storage]: timed out waiting for the condition
Warning FailedAttachVolume 45s (x9 over 2m53s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-697e8f96-a23b-4255-9b19-fa04aeed98ee" : rpc error: code = Internal desc = observed Error: "ServerFaultCode: NotAuthenticated" is set on the volume "fbc91ad5-b62e-4bec-8132-4f2d1c5160f0-697e8f96-a23b-4255-9b19-fa04aeed98ee" on virtualmachine "sqltkc-workers-mpqdb-556696d6f6-rhpsw"
The pv and pvc all are bound:
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pvc-697e8f96-a23b-4255-9b19-fa04aeed98ee 10Gi RWO Delete Bound default/mssql-data-claim pstore-high 67m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/mssql-data-claim Bound pvc-697e8f96-a23b-4255-9b19-fa04aeed98ee 10Gi RWO pstore-high 67m
The deployment manifest is just what I downloaded from the web from various other tutorials:
apiVersion: v1
kind: Service
metadata:
name: mssql-deployment
spec:
selector:
app: mssql
ports:
- protocol: TCP
port: 1433
targetPort: 1433
type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mssql-deployment
spec:
replicas: 1
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 0
selector:
matchLabels:
app: mssql
template:
metadata:
labels:
app: mssql
spec:
terminationGracePeriodSeconds: 10
securityContext:
fsGroup: 1000
restartPolicy: Always
containers:
- name: mssql
resources:
requests:
memory: 8000Mi
image: mcr.microsoft.com/mssql/server:2019-latest
ports:
- containerPort: 1433
env:
- name: MSSQL_PID
value: "Developer"
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
value: VMware123!
volumeMounts:
- name: mssql-persistent-storage
mountPath: /var/opt/mssql
volumes:
- name: mssql-persistent-storage
persistentVolumeClaim:
claimName: mssql-data-claim
Here is the pvc yaml:
kind: PersistentVolumeClaim
metadata:
name: mssql-data-claim
spec:
accessModes:
- ReadWriteOnce
# storageClassName: vsan-default-storage-policy
storageClassName: pstore-high
resources:
requests:
storage: 10Gi
The storage class exists. I have tried this with both the default vSAN and other storage classes and always hit the same volume authentication issue.
I've searched high and low, can't find any related docs. Was hoping to see if someone knew more.
Thanks so much!!
Thanks again for the help, our team was able to fix this. We found out that our vCenter root password had expired. Once we reset the password our persistent volumes were able to mount to the containers without any errors. Highly suggest if you are running Tanzu to make sure your vCenter is fully updated.

Unable to access React Application from Minikube

I've a simple HelloWorld ReactJs application Docker image and I created the deployment as:
kind: Deployment
apiVersion: apps/v1
metadata:
name: minikube-react-app
spec:
replicas: 2
selector:
matchLabels:
app: minikube-react-app
template:
metadata:
labels:
app: minikube-react-app
spec:
containers:
- name: minikube-react-app
image: hello-react:1.0.1
imagePullPolicy: Never
ports:
- containerPort: 80
resources:
requests:
memory: "100Mi"
cpu: "300m"
limits:
memory: "200Mi"
cpu: "600m"
restartPolicy: Always
---
kind: Service
apiVersion: v1
metadata:
name: minikube-react-app
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
protocol: TCP
nodePort: 31000
selector:
app: minikube-react-app
I ran, kubectl apply -f deployent.yaml
But when I access http://localhost:31000 it's not working(This site can’t be reached).
Can someone help me with this please?
Run the following command to get the actual address to connect with your app from host machine.
minikube service --url <service-name>
Ref: https://minikube.sigs.k8s.io/docs/handbook/accessing/
Should use 'node ip' instead of 'localhost' to acccess node port.
Run shell minikube ip to obtain ip of minikube node.
Check the service type: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

React App communicating with Go backend api

I have a frontend React application and a Go backend service as the API for the frontend. Both are Kubernetes services in the same namespace. How can I communicate with the Go backend service without having to use an external IP? I got it to work with an external ip, but, I can't get the fqdn to resolve correctly like it should. The frontend service is built from the nginx:1.15.2-alpine docker image. How can I get the frontend React app to communicate with the backend Go server?
Frontend service.yaml:
apiVersion: v1
kind: Service
metadata:
name: ui
namespace: client
labels:
app: ui
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: http
- name: https
port: 443
targetPort: https
selector:
app: ui
Frontend deployment.yaml:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ui
namespace: client
spec:
replicas: 1
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 2
template:
metadata:
labels:
app: ui
spec:
containers:
- name: ui
image: #######
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
Backend service.yaml:
apiVersion: v1
kind: Service
metadata:
name: api
namespace: client
labels:
app: api
spec:
type: NodePort
ports:
- port: 8001
protocol: TCP
targetPort: http
name: http
selector:
app: api
Backend deployment.yaml:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: api
namespace: client
labels:
name: api
spec:
replicas: 1
revisionHistoryLimit: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: ####
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8001
The React application does not run in Kubernetes. Maybe you have a dev server running in Kubernetes, but it just serves up HTML and Javascript files to a browser running outside the cluster. The application in the browser has no idea about this "Kubernetes" thing and can't resolve the Kubernetes-internal ...svc.cluster.local hostnames; it needs a way to talk back to the cluster.
Since you have the backend configured as a NodePort type service, you can look up the backend's externally visible port, then configure the backend URL in the served browser application to be that port number on some node in your cluster. This is a little bit messy and manual.
A better path is to configure an ingress so that, for example, https://.../ serves your browser application and https://.../api goes to your back-end. Then the backend URL can just be the bare path /api, and it will be interpreted with the same host name and scheme as the UI.
There are many issues with the yamls. First, in service yamls, the targetPort should be port numbers(integers) and not string. So, the updated config will be,
apiVersion: v1
kind: Service
metadata:
name: ui
namespace: client
labels:
app: ui
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
- name: https
port: 443
targetPort: 443
selector:
app: ui
and
apiVersion: v1
kind: Service
metadata:
name: api
namespace: client
labels:
app: api
spec:
type: NodePort
ports:
- port: 8001
protocol: TCP
targetPort: 8001
name: http
selector:
app: api
After changing the targetPort in service yamls, I created a pod to do nslookup and it works as expected.
kubectl apply -f https://k8s.io/examples/admin/dns/busybox.yaml
kubectl exec -ti busybox -- nslookup api.client
produces the output
Defaulting container name to busybox.
Use 'kubectl describe pod/busybox -n default' to see all of the containers in this pod.
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: api.client
Address 1: 10.101.84.21 api.client.svc.cluster.local

Resources