K8s:kube-apiserver start-Up process-2

This is a creation in Article, where the information may have evolved or changed.

Objective

More than one word, online editing inconvenient, this is the 2nd part of the K8s:kube-apiserver start-up process
Portal: K8s:kube-apiserver Start-up process-1

Review

Last talk about the Run method:

// kubernetes/cmd/kube-apiserver/app.server.gofunc Run(runOptions *options.ServerRunOptions, stopCh <-chan struct{}) error {    ...    server, err := CreateServerChain(runOptions, stopCh)    if err != nil {        return err    }    return server.PrepareRun().Run(stopCh)}

The following API servers are currently available in the system:

• Customresourcedefinitions
• Master
• Apiaggregator

Each API server corresponds to a config (config)

• Apiextensionsapiserver. Config
• Master. Config
• Aggregatorapiserver. Config

Createserverchain's task is to create xxxconfig based on serverrunoptions and then create an API server with Xxxconfig, each API server through Genericapiserver D Elegationtarget fields form the chain of responsibility
Take the example of Master API server creation:

func CreateServerChain(runOptions *options.ServerRunOptions, stopCh <-chan struct{})(*genericapiserver.GenericAPIServer, error) {    ...    kubeAPIServerConfig, ... := CreateKubeAPIServerConfig(...)    ...    kubeAPIServer, err := CreateKubeAPIServer(kubeAPIServerConfig,         apiExtensionsServer.GenericAPIServer, sharedInformers, versionedInformers)    

The following is a brief introduction to the creation of the Master API server, which focuses on how Kube-apiserver binds resource objects (Node,pod,service, etc.) to specific restful APIs, allowing clients to use the RESTful API Manipulating Resource objects

What would you do if you were?

After probably looking at some source code, I couldn't help but ask myself: what would you do if you were to design the code architecture?
For example, given an entity Student (Java pseudocode, same as below), persisted in ETCD

public class Student {    public int id;    public String name;    public String phone;}

How do I provide a RESTful API interface that provides CRUD operations on Student? Design a code framework that adapts to all entities

API Interface Example:

Incremented (assuming parameters are passed by URL)

PUT /user?id=xxx&name=yyy&phone=zzz

Delete

DELETE /user?id=xxx

Modify

POST /user?id=xxx&name=yyy

Inquire

GET /user?id=xxx

We take a few steps to consider, first consider persistence, in order to support different persistence frameworks, or we need to consider the framework version matching problem in the immediate use of a persistence framework, which needs to abstract the basic operation of the persistence framework, extracting the interface backend

public interface Backend {    String get(String key);    void set(String key, String value);}

Then we have specific implementations of class Etcdbackend, Consulbackend and factory class Backendfactory

public class EtcdBackend implements Backend {    public String get(String key) { ... }    public void set(String key, String value) { ... }}public class ConsulBackend implements Backend {    public String get(String key) { ... }    public void set(String key, String value) { ... }}public class BackendFactory {    Backend get(String name) { ... }}

Backend's done, now we need a DAO (Data Access object) to access it

public class UserDao {    private Backend backend;    // CRUD 方法    ...}

We note that there are many entities that need to access the backend storage using the backend interface, so you can get a base class Abstractdao and move the Backedn field to the base class.

pubic class AbstractDao {    private Backend backend;}public class User extends AbstractDao {    // CRUD 方法    ...}

Further observation, in fact, the various DAO CRUD methods also have a lot of duplicate (template) code, such as if we can encapsulate the following change point:

• Generate the key required for back-end storage
• Serialization and deserialization of objects

The CRUD methods in DAO can be further extracted into the Abstractdao, and those methods that need to be instantiated by subclasses can be implemented by the template method mode.

public class AbstractDao {    private Backend backend;    // CRUD 方法    ...}public class UserDao extends AbstractDao {    // Template 方法    ...}

We are now a step closer to the final completion, and the only question is how to match the URL to DAO, which is a mapping problem, and you can use map to keep the DAO of the URL corresponding

map.put("/user", userDao)

The above is just a simple deduction, k8s than this demo more complex, considering a variety of decoupling and extensibility, next time will formally introduce the implementation of k8s