0

I wanted to know if an application which is being managed by Kubernetes, like Jupiter would work if some elements of it like the CIRCE dispatcher are used without a container.

If yes, then broadly what kind of changes are required to be made? Also, are there any resources from where I can read up on this? Thanks !!

SHIVANI SINGH
  • 25
  • 5
  • What do you mean by *"without the container"* ? Do you want to run this particular component outside your **kubernetes cluster** ? – mario Feb 06 '20 at 12:23
  • Running a database outside the cluster is fairly routine, and there's not really anything special about it, just set your application database configuration to point at it. Is there a specific problem you're encountering? – David Maze Feb 06 '20 at 12:35

1 Answers1

0

Yes, you can integrate any external component (deployed outside your kuberntes cluster) with components running within the cluster, so that it becomes an integral part of your application architecture.

You can achieve it with so-called service without selector.

Its most common use cases are described in kubernetes documentation but it can be used to integrate practically any external component with your kubernetes cluster:

Services most commonly abstract access to Kubernetes Pods, but they can also abstract other kinds of backends. For example:

  • You want to have an external database cluster in production, but in your test environment you use your own databases.
  • You want to point your Service to a Service in a different Namespace or on another cluster.
  • You are migrating a workload to Kubernetes. Whilst evaluating the approach, you run only a proportion of your backends in Kubernetes.

Below you have example how it may look like:

In any of these scenarios you can define a Service without a Pod selector. For example:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Because this Service has no selector, the corresponding Endpoint object is not created automatically. You can manually map the Service to the network address and port where it’s running, by adding an Endpoint object manually:

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

Accessing a Service without a selector works the same as if it had a selector. In the example above, traffic is routed to the single endpoint defined in the YAML: 192.0.2.42:9376 (TCP).

Also take a look at ExternalName which is a special kind of Service without a selector:

An ExternalName Service is a special case of Service that does not have selectors and uses DNS names instead. For more information, see the ExternalName section later in this document.

You can also read this two articles which basically explain the same thing:

Kubernetes best practices: mapping external services

Kubernetes Access External Services

Please let me know if it helps. If not, please explain in more detail the desired state you want to achieve.

mario
  • 9,858
  • 1
  • 26
  • 42