Building a Service Mesh with NGINX Owen Garrett.pptx
- 2. Building a Service Mesh with NGINX Owen Garrett, Faisal Memon Products & Engineering, NGINX
- 3. Operating a distributed application is hard Static, Predictable Monolith: Dynamic, Distributed App: Fast, reliable function calls Local debugging Local profiling Calendared, big-bang upgrades ‘Integration hell’ contained in dev Slow, unreliable API calls Distributed fault finding Distributed tracing In-place dynamic updates ‘Continuous integration’ live in prod More things can go wrong, it’s harder to find the faults, everything happens live
- 4. FrontEnd RecommendEng InventoryDB ImageRender AdminConnector UserState PricingEng API-fe N • Security • Instrumentation • Tracing • Traffic Control
- 5. Precursors to Service Mesh 1
- 6. NGINX per-Pod Proxy Use NGINX Per-Pod Proxy: • To intercept traffic to a single pod • Implement access control, metrics and tracing, web app firewall for that service Complexity: Simple • Single point of configuration, simple • Fully integrated into pod – easy build, test and deployment Each Pod in Service B has a dedicated proxy. We rely on K8s (kubeproxy) to load-balance traffic to Service B B A kubeproxy
- 7. What about egress traffic? • Why might this be a problem? 1. Cannot automatically perform mTLS. Need to rely on application to make TLS requests, or rely on overlay network and K8s Network Policies for encryption and authorization 2. Metrics and traces are generated on server-side, not client-side, so do not measure latency effect of K8s network No control of egress traffic, exiting pod Full control of ingress traffic, entering pod
- 8. Simple Mesh Use NGINX Simple Mesh: • When the application only needs to talk to a small, well-known set of external services Complexity: Not very simple! • Need to know all egress targets in advance • Fully integrated into pod – easy build, test and deployment Ingress Traffic – exactly as the per-Pod proxy configuration. Egress Traffic – application talks to local NGINX IP address, achieved by e.g. DNS manipulation or IP tables. NGINX needs a virtual server for each egress service.
- 9. Service Mesh Use a Service Mesh (Istio, Linkerd): • When you don’t know the topology of the application • When you want an off-the-shelf solution • When the specific service mesh capabilities match your requirements Complexity: Medium-High Service Mesh technology is not fully mature, so operating, troubleshooting and debugging it requires considerable technical expertise. Control Plane e.g. Istio’s Pilot/Mixer/Citadel Sidecar Proxy Service A Sidecar Proxy Service B Sidecar Proxy Service C Sidecar Proxy Service D
- 11. Why is NGINX building a Service Mesh? What are the attributes of modern applications? • Hybrid (microservice and legacy) • Web and API • Multiple technology stacks What is needed to deliver these applications? • Load Balancer / App Delivery • Specialized API management • Internal Service Mesh
- 12. NGINX Features and Principles Initial Features • Mutual TLS • Instrumentation • Tracing • Traffic Control Core Principles • Hybrid Applications first • Lightweight and Performant • Architectural Simplicity • Use CNCF etc. projects whenever possible
- 13. What is NGINX building? Data Plane East/West traffic Control Plane Management Plane Infrastructure Kubernetes VMware AWS Bare Metal SVC SVC SVC SVC SVC SVC Conf Db Kubernetes Service Registry Inventory VMware, AWS… Inventory
- 14. What is NGINX building? Data Plane East/West traffic Control Plane Management Plane Infrastructure Kubernetes VMware AWS Bare Metal SVC SVC SVC SVC SVC SVC Conf Db Kubernetes Service Registry Inventory VMware, AWS… Inventory
- 15. What is NGINX building? Data Plane East/West traffic Control Plane Management Plane Infrastructure Kubernetes VMware AWS Bare Metal NGINX Service Mesh control plane SVC SVC SVC SVC SVC SVC Topology Policies Conf Db CLI / API $>_ Kubernetes Service Registry Inventory VMware, AWS… Inventory
- 16. What is NGINX building? Data Plane East/West traffic Control Plane Management Plane Infrastructure Kubernetes VMware AWS Bare Metal NGINX Service Mesh control plane SVC SVC SVC SVC SVC SVC Topology Policies Conf Db CLI / API $>_ Kubernetes Service Registry Inventory VMware, AWS… Inventory SPIRE
- 17. What is NGINX building? Data Plane East/West traffic Control Plane Management Plane Infrastructure Kubernetes VMware AWS Bare Metal NGINX Service Mesh control plane SVC SVC SVC SVC SVC SVC Topology Policies Conf Db CLI / API $>_ Kubernetes Service Registry Inventory VMware, AWS… Inventory SPIRE Grafana OpenTracing
- 18. What’s in the dataplane? • NGINX ◦ OpenTracing module (3rd party, open source) ◦ Prometheus module (open sourced) ◦ SPIFFE support (to-be-open sourced) ◦ NGINX Plus ◦ Sophisticated configuration for fully-hitless reloads SVC
- 19. Walkthrough 3 19
- 21. Find the balance Cost to operate Complexity, Interdependencies, Speed of Change Single simple app Many complex, interdependent apps Using native Kubernetes and other services Using service mesh As service meshes mature, their cost will go down
- 22. Solve today’s problem, today • Identify the problem ◦ Security? Visualization? Tracing? Advanced traffic control? • Identify the solution with the minimum technology to solve the problem ◦ Vanilla Kubernetes with Ingress Controller ◦ Per-Service or per-Pod load balancer ◦ “Full-fat” Service Mesh
- 23. Owen Garrett, Faisal Memon owen@nginx.com / faisal@nginx.com Thank you
Editor's Notes
- #7: Traffic to pod is terminated by NGINX NGINX forwards traffic to other microservices in Pod Apply policies to traffic Very common when Application does not handle HTTP or HTTPS well, e.g. php-fpm Candidate Implementation: Embed NGINX instance in each pod and expose NGINX port. Simple NGINX virtual server manages traffic and proxy_pass to local app instance Does not intercept egress traffic, from pod to outside Attributes Embeds additional (lightweight 2Mb) process in each pod Very simple to configure and test. Configuration generated at pod build time Manages traffic to pod. Can’t implement advanced load balancing, retries or blue-green; can’t process egress traffic This solution is typically developed by the App team and is ‘invisible’ to operations.
- #8: In additional, load advanced load balancing done by per-Service proxy
- #9: Not appropriate for a general application where you do not know the topology, as it’s too difficult to manage the NGINX configuration Some NGINX users have created a sidecar proxy using the simple mesh approach. This requires manual configuration for the app. Provided as “Fabric Model” Issues Tooling to deploy is complex No control plane No easy, automated update of credentials No live management of policies or routing Usability is a challenge