hashicorp / consul-k8s

First-class support for Consul Service Mesh on Kubernetes
https://www.consul.io/docs/k8s
Mozilla Public License 2.0
669 stars 323 forks source link

Inject Consul Connect for a Kubernetes deployment without exposing ports #588

Closed vincent-163 closed 3 years ago

vincent-163 commented 3 years ago

According to https://www.consul.io/docs/k8s/connect:

Note: As of consul-k8s v0.26.0 and Consul Helm v0.32.0, having a Kubernetes Service is required to run services on the Consul 
Service Mesh.

I'm not sure about the reasoning behind this. I'm running a bunch of worker containers that needs to connect to their masters but they don't expose any port on their own. Writing a Kubernetes Service requires the worker containers to expose a port (which they don't have), and prevents the workers from connecting to the master via Consul Connect at all. What should I do in such a case?

david-yu commented 3 years ago

Hi @vincent-163. We made an architectural decision to now sync endpoints against the Kube API server as opposed to registered and de-registering services via an init-container. This aligns with how we'd want to cleanly manage Kubernetes service instances over time, as endpoints are managed by the Kube API Server for Services.

We did anticipate that folks would want to deploy workloads onto the mesh that did not expose a port, so we wrote up a bit of documentation that describes this use case Headless Services. In this case, you would need to set DialedDirectly to true for the master service. You could also create a service without a clusterIP for the worker services. A port is required, however, it should not be exposed in the case of a headless service when clusterIP is set to None (see Service Core API).

apiVersion: v1
kind: Service
metadata:
  name: static-client
spec:
  selector:
    app: static-client
  clusterIP: None 
  ports:
    - port: 80
vincent-163 commented 3 years ago

Thanks for the reply! It was very helpful.

Phylu commented 3 years ago

@david-yu Thanks for the information. We have a use-case, where this is – unfortunately – not easily possible.

We want to deploy external (not developed by us) applications into a Kubernetes cluster that is using Consul. We cannot add these headless services in a manageable way as we would have to either adjust the external helm charts or add the services on top of the helm charts which is likely to cause errors.

Are there any plans to provide a way for this in the future?