karmada是华为开源的云原生多云容器编排平台，指标是让开发者像应用单个k8s集群一样应用多k8s云。它的第一个release（v0.1.0）呈现在2020年12月，而正式公布则是在2021年4月25日，在深圳召开的华为开发者大会（HDC.Cloud）2021上。
karmada汲取了CNCF社区的Federation v1和v2（也称为kubefed）我的项目教训与教训，在放弃原有k8s资源定义API不变的状况下，通过增加与分布式工作负载部署治理相干的一套新的API和管制面组件，不便用户将工作负载部署到多云环境中，实现扩容、高可用等指标。
官方网站：https://karmada.io/
代码地址：https://github.com/karmada-io...
应用karmada治理的多云环境蕴含两类集群：
host集群：即由karmada管制面形成的集群，承受用户提交的工作负载部署需要，将之同步到member集群，并从member集群同步工作负载后续的运行状况。
member集群：由一个或多个k8s集群形成，负责运行用户提交的工作负载
架构图如下：
本文形容karmada的上手流程，应用的karmada版本为v0.7.0后的commit：c4835e1f，与8月公布的v0.8.0差了二十几个commit。
karmada装置
1.1. 装置docker
依照docker官网文档在本机装置docker，对debian来说流程如下：
装置根底工具sudo apt-get update sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg \ lsb-release装置docker的gpg key：
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg装置docker源
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null装置docker
apt-get updatesudo apt-get install docker-ce docker-ce-cli containerd.io1.2. 装置繁难k8s开发集群管理工具：kind
kind官网对其形容：kind is a tool for running local Kubernetes clusters using Docker container “nodes”. kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
在本地曾经装置好go (1.11以上) 和docker的状况下，执行上面指令装置kind：GO111MODULE=on GOPROXY=goproxy.cn go get sigs.k8s.io/kind@v0.11.10.11.1是以后kind最新的release的，也是后续部署karmada过程中指定要用的版本
kind应用一个容器来模仿一个node，在容器外部应用systemd托管kubelet和containerd（不是docker），而后通过被托管的kubelet启动其余k8s组件，比方kube-apiserver、etcd、CNI等跑起来。
因为kind应用containerd而非docker作为容器运行时，要查看kind启动的k8s节点外部容器运行状况，须要应用containerd的cli客户端ctr。能够通过上面这条命令查看后续步骤中karmada调用kind启动的单节点k8s集群外部容器的运行状况：docker exec karmada-host-control-plane ctr --namespace k8s.io containers ls。
ctr的flag --namespace不是k8s里的namespace，也不是linux内核反对的namespace，感兴趣的同学能够查看containerd的namespace相干概念
1.3. 启动本地k8s集群，装置karmada管制面
1.确保曾经装置make、gcc工具
2.确保曾经装置kubectl，能够参考官网文档采纳手动装置或包管理器的形式装置
3.clone karmada源码： git clone https://github.com/karmada-io... karmada-io/karmada
4.cd karmada-io/karmada
5.hack/local-up-karmada.sh，这里蕴含一系列步骤：
1）查看go、kind等工具是否曾经存在
2）调用kind创立host k8s集群，集群版本默认为1.19.1，与karmada重用的k8s组件（kube-apiserver、kube-controllermanager）版本统一 。创立k8s集群须要的kindest/node:v1.19.1镜像较大，能够提前下载好，避免后续的local-up-karmada期待集群启动超时（默认5分钟）
3）build karmada管制面可执行文件及容器镜像，build完结后本地能够找到如下镜像：karmada-agent、karmada-webhook、karmada-scheduler、karmada-controller-manager
4）部署karmada管制面组件到host集群
5）创立CRD，也就是karmada自定义的多云工作负载API资源，蕴含：propgation policy，override policy，work，resource binding等
6）创立webhook
7）部署实现后，造成kubeconfig文件$HOME/kube/karmada.config，蕴含karmada-host和karmada-apiserver两个context，别离对应撑持karmada管制面运行的host集群，以及karmada管制面自身
留神：karmada还提供了remote-up-karmada.sh脚本，用以把一个现有的k8s集群退出联邦。感兴趣的读者能够浏览karmada我的项目的readme尝试karmada管制面形成
部署karmada实现后，在切换到karmada-host context后，执行kubectl get po --all-namespaces能够失去曾经部署的组件列表：NAMESPACE NAME READY STATUS RESTARTS AGEkarmada-system etcd-0 1/1 Running 0 98mkarmada-system karmada-apiserver-75b5dc6fb7-l6hdv 1/1 Running 0 98mkarmada-system karmada-controller-manager-7d66968445-nnnpp 1/1 Running 0 98mkarmada-system karmada-kube-controller-manager-5456fd756d-sf9xk 1/1 Running 0 98mkarmada-system karmada-scheduler-7c8d678979-bgq4f 1/1 Running 0 98mkarmada-system karmada-webhook-5bfd9fb89d-msqnw 1/1 Running 0 98mkube-system coredns-f9fd979d6-4bc2l 1/1 Running 0 99mkube-system coredns-f9fd979d6-s7jc6 1/1 Running 0 99mkube-system etcd-karmada-host-control-plane 1/1 Running 0 99mkube-system kindnet-cq6kv 1/1 Running 0 99mkube-system kube-apiserver-karmada-host-control-plane 1/1 Running 0 99mkube-system kube-controller-manager-karmada-host-control-plane 1/1 Running 0 99mkube-system kube-proxy-ld9t8 1/1 Running 0 99mkube-system kube-scheduler-karmada-host-control-plane 1/1 Running 0 99mlocal-path-storage local-path-provisioner-78776bfc44-d9fvv 1/1 Running 0 99m能够看到部署在两个namespace中的两个k8s管制面：
karmada-host context对应的管制面运行在kube-system namespace中，用来运行治理karmada管制面，是个由kind启动的规范的k8s治理节点。
karmada-apiserver context对应的管制面运行在karmada-system namespace中，是karmada管制面，也就是karmada readme中提到的host集群。它由local-up-karmada.sh脚本部署到karmada-host集群中。该管制面重用了k8s的两个组件：kube-apiserver和kube-controllermanager以及etcd，其余3个为karmada组件，包含kamada-controller-manager、karmada-scheduler、karmada-webhook
前一个k8s集群只是为了撑持karmada管制面的运行。所有后续集群联邦相干的操作，包含用karmadactl收回的member集群治理申请，以及用kubectl收回的工作负载治理申请都发往karmada管制面。这些申请中创立的API资源也保留在karmada管制面本身的etcd中（对应下面列表中的etcd-0 pod）。
须要留神的是，尽管karmada管制面重用了局部k8s组件，被重用的kube-controller-mamager通过启动flag限度其只运行namespace、garbagecollector、serviceaccount-token、serviceaccount这几个controller，所以当用户把Deployment等k8s规范资源提交给karmada apiserver时，它们只是被记录在karmada管制面的etcd中，并在后续同步到member集群中，这些Deployment资源并不会在karmada管制面治理的集群中产生reconcile（如创立pod）。karmada应用
用户能够用karmadactl和kubectl两个cli应用karmada，其中：
1.karmadactl用来执行member集群的退出(joint)/来到（unjoin）、标记一个member集群不可调度（cordon）或解除不可调度的标记（uncordon）
2.kubectl用来向karmada集群提交规范的k8s资源申请，或由karmada定义的CR申请。用以治理karmada集群中的工作负载。
3.1 应用karmadactl治理member集群
1.执行hack/create-cluster.sh member1 $HOME/.kube/karmada.config创立新的集群member1
2.执行kubectl config use-context karmada-apiserver切换到karmada管制面
3.执行karmadactl join member1 --cluster-kubeconfig=$HOME/.kube/karmada.config以push的形式把member1退出karmada集群
留神：如果还没有编译过karmadactl可执行文件，能够在代码根目录执行make karmadactl
留神：karmada中的host集群和member集群之间的同步形式有push和pull两种，这里的上手过程采纳push的形式，感兴趣的读者能够参考karmada的readme尝试pull同步形式
目前karmadactl没有list member集群的性能，对于曾经退出的member集群，能够通过获取Cluster类型的CR实现：kubectl get clusters
失去输入为：NAME VERSION MODE READY AGEmember1 v1.19.1 Push True 88s下面的create-cluster.sh脚本默认创立最新版的k8s集群，为了防止再次拉下一个大镜像，能够批改create-cluster.sh脚本，为kind create cluster命令加上--image="kindest/node:v1.19.1"参数
3.2 应用kubectl管理工作负载
karmada代码里自带一个nginx利用能够用来体验基于karmada的分布式工作负载治理：
1.执行kubectl config use-context karmada-apiserver切换到karmada管制面
2.执行kubectl create -f samples/nginx/deployment.yaml创立deployment资源
如后面所述，因为kamada管制面没有部署deployment controller，nginx不会在karmada管制面所在集群跑起来，而是仅仅保留在etcd里
这时候如果去member1集群查看pod资源的状况，能够发现nginx也没有在member1集群中运行起来
3.执行kubectl create -f samples/nginx/propagationpolicy.yaml，定义如下的propgation policy：apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: nginx-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1这个progation policy将之前部署的nginx deployment资源（由resourceSelectors指定）同步到member1集群（由placement指定）中。
这时不必切换到member1 context，对karmada管制面执行kubectl get deploy能够看到名叫nginx的deployment曾经失常运行：NAME READY UP-TO-DATE AVAILABLE AGEnginx 1/1 1 1 21m上述后果阐明karmada有能力从member集群同步工作负载状态到host集群。作为验证，咱们能够切换到member1集群，执行kubectl get po能够看到deployment对应的nginx pod曾经在member1集群内失常运行：
NAME READY STATUS RESTARTS AGEnginx-6799fc88d8-7tgmb 1/1 Running 0 8m27s- 结尾并非完结
在Gartner的一份钻研报告中，私有云用户有81%都采纳了多云架构。近年来蓬勃发展的云原生社区对多云挑战给也几次给出本人的思考和解决方案，远有CNCF社区sig multicluster提出的Federation v1和v2，近有华为开源的karmada以及Red Hat开源的Open Cluster Management（OCM）。尽管尚未在API层面达成统一，但各开源我的项目都在汲取前人的经验教训的根底上优化演进。百家争鸣而非闭门造车，这正是开源的魅力所在。
后续咱们会对karmada我的项目进行更为深刻的剖析。