Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to read the kubernetes source code

2025-01-20 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

This article mainly shows you "how to read kubernetes source code", the content is simple and easy to understand, organized clearly, I hope to help you solve doubts, let Xiaobian lead you to study and learn "how to read kubernetes source code" this article.

Why Read Code? How to read k8s source code?

The source code contains all the information. When writing open source software, you get second-hand information from documentation and other sources, and the code is the most direct first-hand information. The code is what neo sees as the origin of the world in the matrix.

Text is not code itself. Text is just a compromise between human-readable schema and compiler parsable. Code is essentially a data structure with complex topology, like trees or circuits. So the process of reading code is to construct this world in the brain, and the so-called brain supplement is also.

Reading good code is a pleasure. My favorite thing to read is redis code, written in C, extremely concise but powerful. The most efficient and sophisticated data structure can be achieved in a few words, like a Sherlock Holmes detective novel. When I look at it, I often think, if I can implement this function, can it be as simple and efficient as him?

Take reading one of the modules of k8s, scheduler as an example, to tell me how I read the code.

What does the scheduler module do from the user's perspective?

Scheduler is the scheduling module of k8s. What it does is to find a suitable one in the node to adapt after getting the pod. In fact, I've compiled and built this program and run it many times. In my mind, the shedder across the system looks like this:

Scheduler, as a client, reads the pod to be allocated and the node owned from apiserver, then filters and calculates the score, and finally writes this matching information to etcd through apiserver for the next kubelet to pull up the pod. And so, immediately, several questions arose.

Q 1. What is the data structure read by scheduler? (input)

Q 2. What is the data structure written by scheduler? (Output)

Q3. In the previous test, the scheduler became the bottleneck of the system. Why?

Q4. Is it feasible for someone in the community to say that adding cache can effectively improve the efficiency of scheduler?

Read the entire experience of scheduler code Layer 1: cmd entry kubernetes\plugin\cmd\kube-scheduler\scheduler.go

This code is shorter and posted in full.

package mainimport ( "runtime" "k8s.io/kubernetes/pkg/healthz" "k8s.io/kubernetes/pkg/util" "k8s.io/kubernetes/pkg/version/verflag" "k8s.io/kubernetes/plugin/cmd/kube-scheduler/app" "github.com/spf13/pflag")func init() { healthz.DefaultHealthz() //ignore...}func () { runtime.GOMAXPROCS(runtime.NumCPU()) //ignore... s := app.NewSchedulerServer() //focus on the initialization of the actual call s.AddFlags(pflag.CommandLine) //ignore, command line parsing util.InitFlags() util.InitLogs() defer util.FlushLogs() //ignore, open log, etc. verflag.PrintAndExitIfRequested() s.Run(pflag.CommandLine.Args()) //Pay attention to the actual opening}

As you can see, I ignore all the details and move on to the next level. However, it is not that I do not ask questions. The questions I ask will be written here and then "forgotten" from my mind to ease the burden of progress.

kubernetes\plugin\cmd\kube-scheduler\app\server.go

After entering this file, the focus is on the data structure and method:

Scheduler Server This structure stores a bunch of configuration information, naked, you can see that several member variables inside are basic types, int, string, etc.

The main purpose of the two methods invoked at the previous level is to retrieve configuration information. After obtaining information from command line parameters and configuration file kubeconfig,

The Run method starts some performance, health information on the http interface, and then actually calls the next layer.

Kubeconfig is for kubeclient services.

A factory pattern is also used to create algorithm-specific dispatchers named Algorithms Provider.

The entrance to the next floor is at:

sched := scheduler.New(config)sched.Run()

The problem for this layer is:

Q5. How are several current limits implemented? What is the difference between QPS and Brust?

Q6. How is algorithmProvider abstracted? What needs to be done?

A5. After flipping through the current-limiting code, I found that the algorithm from kubernetes\Godeps\_workspace\src\github.com\juju\ratelimit, implemented is a token bucket algorithm, burst refers to the measure of maintaining the average value of qps within n requests. See this article for details

Layer 2: pkg Outer Interface kubernetes\plugin\pkg\scheduler\scheduler.go

A2: Here I see that the output data structure is:

b := &api.Binding{ ObjectMeta: api.ObjectMeta{Namespace: pod.Namespace, Name: pod.Name}, Target: api.ObjectReference{ Kind: "Node", Name: dest, }, }

The most important data structures of this file are:

type Config struct { // It is expected that changes made via modeler will be observed // by NodeLister and Algorithm. Modeler SystemModeler NodeLister algorithm.NodeLister Algorithm algorithm.ScheduleAlgorithm Binder Binder // Rate at which we can create pods // If this field is nil, we don't have any rate limit. BindPodsRateLimiter util.RateLimiter // NextPod should be a function that blocks until the next pod // is available. We don't use a channel for this, because scheduling // a pod may take some amount of time and we don't want pods to get // stale while they sit in a channel. NextPod func() *api.Pod // Error is called if there is an error. It is passed the pod in // question, and the error Error func(*api.Pod, error) // Recorder is the EventRecorder to use Recorder record.EventRecorder // Close this to shut down the scheduler. StopEverything chan struct{}}

What is the data structure? Data structures are the characters on stage, and functional methods are the plays between those characters. Objects are alive, from creation to data flow, from birth to death. As developers, the first thing to understand is these character settings, Guan Gong or Qin Qiong, red face or black face? If you understand the person, you understand the play.

In this code, combined with the following methods, I can get these impressions:

Modeler is a model of all nodes, but I don't know how to do pod mutual exclusion.

NodeLister is used to list nodes.

Algorithm is used for scheduling.

Binder is used to do the actual binding operation

The rest, Ratelimiter said it was to limit the current, the rest were not very important, skipped

Q7. After watching modeler.go, I found that this is processed after binding. The so-called assuemPod is to put the bound pods into a queue. Don't you understand why this mutual exclusion operation is done after binding?

Q 8. How does Binder do binding operations?

Entrance to the next level:

dest, err := s.config.Algorithm.Schedule(pod, s.config.NodeLister) Layer 3: pkg Inner layer implementation kubernetes\plugin\pkg\scheduler\generic_scheduler.go

When I moved to this level, I found myself going too far. s.config. Algorithms.Schedule doesn't call generic_scheduler.go. For an object-oriented language, the final execution may be one interface within another, and the separation of interface and implementation causes you to read somewhere and then not go further. In other words, a purely top-down reading approach does not lend itself to object-oriented code. So my approach to reading is starting to become piecemeal, going through the entire code tree, looking for answers in places that are most likely to explain my questions, and piecing together the truth piece by piece.

Q 9.How does generic_scheduler. go relate to scehduler.go?

This is the code tree:

From the directory tree, you can see that the directory of scheduling algorithms is in algrorithem and algrorithemprovider, and the key source code for assembling objects is in:

File 1: factory.go

A 8. Binder operation is actually very simple, that is, put the two fields of pod and node in the http request and send it to the apiserver to bind, which is also consistent with the overall architecture of the system.

The biggest role of factory is to obtain--algorithm and--policy-config-file from command line parameters to obtain the necessary algorithm name and scheduling policy to construct Config, which is actually the core data structure of the scheduler. schduler What this whole program does can be summarized as: Get Configuration Information-Build Config-Run Config. This process is similar to sping-assembling objects in java, except that in this case it's done explicitly through code. From the assembly plant, we see a key line

algo := scheduler.NewGenericScheduler(predicateFuncs, priorityConfigs, extenders, f.PodLister, r)

This answers Question 9 above.

A 9.scheduler.go is form, generic_scheduler.go is content, assembled by factory

I also answered question 6.

A 6. factoryProvider is only an expression of key value pairs registered by an algorithm, most of the implementations are still placed in generic_scheduler.

File 2: generic_scheduler.go

This involves the core logic of scheduling, just two lines

filteredNodes, failedPredicateMap, err := findNodesThatFit().... priorityList, err := PrioritizeNodes()...

Filter first to find legal nodes that do not cause conflicts

Score from legal nodes and find the node with the highest score to bind

In order to avoid the node with the highest score being crashed by several dispatches, randomly find one from the node with the highest score.

Implementation of Layer 4 Scheduling Algorithm

I won't go into details here, but the reader can follow my path to find out for himself.

The above is "how to read kubernetes source code" all the content of this article, thank you for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report