April 17-19, 2019 -...

SANTA CLARA CONVENTION CENTER, CA

April 17-19, 2019

Delivered by#ContainerWorld

@ContainerWrld

https://tmt.knect365.com/container-world/Information Classification: General

#ContainerWorld

@ContainerWrld

https://tmt.knect365.com/container-world/

Secure, Elastic, Feature-Rich and Observable Ingress for Multi

Cloud/Infra k8s Clusters

Manish CHUGTU

CTO, Cloud Infrastructure and Microservices

Avi Networks

#ContainerWorld

@ContainerWrld


Application Evolution

Application architecture getting more distributed

Apps across multiple

infrastructures

GEN 1

GEN 2

GEN 3

Monolith Apps - On-Prem

Virtual, across 2-3 clouds

Containerized, across multiple public and on-prem clouds

On

-Pre

m

Mu

ltip

le P

ub

lic

an

d

On

-Pre

m C

lou

ds

Controller

Controller

#ContainerWorld

@ContainerWrld


Gen 1: The Monolith App Services

• A few, large appliances provide services

• All traffic funneled through appliances

• All kinds of weird contortions are necessary

for service insertion, IP addressing, etc.

App1App1

App2App2

App3App3

App4App4App5App5

• Still missing: No automation, no uniform object model,

doesn’t scale, no single point of management,

proprietary, poor capacity management/utilization,

no transparent security (encryption, authentication,

RBAC)

Is this enough ?

#ContainerWorld

@ContainerWrld


Gen 2: The Distributed Fabric

• Distributed fabric of load balances provide

services

• All traffic funneled through distributed fabric

• Advantages: Centrally managed, automation,

scales reasonably well, capacity management

App1App1

App2App2

App3App3

App4App4App5App5

Controller

LB

LB

LB?

?

??

?? But Is this enough ?

• Still missing: security - authentication,

authorization & RBAC

#ContainerWorld

@ContainerWrld


Gen 3: Service Mesh

• Traffic is app-to-app - no need for

traffic rerouting to proxies, etc.

• Traffic pattern is app-to-app

• Centrally managed, automation,

scales extremely well, standard

object model, fully secure, full

featured

App1App1

App2App2

App3App3

App4App4

App5App5Ingress gateway

Istio/Avi Controller

But Is that enough ?

#ContainerWorld

@ContainerWrld


Why a Container Based Platform?• Performance

◦ Scale and Speed

▪ OS/Virtualization

• Reliable and Self Healing

◦ Commodity Hardware w/ least HA at metal level.

▪ Including networking switches/routers.

• Resource Utilization to the maximum

▪ Hyper-Converged including Storage (All Kinds)

• Highly Secure

▪ Supporting multiple groups/tenants

• DevOps Cloud

◦ Easy to deploy and manage.

#ContainerWorld

@ContainerWrld


Challenges

#ContainerWorld

@ContainerWrld


Magnifying a Few Issues1. Applications are not written for you or by you :(

• May not bemicroservices based to the core (Just a monolith being containerized).

• Using block storage, logging to files, consuming (or over-committing) resources.

2. Scale Issues are never easy to predict

• Ran into multiple issues with almost all our software when scaling to thousands of Nodes

• Issues were - network partitioning, convergence, load etc.

• Just not easy to detect without proper and correct telemetry information.

Specific example - LB itself. We started seeing issues in convergence/load with thousands of LB’s hitting endpoint to get the state of services.

• Moved from polling to event based (Little better but nothing great).

• One Pattern - ultimately moved from all node LB’s to LB running on just few sets of nodes (of course adding a small penalty for DNS, but worked great after that).

#ContainerWorld

@ContainerWrld


Magnifying a Few Issues

3. Things run fine till you don’t touch them - Upgrades need to be seamless at scale

• Distributed systems - amazing but hard esp. when you need to do an upgrade. Most of our

initial upgrades to core components were not smooth.

• Lot of effort to create upgrade framework, automate pre/in/post flight checks during

upgrade, rollback mechanisms, B/G upgrade strategy, canary deployments etc.

• Monitoring and predictive analytics (event-correlation) really helped during upgrades.

4. You need to build everything with Security in mind

• Need for multi-tenancy.

• Encryption @Flight and @Rest.

• Policy Management etc.

• Secure Front End/Ingress.

#ContainerWorld

@ContainerWrld


Infrastructure Stack for Microservices

Cloud/Resource Manager

Microservices Cluster

Network

Service Proxy/Distributed Load Balancing

Visibility/Application Perf Monitoring

Service Discovery

MicroSegmentation, WAF (L3-L7 Security, XSS, DDoS protection)

Servers – Physical/Virtual

Network

Firewall & Security

Visibility/Monitoring

Service Discovery (IPAM/DNS)

Distributed LB/Traffic Management


Service Schedulers / PaaS

Infrastructure Stack

KubeProxy, HAProxy, NGINX, Envoy

Prometheus, Grafana, ELK

KubeDNS, CoreDNS, Consul

IPTables, Cilium, CNI

Production Ready Clusters

On-Prem H/W

Switches/Routers

Cloud Infra

#ContainerWorld

@ContainerWrld


Service Mesh is…

Servers – Physical/Virtual

Network

Firewall & Security

Visibility/Monitoring

Service Discovery (IPAM/DNS)

Distributed LB/Traffic Management


Service Schedulers / PaaS

Infrastructure Stack

Simplification

Service Mesh

A centrally managed, client-side

load balancer, firewall, and APM.

#ContainerWorld

@ContainerWrld


High Level Service Mesh Architecture

#ContainerWorld

@ContainerWrld


Traffic Management

Easy rules configuration and traffic routing lets you control the flow of traffic and API calls between services.

It simplifies configuration of service-level properties:

• circuit breakers, timeouts, and retries.

Makes it a breeze to set up important tasks like

• A/B testing,

• Canary rollouts,

• Staged rollouts with percentage-based traffic

splits

#ContainerWorld

@ContainerWrld


Security and ObservabilitySecurity:Developers are able to focus on security at the application level.

Mainly provides, the following :

• Underlying secure communication channel

• Manages authentication, authorization, and encryption of service

communication at scale.

Service communications are secured by default, letting you enforce policies

consistently across diverse protocols and runtimes – all with little or no

application changes.

Observability:Provides robust:

• Tracing,

• Monitoring,

• Logging gives deep insights into service mesh deployment.

#ContainerWorld

@ContainerWrld


Service Mesh – A Different Perspective

Operators

Tracing, AppMap, Metrics, App Logs

Security

End to End Authentication

and Authorization,

Traffic Encryption, RBAC,

Policy Enforcement

Developers

Granular CI/CD, Canary, B/G

Deployments,

Resiliency, Mirror, Intelligent

Routing and LB, Retries, Circuit

Breaker,

Error Injection, Rate Limiters.

#ContainerWorld

@ContainerWrld


Great, but…

Is it enough ?

#ContainerWorld

@ContainerWrld


What’s Still Required?

#ContainerWorld

@ContainerWrld


What Enterprises Need in N/S LB?

• Elastic scale out/in and intelligent placement

• Edge LB, ingress and gateway for any environment

• Global LB for availability across regions

• iWAF

• iSSO authentication for SAML, OIDC, LDAP, Kerberos, etc. Enterprises need single sign-on (SSO) for authentication and authorization, and role-based access control (RBAC) that integrates with enterprise active directory (AD) or LDAP.

• Full isolation and enterprise-grade security, including black/white (B/W) lists, rate limiters, denial of service (DoS) protection, web application firewall (WAF), TCP over TLS, zero trust security, and more.

#ContainerWorld

@ContainerWrld


Ingress Gateway Deployment Model

#ContainerWorld

@ContainerWrld


Why Multi-Cluster Use Cases

• High Availability across Clusters.

• Reduce dependency on Public Cloud Infrastructure.

• Multi-Tenancy - Tenant per Cluster.

• Shared Application Pattern.

• Stateful Apps - Not true hyper-converged way.

• Legacy Applications, still sitting on a different infrastructure.

#ContainerWorld

@ContainerWrld


Requirements for Multi-Cloud/Infrastructure Mesh• Multi-Cluster

– Network plugin independent - direct pod reachability not required

– Network topology independent - agnostic of topologies within DC/Cloud

– Isolation - Expose just services that need to be exposed outside of cluster

– Secure - Pods and services aren’t exposed to outside

– Scalable - Doesn’t need larger and larger subnets

• Multi-Cloud

– Multi-cloud ready - works in any IaaS cloud/cluster environment, e.g., VMware, bare metal, OpenStack, AWS, Azure, GCP

• Multi-Region– Multi-region ready - works across regions with GSLB

• Legacy– Seamlessly bridge services in and out of mesh

#ContainerWorld

@ContainerWrld


Multi-Cluster – Routable Clusters

#ContainerWorld

@ContainerWrld


Multi-Cluster – Gateway Based

#ContainerWorld

@ContainerWrld


Multi-Cluster – Federated Mesh

#ContainerWorld

@ContainerWrld


Multi-Cluster – Master Controller

#ContainerWorld

@ContainerWrld


Multi-Cluster/Cloud Deployment

#ContainerWorld

@ContainerWrld


Key Takeaways

#ContainerWorld

@ContainerWrld


#ContainerWorld

@ContainerWrld


Thank You!

April 17-19, 2019 -...

Documents

Transcript of April 17-19, 2019 -...