Kuma 1.0.6 Released With Deep Status Checks & Five New Load Balancers

We are happy to announce a new release that ships with some major new features and improvements, Kuma 1.0.6! We suggest to upgrade to this new version to start using the greatest and latest.

With 1.0.6 the Kuma GUI introduced the first few chart visualizations, more to come!

Notable Improvements in 1.0.6

• 🚀 Deep status checks on data planes proxies, their services and Kuma’s services!
• 🚀 Five new load balancers in addition to round robin: least request, ring hash, consistent hash, random & maglev!
• ⚠️ Deprecating Envoy xDS V2. Introduced support for Envoy xDS V3.
• Fixed a bug affecting the outbound reconciler in Universal mode.
• Performance improvements in Universal mode when storing data in Postgres.
• And more!

For a complete list of features and updates, take a look at the full changelog.

Deep Status Checks

One of the most challenging things with service mesh is understanding - when things go wrong - exactly where they go wrong! With this new release we are introducing deep status checks that allow us to identify where problems occur on the data plane: our services or the Envoy data plane proxies. We have updated both the GUI and the CLI in order to retrieve this information:

We have also updated the services status checks, which can now have three different statuses: Online, Offline, Partially Degraded.

Of course the “kumactl” CLI can also be used to retrieve this information, like:

kumactl inspect services
# SERVICE                        STATUS               DATAPLANES
# demo-app_kuma-demo_svc_5000    Partially Degraded   2/2
# redis_kuma-demo_svc_6379       Online               1/1

New Load Balancers

This new release also ships with new load balancers for our TrafficRoute policies, allowing us to now choose between five load balancers for our traffic:

• Round Robin
• Least Request
• Consistent Hashing
• Random
• Maglev

Since this feature is available in TrafficRoute, that also means we can have different load balancing rules for different traffic paths. For example communication from a client service to a redis service can be roundRobin, but communication to backend can be leastRequest, like:

type: TrafficRoute
name: route-example
mesh: default
sources:
  - match:
      kuma.io/service: client
destinations:
  - match:
      kuma.io/service: redis
conf:
  loadBalancer:
    roundRobin: {}
  split:
    - weight: 100
      destination:
        kuma.io/service: redis
--
type: TrafficRoute
name: route-example
mesh: default
sources:
  - match:
      kuma.io/service: client
destinations:
  - match:
      kuma.io/service: backend
conf:
  loadBalancer:
    leastRequest: {}
      choiceCount: 8
  split:
    - weight: 100
      destination:
        kuma.io/service: backend

Join us on the community call!

Join us on our community channels to learn more about Kuma, including our official Slack chat. The community channels are useful to get up and running with Kuma, as well as to learn how to contribute to and discuss the project roadmap. Kuma is a CNCF Sandbox project: neutral, open and inclusive.

The next community call will be hosted on January 20th at 8:30am PST. Also don’t forget to follow Kuma on Twitter and star it on GitHub!

Upgrading

Be sure to carefully read the Upgrade Guide before upgrading Kuma.