juicefs-csi-driver | JuiceFS CSI Driver | Storage library
kandi X-RAY | juicefs-csi-driver Summary
kandi X-RAY | juicefs-csi-driver Summary
The [JuiceFS] Container Storage Interface (CSI) Driver implements the [CSI] specification for container orchestrators to manage the lifecycle of JuiceFS file system.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- NewMountPod creates a new pod
- ParseSetting retrieves a JfsSetting from secrets .
- Get cache dir volumes
- init initializes the config .
- main initializes driver driver
- NewManager returns a new manager .
- generatePodTemplate generates template for pod template
- NodeUnpublishVolume unmounts a volume
- makeRoundTripper creates a new HTTP RoundTripper
- newNodeService returns a new instance of NodeService
juicefs-csi-driver Key Features
juicefs-csi-driver Examples and Code Snippets
Community Discussions
Trending Discussions on juicefs-csi-driver
QUESTION
I'm using a juicefs-csi in GKE. I use postgre as meta-store and GCS as storage. The corresponding setting is as follow:
...ANSWER
Answered 2021-Dec-15 at 13:53Ok I misunderstood you at the beginning.
When you are creating GKE cluster you can specify which GCP Service Account will be used by this cluster, like below:
By Default it's Compute Engine default service account (71025XXXXXX-compute@developer.gserviceaccount.com) which is lack of a few Cloud Product permissions (like Cloud Storage, it has Read Only). It's even described in this message.
If you want to check which Service Account was set by default to VM, you could do this via
Compute Engine > VM Instances > Choose one of the VMs from this cluster > In details find API and identity management
So You have like 3 options to solve this issue:
1. During Cluster creation
In Node Pools > Security, you have Access scopes where you can add some additional permissions.
Allow full access to all Cloud APIsto allow access for all listed Cloud APIsSet access for each API
In your case you could just use Set access for each API and change Storage to Full.
2. Set permissions with a Service Account
You would need to create a new Service Account and provide proper permissions for Compute Engine and Storage. More details about how to create SA you can find in Creating and managing service accounts.
3. Use Workload Identity
Workload Identity on your Google Kubernetes Engine (GKE) clusters. Workload Identity allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.
For more details you should check Using Workload Identity.
Useful links
- Configuring Velero - Velero is software for backup and restore, however steps 2 and 3 are mentioned there. You would just need to adjust commands/permissions to your scenario.
- Authenticating to Google Cloud with service accounts
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install juicefs-csi-driver
Helm is a tool for managing Kubernetes charts. Charts are packages of pre-configured Kubernetes resources. To install Helm, refer to the [Helm install guide](https://github.com/helm/helm#install) and ensure that the helm binary is in the PATH of your shell. Create a configuration file, for example: values.yaml, copy and complete the following configuration information. Among them, the backend part is the information related to the JuiceFS file system, you can refer to [JuiceFS Quick Start Guide](https://github.com/juicedata/juicefs/blob/main/docs/en/getting-started/_quick_start_guide.md) for more information. If you are using a JuiceFS volume that has been created, you only need to fill in the two items name and metaurl. The mountPod part can specify CPU/memory limits and requests of mount pod for pods using this driver. Unneeded items should be deleted, or its value should be left blank. Execute the following command. If the result is not empty, it means that the root-dir path of kubelet is not the default value and you need to set kubeletDir to the current root-dir path of kubelet in the configuration file values.yaml prepared in the first step.
Helm 3.1.0+
Prepare a YAML file
Check and update kubelet root-dir
Deploy
Check the deployment Check pods are running: the deployment will launch a StatefulSet named juicefs-csi-controller with replica 1 and a DaemonSet named juicefs-csi-node, so run kubectl -n kube-system get pods -l app.kubernetes.io/name=juicefs-csi-driver should see n+1 (where n is the number of worker nodes of the Kubernetes cluster) pods is running. For example:
Check secret: kubectl -n kube-system describe secret juicefs-sc-secret will show the secret with above backend fields in values.yaml:
Check storage class: kubectl get sc juicefs-sc will show the storage class like this:
Since Kubernetes will deprecate some old APIs when a new version is released, you need to choose the appropriate deployment configuration file. Execute the following command on any non-Master node in the Kubernetes cluster. If the check command returns a non-empty result, it means that the root-dir path of the kubelet is not the default, so you need to update the kubeletDir path in the CSI Driver’s deployment file and deploy.
Check the root directory path of kubelet.
Deploy
Refer to [Upgrade Csi Driver](docs/en/upgrade-csi-driver.md) document.
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
