This article summarizes the process scheduling algorithms of the operating system and analyzes the advantages and disadvantages, including the FIFO algorithm, the shortest task priority algorithm, the rotation algorithm, the multi-level feedback queue algorithm, the lottery scheduling algorithm, and the multi-processor scheduling algorithm. Only the principles of each algorithm are summarized, but not the specific implementation of Linux scheduling algorithms. Scheduling Metrics Before looking at the process scheduling algorithm, let’s see what metrics are followed by the process scheduling algorithm.

The previous article, Kubelet Pod Creation Workflow, explained how kubelet creates pods and how the components collaborate with each other. Based on the previous article, this article will explain how kubelet performs quality of service management for pods. Pod QoS Kubernetes has a QoS type for each Pod, which is used to manage the quality of service for the Pod. There are three types, in decreasing order of priority. Guaranteed: Each container in a Pod must have a request and a limit, and the values must be the same.

This article is based on reading the source code of Kubernetes v1.19.0-rc.3 Kubelet, one of the four components of Kubernetes, maintains the entire lifecycle of a pod and is the last link in the pod creation process of Kubernetes. This article will introduce how Kubelet creates pods. Architecture of Kubelet First look at a diagram of the Kubelet’s component architecture, as follows. It can be seen that Kubelet is mainly divided into three layers: API layer, syncLoop layer, CRI and the following; API layer is well understood, that is, the part that provides the interface to the outside; syncLoop layer is the core working layer of Kubelet, the main work of Kubelet is centered around this syncLoop, that is, the control loop, run by producers and consumers; CRI provides the interface of container and mirror services, the container can be accessed as a CRI plugin when running.

There are various network solutions for containers, and it is obviously impractical to adapt every network implementation supported, and CNI was invented to be compatible with multiple network solutions.CNI stands for Container Network Interface, which is a standard common interface to connect container management system and network plugins. In simple terms, container runtime provides network namespace for containers, network plug-in is responsible for inserting network interface into the network namespace

There are more and more networking solutions for containers, and with each new solution, it is obviously unreasonable to adapt the networking solution to different container runtimes, and CNI is designed to solve this problem. While maintaining a “home-level Kubernetes cluster” at home during holidays, I got the idea to write a network plugin, and developed Village Net based on cni/plugin. Taking this network plugin as an example, this article focuses on how to implement a CNI plugin.

Recently, I have been doing CSI-related work, and as I have been developing it, I have come to believe that the details of CSI are quite tedious. By organizing the CSI workflow, I can deepen my understanding of CSI and share my knowledge of CSI with you. I will introduce CSI through two articles, the first of which will focus on the basic components and workings of CSI, based on Kubernetes as the COs (Container Orchestration Systems) for CSI.

This article is based on reading the source code of Kubernetes v1.22.1 Kubelet allows nodes to be evicted if they are under-resourced. I have recently studied Kubelet’s eviction mechanism and found a lot to learn from it, so I’ll share it with you. Kubelet Configuration Kubelet’s eviction feature needs to be turned on in the configuration, and the threshold value for eviction needs to be configured. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 type KubeletConfiguration struct { .

There are three principles of Rust Ownership to keep in mind. For each value, there is an owner. There can only be one owner for a value at a time. When the owner leaves the scope, the corresponding value is automatically dropped. hello is a string allocated on the heap, and the owner is s, which, when passed as an argument to the function takes_ownership, moves ownership to some_string . That is, the hello string will be dropped when the function returns, so main will report an error if it prints line 4 because it has been moved.

The core concept of Rust is Ownership, a GC-enabled language that allows the runtime to sweep the heap at runtime and release unreferenced garbage objects, such as go. For languages like c/c++, you need to manage the allocation and release of memory yourself. Rust uses the concept of Ownership and appends various check rules to the compiler to implement memory management. Note that most of Rust’s work is done at

What is systemtap We generally debug our programs, and the logs printed by the business process are basically sufficient for our needs. If not, using strace, lsof, or perf is enough to see the bottleneck of performance. But for system programming, you can’t print logs like crazy, and many call stacks are in kernel space, so ordinary debugging means are stretched to the limit. At this point systemtap comes in handy, it adds probe probes to kernel functions, aggregates statistics on kernel space function calls, and even intervenes in them.

Rust has a reputation for having a steep learning curve and a rigorous and secure language. But recently, while studying The Book, I discovered that it allows variable shadowing . If the ordinary shadowing is not enough, the same lexical scope allows different types of variables, using the same variable name . What else can I say but shock? Let’s look at the case of rust, go. Common usage 1 2 3 4 5 6 7 8 9 fn main() { let x = 5; let x = x + 1; let x = x * 2; println!

We all know that the smallest unit of scheduling in k8s is the POD, and each POD has a so-called Infra container Pause, so what exactly is a Pause container? What does it look like? What does it do? Analyze the source code From the official pause.c. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 #include <signal.

Concurrency safety is the most basic common sense, but also the most easily ignored premise, more test an engineer language fundamentals and code specification. Concurrent access to modify variables can lead to a variety of unpredictable results, the most serious is the program panic, such as the common go language map concurrent read/write panic. Let’s start with a few examples, the old cliché case, and

The company’s internal golang middleware reported a UDP connection exception log, the problem is obvious, the service on the other side down. Restart it and it will be fine. But the question I’m wondering is how does udp detect when the other side is down? 1 2 3 4 5 6 7 err: write udp 172.16.44.62:62651->172.16.0.46:29999: write: connection refused err: write udp 172.16.44.62:62651->172.16.0.46:29999: write: connection refused err: write udp 172.16.44.62:62651->172.16.0.46:29999:

Google’s self-developed Fuchsia operating system is now available as a full Chrome browser experience, a further step towards widespread deployment, according to tech media outlet 9to5Google. Previously, users have had very limited access to the web on Fuchsia for some time now through the operating system’s “Simple Browser” app (powered by the Chromium engine). But even so, the “browser” didn’t offer some of the daily necessities such as the address bar or tabs.

Go1.18 will be released in a few weeks (March), and we have already updated several new version features, today we bring you a new optimization class that is related to strings and bytes standard library. Background Want to copy faster In everyday programming, bytes []byte are often copied. The following code needs to be written. 1 2 dup := make([]byte, len(data)) copy(dup, data) @Ilia Choly thinks this would be too

First of all what are lifetimes? Lifetimes define the valid range of a reference, in other words lifetimes are a tool used by the compiler to compare the lifetime of the owner and the borrower, in order to avoid dangling pointer as much as possible. 1 2 3 4 5 6 7 8 9 10 11 12 13 fn main() { { let r; { let x = 5; r = &x; // ^^ borrowed value does not live long enough } // - `x` dropped here while still borrowed println!

Those familiar with c++ definitely know shared_ptr , unique_ptr , and Rust also has smart pointers Box , Rc , Arc , RefCell , etc. This article shares the underlying implementation of Box . Box<T> allocates space on the heap, stores the T value, and returns the corresponding pointer. Also Box implements trait Deref dereference and Drop destructor to automatically free space when Box leaves the scope. Getting Started Example Example from the rust book, without the print statement for demonstration purposes.

We know that rust ownership has three principles: For each value, there is an owner. A value can only have one owner at a time. When the owner leaves the scope, the corresponding value is automatically dropped. But sometimes a value is shared by multiple variables. Also it cannot be solved by reference, because there is no way to determine which variable ended up last and there is no way

This article refers to rust book ch15 and adds its own understanding, interested parties can first look at the official documentation. Rust has two ways to achieve mutability Inheritance variability: for example, if a struct is declared with let mut, then any field of the struct can be modified later. Internal mutability: use Cell RefCell to wrap a variable or field so that it can be modified even if the external variable is read-only It seems that inheritance mutability is enough, so why do we need the so-called interior mutability internal mutability?