Skip to content
Snippets Groups Projects
Select Git revision
  • ea8a4f8908726561ee6db6e70316f9268710bb21
  • main default
  • 139-remove-part-of-the-helm-chart-that-is-moved-to-the-dashboard-helmchart
  • 122-admin-logins-should-gain-admin-privileges
  • 116-allow-password-change-without-ssl-public-endpoint-in-startup-job
  • 114-create-development-scripts-for-reverse-proxy-solution
  • 110-enable-hydra-maester
  • 82-pylint-job-broken-2
  • 93-0.2.11
  • master protected
  • update-hydra
  • spike-use-kratos-as-identity-manager
  • merge_master_into_0.2
  • 56-fix-link-in-the-readme
  • 0.2
  • 40-replace-flask-oauth-with-oauthlib-in-test-login_logout
  • 45-update-user-panel-to-fix-jobs
  • 41-make-oauth2-client-data-persistent
  • force-https
  • 42-ldap-support
  • 33-wordpress-sso-admin-login-doesn-t-work
  • 0.8.0
  • 0.7.7
  • 0.7.6
  • 0.7.4
  • 0.7.1
  • 0.5.2
  • 0.5.0
  • 0.4.3
  • 0.4.2
  • 0.4.1
  • 0.4.0
  • 0.2.11
  • 0.2.10
  • 0.2.9
  • 0.2.8
  • 0.2.7
  • 0.2.6
  • 0.2.5
  • 0.2.4
  • 0.2.3
41 results

helmchart.md

Blame
  • README.md 7.87 KiB

    Local Path Provisioner

    Overview

    Local Path Provisioner provides a way for the Kubernetes users to utilize the local storage in each node. Based on the user configuration, the Local Path Provisioner will create hostPath based persistent volume on the node automatically. It utilizes the features introduced by Kubernetes Local Persistent Volume feature, but make it a simpler solution than the built-in local volume feature in Kubernetes.

    Compare to built-in Local Persistent Volume feature in Kubernetes

    Pros

    Dynamic provisioning the volume using host path.

    Cons

    1. No support for the volume capacity limit currently.
      1. The capacity limit will be ignored for now.
    2. Only support hostPath

    Requirement

    Kubernetes v1.12+.

    Deployment

    Installation

    In this setup, the directory /opt/local-path-provisioner will be used across all the nodes as the path for provisioning (a.k.a, store the persistent volume data). The provisioner will be installed in local-path-storage namespace by default.

    kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

    After installation, you should see something like the following:

    $ kubectl -n local-path-storage get pod
    NAME                                     READY     STATUS    RESTARTS   AGE
    local-path-provisioner-d744ccf98-xfcbk   1/1       Running   0          7m

    Check and follow the provisioner log using:

    $ kubectl -n local-path-storage logs -f local-path-provisioner-d744ccf98-xfcbk

    Usage

    Create a hostPath backed Persistent Volume and a pod uses it:

    kubectl create -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pvc.yaml
    kubectl create -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pod.yaml

    You should see the PV has been created:

    $ kubectl get pv
    NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                    STORAGECLASS   REASON    AGE
    pvc-bc3117d9-c6d3-11e8-b36d-7a42907dda78   2Gi        RWO            Delete           Bound     default/local-path-pvc   local-path               4s

    The PVC has been bound:

    $ kubectl get pvc
    NAME             STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    local-path-pvc   Bound     pvc-bc3117d9-c6d3-11e8-b36d-7a42907dda78   2Gi        RWO            local-path     16s

    And the Pod started running:

    $ kubectl get pod
    NAME          READY     STATUS    RESTARTS   AGE
    volume-test   1/1       Running   0          3s

    Write something into the pod

    kubectl exec volume-test -- sh -c "echo local-path-test > /data/test"

    Now delete the pod using

    kubectl delete -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pod.yaml

    After confirm that the pod is gone, recreated the pod using

    kubectl create -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pod.yaml

    Check the volume content:

    $ kubectl exec volume-test cat /data/test
    local-path-test

    Delete the pod and pvc

    kubectl delete -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pod.yaml
    kubectl delete -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pvc.yaml

    The volume content stored on the node will be automatically cleaned up. You can check the log of local-path-provisioner-xxx for details.

    Now you've verified that the provisioner works as expected.

    Configuration

    The configuration of the provisioner is a json file config.json, stored in the a config map, e.g.:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: local-path-config
      namespace: local-path-storage
    data:
      config.json: |-
            {
                    "nodePathMap":[
                    {
                            "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
                            "paths":["/opt/local-path-provisioner"]
                    },
                    {
                            "node":"yasker-lp-dev1",
                            "paths":["/opt/local-path-provisioner", "/data1"]
                    },
                    {
                            "node":"yasker-lp-dev3",
                            "paths":[]
                    }
                    ]
            }
    

    Definition

    nodePathMap is the place user can customize where to store the data on each node.

    1. If one node is not listed on the nodePathMap, and Kubernetes wants to create volume on it, the paths specified in DEFAULT_PATH_FOR_NON_LISTED_NODES will be used for provisioning.
    2. If one node is listed on the nodePathMap, the specified paths in paths will be used for provisioning.
      1. If one node is listed but with paths set to [], the provisioner will refuse to provision on this node.
      2. If more than one path was specified, the path would be chosen randomly when provisioning.

    Rules

    The configuration must obey following rules:

    1. config.json must be a valid json file.
    2. A path must start with /, a.k.a an absolute path.
    3. Root directory(/) is prohibited.
    4. No duplicate paths allowed for one node.
    5. No duplicate node allowed.

    Reloading