A management cluster with integration service for the provision and management of a service in tenant clusters

Abstract

Procedure that includes the following: Received, from a service controller (106), at an integration service (104) running in a hardware-based management cluster (102), a notification to create a new tenant cluster (110) in a container environment (100); in response to the notification to create the new tenant cluster (110), transmitted (302) by the integration service (104) to a service endpoint (114) of a service provider (108), a request to provide a service (112) connected to the service provider (108) at the new tenant cluster (110); in response to the request, the integration service (104) receives (304) tenant cluster-specific configuration information from the service provider (108), the service (112) being registered with the service provider (108) using the tenant cluster-specific configuration information; Generating (306) access authorizations for the new tenant cluster (110) by the integration service (104); and Providing (308) the tenant cluster-specific configuration information and access permissions for the service controller (106) by the integration service (104); and Provisioning and managing (400), by the service controller (106), of the service on the new tenant cluster (110) using the tenant cluster-specific configuration information, access permissions, and a service catalog (202) associated with the service (112) on the management cluster (102), wherein the service catalog (202) includes an application manifest containing information regarding an associated set of resources to be used for provisioning the service (112) in the new tenant cluster (110), and wherein the service (112) in the new tenant cluster (110) is to use the access permissions from the integration service (104) received at the service controller (106) to communicate with the service provider (108).

Description

BACKGROUND

[0001] Computing devices can leverage containerization at the operating system level, providing an easily scalable architecture for custom deployment of a variety of applications that can share the same underlying computing resource. In some examples, mutually isolated computing instances, referred to as containers (or, in some examples, by other terms such as virtualization engines or partitions), operate as separate computers from the perspective of the applications running on them. While a deployed application can use and is aware of the resources of its container, it generally has no knowledge of the resources of another container, even if an underlying physical resource is shared. For example, some of the resources of a computer, server, or the like might be allocated to one container and another to another.An application running inside a container can have access to the compute resources allocated to the container, but not to the compute resources of other containers. Such isolation of compute resources enables easy scalability and access to the same underlying resource by mutually distrustful instances with little additional overhead.

[0002] US 2006 / 0 293 936 A1 discloses a method and system for automatically converting a service offered by a provider into an offer for a customer-specific service environment. US 2020 / 0 404 076 A1 relates to a method for deploying an application workload in a cluster. US 10 951 604 B1 describes a system in which services are offered in multiple Hadoop clusters and secure user access to the services is regulated. US 2021 / 0 240 734 A1 discloses methods, systems, and computer programs for executing container-based computing environments with user interfaces, and US 2019 / 0 238 618 A1 concerns the management of cloud storage solutions with block-based and file-based data.

[0003] A container management and deployment system can help automate the deployment and scaling of applications and / or actively manage and operate an application throughout its lifecycle. For example, Kubernetes (also known as "k8s") is a system that provides a platform for automating the deployment, scaling, and / or operation of containers across clusters of host machines (also known as nodes).

[0004] It is an object of the present invention to enable an efficient and secure solution for providing services in a container environment. This object is achieved by a method according to claim 1, a system according to claim 9, and a non-transitory machine-readable medium according to claim 17. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The following detailed description refers to the drawings in which: Fig. 1 is a block diagram of a container environment with a management cluster for managing the provisioning and lifecycle of services in tenant clusters according to disclosed examples; Fig. 2 is a block diagram of an example management cluster including an integration service and a service controller according to the described examples; Fig. 3 is a flowchart illustrating a method including operations performed by an integration service to enable provisioning of a service in a new tenant cluster, in accordance with disclosed examples; Fig. 4 is a flowchart illustrating a method including operations performed by a service controller for provisioning a service in a new tenant cluster according to the disclosed examples; Fig. 5 is a block diagram showing a processor coupled to a machine-readable medium storing executable instructions for providing dynamic information for providing services in accordance with disclosed examples; and Fig. 6 is a block diagram showing a processor coupled to a machine-readable medium storing executable instructions for provisioning the service in the new tenant cluster, in accordance with disclosed examples. DETAILED DESCRIPTION

[0006] The following detailed description refers to the accompanying drawings. Wherever possible, like reference numerals are used in the drawings and the following description to refer to the same or similar parts. It is expressly understood that the drawings are for illustration and description purposes only. Although several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the examples shown do not limit the description. The proper scope of the disclosed examples may be defined by the appended claims.

[0007] The terminology used herein is for the purpose of describing specific examples and is not intended to be limiting. The singular forms “a,” “an,” and “the” include the plural forms unless the context clearly indicates otherwise. As used herein, “another” is defined as at least one second or more. As used herein, “coupled” is defined as connected, either directly with no intervening elements or indirectly with at least one intervening element, unless otherwise noted. For example, two elements may be mechanically, electrically, or communicatively connected via a communications channel, path, network, or system. Furthermore, as used herein, the term “and / or” refers to and includes all possible combinations of the listed elements.As used herein, the term "includes" means "includes" but is not limited to; the term "including" means "including" but not limited to. The term "based on" means based at least in part on.

[0008] Although particular implementations are shown and described herein, various changes in form and details may be made. For example, some features and / or functions described with respect to one implementation and / or process may be transferred to other implementations. In other words, processes, features, components, and / or properties described with respect to one implementation may also be useful in other implementations. Furthermore, it should be understood that the systems and methods described herein may include various combinations and / or subcombinations of the components and / or features of the various implementations described.

[0009] As described here, a tenant cluster refers to a group of nodes running containerized applications. A tenant cluster can include one or more master nodes and many worker nodes. These worker nodes can be either physical computers or virtual machines, depending on the cluster. The tenant cluster can also be referred to as a workload cluster.

[0010] As described here, a management cluster refers to a multicluster manager in a control plane of a container environment to support the provisioning, configuration, deployment, and lifecycle of services across multiple tenant clusters. The management cluster may also be referred to as a master management cluster.

[0011] As enterprises support container management systems, application development and deployment are increasingly performed in containers. Multiple containers can run on a group of nodes, and the group of nodes together forms a cluster. In general, the applications running in the containers of a cluster can have dependencies. For example, applications running in one cluster may rely on services provided by service providers on another cluster, or they may rely on or interact with service providers on an external cloud. In some cases, the service providers may provide monitoring, logging, and / or alerting services and / or applications that can be deployed in the cluster to monitor the containers.In other cases, service providers may provide databases, message queuing applications, and object storage services.

[0012] In general, an operator can be deployed in a tenant cluster to implement and manage the service lifecycle in the tenant cluster via the service agent. The operator in the tenant cluster can be provided with specific configuration information by the service providers. The configuration information is stored on both the tenant cluster and service provider sides. The service providers uniquely identify each tenant cluster by the configuration. This allows the service providers to distinguish the data received from multiple tenant clusters. In addition to the configuration information, each tenant cluster can be provided with credentials (e.g., username and password). The service agents in the tenant clusters use the credentials to communicate with the service provider.In some cases, the operator can use the credentials and configuration information to communicate with a service provider portal to complete the registration of the tenant cluster with the service provider. In other cases, the operator can communicate with the service provider running on a different cluster to complete the registration of the tenant cluster with the service provider.

[0013] Configuration information is typically generated for each tenant cluster and made available to the tenant cluster operator by the service provider. However, there is currently no standardized way to provide the configuration information to the tenant cluster. The configuration information required by the tenant cluster can be received through various mechanisms. The configuration information can be a YAML (Yet Another Markup Language) file or a JSON (JavaScript Object Notation) file, which the service provider provides upon request. In some cases, the service provider running on a different cluster can generate configuration information and credentials for the tenant cluster and make them available to the operator of the newly generated tenant cluster.In other cases, the configuration information and credentials can be provided by a user after registering the tenant cluster on a cloud service provider's software-as-a-service (SaaS) portal. Furthermore, there is no solution for automatically deploying live configuration information to operators of newly created clusters. Existing implementations require one operator per tenant cluster. Furthermore, updating credentials can become challenging across multiple tenant clusters if the credentials provided to the tenant clusters change. Each credential change would require each tenant cluster to be individually updated with new credentials.

[0014] Therefore, in accordance with aspects of the present disclosure, a management cluster is deployed in a container environment that can avoid one or more of the above-mentioned challenges. The management cluster includes an integration service coupled with a service controller. The integration service provides configuration information to the service controller to provision a service in a new tenant cluster. The configuration information may include access permissions and tenant cluster-specific configuration. The service controller uses the configuration information to provision a service in the tenant cluster.The management cluster can provision, deploy, and manage the lifecycle of a service provided by a service provider across multiple tenant clusters in an automated, dynamic, consistent, and efficient manner using the service controller and the integration service. The management cluster also manages upgrades for the service across multiple tenant clusters using the integration service.

[0015] Because the Integration Service provides the service controller for the new tenant cluster with the credentials and tenant-cluster-specific configuration information, the service is provisioned using dynamically received data from the Integration Service. Furthermore, the Management Cluster can store privileged credentials (also known as secrets) required to communicate with the service provider. The privileged credentials are provided and managed by the service provider. Because these credentials are stored in the Management Cluster and not made available to individual tenant clusters, the operational overhead associated with managing security and rotating credentials can be avoided.

[0016] Fig. 1 is a block diagram of a container environment 100 including a management cluster 102 for managing the deployment and lifecycle of a service 112 across a plurality of tenant clusters. The container environment 100 may be connected to a provider that provides infrastructure and services for the plurality of tenant clusters. The services provided by the container environment 100 may include, but are not limited to, virtual computer systems, block-level data stores, cryptographic services, on-demand data stores, notification services, web services, authentication services, policy management services, task services, and / or other such services.

[0017] The container environment 100 can be managed by a container orchestration platform (e.g., Kubernetes) to schedule and automate the deployment, management, and scaling of containerized applications. The container environment 100 can include a control plane and compute engines. The compute engines can include a number of worker nodes running containerized applications. A tenant cluster can include a master node (in the control plane) and multiple worker nodes. Depending on the cluster, these worker nodes can be either physical computers (infrastructure such as servers, storage devices, desktop computers, laptops, hyperconverged devices, network devices, etc.) or virtual machines running on physical computers. Each worker node can host multiple pods, and each of the pods can contain one or more containers.The containers can be located on the host machine (the machine on which the containers run, i.e. the worker node) and share resources.

[0018] Tenant clusters 110A, 110B, 110C, .... 110N (also collectively referred to as tenant cluster 110) may be clusters created by a tenant (i.e., a customer) registered with management cluster 102. Tenant clusters 110 may be associated with specific resource subsystems, and each tenant cluster is logically isolated from the other tenant clusters. In some cases, each tenant cluster may be defined for a user / entity of the tenant.

[0019] The management cluster 102 is defined in the control plane to manage the multiple tenant clusters 110. The management cluster 102 may be a server that communicates with and manages the multiple tenant clusters 110 in the container environment 100 via application programming interfaces (APIs). The management cluster 102 is defined in the control plane to support the provisioning, configuration, deployment, and lifecycle of services across a plurality of tenant clusters 110. The management cluster 102 may include an integration service 104 and a service controller 106 to facilitate the provisioning and management of services and / or applications used by workloads in the tenant cluster 110, as described below.

[0020] In some implementations, part or all of the container environment 100 may be provided to a user or user's organization by a provider for use as a service by the user or user's organization in a pay-per-use financial model. For example, the provider may deliver physical hardware-based infrastructure (e.g., servers, storage devices, desktop computers, laptops, hyperconverged devices, networking devices, etc.) to a data center or colocation connected to the user or user's organization (thus forming a private cloud), and the infrastructure may connect (e.g., via a provider-operated gateway, which may also be installed in the data center or colocation) to a provider-operated cloud-based portal, which allows the infrastructure to be controlled and workloads on the infrastructure to be managed.In some cases, the service provider 108 may be the same as or different from the vendor. In some implementations, the management cluster 102 may be located in the gateway or the cloud-based portal.

[0021] The integration service 104, the service provider 108, and the tenant clusters 110 communicate over a communications network, which may be one or more of the following networks: local area network ("LAN"), metropolitan area network ("MAN"), wide area network ("WAN"), proprietary network, public switched telephone network ("PSTN"), wireless application protocol ("WAP") network, Bluetooth network, wireless LAN network, and / or Internet Protocol ("IP") network such as the Internet, an intranet, or an extranet.

[0022] In some examples, service 112 may include a storage service, a database service, a message queue application, an object storage service, a monitoring service, and a logging service. In some cases, service provider 108 may be the same provider as a provider that provides the infrastructure (e.g., hardware-based servers, container orchestration platform, management services, etc.) in container environment 100, or in other words, a first-party provider. In some cases, service provider 108 may be a different provider than the provider that provides this infrastructure, also referred to as a "third-party provider."

[0023] In some examples, the integration service 104 may run on a server or be implemented as software (e.g., a set of executable instructions) in the management cluster 102 to provide information required for provisioning the service 112 in the tenant clusters 110. The integration service 104 may run in a hardware-based management cluster 102. The integration service 104 is communicatively coupled to the service controller 106. The service controller 106 may be a custom controller for provisioning and managing services in the tenant clusters 110 based on custom resources (CRs) defined in the management cluster 102. The service controller 106 may communicate with the integration service 104 to obtain tenant cluster-specific configuration information from the integration service 104. Although in Fig. 1 illustrates the management cluster 102 with the integration service 104 and the service controller 106, the management cluster 102 may also include other container orchestration components (e.g., Kubernetes components), such as an application programming interface (API) server, a scheduler, and a controller for managing workloads across the worker nodes in multiple tenant clusters 110. The integration service 104 in the management cluster 102 communicates with a service endpoint 114 of the service provider 108 to obtain the tenant cluster-specific configuration information. The service endpoint 114 may be a Uniform Resource Locator (URL) provided by the service provider 108. The service endpoint 114 provides various APIs associated with various functions of the service 112. The integration service 104 communicates with the service endpoint 114 of the service provider 108 to obtain the tenant cluster-specific configuration information for provisioning the service 112 using an API associated with the service endpoint 114. Although in Fig. 1 illustrates a single integration service 104 communicating with a single service provider 108 to receive tenant cluster-specific configuration information, in other cases, the management cluster 102 may be configured to support multiple integration services for provisioning multiple services and applications from multiple service providers.

[0024] The management cluster 102 may define an application programming interface (REST API) specification to receive data from the integration service 104 for providing the service 112. The REST API for the integration service 104 may be defined according to the REST API specification provided by the management cluster 102. The integration service 104 may be unique for each service provider 108.

[0025] During operation, if service controller 106 detects that a new tenant cluster has been created by the tenant (e.g., for illustrative purposes, consider tenant cluster 110C as a newly added tenant cluster), service controller 106 calls the REST API associated with integration service 104 of service 112. In some cases where multiple services are to be deployed in the new tenant cluster 110C, service controller 106 may call REST APIs of integration services associated with the multiple services. Integration service 104 communicates with service endpoint 114 of service provider 108 to obtain tenant cluster-specific configuration information. The tenant cluster-specific configuration information is provided by service provider 108 to the new tenant cluster 110C.In one example, the tenant cluster-specific configuration information may include an integration identity (e.g., a universally unique identifier (UUID)) generated for the new tenant cluster 110C by the service provider 108. In another example, the tenant cluster-specific configuration information may include certificates that authenticate the new tenant cluster 110C to the service provider 108. In some cases, the integration service 104 may be configured by the service provider 108 to communicate with a certificate authority (CA) associated with the service provider 108 to obtain the certificates for the new tenant cluster 110C.

[0026] In addition, the integration service 104 generates access data for the service 112 provided in the new tenant cluster 110C, which can be used by the new tenant cluster 110C to communicate with the service provider 108. The integration service 104 provides the tenant cluster-specific configuration information and the generated access data to the service controller 106.

[0027] Fig. 2 is a block diagram of an example management cluster 102 including integration service 104 and service controller 106 according to the disclosed examples. In addition to integration service 104 and service controller 106, management cluster 102 may include a service catalog 202. Service catalog 202 may be provided by service provider 108 according to a specification defined by management cluster 102. The specification includes details required in service catalog 202 for provisioning service 112. In one example, service catalog 108 may be provided as a YAML file by service provider 108. Service catalog 202 is used by service controller 106 to provision and manage service 112 in tenant clusters 110.In some examples, the information in service catalog 202 may include an address of the service endpoint 114 of service provider 108 for deploying service 112, an application manifest, and a tenant cluster namespace name. The application manifest may include information about the location of control cards and control card versions to be used for deploying service 112 in the new tenant cluster 110C. The tenant cluster namespace name is added to service catalog 202 by service controller 106 when the new tenant cluster namespace is created in container environment 100.

[0028] The service catalog 202 may be provided for the service 112 provided by the service provider 108. The service catalog 202 may be provided as input to the service controller 106 to deploy the service 112 in the tenant clusters 110. For the service 112 deployed in the tenant clusters 110, the integration service 104 and the service catalog 202 associated with the service provider 108 in the management cluster 102 may be provided by the service provider 108 as a REST API specification and a YAML specification, respectively. In addition to the service catalog 202, a service manager (not shown) may be present in the management cluster 102. The service manager may be used to track the status of the deployment of the service 112 in the tenant clusters 110.

[0029] In one example, service 112 may be a relational database service (RDS) provided by an external service provider, such as a web service provider, and may be defined by a service catalog 202 in management cluster 102. Service catalog 202 may contain RDS-specific information about namespace metadata, version of service 112, database instance class, database engine, allocated storage space, etc.

[0030] In some cases, service catalog 202 may contain information about the deployment of service 112 provided by service provider 108. In other cases, service catalog 202 may contain information related to multiple services provided by service provider 108. Service controller 106 may use the information contained in service catalog 202, along with the information from the integration service, to deploy and manage the lifecycle of service 112 across multiple tenant clusters 110.

[0031] In Fig. 2, the service controller 106 communicates with the integration service 104 to request and receive information for provisioning and managing the lifecycle of the service 112. When creating the new tenant cluster 110C, the service controller 106 may retrieve the details of the service 112 to be deployed from the service catalog 202. The service catalog 202 may contain the REST API of the integration service 104, the location of the control tables used to deploy the services, and the name of the target cluster namespace in which the service 112 is to be deployed. The name of the target cluster namespace is the name of the cluster namespace of the new tenant cluster 110C. The service controller 106 calls the REST API of the integration service 104 to obtain the configuration information required to deploy the service 112 in the new tenant cluster 110C.In some cases, the service controller 106 calls the REST APIs of multiple integration services to set up and manage multiple services in the new tenant cluster 110C. The configuration information includes tenant cluster-specific configuration information and access permissions. The integration service 104 communicates with the service endpoint 114 of the service provider 108 to obtain tenant cluster-specific configuration information and generates the access credentials for the new tenant cluster 110C.

[0032] In some examples, the integration service 104 may include privileged credentials 204 provided by the service provider 108. The privileged credentials 204 may include API keys, tokens, usernames, passwords, etc., used to communicate with the service provider 108. In some cases, the privileged credentials 204 may be encrypted files stored in the management cluster 102. In other cases, the privileged credentials 204 may be stored as part of the service catalog 202.

[0033] The privileged credentials 204 may be managed by the integration service 104. The integration service 104 in the management cluster 102 may be located between the service provider 108 and the tenant clusters 110 in the container environment 100. In Kubernetes, for example, the privileged credentials 204 may be objects that store restricted data in a YAML (or JSON) file in the management cluster 102 or in the service catalog 202. Because the privileged credentials 204 are stored in the management cluster 102 and not in individual tenant clusters 110, managing the privileged credentials 204, including key rotation or revocation, becomes easier.

[0034] In some examples, the integration service 104 may be implemented as software (e.g., a set of executable instructions) that can be executed by a processor 206. The processor 206 may execute the set of instructions stored in a non-transferable machine-readable medium 208. The processor 206 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any devices that process signals based on operating instructions. The machine-readable medium 208 may include any non-transitory computer-readable medium, such as volatile memory (e.g., RAM) and / or non-volatile storage (e.g., EPROM, flash memory, a hard disk drive, etc.). The term "non-transitory" does not include the transient transmission of signals.

[0035] Processor 206 may be configured to execute instructions 210 and 212 (e.g., programming or software code) stored on machine-readable medium 208 to perform the functions of integration service 104. Instructions 210, when executed by processor 206, cause integration service 104 to submit a request to deploy service 112 in a new tenant cluster, e.g., tenant cluster 110C. In some examples, integration service 104 may be prompted to submit the request upon creation of new tenant cluster 110C. The request to deploy service 112 may be communicated to service endpoint 114 of service provider 108.The integration service 104 may communicate with the service endpoint 114 of the service provider 108 using the privileged credentials 204 to request the tenant cluster-specific configuration information. Although the same version of the service 112 may be deployed across the tenant clusters 110C, the tenant cluster-specific configuration information may be different for each tenant cluster to distinguish the data received from the tenant clusters 110C. The integration service 104 may submit a request to deploy the service 112 in the new tenant cluster 110C. The request may include information specific to the new tenant cluster 110C, such as the name of the tenant cluster namespace and the number of containers running in the tenant cluster.The integration service 104 receives the tenant cluster-specific configuration information from the service provider 108 via the service endpoint 114. The tenant cluster-specific configuration information is stored at both the service provider 108 and the tenant clusters 110. In one example, the tenant cluster-specific configuration information may include an integration identity for the new tenant cluster 110C. In another example, the tenant cluster-specific configuration may include certificates that authenticate the tenant clusters to the service provider 108.

[0036] Instructions 212 executed by processor 206 cause integration service 104 to generate credentials for the new tenant cluster 110C. The credentials can be used by the new tenant to communicate with the service provider. Integration service 104 generates the credentials and provides them to service controller 106, which provides service 112 in the new tenant cluster 110C. The credentials are used by the new tenant cluster 110C to communicate with service provider 108. The credentials can include Identity and Access Management (IAM) information created for the new tenant cluster 110C. In contrast to operator-based service provisioning, where all tenant clusters use the credentials provided by service provider 108, management cluster 102 can manage credentials for tenant clusters individually.

[0037] The access data and the tenant cluster-specific configuration information are transmitted from the integration service 104 to the service controller 106. The service controller 106 can use the tenant cluster-specific configuration information, the access authorizations, and the information associated with the service provider 108 in the service catalog 202 to provide the service 112 in the new tenant cluster 110C. Although Fig. 2 shows two instructions 210 and 212, multiple instructions may be stored in the machine-readable medium 208 and executed by the processor 206 to perform other functions of the integration service 104.

[0038] The service controller 106 implements and manages the lifecycle of the service 112 in the tenant clusters 110 using the service catalog 202 of the service provider 108, the tenant cluster-specific configuration information, and the access permissions provided by the integration service 104. This type of deployment allows the management cluster 102 to deploy, track, and update the service 112 across multiple tenant clusters 110. For example, if an update to the service 112 occurs (e.g., a new version of the service 112), the service controller 106 can automatically update the service 112 across all tenant clusters 110.

[0039] The Fig. 3 and Fig. 4 are flowcharts illustrating various example methods. In some embodiments, one or more blocks of the methods may be performed substantially concurrently or in a different order than illustrated. In some embodiments, a method may include more or fewer blocks than illustrated. In some embodiments, one or more blocks of a method may be continuous and / or repeating at certain times. In some embodiments, blocks of the methods may be combined.

[0040] Fig. 3 is a flowchart illustrating a method 300 including operations performed by an integration service to enable dynamic provisioning of a service in a new tenant cluster, in accordance with disclosed examples. Fig. The method 300 illustrated in Figure 3 may be implemented in the form of executable instructions stored on a machine-readable medium and executed by the processor, such as the machine-readable medium 208 and the processor 206, as shown in Fig. 2. The method 300 can be implemented by the integration service 104 of the Fig. 1 and Fig. 2 to enable the provision of service 112 in the new tenant cluster 110C. Fig. 3 is used in conjunction with Fig. 1 and Fig. 2 explained.

[0041] In block 302, the integration service 104 may submit a request to deploy the service 112 in the new tenant cluster 110C. The request to deploy the service 112 may be submitted in response to the creation of a new tenant cluster 110 by the service controller 106. The request is submitted to the service endpoint 114 of the service provider 108. Service providers wishing to provide services to the tenant clusters 110 may register and deploy their integration services in the management cluster 102. The REST API of the integration services may be specified according to the API specification defined by the management cluster 102. The REST API of the integration service 104 of a service 112 may be stored in the service catalog 202 or in the memory of the management cluster 102.

[0042] At block 304, the integration service 104 may receive the tenant cluster-specific configuration information from the service endpoint 114 in response to the request. In some cases, the tenant cluster-specific configuration information may include an integration identity for the new tenant cluster 110C. Further, the new tenant cluster 110C may be registered with the service provider 108 using the tenant cluster-specific configuration information of the new tenant cluster 110C and the version of the deployed service. In some other cases, the tenant cluster-specific configuration may include certificates that authenticate the new tenant cluster to the service provider. The tenant cluster-specific configuration information may be part of the configuration information used to deploy the service 112 in the new tenant cluster 110C.

[0043] In block 306, the integration service 104 generates credentials for the new tenant cluster 110C. The credentials may be used to configure the service in the new tenant cluster 110C to communicate with the service provider 108. In one example, the credentials may include the IAM information, such as secrets, usernames, and access keys, that enable the new tenant cluster 110C to connect to the service provider 108. The integration service 104 may be responsible for creating and managing the lifecycle of the credentials created for the new tenant cluster 110C.

[0044] At block 308, the integration service 104 may pass the credentials and tenant cluster-specific configuration information to the service controller 106 to provision the service 112 in the new tenant cluster 110C. Once the service 112 is provisioned, the new tenant cluster 110C may communicate with the service provider 108. If the service 112 is a monitoring service provided by a third-party provider, an endpoint for metrics collection and automatic discovery may be present in the new tenant cluster 110C.

[0045] Because the integration service 104 dynamically provides the tenant cluster-specific configuration information and credentials to the service controller 106, provisioning and managing the service 112 within the tenant cluster becomes easier. For example, upon a change to the service catalog 202 (updated by the service provider 108 or by a user with the privileged credentials), the service controller 106 can call the integration service 104 to dynamically redeploy and / or update the service 112 within the tenant cluster 110. Because the integration service 104 stores both the tenant cluster-specific configuration information and credentials for each tenant cluster, any update or redeployment can be performed using the tenant cluster-specific configuration information and credentials.

[0046] Fig. 4 is a flowchart illustrating a method 400 including operations performed by a service controller for provisioning a service in a new tenant cluster according to the disclosed examples. Fig. The method 400 illustrated in Figure 4 may be implemented in the form of executable instructions stored on a machine-readable medium and executed by a processor. For example, the method 400 may be executed by the service controller 106 of Fig. 1 to enable the provision of service 112 in the new tenant cluster 110C. Fig. 4 is used in conjunction with Fig. 1 and Fig. 2 explained.

[0047] At block 402, the service controller 106 may create an object in the management cluster 102 to track a provisioning status of the service 112 in the new tenant cluster 110C. The object is created by the service controller 106 upon creation of a new tenant cluster 110C. In some cases, the service controller 106 may create multiple objects corresponding to multiple services provisioned in the new tenant cluster 110C. The objects created in the management cluster 102 are updated based on changes in tenant clusters 110 or changes in the service catalogs in the management cluster 102.

[0048] In addition to creating objects for tracking, service controller 106 may also retrieve information required to deploy service 112 in the new tenant cluster 110C. For example, service controller 106 may retrieve Helm charts used to deploy service 112 in the new tenant cluster 110C.

[0049] In block 404, the service controller 106 calls the REST API of the integration service 104 associated with the service 112 to be deployed. The integration service 104 communicates with the service endpoint 114 that supports the service 112 provided by the service provider 108. In one example, the service controller 106 calls the REST API associated with the integration service 104 to obtain the tenant cluster-specific configuration information and credentials for deploying the service 112 in the new tenant cluster 110C. In some cases where multiple service catalogs associated with multiple services exist in the management cluster 102, the service controller 106 may call REST APIs of integration services corresponding to the multiple services to obtain tenant-specific configuration information for the multiple services to be deployed.

[0050] In block 406, the service controller 106 requests and receives the tenant cluster-specific configuration information along with the credentials from the integration service 104. The service controller 106's call to the REST API associated with the service's integration service 104 for the tenant cluster-specific configuration information and the credentials and the receipt of the tenant cluster-specific configuration information and the credentials results in the dynamic provisioning of the service 112 in a new tenant cluster 110C.

[0051] In block 408, the service controller 106 deploys the service in the new tenant cluster 110C using the information present in the service catalog 202 and the information obtained from the integration service 104. The service controller 106 deploys the service 112 in the new tenant cluster 110C. After deployment, the service controller 106 may manage the lifecycle of the service 112 in the new tenant cluster 110C. For example, if the use of the service 112 is discontinued and the service catalog 202 associated with the service 112 may be deleted, the service controller 106 may detect the deletion of the service catalog 202 and delete the service 112 from the tenant clusters 110. In another example, in cases where there are changes in or to the version of the service 112 deployed in the tenant clusters 110, the service controller 106 may update and / or redeploy the service 112 in the tenant clusters 110.

[0052] The service controller 106 may be configured to monitor and detect changes in the service catalog 202 and perform the update and / or rebalancing of the service 112. The service controller 106 may call the REST API of the integration service 104 to perform the update and / or rebalancing of the service 112. The management cluster 102 with the integration service 104 and the service catalog 202 enables the service controller 106 to manage the lifecycle of the service 112 across multiple tenant clusters 110.

[0053] Fig. 5 is a block diagram showing a processor 502 coupled to a machine-readable medium 504 having executable instructions stored thereon for dynamically providing information for provisioning the service 112 to tenant clusters 110 according to the disclosed examples. The machine-readable medium 504 may be non-transitory and is alternatively referred to as a non-transitory machine-readable medium 504. In some examples, the machine-readable medium 504 may be accessed by the processor 502. As described in detail herein, the machine-readable medium 504 may be encoded with executable instructions 506 and 508 for dynamically providing the information for provisioning the service 112. Although not shown, in some examples, the machine-readable medium 504 may be encoded with certain additional executable instructions to perform operations in one or more blocks in the Fig. 3 and / or any other operations performed by the integration service 104, without limiting the scope of the present disclosure. The processor 502 and the machine-readable medium may be provided to the processor 206 and the machine-readable medium 208, respectively, as shown in Fig. 2 described, be similar.

[0054] In some examples, processor 502 may retrieve, decode, and execute instructions 506 and 508 stored on machine-readable medium 504 to dynamically provision the information for provisioning a service 112 in a new tenant cluster 110C. In certain examples, alternatively or in addition to retrieving and executing instructions 506 and 508, processor 502 may include at least one integrated circuit, other control logic, other electronic circuitry, or combinations thereof to perform the functionalities of integration service 104.

[0055] Instructions 506, when executed by processor 502, may cause integration service 104 to send a request to service endpoint 114 of service provider 108 to obtain tenant cluster-specific configuration information. Integration service 104 may transmit a request to provision service 112 in the new tenant cluster 110C using service endpoint 114 associated with service provider 108 and receive the tenant cluster-specific configuration information from service provider 108. Furthermore, instructions 508, when executed by processor 502, may cause integration service 104 to generate access credentials for the new tenant cluster 110C.The access permissions and tenant cluster-specific configuration information generated by the integration service 104 may be used by the service controller 106 during the provisioning of the service 112 according to an application manifest.

[0056] Fig. 6 is a block diagram illustrating a processor 602 coupled to a machine-readable medium 604 storing executable instructions for provisioning the service 112 in the new tenant cluster 110C according to the disclosed examples. The machine-readable medium 604 may be non-transitory and is alternatively referred to as a non-transitory machine-readable medium 604. In some examples, the machine-readable medium 604 may be accessed by the processor 602. As described in detail herein, the machine-readable medium 604 may be encoded with executable instructions 606, 608, 610, and 612 (hereinafter collectively referred to as instructions 606-612) to deploy the service 112 in the new tenant cluster 110C using the tenant cluster-specific configuration information provided by the integration service 104.Although not shown, in some examples, machine-readable medium 604 may be encoded with certain additional functions to perform operations in one or more blocks in the format described in . Fig. 4 and / or to perform other operations performed by the service controller 106, without limiting the scope of the present disclosure.

[0057] In some examples, processor 602 may retrieve, decode, and execute instructions 606-610 stored on machine-readable medium 604 to provide service 112 in the new tenant cluster 110C. In certain examples, alternatively or in addition to retrieving and executing instructions 606-610, processor 602 may include at least one integrated circuit, other control logic, other electronic circuitry, or combinations thereof to perform the functionalities of service controller 106.

[0058] Instructions 606, when executed by processor 602, may cause service controller 106 to create an object in management cluster 102 to track a provisioning status of a new tenant cluster in management cluster 102. The object is created by service controller 106 upon the tenant's creation of a new tenant cluster 110C. Service controller 106 may create multiple objects corresponding to multiple services provisioned in the new tenant cluster 110C. The objects may be used to determine whether or not the service is provisioned for a tenant cluster. Additionally, instructions 608, when executed by processor 602, may cause service controller 106 to call the REST API of integration service 104 associated with service 112 being provisioned.Instructions 610, when executed by processor 602, may cause service controller 106 to request and receive tenant cluster-specific configuration information and access permissions from integration service 104. Further, instructions 612, when executed, may cause service controller 106 to provision service 112 in new tenant cluster 110C using service catalog 202 associated with service 112, tenant cluster-specific configuration information, and access permissions.

[0059] Although specific implementations have been shown and described above, various changes in form and details may be made. For example, some features and / or functions described with respect to one implementation and / or process may be transferred to other implementations. In other words, processes, features, components, and / or properties described with respect to one implementation may also be useful in other implementations. Furthermore, it should be understood that the systems and methods described herein may include various combinations and / or subcombinations of the components and / or features of the various implementations described.

[0060] In the foregoing description, numerous details are set forth to facilitate understanding of the subject matter disclosed herein. However, implementations may be made without some or all of these details. Other implementations may include modifications, combinations, and variations of the details described above. The following claims are intended to cover such modifications and variations.

Claims

[1] Procedure comprising: Receiving, from a service controller (106), at an integration service (104) executing in a hardware-based management cluster (102), an indication to create a new tenant cluster (110) in a container environment (100); in response to the indication to create the new tenant cluster (110), transmitting (302), by the integration service (104) to a service endpoint (114) of a service provider (108), a request to provide a service (112) associated with the service provider (108) to the new tenant cluster (110); in response to the request, receiving (304) tenant cluster-specific configuration information from the service provider (108) by the integration service (104), wherein the service (112) is registered with the service provider (108) using the tenant cluster-specific configuration information; Generating (306) access authorizations for the new tenant cluster (110) by the integration service (104); and Providing (308) the tenant cluster-specific configuration information and access permissions for the service controller (106) by the integration service (104); and Provisioning and managing (400), by the service controller (106), the service at the new tenant cluster (110) using the tenant cluster-specific configuration information, the access permissions, and a service catalog (202) associated with the service (112) at the management cluster (102), wherein the service catalog (202) includes an application manifest containing information regarding an associated set of resources to be used for provisioning the service (112) in the new tenant cluster (110), and wherein the service (112) in the new tenant cluster (110) is to use the access permissions from the integration service (104) received at the service controller (106) to communicate with the service provider (108). [2] The method of claim 1, wherein the service catalog (202) is provided by the service provider (108) and wherein the service catalog (202) is provided according to an application programming interface specification, API specification, provided by the management cluster (102). [3] The method of claim 1, wherein the service catalog (202) stores an address of the service endpoint (114) of the service provider (108) and a tenant cluster namespace name for providing the service (112). [4] The method of claim 1, further comprising: Detecting a change in the service catalog (202) by the service controller (106); and The service controller (106) updates the service (112) in the new tenant cluster (110) according to the change in the service catalog (202). [5] The method of claim 1, further comprising receiving a Representational State Transfer (REST) application programming interface (API) call at the integration service (104) from the service controller (106) requesting the tenant cluster-specific configuration information for deployment of the service (112) in the new tenant cluster (110), wherein a REST API associated with the integration service (104) is called by the service controller (106) in response to the creation of the new tenant cluster (110). [6] The method of claim 5, wherein the REST API associated with the integration service (104) is implemented by the service provider (108) according to the API specification provided by the management cluster (102) and is deployed in the management cluster (102) is provided. [7] The method of claim 1, further comprising: Receiving, by the integration service (104), privileged credentials (204) associated with the service provider (108), wherein the privileged credentials (204) are stored in the management cluster (102); and Use of the privileged credentials (204) by the integration service (104) to communicate with the service provider (108). [8] The method of claim 1, further comprising tracking, by the management cluster (102), a status of provisioning of the service (112) at a plurality of tenant clusters (110), wherein the new tenant cluster (110) belongs to the plurality of tenant clusters (110). [9] A system comprising a management cluster (102) comprising an integration service (104) and a service controller (106), wherein the integration service (104) is configured to: receive from the service controller (106) an indication to create a new tenant cluster (110) in a container environment (100); in response to the indication of the creation of the new tenant cluster (110), transmit from the integration service (104) to a service endpoint (114) of a service provider (108) a request to provide a service (112) associated with the service provider (108) at the new tenant cluster (110); in response to the request to receive tenant cluster-specific configuration information from the service provider (108) at the integration service (104); and to generate access authorizations for the new tenant cluster (110), wherein the new tenant cluster (110) belongs to a plurality of tenant clusters (110); and from the integration service (104) to the service controller (106) to provide the tenant cluster-specific configuration information and the access authorizations, wherein the service controller (106) is designed to: Deploying the service (112) in the new tenant cluster (110) using the tenant cluster-specific configuration information, the access authorizations, and a service catalog associated with the service (112) in the management cluster (102), wherein the service catalog (102) includes an application manifest containing information regarding an associated set of resources to be used for deploying the service (112) in the new tenant cluster (110), and wherein the service (112) in the new tenant cluster (110) is to use the access authorizations from the integration service (104) received at the service controller (106) to communicate with the service provider (108); and Manage a lifecycle of the service (112) in the new tenant cluster (110). [10] The system of claim 9, wherein the service catalog (202) is provided by the service provider (108), and wherein the service catalog (202) is provided according to an application programming interface specification, API specification, provided by the management cluster (102). [11] The system of claim 9, wherein the service catalog (202) stores an address of the service endpoint (114) and a tenant cluster namespace name for providing the service (112). [12] The system of claim 9, wherein the service controller (106) is to: to detect a change in the service catalogue (202); and update the service (112) in the new tenant cluster (110) according to the change in the service catalog (202). [13] The system of claim 9, wherein the integration service (104) is to: Receiving, by the integration service (104), privileged credentials (204) associated with the service provider (108), wherein the privileged credentials (204) are stored in the management cluster (102); and Use of the privileged credentials (204) by the integration service (104) to communicate with the service provider (108). [14] The system of claim 9, wherein the service controller (106) has the task of: perform a Representational State Transfer (REST) application programming interface call, API call to the integration service (104) when creating the new tenant cluster (110); and receive the tenant cluster-specific configuration information and access permissions from the integration service (104) in response to the REST API call. [15] The system of claim 14, wherein the REST API associated with the integration service (104) is implemented by the service provider (108) and provided in the management cluster (102) according to the API specification defined by the management cluster (102). [16] The system of claim 9, wherein the management cluster (102) is to track a status of the provision of the service (112) in the plurality of tenant clusters (110). [17] A non-transitory machine-readable medium (208; 504) storing instructions that, when executed, cause a management cluster (102) to: receive an indication to create a new tenant cluster (110) in a container environment (100) from a service controller (106) at an integration service (104) executing in the management cluster (102); in response to the indication to create the new tenant cluster (110), transmit from the integration service (104) to a service endpoint (114) of a service provider (108) a request for provision of a service (112) at the new tenant cluster (110) associated with the service provider (108) at the new tenant cluster (110); in response to the request, at the integration service (104) to receive tenant cluster-specific configuration information from the service provider (108) via the service endpoint (114); to generate access authorizations for the new tenant cluster (110) at the integration service (104); provide the tenant cluster-specific configuration information from the integration service (104) to the service controller (106); and by the service controller (106), to provide and manage the service (112) in the new tenant cluster (110) using the tenant cluster-specific configuration information, the access authorizations, and a service catalog (202) associated with the service in the management cluster (102), wherein the service catalog (202) comprises an application manifest containing information regarding an associated set of resources to be used for providing the service (112) in the new tenant cluster (110), and wherein the service (112) in the new tenant cluster (110) is to use the access authorizations from the integration service (104) received at the service controller (106) to communicate with the service provider (108). [18] The non-transitory machine-readable medium (208; 504) of claim 17, wherein the service catalog (202) is provided by the service provider (108), and wherein the service catalog (202) is provided according to an application programming interface specification, API specification, provided by the management cluster (102). [19] The non-transitory machine-readable medium (208; 504) of claim 17, wherein the service catalog (202) stores an address of the service endpoint (114) and a tenant cluster namespace name for provisioning the service (112) in the new tenant cluster (110). [20] The non-transitory machine-readable medium (208; 504) of claim 17, wherein the instructions, when executed, cause the management cluster (102) to: receive, at the integration service (104), a Representational State Transfer, REST Application Programming Interface call, API call from the service controller (106) requesting the tenant cluster-specific configuration information and the access permissions for provisioning the service (112) in the new tenant cluster (110). [21] The method of claim 1, wherein the application manifest further includes at least one of the following information: a location of the information regarding the associated set of resources to be used for provisioning the service (112) in the new tenant cluster (110), or a version of the information regarding the associated set of resources to be used for provisioning the service (112) in the new tenant cluster (110). [22] The method of claim 21, wherein the application manifest includes a location of a control card or a version of the control card to be used for provisioning the service (112) in the new tenant cluster (110)

Images