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:
| command | 解释 |
|---|---|
| cordon | 标记指定集群不可调度 |
| get | 获取一个或多个资源 |
| init | 在kubernetes集群中安装karmada |
| join | 注册一个集群到karmada控制面板（push模式） |
| promote | 将资源从遗留（member）集群提升到karmada控制面板 |
| taint | 给一个或多个集群更新污点 |
| uncordon | 标记指定集群可调度 |
| unjoin | 从karmada控制面板移除集群注册 |
| version | 输出版本信息 |
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:latest2.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 clusters3. karmada组件介绍及分析
3.1 karmadactl
karmadactl是karmada的一个命令行工具，其功能和kubectl-karmada是完全一样的。karmada在全局参数中通过--kubeconfig配置kubeconfig的路径。
3.1.1 init子命令
init子命令用于在kubernetes上部署karmada。
用法：
karmadactl init [flags]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --cert-external-dns | string | the external DNS of Karmada certificate (e.g localhost,localhost.com)，生成证书生效外部DNS |
| --cert-external-ip | string | the external IP of Karmada certificate (e.g 192.168.1.2,172.16.1.2),生成证书生效外部IP |
| --crds | string | karmada的自定义资源 |
| --etcd-data | string | 配置etcd数据路径，在hostPath模式下生效 |
| --etcd-image | string | 配置etcd镜像仓库，默认k8s.gcr.io/etcd:3.5.1-0 |
| --etcd-init-image | string | 配置etcd init容器镜像仓库，默认docker.io/alpine:3.14.3 |
| --etcd-node-selector-labels | string | 配置etcd pod运行的节点通过label,在hostPath模式生效 |
| --etcd-pvc-size | string | 配置etcd所有pvc大小，默认5Gi,在PVC模式生效 |
| --etcd-replicas | int32 | 配置etcd副本数，默认1 |
| --etcd-storage-mode | string | 配置etcd数据储存模式（emptyDir(默认),hostPath,PVC（配置--storage-classes-name）) |
| --karmada-aggregated-apiserver-image | string | 配置karmada聚合apiserver镜像仓库，默认swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-aggregated-apiserver:latest |
| --karmada-aggregated-apiserver-replicas | int32 | 配置karmada聚合apiserver副本数，默认1 |
| --karmada-apiserver-image | string | 配置karmada apiserver镜像仓库，默认k8s.gcr.io/kube-apiserver:v1.21.7 |
| --karmada-apiserver-replicas | int32 | 配置karmada apiserver副本数 |
| --karmada-controller-manager-image | string | 配置karmada-controller-manager镜像仓库，默认"swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-controller-manager:latest |
| --karmada-controller-manager-replicas | int32 | 配置karmada-controller-manage副本数 |
| --karmada-data | string | 配置karmada数据（kubeconfig cert，crds等）路径，默认/etc/karmada(执行命令的主机上) |
| --karmada-kube-controller-manager-image | string | 配置karmada-kube-controller-manager镜像仓库，默认k8s.gcr.io/kube-controller-manager:v1.21.7 |
| --karmada-kube-controller-manager-replicas | int32 | 配置karmada-kube-controller-manager副本数 |
| --karmada-scheduler-image | string | 配置karmada-scheduler镜像仓库，默认swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-scheduler:latest |
| --karmada-scheduler-replicas | int32 | 配置karmada-scheduler副本数，默认1 |
| --karmada-webhook-image | string | 配置karmada-webhook镜像仓库，默认swr.ap-southeast-1.myhuaweicloud.com/karmada/karmada-webhook:latest |
| --karmada-webhook-replicas | int32 | 配置karmada-webhook副本数，默认1 |
| --namespace | string | 配置karmada组件所在的namespace,默认karmada-system |
| --port | int32 | 配置访问karmada apiserver的node port,默认32443 |
| --storage-classes-name | string | 配置使用的Kubernetes StorageClasses名 |
通过参数可以看出，我们可以在部署karmada的时候根据自己的实际情况配置karmada组件相关参数,整个流程如下所示：
3.1.2 join子命令
join子命令用于添加member集群到karmada控制面。
用法：
karmadactl join CLUSTER_NAME --cluster-kubeconfig=<KUBECONFIG> [flags]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --cluster-context | string | 当kubeconfig(member)中有多个context时，指定context name |
| --cluster-kubeconfig | string | 配置要添加的集群的kubeconfig的路径 |
| --cluster-namespace | string | 配置在karmda控制面保存member集群 secret的namespace，默认karmada-cluster |
| --cluster-provider | string | 配置member集群的云提供商名 |
| --dry-run | dry-run模式，不发送请求到server | |
| --karmada-context | string | 控制面kubeconfig中的cluster context名，默认current-context |
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]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --cluster-context | string | 当kubeconfig(member)中有多个context时，指定context name |
| --cluster-kubeconfig | string | 配置要移除的集群的kubeconfig的路径 |
| --cluster-namespace | string | 配置在karmda控制面保存member集群 secret的namespace，默认karmada-cluster |
| --dry-run | dry-run模式，不发送请求到server | |
| --force | 即使unjoin目标集群中的资源没有被成功移除，也删除cluster和secret资源。 | |
| --karmada-context | karmada控制面kubeconfig中的cluster context名，默认current-context | |
| --wait | 配置移除命令执行时间，默认60s,超时未成功则返回timeout |
unjoin子命令移除member集群流程如下：
unjoin子命令在karmada控制面删除了cluster资源，会连带删除子资源secret。
3.1.4 cordon和uncordon子命令
cordon子命令用于标记一个集群不可调度。
用法：
karmadactl cordon CLUSTER [flags]uncordon子命令标记一个集群可调度
用法：
karmadactl uncordon CLUSTER [flags]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --dry-run | dry-run模式，不发送请求到server | |
| --karmada-context | string | karmada控制面kubeconfig中的cluster context名，默认current-context |
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]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --dry-run | dry-run模式，不发送请求到server | |
| --karmada-context | string | karmada控制面kubeconfig中的cluster context名，默认current-context |
| --overwrite | 如果为true允许覆盖taints，否则拒绝覆盖现在taints的更新 |
taint子命令执行流程：
3.1.6 get子命令
get子命令用来获取一个或多个资源,只是获得member集群中的资源。
用法：
karmadactl get [NAME | -l label | -n namespace] [flags]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --all-namespaces | 获取所有namesapce下被请求的资源 | |
| --namespace | string | 获取指定namespace下被请求的资源，默认default |
| --allow-missing-template-keys | 当输出格式为golang和json时，允许忽略字段缺失和map key缺失的错误 | |
| --cluster-namespace | string | 配置member集群保存在karmada的namesapce,默认karmada-cluster |
| --clusters | strings | 获取指定cluster的子资源 |
| --dry-run | dry-run模式，不发送请求到server | |
| --karmada-context | string | karmada控制面kubeconfig中的cluster context名，默认current-context |
| --label-columns | strings | 接受将以列形式显示的由逗号分隔的标签列表 |
| --labels | string | 指定标签 |
| --no-headers | 当使用默认或自定义列输出格式时，不要打印标题(默认打印标题)。 | |
| --output | string | 输出格式：json,yaml,name,go-template,go-template-file,template,templatefile,jsonpath,jsonpath-as-json,jsonpath-file,custom-columns-file,custom-columns,custom columns, golang template,jsonpath template |
| --show-kind | 展示请求资源的type | |
| --show-labels | 展示请求资源的labels | |
| --show-managed-fields | 如果为true，则在以JSON或YAML格式打印对象时保留managedFields。 | |
| --template | 当--output=go-template，--output=go-template-file时使用的模板字符串或模板文件的路径 | |
| --sort-by | string | 如果非空，则使用此字段规范对列表类型进行排序。 字段规范被表示为JSONPath表达式(例如。 “{.metadata.name}”)。 由这个JSONPath表达式指定的API资源中的字段必须是整数或字符串。 |
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应该接收参数的格式：
(<type1>[,<type2>,...]|<type><name1>[,<name2>,...]). 当接收到一个参数时，将从服务器检索提供的类型（并以逗号隔开），当接收到两个或多个参数时，它们必须似乎单个类型和资源名。该方法子一个参数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]参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --cluster | string | legacy集群的name |
| --cluster-context | string | legacy集群kubeconfig中context,用在有多个context的情况 |
| --cluster-kubeconfig | string | legacy集群的kubeconfig的path |
| --cluster-namespace | string | 在karmada控制平面储存member集群的Namesapce,默认karmada-cluster |
| --dry-run | dry-run模式，不发送请求到server | |
| --karmada-context | string | karmada控制面kubeconfig中的cluster context名，默认current-context |
| --namespace | string | |
| --output | string | 输出格式：json\ |
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。我们先看一下它的参数列表可以做哪些配置：
| 参数 | 类型 | 描述 |
|---|---|---|
| --add_dir_header | 如果为true，则将文件目录添加到日志消息的头部 | |
| --alsologtostderr | log to standard error as well as files （ ？） | |
| --bind-address | string | 监听--secure-port端口的IP地址，默认："0.0.0.0" |
| --cluster-api-burst | int | 与集群kube-apiserver通信的burst数量，默认60 |
| --cluster-api-context | string | cluster-api管理集群kubeconfig文件中的context的Name |
| --cluster-api-kubeconfig | string | cluster-api管理集群kubeconfig文件的Path |
| --cluster-api-qps | float32 | 与集群kube-apiserver通信的QPS配置，默认40 |
| --cluster-cache-sync-timeout | duration | 集群同步缓存超时时间，默认30s |
| --cluster-lease-duration | duration | 集群lease到期时间。默认40s |
| --cluster-lease-renew-interval-fraction | float | 集群lease更新间隔fraction，default 0.25，与ClusterLeaseDuration协调，renewInterval（更新间隔时间） = cluster-lease-duration*cluster-lease-renew-interval-fraction，即过期时间内进行更新。 |
| --cluster-monitor-grace-period | duration | 指定在将正在运行的集群标记为不健康之前允许其无响应的宽限期。(默认40s) |
| --cluster-monitor-period | duration | 指定karmada-controller-manager监视集群运行状况状态的频率。 (默认5 s) |
| --cluster-startup-grace-period | duration | 指定在标记集群不健康之前，允许集群在启动期间无响应的宽限期。 (默认1 m0s) |
| --cluster-status-update-frequency | duration | 指定karmada-controller-manager向karmada-apiserver发布集群状态的频率。 (默认10s) |
| --concurrent-cluster-syncs | int | 允许并发同步的Clusters数量。 (默认5) |
| --concurrent-clusterresourcebinding-syncs | int | 允许并发同步的ClusterResourceBindings的个数。 (默认5) |
| --concurrent-namespace-syncs | int | 允许并发同步的namespace的数量。 (默认为1) |
| --concurrent-resource-template-syncs | int | 允许并发同步的资源模板数量。 (默认5) |
| --concurrent-resourcebinding-syncs | int | 允许并发同步的ResourceBindings的数量。 (默认5) |
| --concurrent-work-syncs | int | 允许并发同步的Works的数量。 (默认5) |
| --controllers | strings | 开启controller的列表，默认开启所有[*],"foo" 开启命名为foo的controller,"-foo" 关闭名为foo的controller,全部controller包括： binding, cluster, clusterStatus, endpointSlice, execution, federatedResourceQuotaStatus, federatedResourceQuotaSync, hpa, namespace, serviceExport, serviceImport, unifiedAuth, workStatus. |
| --feature-gates | mapStringBool | A set of key=value pairs that describe feature gates for alpha/experimental features. Options are: AllAlpha=true\ |
| --kube-api-burst | int | 与karmada-apiserver通信时的Burst的数量，默认60 |
| --kube-api-qps | float32 | 与karmada-apiserver通信是的QPS配置，默认40 |
| --kubeconfig | string | karmada控制平面的kubeconfile的文件路径 |
| --leader-elect | 启动一个leader选举客户端，并在执行man loop之前获得leadership。 在运行replicated组件以获得高可用性时启用此功能。 (默认true) | |
| --leader-elect-resource-namespace | string | 在leader选举期间用于锁定的资源对象的名称空间。 (默认“karmada-system”) |
| --log_backtrace_at | traceLocation | when logging hits line file:N, emit a stack trace (default :0), klog |
| --log_dir | string | klog |
| --log_file | string | klog |
| --log_file_max_size | uint | klog |
| --logtostderr | klog | |
| --metrics-bind-address | string | 为controller绑定输出Prometheus metrics的TCP address,(e.g. 127.0.0.1:8088, :8088) (default ":8080") |
| --one_output | klog | |
| --rate-limiter-base-delay | duration | The base delay for rate limiter. (default 5ms) |
| --rate-limiter-bucket-size | int | The bucket size for rate limier. (default 100) |
| --rate-limiter-max-delay | duration | The max delay for rate limiter. (default 16m40s) |
| --rate-limiter-qps | int | The qps for rate limier. (default 10) |
| --resync-period | duration | informers的resynced的频率 |
| --secure-port | int | 提供HTTPS服务的安全端口 |
| --skip_headers | 如果为true，在日志消息中避免header | |
| --skip_log_headers | 如果为true，在打开日志文件时避免headers | |
| --skipped-propagating-apis | string | 除了默认的跳过列表(cluster.karmada.io;policy.karmada.io;work.karmada.io)之外，应该从传播中跳过那些用分号分隔的资源。支持的格式有: 用于跳过具有特定API组的资源(例如:networking.k8s.io)；/ 为跳过资源与特定的API版本(如。networking.k8s.io / v1beta1)；//, 为了跳过一个或多个特定的资源(例如:networking.k8s.io/v1beta1/Ingress,IngressClass)，其中类型不区分大小写。 |
| --skipped-propagating-namespaces | strings | 除了默认跳过的命名空间（karmada-system、karmada-cluster、以 kube- 和 karmada-es- 为前缀的命名空间）之外，应该从传播中跳过的以逗号分隔的命名空间。 |
| --stderrthreshold | severity | 等于或高于此阈值的日志转到 stderr（默认 2） |
| --vmodule | moduleSpec |
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控制面实现统一认证和通过用户伪装实现统一鉴权的目的。
参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --admission-control-config-file | string | 准入控制配置文件 |
| --audit-log-batch-buffer-size | int | 在批处理和写入之前存储事件的缓冲区大小。仅用于批处理模式。 （默认 10000） |
| --audit-log-batch-max-size | int | 批处理的最大大小。 仅用于批处理模式。 （默认 1） |
| --audit-log-batch-max-wait | duration | 在强制写入未达到最大大小的批次之前等待的时间。 仅用于批处理模式。 |
| --audit-log-batch-throttle-burst | int | 如果之前未使用 ThrottleQPS，则同时发送的最大请求数。 仅用于批处理模式。 |
| --audit-log-batch-throttle-enable | 是否启用批处理节流。 仅用于批处理模式。 | |
| --audit-log-batch-throttle-qps | float32 | 每秒最大平均批次数。 仅用于批处理模式。 |
| --audit-log-compress | 如果设置，rotated的日志文件将使用 gzip 压缩。 | |
| --audit-log-format | string | 已保存审计的格式。 “legacy”表示每个事件 1-line text format。 “json”表示结构化的json格式。 已知的格式是legacy,json。 （默认“json”） |
| --audit-log-maxage | int | 根据文件名中编码的时间戳，保留旧审计日志文件的最大天数。 |
| --audit-log-maxbackup | int | 要保留的旧审计日志文件的最大数量。 将值设置为 0 意味着对文件数量没有限制。 |
| --audit-log-maxsize | int | rotated（轮换）前审核日志文件的最大大小（以 MB 为单位）。 |
| --audit-log-mode | string | 发送审计事件的策略。blocking表示发送事件应该阻塞服务器响应。Batch 导致后端异步缓冲和写入事件。 已知的模式是：batch,blocking,blocking-strict. 默认："blocking" |
| --audit-log-path | string | 如果设置，所有到达 apiserver 的请求都将被记录到这个文件中。 '-' 表示标准输出。 |
| --audit-log-truncate-enabled | 是否启用事件和批处理截断。 | |
| --audit-log-truncate-max-batch-size | int | 发送到底层后端的批处理的最大大小。 实际的序列化大小可以大几百字节。 如果一个批次超过了这个限制，它会被分成几个更小的批次。 （默认 10485760） |
| --audit-log-truncate-max-event-size | int | 发送到底层后端的审计事件的最大大小。 如果事件的大小大于此数字，则删除第一个请求和响应，如果这不能充分减小大小，则丢弃事件。 （默认 102400） |
| --audit-log-version | string | 用于序列化写入日志的审计事件的 API 组和版本。 （默认“audit.k8s.io/v1”） |
| --audit-policy-file | string | 定义审计策略配置的文件的路径。 |
| --audit-webhook-batch-buffer-size | int | 在批处理和写入之前存储事件的缓冲区大小。 仅用于批处理模式。 （默认 10000） |
| --audit-webhook-batch-max-size | int | 批处理的最大大小。 仅用于批处理模式。 （默认 400） |
| --audit-webhook-batch-max-wait | duration | 在强制写入未达到最大大小的批次之前等待的时间。 仅用于批处理模式。 （默认 30 秒） |
| --audit-webhook-batch-throttle-burst | int | 如果之前未使用 ThrottleQPS，则同时发送的最大请求数。 仅用于批处理模式。 （默认 15） |
| --audit-webhook-batch-throttle-enable | 是否启用批处理节流。 仅用于批处理模式。 （默认：true） | |
| --audit-webhook-batch-throttle-qps | float32 | 每秒最大平均批次数。 仅用于批处理模式。 （默认 10） |
| --audit-webhook-config-file | string | 定义审计 webhook 配置的 kubeconfig 格式文件的路径。 |
| --audit-webhook-initial-backoff | duration | 在重试第一个失败请求之前等待的时间。 （默认 10 秒） |
| --audit-webhook-mode | string | 发送审计事件的策略。blocking表示发送事件应该阻塞服务器响应。Batch 导致后端异步缓冲和写入事件。 已知的模式是：batch,blocking,blocking-strict.默认："batch" |
| --audit-webhook-truncate-enabled | 是否启用事件和批处理截断。 | |
| --audit-webhook-truncate-max-batch-size | int | 发送到底层后端的批处理的最大大小。 实际的序列化大小可以大几百字节。 如果一个批次超过了这个限制，它会被分成几个更小的批次。 （默认 10485760） |
| --audit-webhook-truncate-max-event-size | int | 发送到底层后端的审计事件的最大大小。 如果事件的大小大于此数字，则删除第一个请求和响应，如果这不能充分减小大小，则丢弃事件。 （默认 102400） |
| --audit-webhook-version | string | 用于序列化写入 webhook 的审计事件的 API 组和版本。 （默认“audit.k8s.io/v1”） |
| --authentication-kubeconfig | string | kubeconfig 文件指向具有足够权限的“核心”kubernetes 服务器来创建 tokenreviews.authentication.k8s.io。 |
| --authentication-skip-lookup | 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 | |
| --authentication-token-webhook-cache-ttl | duration | 缓存来自 webhook 令牌身份验证器响应的持续时间。 （默认 10 秒） |
| --authentication-tolerate-lookup-failure | 如果为 true，则无法从集群中查找缺少的身份验证配置不被视为致命的。 请注意，这可能会导致将所有请求视为匿名的身份验证。 | |
| --authorization-always-allow-paths | strings | 授权期间要跳过的 HTTP 路径列表，即在不联系“核心”kubernetes 服务器的情况下授权这些路径。 （默认 [/healthz,/readyz,/livez]） |
| --authorization-kubeconfig | string | kubeconfig 文件指向具有足够权限的“核心”kubernetes 服务器来创建 subjectaccessreviews.authorization.k8s.io。 |
| --authorization-webhook-cache-authorized-ttl | duration | 缓存来自 webhook 授权方的“授权”响应的持续时间。 （默认 10 秒） |
| --authorization-webhook-cache-unauthorized-ttl | duration | 缓存来自 webhook 授权方的“未授权”响应的持续时间。 （默认 10 秒） |
| --bind-address | ip | 侦听 --secure-port 端口的 IP 地址。 集群的其余部分和 CLI/Web 客户端必须可以访问关联的接口。 如果为空白或未指定地址（0.0.0.0 或 ::），将使用所有接口。 （默认 0.0.0.0） |
| --cert-dir | string | TLS 证书所在的目录。 如果提供了 --tls-cert-file 和 --tls-private-key-file，则此标志将被忽略。 （默认“apiserver.local.config/certificates”） |
| --client-ca-file | string | 如果设置，则任何呈现由 client-ca-file 中的权威机构之一签署的客户端证书的请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 |
| --contention-profiling | 如果启用了分析，则启用锁争用分析 | |
| --default-watch-cache-size | int | 默认监视缓存大小。 如果为零，对于没有设置默认监视大小的资源，监视缓存将被禁用。 （默认 100） |
| --delete-collection-workers | int | 为 DeleteCollection 调用生成的worker数。 这些用于加速命名空间清理。 （默认 1） |
| --disable-admission-plugins | strings | 应禁用的准入插件，尽管它们在默认启用的插件列表中（NamespaceLifecycle、MutatingAdmissionWebhook、ValidatingAdmissionWebhook）。 准入插件的逗号分隔列表：MutatingAdmissionWebhook、NamespaceLifecycle、ValidatingAdmissionWebhook。 此标志中插件的顺序无关紧要。 |
| --egress-selector-config-file | string | 带有 apiserver egress selector 配置的文件。 |
| --enable-admission-plugins | strings | 除了默认启用的插件（NamespaceLifecycle、MutatingAdmissionWebhook、ValidatingAdmissionWebhook）之外，还应启用的准入插件。 准入插件的逗号分隔列表：MutatingAdmissionWebhook、NamespaceLifecycle、ValidatingAdmissionWebhook。 此标志中插件的顺序无关紧要。 |
| --enable-garbage-collector | 启用通用垃圾收集器。 必须与 kube-controller-manager 的相应标志同步。 （默认为true） | |
| --encryption-provider-config | string | 包含用于在 etcd 中存储机密的加密提供程序的配置文件 |
| --etcd-cafile | string | 用于保护 etcd 通信的 SSL 证书颁发机构文件。 |
| --etcd-certfile | string | 用于保护 etcd 通信的 SSL 认证文件。 |
| --etcd-compaction-interval | duration | compaction请求的间隔。 如果为 0，则禁用来自 apiserver 的compaction请求。 （默认 5m0s） |
| --etcd-count-metric-poll-period | duration | 针对每种类型的资源数量轮询 etcd 的频率。 0 禁用度量收集。 （默认 1m0s） |
| --etcd-db-metric-poll-interval | duration | 轮询 etcd 和更新指标的请求间隔。 0 禁用度量收集（默认 30s） |
| --etcd-healthcheck-timeout | duration | 检查 etcd 运行状况时使用的超时时间。 （默认2s） |
| --etcd-keyfile | string | 用于保护 etcd 通信的 SSL 密钥文件。 |
| --etcd-prefix | string | 在 etcd 中添加到所有资源路径的前缀。 （默认“/registry”） |
| --etcd-servers | strings | 要连接的 etcd 服务器列表（scheme://ip:port），逗号分隔。 |
| --etcd-servers-overrides | strings | 每个资源的 etcd 服务器覆盖，逗号分隔。 单独的覆盖格式：group/resource#servers，其中服务器是 URL，以分号分隔。 请注意，这仅适用于编译到此服务器二进制文件中的资源。 |
| --feature-gates | mapStringBool | 一组键值对，描述了 alpha/experimental 的特征门。 |
| --http2-max-streams-per-connection | int | 服务器为客户端提供的 HTTP/2 连接中最大流数的限制。 零表示使用 golang 的默认值。 （默认 1000） |
| --kube-api-burst | int | 在与 karmada-apiserver 交谈时使用burst。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 60） |
| --kube-api-qps | float32 | 与 karmada-apiserver 交谈时使用的 QPS。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 40） |
| --kubeconfig | string | karmada控制平面 kubeconfig文件路径 |
| --lease-reuse-duration-seconds | int | 重用每个lease的时间（以秒为单位）。 较低的值可以避免大量对象重用相同的lease。 请注意，太小的值可能会导致存储层的性能问题。 （默认 60） |
| --permit-address-sharing | 如果为 true，绑定端口时将使用 SO_REUSEADDR。 这允许绑定到通配符 IP，如 0.0.0.0 和并行的特定 IP，并且避免等待内核释放处于 TIME_WAIT 状态的套接字。 [default=false] | |
| --permit-port-sharing | 如果为 true，则绑定端口时将使用 SO_REUSEPORT，这允许多个实例绑定在同一地址和端口上。 [default=false] | |
| --profiling | 通过 Web 界面 host:port/debug/pprof/ 启用分析（默认为 true） | |
| --requestheader-allowed-names | strings | 允许在 --requestheader-username-headers 指定的标头中提供用户名的客户端证书通用名称列表。 如果为空，则允许在 --requestheader-client-ca-file 中由权威机构验证的任何客户端证书。 |
| --requestheader-client-ca-file | string | 在信任由 --requestheader-username-headers 指定的标头中的用户名之前，用于验证传入请求的客户端证书的根证书包。 警告：通常不依赖于已经为传入请求完成的授权。 |
| --requestheader-extra-headers-prefix | strings | 要检查的请求标头前缀(request header prefixes )列表。 建议使用 X-Remote-Extra-。 （默认 [x-remote-extra-]） |
| --requestheader-group-headers | strings | 要检查组的请求标头(request headers )列表。 建议使用 X-Remote-Group。 （默认 [x-remote-group]） |
| --requestheader-username-headers | strings | 检查用户名的请求标头(request headers )列表。 X-Remote-User 很常见。 （默认 [x-remote-user]） |
| --secure-port | int | 通过身份验证和授权为 HTTPS 提供服务的端口。 如果为 0，则根本不提供 HTTPS。 （默认 443） |
| --storage-backend | string | 用于持久性的存储后端。 选项：'etcd3'（默认）。 |
| --storage-media-type | string | 用于在存储中存储对象的media type。 某些资源或存储后端可能仅支持特定的media type，并且会忽略此设置。 （默认“application/json”） |
| --tls-cert-file | string | 包含 HTTPS 的默认 x509 证书的文件。 （CA 证书，如果有的话，连接在服务器证书之后）。 如果启用了 HTTPS 服务，并且没有提供 --tls-cert-file 和 --tls-private-key-file ，则会为公共地址生成一个自签名证书和密钥并保存到 --cert-dir。 |
| --tls-cipher-suites | strings | 服务器的密码套件的逗号分隔列表。 如果省略，将使用默认的 Go 密码套件。 |
| --tls-min-version | string | 支持的最低 TLS 版本。 可能的值：VersionTLS10、VersionTLS11、VersionTLS12、VersionTLS13 |
| --tls-private-key-file | string | 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 |
| --tls-sni-cert-key | namedCertKey | 一对 x509 证书和私钥文件路径，可选地以域模式列表作为后缀，这些域模式是完全限定的域名，可能带有前缀通配符段。 域模式也允许 IP 地址，但只有在 apiserver 可以看到客户端请求的 IP 地址时才应使用 IP。 如果未提供域模式，则提取证书的名称。 非通配符匹配胜过通配符匹配，显式域模式胜过提取的名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。 示例：“example.crt,example.key”或“foo.crt,foo.key:*.foo.com,foo.com”。 （默认 []） |
| --tracing-config-file | string | 带有 apiserver 跟踪配置的文件。 |
| --watch-cache | 在 apiserver 中启用监视缓存（默认为 true） | |
| --watch-cache-sizes | strings | 监视某些资源（pod、节点等）的缓存大小设置，逗号分隔。 单独设置格式：resource[.group]#size，其中resource为小写复数（无版本），apiVersion v1（遗留核心API）的资源省略group，其他包含，size为数字。 开启 watch-cache 后生效。 一些资源（replicationcontrollers、endpoints、nodes、pods、services、apiservices.apiregistration.k8s.io）具有启发式设置的系统默认值，其他默认为 default-watch-cache-size |
karmada-aggregated-apiserver启动流程如下:
- 在aggregate-apiserver中安装的资源有clusters，clusters/status，clusters/proxy
3.2.3 karmada-scheduler
scheduler主要提供两个方面的能力，即调度策略和调度时机。
参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --add_dir_header | 如果为 true，则将文件目录添加到日志消息的标题中 | |
| --alsologtostderr | 记录到标准错误以及文件 | |
| --bind-address | string | 侦听 --secure-port 端口的 IP 地址。 （默认“0.0.0.0”） |
| --enable-scheduler-estimator | 启用调用集群调度程序估计器以调整副本。 | |
| --feature-gates | mapStringBool | 一组键值对，描述了 alpha/experimental的特征门。 |
| --kube-api-burst | int | 在与 karmada-apiserver 交谈时使用Burst。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 60） |
| --kube-api-qps | float32 | 与 karmada-apiserver 交谈时使用的 QPS。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 40） |
| --kubeconfig | string | karmada控制面的kubeconfig文件路径 |
| --leader-elect | 启用领导者选举，运行多实例时必须为true。 （默认: true） | |
| --leader-elect-resource-namespace | string | 领导选举期间用于锁定的资源对象的命名空间。 （默认: karmada-system） |
| --log_backtrace_at | traceLocation | when logging hits line file:N, emit a stack trace (default :0) klog |
| --log_dir | string | 如果不为空，则将日志文件写入该目录 |
| --log_file | string | 如果非空，使用此日志文件 |
| --log_file_max_size | uint | 定义日志文件可以增长到的最大大小。 单位是兆字节。 如果值为 0，则最大文件大小不受限制。 （默认 1800） |
| --logtostderr | 记录到标准错误而不是文件（默认:true） | |
| --master | string | Kubernetes API 服务器的地址。 覆盖 KubeConfig 中的任何值。 只有在集群外时才需要。 |
| --one_output | 如果为true，则仅将日志写入其本机严重性级别（而不是写入每个较低的严重性级别） | |
| --scheduler-estimator-port | int | 连接accurate scheduler estimator的安全端口。 （默认 10352） |
| --scheduler-estimator-timeout | duration | 指定调用scheduler estimator service的超时时间。 （默认 3s） |
| --secure-port | int | 提供 HTTPS 的安全端口。 （默认 10351） |
| --skip_headers | 如果为true，则避免在日志消息中使用 header prefixes | |
| --skip_log_headers | 如果为true，则在打开日志文件时避免headers | |
| --stderrthreshold | severity | 超过这个阈值的日志将转到stderr(默认2) |
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”。注意，只有在副本调度策略为动态划分时才会生效。
参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --bind-address | string | 侦听 --secure-port 端口的 IP 地址。 （默认“0.0.0.0”） |
| --descheduling-interval | duration | descheduler执行间隔，设置此值指示descheduler以指定的时间间隔在连续循环中运行。（默认2m0s） |
| --kube-api-burst | int | 在与 karmada-apiserver 交谈时使用Burst。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 60） |
| --kube-api-qps | float32 | 与 karmada-apiserver 交谈时使用的 QPS。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 40） |
| --kubeconfig | string | karmada控制面的kubeconfig文件路径 |
| --leader-elect | bool | 启用领导者选举，运行多实例时必须为true。 （默认: true） |
| --leader-elect-resource-namespace | string | 领导选举期间用于锁定的资源对象的命名空间。 （默认: karmada-system） |
| --master | string | Kubernetes API 服务器的地址。 覆盖 KubeConfig 中的任何值。 只有在集群外时才需要。 |
| --scheduler-estimator-port | int | 连接accurate scheduler estimator的安全端口。 （默认 10352） |
| --scheduler-estimator-timeout | duration | 指定调用scheduler estimator service的超时时间。 （默认 3s） |
| --secure-port | int | 提供 HTTPS 的安全端口。 （默认 10358） |
| --unschedulable-threshold | duration | pod处于Unschedulable状态的period，用于作为判断Pod是不可调度的标准。（默认5m0s） |
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，或者请求创建工作负载中的其他资源是否满足调度需求。
参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --bind-address | string | 侦听 --secure-port 端口的 IP 地址。 （默认“0.0.0.0”） |
| --cluster-name | string | estimator serve的成员集群的名称 |
| --kube-api-burst | int | 在与 apiserver 通信时使用 Burst。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 30） |
| --kube-api-qps | float32 | 与 apiserver 通信时使用的 QPS。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 20） |
| --kubeconfig | string | 成员集群的KubeConfig 的路径。 |
| --master | string | 成员 Kubernetes API 服务器的地址。 覆盖 KubeConfig 中的任何值。 只有在集群外时才需要。 |
| --secure-port | int | 提供 HTTPS 的安全端口。 （默认 10351） |
| --server-port | int | 提供 gRPC 服务的安全端口。 （默认 10352） |
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=43.3 karmada成员集群组件
3.3.1 karmada-agent
karmada添加的member集群有两种模式，当模式为pull时，会在member集群部署karmada-agent,karmada会负责收集自己所在集群的状态并且更新 member 集群的相应的 Cluster 资源状态。
参数介绍：
| 参数 | 类型 | 描述 |
|---|---|---|
| --add_dir_header | 如果为 true，则将文件目录添加到日志消息的标题中 | |
| --alsologtostderr | 记录到标准错误以及文件 | |
| --cluster-api-burst | int | 在与集群 kube-apiserver 交谈时使用 Burst。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 60） |
| --cluster-api-endpoint | string | 集群的 APIEndpoint。 |
| --cluster-api-qps | float32 | 与集群 kube-apiserver 通信时使用的 QPS。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 40） |
| --cluster-cache-sync-timeout | duration | 等待集群缓存同步的超时时间。 （默认 30 秒） |
| --cluster-lease-duration | duration | 指定集群lease的有效期。 （默认 40 秒） |
| --cluster-lease-renew-interval-fraction | float | 指定集群lease更新间隔分数。 （默认 0.25） |
| --cluster-name | string | 代理服务的member集群的名称。 |
| --cluster-namespace | string | 控制平面中的哪个namespace存储member集群secret的。 （默认“karmada-cluster”） |
| --cluster-status-update-frequency | duration | 指定 karmada-agent 将集群状态发布到 karmada-apiserver 的频率。 注意：更改常量时要小心，它必须与 karmada-controller-manager 中的 ClusterMonitorGracePeriod 一起使用。 （默认 10 秒） |
| --concurrent-cluster-syncs | int | 允许同时同步的集群数量。 （默认 5） |
| --concurrent-work-syncs | int | 允许同时同步的work数。 （默认 5） |
| --controllers | strings | 要启用的控制器列表。 '*' 启用所有默认开启的控制器，'foo' 启用名为 'foo' 的控制器，'-foo' 禁用名为 'foo' 的控制器。 所有控制器：clusterStatus、execution、serviceExport、workStatus。 （默认 *） |
| --karmada-context | string | karmada 控制平面 kubeconfig 文件中集群上context的名称。 |
| --karmada-kubeconfig | string | Karmada的控制平面 Kubeconfig 文件的路径。 |
| --kube-api-burst | int | 在与 karmada-apiserver 交谈时使用Burst数。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 60） |
| --kube-api-qps | float32 | 与 karmada-apiserver 交谈时使用的 QPS。 不涵盖速率限制由一组不同的标志控制的事件和节点心跳 API。 （默认 40） |
| --kubeconfig | string | member集群kubeconfig 的路径。集群外运行时需要配置。 |
| --leader-elect | 在main loop之前启动一个领导选举客户端并获得领导权。 在运行replicated组件以实现高可用性时启用此功能。 （默认 true） | |
| --leader-elect-resource-namespace | string | leader选举期间用于锁定的资源对象的命名空间。 （默认karmada-system） |
| --log_backtrace_at | traceLocation | when logging hits line file:N, emit a stack trace (default :0) klog |
| --log_dir | string | 如果非空，则在此目录中写入日志文件 |
| --log_file | string | 如果非空，则使用此日志文件 |
| --log_file_max_size | uint | 定义日志文件可以增长到的最大大小。 单位是兆字节。 如果值为 0，则最大文件大小不受限制。 （默认 1800） |
| --logtostderr | 记录到标准错误而不是文件（默认为真） | |
| --one_output | 如果为真，则仅将日志写入其native severity level（而不是写入每个lower severity level） | |
| --proxy-server-address | string | 用于代理到集群的代理服务器的地址。 |
| --resync-period | duration | 重新同步informers的基本频率。 |
| --skip_headers | 如果为 true，避免在日志消息中使用header prefixes |
karmada-agent启动流程如下：
- karmada将自己注册到集群，在karmada控制面创建保存member集群验证信息的namespace、创建的Cluster对象，创建相关secret。
- 初始化controllerManager之前在karmada控制平面创建了执行分发策略的namespace karmada-es-*。
类似资料：