Simplified Platform Networking with Pivotal Ingress Router, Powered by Istio and Envoy

Why are Istio and Envoy worthy of all the buzz they receive? We’ve written about this previously. The upshot: Istio and Envoy simplify the communications, security, and observability for microservices. They are particularly useful when you have microservices written in many different development frameworks (Java, Node, Python™, etc).

Now that many organizations have gotten a handle on containers and Kubernetes, IT leaders are investigating the service mesh pattern. That means you’re learning about Istio (the control plane) and Envoy (the sidecar proxy).

We’ve been working with several customers on this service mesh concept for a while now. What have we learned so far? Customers want great outcomes, powered by Istio™ and Envoy™.

It’s not surprising when you think about it. Who doesn’t want great business results, based on practical implementations of important open-source projects?

Here’s are some of the outcomes we’ve delivered so far:

Greater routing guarantees and a stronger security posture. We released TLS ingress down to the application container and greater routing guarantees powered by Envoy over a year ago.

Simplified blue-green deployments. More recently, PCF 2.5 included new weighted routing for Pivotal Application Service (PAS) ingress with Istio and Envoy.

It’s time to announce the next phase of our journey with Istio and Envoy: the Pivotal Ingress Router. We have exciting plans in store for this offering. The Kubernetes^Ⓡ (K8s) community will love the first problem we’re tackling.

For Starters, Pivotal Ingres Router Aims to Automate Access to Your Kubernetes Clusters

We all love a good shell script. If you're like most, you've written scripts to set up ingress routing for Kubernetes cluster. Over time, this can become technical debt, and you want a more reliable approach. Enter Ingress Router.

Ingress Router seeks to completely automate this scenario. Deploy the service alongside Enterprise Pivotal Container Service (PKS). Then, you simply set up DNS and load balancing once with a wildcard. After that, you can enjoy automated routing and load balancing to the K8s APIs of any clusters deployed with PKS, as well as to the workloads that run on them. As the commercial says, “Set it and forget it!”

This is a welcome solution especially for enterprises deploying Kubernetes across clouds. Sure, load balancers are just an API call away in public cloud deployments. That’s not always the case with on-premises environments though. Ingress Router is a single solution for all your environments!

This handy diagram shows what it does. Ingress Router performs HTTP routing to API masters, and TCP Routing to the workloads themselves.

Here’s how it works.

The ingress service watches the PKS API for cluster lifecycle events. When a cluster is created, the service will set up HTTP routing for a subdomain of the prerequisite wildcard DNS name to the new cluster. This enables cluster users to connect to the API of their cluster with the kubectl CLI (or another compatible client) without additional load balancer or DNS configuration.

Then, the service begins watching the API of each cluster for objects of the Istio VirtualService custom resource. When a VirtualService is discovered with an annotation indicating the user wants the workload to be accessible from outside the cluster, the service allocates a dedicated port on the platform ingress proxies for this workload. From there, it updates the object with the assigned host and port so the user can discover where their workload can be accessed. Upon receiving TCP connections on this port, the proxy establishes a backend TCP connection to the workload, enabling traffic from the client over any TCP protocol received by the workload.

Ingress Router runs on Kubernetes. You can install it on your own K8s environment or run it atop Enterprise PKS for an automated “Day 2” experience. (We recommend the latter.)

The product is now available to Pivotal customers via an invite-only alpha, so reach out to your account team if you'd like early access. [Editor's note: the service is now beta.]

Where do we go from here? We plan to extend Ingress Router capabilities to other products in the PCF portfolio, enabling traffic management for multiple Pivotal Application Service (PAS) and PKS environments with a single service.

Avoid the Pitfalls of a Do It Yourself Service Mesh

Lots of engineers are tinkering with Kubernetes, Istio, and Envoy. And by all means, experiment with this tech in your home lab! But as we like to say, smart people with important things to do choose a commercial platform, and then get on with the job of building great software. The same is true for a service mesh: choose your fully managed offering, then get on with delivering value for your organization!

We’ve learned that very few organizations can succeed at scale with homebrew tech. This whitepaper captures what we’ve heard from enterprises over the years.

More to the point, your CEO isn’t going to say “great job building a service mesh.” Your leaders want outcomes, and you should too!

Speaking of outcomes, it’s time to give Pivotal tech a spin.

• Request access to Ingress Router via this form, or by reaching out to your account team.

• Check out the docs for Ingress Router.

• Sign-up for a free trial of Pivotal Web Services.

• Register for SpringOne Platform October 7-10 in Austin. It’s where your peers will gather to discuss the latest open-source tech, development trends, and most importantly, business outcomes!

SAFE HARBOR STATEMENT

This blog contains statements relating to Pivotal’s expectations, projections, beliefs, and prospects which are "forward-looking statements” and by their nature are uncertain. Words such as "believe," "may," "will," "estimate," "continue," "anticipate," "intend," "expect," "plans," and similar expressions are intended to identify forward-looking statements. Such forward-looking statements are not guarantees of future performance, and you are cautioned not to place undue reliance on these forward-looking statements. Actual results could differ materially from those projected in the forward-looking statements as a result of many factors. All information set forth in this blog is current as of the date of this blog. These forward-looking statements are based on current expectations and are subject to uncertainties, risks, assumptions, and changes in condition, significance, value and effect as well as other risks disclosed previously and from time to time by us. Additional information we disclose could cause actual results to vary from expectations. Pivotal disclaims any obligation to, and does not currently intend to, update any such forward-looking statements, whether written or oral, that may be made from time to time except as required by law.

This blog also contains statements which are intended to outline the general direction of certain of Pivotal's offerings. It is intended for information purposes only and may not be incorporated into any contract.  Any information regarding the pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. All software releases are on an “if and when available” basis and are subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal's offerings. Any purchasing decisions should only be based on features currently available.  The development, release, and timing of any features or functionality described for Pivotal's offerings in this blog remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward-looking information in this blog.

Kubernetes is either a registered trademark or trademark of The Linux Foundation in the United States and/or other countries. Istio is either a registered trademark or trademark of Google, Inc. in the United States and/or other countries. Envoy is either a registered trademark or trademark of The Linux Foundation in the United States and/or other countries. Java is a trademark or registered trademark of Oracle and/or its affiliates. Python is a trademark or registered trademark of the Python Software Foundation. Other names may be trademarks of their respective owners.