CN112073449B

CN112073449B - Kubernetes-based environment switching processing method and equipment

Info

Publication number: CN112073449B
Application number: CN201910500775.8A
Authority: CN
Inventors: 陈登月
Original assignee: eBaoTech Corp
Current assignee: eBaoTech Corp
Priority date: 2019-06-11
Filing date: 2019-06-11
Publication date: 2023-04-18
Anticipated expiration: 2039-06-11
Also published as: CN112073449A

Abstract

The embodiment of the invention provides an environment switching processing method based on Kubernetes, which comprises the following steps: creating a proxy service configured to expose a port to a plurality of Kubernets internal services through a first port exposure manner; in a production environment, closing the proxy service, and externally exposing a plurality of Kubernets internal services through a second port exposure mode; in a development environment, the proxy service is opened, kubernets internal services are exposed to the outside through a second port exposure mode, and ports are exposed to a plurality of Kubernets internal services through the proxy service according to the first port exposure mode. According to the invention, the service configuration file can be decoupled from the environment information, so that the same set of service configuration file can be conveniently used for deployment and management in a production environment and a development environment.

Description

Kubernetes-based environment switching processing method and equipment

Technical Field

The invention relates to the field of computer networks, in particular to an environment switching processing method and device based on Kubernetes.

Background

In the kubernets system, also called the K8S system, different port exposure schemes are adopted for the production environment and the development environment, respectively. The configuration file of the kubernets internal service is modified by a tool, in a development environment, a first port exposure scheme is adopted, and in a production environment, the first port exposure scheme is forbidden, and a second port exposure scheme is adopted. The problems arising from the use of the above-described solutions include: the configuration file modification tool itself needs to be developed and maintained, and the port exposure information of each Kubernetes internal service is distributed in the configuration file of each internal service itself, which causes inconvenience in configuration management of the service.

Disclosure of Invention

In order to solve the above problems, embodiments of the present invention provide an environment switching processing method based on Kubernetes, where an agent service is additionally provided, the agent service is used to expose a nodecort port to an internal service of the Kubernetes, the agent service is switched on and off, so that the Kubernetes service in a development environment and a test environment can use a same set of configuration files, and all services are exposed in an ingress manner.

In a first aspect, an embodiment of the present invention provides an environment switching processing method based on kubernets, where the method includes: creating a proxy service configured to expose a port to a plurality of Kubernets internal services through a first port exposure manner; in a production environment, closing the proxy service, and externally exposing a plurality of Kubernets internal services through a second port exposure mode; in a development environment, the proxy service is opened, kubernets internal services are exposed to the outside through a second port exposure mode, and ports are exposed to a plurality of Kubernets internal services through the proxy service according to the first port exposure mode.

In some embodiments of the present invention, the first mode is a notport mode, and the second mode is an Ingress mode.

In some embodiments of the present invention, the configuration file of the proxy service configures a mapping relationship between a Nodeport port and a Kubernetes internal service.

In some embodiments of the present invention, the Ingress manner is to bind a plurality of kubernets internal services with one fixed port, and forward the access request to the plurality of kubernets internal services according to a predetermined forwarding rule.

In some embodiments of the invention, exposing the port to a plurality of kubernets internal services according to the first port exposure comprises: and carrying out one-to-one mapping binding on the port and the Kubernets internal service according to the configuration file of the proxy service.

In some embodiments of the invention, the configuration file for each of the plurality of kubernets internal services is the same in the production environment and the development environment.

In some embodiments of the invention, the proxy service is a hypertext transfer protocol, HTTP, service.

In some embodiments of the invention, the proxy service determines the internal service acted by the label selector.

In a second aspect, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores computer instructions, and the processor is configured to execute the computer instructions to cause the computer device to perform the method of the first aspect.

In a third aspect, an embodiment of the present invention further provides a computer-readable storage medium, on which computer instructions are stored, and when executed by a processor, the computer instructions implement the method of the first aspect.

Drawings

Fig. 1 shows a Kubernetes-based context switch processing method according to an embodiment of the present invention.

FIG. 2 illustrates a port exposure schematic for a Kubernetes-based production environment, according to an embodiment of the invention.

FIG. 3 illustrates a port exposure diagram for a Kubernets-based development environment, according to an embodiment of the present invention.

Fig. 4 shows a Kubernetes-based protocol conversion processing method according to an embodiment of the present invention.

Fig. 5 shows a schematic diagram of a kubernets request forwarding process.

Fig. 6 shows a schematic diagram of request forwarding processing according to an embodiment of the present invention.

Fig. 7 shows a schematic structural diagram of a computer device according to an embodiment of the present invention.

Detailed Description

The invention will now be described in detail with reference to exemplary embodiments thereof, some of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which like numerals represent the same or similar elements throughout the different views unless otherwise specified. The aspects described in the following exemplary embodiments do not represent all aspects of the present invention. Rather, these aspects are merely examples of systems and methods according to various aspects of the present invention as recited in the appended claims.

In the embodiment of the invention, the Kubernetes system can be a cluster-type system, and machines in a cluster can be divided into a Master Node and a group of working nodes (nodes). The Master node runs a group of processes etcd, API Server, controller Manager and Scheduler related to cluster management, the last three components API Server, controller Manager and Scheduler form a general control center of Kubernet, and the processes realize the management functions of resource management, pod scheduling, elastic expansion, safety control, system monitoring, error correction and the like of the whole cluster.

RC (Replication Controller) for definition of target Pod; the number of copies that the target Pod needs to run; target Pod tag (Label) to be monitored; kubernets screen the corresponding Pod instances through Lable defined in RC, monitors the state and the number of the Pod instances in real time, if the number of the instances is less than the defined copy number (Replicas), creates a new Pod according to the Pod template defined in the RC, and then dispatches the Pod to a proper Node to start running until the number of the Pod instances reaches a preset target.

The procedure in Kubernetes is as follows: submitting a request for creating an RC through Kubectl, the request being written into etcd through API Server, at this time, controller Manager monitors RC event through interface of API Server monitoring resource change, after analysis, it finds that there is no Pod instance corresponding to it in current cluster, then generates a Pod object according to Pod template definition in RC, writes into etcd through API Server, then, the event is found by Scheduler, it immediately executes a complex scheduling flow, selects a Node of drop for this new Pod, then writes this result into etcd through API Server, then Kubel process running on target Node monitors this 'newly-generated' Pod through API Server, and starts up this Pod according to its definition to provide service for Pod until the life of Pod is over.

Subsequently, a new Service creation request mapped to the Pod is submitted through Kubectl, a Controller Manager queries the associated Pod instance through a Label tag, generates the endpoint information of the Service, writes the endpoint information into etcd through an API Server, and then, the Proxy processes running on all nodes query and monitor the Service object and the endpoint information corresponding to the Service object through the API Server, and establishes a load balancer in a software mode to realize the flow forwarding function of the Service access to the backend Pod.

In the embodiment of the invention, the etcd in the Kubernetes framework is used for persistently storing all resource objects in the cluster, such as Node, service, pod, RC, namespace and the like; the API Server provides the encapsulation interface API for the operation etcd, and the API is basically an interface for the adding, deleting, modifying, checking and monitoring the resource change of the resource object in the cluster.

In the embodiment of the present invention, in a kubernets framework, application containers in one Pod share the same set of resources, including: assigning an IP address to each Pod, using the Pod name as the host name for inter-container communication, etc., in the kubernets system, although each Pod is assigned a separate IP address, this IP address disappears as the Pod is destroyed; PID namespace: different applications in the Pod can see the process IDs of other applications; network name space: multiple containers in a Pod can access the same IP and port range; IPC namespace: the containers in the Pod can communicate using SystemV IPC or POSIX message queues; UTS namespace: multiple containers in a Pod share a hostname; volumes (shared storage volume): each container in a Pod may access Volumes defined at the Pod level; the lifecycle of the Pod is managed by the Replication Controller; and defining through the template, then distributing to a Node for operation, and after the operation of the container contained in the Pod is finished, finishing the Pod.

The kubernets system according to the embodiments of the present invention is briefly described above, and an environment switching processing method according to the embodiments of the present invention is described below with reference to specific drawings.

Referring to fig. 1, illustrating a kubernets-based context switching processing method according to an embodiment of the present invention, the method 100 may include

steps

110, 120 and 130, which are described below with reference to specific examples.

Step 110, creating a proxy service configured to expose a port to a plurality of kubernets internal services through a first port exposure mode.

In step 110, creating a proxy service may include: outside the Kubernets framework, a proxy service with the engineering name dev-proxy is additionally configured, the proxy service exposes ports to a plurality of Kubernets services through a first port exposure mode, and one port corresponds to one Kubernets service.

In some embodiments, the first port exposure mode is a Nodeport mode, which binds a port of a host to an internal service. The Node port refers to a real port of a host opened by the kubernets system on each Node in the cluster, so that a client capable of accessing the Node can access the internal Service through the port.

In some embodiments, the proxy service dev-proxy created in step 110 may be a hypertext transfer protocol (HTTP) -based proxy service. The proxy service dev-proxy comprises a configuration file, and the configuration file is configured with the mapping relation between a Nodeport port and Kubernetes internal services. For example, the mapping of the configuration file of the proxy service may be a one-to-one mapping. Furthermore, the proxy service dev-proxy may determine the scope of the internal service acted through the tag selector label selector.

In the embodiment of the invention, the ports are uniformly exposed through the proxy service dev-proxy, so that the mapping relation configuration of all the nodecort ports and the internal services can be determined only by checking the configuration file of the dev-proxy, thereby being convenient for checking and facilitating the port configuration management of each internal service.

And step 120, in a production environment, closing the proxy service, and exposing a plurality of Kubernets internal services to the outside through a second port exposure mode.

In some embodiments of the present invention, the second port exposure mode is an Ingress mode, which binds a plurality of kubernets internal services (for example, greater than or equal to 2) to one fixed port, that is, binds a plurality of internal services to the fixed port externally, and then forwards an access request (for example, an access request from a user) to one or some of the kubernets internal services according to a predetermined forwarding rule.

In a production environment, the Kubernets internal service is externally bound with a fixed port, so that the management is convenient, and the port of the internal service is not directly exposed to the outside and is safer.

In some embodiments, as shown in FIG. 2, in a production environment, service A, service B and Service C are exposed through a unified fixed port 80, where Service A, service B and Service C are located at Host a.com, host b.com and Host c.com, respectively. In Ingress, multiple internal services in Kuberneres are bound to a fixed port, and the fixed port forwards a received request from a user to a service on each host according to a predetermined rule.

Step 130, in a development environment, opening the proxy service, and exposing the inside services of kubernets to the outside through a second port exposure mode, and simultaneously exposing the ports to the inside services of the kubernets through the proxy service according to the first port exposure mode.

In some embodiments of the present invention, in a development environment, an additionally configured proxy service is opened, an Ingress manner is uniformly adopted to expose internal services of kubernets to the outside, and a port is exposed to multiple kubernets internal services through the proxy service according to a Nodeport manner. Exposing a port to a plurality of Kubernets internal services according to a Nodeport mode may include: and carrying out one-to-one mapping binding on the port and Kubernets internal service according to the configuration file of the proxy service. For example, port 30001 is forwarded to Service A, port 30002 is forwarded to Service B, and port 30003 is forwarded to Service C.

The configuration file of the K8S in the related art includes configuration information of the service, and the configuration file of the embodiment of the present invention includes information such as a detailed monitoring port of the agent, the forwarded service, and the like.

In the embodiment of the invention, in the development environment and the production environment, the configuration files of the Kubernets internal service are the same, that is, the configuration files of the Kubernets service can be decoupled from the environment information, the same customized Kubernets service configuration file can be issued and managed in the development environment and the production environment at the same time, modification is not needed, and the configuration processing efficiency of the Kubernets service is greatly improved.

In some embodiments of the present invention, as shown in fig. 3, in a development environment, while the port 80 is exposed to the outside through an Ingress manner, a dev-proxy Service is opened, and the proxy Service exposes the ports 30001, 30002, and 30003 to a Service a, a Service B, and a Service C in sequence based on a nodecort manner, where the Service a, the Service B, and the Service C are located at a Host of a.com, a Host of b.com, and a Host of c.com, respectively. The proxy service is opened, and the plurality of ports are respectively exposed to the plurality of internal services, so that the ports can be conveniently tested in a development environment.

In the embodiment of the invention, the additionally configured proxy service dev-proxy is adopted to expose the port to the internal service in the development environment according to the node port mode, compared with the mode that the node port mode is forbidden in the production environment, the node port mode is started in the development environment and the service configuration file is modified by a special tool in the related technology, the method can realize that the port is exposed in the development environment and the production environment in a unified manner by adopting the ingress mode through the switch of the proxy service without modifying the configuration file of the Kubernets service, and is greatly convenient for the configuration management of the Kubernets service.

Referring to fig. 4, a protocol conversion processing method according to an embodiment of the present invention is shown, and the method 400 may include

steps

410, 420 and 430, which are described below with reference to specific examples.

At step 410, a first request according to a first protocol forwarded by a global agent is received by a local agent deployed in a pod.

In an embodiment of the invention, a Pod is assigned an IP address, using the name of the Pod as the host name for inter-container communication. The lifecycle of the Pod is managed by the Replication Controller; and defining through the template, then distributing to a Node for operation, and after the operation of the container contained in the Pod is finished, finishing the Pod.

Multiple containers may be deployed in one Pod, and multiple containers deployed in the same Pod share a network. Two containers, namely a local proxy and a local Service, are deployed in the Pod and are located on the same virtual machine, wherein the local Service is configured not to provide external services, such as a Central Authentication Service (CAS); the home agent provides an interface to external access.

It should be noted that the pod in step 410 may be any one pod of the kubernets system, and the pod and other pods inside the kubernets system may communicate based on a hypertext Transfer Protocol (HTTP). The services of the Pod can also communicate based on the hypertext transfer protocol HTTP protocol.

The local Proxy of the Pod receives a first request according to a first protocol forwarded by a Global Proxy in the kubernets system, for example, a request based on a hypertext transfer protocol HTTP sent by the Global Proxy (Global Proxy) to the local Proxy.

As described above, in the kubernets system, communication between pod and service is based on the HTTP protocol. However, as shown in fig. 5, the request sent by the user 501 to the kubernets system through the client device is an access request based on a Secure hypertext Transfer Protocol over Secure Socket Layer (HTTPS) Protocol, that is, an HTTPS request. For security purposes, the kubernets system uses the HTTPS protocol for external services and the HTTP protocol for internal services. For an access request based on HTTPS from an external user, the access request is processed through a Global Proxy (Global Proxy) 502, and is distributed to various services according to the requested address, and if the internal service returns the result based on the HTTP protocol, the services are not normally provided. For example, the user's request is https:// www.ebaocloud.com/CAS/, the global Proxy Service forwards the request to the internal Service, i.e. central authentication Service CAS503, calls http:// CAS _ SERVICE, i.e. the central authentication Service CAS receives the http protocol request, thus returning http:// www.ebaocloud.com/CAS/login. Therefore, the protocol is changed, and a cross-domain problem is generated, so that the service cannot be normally provided. The central authentication service CAS503 communicates with the other services 504 according to the HTTP protocol.

Step 420, converting, by the home agent, the first request into a second request based on a second protocol, wherein the pod is further deployed with a home service.

In some embodiments of the invention, the second protocol is the same as the communication protocol of the user client with the kubernets system, which, as mentioned above, may be the HTTPS protocol. The local proxy in the Pod converts the HTTP request received from the global proxy into the HTTPS request, so that the local service can return a request result consistent with the access request of the user client according to the converted request.

Step 430, sending the second request to the local service through the local proxy.

In some embodiments of the invention, the home agent of the pod has one port address and the home service has one port address. Sending the second request to the local service through the local proxy in step 430 may include: the home agent sends the protocol-converted second request from the port of the home agent to the port of the home service.

In some embodiments of the invention, the local service of the pod is configured not to provide the service externally, in which case the method of the invention may further comprise: the port of the external service of the local service is modified into the port of the local proxy, so that the global proxy can conveniently forward the request flow to the corresponding local proxy port.

In some embodiments of the invention, the method of the invention may further comprise: the home service returns the request result based on the second protocol to the home agent. For example, for the central authentication service CAS, it receives an HTTPS request, which returns a result based on the HTTPS request.

In some embodiments of the present invention, as shown in fig. 6, a user 601 sends a request based on an HTTPS protocol to a kubernets system through a client, a Global Proxy602 in the kubernets system sends the request to a local Proxy 604 in a Pod according to an HTTP protocol according to an external service port (i.e., a port of the local Proxy) of the CAS service 603, the local Proxy converts the HTTP request into an HTTPS request and then sends the HTTPS request to a port of a local service CAS from the port of the local Proxy, so that the local Proxy forwards the request to the local service, the local service processes the request to obtain a request result, and then returns the request result to the local Proxy, which is forwarded to the Global Proxy, and returns the request result to the requesting client through the Global Proxy. The pod where the CAS service 603 and the proxy 604 are located communicates with other pods and services 605 according to the HTTP protocol.

The protocol conversion method provided by the embodiment of the invention enables the specific services of Kubernets, such as the central authentication service CAS, to be processed by the local proxy with customization, does not need to perform difference processing on the configuration file of the Kubernets service and the existing configuration file, and can perform equivalent processing with other services for deployment, thereby facilitating development and deployment of the services.

The embodiment of the invention also provides computer equipment. As shown in FIG. 7, the computer device 700 may include a processor 701, an input/output (I/O) device 702, a memory 703, and a database 704.

The processor 701 may employ one or more processing chips that may load computer instructions stored in the memory 703 to implement the methods described above to cause a server to implement the methods described above.

The I/O device 702 may be configured to allow data to be received and/or transmitted. The I/O devices 702 may include one or more digital and/or analog communication devices that allow the computer device 700 to communicate with other machines and devices. The computer device 700 may also include one or more databases 704 or be communicatively coupled to one or more databases 704 via a network. For example, database 704 may be any suitable database suitable for performing the associated data processing of the above-described methods.

Embodiments of the present invention further provide a computer-readable storage medium, on which computer instructions are stored, and when the computer instructions are executed by a processor, the kubernets-based environment switching processing method and the protocol conversion processing method are implemented as described above.

Through the above description of the embodiments, those skilled in the art will clearly understand that the present invention can be implemented by combining software and a hardware platform. With this understanding in mind, all or part of the technical solutions of the present invention that contribute to the background art may be embodied in the form of a software product, which can be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, a smart phone, or a network device, etc.) to execute the methods according to the embodiments or some parts of the embodiments.

The terms and expressions used in the specification of the present invention have been set forth for illustrative purposes only and are not meant to be limiting. It will be appreciated by those skilled in the art that changes could be made to the details of the above-described embodiments without departing from the underlying principles thereof. The scope of the invention is, therefore, to be determined only by the following claims, in which all terms are to be interpreted in their broadest reasonable sense unless otherwise indicated.

Claims

1. An environment switching processing method based on Kubernetes is characterized by comprising the following steps:

the method comprises the steps that proxy service is created, the proxy service is configured to expose ports to a plurality of Kubernets internal services through a first port exposure mode, wherein the first port exposure mode is a Notport mode, and a configuration file of the proxy service configures mapping relations between Nodeport ports and Kubernets internal services;

in a production environment, closing the proxy service, and externally exposing a plurality of Kubernets internal services through a second port exposure mode, wherein the second port exposure mode is an Ingress mode, the Ingress mode is to bind the plurality of Kubernets internal services with one fixed port, and forward an access request to the plurality of Kubernets internal services according to a predetermined forwarding rule;

in a development environment, opening the proxy service, and exposing Kubernets internal services to the outside through a second port exposure mode, and simultaneously exposing ports to a plurality of Kubernets internal services through the proxy service according to the first port exposure mode;

wherein exposing the port to a plurality of Kubernets internal services according to the first port exposure manner comprises: carrying out one-to-one mapping binding on a port and Kubernets internal service according to the configuration file of the proxy service;

wherein the configuration file of each of the plurality of Kubernets internal services is the same in the production environment and the development environment.

2. The method of claim 1, wherein the proxy service is a hypertext transfer protocol (HTTP) service.

3. The method of claim 1, wherein the proxy service determines the internal service to be acted upon by a tag selector, label selector.

4. A computer device comprising a memory and a processor, wherein

The memory storing computer instructions;

the processor configured to execute the computer instructions to cause the computer device to perform the method of claims 1 to 3.

5. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the method of claims 1 to 3.