Weaveworks Embeds Observability Portal in GitOps Platform for Kubernetes
Weaveworks has added observability tools to its GitOps platform for Kubernetes environments with no additional configuration effort required.
Company COO Steve George says the addition of an observability portal to the Weave Kubernetes Platform (WKP) to monitor the health of clusters and overall system performance is a natural extension, given the scope of the technology.
In addition, with the release of version 2.5 of WKP, Weaveworks is enabling IT teams to troubleshoot entire fleets of clusters on which the company’s GitOps platform is deployed across. Support for standard metrics and logs along with aggregation of alerts are all included, says George.
IT teams can also leverage open source Prometheus monitoring software to collect endpoint data from other platforms running on Kubernetes in addition to the alerts and cluster events generated by Prometheus.
Finally, Weaveworks has added support for single sign-on capabilities and deepened the level of integration it provides with the Amazon Elastic Kubernetes Service (EKS).
Weaveworks is making the case for a GitOps platform based on Flux, an open source tool that automatically ensures the state of a cluster matches the configuration stored in a Git repository. It uses an operator in the cluster dubbed Flagger to trigger application deployments to Kubernetes without requiring IT teams to acquire and deploy a dedicated continuous delivery platform. Flux monitors all image repositories, detects new images, triggers deployments and updates configurations accordingly.
WKP adds on top of that core platform Team Workspaces, a workflow application for tracking changes to Git-based deployments that can be used by multiple DevOps teams. Each workspace can span multiple Kubernetes clusters to simplify the rollout of applications across a fleet of Kubernetes clusters.
That approach provides the added benefit of improving security and auditing because each pull request made from the repository needs to be authorized and logged, notes George. That audit trail also accelerates troubleshooting, he adds, by making it easier to discover the root cause of an issue across the full stack of a Kubernetes environment that otherwise would be challenging to diagnose.
It’s not clear at what rate organizations are adopting GitOps as a more opinionated instance of a DevOps workflow. However, it’s apparent there is a high correlation between the adoption of GitOps and the transitions organizations are making to Kubernetes. Given the rapid pace of change to microservices-based applications, organizations are attempting to leverage the standard set of application programming interfaces (APIs) that Kubernetes clusters present to automate continuous delivery especially.
IT teams will require observability tools that provide more context than traditional IT monitoring tools to achieve that goal. Each IT team will need to decide for themselves to what degree they want to employ observability tools for a specific application deployment environment versus relying on platforms that observe both legacy IT and more modern Kubernetes environments. Regardless of the path chosen, one way or another observability as a core tenet of a best DevOps workflow is finally becoming a lot easier to achieve.