pod mysql mount azure files failed - mysql

wanna deploy a mysql in cluster, and pod need a persistent storage, here are yaml & pictures:
The pod:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- image: mysql:5.7
name: mypod
ports:
- containerPort: 3306
protocol: TCP
env:
- name: MYSQL_ROOT_PASSWORD
value: THEROODPWD
volumeMounts:
- name: azure
mountPath: /var/lib/mysql/
volumes:
- name: azure
csi:
driver: file.csi.azure.com
volumeAttributes:
secretName: williamstoragekey
shareName: mysql
mountOptions: "dir_mode=0777,file_mode=0777,cache=strict,actimeo=30"
The secret:
kind: Secret
apiVersion: v1
metadata:
name: williamstoragekey
namespace: default
uid: 0e164956-2e2c-47ef-adc3-ffed8089a4a7
resourceVersion: '20976434'
creationTimestamp: '2022-03-14T07:13:38Z'
managedFields:
- manager: kubectl-create
operation: Update
apiVersion: v1
time: '2022-03-14T07:13:38Z'
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:azurestorageaccountkey: {}
f:azurestorageaccountname: {}
f:type: {}
data:
azurestorageaccountkey: >-
TWYrMFRaQ0ZLQVIxcEtVMFJGNUdCSEFGcXVnREdYZDZ5V2JMd2hFeGJFeTd0Z1pmNWNFQjM2d3FQM1EwY0VkeExRckhKWVZMZnJvYlN0QlIzcEJOeHc9PQ==
azurestorageaccountname: a3ViZXRlc3RpbmcwMDk=
type: Opaque
The pod event:
And inside the file share:
Pod logs:
2022-03-15 01:07:34+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
2022-03-15 01:07:34+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2022-03-15 01:07:34+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
2022-03-15 01:07:35+00:00 [Note] [Entrypoint]: Initializing database files
2022-03-15T01:07:35.308618Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2022-03-15T01:07:35.321413Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2022-03-15T01:07:35.321452Z 0 [ERROR] Aborting
It's obviously the files inside mysql file share are created by mysql, and the file share is new created and is empty. But the pod seems crashed many times to start and terminated.

https://learn.microsoft.com/en-us/answers/questions/770819/pod-mount-azure-files-failed.html
Posting the Microsoft Q&A thread(answered) discussion here, which can benefits other community reading this thread.

Related

MySQL database in Azure cluster using Azure Files as PV won't start

I have an Azure kubernetes cluster, but because of the limitation of attached default volumes per node (8 at my node size), I had to find a different solution to provision volumes.
The solution was to use Azure files volume and I followed this article https://learn.microsoft.com/en-us/azure/aks/azure-files-volume#mount-options which works, I have a volume mounted.
But the problem is with the MySQL instance, it just won't start.
For the test purpose, I created a deployment with 2 simple DB containers, one of which is using the default storage class volume and the second one is using the Azure-files.
Here is my manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-db
labels:
prj: test-db
spec:
selector:
matchLabels:
prj: test-db
template:
metadata:
labels:
prj: test-db
spec:
containers:
- name: db-default
image: mysql:5.7.37
imagePullPolicy: IfNotPresent
args:
- "--ignore-db-dir=lost+found"
ports:
- containerPort: 3306
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: password
volumeMounts:
- name: default-pv
mountPath: /var/lib/mysql
subPath: test
- name: db-azurefiles
image: mysql:5.7.37
imagePullPolicy: IfNotPresent
args:
- "--ignore-db-dir=lost+found"
- "--initialize-insecure"
ports:
- containerPort: 3306
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: password
volumeMounts:
- name: azurefile-pv
mountPath: /var/lib/mysql
subPath: test
volumes:
- name: default-pv
persistentVolumeClaim:
claimName: default-pvc
- name: azurefile-pv
persistentVolumeClaim:
claimName: azurefile-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: default-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 200Mi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: azurefile-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: azure-file-store
resources:
requests:
storage: 200Mi
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict
- nosharesock
parameters:
skuName: Standard_LRS
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
The one with default PV works without any problem, but the second one with Azure-files throws this error:
[Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
[Note] [Entrypoint]: Switching to dedicated user 'mysql'
[Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
[Note] [Entrypoint]: Initializing database files
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
[Warning] InnoDB: New log files created, LSN=45790
[Warning] InnoDB: Creating foreign key constraint system tables.
[Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: e86bdae0-979b-11ec-abbf-f66bf9455d85.
[Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
mysqld: Can't change permissions of the file 'ca-key.pem' (Errcode: 1 - Operation not permitted)
[ERROR] Could not set file permission for ca-key.pem
[ERROR] Aborting
Based on the error, it seems like the database can't write to the volume mount, but that's not (entirely) true. I mounted both of those volumes to another container to be able to inspect files, here is the output and we can see that database was able to write files on the volume:
-rwxrwxrwx 1 root root 56 Feb 27 07:07 auto.cnf
-rwxrwxrwx 1 root root 1680 Feb 27 07:07 ca-key.pem
-rwxrwxrwx 1 root root 215 Feb 27 07:07 ib_buffer_pool
-rwxrwxrwx 1 root root 50331648 Feb 27 07:07 ib_logfile0
-rwxrwxrwx 1 root root 50331648 Feb 27 07:07 ib_logfile1
-rwxrwxrwx 1 root root 12582912 Feb 27 07:07 ibdata1
Obviously, some files are missing, but this output disproved my thought that the Mysql can't write to the folder.
My guess is, that the MySQL can't properly work with the file system used on Azure files.
What I tried:
different versions of MySQL (5.7.16, 5.7.24, 5.7.31, 5.7.37) and MariaDB (10.6)
testing different arguments for mysql
recreate the storage with NFS v3 enabled
create a custom Mysql image with added cifs-utils
testing different permissions, gid/uid, and other attributes of the container and also storage class
It appears to be the permissions of volumes mounted this way that is causing the issue.
If we modify your storage class to match the uid/gid of the mysql user, the pod can start:
apiVersion: storage.k8s.io/v1
kind: StorageClass
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=999
- gid=999
- mfsymlinks
- cache=strict
- nosharesock
parameters:
skuName: Standard_LRS
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
The mount options permanently set the owner of the files contained in the mount, which doesn't work well for anything that wants to own the files it creates. Because things are created 777, anyone can read/write to the directories just not own them.

How to disable mysql strict mode in kubernetes?

I wanted to create a MySQL container in Kubernetes with default disabled strict mode. I know the way of how to disable strict mode in docker. I tried to use the same way in Kubernetes, but it shows an errors log.
docker
docker container run -t -d --name hello-wordl mysql --sql-mode=""
kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-db
labels:
app: db
spec:
selector:
matchLabels:
app: db
template:
metadata:
name: my-db
labels:
app: db
spec:
containers:
- name: my-db
image: mariadb
imagePullPolicy: Always
args: ["--sql-mode=\"\""]
error:
2021-10-29 08:20:57+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.2.40+maria~bionic started.
2021-10-29 08:20:57+00:00 [ERROR] [Entrypoint]: mysqld failed while attempting to check config
command was: mysqld --sql-mode="" --verbose --help --log-bin-index=/tmp/tmp.i8yL5kgKoq
2021-10-29 8:20:57 140254859638464 [ERROR] mysqld: Error while setting value '""' to 'sql_mode'
Based on the error you're getting, it is reading the double quotes as value to sql_mode. You should omit the escaped double-quotes.
args: ["--sql-mode="]
It seems you have to use a configmap for this.
Configmap manifest:
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql-config
labels:
app: mysql
data:
my.cnf: |-
[client]
default-character-set=utf8mb4
[mysql]
default-character-set=utf8mb4
[mysqld]
max_connections = 2000
secure_file_priv=/var/lib/mysql
sql_mode=STRICT_TRANS_TABLES
Deployment Manifest : in Volume section
volumeMounts:
- name: data
mountPath: /var/lib/mysql
- name: config
mountPath: /etc/mysql/conf.d/my.cnf
subPath: my.cnf
volumes:
- name: config
configMap:
name: mysql-config
This will replace your default my.conf in MySQL container, if you need to set more variables, better to include them in the configmap
For more detailed answer

error during mysql deployment in kubernetes for FireFly III installation

followed https://docs.firefly-iii.org/installation/k8n
Did some extra customization to the pvc's to make them bind to my nfs pv's.
All going smooth so far. But the mysql pod wont come up and gets into a CrashLoopBackOff.
Describing the mysql pod:
~/kubernetes$ kubectl describe pod firefly-iii-mysql-67bfb68cf9-6gm9l
Name: firefly-iii-mysql-67bfb68cf9-6gm9l
Namespace: default
Priority: 0
Node: ommitted
Start Time: Fri, 30 Oct 2020 15:09:29 +0000
Labels: app=firefly-iii
pod-template-hash=67bfb68cf9
tier=mysql
Annotations: <none>
Status: Running
IP: 10.32.0.4
IPs:
IP: 10.32.0.4
Controlled By: ReplicaSet/firefly-iii-mysql-67bfb68cf9
Containers:
mysql:
Container ID: docker://7c0e5920d4e1cb3ce98308e0c02d4a98bc9926b828c50496b8d8b3486245dcb9
Image: mysql:5.6
Image ID: docker-pullable://mysql#sha256:8875725ff152f77e47a563661ea010b4ca9cea42d9dda897fb565ca224e83de2
Port: 3306/TCP
Host Port: 0/TCP
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 141
Started: Fri, 30 Oct 2020 15:25:48 +0000
Finished: Fri, 30 Oct 2020 15:25:50 +0000
Ready: False
Restart Count: 8
Environment:
MYSQL_ROOT_PASSWORD: <set to the key 'db_password' in secret 'firefly-iii-secrets-kkcdcb696c'> Optional: false
Mounts:
/var/lib/mysql from mysql-persistent-storage (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-k9zt4 (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
mysql-persistent-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mysql-pv-claim
ReadOnly: false
default-token-k9zt4:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-k9zt4
Optional: false
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
---- ------ ---- ---- -------
Warning FailedScheduling 18m (x2 over 18m) default-scheduler persistentvolumeclaim "mysql-pv-claim" not found
Normal Scheduled 18m default-scheduler Successfully assigned default/firefly-iii-mysql-67bfb68cf9-6gm9l to domm-lnx-02
Normal Pulled 16m (x5 over 18m) kubelet Container image "mysql:5.6" already present on machine
Normal Created 16m (x5 over 18m) kubelet Created container mysql
Normal Started 16m (x5 over 18m) kubelet Started container mysql
Warning BackOff 3m16s (x73 over 18m) kubelet Back-off restarting failed container
From the logs I get this:
~/kubernetes$ kubectl logs firefly-iii-mysql-67bfb68cf9-6gm9l
2020-10-30 15:25:48+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.50-1debian9 started.
2020-10-30 15:25:49+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-10-30 15:25:49+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.50-1debian9 started.
2020-10-30 15:25:49+00:00 [Note] [Entrypoint]: Initializing database files
2020-10-30 15:25:50 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-10-30 15:25:50 0 [Note] Ignoring --secure-file-priv value as server is running with --bootstrap.
2020-10-30 15:25:50 0 [Note] /usr/sbin/mysqld (mysqld 5.6.50) starting as process 52 ...
2020-10-30 15:25:50 52 [Warning] Can't create test file /var/lib/mysql/firefly-iii-mysql-67bfb68cf9-6gm9l.lower-test
2020-10-30 15:25:50 52 [Warning] Can't create test file /var/lib/mysql/firefly-iii-mysql-67bfb68cf9-6gm9l.lower-test
/usr/sbin/mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13 - Permission denied)
2020-10-30 15:25:50 52 [ERROR] Aborting
2020-10-30 15:25:50 52 [Note] Binlog end
2020-10-30 15:25:50 52 [Note] /usr/sbin/mysqld: Shutdown complete
pod creation yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: firefly-iii-mysql
labels:
app: firefly-iii
spec:
selector:
matchLabels:
app: firefly-iii
tier: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: firefly-iii
tier: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: firefly-iii-secrets
key: db_password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
I had some trouble with my pvc's at first, but that seems to be resolved now. The firefly-iii main pod seems to be working just fine, with a similar pv-pvc setup. I had to recreate the whole deployment a couple of times. But now I am stuck with this permission error. I am not sure how to fix it and I could not find much useful anywhere about this...
I hope someone here can point me in the right direction...
Figured it out. Problem was with the nfs permissions. Had to set them to "map all users to admin" on the nfs host. Now my deployment can actually edit files there... Which is something mysql likes ;)

How to create mysql service using local persistent volume to store the data on windows local machine

I want that mysql pod doesn't remove all mysql data when I restart the computer.
I should be able to store the data in my machine, so when I reboot my computer and the mysql pod starts again, the databases are still there.
here are my yaml's:
storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
mysql-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-volume
labels:
type: local
spec:
capacity:
storage: 20Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
volumeMode: Filesystem
storageClassName: local-storage
local:
path: "C:\\mysql-volume" #2 \ for escape characters right?
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- docker-desktop
#hostPath:
# path: /mysql-volume
#type: DirectoryOrCreate
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
type: local
spec:
storageClassName: local-storage
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi
mysql-deployment.yaml
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
app: mysql
spec:
ports:
- protocol: TCP
port: 3306
nodePort: 30001
selector:
app: mysql
type: NodePort
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql-custom-img-here
imagePullPolicy: IfNotPresent
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: mysql-root-password
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: db-secret
key: mysql-user
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: mysql-password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
After trying that, the first error I got was:
MountVolume.NewMounter initialization failed for volume "mysql-pv-volume" : path "C:\\mysql-volume" does not exist
Since im using windows, I guess that's the correct path right? Im using 2 "" for a escape character, Maybe the problem is here in the path, but not sure. If it is, how can I give my local path on my windows machine?
Then I changed the local: path: to /opt and the following error apeared:
initialize specified but the data directory has files in it.
log:
2020-09-24 12:53:00+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.31-1debian10 started.
2020-09-24 12:53:00+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-09-24 12:53:00+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.31-1debian10 started.
2020-09-24 12:53:00+00:00 [Note] [Entrypoint]: Initializing database files
2020-09-24T12:53:00.271130Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-09-24T12:53:00.271954Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2020-09-24T12:53:00.271981Z 0 [ERROR] Aborting
but if I change the mountPath: /var/lib/mysql to for example mountPath: /var/lib/mysql-test
It works, but not as expected(saving the data after rebooting the computer).
Even after removing the PV, PVC and MYSQL deployment/service, that same error keeps appearing.
I even removed the volumes using the docker command, and changing my mysql custom image just to 'mysql:5.7' just in case, but the same initialize specified but the data directory has files in it. appears.
How does that happen, even when I remove the pod? mountPath is the container path, so the data should disappear.
And how can I give my local path in the persistentVolume?
Thanks for your time!
edit: forgot the tell that I already saw this: How to create a mysql kubernetes service with a locally mounted data volume?
I searched a lot, but no luck
I finally solved the problem...
The problem of initialize specified but the data directory has files in it. was answered by #Jakub
The MountVolume.NewMounter initialization failed for volume "mysql-pv-volume" : path "C:\\mysql-volume" does not exist .... I can't even believe the time spent because of this silly problem...
the correct path is: path: /c/mysql-volume after that, all worked as expected!
I am posting this as a community wiki answer for better visibility.
If you have problem with initialize specified but the data directory has files in it then there is github issue which will help you.
TLDR
Use --ignore-db-dir=lost+found in your container
Use older version of mysql, for example mysql:5.6
There are answers on github provided by #alexpls and #aklinkert
I had this issue with Kubernetes and MySQL 5.7.15 as well. Adding the suggestion from #yosifki to my container's definition got things working.
Here's an extract of my working YAML definition:
name: mysql-master
image: mysql:5.7
args:
- "--ignore-db-dir=lost+found"
The exact same configuration is working for MySQL Version 5.6 with.

Unable to deploy MySQL on Redhat Openshift

I am unable to deploy MySQL on Redhat openshift. My pod keep going into CrashLoopBackOff. From the error, I don't understand what is the issue because it states that initializing of server in progress as process and after that, it directly goes into shutdown state. Need to understand what is actually happening.
Deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-wordpress-deployment
namespace: wordpress-website
labels:
app: mysql-wordpress
spec:
selector:
matchLabels:
app: mysql-wordpress
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql-wordpress
spec:
volumes:
- name: mysql-local-pv
persistentVolumeClaim:
claimName: local-mysql-pvc
containers:
- name: mysql-container
image: mysql
imagePullPolicy: IfNotPresent
port:
- containerPorts: 3306
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: pass
volumeMounts:
- name: mysql-local-pv
mountPath: /var/lib/mysql
PersistentVolume.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-mysql-pv
spec:
storageClassName: ibmc-block-bronze
accessModes:
- ReadWriteOnce
capacity:
storage: "20Gi"
hostPath:
path: /tmp/data/
persistentVolumeReclaimPolicy: Recycle
PersistentVolumeClaim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: local-mysql-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Error Logs
Initializing database
mysqld: Can't create directory '/var/lib/mysql/' (OS errno 17 - File exists)
2019-08-18T10:16:22.005955Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-08-18T10:16:22.006063Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.17) initializing of server in progress as process 17
2019-08-18T10:16:22.008464Z 0 [ERROR] [MY-013236] [Server] The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it.
2019-08-18T10:16:22.008504Z 0 [ERROR] [MY-010119] [Server] Aborting
2019-08-18T10:16:22.008970Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.17) MySQL Community Server - GPL.
hostPath is required privileged scc to write something to host by pod.
So you configure privileged permission as following steps.
# oc adm policy add-scc-to-user privileged -z default
# oc edit deployment mysql-wordpress-deployment
spec:
...
template:
...
spec:
...
containers:
- name: mysql-container
securityContext:
privileged: true
Basically, privileged mode is not recommended as aspect of security, because privileged allow to access directly to host resources without any constraints.
I hope it help you.