Casos de uso para aplicaciones tradicionales en un mundo de contenedores
1 like•125 views
This document discusses using stateful applications on Kubernetes. It describes how containers are inherently stateless but Kubernetes provides tools like volumes and StatefulSets to manage state. Volume plugins allow connecting containers to various storage backends. PersistentVolumes and PersistentVolumeClaims provide an API for storage requests. StatefulSets ensure ordered deployment and stable networking for stateful applications. Real-world examples from SUSE include containerizing OpenStack and Cloud Foundry platforms.
Casos de uso para aplicaciones tradicionales en un mundo de contenedores
- 1. Juan Herrera Sales Engineer [email protected] Statefull apps on Kubernetes Use cases for traditional apps on the containerized world
- 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
- 17. 17 Q & A
- 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.