IBM VPC Block
Container Storage Interface (CSI) Driver provides a CSI
interface used by Container Orchestrators to manage the lifecycle of IBM VPC Block Data volumes.
The following are the supported orchestration platforms suitable for deployment for IBM VPC Block CSI Driver.
Orchestration platform Version Architecture Red Hat® OpenShift® 4.7 x86 Red Hat® OpenShift® 4.8 x86 Red Hat® OpenShift® 4.9 x86 Kubernetes 1.19 x86 Kubernetes 1.20 x86 Kubernetes 1.21 x86Following are the prerequisites to use the IBM VPC Block CSI Driver:
ibmcloud is
CLI or get the required worker/node details by using IBM Cloud Console
"ibm-cloud.kubernetes.io/worker-id"
"failure-domain.beta.kubernetes.io/region"
"failure-domain.beta.kubernetes.io/zone"
"topology.kubernetes.io/region"
"topology.kubernetes.io/zone"
Please use apply-required-setup.sh
script for all the nodes in the cluster which will need couple of inputs like
instanceID
: That you can get from ibmcloud is ins
node-name
: this is as per node name in the kubernetes node check by using kubectl get nodes
region-of-instanceID
: region of the instanceID, this you can get the by using ibmcloud is in <instanceID>
zone-of-instanceID
: Zone of the instanceID, this you can get the by using ibmcloud is in <instanceID>
Example :- ./apply-required-setup.sh
For building the driver docker
and GO
should be installed on the system
GO version should be >=1.16
Set the GOPATH
environment variable.
Build the driver image
Clone the repo or your forked repo$ mkdir -p $GOPATH/src/github.com/kubernetes-sigs
$ cd $GOPATH/src/github.com/kubernetes-sigs/
$ git clone https://github.com/kubernetes-sigs/ibm-vpc-block-csi-driver.git
$ cd ibm-vpc-block-csi-driver
Build project and runs testcases Build container image for the driver
Image should be pushed to any registry from which cluster worker nodes have access to pull
You can push the driver image to docker.io registry or IBM public registry under your namespace.
For pushing to IBM registry:
Create an image pull secret in your cluster
ibmcloud login to the target region
Run - ibmcloud cr region-set global
Run - ibmcloud cr login
Make sure kubectl is configured to use the cluster
Review and retrieve the following values for your image pull secret.
<docker-username>
- Enter the string: iamapikey
.
<docker-password>
- Enter your IAM API key. For more information about IAM API keys, see Understanding API keys .
<docker-email>
- Enter the string: iamapikey.
Run the following command to create the image pull secret in your cluster. Note that your secret must be named icr-io-secret
kubectl create secret docker-registry icr-io-secret --docker-server=icr.io --docker-username=iamapikey --docker-password=-<iam-api-key> --docker-email=iamapikey -n kube-system
IBM VPC endpoints which supports Gen2 is documented here
kustomize
tool. The instructions are available hereYou can use any overlays available under deploy/kubernetes/driver/kubernetes/overlays/
and edit the image tag if you want to use your own build image from this source code, although default overlays are already using released IBM VPC Block CSI Driver image
gcr.io/k8s-staging-cloud-provider-ibm/ibm-vpc-block-csi-driver:master
image is always the latest image build using master
branch code.
Example using stage
overlay to update the image tag
iks-vpc-block-driver
image name in deploy/kubernetes/driver/kubernetes/overlays/stage/controller-server-images.yaml
iks-vpc-block-driver
image name in deploy/kubernetes/driver/kubernetes/overlays/stage/node-server-images.yaml
Deploy plugin
bash deploy/kubernetes/driver/kubernetes/deploy-vpc-block-driver.sh stage
ls deploy/kubernetes/storageclass/ | xargs -I classfile kubectl apply -f deploy/kubernetes/storageclass/classfile
kubectl create -f examples/kubernetes/validPVC.yaml
kubectl create -f examples/kubernetes/validPOD.yaml
bash deploy/kubernetes/driver/kubernetes/delete-vpc-csi-driver.sh stage
Please refer this repository for e2e tests.
If you have any questions or issues you can create a new issue here .
Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:
Fork the repo
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Added some feature')
Push to the branch (git push origin my-new-feature)
Create new Pull Request
Add the test results in the PR
For any changes to go.mod
or go.sum
, be sure to run go mod vendor
to update dependencies in the vendor/
directory. You can verify that the vendor directory is up-to-date before filing a PR by running hack/verify-vendor.sh
.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4