Project: iSulad (Runtime / Container Runtime)
File: native_network_design.md

| Autho | | | -- | | | Date | 2021-02-19 | | Email | | In order to improve the function of iSulad, it is necessary to support the Native network. Usually, testing and development scenarios basically start containers through the client. Therefore, this article details iSulad's Native network design. The CRI interface implements the container network capability flexibly and extensibly by encapsulating the CNI. So, can the native network of isulad also be implemented based on the capabilities of CNI? certainly! This design idea has many advantages: High flexibility and scalability; Relying on open source network plug-ins, greatly reducing the workload; Minimal impact on current iSulad architecture; In line with current industry standards, it can better expand the ecology of iSulad; We divide the network design of iSulad into four modules: network api module: provides the API interface of the entire network component, provides network capabilities for the container (the ability to create, delete the network, join the container, exit the network, etc.), and determine the network type through the `type` parameter. Adaptor module: provides different network type implementations. Currently, it supports two network types: `CRI` and `native`, which correspond to the network implementation of the CRI interface and the local network capabilities of the client respectively. cni-operator module: encapsulates the libcni module, provides a more reasonable and friendly network management interface for the upper layer, and is responsible for the combined adaptation of user configuration and network configuration; libcni module: Based on the existing clibcni self-developed project, it is upgraded and adapted to the latest cni 0.4.0 version, and provides new mechanisms and functions such as check and cache; The overall structure is as follows: ```mermaid flowchart TD classDef impStyle fill:#c19,stroke:#686,stroke-width:2px,color:#fff; classDef apiStyle stroke:#216,stroke-width:2px,stroke-dasharray: 5 5; subgraph networkAPI B(attach network) C(detach network) D(config create) E(config remove) F(config ls) G(config inspect) H(init) end networkAPI:::apiStyle subgraph CRI-adaptor XA[detach network] XB[attach network] XC[......] end CRI-adaptor:::impStyle subgraph Native-adaptor YA[detach network] YB[attach network] YC[config apis...] end subgraph config-apis ADA[create] ADB[remove] ADC[ls] ADD[inspect] end config-apis:::apiStyle subgraph bridge-driver BDA[bridge create] BDB[bridge remove] BDC[bridge ls] BDD[bridge inspect] end subgraph other-drivers ODA[implement driver] end YC --> config-apis config-apis --> bridge-driver config-apis --> other-drivers Native-adaptor:::impStyle subgraph cni-operator J[attach network] K[detach network] end subgraph libcni M[AddNetworkList] N[CheckNetworkList] O[DelNetworkList] end networkAPI --> CRI-adaptor networkAPI --> Native-adaptor CRI-adaptor --> cni-operator Native-adaptor --> cni-operator cni-operator --> libcni OA[CRI pod lifecycle] --> |call| networkAPI OB[Container lifecycle] --> |call| networkAPI ``` The sequence diagram is as follows: ```mermaid sequenceDiagram participant adaptor participant configsDatabase participant cniManager adaptor ->> configsDatabase: cniManager ->> configsDatabase: adaptor ->> cniManager: API ``` ```bash src/daemon/modules/api/network_api.h src/daemon/modules/network/ CMakeLists.txt cni_operator CMakeLists.txt cni_operate.c cni_operate.h libcni CMakeLists.txt invoke CMakeLists.txt libcni_errno.c libcni_errno.h libcni_exec.c libcni_exec.h libcniresultparse.c libcniresultparse.h libcni_api.c libcni_api.h libcni_cached.c libcni_cached.h libcni_conf.c libcni_conf.h libcniresulttype.c libcniresulttype.h cri adaptor_cri.c adaptor_cri.h CMakeLists.txt native adaptor_native.c adaptor_native.h CMakeLists.txt network.c

```` ````c // support network type struct attachnetconf { char *name; char *interface; }; typedef struct networkapiconf_t { char *name; char *ns; char *pod_id; char *netns_path; char *default_interface; // attach network panes config struct { struct attachnetconf extral_nets; sizet extralnets_len; }; // external args; jsonmapstring_string *args; // extention configs: map<string, string> map_t *annotations; } networkapiconf; struct networkapiresult { char *name; char *interface; char ips; sizet ipslen; char *mac; }; typedef struct networkapiresultlistt { struct networkapiresult items; size_t len; size_t cap; } networkapiresult_list; ```` Support up to 1024 CNI profiles; Supports two network types: `native` and `cri`; Interface input parameter type: `networkapiconf`; Network operation result types: `networkapiresultlist` and `networkapi_result`; ````c // 1. Network module initialization interface; bool networkmoduleinit(const char network_plugin, const char cachedir, const char *confdir, const char* bin_path); // 2. The container is connected to the network plane interface; int networkmoduleattach(const networkapiconf conf, const char type, networkapiresult_list result); // 3. Network check operation, which can be used to obtain the network configuration information of the container; int networkmodulecheck(const networkapiconf conf, const char type, networkapiresult_list result); // 4. The container exits the interface from the network plane; int networkmoduledetach(const networkapiconf conf, const char type); // 5. Network configuration generation interface; int networkmoduleconfcreate(const char *type, const networkcreate_request *request, networkcreateresponse response); // 6. Network configuration view interface; int networkmoduleconfinspect(const char *type, const char *name, char **networkjson); // 7. List interfaces for network profiles; int networkmoduleconflist(const char *type, const struct filtersargs filters, network_network_info networks, sizet *networkslen); // 8. Network configuration file delete interface; int networkmoduleconfrm(const char *type, const char *name, char **resname); // 9. Interface to check if the network module is ready; bool networkmoduleready(const char *type); // 10. Network module configuration update interface; int networkmoduleupdate(const char *type); // 11. Interface for resource cleanup when network module exits; void networkmoduleexit(); // 12. Set the portmapping settings of annotations; int networkmoduleinsertportmapping(const char *val, networkapi_conf *conf); // 13. Set the bandwidth setting of annotations; int networkmoduleinsertbandwidth(const char *val, networkapi_conf *conf); // 14. Set the iprange setting of annotations; int networkmoduleinsertiprange(const char *val, networkapi_conf *conf); // 15. Check whether the network module network exists or not; int networkmoduleexist(const char type, const char name); ```` Provides the upper layer with the basic capabilities of CNI, and completes functions such as building, deleting, and checking the CNI network according to the incoming CNI network configuration information. The current libcni module has provided the capability of the `v0.3.0` version, it needs to be upgraded to `v0.4.0` after iteration, and `v0.4.0` needs to support the `check` and `cache` mechanisms. The part marked by the red part in the figure below. ```mermaid graph TD classDef unFinish fill:#c19,stroke:#216,stroke-width:2px,color:#fff,stroke-dasharray: 5 5; O(libcni) --> X O(libcni) --> Y subgraph test X[exec] X --> A(AddNetworkList) X --> B(CheckNetworkList) X --> C(DelNetworkList) X --> F(ValidateNetworkList) end subgraph cache Y[cache] Y --> D(GetNetworkListCachedResult) Y --> E(GetNetworkListCachedConfig) end A --> G[executor] B --> G[executor] C --> G[executor] F --> G[executor] G --> H(cni plugin) D --> P[cache API] E --> P[cache API] P --> R[addCache] P --> S[deleteCache] B:::unFinish F:::unFinish cache:::unFinish ``` You can see how the CRI adapter modules are designed in . You can see how the native network adapter modules are designed in . You can see how the cni operator modules are designed in .