I am trying to free up some space on my Ubuntu 16.04 machine. Running ncdu shows that minikube is using about 19GB of my /home space. Upon further investigation i see it is the minikube.rawdisk file that is taking up most of the space
Can I delete this file and still have minikube work appropriately. I don't see this as a Linux only question but as a question that can affect the functionality of a Kubernetes service.
no, if you delete this file, minikube won't be able to run kubernetes anymore.
Related
Environment: external NFS share for persistent storage, accessible to all, R/W, Centos7 VMs (NFS share and K8s cluster), NFS utils installed on all workers.
Mount on a VM, e.g. a K8s worker node, works correctly, the share is R/W
Deployed in the K8s cluster: PV, PVC, Deployment (Volumes - referenced to PVC, VolumeMount)
The structure of the YAML files corresponds to the various instructions and postings, including the postings here on the site.
The pod starts, the share is mounted. Unfortunately, it is read-only. All the suggestions from the postings I have found about this did not work so far.
Any idea what else I could look out for, what else I could try?
Thanks. Thomas
After digging deep, I found the cause of the problem. Apparently, the syntax for the NFS export is very sensitive. One more space can be problematic.
On the NFS server, two export entries were stored in the kernel tables. The first R/O and the second R/W. I don't know whether this is a Centos bug because of the syntax in /etc/exports.
On another Centos machine I was able to mount the share without any problems (r/w). In the container (Debian-based image), however, not (only r/o). I have not investigated whether this is due to Kubernetes or Debian behaves differently.
After correcting the /etc/exports file and restarting the NFS server, there was only one correct entry in the kernel table. After that, mounting R/W worked on a Centos machine as well as in the Debian-based container inside K8s.
Here are the files / table:
privious /etc/exports:
/nfsshare 172.16.6.* (rw,sync,no_root_squash,no_all_squash,no_acl)
==> kernel:
/nfsshare 172.16.6.*(ro, ...
/nfsshare *(rw, ...
corrected /etc/exports (w/o the blank):
/nfsshare *(rw,sync,no_root_squash,no_all_squash,no_acl)
In principle, the idea of using an init container is a good one. Thank you for reminding me of this.
I have tried it.
Unfortunately, it doesn't change the basic problem. The file system is mounted "read-only" by Kubernetes. The init container returns the following error message (from the log):
chmod: /var/opt/dilax/enumeris: Read-only file system
I am looking for a way to install an Antivirus in Google Kubernetes Engine(GKE). However, I could only find this Kubernetes ClamAV tutorial.
Here is the link of Installing antivirus and file integrity monitoring on Container-Optimized OS.
There are two issues I am facing with this ClamAV on GKE:
Ensure scan-required paths within other pods are mounted as named volumes so they will be included in the scan of the node. This requirement in the overview suggests that only named volumes can be scanned and we want to scan almost every file inside the container.
Trying the steps mentioned in this tutorial I got stuck on the step which says get all pods and exec into one to initiate a full scan.
After creating the resources using kubectl apply -f clamav-daemonset.yaml
I don't see any pods being created.
How do I solve the above-mentioned issues?
Also, is there any other alternative for Antivirus (and file integrity) on GKE apart from ClamAV?
I am trying to configure the kube-apiserver so that it uses encryption to configure secrets in my minikube cluster.
For that, I have followed the documentation on kubernetes.io but got stuck at step 3 that says
Set the --encryption-provider-config flag on the kube-apiserver to point to the location of the config file.
I have discovered the option --extra-config on minikube start and have tried starting my setup using
minikube start --extra-config=apiserver.encryption-provider-config=encryptionConf.yaml
but naturally it doesn't work as encryptionConf.yaml is located in my local file system and not in the pod that's spun up by minikube. The error minikube log gives me is
error: error opening encryption provider configuration file "encryptionConf.yaml": open encryptionConf.yaml: no such file or directory
What is the best practice to get the encryption configuration file onto the kube-apiserver? Or is minikube perhaps the wrong tool to try out these kinds of things?
I found the solution myself in this GitHub issue where they have a similar issue for passing a configuration file. The comment that helped me was the slightly hacky solution that made use of the fact that the directory /var/lib/localkube/certs/ from the minikube VM is mounted into the apiserver.
So my final solution was to run
minikube mount .:/var/lib/minikube/certs/hack
where in the current directory I had my encryptionConf.yaml and then start minikube like so
minikube start --extra-config=apiserver.encryption-provider-config=/var/lib/minikube/certs/hack/encryptionConf.yaml
Based on drivers used some directories are mounted on to your minikube VM.
Check this link - https://kubernetes.io/docs/setup/minikube/#mounted-host-folders
Also ~/.minikube/files is also mounted into the VM at /files. So you can keep your files there and use that path for API server config
I had similar issues in windows regarding filepath location
since C:\Users\%USERNAME%\ is by default mounted in minikube VM
so i copied the files to Desktop folder( any folder under C drive )
minikube --extra-config=apiserver.encryption-provider-config=/c/Users/%USERNAME%/.../<file-name>
hope this is helpful for folks facing this issues on windows platform.
I installed kubernetes on Ubuntu 16.04 (Virtualbox vm) - a single node with master tainted. It worked well. But after I restart my vm, it is not working any more.
kubectl commands are not working any more, throws this error -
The connection to the server localhost:8001 was refused - did you specify the
right host or port?
It looks similar to this thread, but the solution is not working for me.
When I try "sudo docker ps -a", all kube pods are showing in Exited status.
Any helps/pointers, please? Thanks in advance.
I've been having the same issue with my rancher 2 setup. I have two nodes in one cluster. One of my node servers was restarted and never connected to my cluster. Even though docker and containers were running fine.
One of the things i tried was reduce the number of workloads that can run in one node. I had increased it to 400. SO i put it back to 100. That's when I got my first breakthrough of what could be happening with my downed node. I go the error "Path /var/lib/docker is mounted on / but it is not a shared or slave mount." A quick search led me to a similar issue in the rancher github page. Basically a workaround by superseb fixed my issue. I sshed into my node and ran
> mount --make-rshared /
> docker start kubelet
Maybe your issue might be different, but maybe you could be having this same shared problem.
I installed a Kubernetes cluster by following the instruction here:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/vagrant.md
Everything looks fine the first time. I'm able to see the nodes, pods, deploy new pods, etc.
The problem shows up when I stop the cluster and try to start it again. I'm restarting the cluster as indicated on the documentation:
vagrant halt
./cluster/kube-up.sh
When I do that I see the following error:
Comment: Source file salt://kubelet/kubeconfig not found
...
Minion did not return. [No response]
Then, when I check the status of nodes it says the minion is NotReady.
If I have VirtualBox open while I run kube-up.sh, I see that the error is thrown before the minion VM is started. So it sounds like the minion is not running when it tries to configure it. That's just an observation, not sure what's the problem.
In order to solve this issue I have to destroy the cluster and create it again, what downloads and install everything again, making it very slow to use.
I found this problem on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/9270
Here it was suggested to use the code in HEAD. I did that and now it is working fine.