2. 2
”State” is the question!
What happens if we want to explore the benefits of
containerization for already existing applications
not really architected to be deployed on containers?
And, if container native, what to do if some services
in our app need to store state? ?
3. 3
May I move ANY application to containers?
• Even technically possible, not really practical in many cases. Short
answer: NO
• Containers have a stateless behaviour ”per definition” so persistent
local storage (overlayFS) is lost during container’s destroy/create
cycles. That local storage can’t be either shared with other
containers.
• Network visibility between containers is not usually possible.
4. 4
Is that the end of the world?
Kubernetes Volume Management and
StatefulSets, to the rescue!
Kubernetes provides all the required resources and services needed by
containerized applications to overcome those limitations.
5. 5
Dealing with state: Volume management
Stateless
container
Stateful
container
SUSE
Enterprise
Storage
RBD Pool,
iSCSI
Volume, NFS
share , …
External DB
Object Store
…
6. 6
Why use Stateful Containers in traditional apps?
Scale easier
• Simplified deployment to scale faster
• Less manual work
More reliable
• Repeatable and consistent declarative deployment config stored in
git
• User Kubernetes to monitor and maintain desired state
7. 7
Volume management plugins
Different volume plugins (+20) covering any possible storage need
Remote storage
• GCE Persistent Disk
• AWS EBS
• Azure File Storage
• Azure Data Disk
• Dell EMC
• iSCSI
• NFS
• SES – Ceph RBD
• SES – CephFS
• FibreChannel
• OpenStack Cinder
• vSphere
• …..
Ephemeral
• Empty dir (tmpfs)
• K8S API (Secret,
ConfigMap, ..)
• …
Other
• Host path
Kubernetes node
kubelet Container RT
POD
Volume
8. 8
Persistent Volumes & Persistent Volume Claims
Persistent Volume
• First class cluster resources, comparable to Nodes
• API captures de implementation details (NFS, iSCSI, RBD, …)
• Can be provisioned statically or dinamically
• Have capacity, access mode, storage class and reclaim policy
Persistent Volume Claim
• A request for storage
• Includes size and access mode
• Optionally includes a storage class and selectors
9. 9
Static vs Dynamic Provisioning
Static
• Requires admin intervention!
• Volumes are defined beforehand. Volume request may be less or equal the
size of the volume so space may be wasted
Dynamic
• Based on classes of storage (Gold-Silver, Dev-Prod, …)
• Abstracts user requests from implementation. Portable!
• No manual intervention!
10. 10
Example
Persistent volume definition and claim for MySQL storage:
https://kubernetes.io/docs/tutorials/stateful-application/mysql-
wordpress-persistent-volume/
11. 11
Last step … Stateful Sets
Kubernetes feature that give us the required services to do real stateful
app scaling like the one needed to set up database clusters.
The 4 main features are:
• Assign PersistentVolumeClaim for each Pod
• Stable network identifier for Pods (predictable hostnames)
• Ordered deployment (scheduled in order, safe from race conditions
where a service is waiting for another one not ready. Predictable
order solves that)
• Double checking: running + ready (e.g. Swarm only running)
12. 12
Is that enough? Two main patterns to deal with “real world”
Example cluster management operations:
• New member joining a MongoDB cluster …
• Handle node failover, master promotion in a PostgreSQL DB
• Dealing with software upgrades and patching
Two patterns:
• Bot / sidecar pattern (deals with each specific cluster constraints)
• Operator (develop custom resource type)
13. 13
Final notes on Stateful Apps
1
Remember that not all stateful applications scale nicely if their architecture
was not designed for containerization.
Always do extensive testing!!!
15. 15
Real world examples from SUSE
SUSE OpenStack Cloud
• Control panel containerization lead to remove PostgreSQL (active-
pasive) and deploy N-active-active MariaDB/Galera instead
• Other services like Neutron, Cinder or RabbitMQ, where straight
forward.
SUSE Cloud Application Platform
• Deal with CloudFoundry certification
• All possible use cases in one product
16. 16
SUSE Cloud Application Platform (CloudFoundry)
SUSE CAP
SUSE CaaS Platform
SUSE Cloud Foundry
Router
SLE
CC API
SLE
Router
SLE
Diego
Logging
SLE
Diego
SLESLECF
Diego
Diego
CFSLE
Diego
DiegoSLE
SLESLE
UAA
SLE
CF Volume
SLE
SUSE
Enterprise Storage
(CEPH)
Broker
SLE
Portus
SLE
Git
SLE
CI/CD
SLE
SLE SLE
19. 1919
Unpublished Work of SUSE LLC. All Rights Reserved.
This work is an unpublished work and contains confidential, proprietary and trade secret information of SUSE LLC.
Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of their
assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated,
abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE.
Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General Disclaimer
This document is not to be construed as a promise by any participating company to develop, deliver, or market a
product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making
purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The
development, release, and timing of features or functionality described for SUSE products remains at the sole discretion
of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in this
presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-
party trademarks are the property of their respective owners.