Switch branches/tags
Nothing to show
Find file History
serathius and ahmetb Import kubernetes updates (#210)
* Admin Can Specify in Which GCE Availability Zone(s) a PV Shall Be Created

An admin wants to specify in which GCE availability zone(s) users may create persistent volumes using dynamic provisioning.

That's why the admin can now configure in StorageClass object a comma separated list of zones. Dynamically created PVs for PVCs that use the StorageClass are created in one of the configured zones.

* Admin Can Specify in Which AWS Availability Zone(s) a PV Shall Be Created

An admin wants to specify in which AWS availability zone(s) users may create persistent volumes using dynamic provisioning.

That's why the admin can now configure in StorageClass object a comma separated list of zones. Dynamically created PVs for PVCs that use the StorageClass are created in one of the configured zones.

* move hardPodAffinitySymmetricWeight to scheduler policy config

* Added Bind method to Scheduler Extender

- only one extender can support the bind method
- if an extender supports bind, scheduler delegates the pod binding to the extender

* examples/podsecuritypolicy/rbac: allow to use projected volumes in restricted PSP.

* fix typo

* SPBM policy ID support in vsphere cloud provider

* fix the invalid link

* DeamonSet-DaemonSet

* Update GlusterFS examples readme.

Signed-off-by: Humble Chirammal <hchiramm@redhat.com>

* fix some typo in example/volumes

* Fix  spelling in example/spark

* Correct spelling in quobyte

* Support custom domains in the cockroachdb example's init container

This switches from using v0.1 of the peer-finder image to a version that
includes kubernetes/contrib#2013

While I'm here, switch the version of cockroachdb from 1.0 to 1.0.1

* Update docs/ URLs to point to proper locations

* Adds --insecure to cockroachdb client command

Cockroach errors out when using said command:

```shell
▶  kubectl run -it --rm cockroach-client --image=cockroachdb/cockroach --restart=Never --command -- ./cockroach sql --host cockroachdb-public
Waiting for pod default/cockroach-client to be running, status is Pending, pod ready: false
Waiting for pod default/cockroach-client to be running, status is Pending, pod ready: false
Waiting for pod default/cockroach-client to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
                                                      Error attaching, falling back to logs: unable to upgrade connection: container cockroach-client not found in pod cockroach-client_default
Error: problem using security settings, did you mean to use --insecure?: problem with CA certificate: not found
Failed running "sql"
Waiting for pod default/cockroach-client to terminate, status is Running
pod "cockroach-client" deleted
```

This PR updates the README.md to include --insecure in the client command

* Add StorageOS volume plugin

* examples/volumes/flexvolume/nfs: check for jq and simplify quoting.

* Remove broken getvolumename and pass PV or volume name to attach call

* Remove controller node plugin driver dependency for non-attachable flex volume drivers (Ex: NFS).

* Add `imageFeatures` parameter for RBD volume plugin, which is used to
customize RBD image format 2 features.
Update RBD docs in examples/persistent-volume-provisioning/README.md.

* Only `layering` RBD image format 2 feature should be supported for now.

* Formatted Dockerfile to be cleaner and precise

* Update docs for user-guide

* Make the Quota creation optional

* Remove duplicated line from ceph-secret-admin.yaml

* Update CockroachDB tag to v1.0.3

* Correct the comment in PSP examples.

* Update wordpress to 4.8.0

* Cassandra example, use nodetool drain in preStop

* Add termination gracePeriod

* Use buildozer to remove deprecated automanaged tags

* Use buildozer to delete licenses() rules except under third_party/

* NR Infrastructure agent example daemonset

Copy of previous newrelic example, then modified to use the new agent
"newrelic-infra" instead of "nrsysmond".

Also maps all of host node's root fs into /host in the container (ro,
but still exposes underlying node info into a container).

Updates to README

* Reduce one time url direction

Reduce one time url direction

* update to rbac v1 in yaml file

* Replicate the persistent volume label admission plugin in a controller in
the cloud-controller-manager

* update related files

* Paramaterize stickyMaxAgeMinutes for service in API

* Update example to CockroachDB v1.0.5

* Remove storage-class annotations in examples

* PodSecurityPolicy.allowedCapabilities: add support for using * to allow to request any capabilities.

Also modify "privileged" PSP to use it and allow privileged users to use
any capabilities.

* Add examples pods to demonstrate CPU manager.

* Tag broken examples test as manual

* bazel: use autogenerated all-srcs rules instead of manually-curated sources rules

* Update CockroachDB tag to v1.1.0

* update BUILD files

* pkg/api/legacyscheme: fixup imports

* Update bazel

* [examples.storage/minio] update deploy config version

* Volunteer to help review examples

I would like to do some code review for examples about how to run real applications with Kubernetes

* examples/podsecuritypolicy/rbac: fix names in comments and sync with examples repository.

* Update storageclass version to v1 in examples

* pkg/apis/core: mechanical import fixes in dependencies

* Use k8s.gcr.io vanity domain for container images

* Update generated files

* gcloud docker now auths k8s.gcr.io by default

* -Add scheduler optimization options, short circuit all predicates if one predicate fails

* Revert k8s.gcr.io vanity domain

This reverts commit eba5b6092afcae27a7c925afea76b85d903e87a9.

Fixes kubernetes/kubernetes#57526

* Autogenerate BUILD files

* Move scheduler code out of plugin directory.

This moves plugin/pkg/scheduler to pkg/scheduler and
plugin/cmd/kube-scheduler to cmd/kube-scheduler.

Bulk of the work was done with gomvpkg, except for kube-scheduler main
package.

* Fix scheduler refs in BUILD files.

Update references to moved scheduler code.

* Switch to k8s.gcr.io vanity domain

This is the 2nd attempt.  The previous was reverted while we figured out
the regional mirrors (oops).

New plan: k8s.gcr.io is a read-only facade that auto-detects your source
region (us, eu, or asia for now) and pulls from the closest.  To publish
an image, push k8s-staging.gcr.io and it will be synced to the regionals
automatically (similar to today).  For now the staging is an alias to
gcr.io/google_containers (the legacy URL).

When we move off of google-owned projects (working on it), then we just
do a one-time sync, and change the google-internal config, and nobody
outside should notice.

We can, in parallel, change the auto-sync into a manual sync - send a PR
to "promote" something from staging, and a bot activates it.  Nice and
visible, easy to keep track of.

* Remove apiVersion from scheduler extender example configuration

* Update examples to use PSPs from the policy API group.

* fix all the typos across the project

* Autogenerated: hack/update-bazel.sh

* Modify PodSecurityPolicy admission plugin to additionally allow authorizing via "use" verb in policy API group.

* fix todo: add validate method for &schedulerapi.Policy

* examples/podsecuritypolicy: add owners.

* Adding dummy and dummy-attachable example Flexvolume drivers; adding DaemonSet deployment example

* Fix relative links in README
Latest commit e4cc298 Mar 14, 2018

README.md

StorageOS Volume

StorageOS

StorageOS can be used as a storage provider for your Kubernetes cluster. StorageOS runs as a container within your Kubernetes environment, making local storage accessible from any node within the Kubernetes cluster. Data can be replicated to protect against node failure.

At its core, StorageOS provides block storage. You may choose the filesystem type to install to make devices usable from within containers.

Prerequisites

The StorageOS container must be running on each Kubernetes node that wants to contribute storage or that wants to consume storage. For more information on how you can run StorageOS, consult the StorageOS documentation.

API Configuration

The StorageOS provider has been pre-configured to use the StorageOS API defaults, and no additional configuration is required for testing. If you have changed the API port, or have removed the default account or changed its password (recommended), you must specify the new settings. This is done using Kubernetes Secrets.

API configuration is set by using Kubernetes secrets. The configuration secret supports the following parameters:

  • apiAddress: The address of the StorageOS API. This is optional and defaults to tcp://localhost:5705, which should be correct if the StorageOS container is running using the default settings.
  • apiUsername: The username to authenticate to the StorageOS API with.
  • apiPassword: The password to authenticate to the StorageOS API with.
  • apiVersion: Optional, string value defaulting to 1. Only set this if requested in StorageOS documentation.

Mutiple credentials can be used by creating different secrets.

For Persistent Volumes, secrets must be created in the Pod namespace. Specify the secret name using the secretName parameter when attaching existing volumes in Pods or creating new persistent volumes.

For dynamically provisioned volumes using storage classes, the secret can be created in any namespace. Note that you would want this to be an admin-controlled namespace with restricted access to users. Specify the secret namespace as parameter adminSecretNamespace and name as parameter adminSecretName in storage classes.

Example spec:

apiVersion: v1
kind: Secret
metadata:
  name: storageos-secret
type: "kubernetes.io/storageos"
data:
  apiAddress: dGNwOi8vMTI3LjAuMC4xOjU3MDU=
  apiUsername: c3RvcmFnZW9z
  apiPassword: c3RvcmFnZW9z

Values for apiAddress, apiUsername and apiPassword can be generated with:

$ echo -n "tcp://127.0.0.1:5705" | base64
dGNwOi8vMTI3LjAuMC4xOjU3MDU=

Create the secret:

$ kubectl create -f storageos-secret.yaml
secret "storageos-secret" created

Verify the secret:

$ kubectl describe secret storageos-secret
Name:		storageos-secret
Namespace:	default
Labels:		<none>
Annotations:	<none>

Type:	kubernetes.io/storageos

Data
====
apiAddress:	20 bytes
apiPassword:	8 bytes
apiUsername:	8 bytes

Examples

These examples assume you have a running Kubernetes cluster with the StorageOS container running on each node, and that an API configuration secret called storageos-secret has been created in the default namespace.

Pre-provisioned Volumes

Pod

Pods can be created that access volumes directly.

  1. Create a volume using the StorageOS UI, CLI or API. Consult the StorageOS documentation for details.

  2. Create a pod that refers to the new volume. In this case the volume is named redis-vol01.

    Example spec:

    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        name: redis
        role: master
      name: test-storageos-redis
    spec:
      containers:
        - name: master
          image: kubernetes/redis:v1
          env:
            - name: MASTER
              value: "true"
          ports:
            - containerPort: 6379
          resources:
            limits:
              cpu: "0.1"
          volumeMounts:
            - mountPath: /redis-master-data
              name: redis-data
      volumes:
        - name: redis-data
          storageos:
            # This volume must already exist within StorageOS
            volumeName: redis-vol01
            # volumeNamespace is optional, and specifies the volume scope within
            # StorageOS.  If no namespace is provided, it will use the namespace
            # of the pod.  Set to `default` or leave blank if you are not using
            # namespaces.
            #volumeNamespace: test-storageos
            # The filesystem type to format the volume with, if required.
            fsType: ext4
            # The secret name for API credentials
            secretName: storageos-secret

    Download example

    Create the pod:

    $ kubectl create -f examples/volumes/storageos/storageos-pod.yaml

    Verify that the pod is running:

    $ kubectl get pods test-storageos-redis
    NAME                   READY     STATUS    RESTARTS   AGE
    test-storageos-redis   1/1       Running   0          30m

Persistent Volumes

  1. Create a volume using the StorageOS UI, CLI or API. Consult the StorageOS documentation for details.

  2. Create the persistent volume redis-vol01.

    Example spec:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv0001
    spec:
      capacity:
        storage: 5Gi
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageos:
        # This volume must already exist within StorageOS
        volumeName: pv0001
        # volumeNamespace is optional, and specifies the volume scope within
        # StorageOS.  Set to `default` or leave blank if you are not using
        # namespaces.
        #volumeNamespace: default
        # The filesystem type to create on the volume, if required.
        fsType: ext4
        # The secret name for API credentials
        secretName: storageos-secret

    Download example

    Create the persistent volume:

    $ kubectl create -f examples/volumes/storageos/storageos-pv.yaml

    Verify that the pv has been created:

    $ kubectl describe pv pv0001
    Name:           pv0001
    Labels:         <none>
    Annotations:    <none>
    StorageClass:   fast
    Status:         Available
    Claim:
    Reclaim Policy: Delete
    Access Modes:   RWO
    Capacity:       5Gi
    Message:
    Source:
        Type:             StorageOS (a StorageOS Persistent Disk resource)
        VolumeName:       pv0001
        VolumeNamespace:
        FSType:           ext4
        ReadOnly:         false
    Events:               <none>
  3. Create persistent volume claim

    Example spec:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc0001
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
      storageClassName: fast

    Download example

    Create the persistent volume claim:

    $ kubectl create -f examples/volumes/storageos/storageos-pvc.yaml

    Verify that the pvc has been created:

    $ kubectl describe pvc pvc0001
    Name:          pvc0001
    Namespace:     default
    StorageClass:  fast
    Status:        Bound
    Volume:        pv0001
    Labels:        <none>
    Capacity:      5Gi
    Access Modes:  RWO
    No events.
  4. Create pod which uses the persistent volume claim

    Example spec:

    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        name: redis
        role: master
      name: test-storageos-redis-pvc
    spec:
      containers:
        - name: master
          image: kubernetes/redis:v1
          env:
            - name: MASTER
              value: "true"
          ports:
            - containerPort: 6379
          resources:
            limits:
              cpu: "0.1"
          volumeMounts:
            - mountPath: /redis-master-data
              name: redis-data
      volumes:
        - name: redis-data
          persistentVolumeClaim:
            claimName: pvc0001

    Download example

    Create the pod:

    $ kubectl create -f examples/volumes/storageos/storageos-pvcpod.yaml

    Verify that the pod has been created:

    $ kubectl get pods
    NAME                       READY     STATUS    RESTARTS   AGE
    test-storageos-redis-pvc   1/1       Running   0          40s

Dynamic Provisioning

Dynamic provisioning can be used to auto-create volumes when needed. They require a Storage Class, a Persistent Volume Claim, and a Pod.

Storage Class

Kubernetes administrators can use storage classes to define different types of storage made available within the cluster. Each storage class definition specifies a provisioner type and any parameters needed to access it, as well as any other configuration.

StorageOS supports the following storage class parameters:

  • pool: The name of the StorageOS distributed capacity pool to provision the volume from. Uses the default pool which is normally present if not specified.
  • description: The description to assign to volumes that were created dynamically. All volume descriptions will be the same for the storage class, but different storage classes can be used to allow descriptions for different use cases. Defaults to Kubernetes volume.
  • fsType: The default filesystem type to request. Note that user-defined rules within StorageOS may override this value. Defaults to ext4.
  • adminSecretNamespace: The namespace where the API configuration secret is located. Required if adminSecretName set.
  • adminSecretName: The name of the secret to use for obtaining the StorageOS API credentials. If not specified, default values will be attempted.
  1. Create storage class

    Example spec:

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: sc-fast
    provisioner: kubernetes.io/storageos
    parameters:
      pool: default
      description: Kubernetes volume
      fsType: ext4
      adminSecretNamespace: default
      adminSecretName: storageos-secret

    Download example

    Create the storage class:

    $ kubectl create -f examples/volumes/storageos/storageos-sc.yaml

    Verify the storage class has been created:

    $ kubectl describe storageclass fast
    Name:           fast
    IsDefaultClass: No
    Annotations:    <none>
    Provisioner:    kubernetes.io/storageos
    Parameters:     description=Kubernetes volume,fsType=ext4,pool=default,secretName=storageos-secret
    No events.
  2. Create persistent volume claim

    Example spec:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: fast0001
    spec:
      storageClassName: fast
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi

    Create the persistent volume claim (pvc):

    $ kubectl create -f examples/volumes/storageos/storageos-sc-pvc.yaml

    Verify the pvc has been created:

    $ kubectl describe pvc fast0001
    Name:         fast0001
    Namespace:    default
    StorageClass: fast
    Status:       Bound
    Volume:       pvc-480952e7-f8e0-11e6-af8c-08002736b526
    Labels:       <none>
    Capacity:     5Gi
    Access Modes: RWO
    Events:
      <snip>

    A new persistent volume will also be created and bound to the pvc:

    $ kubectl describe pv pvc-480952e7-f8e0-11e6-af8c-08002736b526
    Name:            pvc-480952e7-f8e0-11e6-af8c-08002736b526
    Labels:          storageos.driver=filesystem
    StorageClass:    fast
    Status:          Bound
    Claim:           default/fast0001
    Reclaim Policy:  Delete
    Access Modes:    RWO
    Capacity:        5Gi
    Message:
    Source:
        Type:        StorageOS (a StorageOS Persistent Disk resource)
        VolumeName:  pvc-480952e7-f8e0-11e6-af8c-08002736b526
        Namespace:   default
        FSType:      ext4
        ReadOnly:    false
    No events.
  3. Create pod which uses the persistent volume claim

    Example spec:

    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        name: redis
        role: master
      name: test-storageos-redis-sc-pvc
    spec:
      containers:
        - name: master
          image: kubernetes/redis:v1
          env:
            - name: MASTER
              value: "true"
          ports:
            - containerPort: 6379
          resources:
            limits:
              cpu: "0.1"
          volumeMounts:
            - mountPath: /redis-master-data
              name: redis-data
      volumes:
        - name: redis-data
          persistentVolumeClaim:
            claimName: fast0001

    Download example

    Create the pod:

    $ kubectl create -f examples/volumes/storageos/storageos-sc-pvcpod.yaml

    Verify that the pod has been created:

    $ kubectl get pods
    NAME                          READY     STATUS    RESTARTS   AGE
    test-storageos-redis-sc-pvc   1/1       Running   0          44s

Analytics