Downloaded 18 times
Uploaded byEDB
Advanced Database Patterns for Kubernetes
Oscar Herrera is the SVP of Global Services and Field CTO at EnterpriseDB. The document discusses database design patterns for Kubernetes including: - EPAS which provides a containerized PostgreSQL database with high availability. - Operators which extend Kubernetes capabilities by automating tasks like backups and resizing. - Sidecars which add functionality like monitoring and logging to database containers. - Service meshes which provide reliable communication between microservices through proxies. The patterns aim to abstract databases from applications and provide scalable, reliable database deployments in container and microservices environments.
Advanced Database Patterns for Kubernetes
- 1. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. K8s Design Patterns Oscar M Herrera SVP Services and Field CTO 1
- 2. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. HELLO!!! • Oscar M. Herrera • SVP Global Services and Field CTO •Working with Open Source since, 1996 • Member of the free software foundation • GNU Projects, Hurd, GCC, GDB, Bash, GNOME •Working with PostgreSQL since 7.3, 2002 •Large Scale Open Source Deployments • Largest Implementation, 4000 PostgreSQL database across 3 data centers •9 Years at Deloitte Consulting • Last 2 as the Principal for Architecture and Engineering practice • Claim to Fame •Architecture of the first TCP/IP based commercial Client/Server application that used Satellites as a networking infrastructure. GNU is not Unix!
- 3.
- 4. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. EDB BUILDING BLOCK EPAS Database Container Supported Platforms: • Kubernetes • Google K8s Engine • Red Hat OpenShift • Docker Single Database EPAS Master Database Container EPAS Standby Database Container Streaming Replication EFM PGPOOL Database Cluster Read/Write Read
- 5. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. NORMAL KUBERNETES DEPLOYMENT • Write some Deployment, Services, Configmaps, etc… • Deploy them to K8 • Maybe create Helm Chart • YAML, YAML, YAML Success?!
- 6. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. DAY 2 OPERATIONS • Backups? • Upscaling? • Reshuffle Data? • Downscaling without Dataloss? • Healing and Restoring Backups • Configuration? Templating? • Replication?
- 7.
- 8. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. OPERATORS IN SUMMARY An operator is a way of building an application and driving an application on top of Kubernetes, behind Kubernetes APIs. The idea of running complex applications like Postgres in a container require lots of domain-specific knowledge Kubernetes PostgreSQL Operator
- 9. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. OPERATORS • Important ? • Extended Native Kubernetes Capabilities • Codify human knowledge • Are scalable, repeatable and standardize operational procedures • Increase operational resiliency while reducing burden of operation staff • Any cloud same functionality •Private Cloud VMS •Public Cloud Instances •Kubernetes Everywhere Operator Observe Analyze Act CRD Control Loop
- 10.
- 11. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. SIDECAR PATTERN Sidecar by name is an assisting entity that stays attached with the main application and performs some action to extend or improve the parent container like a sidecar on a motorbikes. Rather than adding additional logics in the main container other than application logics and dependencies, it’s better to employ sidecar container for better performance, enhance functionality and maintainable. EPAS EDB
- 12. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. WHY SIDECARS? • Pros • Applications and Sidecars may be written in different languages • Application code should not have to change • Because of proximity (same container group), latency should be low • Even if applications don’t provide extensibility, you can add functionality through a Sidecar • Cons • Maybe overkill. If your app is small, you may want to bake in the functionality • If the Sidecar functionality needs to scale differently than or independently from the main applications, you may want to make it a separate hosted service • When inter-process communication needs to be optimized, you may not want to use the Sidecar Pattern. EPAS Monitoring Logging Configuration Network Services Container POD
- 13. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. SIDECARS @ EDB PEM Integration Prometheus Integration Distributed Logging Integration ElasticSearch/Splunk Integration EFM Integration Service Mesh Integration Third Party Failover mechanisms Audit log aggregation SSL Termination Compliance Monitoring Connection Pooling Configuration Management Access Control
- 14.
- 15. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. SERVICE MESH PATTERN A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. EPAS EPASEPAS Manager Mixer Auth
- 16. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. WHY SERVICE MESH? • Evolution in thinking for scalability • Web apps have always had to manage complex service communications • 3-Tier application model managed complex communication but limited scope to 2 hops • Scalability constrained by tier scalability • Microservices Scale • Each tier is split into many services along functional domains • Scalability based on additional functional decomposition • Can scale on demand and under load • Increase scalability comes with it increase complexity and exponential growth in the complexity of communication across tiers Web Serving App Logic Data Store 3-Tier Model Web App Data Store Web App Data Store Web App Data Store Web App Data Store Microservice Model
- 17. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. WHY SERVICE MESH? Because our customers are always on and demand performance zero downtime, minimal service interruptions, increase performance
- 18. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. SERVICE MESH @ EDB EPAS Envoy Master DB Service Pod Manager Mixer Auth Control Plane API Streaming Replication Control flow during request process Write/Read Request EPAS Envoy Standby DB Service Pod Read Request Policy Check Telemetry EPAS Envoy Standby DB Service Pod Failover is control by the control plane Promotion is control by the envoy agent Traffic redirection is managed by the control plane • Secure • Scalable • Reliable • Manageable
- 19. “champagne wishes andcaviar dreams.” EPAS Envoy Master DB Service Pod Manager Mixer Auth Control Plane API Control flow during request process Write/Read Request EPAS Envoy Master DB Service Pod Write/Read Request Policy Check Telemetry EPAS Envoy Master DB Service Pod EPRS 7 Envoy MMR Service Pod EPRS 7 Envoy MMR Service Pod EPRS 7 Envoy MMR Service Pod
- 20. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. CONCLUSION It is no longer just about the databases for successful scalable deployments of databases in containers and microservices we need to look at the entire infrastructure. Make the best use of architectural pattern that abstract our database from applications moving at the speed of business.
- 21. CONFIDENTIAL © CopyrightEnterpriseDB Corporation, 2018. All rights reserved. THANK YOU info@enterprisedb.com www.enterprisedb.com 2 1