Kurator v0.4.0: Leading a New Chapter in Distributed Cloud-Native Management

Kurator is an open-source distributed cloud-native platform that integrates numerous mainstream cloud-native software stacks, such as Kubernetes, Istio, Prometheus, etc. It is designed to help users build and manage their distributed cloud-native infrastructure, thus driving the digital transformation of enterprises. Kurator embodies the concept of “Infrastructure as Code,” allowing users to manage infrastructure in cloud, edge, or local environments declaratively. Its “out-of-the-box” feature enables users to install cloud-native software stacks with a single click. Leveraging Fleet, Kurator further offers unified management of multi-cloud and multi-cluster environments, greatly enhancing management efficiency.

In the newly released version v0.4.0, Kurator further enriches the unified management capabilities for applications in distributed cloud-native scenarios to better meet the complex requirements of multi-cloud environments. This update primarily includes the following four aspects:

• Adopting GitOps and utilizing Fleet for unified application distribution in multi-cloud environments. This new approach reduces the complexity of configuration in multi-cloud heterogeneous environments and simplifies the management process of distributed deployment.

• Providing a unified cluster metric monitoring solution based on Fleet, Prometheus, and Thanos. This solution aims to improve the comprehensiveness, accuracy, and real-time nature of metric monitoring in complex multi-cloud and multi-cluster environments, thereby increasing operational efficiency and reducing complexity.

• Utilizing Kyverno and Fleet for unified policy management in multi-cloud and multi-cluster environments. This feature will enhance the efficiency of policy management, ensuring consistency and security of policies across all clusters.

• Introducing a new cluster type called “Attached Cluster.” This type allows Kurator to manage Kubernetes clusters built by any tool, located anywhere, further strengthening Kurator’s management of distributed cloud environments.

Unified Application Distribution

As multi-cloud and multi-cluster become more common, effectively deploying and distributing applications in distributed cloud-native environments is becoming increasingly important. Kurator’s unified application distribution function aims to solve the following problems:

• Cumbersome configuration for multi-cloud, multi-cluster environments: In traditional multi-cloud environments, deploying the same application in each environment requires complex configuration, increasing the difficulty of deployment and consuming unnecessary time and human resources.

• Maintaining version consistency challenges: In distributed multi-cloud environments, keeping the application version consistent across all clusters and updating them in a timely manner is challenging.

• Difficulties in managing distributed deployments: After deploying applications in various clusters, one must enter each cluster separately to check whether the deployment was successful and view the deployment status.

Kurator’s unified application distribution function uses GitOps, making it possible to deploy applications to multiple cloud environments with one click and simplifying the configuration process. This method ensures that the application versions in each cluster remain consistent and can be updated promptly. On the Kurator host cluster, users can view and manage the application deployment status of all clusters in a unified manner, thereby improving operational efficiency.

Kurator, based on FluxCD, optimizes deployment efficiency and accuracy with automated application synchronization and deployment processes. Leveraging the advantages of Fleet, it can flexibly adapt to various business and cluster needs, meeting the diverse requirements of users for application distribution.

Kurator’s unified application distribution function provides rich and flexible configuration options. Users can define key parameters such as the application’s source and synchronization policy through YAML configuration files. Additionally, Kurator supports a combination of various source types (including gitRepository, helmRelease, etc.) and synchronization strategies.

Here is an example of unified application distribution:

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: gitrepo-kustomization-demo
  namespace: default
spec:
  source:
    gitRepository:
      interval: 3m0s
      ref:
        branch: master
      timeout: 1m0s
      url: https://github.com/stefanprodan/podinfo
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        interval: 5m0s
        path: ./deploy/webapp
        prune: true
        timeout: 2m0s
    - destination:
        fleet: quickstart
      kustomization:
        targetNamespace: default
        interval: 5m0s
        path: ./kustomize
        prune: true
        timeout: 2m0s

This example configuration demonstrates how to achieve unified application distribution across multiple clusters with Kurator: retrieving application configuration from a Git source, followed by synchronization and deployment through Fleet. Users only need simple configuration to quickly deploy applications to multiple clusters.

For more examples and related information, please refer to: Kurator Unified Application Distribution Documentation

Unified Cluster Metric Monitoring

In complex multi-cloud and multi-cluster environments, unified cluster metric monitoring can enhance work efficiency and reduce operational complexity. Many enterprises face the challenge of effectively monitoring and managing across various clusters to ensure service stability and optimize resource utilization.

Single monitoring tools often fail to meet the needs for comprehensive, timely, and accurate monitoring. This requires operational personnel to enter each cluster separately for checks, increasing the workload and potentially leading to missed or delayed critical metric information. Moreover, different clusters may have different requirements, making management even more complex.

To address these issues, Kurator offers a multi-cluster metric monitoring solution based on Prometheus, Thanos, Grafana, and Fleet, enabling users to easily achieve unified metric monitoring across multiple clusters.

Typically, the process of achieving unified metric monitoring in multi-cluster environments can be summarized as follows:

• Each cluster runs a Prometheus instance responsible for collecting local monitoring data.

• Each Prometheus instance is accompanied by a Thanos Sidecar, which pushes the data collected by Prometheus to remote storage.

• Thanos Query aggregates data from all Thanos Sidecars and remote storage, providing a unified query interface.

• Grafana connects to Thanos Query, thus displaying a unified monitoring view of all clusters.

With the capabilities of Kurator’s Fleet, users do not have to handle the above complex process themselves. Users simply define related configurations in Fleet, and the Fleet Manager automatically completes the process.

Here is an example Fleet configuration that can complete the above process:

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: AttachedCluster
  plugin:
    metric:
      thanos:
        objectStoreConfig:
          secretName: thanos-objstore
grafana: {}

After executing the above configuration, the Fleet Manager will install Prometheus and Thanos Sidecar on both the kurator-member1 and kurator-member2 clusters. Then, users can view the unified monitoring view of all clusters on the Kurator host through the Grafana dashboard.

For more details on using unified cluster metric monitoring, please refer to: Kurator Unified Cluster Metric Monitoring Documentation

Unified Policy Management

In the distributed cloud environment, to meet the unified security protection needs of multi-cloud and multi-cluster, Kurator introduces unified policy management functionality to solve the following problems:

• Inability to manage policies across multiple clusters and apply the same policy across clusters.

• Scattered management of policies in multiple sub-clusters, leading to redundancy and high complexity, preventing unified, efficient configuration and management.

• Inability to uniformly limit resource usage across multiple clusters to ensure all clusters follow the same operational rules and business requirements.

Kurator’s policy management capability is based on Kyverno and utilizes Fleet to implement the cross-cluster distribution and application of policies. This mechanism allows for unified and efficient management of policies across the entire cluster group, avoiding the complexity of managing policies in each sub-cluster separately.

Kurator’s policy management capability is nearly identical to policy management in a single Kubernetes cluster, allowing users to quickly familiarize themselves and get started. Here is an example of implementing unified policy management in Fleet with Kurator:

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: Cluster
    - name: kurator-member3
      kind: CustomCluster
  plugin:
    policy:
      kyverno:
        podSecurity:
          standard: baseline
          severity: high
          validationFailureAction: Audit

In the above configuration file, we apply a Pod security policy with podSecurityStandard as baseline and podSecuritySeverity as high to the clusters in Fleet. When Pod configurations violate the security policy, the corresponding events are recorded in the PolicyReport during their creation process; when validationFailureAction is set to Enforce, the creation or update of illegal resources will be intercepted. All clusters in Fleet will apply this policy, and application operations and development personnel will adjust and configure applications following these Pod security regulations. With Kurator’s unified policy management capability, policy management efficiency can be effectively improved while ensuring the consistency and security of policies across all clusters.

For more information on Kurator’s unified policy management, please refer to: Kurator Unified Policy Management Documentation

AttachedCluster

In the world of cloud-native, the complexity and diversity of infrastructure are unavoidable challenges. For large organizations or companies, they may have deployed multiple Kubernetes clusters in different environments, created by various tools and distributed around the world. To better address this issue, Kurator introduces a new type of cluster in its latest version, the AttachedCluster.

The main purpose of the AttachedCluster is to manage Kubernetes clusters that were not created by Kurator but need to be included in the Kurator fleet management scope. These clusters can be created by any tool and located anywhere. The introduction of this new cluster type extends Kurator’s management capabilities to effectively manage truly distributed cloud environments. In practice, users need to create AttachedCluster resources for Kubernetes clusters they plan to manage with Kurator. These resources contain the cluster’s connection and authentication information, securely stored and managed through Secret. With this information, Kurator can effectively interact with and manage these clusters.

Here is an example:

apiVersion: cluster.kurator.dev/v1alpha1
kind: AttachedCluster
metadata:
  name: kurator-member1
  namespace: default
spec:
  kubeconfig:
    name: kurator-member1
    key: kurator-member1.config

Once the AttachedCluster resources are created, users also need to add these resources to the Kurator Fleet to include these clusters in Kurator’s management scope. In this way, regardless of where these clusters are or what tools created them, they can be uniformly managed and monitored in Kurator.

Here is an example of adding the above AttachedCluster to the Fleet:

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet 
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1 
      kind: AttachedCluster

With the introduction of AttachedCluster, Kurator provides convenient management of all Kubernetes clusters on a unified platform, avoiding frequent switching between various tools and effectively monitoring and managing clusters in the distributed cloud environment. This improvement not only strengthens Kurator’s management capabilities in the cloud-native field but also expands its management scope, significantly enhancing Kurator’s adaptability and management efficiency in handling complex and diverse cloud computing environments.

For more information on Kurator’s unified policy management, please refer to: Kurator AttachedCluster Documentation

Reference Links

Release Notes

Unified Application Distribution Documentation

Unified Cluster Metrics Monitoring Documentation

Unified Policy Management Documentation

AttachedCluster Documentation

Fleet Manager Documentation

GitHub Address

Kurator Homepage

Slack Address

• ←Previous
• Next→