Karmada (Kubernetes Armada) is a Kubernetes management system that enables you to run your cloud-native applications across multiple Kubernetes clusters and clouds, with no changes to your applications. By speaking Kubernetes-native APIs and providing advanced scheduling capabilities, Karmada enables truly open, multi-cloud Kubernetes.
Karmada aims to provide turnkey automation for multi-cluster application management in multi-cloud and hybrid cloud scenarios, with key features such as centralized multi-cloud management, high availability, failure recovery, and traffic scheduling.
Karmada is a sandbox project of the Cloud Native Computing Foundation (CNCF).
K8s Native API Compatible
Out of the Box
Avoid Vendor Lock-in
Centralized Management
Fruitful Multi-Cluster Scheduling Policies
Open and Neutral
Notice: this project is developed in continuation of Kubernetes Federation v1 and v2. Some basic concepts are inherited from these two versions.
The Karmada Control Plane consists of the following components:
ETCD stores the karmada API objects, the API Server is the REST endpoint all other components talk to, and the Karmada Controller Manager perform operations based on the API objects you create through the API server.
The Karmada Controller Manager runs the various controllers, the controllers watch karmada objects and then talk to the underlying clusters' API servers to create regular Kubernetes resources.
Cluster Controller: attach kubernetes clusters to Karmada for managing the lifecycle of the clusters by creating cluster object.
Policy Controller: the controller watches PropagationPolicy objects. When PropagationPolicy object is added, it selects a group of resources matching the resourceSelector and create ResourceBinding with each single resource object.
Binding Controller: the controller watches ResourceBinding object and create Work object corresponding to each cluster with single resource manifest.
Execution Controller: the controller watches Work objects.When Work objects are created, it will distribute the resources to member clusters.
Resource template: Karmada uses Kubernetes Native API definition for federated resource template, to make it easy to integrate with existing tools that already adopt on Kubernetes
Propagation Policy: Karmada offers standalone Propagation(placement) Policy API to define multi-cluster scheduling and spreading requirements.
Override Policy: Karmada provides standalone Override Policy API for specializing cluster relevant configuration automation. E.g.:
The following diagram shows how Karmada resources are involved when propagating resources to member clusters.
This guide will cover:
karmada
control plane components in a Kubernetes cluster which as known as host cluster
.karmada
control plane.karmada
.git clone https://github.com/karmada-io/karmada
cd karmada
run the following script:
# hack/local-up-karmada.sh
This script will do following tasks for you:
host cluster
.host cluster
.If everything goes well, at the end of the script output, you will see similar messages as follows:
Local Karmada is running.
To start using your karmada, run:
export KUBECONFIG="$HOME/.kube/karmada.config"
Please use 'kubectl config use-context karmada-host/karmada-apiserver' to switch the host and control plane cluster.
To manage your member clusters, run:
export KUBECONFIG="$HOME/.kube/members.config"
Please use 'kubectl config use-context member1/member2/member3' to switch to the different member cluster.
There are two contexts about karmada:
kubectl config use-context karmada-apiserver
kubectl config use-context karmada-host
The karmada-apiserver
is the main kubeconfig to be used when interacting with karmada control plane, while karmada-host
is only used for debugging karmada installation with the host cluster. You can check all clusters at any time by running: kubectl config view
. To switch cluster contexts, run kubectl config use-context [CONTEXT_NAME]
In the following steps, we are going to propagate a deployment by karmada.
First, create a deployment named nginx
:
kubectl create -f samples/nginx/deployment.yaml
Then, we need create a policy to drive the deployment to our member cluster.
kubectl create -f samples/nginx/propagationpolicy.yaml
You can check deployment status from karmada, don't need to access member cluster:
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 2/2 2 2 20s
Kubernetes 1.15 | Kubernetes 1.16 | Kubernetes 1.17 | Kubernetes 1.18 | Kubernetes 1.19 | Kubernetes 1.20 | Kubernetes 1.21 | Kubernetes 1.22 | Kubernetes 1.23 | |
---|---|---|---|---|---|---|---|---|---|
Karmada v0.9 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Karmada v0.10 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Karmada v1.0 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Karmada HEAD (master) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Key:
✓
Karmada and the Kubernetes version are exactly compatible.+
Karmada has features or API objects that may not be present in the Kubernetes version.-
The Kubernetes version has features or API objects that Karmada can't use.Regular Community Meeting:
Resources:
If you have questions, feel free to reach out to us in the following ways:
If you're interested in being a contributor and want to get involved in developing the Karmada code, please see CONTRIBUTING for details on submitting patches and the contribution workflow.
Karmada is under the Apache 2.0 license. See the LICENSE file for details.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。