CN111273960A - Method for realizing cloud native MIPS architecture container cloud - Google Patents
Method for realizing cloud native MIPS architecture container cloud Download PDFInfo
- Publication number
- CN111273960A CN111273960A CN202010064788.8A CN202010064788A CN111273960A CN 111273960 A CN111273960 A CN 111273960A CN 202010064788 A CN202010064788 A CN 202010064788A CN 111273960 A CN111273960 A CN 111273960A
- Authority
- CN
- China
- Prior art keywords
- mips
- kubernets
- images
- test
- image
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 238000012360 testing method Methods 0.000 claims abstract description 86
- 230000001419 dependent effect Effects 0.000 claims description 7
- 238000010276 construction Methods 0.000 claims description 6
- 238000005516 engineering process Methods 0.000 claims description 5
- 238000004519 manufacturing process Methods 0.000 claims description 5
- 238000009826 distribution Methods 0.000 claims description 4
- 241000322338 Loeseliastrum Species 0.000 claims description 3
- 238000003860 storage Methods 0.000 description 4
- 230000006978 adaptation Effects 0.000 description 3
- 244000035744 Hura crepitans Species 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000004807 localization Effects 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a method for realizing a cloud native MIPS framework container cloud, which belongs to the technical field of cloud computing, and comprises the steps of constructing a Kubernets component and an E2E test mirror image of an MIPS framework, constructing a Kubernets cluster of the MIPS framework and passing through consistency certification of the Kubernets of the MIPS framework, and specifically comprises the steps of constructing a K8S-MIPS component, constructing a K8S-MIPS cluster, constructing a K8S-E2E test mirror image and passing through K8S consistency certification. The invention can provide stable and reliable MIPS architecture cloud native container cloud, and provide a domestic cloud native application support scheme for users.
Description
Technical Field
The invention relates to the technical field of cloud computing, in particular to a method for realizing a cloud native MIPS architecture container cloud.
Background
The MIPS (microprocessor with out Interlocked Pipelined architectures) architecture, which is a processor architecture adopting a reduced instruction set, appeared in 1981, was developed and authorized by MIPS technologies corporation, and is widely used in many electronic products, network devices, personal entertainment devices, and business devices.
Kubernetes is an open source container arrangement system with excellent design concept and active community. The kubernets authority has supported a variety of CPU architectures including X86, ARM/ARM64, PPC64LE, S390X, etc., but has never supported the MIPS architecture, which is always unfortunate.
In china, some home-made chips are designed based on MIPS architecture, such as loongson, and servers run based on loongson chips, and application services on the servers have very urgent needs to use cloud native capability.
Disclosure of Invention
The technical task of the invention is to provide a method for realizing the cloud native MIPS architecture container cloud aiming at the defects, which can provide a stable and reliable MIPS architecture cloud native container cloud and provide a domestic cloud native application support scheme for users.
The technical scheme adopted by the invention for solving the technical problems is as follows:
a method for realizing a cloud native MIPS framework container cloud comprises the steps of constructing a Kubernets component and an E2E test mirror image of an MIPS framework, constructing a Kubernets cluster of the MIPS framework and passing consistency certification of the Kubernets of the MIPS framework, so that stable and reliable MIPS framework cloud native container cloud is provided, a domestic cloud native application support scheme is provided for a user, and the method specifically comprises the four steps of constructing a K8S-MIPS component, constructing a K8S-MIPS cluster, constructing a K8S-E2E test mirror image and passing K8S consistency certification. K8S, kubernets, container orchestration management component.
In particular, for constructing the K8S-MIPS component, substantially all kubernets-related cloud native components do not provide MIPS version installation packages or images, and the premise of deploying kubernets on a MIPS platform is to build all required components by self-compilation,
the method comprises the steps of deploying components required by Kubernetes compiling on an MIPS platform, wherein the components comprise golang, docker-ce, hyperkube, pause, etcd, calico, coredns and metrics-server, compiling the latest and stable golang on a MIPS64el platform, and compiling most of the components in a source code construction mode.
golang: a static strongly typed, compiled language developed by Google;
docker-ce: an open source application container engine;
hyperkube: kubernets run components;
pause: running a mirror image of the sandbox container;
etcd: a distributed kv storage component;
a calco: a pure three-layer network component;
coredns: a plug-in DNS server;
metrics-server: the Kubernetes cluster core monitors the aggregator of data.
Preferably, a K8S-MIPS component is constructed by using a cross-compiling technology, a cross-compiling basic mirror image for constructing the MIPS framework is manufactured, the mirror image is integrated with a qemu (virtual machine simulator) tool and is used for translating CPU instructions of the MIPS, and the MIPS framework hyperkube and E2E test mirror image are cross-compiled by modifying a construction script of Kubernets and an E2E mirror image manufacturing script of Kubernets.
Further, after the required components are built, the building of kubernets cluster is completed using tools including kubes pray and kubes dm.
In particular, the K8S-MIPS cluster component distribution comprises a master node and a slave node,
the master node comprises Kube-apiServer-mips, Kube-schedule-mips, Kube-controller-manager-mips, Kube-proxy-mips, Kubel-let-mips, Etcd-mips, Coredns-mips, mouse-mips, Calico-mips, Metrics-server-mips, Docker-mips and Kubeamm-mips;
the slave nodes include Kube-proxy-mips, Kubelet-mips, Calico-mips, Pause-mips, Docker-mips, and Kubeadm-mips.
Kube-apiserver: kubernets's api server
Kube-scheduler: scheduler for kubernets
Kube-controller-manager: control manager of kubernets
Kube-proxy: agent of kubernets
Kubelet: container manager for kubernets
Preferably, running the end-to-end test case of Kubernetes to verify the K8S-MIPS cluster stability, first construct all the mirrors needed for the test.
The simplest and straightforward way to verify K8S-MIPS cluster stability and availability is to run an end-to-end (E2E) test case of Kubernets. The E2E test of K8S provides a series of test cases based on the BDD (Behavior-drive Development) paradigm. The E2E test was performed according to the official test guidelines of the Kubernetes open source community.
When we perform the E2E test, the test program will start many Pod to perform various end-to-end behavior tests, the source code of the image used by these Pod is mostly from the kubernets/tests/images directory, during the test, we will go to gcr.io/kubernets-E2E-test-images/warehouse to pull the already constructed image, the image of MIPS architecture does not exist in the gcr.io/kubernets-E2E-test-images/images warehouse, and we must first construct all the images required by the test to run the E2E test.
Further, the mirror image required by the test is built, all the mirror images required by the test are listed,
for a part of test images of which the image source codes are positioned under kubernets/tests/images/catalogs, compiling by using golang, compiling a binary file, and manufacturing an image based on a corresponding Dockerfile (image construction file);
for a test image with the image source code not under kubernets/tests/images/catalogs, finding the original image source code and making an image of the original image source code and a base image directly or indirectly dependent on the original image source code.
Most mirror source codes are located under kubernets/test/images/directories. Although the kubernets authority has already completed Makefile (component build file) and shell-script (execute script) and provided commands for building test images, there are still many architecture related problems that have not been solved, such as the problem of qemu cross-compilation, the problem of base images and dependency package incompatibility, so we are temporarily unable to automatically build images of mips64el architecture directly by executing these commands. Most test images are written using golang, then binary files are compiled, and images are created based on corresponding dockerfiles (image build files).
Some of the source codes that need to be mirrored for testing are not under kubernets/tests/images, such as gcr. io/google-samples/gb-front: v6, etc., and the original mirror source codes are found in the repository of githu. com/google Cloudpastform/kubernets-genes-samples. But we need to make these images, as well as the base images on which it depends, and the base images of the base images, such as php:5-apache, redis, perl, etc.
Php: universal open source scripting language
Apache: web server software
Redis: open-source key-value storage system
Perl: computer program language with rich functions
Preferably, all images required for the test are listed by the sonobuoy images-p e2e command. sonobuoy: end-to-end test case execution tool for kubernets
Preferably, the partial test image with the mirror source code under the kubernets/test/images/catalog is replaced by mips64el base image.
The default basic mirror image used by the test mirror image is mainly Alpine (a security-oriented light Linux release), the mips64el architecture is not supported by the Alpine officer at present, and when the Alpine basic mirror image of the mips64el version is not manufactured, the basic mirror image can only be replaced by the existing mips64el basic mirror image, such as debian-stretch, fedora, ubuntu and the like. Replacing the base image also requires replacing the commands that install the dependent packages, even the versions of the dependent packages, etc.
Debian: operating system and free software release
Fedora: rapid, stable and powerful operating system for daily application and constructed by global community enthusiasts
Ubuntu: linux operating system mainly based on desktop application
Further, all images are prepared within the cluster, imagePullPolicy for all Pod (container group) within the test case is set to ifNotPresent, and then the E2E test is performed.
Compared with the prior art, the method for realizing the cloud native MIPS framework container cloud has the following beneficial effects:
according to the method, Kubernets are adapted to the MIPS framework platform, migration adaptation of the Kubernets and related components is completed, a stable and high-availability MIPS cluster is built, meanwhile, consistency testing of the Kubernets is completed, cloud native capability is provided for localization service application, and a localization process of cloud native application is powerfully promoted.
Drawings
Fig. 1 is a technical architecture diagram of a MIPS architecture container cloud implementing cloud-native of the present invention;
FIG. 2 is a K8S-MIPS cluster component schematic layout;
FIG. 3 is an example of a CPU architecture for a K8S-MIPS cluster;
FIG. 4 is an example of cluster node information for a K8S-MIPS cluster;
FIG. 5 is a K8S-MIPS cluster management example;
fig. 6 is a K8S consistent authentication example.
Detailed Description
The invention is further described with reference to the following figures and specific examples.
For many years, in order to enrich the ecology of the Kubernetes open source community, the Kubernetes are continuously tried to be adapted to the MIPS architecture platform, and with the continuous iterative optimization and performance improvement of the Loongson CPU, the Kubernetes-MIPS 64el platform continuously makes some breakthrough progress. At present, the Kubernets and the migration adaptation of related components are successfully completed, a stable and high-availability MIPS cluster is built, and meanwhile, the consistency test of Kubernets-v1.16.2 is completed.
A method for realizing cloud native MIPS framework container cloud is characterized in that a Kubernets component and an E2E test mirror image of an MIPS framework are built, a Kubernets cluster of the MIPS framework is built, and consistency authentication of the Kubernets of the MIPS framework is achieved, so that stable and reliable MIPS framework cloud native container cloud is provided, and a domestic cloud native application support scheme is provided for a user.
The method specifically comprises four steps of constructing a K8S-MIPS component, constructing a K8S-MIPS cluster, constructing a K8S-E2E test image and passing K8S consistency certification.
K8S, kubernets, container orchestration management component.
Constructing a K8S-MIPS component:
essentially all kubernets-related cloud native components do not provide MIPS version installation packages or images, and the premise to deploy kubernets on MIPS platforms is to build all required components by self-compilation, which mainly include golang, docker-ce, hyperkube, pause, etcd, calico, coredns, and metrics-server.
Note:
golang: a static strongly typed, compiled language developed by Google;
docker-ce: an open source application container engine;
hyperkube: kubernets run components;
pause: running a mirror image of the sandbox container;
etcd: a distributed kv storage component;
a calco: a pure three-layer network component;
coredns: a plug-in DNS server;
metrics-server: the Kubernetes cluster core monitors the aggregator of data.
Thanks to the excellent design of Golang and good support for MIPS platform, the compilation process of the above cloud-native components is greatly simplified. First, we compiled the latest stable golang on mips64el platform, and then compiled by means of source code construction to complete most of the above components.
In the compiling process, a plurality of platform compatibility problems are inevitably encountered, such as compatibility problems related to golang system call (syscall), and the like, and are finally and successfully solved through the efforts of research and development personnel, and some adaptation results also contribute to an open source community by submitting batch and the like.
The K8S-MIPS component is constructed by mainly using a cross-compiling technology, and an input-cross-compiled basic mirror (inpur-cross-built) for constructing the MIPS framework is manufactured, and the mirror is integrated with a qemu (virtual machine simulator) tool and used for translating CPU instructions of the MIPS. By modifying a construction script of Kubernetes and an E2E mirror image production script of Kubernetes, hyperkube and E2E test mirror images of the MIPS framework are cross-compiled.
After successfully building the above components, we use tools to complete building of kubernets clusters, such as kubes pray, kubeudm, etc.
The K8S-MIPS components list is as follows:
note: CKE: wave push is a Kubernetes-based container cloud service engine.
K8S-MIPS cluster component distribution:
as shown in fig. 2, the K8S-MIPS cluster component distribution includes a master node and a slave node,
the master node comprises Kube-apiServer-mips, Kube-schedule-mips, Kube-controller-manager-mips, Kube-proxy-mips, Kubel-let-mips, Etcd-mips, Coredns-mips, mouse-mips, Calico-mips, Metrics-server-mips, Docker-mips and Kubeamm-mips;
the slave nodes include Kube-proxy-mips, Kubelet-mips, Calico-mips, Pause-mips, Docker-mips, and Kubeadm-mips.
Note:
kube-apiserver: an api server of kubernets;
kube-scheduler: a scheduler of kubernets;
kube-controller-manager: a control manager of kubernets;
kube-proxy: a proxy for kubernets;
kubelet: a container manager of kubernets.
K8S-E2E test case:
running an end-to-end test case of Kubernetes to verify the stability of the K8S-MIPS cluster, firstly constructing all mirror images required by the test.
The simplest and straightforward way to verify K8S-MIPS cluster stability and availability is to run an end-to-end (E2E) test case of Kubernets.
The E2E test of K8S provides a series of test cases based on the BDD (Behavior-DrivenDevelop) paradigm. The E2E test was performed according to the official test guidelines of the Kubernetes open source community.
When we perform the E2E test, the test program will start many Pod to perform various end-to-end behavior tests, the source code of the image used by these Pod is mostly from the kubernets/tests/images directory, during the test, we will go to gcr.io/kubernets-E2E-test-images/warehouse to pull the already constructed image, the image of MIPS architecture does not exist in the gcr.io/kubernets-E2E-test-images/images warehouse, and we must first construct all the images required by the test to run the E2E test.
Constructing a mirror image required by testing:
all the mirror images required for the test are listed,
all images required for the test are listed by the sonobuoy images-p e2e command.
Most mirror source codes are located under kubernets/test/images/directories. Although the kubernets authority has already completed Makefile (component build file) and shell-script (execute script) and provided commands for building test images, there are still many architecture related problems that have not been solved, such as the problem of qemu cross-compilation, the problem of base images and dependency package incompatibility, so we are temporarily unable to automatically build images of mips64el architecture directly by executing these commands.
Most test images are written using golang, then binary files are compiled, and images are created based on corresponding dockerfiles (image build files). These mirror images can be easily made for us. But one point needs to be noted: the default basic mirror image used by the test mirror image is mainly Alpine (a security-oriented light Linux release), the mips64el architecture is not supported by Alpine officials at present, the Alpine basic mirror image of the mips64el version cannot be made by the officials for the moment, and only the basic mirror image can be replaced by the existing mips64el basic mirror image, such as debian-stretch, fedora, ubuntu and the like. Replacing the base image also requires replacing the commands that install the dependent packages, even the versions of the dependent packages, etc.
Some of the source codes of the images required for the tests are not under kubernets/tests/images, such as gc. io/google-samples/gb-front: v6, etc., there is no explicit document describing where such images come from, and we found the original source codes of the images in the warehouse of githu. com/google cloud platform/kubernets-images-samples. But are blocked by the base mirror images on which the mirror images depend, we need to make the mirror images, and also need to make the base mirror images on which the mirror images depend, and the base mirror images of the base mirror images, such as php:5-apache, redis, perl, and the like.
After lengthy and cumbersome image reproduction, we have completed the production of a total of about 50 images, including test images and directly and indirectly dependent base images.
Finally we prepare all the images properly within the cluster and ensure that the imagePullPolicy of all the Pod within the test case is set to ifNotPresent before the E2E test can be successfully performed.
Note:
sonobuoy: an end-to-end test case execution tool for kubernets;
debian: an operating system and release of free software;
fedora: a fast, stable and powerful operating system for daily application constructed by global community enthusiasts;
ubuntu: a Linux operating system mainly based on desktop application;
php: a universal open source scripting language;
apache: a Web server software;
redis: an open source key-value storage system;
perl: a computer programming language with rich functions;
pod: container set
K8S-E2E test mirror:
we have made at least 32 test images of E2E, including:
K8S consistency authentication:
./sonobuoy run--image-pull-policy＝IfNotPresent
the description of the screenshot of the page,
K8S-MIPS Cluster:
the CPU architecture is shown in FIG. 3;
the cluster node information is shown in fig. 4;
the K8S-MIPS cluster management page is shown in FIG. 5;
the K8S consistency authentication page is shown in fig. 6.
The present invention can be easily implemented by those skilled in the art from the above detailed description. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the basis of the disclosed embodiments, a person skilled in the art can combine different technical features at will, thereby implementing different technical solutions.
In addition to the technical features described in the specification, the technology is known to those skilled in the art.
Claims (10)
1. A method for realizing a cloud native MIPS framework container cloud is characterized in that a Kubernets component and an E2E test mirror image of an MIPS framework are built, a Kubernets cluster of the MIPS framework is built, consistency authentication of the Kubernets of the MIPS framework is achieved, and the method specifically comprises the four steps of building a K8S-MIPS component, building a K8S-MIPS cluster, building a K8S-E2E test mirror image and achieving the consistency authentication of the K8S.
2. The method of claim 1, wherein Kubernets compile required components including golang, docker-ce, hyperkube, pause, etcd, calico, coredns and metrics-server are deployed on a MIPS platform, stable golang is compiled on a MIPS64el platform, and then the above components are compiled by means of source code construction.
3. The method of claim 1 or 2, wherein a cross-compilation technology is used to construct K8S-MIPS components, and a cross-compilation base image for constructing MIPS architecture is created, wherein the image integrates qemu tools for translating CPU instructions of MIPS, and cross-compiles MIPS architecture hyperkube and E2E test images.
4. The method of claim 3, in which building a Kubernets cluster is done using tools including kubes pray and kubeeadm after building required components.
5. The method of claim 1, in which a K8S-MIPS cluster component distribution includes a master node and a slave node,
the master node comprises Kube-apiServer-mips, Kube-schedule-mips, Kube-controller-manager-mips, Kube-proxy-mips, Kubel-let-mips, Etcd-mips, Coredns-mips, mouse-mips, Calico-mips, Metrics-server-mips, Docker-mips and Kubeamm-mips;
the slave nodes include Kube-proxy-mips, Kubelet-mips, Calico-mips, Pause-mips, Docker-mips, and Kubeadm-mips.
6. The method for realizing the cloud native MIPS architecture container cloud of claim 1 or 5, characterized in that running the Kubernets end-to-end test case to verify K8S-MIPS cluster stability, first constructing all the mirror images required for the test.
7. The method of claim 6, in which the constructing of the mirror images required for testing, listing all mirror images required for testing,
for a part of test images of which the image source codes are positioned under kubernets/tests/images/catalogs, compiling by using golang, compiling a binary file, and manufacturing the images based on the corresponding Dockerfiles;
for a test image with the image source code not under kubernets/tests/images/catalogs, finding the original image source code and making an image of the original image source code and a base image directly or indirectly dependent on the original image source code.
8. The method of implementing a cloud-native MIPS architecture container cloud of claim 7, wherein all images required for testing are listed by the sonobuoy images-p e2e command.
9. The method of claim 7, in which the base image of the partial test image whose source code is under kubernets/tests/images/catalog is replaced with MIPS64el base image.
10. The method of claim 7, in which all images are prepared within a cluster, and imagePullPolicy for all Pod within a test case is set to ifNotPresent, and then an E2E test is performed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010064788.8A CN111273960A (en) | 2020-01-20 | 2020-01-20 | Method for realizing cloud native MIPS architecture container cloud |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010064788.8A CN111273960A (en) | 2020-01-20 | 2020-01-20 | Method for realizing cloud native MIPS architecture container cloud |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111273960A true CN111273960A (en) | 2020-06-12 |
Family
ID=70999003
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010064788.8A Pending CN111273960A (en) | 2020-01-20 | 2020-01-20 | Method for realizing cloud native MIPS architecture container cloud |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111273960A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112685323A (en) * | 2021-01-21 | 2021-04-20 | 浪潮云信息技术股份公司 | Method for realizing self-defined end-to-end test case compiling |
| CN114157654A (en) * | 2021-10-28 | 2022-03-08 | 杭州未名信科科技有限公司 | Integrated circuit collaborative design system and method |
| CN114924810A (en) * | 2021-05-14 | 2022-08-19 | 武汉深之度科技有限公司 | Heterogeneous program execution method and device, computing device and readable storage medium |
| CN117648198A (en) * | 2024-01-30 | 2024-03-05 | 北京比格大数据有限公司 | Application adaptation method, device, equipment and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106888254A (en) * | 2017-01-20 | 2017-06-23 | 华南理工大学 | A kind of exchange method between container cloud framework based on Kubernetes and its each module |
| CN109981351A (en) * | 2019-03-06 | 2019-07-05 | 浪潮通用软件有限公司 | A kind of private clound dispositions method |
| CN110704164A (en) * | 2019-09-30 | 2020-01-17 | 珠海市新德汇信息技术有限公司 | Cloud native application platform construction method based on Kubernetes technology |
-
2020
- 2020-01-20 CN CN202010064788.8A patent/CN111273960A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106888254A (en) * | 2017-01-20 | 2017-06-23 | 华南理工大学 | A kind of exchange method between container cloud framework based on Kubernetes and its each module |
| CN109981351A (en) * | 2019-03-06 | 2019-07-05 | 浪潮通用软件有限公司 | A kind of private clound dispositions method |
| CN110704164A (en) * | 2019-09-30 | 2020-01-17 | 珠海市新德汇信息技术有限公司 | Cloud native application platform construction method based on Kubernetes technology |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112685323A (en) * | 2021-01-21 | 2021-04-20 | 浪潮云信息技术股份公司 | Method for realizing self-defined end-to-end test case compiling |
| CN114924810A (en) * | 2021-05-14 | 2022-08-19 | 武汉深之度科技有限公司 | Heterogeneous program execution method and device, computing device and readable storage medium |
| CN114924810B (en) * | 2021-05-14 | 2024-02-23 | 武汉深之度科技有限公司 | Heterogeneous program execution method, heterogeneous program execution device, computing equipment and readable storage medium |
| CN114157654A (en) * | 2021-10-28 | 2022-03-08 | 杭州未名信科科技有限公司 | Integrated circuit collaborative design system and method |
| CN114157654B (en) * | 2021-10-28 | 2024-03-19 | 杭州未名信科科技有限公司 | Integrated circuit collaborative design system and method |
| CN117648198A (en) * | 2024-01-30 | 2024-03-05 | 北京比格大数据有限公司 | Application adaptation method, device, equipment and storage medium |
| CN117648198B (en) * | 2024-01-30 | 2024-05-10 | 北京比格大数据有限公司 | Application adaptation method, device, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Burns et al. | Kubernetes: up and running | |
| CN111273960A (en) | Method for realizing cloud native MIPS architecture container cloud | |
| EP2726976B1 (en) | Virtual machine migration tool | |
| US8799893B2 (en) | Method, system and computer program product for solution replication | |
| US11561784B2 (en) | Versioning of pipeline templates for continuous delivery of services on datacenters configured in cloud platforms | |
| US11385883B2 (en) | Methods and systems that carry out live migration of multi-node applications | |
| CN108089888B (en) | It is a kind of that operation method and system are applied based on file system | |
| US20100058331A1 (en) | Automated deployment of defined topology in distributed computing environment | |
| US10901804B2 (en) | Apparatus and method to select services for executing a user program based on a code pattern included therein | |
| CN103123605B (en) | A kind of Android platform automatic integration test method and device | |
| US11392366B1 (en) | Optimized compilation of pipelines for continuous delivery of services on datacenters configured in cloud platforms | |
| CN108089890B (en) | It is a kind of that operation method and system are applied based on disk | |
| US20190340057A1 (en) | Methods and systems to compound alerts in a distributed computing system | |
| CN105138765A (en) | Large-scale computational experiment method based on Docker of artificial transportation system | |
| Strijkers et al. | Toward Executable Scientific Publications. | |
| CN116783581A (en) | Deploying software release on a data center configured in a cloud platform | |
| Meng et al. | Umbrella: A portable environment creator for reproducible computing on clusters, clouds, and grids | |
| KR20140113685A (en) | Installation engine and package format for parallelizable, reliable installations | |
| CN109753302B (en) | Service method without service function based on hybrid cloud computing platform | |
| Bhardwaj et al. | Serving mobile apps: A slice at a time | |
| CN101840337B (en) | Method for customizing reducing system applied to packet capture application | |
| Thomas et al. | Simulation factory: Taming application configuration and workflow on high-end resources | |
| Pan et al. | Design and Implementation of Server Management System Based on Docker | |
| CN115794253A (en) | Application integration method and device, electronic equipment and computer readable storage medium | |
| Buelta | Hands-On Docker for Microservices with Python: Design, deploy, and operate a complex system with multiple microservices using Docker and Kubernetes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200612 |