karmada介绍和分析

karmada介绍和分析

背景

• kind v0.11.1
• 已用kind创建一个版本为1.23的集群：k8s123

1. kubectl-karmada

kubectl-karmada是kubectl的一个插件，用来操纵karmada的命令行工具。我们通过以下步骤安装它：

# 1.下载
wget https://github.com/karmada-io/karmada/releases/download/v1.0.2/kubectl-karmada-linux-amd64.tgz
# 2.解压
tar -zxf kubectl-karmada-linux-amd64.tgz
# 3.移动到指定目录
mv kubectl-karmada /usr/local/bin/

现有command:

2. 安装Karmada

为了更好的理解Karmada,我们采用离线的方式安装karmada。提前准备好以下内容crd和相关组件的镜像：

• CRD ，karmada部署所需的CRD文件。
• --etcd-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-k8sgcrio-etcd:3.5.1-0 (原镜像仓库: k8s.gcr.io/etcd:3.5.1-0)，该镜像为etcd镜像,服务于karmada-apiserver。
• --etcd-init-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-dockerio-alpine:3.14.3 (原镜像仓库: docker.io/library/alpine:3.14.3)，该镜像为ectd init容器镜像。
• --karmada-aggregated-apiserver-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-aggregated-apiserver:latest (原镜像仓库: swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-aggregated-apiserver:latest)
• --karmada-apiserver-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-k8sgcrio-kube-apiserver:v1.21.7(原镜像仓库: k8s.gcr.io/kube-apiserver:v1.21.7)
• --karmada-controller-manager-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-controller-manager:latest(原镜像仓库: swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-controller-manager:latest)
• --karmada-kube-controller-manager-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-k8sgcrio-kube-controller-manager:v1.21.7(原镜像仓库: k8s.gcr.io/kube-controller-manager:v1.21.7)
• --karmada-scheduler-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-scheduler:latest(原镜像仓库: swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-scheduler:latest)
• --karmada-webhook-image: registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-webhook:latest(原镜像仓库: swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-webhook:latest)

2.1 执行安装

kubectl karmada init --crds crds.tar.gz \
--etcd-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-k8sgcrio-etcd:3.5.1-0 \
--etcd-init-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-dockerio-alpine:3.14.3 \
--karmada-aggregated-apiserver-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-aggregated-apiserver:latest \
--karmada-apiserver-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-k8sgcrio-kube-apiserver:v1.21.7 \
--karmada-controller-manager-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-controller-manager:latest \
--karmada-kube-controller-manager-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-k8sgcrio-kube-controller-manager:v1.21.7 \
--karmada-scheduler-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-scheduler:latest \
--karmada-webhook-image registry.cn-hangzhou.aliyuncs.com/earl-k8s/karmada-webhook:latest

2.2 部署成功

部署成功后会显示如下内容，其中由包含注册member集群的步骤指导。注册模式分为push模式和pull模式。

其中push模式下，karmada将直接访问member集群的kube-apiserver来获取集群状态和部署资源。

在pull模式下，karmada不会访问成员集群而是通过karmada-agen组件来实现：

• 将member集群注册到karmada
• 维护集群的状态报告给karmada
• 从karmada执行空间（karmada-es-)获取部署资源部署到其所在集群。

------------------------------------------------------------------------------------------------------
 █████   ████   █████████   ███████████   ██████   ██████   █████████   ██████████     █████████
░░███   ███░   ███░░░░░███ ░░███░░░░░███ ░░██████ ██████   ███░░░░░███ ░░███░░░░███   ███░░░░░███
 ░███  ███    ░███    ░███  ░███    ░███  ░███░█████░███  ░███    ░███  ░███   ░░███ ░███    ░███
 ░███████     ░███████████  ░██████████   ░███░░███ ░███  ░███████████  ░███    ░███ ░███████████
 ░███░░███    ░███░░░░░███  ░███░░░░░███  ░███ ░░░  ░███  ░███░░░░░███  ░███    ░███ ░███░░░░░███
 ░███ ░░███   ░███    ░███  ░███    ░███  ░███      ░███  ░███    ░███  ░███    ███  ░███    ░███
 █████ ░░████ █████   █████ █████   █████ █████     █████ █████   █████ ██████████   █████   █████
░░░░░   ░░░░ ░░░░░   ░░░░░ ░░░░░   ░░░░░ ░░░░░     ░░░░░ ░░░░░   ░░░░░ ░░░░░░░░░░   ░░░░░   ░░░░░
------------------------------------------------------------------------------------------------------
Karmada is installed successfully.
 
Register Kubernetes cluster to Karmada control plane.
 
Register cluster with 'Push' mode
 
Step 1: Use kubectl karmada join to register the cluster to Karmada control panel. --cluster-kubeconfig is members kubeconfig.
(In karmada)~# MEMBER_CLUSTER_NAME=`cat ~/.kube/config  | grep current-context | sed 's/: /\n/g'| sed '1d'`
(In karmada)~# kubectl karmada --kubeconfig /etc/karmada/karmada-apiserver.config  join ${MEMBER_CLUSTER_NAME} --cluster-kubeconfig=$HOME/.kube/config
 
Step 2: Show members of karmada
(In karmada)~# kubectl  --kubeconfig /etc/karmada/karmada-apiserver.config get clusters
 
 
Register cluster with 'Pull' mode
 
Step 1:  Send karmada kubeconfig and karmada-agent.yaml to member kubernetes
(In karmada)~# scp /etc/karmada/karmada-apiserver.config /etc/karmada/karmada-agent.yaml {member kubernetes}:~
 
Step 2:  Create karmada kubeconfig secret
 Notice:
   Cross-network, need to change the config server address.
(In member kubernetes)~#  kubectl create ns karmada-system
(In member kubernetes)~#  kubectl create secret generic karmada-kubeconfig --from-file=karmada-kubeconfig=/root/karmada-apiserver.config  -n karmada-system
 
Step 3: Create karmada agent
(In member kubernetes)~#  MEMBER_CLUSTER_NAME="demo"
(In member kubernetes)~#  sed -i "s/{member_cluster_name}/${MEMBER_CLUSTER_NAME}/g" karmada-agent.yaml
(In member kubernetes)~#  kubectl create -f karmada-agent.yaml
 
Step 4: Show members of karmada                                                                                                                       
(In karmada)~# kubectl  --kubeconfig /etc/karmada/karmada-apiserver.config get clusters

3. karmada组件介绍及分析

3.1 karmadactl

karmadactl是karmada的一个命令行工具，其功能和kubectl-karmada是完全一样的。karmada在全局参数中通过--kubeconfig配置kubeconfig的路径。

3.1.1 init子命令

init子命令用于在kubernetes上部署karmada。

用法：

karmadactl init [flags]

参数介绍：

通过参数可以看出，我们可以在部署karmada的时候根据自己的实际情况配置karmada组件相关参数,整个流程如下所示：

3.1.2 join子命令

join子命令用于添加member集群到karmada控制面。

用法：

karmadactl join CLUSTER_NAME --cluster-kubeconfig=<KUBECONFIG> [flags]

参数介绍：

join命令添加member集群的流程如下图所示：

其中有意思的是在join member集群的时候创建了两个serviceAccount在member集群中，这两个账户的区别是karmada-member账户是被授予了get集群权限的，karmada-impersonator是没有被授予任何权限的。在karmada v1.0.0版本开始，支持了聚合API特性，实现统一API endpoint，统一认证鉴权。统一认证在karmada控制面实现了，而karmada-impersonator账户则用于统一鉴权，当用户请求通过karmada-apiserver代理到成员集群时，会使用收集到Karmada控制面中相应集群的karmada-impersonator的token，同时携带待伪装用户（下图中的zhangsan）的Header信息，来访问成员集群kube-apiserver。剩下的工作就与单集群内访问一致了，karmada-impersonator伪装成相应的用户进行访问请求。

3.1.3 unjoin子命令

unjoin子命令移除karmada控制面中注册的member集群。

用法：

karmadactl unjoin CLUSTER_NAME --cluster-kubeconfig=<KUBECONFIG> [flags]

参数介绍：

unjoin子命令移除member集群流程如下：

unjoin子命令在karmada控制面删除了cluster资源，会连带删除子资源secret。

3.1.4 cordon和uncordon子命令

cordon子命令用于标记一个集群不可调度。

用法：

karmadactl cordon CLUSTER [flags]

uncordon子命令标记一个集群可调度

用法：

karmadactl uncordon CLUSTER [flags]

参数介绍：

cordon子命令用于标记集群流程：

3.1.5 taint子命令

taint子命令用来为一个或多个集群修改taint。

用法：

karmadactl taint CLUSTER NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [flags]

参数介绍：

taint子命令执行流程：

3.1.6 get子命令

get子命令用来获取一个或多个资源,只是获得member集群中的资源。

用法：

karmadactl get [NAME | -l label | -n namespace]  [flags]

参数介绍：

get子命令执行流程：

其中我们着重看一下getFactoty，getFactory里调用了kubect中的NewFactory函数，该函数返回了一个factoryImpl类型的对象。

func getFactory(clusterName string, clusterInfos map[string]*ClusterInfo) cmdutil.Factory {
    kubeConfigFlags := NewConfigFlags(true).WithDeprecatedPasswordFlag()
    // Build member cluster kubeConfigFlags
    kubeConfigFlags.BearerToken = stringptr(clusterInfos[clusterName].BearerToken)
    kubeConfigFlags.APIServer = stringptr(clusterInfos[clusterName].APIEndpoint)
    kubeConfigFlags.CaBundle = stringptr(clusterInfos[clusterName].CAData)
    matchVersionKubeConfigFlags := cmdutil.NewMatchVersionFlags(kubeConfigFlags)
    return cmdutil.NewFactory(matchVersionKubeConfigFlags)
}
// 该结构体实现了NewBuilder()方法
type factoryImpl struct {
    clientGetter genericclioptions.RESTClientGetter
 
    // Caches OpenAPI document and parsed resources
    openAPIParser *openapi.CachedOpenAPIParser
    openAPIGetter *openapi.CachedOpenAPIGetter
    parser        sync.Once
    getter        sync.Once
}
 
func NewFactory(clientGetter genericclioptions.RESTClientGetter) Factory {
    if clientGetter == nil {
        panic("attempt to instantiate client_access_factory with nil clientGetter")
    }
    f := &factoryImpl{
        clientGetter: clientGetter,
    }
 
    return f
}

下面我们看下获取资源的方法：

// getObjInfo get obj info in member cluster
func (g *CommandGetOptions) getObjInfo(wg *sync.WaitGroup, mux *sync.Mutex, f cmdutil.Factory,
    cluster string, objs *[]Obj, allErrs *[]error, args []string) {
    defer wg.Done()
    chunkSize := g.ChunkSize
    r := f.NewBuilder().
        Unstructured().
        NamespaceParam(g.Namespace).DefaultNamespace().AllNamespaces(g.AllNamespaces).
        FilenameParam(g.ExplicitNamespace, &g.FilenameOptions).
        LabelSelectorParam(g.LabelSelector).
        FieldSelectorParam(g.FieldSelector).
        RequestChunksOf(chunkSize).
        ResourceTypeOrNameArgs(true, args...).
        ContinueOnError().
        Latest().
        Flatten().
        TransformRequests(g.transformRequests).
        Do()
 
    r.IgnoreErrors(apierrors.IsNotFound)
 
    if !g.IsHumanReadablePrinter {
        err := g.printGeneric(r)
 
        *allErrs = append(*allErrs, err)
        return
    }
 
    infos, err := r.Infos()
    if err != nil {
        *allErrs = append(*allErrs, err)
    }
    mux.Lock()
    var objInfo Obj
    for ix := range infos {
        objInfo = Obj{
            Cluster: cluster,
            Infos:   infos[ix].Object,
            Mapping: infos[ix].Mapping,
        }
        *objs = append(*objs, objInfo)
    }
    mux.Unlock()
}

代码中有一个长的调用链，调用了一系列的方法:

• NewBuilder 返回一个帮助从磁盘和服务器加载对象的对象，它实现了CLI与通用资源交互的通用模式。

• Unstructured 非结构化更新构建器，以便它将请求和发送非结构化对象。非结构化对象以基于对象JSON结构的映射格式保存服务器发送的所有字段，这意味着当客户端读取和写入对象时，数据不会丢失。使用此模式优先于内部模式，除非您直接使用Go类型。

• NamespaceParam 用于指定获取资源的namesapces

• FilenameParam 用于通过指定文件内容获取资源

• LabelSelectorParam 用于通过lablel获取指定资源

• FieldSelectorParam 添加字段选择器

• RequestChunksOf 用于尝试限定size的从服务器批量加载响应，避免加载和传输非常大的列表时出现长时间延迟，如果未设置则部分块。

• ResourceTypeOrNameArgs 表明builder应该接收参数的格式：([,,...]|[,,...]). 当接收到一个参数时，将从服务器检索提供的类型（并以逗号隔开），当接收到两个或多个参数时，它们必须似乎单个类型和资源名。该方法子一个参数allowEmptySelector允许获取所有资源。

• ContinueOnError 用于尝试加载和访问尽可能多的对象，即使一些访问出现错误和一些对象无法加载。

• Latest 获取 通过URLs或者文件从服务加载的任意对象最新的copy

• Flatten F将转换具有名为“Items”的字段的任何对象，这是一个运行时数组。将对象兼容类型转换为单独的entry，并为它们提供自己items。原始对象不会传递给任何访问者。

• TransformRequests 修改从这个builder的客户端发起的API调用。

  func (g *CommandGetOptions) transformRequests(req *rest.Request) {
      if !g.ServerPrint || !g.IsHumanReadablePrinter {
          return
      }
   
      req.SetHeader("Accept", strings.Join([]string{
          // "v1" ,"meta.k8s.io"
          fmt.Sprintf("application/json;as=Table;v=%s;g=%s", metav1.SchemeGroupVersion.Version, metav1.GroupName),
          // "v1beta1",""meta.k8s.io""
          fmt.Sprintf("application/json;as=Table;v=%s;g=%s", metav1beta1.SchemeGroupVersion.Version, metav1beta1.GroupName),
          "application/json",
      }, ","))
  }
  

• Do为生成器标识的资源返回一个带有Visitor的Result对象。访问者将遵循ContinueOnError指定的错误行为。注意，流输入是由第一次执行消费的——在Result上使用info()或Object()来捕获一个列表以供进一步迭代。

然后调用Infos方法获取资源列表。

3.1.6 promote子命令

promote命令用于让karmada接管member集群中不被karmada管理的资源，且资源为工作负载时它的Pod不重启（需要在karmada控制面能够连接到成员集群）。

用法：

 karmadactl promote <RESOURCE_TYPE> <RESOURCE_NAME> -n <NAME_SPACE> -c <CLUSTER_NAME> [flags]

参数介绍：

promote子命令执行流程如下：

可以看出，在使用karmada接管集群的时候，可以同时通过该命令接管集群中的资源。

3.1.7 version子命令

version子命令用于获取整个代码库版本。 它是用来检测二进制代码是由什么代码构成的。

示例：

{
  "GitVersion": "v1.0.0-149-gb5493cc-dirty",
  "GitCommit": "b5493ccf5fe3e246e402e9f17f1000a69bef36b3",
  "GitTreeState": "dirty",
  "BuildDate": "2022-03-11T02:30:40Z",
  "GoVersion": "go1.17.5",
  "Compiler": "gc",
  "Platform": "linux/amd64"
}

3.2 karmada控制平面组件

karmada总体架构图如下图所示：

其中的ETCD和karmada API server用的K8s官方的镜像。我们主要介绍karmada官方的自己实现的组件。

每个成员集群都有对应的karmada scheduler-estimator,scheduler-estimator计算自己所对应member集群的资源使用情况。

3.2.1 karmada-controller-manager

controller manager 负责设置和启动所有的controller。我们先看一下它的参数列表可以做哪些配置：

controller manager启动流程如下：

其中有几个程序解释一下：

• ResourceInterpreter 管理默认和自定义 webhook 以解释自定义资源结构。

• ResourceDetector 是一个资源观察器，它观察所有资源并协调事件。

• DependenciesDistributor 是自动传播相关资源。 当资源（例如deployment）与传播策略匹配时，将创建资源绑定，我们在 DependenciesDistributor 中将其称为独立绑定。 并且当 DependenciesDistributor 工作时，它会创建或更新相关资源的引用资源绑定（例如secret），我们称之为附加绑定。

• ClusterDetector 是一个cluster观察者，它在 cluster-api 管理cluster中观察cluser对象并协调事件。

TODO : 介绍controller和crd资源

3.2.2 karmada-aggregated-apiserver

karmada-aggregated-apiserver用以实现通过karmada-apiserver访问member集群上的资源，达到在karmada控制面实现统一认证和通过用户伪装实现统一鉴权的目的。

参数介绍：

karmada-aggregated-apiserver启动流程如下:

• 在aggregate-apiserver中安装的资源有clusters，clusters/status，clusters/proxy

3.2.3 karmada-scheduler

scheduler主要提供两个方面的能力，即调度策略和调度时机。

参数介绍：

karmada-scheduler启动流程如下：

• karmada创建了三种客户端，dynamicClientSet为各种类型资源都提供了统一的操作API，可以用来操作自定义资源；karmadaClient用来操作karmada官方的自定义资源；kubeClientSet用来操作k8s的内置资源。
• 初始化scheduler的时候，新建了SharedInformerFactory，bindingLister，policyLister，clusterBindingLister，clusterPolicyLister，clusterLister，workqueue，schedulerCache，algorithm以及注册了informerFactory的event Handlers。如果开启了SchedulerEstimator，也会新建SchedulerEstimator。

3.2.4 karmada-descheduler

karmada-descheduler 将每隔一段时间检测一次所有部署，默认情况下每 2 分钟检测一次。在每个周期中，它会通过调用 karmada-scheduler-estimator 找出部署在目标调度集群中有多少不可调度的副本。然后它将逐出它们，spec.clusters并根据当前情况触发 karmada-scheduler 执行“Scale Schedule”。注意，只有在副本调度策略为动态划分时才会生效。

参数介绍：

karmada-descheduler启动流程如下图所示：

• 初始化descheduler 新建了SharedInformerFactory，bindingInformer，bindingLister，clusterInformer，clusterLister，schedulerEstimator，并注册了clusterInformer 的EventHandler，eventRecorder。

3.2.5 karmada-scheduler-estimator

用户可以根据成员集群的可用资源将他们的工作负载副本划分为不同的集群。当某些集群资源不足时，调度器不会将过多的副本分配到这些集群中通过调用 karmada-scheduler-estimator。karmada-scheduler-estimator用来计算集群上CPU，Memory，EphemeralStorage，或者请求创建工作负载中的其他资源是否满足调度需求。

参数介绍：

karmada-scheduler-estimator启动流程如下图所示：

• estimator启动时创建了discoveryClient，DiscoveryClient 实现了发现服务器支持的 API 组、版本和资源的功能。
• estimator启动时启动的informerManager是指SingleClusterInformerManager，SingleClusterInformerManager 管理所有资源的动态共享 Informer，包括 Kubernetes 资源和由 CustomResourceDefinition 定义的自定义资源。
• estimator是一个GRPC服务。

3.2.6 karmada webhook

负责propagationpolicy，clusterpropagationpolicy，overridepolicy，clusteroverridepolicy，resourceinterpreterwebhookconfigurations资源修改或验证操作。

3.2.7 karmada apiserver

此组件使用的kuberntes官方的镜像，负责与聚合api-server，各种controllers,调度器，webhook通信，以及持久化数据到etcd。

3.2.8 karmada kube-controller-manager

此组件使用的kubernetes官方的镜像，我们看一下它的command参数，通过--controllers 参数可以看出，只开启了namespace,garbagecollector,serviceaccount-token控制器。

    containers:
        - command:
            - kube-controller-manager
            - --allocate-node-cidrs=true
            - --authentication-kubeconfig=/etc/kubeconfig
            - --authorization-kubeconfig=/etc/kubeconfig
            - --bind-address=0.0.0.0
            - --client-ca-file=/etc/karmada/pki/server-ca.crt
            - --cluster-cidr=10.244.0.0/16
            - --cluster-name=karmada
            - --cluster-signing-cert-file=/etc/karmada/pki/server-ca.crt
            - --cluster-signing-key-file=/etc/karmada/pki/server-ca.key
            - --controllers=namespace,garbagecollector,serviceaccount-token
            - --kubeconfig=/etc/kubeconfig
            - --leader-elect=true
            - --node-cidr-mask-size=24
            - --port=0
            - --root-ca-file=/etc/karmada/pki/server-ca.crt
            - --service-account-private-key-file=/etc/karmada/pki/karmada.key
            - --service-cluster-ip-range=10.96.0.0/12
            - --use-service-account-credentials=true
            - --v=4

3.3 karmada成员集群组件

3.3.1 karmada-agent

karmada添加的member集群有两种模式，当模式为pull时，会在member集群部署karmada-agent,karmada会负责收集自己所在集群的状态并且更新 member 集群的相应的 Cluster 资源状态。

参数介绍：

karmada-agent启动流程如下：

• karmada将自己注册到集群，在karmada控制面创建保存member集群验证信息的namespace、创建的Cluster对象，创建相关secret。
• 初始化controllerManager之前在karmada控制平面创建了执行分发策略的namespace karmada-es-*。