It’s been almost a year since Jörg Schad, the technical lead for community projects at Mesosphere in San Francisco told us at DevOpsCon that “the next big topics in the container world are service meshes and machine learning.” Suffice it to say, he was right.
It’s not far-fetched to say that Istio is one of the hottest open source projects right now; anyone who’s interested in microservices, containers and even serverless will find it useful. 1.0 was released in August 2018.
If you’d like to see all the changes introduced in Istio 1.0, I invite you to read the release notes. If you want to skim through the release, then these highlights will come in handy:
- Multiple Kubernetes clusters can now be added to a single mesh and enabling cross-cluster communication and consistent policy enforcement. Multi-cluster support is now Beta.
- Networking APIs that enable fine-grained control over the flow of traffic through a mesh are now Beta. Explicitly modeling ingress and egress concerns using Gateways allows operators to control the network topology and meet access security requirements at the edge.
- Mutual TLS can now be rolled out incrementally without requiring all clients of a service to be updated. This is a critical feature that unblocks adoption in-place by existing production deployments.
- Mixer now has support for developing out-of-process adapters. This will become the default way to extend Mixer over the coming releases and makes building adapters much simpler.
- Authorization policies which control access to services are now entirely evaluated locally in Envoy increasing their performance and reliability.
- Helm chart installation is now the recommended install method offering rich customization options to adopt Istio on your terms.
- A lot of effort went into performance including continuous regression testing, large-scale environment simulation and targeted fixes. More details coming soon.
Istio 1.0.2 was released last month. Have a look at the release notes to learn more about what’s included in the latest release.
We need to cut the ode to Istio short and talk about the growing importance of observability. In her DevOpsCon keynote earlier this year, Charity Majors, founder and CEO of Honeycomb.io, laid down some wisdom about how monitoring has not changed significantly in 20 years. She stated that observability is the thing to do because it is different from monitoring – the best practices are different. Majors discussed that the best practices are events, not metrics. There is importance in rich instrumentation, few dashboards, test in production, very few paging alerts, sampling, and not write-time aggregation.
Dashboards, according to Major, are the devil because you want to slice-and-dice in real-time. No users care what the system health is, they only care about the experience. Services need owners, not operators, and software engineers need to focus on observability-driven development!
We’ve covered Istio and observability, now it’s time to marry them and introduce Kiali to you.
Kiali: Observability for the Istio service mesh
According to the project’s website, “Kiali works with Istio [ in OpenShift or Kubernetes] to visualise the service mesh topology, features like circuit breakers or request rates. Kiali also includes Jaeger Tracing to provide distributed tracing out of the box.”
For more information about what this new project can do for you, check out Kiali’s documentation and the GitHub repo.
If you’re here just to run something to see how Kiali works, go to https://www.kiali.io for instructions. You could also try to use their hack script to quickly install OpenShift, Istio, and Kiali like this:
wget https://raw.githubusercontent.com/kiali/kiali/master/hack/cluster-openshift.sh
sh cluster-openshift.sh --kiali-enabled true up
Kiali is published as a docker image on Docker hub at kiali/kiali.
First things first, make sure you have the following installed on your system:
- Go Programming Language, which must be at least version 1.8.3,
- git,
- Docker, and
- make.
To run Kiali on OpenShift after you build it, you should have a running OpenShift environment available to you.
To run Kiali on Kubernetes after you built it, you should have a running Kubernetes environment available to you.
To build Kiali:
- Clone this repository inside a GOPATH. These instructions will use the example GOPATH of “/source/kiali/kiali” but you can use whatever you want. Just change the first line of the below instructions to use your GOPATH.
export GOPATH=/source/kiali/kiali
mkdir -p $GOPATH
cd $GOPATH
mkdir -p src/github.com/kiali
cd src/github.com/kiali
git clone [email protected]:kiali/kiali
export PATH=${PATH}:${GOPATH}/bin
- Install Glide – the Go dependency management tool that Kiali uses to build itself
cd ${GOPATH}/src/github.com/kiali/kiali
make dep-install
- Tell the dependency manager tool to update the Kiali dependencies
cd ${GOPATH}/src/github.com/kiali/kiali
make dep-update
This command is only useful if you add, remove, or modify a dependency. If you are simply git cloning and building from source, you should skip this step.
- Build Kiali
cd ${GOPATH}/src/github.com/kiali/kiali
make build
- At this point, you can run the Kiali tests
cd ${GOPATH}/src/github.com/kiali/kiali
make test
You’re all welcome to contribute to Kiali; it uses the Apache 2 license and does not require any contributor agreement to submit patches.
To setup your environment, check instructions in the Building and Running sections.
The post If you want to check in on the microservices in your Istio service mesh, Kiali’s got you covered appeared first on JAXenter.
Source : JAXenter