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](https://github.com/Kong/kuma/blob/master/CHANGELOG.md#060)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:

1. - Round Robin
2. - Least Request
3. - Consistent Hashing
4. - Random
5. - 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: client-to-redis
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: client-to-backend
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

## [](https://gist.github.com/subnetmarco/7ca188a39264304aebc2c1586c15e819#community)Join us on the community call!

Join us on our [community channels](https://kuma.io/community)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 [February 3rd at 8:30am PT](https://kuma.io/community)February 3rd at 8:30am PT. Also don’t forget to follow Kuma [on Twitter](https://twitter.com/kumamesh)on Twitter and star it [on GitHub](https://github.com/kumahq/kuma)on GitHub!

## [](https://gist.github.com/subnetmarco/7ca188a39264304aebc2c1586c15e819#upgrading)Upgrading

Be sure to carefully read the [Upgrade Guide](https://github.com/Kong/kuma/blob/master/UPGRADE.md)Upgrade Guide before upgrading Kuma.