Declarative streamlining of dependency consumption
According to some embodiments, methods and systems may be associated with a consuming cluster where custom dependencies are exposed (e.g., a Kubernetes cluster deploying a workload) and an external service application programming interface where the custom dependencies are mapped. A dependency controller platform may be located between the consuming cluster and the external service application programming interface. Moreover, a computer processor of the dependency controller platform may receive information about an exposed consuming cluster custom dependency. The dependent controller platform may then map the received information to the appropriate external service application programming interface to declaratively streamline dependency consumption. Note that the external service application programming interface might be setup in the same Kubernetes cluster, in a workload hosted on a different Kubernetes cluster, as a managed service provided natively by a cloud provider, as an external cloud-native service (e.g., a database service), etc.
1. A container-orchestration system, comprising:
a consuming Kubernetes cluster, deploying a workload, where custom dependencies are exposed;
a first external service Application Programming Interface (“API”) where custom dependencies are mapped, setup in the same consuming Kubernetes cluster;
a second external service API where custom dependencies are mapped, setup in a workload hosted on a Kubernetes cluster other than the consuming Kubernetes cluster;
a third external service API where custom dependencies are mapped, setup as a managed service provided natively by a cloud provider;
a fourth external service API where custom dependencies are mapped, setup as an external cloud-native service; and
a dependency controller platform between the consuming cluster and the external service APIs, including:
an API definition component,
an API runtime component,
a metadata component,
a computer processor, and
computer memory, coupled to the computer processor, storing instructions that, when executed by the computer processor cause the processor to:
(i) receive information about an exposed consuming cluster custom dependency, and
(ii) perform two-way mapping to map the received information to an appropriate external service API to declaratively streamline dependency consumption,
wherein the dependency controller platform accepts the following inputs:
an open API definition of at least one external service's lifecycle API,
a definition of Kubernetes custom resources and sub-resources for that external service to act as a Kubernetes API for that external service, and
additional metadata to map actions on the Kubernetes custom resources of the service to the native lifecycle API of that external service.
2. The system of claim 1 , wherein the consuming cluster includes an API server and custom resources.
3. The system of claim 1 , wherein custom resource definitions are used as the Kubernetes API for that external service.
4. The system of claim 1 , wherein a remotely hosted API server extension is used as the Kubernetes API for that external service.
5. The system of claim 1 , wherein a Kubernetes API is hosted in an external Kubernetes cluster and exposed as local Kubernetes custom resources in the consuming cluster.
6. A computer-implemented container-orchestration system method, comprising:
receiving, at a computer processor of a dependency controller platform between a consuming Kubernetes cluster and external service APIs, wherein the dependency controller platform also includes an API definition component, an API runtime component, and a metadata component and receives information about the consuming Kubernetes cluster, deploying a workload, where custom dependencies are exposed;
setting up a first external service Application Programming Interface (“API”) where custom dependencies are mapped, in the same consuming Kubernetes cluster;
setting up a second external service API where custom dependencies are mapped, in a workload hosted on a Kubernetes cluster other than the consuming Kubernetes cluster;
setting up a third external service API where custom dependencies are mapped, setup as a managed service provided natively by a cloud provider;
setting up a fourth external service API where custom dependencies are mapped, setup as an external cloud-native service; and
performing two-way mapping, by the dependency controller platform, to map the received information to an appropriate external service API to declaratively streamline dependency consumption,
wherein the dependency controller platform accepts the following inputs:
an open API definition of at least one external service's lifecycle API,
a definition of Kubernetes custom resources and sub-resources for that external service to act as a Kubernetes API for that external service, and
additional metadata to map actions on the Kubernetes custom resources of the service to the native lifecycle API of that external service.
7. The method of claim 6 , wherein the consuming cluster includes an API server and custom resources.
8. The method of claim 6 , wherein custom resource definitions are used as the Kubernetes API for that external service.
9. The method of claim 6 , wherein a remotely hosted API server extension is used as the Kubernetes API for that external service.
10. The method of claim 6 , wherein a Kubernetes API is hosted in an external Kubernetes cluster and exposed as local Kubernetes custom resources in the consuming cluster.
11. A non-transitory, computer-readable medium storing instructions, that, when executed by a processor, cause the processor to perform a method associated with a container-orchestration system, the method comprising:
receiving, at a computer processor of a dependency controller platform between a consuming Kubernetes cluster and external service APIs, wherein the dependency controller platform also includes an API definition component, an API runtime component, and a metadata component and receives information about the consuming Kubernetes cluster, deploying a workload, where custom dependencies are exposed;
setting up a first external service Application Programming Interface (“API”) where custom dependencies are mapped, in the same consuming Kubernetes cluster;
setting up a second external service API where custom dependencies are mapped, in a workload hosted on a Kubernetes cluster other than the consuming Kubernetes cluster,
setting up a third external service API where custom dependencies are mapped, as a managed service provided natively by a cloud provider;
setting up a fourth external service API where custom dependencies are mapped, setup as an external cloud-native service; and
performing two-way mapping, by the dependency controller platform, to map the received information to an appropriate external service API to declaratively streamline dependency consumption,
wherein the dependency controller platform accepts the following inputs:
an open API definition of at least one external service's lifecycle API,
a definition of Kubernetes custom resources and sub-resources for that external service to act as a Kubernetes API for that external service, and
additional metadata to map actions on the Kubernetes custom resources of the service to the native lifecycle API of that external service.
12. The medium of claim 11 , wherein the consuming Kubernetes cluster includes an API server and custom resources.