Profiles¶
A Profile custom resource (CR) is used to perform operations on K10 Profiles. You can learn more about using K10 Profiles at Location Configuration.
Example Profile Operations¶
Create Profile Secret¶
When creating a Profile, you first need to create a Kubernetes secret that holds the credentials for the location associated with the profile. The examples below use an S3 bucket and therefore requires a properly formatted S3 secret.
$ kubectl create secret generic k10-s3-secret \
--namespace kasten-io \
--type secrets.kanister.io/aws \
--from-literal=aws_access_key_id=AKIAIOSFODNN7EXAMPLE \
--from-literal=aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
For complete documentation of secret formats, refer to Profile Secret Types.
Create Location Profile¶
With a secret already defined, you can now create a Location Profile. Location profiles can be used for import as well as export operations
$ cat <<EOF >>sample-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: sample-profile
namespace: kasten-io
spec:
type: Location
locationSpec:
credential:
secretType: AwsAccessKey
secret:
apiVersion: v1
kind: Secret
name: k10-s3-secret
namespace: kasten-io
type: ObjectStore
objectStore:
name: profile-s3-bucket
objectStoreType: S3
region: us-east-2
EOF
$ kubectl apply -f sample-profile.yaml
profile.config.kio.kasten.io/sample-profile created
# make sure it initializes and validates properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS
sample-profile Running
sample-profile Success
For complete documentation of the Profile CR, refer to Profile API Type.
Create Infrastructure Profile¶
The example demonstrates how to create a Ceph Infrastructure Profile, but an analogous approach applies to creating an OpenStack Profile.
First, create a secret with the Ceph provider credentials as described in Ceph KeyRing Secret.
$ cat <<EOF >>sample-ceph-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: sample-ceph-profile
namespace: kasten-io
spec:
type: Infra
infra:
type: Ceph
ceph:
monitor: 10.0.0.10:6789
pool: my-pool
credential:
secretType: cephKeyring
secret:
apiVersion: v1
kind: Secret
name: k10-ceph-infra-secret
namespace: kasten-io
EOF
$ kubectl apply -f sample-ceph-profile.yaml
profile.config.kio.kasten.io/sample-ceph-profile created
# make sure it initializes and validates properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS
sample-ceph-profile Running
sample-ceph-profile Success
For complete documentation of the Profile CR, refer to Profile API Type.
Create Kanister Profile¶
Similarly to a Location Profile, you can create a Kanister Profile which is used to store artifacts generated for applications instrumented with a Kanister blueprint. K10 will currently use the earliest created Kanister Profile.
$ cat <<EOF >>kanister-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: kanister-profile
namespace: kasten-io
spec:
type: Kanister
kanister:
credential:
secretType: AwsAccessKey
secret:
apiVersion: v1
kind: Secret
name: k10-s3-secret
namespace: kasten-io
location:
type: ObjectStore
objectStore:
name: profile-s3-bucket
objectStoreType: S3
region: us-east-2
EOF
$ kubectl apply -f kanister-profile.yaml
profile.config.kio.kasten.io/kanister-profile created
# make sure it initializes and validates properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS
kanister-profile Running
kanister-profile Success
For complete documentation of the Profile CR, refer to Profile API Type.
Update Profile¶
To update a Profile edit the spec portion of a Profile CR using your preferred method of submitting resource changes with kubectl.
$ kubectl apply -f sample-profile-changed.yaml
profile.config.kio.kasten.io/sample configured
Once the change is submitted, K10 will re-validate the profile and update .status.validation accordingly.
$ kubectl get profiles.config.kio.kasten.io -w
NAME STATUS
sample-profile Running
sample-profile Success
Since K10 processes API object changes asynchronously, to avoid confusion with a previous Profile status, it is recommended as convention that the status portion of the Profile is omitted when submitting changes.
Delete Profile¶
You can delete a Profile using the following command.
# delete profile "sample-profile" for K10 installed in "kasten-io"
$ kubectl delete profiles.config.kio.kasten.io sample-profile --namespace kasten-io
profile.config.kio.kasten.io "sample-profile" deleted
Profile API Type¶
The following is a complete specification of the Profile CR.
# Standard Kubernetes API Version declaration. Required.
apiVersion: config.kio.kasten.io/v1alpha1
# Standard Kubernetes Kind declaration. Required.
kind: Profile
# Standard Kubernetes metadata. Required.
metadata:
# Profile name. May be any valid Kubernetes object name. Required.
# Profile name is not mutable once created.
name: sample-location-profile
# Profile namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Profile parameters. Required.
spec:
# Type of Profile. Required
# Valid values are Location, Kanister, Infra
type: Location
# Only one of the profile type sections can be specified
# NOTE: camelCasing of the key is important
locationSpec:
# Credentials associated with profile location. Required.
credential:
# Type of secret being specified. Required.
# Valid values are:
# # AwsAccessKey (Amazon S3 and Generic S3)
# # GcpServiceAccountKey (Google Cloud Storage)
# # AzStorageAccount (Azure Storage)
secretType: AwsAccessKey
# Reference to K8s secret with credentials of secretType. Required.
secret:
# Standard Kubernetes API Version. Must be 'v1'. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Must be 'secret'. Required.
kind: secret
# Secret name. May be any valid Kubernetes secret name. Required.
name: sample-profile-secret
# Secret namespace. Must be K10 installed namespace . Required.
namespace: kasten-io
# Location for profile data. Required.
location:
# Type of location being specified. Required.
# Valid values are ObjectStore, FileStore
locationType: ObjectStore
# When the type above is ObjectStore. Required.
# Only one of the location type sections can be specified
objectStore:
# Type of object store. Required
# Valid values are:
# # S3 (Amazon S3 and Generic S3)
# # GCS (Google Cloud Storage)
# # Azure (Azure Storage)
objectStoreType: S3
# The endpoint for object store API. Optional.
# Can be omitted unless an S3 compatible provider is used.
endpoint: ''
# If set to true, do not verify SSL cert. Optional.
# Default, when omitted, is false
skipSSLVerify: false
# Name of the object store bucket. Required
name: gmm-test
# Region valid for the object store provider.
# Required, if supported by provider.
# If provider does not support region, pass ""
region: us-east-2
# Path within bucket for profile artifacts. Optional.
# If not used, it will be generated by the system and
# updated during delayed initialization and validation.
# If used, it requires pathType below as well.
path: k10/q4ees3b2zilluaxw/migration
# Type of the path within the bucket above. Optional.
# Defaults to Directory if not specified.
pathType: Directory
# The protection period for immutable backups. Optional.
# Must be shorter than the bucket default retention
# period minus 20 days.
protectionPeriod: 240h
# When the type above is FileStore. Required.
# Only one of the location type sections can be specified
fileStore:
# Name of the Persistent Volume Claim. Required.
claimName: test-pvc
# Path within the PVC mount for profile artifacts. Optional.
# If not used, it will be generated by the system and
# updated during delayed initialization and validation.
path: k10/q4ees3b2zilluaxw/migration
# Optional: Make export to this profile infra-portable.
# Default: false
infraPortable: false
# When type above is Kanister - Kanister profile. Required.
# Only one of the profile type sections can be specified
# K10 currently only uses the oldest valid Kanister profile
# NOTE: camelCasing of the key is important
kanister:
# Credentials associated with profile location. Required.
credential:
# same content as credential in location above
# Location for profile data. Required.
location:
# same content as location in location above
# When type above is Infra - Infrastructure profile. Required.
# Only one of the following profile type sections can be specified
# NOTE: camelCasing of the key is important
infra:
# type of Infrastructure profile. Required
# Valid values are OpenStack, Ceph, Portworx or VSphere
type: OpenStack
# When type of this Infra profile above is OpenStack. Required.
# Only one of the following infra profiles can be specified
# NOTE: camelCasing of the key is important
openStack:
# Endpoint for the Keystone auth provider. Required
keystoneEndpoint: https://my-keystone-ip:1234
# When type of this Infra profile above is OpenStack. Required.
# Only one of the following infra profiles can be specified
# NOTE: camelCasing of the key is important
ceph:
# Endpoint for the Ceph monitor to be used. Required.
monitor: 10.0.0.10:6789
# Name of the Ceph pool associated with this profile. Required.
pool: my-ceph-pool
portworx:
# The namespace of the Portworx service.
namespace: kube-system
# The name of the Portworx service.
serviceName: portworx-service
vsphere:
# The vSphere endpoint
serverAddress: vsphere.server.com
# Credentials associated with the infrastructure provider. Required.
credential:
# Type of secret being specified. Required.
# Valid values are:
# # OpenStackAccount (OpenStack storage provider)
# # CephKeyring (Ceph storage provider)
# # PortworxKey (Portworx storage provider)
# # VSphereKey (vSphere storage provider)
secretType: OpenStackAccount
# Reference to K8s secret with credentials of secretType. Required.
secret:
# Same format as above
# #####################
# Status of the Profile. Users should not set any data here.
status:
# Validation status of the Profile
# Valid values are:
# # Pending - profile has been created
# # Running - undergoing initialization and validation
# # Success - successfully initialized and validated
# # Failed - not properly initialized on validated
# Only profiles which have status of Success should be used
validation: Success
# An array of any validation or initialization errors encountered.
error: null
# Hash of the spec portion of the profile.
# Used internally to determine when successfully validated profiles
# need to be reprocessed.
hash: 3369880242
Profile Secret Types¶
The following are the different secret types and formats to be used with profiles.
AWS S3 and S3 Compatible Bucket¶
When a Profile is using an S3 or S3-compatible bucket location, the credential secret must follow the format below. In order to use temporary security credentials, you can generate an IAM role and provide it as a part of the S3 secret as shown below. K10 supports the generation of temporary credentials to perform generic backups, export collections to an object store, and for EBS/EFS snapshot operations.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-s3-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: secrets.kanister.io/aws
# Secret data payload. Required.
data:
# Base64 encoded value for key with proper permissions for the bucket
aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
# Base64 encoded value for the secret corresponding to the key above
aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
# (optional field) Base64 encoded value for AWS IAM role
role: YXJuOmF3czppYW06OjAwMDAwMDAwMDAwMDpyb2xlL2Zha2Utcm9sZQo=
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-s3-secret \
--namespace kasten-io \
--type secrets.kanister.io/aws \
--from-literal=aws_access_key_id=AKIAIOSFODNN7EXAMPLE \
--from-literal=aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
GCS Bucket¶
When a Profile is using a GCS Storage bucket location the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-gcs-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for project with proper permissions for the bucket
project-id: bXktcHJvamVjdC1pZAo=
# Base64 encoded value for the SA with proper permissions for the bucket
# This value is base64 encoding of the service account json file when
# creating a new service account.
service-account.json: <base64 encoded SA json file>
Alternatively, the secret can be created using kubectl as follows. The example assumes that GCP service account json with the proper permissions for accessing your bucket is in your working directory.
$ kubectl create secret generic k10-gcs-secret \
--namespace kasten-io \
--from-literal=project-id=my-project-id \
--from-file=service-account.json=./gcs-access-service-account.json
Azure Storage Bucket¶
When a Profile is using an Azure Storage bucket location the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-azure-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for account with proper permissions for the bucket
azure_storage_account_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEVBQ0NUCg==
# Base64 encoded value for the key corresponding to the account above
azure_storage_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-azure-secret \
--namespace kasten-io \
--from-literal=azure_storage_account_id=AKIAIOSFODNN7EXAMPLEACCT \
--from-literal=azure_storage_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Ceph KeyRing Secret¶
When an Infrastructure Profile is being configured for Ceph storage access the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-ceph-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for the client.user to be used with the Ceph provider
# The value should not include the 'client' portion of the user name.
ceph_user: Y2VwaC11c2VyCg==
# Base64 encoded value for the (already base64 encoded) keyring file to be used
# with the user.
ceph_keyring: <base64 encoded key ring file>
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-ceph-secret \
--namespace kasten-io \
--from-literal=ceph_user=sample-ceph-user \
--from-file=ceph_keyring=./my-ceph-client.keyring
OpenStack Account Secret¶
When an Infrastructure Profile is being configured for accessing storage that support the Open Stack Cinder interface the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-openstack-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for an OpenStack user name to use with provider
os_username: b3MtdXNlcm5hbWUK
# Base64 encoded OpenStack password
os_password: b3MtcGFzc3dvcmQK
# Base64 encoded OpenStack domain
os_domain: b3MtZG9tYWluCg==
# Base64 encoded OpenStack project
os_project: b3MtcHJvamVjdAo=
# Base64 encoded OpenStack region
os_region: b3MtcmVnaW9u
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-openstack-secret \
--namespace kasten-io \
--from-literal=os_username=my-os-username \
--from-literal=os_password=my-os-password-user \
--from-literal=os_domain=my-os-domain \
--from-literal=os_project=my-os-project
Portworx Key Secret¶
When an Infrastructure Profile is being configured for accessing storage that supports the Portworx interface, the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-portworx-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for a Portworx jwt issuer.
pwx_issuer: cHd4X2lzc3Vlcg==
# Base64 encoded value for a Portworx jwt secret.
pwx_secret: cHd4X3NlY3JldA==
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-portworx-infra-secret \
--namespace kasten-io \
--from-literal=pwx_issuer=my-pwx-issuer \
--from-file=pwx_secret=my-pwx-secret
vSphere Key Secret¶
When an Infrastructure Profile is being configured for accessing storage that supports the vSphere interface, the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-vsphere-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for a vSphere user.
vsphere_user: dnNwaGVyZV91c2Vy
# Base64 encoded value for a vSphere password.
vsphere_password: dnNwaGVyZV9wYXNzd29yZA==
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-vsphere-infra-secret \
--namespace kasten-io \
--from-literal=vsphere_user=my-vsphere-user \
--from-file=vsphere_password=my-vsphere-password