Kubernetes and containerized applications allow development teams to iterate fast, deploy efficiently and operate at scale. Kubernetes allows you to orchestrate containers that are highly available. However, in the case of container reschedule, Kubernetes does not provide a great set of primitives to manage your persistent data along with your application containers. In this talk, we will present some of the challenges associated with managing persistent data in Kubernetes and how we can make day 2 operations easier to manage. We will talk about a couple of approaches to solving data persistence problems in multi-cloud environments. During the demos, we will showcase how we address data replication and data encryption challenges.

1. PRESENTED BY
Container Attached Storage for Redis

2. PRESENTED BY
1 Introduction to Kubernetes Storage
2 Challenges with Storage in Kubernetes
3 Cloud Native Storage Solutions
Agenda:
4
5 Demos
Benefits of Container Attached Storage Solutions for Redis

3. PRESENTED BY
“Applications have changed and somebody
forgot to tell storage”—@JeffryMolanus

4. PRESENTED BY
Introduction to K8s Persistent Storage Primitives
Storage Terminology
• Storage Class (SC)
○ Dynamic provisioning of Volumes
• Persistent Volume (PV)
• Persistent Volume Claim (PVC)
• Redis Persistent Data
○ AOF
○ RDB Snapshots
Physical Storage
Persistent Volume Claims
(PVC)
Persistent Volume
(PV)
Cluster
Application
Pod
Redis volumeMounts: /foo
Volumes:
-PVC
claimName
Persistent Volume Claim (PVC)
- 50Gi
- Selector
- StorageClassName
Storage Class
- name: StorageClassName
- annotations:
- name: parameterA value: "x"
- Provisioner: VolumeProvisionerName

5. PRESENTED BY
How does Kubernetes improve storage?
● PVs and PVCs are new terms for known storage concepts
● Kubernetes is
○ Open-source
○ Ubiquitous
○ Extensibility
● Storage Classes provide data agility
■ Enable per workload policies
■ Infrastructure agnostic dynamic provisioning
This will allow for innovation the same way Linux becoming the ubiquitous server
OS allowed for massive innovation

6. PRESENTED BY
Challenges with Kubernetes Persistent Storage
SSD
HDD
SAN
Vendor
Lock In
Storage systems are not multi cloud
Plugin
Solutions
Not flexible and can’t scale
(manual LUN management)
Data
portability
Data needs to follow rescheduled
containers efficiently
Scalability How do you scale and provision storage

7. PRESENTED BY
Cloud Native Storage Solution provides
Cloud and
On-Premises
Software defined storage platform
aggregate capacity & provide scalability
CSI based
APIs
Standardization like RBACs, AuthZ,
AuthN
Data
portability
Data Replication, Encryption & High
availability with scheduler (K8s) of choice
Scalability Dynamic & Thin Provisioning
SSD
HDD
SAN

8. PRESENTED BY
Cloud Native Storage for Stateful applications
● Application centric
○ Present storage to Redis application
● Declarative Configuration
○ YAMLs for SC, PV, PVCs
● API centric
○ Take Volume snapshots via API
● Security features
○ RBACs - CSI interface
○ Encryption

9. PRESENTED BY
Cloud Native Storage for Stateful applications
● Observability
○ Prometheus Integration
○ Grafana Integrations
● Kubernetes Operators
○ Custom Controller
○ Custom Resource Definitions (CRD)

10. PRESENTED BY
It takes two to tango

11. PRESENTED BY
DBaaS-like Experience
The bar - user expectations - has been set by AWS and others
My data is just there - accessible via NoSQL - and works without me
needing to do anything or even think about storage vs. DBs
Why would anyone want to run their own environment, as opposed to
relying on a cloud-provider-service?
Freedom from lock-in & control resulting in greater agility including the
ability to operate across clouds
To achieve these benefits, operations have to be simple and
completely automated with multiple layers of resilience

12. PRESENTED BY
DBs vs. Storage - Summary
Databases:
- Provide application friendly semantics
- Different flavors of databases are optimized for different requirements; for
example ACID compliance vs. eventual consistency
- Depend on a storage layer whether consuming raw disk or using file systems
and virtual disks
Storage:
- Reads/writes data to underlying disks / SSDs or cloud volumes
- May provide HA capabilities for applications - for example ensuring that
Kubernetes will find data when workloads are rescheduled
- Typically provides disaster recovery capabilities, such as cross region or cross
cloud replication so that an entire workload can be restored when needed
- Can provide more efficient incremental backup and faster restore times

13. PRESENTED BY
Benefits of Container Attached Storage (CAS)
for Redis

14. PRESENTED BY
How container attached storage helps Redis
● No need to manage the local disks, they are managed by CAS
● Start with small storage and add disks as needed on the fly
● Nodes are under utilized for eg CPU 40% yet storage is full
○ Ability to increase volumes attached to DB
○ Save costs in cloud and on prem environments
● Redis can be deployed both as deployment or as statefulset. When Redis deployed
as statefulset, you don't need to replicate the data again at CAS level.
● When Redis is deployed as deployment, consider 3 CAS replicas, choose the
StorageClass accordingly.

15. PRESENTED BY
How container attached storage helps Redis
● Take backup of the Redis data periodically and back them up to S3
● Restoration of the same data is possible to the same or any other Kubernetes
cluster
● Database’s consistent snapshots can be cloned and mounted in CI/CD pipeline
○ Helps with blue/green deployment and use of copy data in Dev and Staging
○ Storage can also be used for efficient backup and restore
■ See journal requirements
● Without storage, DB snaps and backups typically not efficient and require that a
new LUN is attached databases dumped to text file(s)
● Cloud native storage can mount backups (DB dumps or storage snaps) in available
environments to avoid backup hit on production environments

16. PRESENTED BY
More benefits to tuned CAS
● Cloud by means of storage classes provides different types of “disks” for the
different type of DB requirements
○ Use PDIM for WAL/Journal over NVMF
○ Use NVMe for caches/oplog (DB depended)
○ Use iSCSI for data dirs
● OpenEBS & Portworx solutions allow for transparent data movement online to
higher tiers without any DB disruption
○ Move data dirs from rotational to SSD (backend)
○ Switch backend protocol from iSCSI to NVMe to reduce latency

17. PRESENTED BY
TCO - Cost Savings
Costs:
● Your devs spin up containers
○ 10-100x the rate of VMs
○ Many storage systems cannot
handle rate of attach / detach
● And 25-30% are stateful requiring
storage
○ Storage from clouds is 5-10x more
expensive than ephemeral disks
Solution:
● Per container storage
○ Granular control
○ Eliminates attach / detach
challenges
● Runs across direct attached
storage including ephemeral
○ Saves 25-30% directly
● Thin provisioning reduces need to
reprovision or over provision
○ Additional 20-25% savings
45-50% $ savings

18. PRESENTED BY
How to build your DBaaS?
To be like a cloud DB as a service, must be:
● No Ops - just works
● Scales
Plus:
● Costs Less
● More flexibility

19. PRESENTED BY
OpenEBS Demo Here
https://github.com/openebs/openebs/tree/master/k8s/demo/redis
https://www.katacoda.com/openebs/scenarios/openebs-intro

20. PRESENTED BY
Portworx Demo
HA Redis on K8s
https://katacoda.com/portworx/scenarios/px-k8s-redis
or
https://www.katacoda.com/portworx/training/redisconf

21. PRESENTED BY
Resources
https://github.com/container-storage-interface
https://github.com/openebs
https://github.com/libopenstorage
https://github.com/operator-framework
https://redis.io/topics/persistence
https://mayadata.io/mdap
https://portworx.com/products/introduction/

22. Thank you!

23. PRESENTED BY