k8s (kubernetes) 代码分析

API源码分析

API server 是中心．　https://www.jianshu.com/p/88c6ed78b668

$ git ls-files |grep apiserver |less

cmd/kube-apiserver/apiserver.go　是入口

scheduler 源码分析．

$ git ls-files |grep scheduler |less

可以看到　scheduler 的主要目录，有cmd, algorithm, api ...

可以猜出来这些文件是干啥的．　

算法下面：

ls plugin/pkg/scheduler/algorithm/ 
BUILD  doc.go  listers.go  predicates  priorities  scheduler_interface.go  scheduler_interface_test.go  types.go

cmd是　就是command吗，main 函数的入口．

打开　plugin/cmd/kube-scheduler/scheduler.go　发现启动了一个SchedulerServer．

深入进去

配置

plugin/cmd/kube-scheduler/app/options/options.go　-> pkg/apis/componentconfig/types.go

看到其实　KubeSchedulerConfiguration，　就是一个http的server.

看来这个与openstack不同，不是采用rpc通信．　

监听的server

plugin/cmd/kube-scheduler/app/server.go

Run 起了两个server.

1. startHTTP

主要是　Profiling　和　metrics

2. sched.Run

需要先创建有两个函数ｓｃｈｅｄｕｌｅｒ，有两个函数　CreateFromProvider　和　CreateFromConfig．

主要执行的函数是scheduleOne　

做了一个Binding, 不知道做啥用，先看　pkg/api/v1/types.go　说明

// Binding ties one object to another.
// For example, a pod is bound to a node by a scheduler.
type Binding struct {
    metav1.TypeMeta `json:",inline"`
    // Standard object's metadata.
    // More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#metadata
    // +optional
    metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

    // The target object that you want to bind to the standard object.
    Target ObjectReference `json:"target" protobuf:"bytes,2,opt,name=target"`
}

开启的貌似是个http的client.

主要数据结构看　plugin/pkg/scheduler/scheduler.go　中Config的定义．

3. 还有LeaderElection, 先略过去，　后面单独分析选举算法．

４. 具体怎么找到未分配的pod，　还需要进一步的分析．

有关ｓｃｈｅｄｕｌｅｒ分析的文章，网上比比皆是．

http://cizixs.com/　写了一系列的分析文章

对比opentstack的schedule

Kubelet源码分析(一):启动流程分析

入口　cmd/kubelet/kubelet.go