
anhpham1652 asked a question.
I'm trying to deploy k8s full inventory agent. The monitor pod is always pending and I got this error. So in ./krm.yaml generated from ./generate.sh, does it include all these requirements
============
Decide how you will provide persistent storage to the Flexera Kubernetes inventory agent.
The statefulSet used by the Flexera Kubernetes inventory agent requires a PersistentVolumnClaim (PVC) that defines its storage configuration. The storage requirements are:- The volume is durable/reliable across restarts and upgrades of the Kubernetes pods containing the Flexera Kubernetes inventory agent
- The volume is not shared with any other resources in the cluster
- A minimum of 2GB of storage is available
- The access mode must be ReadWriteOnce (this is the default for controllers)
- The volume mode must be Filesystem (also the default for controllers).
============
I also attach the result of describe pod monitor.
You will likely want to use one of the storage classes already configured in your cluster. Running 'kubectl get storageclass' will list those that are available. You provide a complete PersistentVolumeClaim spec in the KRM resource under the 'spec.monitor.storage' attribute, which commonly includes one of the storage classes provided by your cluster. You can read more about PVCs here: https://kubernetes.io/docs/concepts/storage/persistent-volumes/persistentvolumeclaims . The section on storage classes is particularly relevant. Once you've determined what storage classes are available and chosen one, you can generally search for some documentation on that storage class to find out how to troubleshoot issues with it.
Whether or not dynamic provisioning is available isn't directly related to whether or not your cluster is running on virtual machines, it is a property of a storage class. Each storage class either does or does not support dynamic provisioning, which is usually a consequence of the type of underlying storage provider it is using. What storage classes may be successfully implemented in you cluster may be impacted by the type of underlying machine (by virtue of what types of underlying storage providers are available), but most clusters will provide some sort of storage class out of the box that supports dynamic provisioning.
Based on your concerns about virtual machines and the fact that some of the pods are failing with an image pull error while some are not, are you using minikube? If so, you can simply use the "standard" storage class and it will support dynamic provisioning. Something like this would suffice:
The installation process is just as you've said. The only challenging part is configuring the storage and ensuring that you have network communication with a beacon set up correctly. With those details worked out, it is just running install.sh, running generate.sh or manually writing a KRM resource (krm.yaml), then applying that KRM resource to the cluster using 'kubectl apply'.
I've redacted the beacon URL, but here's my basic KRM resource from krm.yaml: