GLOBAL SERVICE CATALOG FOR PROVISIONING SERVICES ON A MULTI-CLUSTER SERVICE MESH OF A MULTI-CLUSTER COMPUTING ENVIRONMENT

An apparatus comprises a processing device configured to identify one or more dependent services for a workload deployed in a first computing cluster of a multi-cluster computing environment and to select, utilizing a global service catalog aggregating service information for sets of available services offered by at least two computing clusters of the multi-cluster computing environment, a second computing cluster of the multi-cluster computing environment to utilize for provisioning at least a given one of the one or more dependent services for the workload. The processing device is further configured to provision the given dependent service on a multi-cluster service mesh associated with the multi-cluster computing environment by configuring the multi-cluster service mesh to permit access by the workload on the first computing cluster of the multi-cluster computing environment to the given dependent service on the second computing cluster of the multi-cluster computing environment.

FIELD

The field relates generally to information processing, and more particularly to managing information processing systems.

BACKGROUND

Information processing systems increasingly utilize reconfigurable virtual resources to meet changing user needs in an efficient, flexible and cost-effective manner. For example, cloud computing and storage systems implemented using virtual resources such as virtual machines have been widely adopted. Other virtual resources now coming into widespread use in information processing systems include Linux containers. Such containers may be used to provide at least a portion of the virtualization infrastructure of a given cloud-based information processing system. However, significant technical problems can arise in the management of services in cloud-based information processing systems. Similar technical problems arise in other types of information processing systems that include clusters of processing devices.

SUMMARY

Illustrative embodiments of the present disclosure provide techniques for provisioning services on a multi-cluster service mesh of a multi-cluster computing environment utilizing a global service catalog.

In one embodiment, an apparatus comprises at least one processing device comprising a processor coupled to a memory. The at least one processing device is configured to perform the steps of identifying one or more dependent services for a workload deployed in a first one of two or more computing clusters of a multi-cluster computing environment and selecting, utilizing a global service catalog aggregating service information for sets of available services offered by at least two of the two or more computing clusters of the multi-cluster computing environment, a second one of the two or more computing clusters of the multi-cluster computing environment to utilize for provisioning at least a given one of the one or more dependent services for the workload. The at least one processing device is further configured to perform the step of provisioning the given dependent service on a multi-cluster service mesh associated with the multi-cluster computing environment, wherein provisioning the given dependent service on the multi-cluster service mesh comprises configuring the multi-cluster service mesh to permit access by the workload on the first one of the two or more computing clusters of the multi-cluster computing environment to the given dependent service on the second one of the two or more computing clusters of the multi-cluster computing environment.

DETAILED DESCRIPTION

Software architecture may be designed in various ways. In some architectures, software may provide a number of functions in the form of a single, monolithic application. A “monolithic” application refers to a single-tiered, tightly-coupled software application in which various elements of the software architecture (e.g., a user interface, database access, processing logic, etc.) are combined into a single program, usually on a single platform. In software engineering, a monolithic application describes a software application that is designed without modularity. In general, modularity of software elements in a software architecture is desirable, as modularity supports reuse of portions of application logic while also enabling efficient maintenance and development (e.g., by enabling repair and replacement of parts of an application without requiring upgrading the entire application).

Monolithic applications may suffer from disadvantages relating to innovation, manageability, resiliency and scalability, particularly in computing environments such as cloud computing environments, datacenters, and converged infrastructure. As an alternative to such monolithic applications, some software architectures provide different functions in the form of microservices. In a microservice architecture, a single application is developed as a suite of small microservices. A microservice can run on its own process and communicate with other systems or services through a lightweight mechanism, such as a hypertext transport protocol (HTTP) resource application programming interface (API) or communication API provided by an external system. Microservices in some embodiments are assumed to be independently deployable using fully automated deployment mechanisms.

In some embodiments, microservices are small, independent and composable services that can be accessed through Representational State Transfer (RESTful) APIs. Thus, a single monolithic application may be broken down into separate and independent microservices for discrete functions, providing potential benefits in innovation, manageability, resiliency and scalability. Innovation benefits may be provided through the ability to develop and deploy new versions of microservices more rapidly as compared to a single monolithic application. Manageability benefits may be realized as the code used is smaller and thus easier to understand, facilitating changes and deployments. Resiliency benefits may be realized as functionality may be distributed across multiple microservices, such that failure or downtime of one microservice does not result in loss of functionality provided by other microservices. Scalability benefits may be realized in that microservices can be deployed and scaled independently of one another.

Microservices-based software architectural design structures an application as a collection of loosely coupled services. Microservices-based software architectures may be viewed as a variant of a service-oriented architecture that focuses on fine-grained services, lightweight protocols, etc. A microservices architecture enables individual microservices to be deployed and scaled independently, such as via software containers. Individual microservices can be worked on in parallel by different teams, may be built in different programming languages, and have continuous delivery and deployment flows. As development moves toward cloud-native approaches, it is desired to decompose, disintegrate or otherwise separate existing monolithic applications into microservices. Advantageously, microservices allow software developers of an enterprise to work independently and communicate together. Thus, an enterprise system can achieve better efficiency and resiliency with microservices as compared with monolithic applications, while providing similar or better results.

FIG.1shows an information processing system100configured in accordance with an illustrative embodiment for provisioning services on a multi-cluster service mesh of a multi-cluster computing environment101. The multi-cluster computing environment101comprises a set of computing clusters102-1,102-2, . . .102-N(collectively, computing clusters102) which are configured for communication with a multi-cluster service management system104over network108. Also coupled to the network108is a set of one or more host devices106. The host devices106may run workloads on the computing clusters102of the multi-cluster computing environment101, where each of such workloads may utilize one or more dependent services (e.g., microservices) which also run on the computing clusters102of the multi-cluster computing environment101. The workloads and their dependent services, as will be described in further detail below, may run on different ones of the computing clusters102of the multi-cluster computing environment101. The multi-cluster service management system104is configured to facilitate the provisioning and deployment of workloads and their dependent services on the computing clusters102of the multi-cluster computing environment101.

The computing clusters102, the multi-cluster service management system104and the host devices106illustratively comprise respective computers, servers or other types of processing devices capable of communicating with one another via the network108. For example, at least a subset of the host devices106and the multi-cluster service management system104may be implemented as respective virtual machines of a compute services platform or other type of processing platform. The computing clusters102of the multi-cluster computing environment101illustratively provide compute services such as execution of one or more applications or workloads and their dependent services on behalf of each of one or more users associated with respective ones of the host devices106.

The term “user” herein is intended to be broadly construed so as to encompass numerous arrangements of human, hardware, software or firmware entities, as well as combinations of such entities.

The multi-cluster service management system104implements functionality for provisioning and deploying workloads and their dependent services on the computing clusters102of the multi-cluster computing environment101utilizing a global service catalog140and service scheduler142. The global service catalog140utilizes local service catalog registration logic144to register local service catalogs120-1,120-2, . . .120-N(collectively, local service catalogs120) implemented by the computing clusters102in the multi-cluster computing environment101. Each of the computing clusters102may offer different types of services, with information on such services being made part of their associated local service catalogs120. The local service catalog registration logic144of the multi-cluster service management system104registers the local service catalogs120with the global service catalog140, which can aggregate information regarding the services offered by different ones of the computing clusters102of the multi-cluster computing environment101. Such aggregated information is used by the service scheduler142for determining where to deploy workloads and their dependent services across the computing clusters102of the multi-cluster computing environment101.

The service scheduler142utilizes service provisioning logic146for provisioning and deploying workloads and their dependent services on the computing clusters102of the multi-cluster computing environment101. As shown inFIG.1, each of the computing clusters102implements an instance of service provisioning logic122-1,122-2, . . .122-N(collectively, service provisioning logic122) for facilitating such provisioning and deployment of workloads and their dependent services with the service provisioning logic146of the multi-cluster service management system104.

It should be noted that whileFIG.1shows an embodiment where each of the computing clusters102implements a local service catalog120and service provisioning logic122, this is not a requirement. For example, one or more of the computing clusters102of the multi-cluster computing environment101may not implement a local service catalog instance. Further, while in theFIG.1embodiment the multi-cluster service management system104and host devices106are shown as being implemented outside of the multi-cluster computing environment101, this is not a requirement. In other embodiments, the multi-cluster service management system104and/or one or more of the host devices106may be implemented at least partially internal to the multi-cluster computing environment101(e.g., on one of more of the computing clusters102thereof, as separate standalone servers, computers or other processing devices that execute within the multi-cluster computing environment101, etc.).

At least portions of the functionality of the local service catalogs120, the service provisioning logic122, the global service catalog140, the service scheduler142, the local service catalog registration logic144, and the service provisioning logic146may be implemented at least in part in the form of software that is stored in memory and executed by a processor.

The computing clusters102, the multi-cluster service management system104and the host devices106(or one or more components thereof such as the local service catalogs120, the service provisioning logic122, the global service catalog140, the service scheduler142, the local service catalog registration logic144, and the service provisioning logic146) may be implemented on respective distinct processing platforms, although numerous other arrangements are possible. For example, in some embodiments at least portions of one or more of the host devices106and the multi-cluster service management system104and/or one or more of the computing clusters102are implemented on the same processing platform. The multi-cluster service management system104can therefore be implemented at least in part within at least one processing platform that implements at least a subset of the host devices106. Further, as noted above, the multi-cluster service management system104and/or one or more of the host devices106may be implemented at least partially internal to the multi-cluster computing environment101(e.g., on one or more of the computing clusters102thereof).

The network108may be implemented using multiple networks of different types. For example, the network108may comprise a portion of a global computer network such as the Internet, although other types of networks can be part of the network108including a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network, a wireless network such as a WiFi or WiMAX network, a storage area network (SAN), or various portions or combinations of these and other types of networks. The network108in some embodiments therefore comprises combinations of multiple different types of networks each comprising processing devices configured to communicate using Internet Protocol (IP) or other related communication protocols.

The computing clusters102, the multi-cluster service management system104and the host devices106in some embodiments may be implemented as part of a cloud-based system. The computing clusters102, the multi-cluster service management system104and the host devices106can be part of what is more generally referred to herein as a processing platform comprising one or more processing devices each comprising a processor coupled to a memory. A given such processing device may correspond to one or more virtual machines or other types of virtualization infrastructure such as Docker containers or other types of LXCs. As indicated above, communications between such elements of system100may take place over one or more networks including network108.

The term “processing platform” as used herein is intended to be broadly construed so as to encompass, by way of illustration and without limitation, multiple sets of processing devices and one or more associated storage systems that are configured to communicate over one or more networks. For example, distributed implementations of the computing clusters102, the multi-cluster service management system104and the host devices106are possible, in which certain ones of the host devices106and/or computing clusters102reside in one data center in a first geographic location while other ones of the host devices106and/or computing clusters102reside in one or more other data centers in at least a second geographic location that is potentially remote from the first geographic location. The multi-cluster service management system104may be implemented at least in part in the first geographic location, the second geographic location, and one or more other geographic locations. Thus, it is possible in some implementations of the system100for different ones of the host devices106, the computing clusters102and the multi-cluster service management system104to reside in different data centers.

Numerous other distributed implementations of computing clusters102, the multi-cluster service management system104and the host devices106are possible. Accordingly, computing clusters102, the multi-cluster service management system104and the host devices106can also be implemented in a distributed manner across multiple data centers.

Additional examples of processing platforms utilized to implement portions of the system100in illustrative embodiments will be described in more detail below in conjunction withFIGS.5and6.

It is to be understood that the particular set of elements shown inFIG.1for provisioning services on a multi-cluster service mesh of the multi-cluster computing environment101utilizing the global service catalog140is presented by way of illustrative example only, and in other embodiments additional or alternative elements may be used. Thus, another embodiment may include additional or alternative systems, devices and other network entities, as well as different arrangements of modules and other components.

An exemplary process for provisioning services on a multi-cluster service mesh of a multi-cluster computing environment utilizing a global service catalog will now be described in more detail with reference to the flow diagram ofFIG.2. It is to be understood that this particular process is only an example, and that additional or alternative processes for provisioning services on a multi-cluster service mesh of a multi-cluster computing environment utilizing a global service catalog may be used in other embodiments.

In this embodiment, the process includes steps200through204. These steps are assumed to be performed by or using the local service catalogs120, the service provisioning logic122, the global service catalog140, the service scheduler142, the local service catalog registration logic144, and the service provisioning logic146. The process begins with step200, identifying one or more dependent services for a workload deployed in a first one of two or more computing clusters (e.g., computing clusters102) of a multi-cluster computing environment (e.g., multi-cluster computing environment101). In step202, a global service catalog (e.g., global service catalog140) that aggregates service information for sets of available service offered by at least two of the two or more computing clusters of the multi-cluster computing environment is utilized to select a second one of the two or more computing clusters of the multi-cluster computing environment to utilize for provisioning at least a given one of the one or more dependent services for the workload. The given dependent service may comprise a given service type, and step202may comprise selecting the second one of the two or more computing clusters of the multi-cluster computing environment from among at least two of the two or more computing clusters of the multi-cluster computing environment offering services of the given service type. The second one of the two or more computing clusters of the multi-cluster computing environment may be selected based at least in part on various factors, such as latency to the first one of the two or more computing clusters of the multi-cluster computing environment where the workload is deployed.

The aggregated service information may be collected from local service catalogs (e.g., local service catalogs120) associated with at least two of the two or more computing clusters of the multi-cluster computing environment. Such local service catalogs may be registered with the global service catalog, where such registration includes, for a given one of the local service catalogs associated with a given one of the at least two of the two or more computing clusters of the multi-cluster computing environment, parsing a registration request for the given local service catalog. The registration request may specify an operator of the given one of the two or more computing clusters of the multi-cluster computing environment, a network address of the given local service catalog, and a private key of a key pair generated for establishing secure connection between the given local service catalog and the global service catalog. The global service catalog may periodically poll the local service catalogs that maintain information regarding sets of available services offered by the at least two of the two or more computing clusters of the multi-cluster computing environment to update the sets of available services offered by the at least two of the two or more computing clusters of the multi-cluster computing environment.

The aggregated service information of the global service catalog may comprise one or more consolidated service entries. At least a given one of the one or more consolidated service entries may be associated with a given service type. The given service type may comprise at least one of: a database service type; a storage service type; a security service type; a hardware accelerator service type. The given consolidated service entry may identify at least two of the two or more computing clusters of the multi-cluster computing environment that offer services of the given service type. The given consolidated service entry may also or alternatively identify at least two service configurations of the given service type offered by at least one of the two or more computing clusters of the multi-cluster computing environment. The at least two service configurations may comprise two or more different guaranteed levels of service of the given service type offered by the at least one of the two or more computing clusters of the multi-cluster computing environment.

In step204, the given dependent service is provisioned on a multi-cluster service mesh associated with the multi-cluster computing environment. Step204comprises configuring the multi-cluster service mesh to permit access by the workload on the first one of the two or more computing clusters of the multi-cluster computing environment to the given dependent service on the second one of the two or more computing clusters of the multi-cluster computing environment. Step204may further comprise generating a key pair for the workload, wherein the generated key pair comprises a private key and a public key, providing the private key of the generated key pair to the workload, and providing the public key and a given identifier of the workload to the given dependent service. Step204may further or alternatively comprise: receiving, from a local service catalog associated with the second one of the two or more computing clusters of the multi-cluster computing environment, one or more credentials for the given dependent service encrypted utilizing a public key of a key pair associated with the local service catalog; decrypting, at the global service catalog, the one or more credentials for the given dependent service utilizing a private key of the key pair associated with the local service catalog, the private key being previously provided to the global service catalog during registration of the local service catalog; and injecting the decrypted one or more credentials into the first one of the two or more computing clusters of the multi-cluster computing environment where the workload is deployed.

In some embodiments, steps202and204are repeated dynamically in response to various conditions, such as detecting one or more changes in available resources of at least one of the two or more computing clusters of the multi-cluster computing environment, detecting migration of the workload (e.g., from (i) being deployed in the first one of the two or more computing clusters of the multi-cluster computing environment to (ii) being deployed in at least one other one of the two or more computing clusters of the multi-cluster computing environment), etc.

With growing trends of 5G and edge computing, workloads are being moved away from traditional data centers and cloud computing platforms to places that are closer to the end users to improve user experience. Moving workloads between different facilities (e.g., different computing sites, including among data centers, cloud computing platforms, edge computing sites, etc.) will thus become more common. There is a need for technical solutions that can provide support for moving workloads and their dependent services, enabling the dependent services for workloads to be scheduled and run at multiple different facilities (e.g., which may be the same as or different than their associated workloads).

Various workloads may depend on or otherwise utilize various different types of services, such as database services, storage services, acceleration services, etc. Moving workloads between facilities requires technical solutions for providing dependent services in corresponding environments. As dynamic scheduling approaches are adopted for workload placement (e.g., including for edge and 5G deployments), there is a need for technical solutions for managing dependent services of the workloads. In some embodiments, a service mesh and service broker are utilized for facilitating management of dependent services.

Dependent services are normally deployed in the same environment as the consumers (e.g., workloads) of the services in order to reduce operational cost and improve latency between the workloads and their dependent services. Being in the same environment makes it easier for workloads to consume dependent services (e.g., avoiding the need for handling firewall and authentication issues).

There are various technical problems associated with handling of workloads and dependent services in multi-cluster computing environments. In a multi-cluster computing environment, each computing cluster may be operated by a different provider. The barriers between two computing clusters require operators or developers to manually resolve each case. Multi-cluster computing environments also make service provisioning a more complicated task. When a workload is moved from a first computing cluster to a second computing cluster, the dependent services will typically be moved along with the workload from the first computing cluster to the second computing cluster. There may be other options, however. Consider, as an example, a database service that has been created and used for many years. In some cases, moving the database service to another computing cluster may not be the best choice (e.g., as extra latency may not be critical for the workload, considering the cost associated with movement of the dependent service between computing clusters). In other cases, a dependent service should be moved from its original computing cluster (e.g., where latency is important to user experience) to a target computing cluster. However, due to limited resources in the target computing cluster, moving the dependent service into the target computing cluster may not be cost efficient. A technical solution in such an instance would be to run the dependent services in another computing cluster that is close to the target computing cluster (e.g., with good latency characteristics and better cost efficiency than running the dependent service directly in the target computing cluster). There are thus various technical problems with service provisioning in multi-cluster computing environments, as compared with single-cluster computing environments (e.g., as more factors are involved).

Multi-cluster computing environments can also pose security threats. Accessing dependent services in another computing cluster (e.g., in a different facility) often involves manual configuration effort by IT departments (e.g., to open a port in a firewall, such as where the port is a non-traditional port). Further, exposing an existing dependent service that was previously only available internally within one computing cluster can require various manual configuration (e.g., assigning new IP addresses or domains, etc.). In addition, scheduling workloads is not always a static one-time process and may instead be a continuous process based on various factors (e.g., user input, changes in related environments, etc.). Further, continuously punching “holes” (e.g., opening ports in firewalls or other tasks that expose potential attack vectors for malicious actors) and exposing internal services to other computing clusters will intensify the efforts required for IT operators and pose security threats.

Multi-cluster computing environments can also pose threats to credential management systems. To access dependent services in different facilities, credentials are often required. The task of managing such credentials while workloads are moved across different computing clusters without compromising the credentials presents technical problems and challenges for both operators and developers.

Illustrative embodiments provide technical solutions for service selection and placement among multiple computing sites (e.g., multiple computing clusters, including cloud computing platforms, edge computing sites, data centers, etc.). The technical solutions described herein may utilize a global service catalog, a customized local service catalog, and a customized service broker API. The customized local service catalog for a given computing site or cluster may be used to provision third-party services (e.g., dependent services) for workloads that are running within that computing site or clusters, or potentially in a different computing site or cluster. For example, a Kubernetes container orchestration system may utilize a service catalog for providing third-party services to workloads running in a Kubernetes environment. Developers can use the Kubernetes API or command line interface (CLI) to provision service instances in the service catalog, and for binding the provisioned services to applications. In some embodiments, a customized local service catalog is provided that enables provisioning of services, binding services to applications or other workloads, collecting metrics data, and generating public key infrastructure (PKI) keys for the binding of provisioned services to applications or other workloads.

Some embodiments also utilize a customized service broker API. A service broker API may be used to facilitate management and delivery of services. Kubernetes, for example, utilizes a service broker API in its service catalog. The customized service broker API utilized in some embodiments provides additional functionality for adding metrics data into the bodies of service requests.

The global service catalog provides functionality for communicating with one or more customized local service catalogs, deployed in different computing clusters, which are registered to the global service catalog. The global service catalog can collect service information from the customized local service catalogs, where the service information comprises information regarding the available services on each computing cluster. The global service catalog can also send requests to the customized local service catalogs to provision new services.

FIG.3shows an example architecture300, including a set of computing clusters302-1,302-2, and302-3(collectively, computing clusters302). The computing clusters302-1and302-2implement respective local customized service catalogs320-1and320-2(collectively, local service catalogs320). The computing clusters302-1and302-2also run respective sets of services321-1,321-2, and321-3(collectively, services321) and services322-1,322-2, and322-3(collectively, services322) which may be consumed by or otherwise utilized by a set of workloads331-1,331-2, and331-3(collectively, workloads331) running on computing cluster302-3. The services321and322may be scheduled (e.g., provisioned and bound to the workloads331) utilizing a service scheduler342coupled to the global service catalog340and the computing cluster302-3. The architecture300also includes a multi-cluster service mesh341(e.g., of the services321and322running on the computing clusters302-1and302-2, and the workloads331running on the computing cluster302-3). The local service catalogs320are shown in communication with a multi-cluster service mesh control plane343.

As illustrated inFIG.3, each of the computing clusters302can provide a place for provisioning services (e.g., services321and322), for running workloads (e.g., workloads331), or combinations thereof. WhileFIG.3shows an example where each of the computing clusters302runs either a set or services or a set of workloads, this is not a requirement. In other embodiments, a single one of the computing clusters302may run one or more services and one or more workloads. The computing clusters302utilize the multi-cluster service mesh341as an underlying way of secure communication therebetween. In some embodiments, the multi-cluster service mesh341utilizes a suitably modified implementation of an Istio® service mesh. The Istio service mesh, for example, is used as the default service mesh in Kubernetes, and supports multi-cluster service mesh environments. The global service catalog340can be deployed in any one of the computing clusters302, or in a dedicated location (e.g., a dedicated server) where the computing clusters302are able to establish a secure connection with the global service catalog340as part of the multi-cluster service mesh control plane343.

The multi-cluster service mesh341enables services321and322, as well as workloads331, to connect to each other without requiring that each of the services321and322, and each of the workloads331, know the exact connection details of one another (e.g., IP or other network addresses, secrets, etc.). The multi-cluster service mesh341may implement an application layer proxy that facilitates the development and deployment of workloads that have dependent services (e.g., third-party services). The multi-cluster service mesh341enables the services321and322and the workloads331to connect to each other. As will be described in further detail below, secrets or other credentials may be added to the multi-cluster service mesh341to make sure that only specific workloads331can access specific ones of the services321and322.

The local service catalogs320and the global service catalog340may be used for implementing a marketplace for services. The number and types of such services may vary. Non-limiting examples of the services include database services, block storage services, authentication services, accelerator services, security services, etc. Conventionally, a marketplace (e.g., a local service catalog) can only serve the computing cluster where the marketplace is deployed. The technical solutions described herein deploy the global service catalog340that can provide a union of all available marketplaces (e.g., the local service catalogs320on computing clusters302-1and302-2) together as one, to facilitate running workloads (e.g., workloads331) which utilize dependent services (e.g., services321and322) across the multiple computing clusters302.

To register the local service catalogs320with the global service catalog340, a registration request may be submitted to an endpoint of the global service catalog340. The registration request may follow a predefined format. In some embodiments, the registration request may be a Hypertext Transfer Protocol (HTTP) POST method to the endpoint of the global service catalog340(e.g., to “/v1/catalog” of the global service catalog340). The registration request may therefore use the syntax:

The body of the registration request will provide various information associated with a given one of the local service catalogs320that is the subject of the registration request. Such information may include, for example, an address of the given local service catalog320, a provider of the given local service catalog320, a private key of the given local service catalog320, etc. In some embodiments, the body of the registration request utilizes a JavaScript Object Notation (JSON) format as follows:

{“provider”: “Provider_Name”,“address”: “catalog.local_location.provider_name.com”“private_key”: “ABCDE12345”}
The private key of the given local service catalog320in some embodiments is generated and utilized solely for the purpose of establishing a secure connection between the global service catalog340and the given local service catalog320.

Once the global service catalog340receives the registration request from the given local service catalog320, the global service catalog340connects to the given local service catalog320(e.g., using information from the body of the registration request) to retrieve information about the services that are part of the given local service catalog320. The global service catalog340will then update its own records with any new services, if necessary. Since services can be added and removed, and existing services may be modified (e.g., to change their performance or other characteristics), the global service catalog340may poll information from each of the registered local service catalogs320(e.g., periodically, at some user-specified frequency, etc.).

The global service catalog340may also aggregate service information across the registered local service catalogs320, as there may be local service catalogs320in more than one of the computing clusters302that provide a same type of service. For example, there may be multiple ones of the computing clusters302that provide a given type of database service (e.g., a MySQL® database service), with each of such multiple computing clusters302providing an instance of the given type of database service with its own characteristics. A first instance of the given type of database service may have a higher limit on active connections than a second instance of the given type of database service, while the first instance of the given type of database service has a higher cost than the second instance of the given type of database service. Further, even within a same one of the local service catalogs320, there may be different plans for the given type of database service (e.g., a silver plan with 100 gigabytes (GB) of storage, a gold plan with 500 GB of storage, etc.). For each type of service, the global service catalog340will aggregate all plans of all the local service catalogs320with additional information (e.g., the provider of that plan), and show such plans under a single service type (e.g., multiple plans under one MySQL® database service type).

Following registration of the local service catalogs320with the global service catalog340, the global service catalog340will have a collection of services that can be used to help the service scheduler342to decide which of the computing clusters302should be used to deploy new workloads based at least in part on the dependent services utilized by the workloads. The customized service broker API can be used to expose functions of the global service catalog340to the service scheduler342.

Once the service scheduler342decides where to deploy a given workload and which service plan should be used to provision dependent services of the given workload, such decisions may be sent to the global service catalog340. The global service catalog340will generate a pair of private and public keys for each workload. The global service catalog340will then send provisioning requests to the local service catalogs320that provide the dependent services (e.g., with the local service catalogs320being selected based on the chosen plan for the dependent services), along with the public key and the name (or other identifier) of the workload that is going to be consuming the dependent services. The local service catalogs320will then provision the requested services, and make such provisioned services available on the multi-cluster service mesh341. The multi-cluster service mesh341may be configured to only accept traffic from the workload with the name or other identifier that has the provided public key, so that only the authorized workload can consume the provisioned services.

FIG.4shows an architecture400of a provisioned service421on a computing cluster402-1that is a dependent service of a workload431deployed on a computing cluster402-2. The service421and workload431have respective “sidecars”423and433which facilitate communication between the service421and the workload431via multi-cluster service mesh441. The service sidecar423and the workload sidecar433may implement proxy servers that can redirect traffic based on policies defined by the multi-cluster service mesh441. The proxy servers implemented by the service sidecar423and the workload sidecar433can handle application layer traffic in protocols such as HTTP. The service sidecar423is deployed along with the service421, and listens to requests (e.g., from the workload431) that are directed to the service421. The service sidecar423will translate the original application layer request, and establish a secure connection with the target service421. Similarly, the workload sidecar433is deployed along with the workload431and listens for requests directed to the workload431and translates them as needed.

The workload sidecar433will have a private key generated by the global service catalog (e.g., the global service catalog340, not shown inFIG.4), and the service sidecar423will have the corresponding public key and the name or other identifier of the workload431. With this setup, only the workload431can access the service421—even traffic from another location (e.g., another workload) with the private key would be rejected. If the service421needs to create credentials, a local service catalog (not shown inFIG.4) on the computing cluster402-1will build a correct service configuration for provisioning. The necessary credentials are sent to the global service catalog, and such credentials will be encrypted by the provided public key. Once the global service catalog receives the encrypted credential, it will send this to the service scheduler (e.g., the service scheduler342, not shown inFIG.4). The service scheduler342is responsible for injecting this credential into the environment (e.g., the computing cluster402-2) where the workload431is running, so that the workload431can access the credentials and use them to access the provisioned service421on the computing cluster402-1. Once the workload431is finished (e.g., ceases execution, migrates to another computing cluster, etc.) and the service421is no longer needed, a deprovision request may be sent to the global service catalog340to deprovision the service421. The global service catalog340can then terminate or destroy the service421, as well as the service sidecar423and the workload sidecar433.

The technical solutions described herein provide a number of technical advantages. Such technical advantages include dynamically provisioning services in a multi-cluster computing environment with a global service catalog (e.g., the global service catalog340). Scheduling workloads in a multi-cluster computing environment is not always a static process, but may instead be a continuous process that is based on various factors such as latest user requests, resource availability in computing clusters that are part of the multi-cluster computing environment, network latency, etc. Advantageously, the technical solutions described herein can detect changes in such factors, and dynamically decide where to provision dependent services to increase overall resource utilization and efficiency in the multi-cluster computing environment, and to improve workload performance.

Dynamic access control in a multi-cluster computing environment is also enabled through the use of a multi-cluster service mesh (e.g., multi-cluster service mesh341, multi-cluster service mesh441). Accessing services in different facilities (e.g., different computing clusters of a multi-cluster computing environment) is a “pain point” for developers, due to the complexity of the IT systems (e.g., including managing access control lists for incoming traffic). The technical solutions described herein provide a multi-cluster service mesh that can free developers from having to deal with these and other issues, by dynamically granting and revoking permissions for specific workloads accessing specific services.

The technical solutions described herein further enable inter-cluster credential management in a multi-cluster computing environment, where such inter-cluster credential management may include cluster and service-specific credentials. Advantageously, service credentials may be dynamically regenerated for services, such as in the context of client or workload migration during multi-cloud (or other multi-cluster computing environment) orchestration optimization.

The global service catalog can also facilitate inter-cluster scheduling of workloads and their dependent services. The scheduling of workloads and their dependent services may involve many different factors, including but not limited to latency between computing clusters, service availability, service performance, etc., to make improved scheduling decisions. The global service catalog provides a channel for collecting service information from multiple local service catalogs, aggregating the collected service information, and sending the aggregated service information to a service scheduler that will utilize the aggregated service information to make intelligent decisions for the deployment of workloads and their dependent services across different computing clusters of a multi-cluster computing environment. The global service catalog can also be used to dynamically add and remove local service catalogs for different computing clusters that may provide different types of services. The ability to dynamically add (and remove) local service catalogs will increase the capabilities of the multi-cluster computing environment, and create mechanisms for third-party service providers to join the multi-cluster computing environment to build a greater services ecosystem.

Illustrative embodiments of processing platforms utilized to implement functionality for provisioning services on a multi-cluster service mesh of a multi-cluster computing environment utilizing a global service catalog will now be described in greater detail with reference toFIGS.5and6. Although described in the context of system100, these platforms may also be used to implement at least portions of other information processing systems in other embodiments.

FIG.5shows an example processing platform comprising cloud infrastructure500. The cloud infrastructure500comprises a combination of physical and virtual processing resources that may be utilized to implement at least a portion of the information processing system100inFIG.1. The cloud infrastructure500comprises multiple virtual machines (VMs) and/or container sets502-1,502-2, . . .502-L implemented using virtualization infrastructure504. The virtualization infrastructure504runs on physical infrastructure505, and illustratively comprises one or more hypervisors and/or operating system level virtualization infrastructure. The operating system level virtualization infrastructure illustratively comprises kernel control groups of a Linux operating system or other type of operating system.

The cloud infrastructure500further comprises sets of applications510-1,510-2, . . .510-L running on respective ones of the VMs/container sets502-1,502-2, . . .502-L under the control of the virtualization infrastructure504. The VMs/container sets502may comprise respective VMs, respective sets of one or more containers, or respective sets of one or more containers running in VMs.

In some implementations of theFIG.5embodiment, the VMs/container sets502comprise respective VMs implemented using virtualization infrastructure504that comprises at least one hypervisor. A hypervisor platform may be used to implement a hypervisor within the virtualization infrastructure504, where the hypervisor platform has an associated virtual infrastructure management system. The underlying physical machines may comprise one or more distributed processing platforms that include one or more storage systems.

In other implementations of theFIG.5embodiment, the VMs/container sets502comprise respective containers implemented using virtualization infrastructure504that provides operating system level virtualization functionality, such as support for Docker containers running on bare metal hosts, or Docker containers running on VMs. The containers are illustratively implemented using respective kernel control groups of the operating system.

The processing platform600in this embodiment comprises a portion of system100and includes a plurality of processing devices, denoted602-1,602-2,602-3, . . .602-K, which communicate with one another over a network604.

The processing device602-1in the processing platform600comprises a processor610coupled to a memory612.

The memory612may comprise random access memory (RAM), read-only memory (ROM), flash memory or other types of memory, in any combination. The memory612and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs.

Also included in the processing device602-1is network interface circuitry614, which is used to interface the processing device with the network604and other system components, and may comprise conventional transceivers.

The other processing devices602of the processing platform600are assumed to be configured in a manner similar to that shown for processing device602-1in the figure.