前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >kubescheduler源码解析

kubescheduler源码解析

作者头像
sealyun
发布2019-07-25 14:28:50
1.4K0
发布2019-07-25 14:28:50
举报
文章被收录于专栏:sealyun

kubernetes集群三步安装

kube-scheduler源码分析

关于源码编译

我嫌弃官方提供的编译脚本太麻烦,所以用了更简单粗暴的方式编译k8s代码,当然官方脚本在编译所有项目或者夸平台编译以及realse时还是挺有用的。

在容器中编译:

代码语言:javascript
复制
docker run -v /work/src/k8s.io/kubernetes:/go/src/k8s.io/kubernetes golang:1.11.2 bash

在容器中可以保证环境干净

进入bash后直接进入kube-scheduler的主目录编译即可

代码语言:javascript
复制
cd cmd/kube-scheduler && go build

二进制就产生了。。。

源码编译接入CI/CD

作为高端玩家,自动化是必须的,因为服务器性能更好,用CI/CD编译更快,这里分享一下我的一些配置:

  1. 我把vendor打到编译的基础镜像里了,因为vendor大而且不经常更新
代码语言:javascript
复制
$ cat Dockerfile-build1.12.2
FROM golang:1.11.2
COPY vendor/ /vendor

然后代码里的vendor就可以删了

  1. .drone.yml
代码语言:javascript
复制
workspace:
  base: /go/src/k8s.io
  path: kubernetes
pipeline:
    build:
        image: fanux/kubernetes-build:1.12.2-beta.3
        commands:
           - make all WHAT=cmd/kube-kubescheduler GOFLAGS=-v
    publish:
        image: plugins/docker
        registry: xxx
        username: xxx
        password: xxx
        email: xxx
        repo: xxx/container/kube-scheduler
        tags: ${DRONE_TAG=latest}
        dockerfile: dockerfile/Dockerfile-kube-scheduler
        insecure: true
        when:
            event: [push, tag]
  1. Dockerfile 静态编译连基础镜像都省了
代码语言:javascript
复制
$ cat dockerfile/Dockerfile-kube-scheduler
FROM scratch
COPY  _output/local/bin/linux/amd64/kube-scheduler /
CMD ["/kube-scheduler"]

对于kubeadm这种二进制交付的,可直接编译然后传到nexus上, 通过drone deploy事件选择是不是要编译kubeadm:

代码语言:javascript
复制
build_kubeadm:
        image: fanux/kubernetes-build:1.12.2-beta.3
        commands:
           - make all WHAT=cmd/kube-kubeadm GOFLAGS=-v
           - curl -v -u container:container --upload-file kubeadm http://172.16.59.153:8081/repository/kubernetes/kubeadm/
        when:
            event: deployment
            enviroment: kubeadm

直接go build的大坑

发现build完的kubeadm二进制并不能用,可能是build时选用的基础镜像的问题,也可能是没去生成一些代码导致的问题

代码语言:javascript
复制
[signal SIGSEGV: segmentation violation code=0x1 addr=0x63 pc=0x7f2b7f5f057c]
runtime stack:
runtime.throw(0x17c74a8, 0x2a)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:374 +0x2f2

后面再补上CD的配置

如此我编译scheduler代码大约40秒左右,如vendor可软连接还可节省十几秒

调度器cache

cache状态机

代码语言:javascript
复制
+-------------------------------------------+     +----+
|                            Add            |     |    |
|                                           |     |    | Update
+      Assume                Add            v     v    |
Initial +--------> Assumed +------------+---> Added <--+
^                +   +                  |       +
|                |   |                  |       |
|                |   |              Add |       | Remove
|                |   |                  |       |
|                |   |                  +       |
+----------------+   +-----------> Expired+----> Deleted
  • Assume 尝试调度,会把node信息聚合到node上,如pod require多少CPU内存,那么加到node上,如果超时了需要重新减掉
  • AddPod 会检测是不是已经尝试调度了该pod,校验是否过期,如果过期了会被重新添加
  • Remove pod信息会在该节点上被清除掉
  • cache其它接口如node相关的cache接口 ADD update等

cache实现

代码语言:javascript
复制
type schedulerCache struct {
	stop   <-chan struct{}
	ttl    time.Duration
	period time.Duration
	// This mutex guards all fields within this cache struct.
	mu sync.RWMutex
	// a set of assumed pod keys.
	// The key could further be used to get an entry in podStates.
	assumedPods map[string]bool
	// a map from pod key to podState.
	podStates map[string]*podState
	nodes     map[string]*NodeInfo
	nodeTree  *NodeTree
	pdbs      map[string]*policy.PodDisruptionBudget
	// A map from image name to its imageState.
	imageStates map[string]*imageState
}

这里存储了基本调度所需要的所有信息

以AddPod接口为例,本质上就是把监听到的一个pod放到了cache的map里:

代码语言:javascript
复制
cache.addPod(pod)
ps := &podState{
	pod: pod,
}
cache.podStates[key] = ps

node Tree 节点信息有这样一个结构体保存:

代码语言:javascript
复制
type NodeTree struct {
	tree      map[string]*nodeArray // a map from zone (region-zone) to an array of nodes in the zone.
	zones     []string              // a list of all the zones in the tree (keys)
	zoneIndex int
	NumNodes  int
	mu        sync.RWMutex
}

cache 运行时会循环清理过期的assume pod

代码语言:javascript
复制
func (cache *schedulerCache) run() {
	go wait.Until(cache.cleanupExpiredAssumedPods, cache.period, cache.stop)
}

scheduler

scheduler里面最重要的两个东西:cache 和调度算法

代码语言:javascript
复制
type Scheduler struct {
	config *Config  -------> SchedulerCache
|
+---> Algorithm
}

等cache更新好了,调度器就是调度一个pod:

代码语言:javascript
复制
func (sched *Scheduler) Run() {
	if !sched.config.WaitForCacheSync() {
		return
	}
	go wait.Until(sched.scheduleOne, 0, sched.config.StopEverything)
}

核心逻辑来了:

代码语言:javascript
复制
+-------------+
| 获取一个pod |
+-------------+
|
+-----------------------------------------------------------------------------------+
| 如果pod的DeletionTimestamp 存在就不用进行调度, kubelet发现这个字段会直接去删除pod |
+-----------------------------------------------------------------------------------+
|
+-----------------------------------------+
| 选一个suggestedHost,可理解为合适的节点 |
+-----------------------------------------+
|_____________选不到就进入强占的逻辑,与我当初写swarm调度器逻辑类似
|
+--------------------------------------------------------------------------------+
| 虽然还没真调度到node上,但是告诉cache pod已经被调度到node上了,变成assume pod  |
| 这里面会先检查volumes                                                          |
| 然后:err = sched.assume(assumedPod, suggestedHost) 假设pod被调度到node上了    |
+--------------------------------------------------------------------------------+
|
+---------------------------+
| 异步的bind这个pod到node上 |
| 先bind volume             |
| bind pod                  |
+---------------------------+
|
+----------------+
| 暴露一些metric |
+----------------+

bind动作:

代码语言:javascript
复制
err := sched.bind(assumedPod, &v1.Binding{
	ObjectMeta: metav1.ObjectMeta{Namespace: assumedPod.Namespace, Name: assumedPod.Name, UID: assumedPod.UID},
	Target: v1.ObjectReference{
		Kind: "Node",
		Name: suggestedHost,
	},
})

先去bind pod,然后告诉cache bind结束

代码语言:javascript
复制
err := sched.config.GetBinder(assumed).Bind(b)
if err := sched.config.SchedulerCache.FinishBinding(assumed);

TODO: bind具体做了什么

调度算法

代码语言:javascript
复制
▾ algorithm/
▸ predicates/  预选
▸ priorities/  优选

现在最重要的就是选节点的实现

代码语言:javascript
复制
suggestedHost, err := sched.schedule(pod)

也就是调度算法的实现:

代码语言:javascript
复制
type ScheduleAlgorithm interface {
// 传入pod 节点列表,返回一下合适的节点
	Schedule(*v1.Pod, NodeLister) (selectedMachine string, err error)
// 资源抢占用的
	Preempt(*v1.Pod, NodeLister, error) (selectedNode *v1.Node, preemptedPods []*v1.Pod, cleanupNominatedPods []*v1.Pod, err error)
// 预选函数集,
	Predicates() map[string]FitPredicate
|                              这一个节点适合不适合调度这个pod,不适合的话返回原因
+-------type FitPredicate func(pod *v1.Pod, meta PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []PredicateFailureReason, error)
// 返回优选配置,最重要两个函数 map 和 reduce
	Prioritizers() []PriorityConfig
|____________PriorityMapFunction 计算 节点的优先级
|____________PriorityReduceFunction 根据map的结果计算所有node的最终得分
|____________PriorityFunction 废弃
}

调度算法可以通过两种方式生成:

  • Provider 默认方式, 通用调度器
  • Policy 策略方式, 特殊调度器

最终new了一个scheduler:

代码语言:javascript
复制
priorityConfigs, err := c.GetPriorityFunctionConfigs(priorityKeys)
priorityMetaProducer, err := c.GetPriorityMetadataProducer()
predicateMetaProducer, err := c.GetPredicateMetadataProducer()
|
algo := core.NewGenericScheduler(                 |
	c.schedulerCache,                         |
	c.equivalencePodCache,                    V
	c.podQueue,
	predicateFuncs,   ============> 这里面把预选优选函数都注入进来了
	predicateMetaProducer,
	priorityConfigs,
	priorityMetaProducer,
	extenders,
	c.volumeBinder,
	c.pVCLister,
	c.alwaysCheckAllPredicates,
	c.disablePreemption,
	c.percentageOfNodesToScore,
)
type genericScheduler struct {
	cache                    schedulercache.Cache
	equivalenceCache         *equivalence.Cache
	schedulingQueue          SchedulingQueue
	predicates               map[string]algorithm.FitPredicate
	priorityMetaProducer     algorithm.PriorityMetadataProducer
	predicateMetaProducer    algorithm.PredicateMetadataProducer
	prioritizers             []algorithm.PriorityConfig
	extenders                []algorithm.SchedulerExtender
	lastNodeIndex            uint64
	alwaysCheckAllPredicates bool
	cachedNodeInfoMap        map[string]*schedulercache.NodeInfo
	volumeBinder             *volumebinder.VolumeBinder
	pvcLister                corelisters.PersistentVolumeClaimLister
	disablePreemption        bool
	percentageOfNodesToScore int32
}

这个scheduler实现了ScheduleAlgorithm中定义的接口

Schedule 流程:

代码语言:javascript
复制
+------------------------------------+
| trace记录一下,要开始调度哪个pod了 |
+------------------------------------+
|
+------------------------------------------------+
| pod基本检查,这里主要检查卷和delete timestamp |
+-----------------------------------------------+
|
+----------------------------------------+
| 获取node列表, 更新cache的node info map |
+----------------------------------------+
|
+----------------------------------------------+
| 预选,返回合适的节点列表和预选失败节点的原因 |
+----------------------------------------------+
|
+----------------------------------------------------------+
| 优选,                                                   |
| 如果预选结果只有一个节点,那么直接使用之,不需要进行优选 |
| 否则进行优选过程                                         |
+----------------------------------------------------------+
|
+------------------------------------+
| 在优选结果列表中选择得分最高的节点 |
+------------------------------------+

预选

主要分成两块

  • 预选, 检查该节点符合不符合
  • 执行extender, 自定义调度器扩展,官方实现了HTTP extender 把预选结果发给用户,用户再去过滤

podFitOnNode: 判断这个节点是不是适合这个pod调度

这里插播一个小知识,调度器里有个Ecache:

Equivalence Class目前是用来在Kubernetes Scheduler加速Predicate,提升Scheduler的吞吐性能。 Kubernetes scheduler及时维护着Equivalence Cache的数据,当某些情况发生时(比如delete node、bind pod等事件), 需要立刻invalid相关的Equivalence Cache中的缓存数据。

一个Equivalence Class是用来定义一组具有相同Requirements和Constraints的Pods的相关信息的集合, 在Scheduler进行Predicate阶段时可以只需对Equivalence Class中一个Pod进行Predicate,并把Predicate的结果放到 Equivalence Cache中以供该Equivalence Class中其他Pods(成为Equivalent Pods)重用该结果。只有当Equivalence Cache 中没有可以重用的Predicate Result才会进行正常的Predicate流程。

ecache这块后续可以深入讨论,本文更多关注核心架构与流程

所以这块就比较简单了, 把所有的预选函数执行行一遍

代码语言:javascript
复制
先排序 predicates.Ordering()
if predicate, exist := predicateFuncs[predicateKey]; exist {
		fit, reasons, err = predicate(pod, metaToUse, nodeInfoToUse)

顺序是这样的:

代码语言:javascript
复制
predicatesOrdering = []string{CheckNodeConditionPred, CheckNodeUnschedulablePred,
		GeneralPred, HostNamePred, PodFitsHostPortsPred,
		MatchNodeSelectorPred, PodFitsResourcesPred, NoDiskConflictPred,
		PodToleratesNodeTaintsPred, PodToleratesNodeNoExecuteTaintsPred, CheckNodeLabelPresencePred,
		CheckServiceAffinityPred, MaxEBSVolumeCountPred, MaxGCEPDVolumeCountPred, MaxCSIVolumeCountPred,
		MaxAzureDiskVolumeCountPred, CheckVolumeBindingPred, NoVolumeZoneConflictPred,
		CheckNodeMemoryPressurePred, CheckNodePIDPressurePred, CheckNodeDiskPressurePred, MatchInterPodAffinityPred}

这些预选函数是存在一个map里的,key是一个string,value就是一个预选函数, 再回头去看注册map的逻辑

代码语言:javascript
复制
predicateFuncs, err := c.GetPredicates(predicateKeys)

pkg/scheduler/algorithmprovider/defaults/defaults.go 里面会对这些函数进行注册,如:

代码语言:javascript
复制
factory.RegisterFitPredicate(predicates.NoDiskConflictPred, predicates.NoDiskConflict),
factory.RegisterFitPredicate(predicates.GeneralPred, predicates.GeneralPredicates),
factory.RegisterFitPredicate(predicates.CheckNodeMemoryPressurePred, predicates.CheckNodeMemoryPressurePredicate),
factory.RegisterFitPredicate(predicates.CheckNodeDiskPressurePred, predicates.CheckNodeDiskPressurePredicate),
factory.RegisterFitPredicate(predicates.CheckNodePIDPressurePred, predicates.CheckNodePIDPressurePredicate),

然后直接在init函数里调用注册逻辑

优选

PrioritizeNodes 优选大概可分为三个步骤:

  • Map 计算单个节点,优先级
  • Reduce 计算每个节点结果聚合,计算所有节点的最终得分
  • Extender 与预选差不多

优选函数同理也是注册进去的, 不再赘述

代码语言:javascript
复制
factory.RegisterPriorityFunction2("LeastRequestedPriority", priorities.LeastRequestedPriorityMap, nil, 1),
// Prioritizes nodes to help achieve balanced resource usage
factory.RegisterPriorityFunction2("BalancedResourceAllocation", priorities.BalancedResourceAllocationMap, nil, 1),

这里注册时注册两个,一个map函数一个reduce函数,为了更好的理解mapreduce,去看一个实现

代码语言:javascript
复制
factory.RegisterPriorityFunction2("NodeAffinityPriority", priorities.CalculateNodeAffinityPriorityMap, priorities.CalculateNodeAffinityPriorityReduce, 1)

node Affinity map reduce

map 核心逻辑, 比较容易理解:

代码语言:javascript
复制
如果满足节点亲和,积分加权重
count += preferredSchedulingTerm.Weight
return schedulerapi.HostPriority{
	Host:  node.Name,
	Score: int(count),  # 算出积分
}, nil

reduce: 一个节点会走很多个map,每个map会产生一个分值,如node affinity产生一个,pod affinity再产生一个,所以node和分值是一对多的关系

去掉reverse的逻辑(分值越高优先级越低)

代码语言:javascript
复制
var maxCount int
for i := range result {
	if result[i].Score > maxCount {
		maxCount = result[i].Score  # 所有分值里的最大值
	}
}
for i := range result {
	score := result[i].Score
	score = maxPriority * score / maxCount  # 分值乘以最大优先级是maxPriority = 10,除以最大值赋值给分值 我没明白
	result[i].Score = score
}
代码语言:javascript
复制
for i := range priorityConfigs {
	if priorityConfigs[i].Function != nil {
		continue
	}
	results[i][index], err = priorityConfigs[i].Map(pod, meta, nodeInfo)
	if err != nil {
		appendError(err)
		results[i][index].Host = nodes[index].Name
	}
}
err := config.Reduce(pod, meta, nodeNameToInfo, results[index]);

看这里有个results,对理解很重要,是一个二维数组:

xxx

node1

node2

node3

nodeaffinity

1分

2分

1分

pod affinity

1分

3分

6分

这样reduce时取一行,其实也就是处理所有节点的某项得分

代码语言:javascript
复制
result[i].Score += results[j][i].Score * priorityConfigs[j].Weight  (二维变一维)

reduce完最终这个节点的得分就等于这个节点各项得分乘以该项权重的和,最后排序选最高分 (一维变0纬)

调度队列 SchedulingQueue

scheduler配置里有一个NextPod 方法,获取一个pod,并进行调度:

代码语言:javascript
复制
pod := sched.config.NextPod()

配置文件在这里初始化:

代码语言:javascript
复制
pkg/scheduler/factory/factory.go
NextPod: func() *v1.Pod {
	return c.getNextPod()
},
func (c *configFactory) getNextPod() *v1.Pod {
	pod, err := c.podQueue.Pop()
	if err == nil {
		return pod
	}
...
}

队列接口:

代码语言:javascript
复制
type SchedulingQueue interface {
	Add(pod *v1.Pod) error
	AddIfNotPresent(pod *v1.Pod) error
	AddUnschedulableIfNotPresent(pod *v1.Pod) error
	Pop() (*v1.Pod, error)
	Update(oldPod, newPod *v1.Pod) error
	Delete(pod *v1.Pod) error
	MoveAllToActiveQueue()
	AssignedPodAdded(pod *v1.Pod)
	AssignedPodUpdated(pod *v1.Pod)
	WaitingPodsForNode(nodeName string) []*v1.Pod
	WaitingPods() []*v1.Pod
}

给了两种实现,优先级队列和FIFO :

代码语言:javascript
复制
func NewSchedulingQueue() SchedulingQueue {
	if util.PodPriorityEnabled() {
		return NewPriorityQueue()  # 基于堆排序实现,根据优先级排序
	}
	return NewFIFO() # 简单的先进先出
}

队列实现比较简单,不做深入分析, 更重要的是关注队列,调度器,cache之间的关系:

代码语言:javascript
复制
AddFunc:    c.addPodToCache,
UpdateFunc: c.updatePodInCache,
DeleteFunc: c.deletePodFromCache,
| informer监听,了pod创建事件之后往cache和队列里都更新了
V 
if err := c.schedulerCache.AddPod(pod); err != nil {
	glog.Errorf("scheduler cache AddPod failed: %v", err)
}
c.podQueue.AssignedPodAdded(pod)
代码语言:javascript
复制
+------------+ ADD   +-------------+   POP  +-----------+
| informer   |------>|  sche Queue |------->| scheduler |
+------------+   |   +-------------+        +----^------+
+-->+-------------+             |
| sche cache  |<------------+
+-------------+

Extender

调度器扩展

定制化调度器有三种方式:

  • 改scheduler代码重新编译 - 没啥可讨论
  • 重写调度器,调度时选择调度器 - 比较简单,问题是没法与默认调度器共同作用
  • 写调度器扩展(extender)让k8s调度完了 把符合的节点扔给你 你再去过滤和优选 - 重点讨论,新版本做了一些升级,老的方式可能都无用了 资料
  • 这里有个调度器扩展事例

目前第三点资料非常少,很多细节需要在代码里找到答案,带着问题看代码效果更好。

Extender接口

代码语言:javascript
复制
+----------------------------------+       +----------+
| kube-scheduler -> extender client|------>| extender | (你需要开发的扩展,单独的进程)
+----------------------------------+       +----------+

这个接口是kube-scheduler实现的,下面会介绍HTTPextender的实现

代码语言:javascript
复制
type SchedulerExtender interface {
// 最重要的一个接口,输入pod和节点列表,输出是符合调度的节点的列表
	Filter(pod *v1.Pod,
		nodes []*v1.Node, nodeNameToInfo map[string]*schedulercache.NodeInfo,
	) (filteredNodes []*v1.Node, failedNodesMap schedulerapi.FailedNodesMap, err error)
// 这个给节点打分的,优选时需要用的
	Prioritize(pod *v1.Pod, nodes []*v1.Node) (hostPriorities *schedulerapi.HostPriorityList, weight int, err error)
// Bind接口主要是最终调度器选中节点哪个节点时通知extender
	Bind(binding *v1.Binding) error
	// IsBinder returns whether this extender is configured for the Bind method.
	IsBinder() bool
// 可以过滤你感兴趣的pod 比如按照标签
	IsInterested(pod *v1.Pod) bool
	// ProcessPreemption returns nodes with their victim pods processed by extender based on
	// given:
	//   1. Pod to schedule
	//   2. Candidate nodes and victim pods (nodeToVictims) generated by previous scheduling process.
	//   3. nodeNameToInfo to restore v1.Node from node name if extender cache is enabled.
	// The possible changes made by extender may include:
	//   1. Subset of given candidate nodes after preemption phase of extender.
	//   2. A different set of victim pod for every given candidate node after preemption phase of extender.
// 我猜是与亲和性相关的功能,不太清楚 TODO
	ProcessPreemption(
		pod *v1.Pod,
		nodeToVictims map[*v1.Node]*schedulerapi.Victims,
		nodeNameToInfo map[string]*schedulercache.NodeInfo,
	) (map[*v1.Node]*schedulerapi.Victims, error)
// 优先级抢占特性,可不实现
	SupportsPreemption() bool
// 当访问不到extender时怎么处理,返回真时extender获取不到时调度不能失败
	IsIgnorable() bool
}

官方实现了HTTPextender,可以看下:

代码语言:javascript
复制
type HTTPExtender struct {
	extenderURL      string
	preemptVerb      string
	filterVerb       string  # 预选RUL
	prioritizeVerb   string  # 优选RUL
	bindVerb         string
	weight           int
	client           *http.Client
	nodeCacheCapable bool
	managedResources sets.String
	ignorable        bool
}

看其预选和优选逻辑:

代码语言:javascript
复制
args = &schedulerapi.ExtenderArgs{  # 调度的是哪个pod,哪些节点符合调度条件, 返回的也是这个结构体
	Pod:       pod,
	Nodes:     nodeList,
	NodeNames: nodeNames,
}
if err := h.send(h.filterVerb, args, &result); err != nil { # 发了个http请求给extender(你要去实现的httpserver), 返回过滤后的结构
	return nil, nil, err
}

HTTPExtender配置参数从哪来

scheduler extender配置:

代码语言:javascript
复制
NamespaceSystem string = "kube-system"
SchedulerDefaultLockObjectNamespace string = metav1.NamespaceSystem
// SchedulerPolicyConfigMapKey defines the key of the element in the
// scheduler's policy ConfigMap that contains scheduler's policy config.
SchedulerPolicyConfigMapKey = "policy.cfg"

总结

调度器的代码写的还是挺不错的,相比较于kube-proxy好多了,可扩展性也还可以,不过目测调度器会面临一次大的重构,现阶段调度器对深度学习的批处理任务支持就不好 而one by one调度的这种设定关系到整个项目的架构,要想优雅的支持更优秀的调度估计重构是跑不掉了

www.sealyun.com

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-12-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 sealyun 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • kube-scheduler源码分析
    • 关于源码编译
      • 源码编译接入CI/CD
      • 直接go build的大坑
  • 调度器cache
    • cache状态机
      • cache实现
      • scheduler
        • bind动作:
          • 调度算法
            • 预选
            • 优选
            • node Affinity map reduce
        • 调度队列 SchedulingQueue
        • Extender
          • 调度器扩展
            • Extender接口
              • HTTPExtender配置参数从哪来
                • scheduler extender配置:
                  • 总结
                  相关产品与服务
                  容器服务
                  腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档