Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Traffic Control - Managing Egress with Istio

Traffic Control - Managing Egress with Istio

This educational video series will walk you through various application networking challenges, how we have traditionally solved them, service mesh networking concepts to solve them for microservices, and show you how to do it through live demonstration.

The first installment features Christian Posta and Sandeep Parik diving into how to manage egress traffic with Istio.

Watch the video https://youtu.be/hjTLSaK4PH8

Learn more about the technologies used in this video
Istio https://istio.io/
Google Cloud https://cloud.google.com/
Service Mesh Hub http://servicemeshhub.io
Solo.io https://www.solo.io/

Solo.io

July 25, 2019
Tweet

More Decks by Solo.io

Other Decks in Technology

Transcript

  1. Why? For many deployments that communicate with external services, those

    outbound communications need to originate from a known source.
  2. Why? Examples could include downstream APIs or systems that require

    whitelisting, or PCI compliant deployments, where outbound traffic must come from a stable origin.
  3. All outbound traffic must originate from a stable IP Secure

    application sits behind a firewall IP must be whitelisted in firewall configuration Requirements
  4. External Proxy Pro Stable outbound IP Protocol controls Con VM

    and proxy management Coarse-grained traffic controls
  5. kube-static-egress-ip Pro Runs as DaemonSet Con Alpha Single node for

    egress github.com/nirmata/kube-static-egress-ip
  6. Accessing external service Using ServiceEntry, add the external service to

    the Kubernetes service registry apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: se-httpbin-egress spec: hosts: - httpbin.gcp.external addresses: - 34.67.71.77 ports: - number: 80 name: http-port protocol: TCP resolution: STATIC location: MESH_EXTERNAL endpoints: - address: 34.67.71.77 exportTo: ["."]
  7. Configuring egressgateway Create a DestinationRule and Gateway that allows traffic

    from the mesh to the external service apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: dr-httpbin-egress spec: host: istio-egressgateway.istio-system subsets: - name: httpbin --- apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: gw-httpbin-egress spec: selector: istio: egressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - httpbin.gcp.external
  8. Directing traffic Mesh-internal traffic for external service goes to egress

    gateway. Traffic from gateway goes to external service. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: vs-httpbin-egress spec: hosts: - httpbin.gcp.external gateways: - gw-httpbin-egress - mesh http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system subset: httpbin port: number: 80 weight: 100 - match: - gateways: - gw-httpbin-egress port: 80 route: - destination: host: httpbin.gcp.external port: number: 80 weight: 100
  9. Enforcing egress control $ kubectl label ns istio-system istio=system $

    kubectl label ns kube-system kube-system=true $ cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-istio-system-and-kube-dns-only spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kube-system: "true" ports: - protocol: UDP port: 53 - to: - namespaceSelector: matchLabels: istio: system EOF Kubernetes NetworkPolicy prevents bypassing Istio’s egress gateway
  10. Capturing external hosts dns-discovery automatically detects egress traffic and creates

    ServiceEntry objects. github.com/istio-ecosystem/dns-discovery
  11. Istio 1.2 highlights Investing in build, test, and release machinery

    New subteams: Github Workflow, Source Organization, Testing Methodology, Build & Release Automation Theme of this release is predictability Quality of releases Timing of releases Build, Test, Release New Features Global log levels for data and control planes Validate Kubernetes environment using istioctl Annotate services with traffic.sidecar.istio.io/includeOutboundPorts and eliminate need for containerPort Release Predictability
  12. Istio 1.2 highlights Beta → Stable SNI with ingress Distributed

    tracing Service tracing Alpha → Beta Cert mgmt on ingress Config resource validation Config processing with Galley
  13. Added traffic.sidecar.istio.io/includeInboundPorts annotation to eliminate the need for service owner

    to declare containerPort in the deployment yaml file. This will become the default in a future release. Improved locality based routing in multi-cluster environments. Improved outbound traffic policy in ALLOW_ANY mode. Traffic for unknown HTTP/HTTPS hosts on an existing port will be forwarded as is. Unknown traffic will be logged in Envoy access logs. Istio 1.2 for Traffic Management Added support for setting HTTP idle timeouts to upstream services. Improved Sidecar support for NONE mode (without iptables) . Added ability to configure the DNS refresh rate for sidecar Envoys, to reduce the load on the DNS servers. Graduated Sidecar API from Alpha to Alpha API and Beta runtime.
  14. Thank You! Questions or Comments? Find us @christianposta and @crcsmnky

    Learn More • Istio istio.io • Google Cloud cloud.google.com • Solo.io www.solo.io • Gloo gloo.solo.io • Service Mesh Hub servicemeshhub.io Demo • github.com/crcsmnky/istio-egress-gateway