Do not create services static using Kubernetes API

[simonswine]

Kube-Lego currently creates all it's required services. We should no longer do that.

The only valid dynamic service creation is for multi-namespace watches on GCE. We should create the static services using helm/charts

[xeor]

I have been debugging why my kube-lego setup didn't work. It turned out that kube-lego didn't create the required service automatic (as it sais it should).

I'm using rbac with the rule from https://github.com/kubernetes/ingress/issues/575#issuecomment-292781303, including create permission to service. There was no errors, nor any services to be seen.

Based on https://github.com/jetstack/kube-lego/blob/master/pkg/service/service.go#L97, I created a service manually, and everything started to work.

I don't see any reason why this service had to be added magically like this. It was confusing to debug. Specially when you are new to kubernetes. Glad to see this issue addressing this!

The service:

apiVersion: v1
kind: Service
metadata:
  name: kube-lego-nginx
  namespace: kube-system
  annotations:
    kubelego.AnnotationKubeLegoManaged: "true"
spec:
  type: ClusterIP
  ports:
    - port: 8080
      targetPort: 8080
      protocol: "TCP"
  selector:
    app: kube-lego

[bvoss]

Is it correct, that this will also solve #68, because I see a selector here?

[munnerz]

The only valid dynamic service creation is for multi-namespace watches on GCE. We should create the static services using helm/charts

So this is correct, provided that nginx is also configured to watch all namespaces. If a user specifies the --watch-namespace option, the kube-lego pod will also need to be running in the target namespace, as otherwise the Ingress resource won't be added to nginx's rules.

I think we should make a decision here on how kube-lego should operate:

1. we always create dynamic services in the target namespace, and manually manage the endpoint resources for them (akin to the current GCLB implementation)

   • This actually reduces the complexity of all implementations - aside from maybe the format for the path field, it would allow us to remove the two differing ingress controller implementations (GCE & nginx). This theoretically should allow us to support all ingress providers in one go.

2. we require that kube-lego is running in the target namespace iff the user has configured their ingress to watch just one namespace.

   • My concern here is that it's more complicated for users, as the way kube-lego should be deployed varies depending on how their ingress controller(s) deployed.

What issues do you see with (1) here? Personally, I'd prefer to err on the side of simplicity, and this seems to be a good step towards supporting the goal of getting rid of the 'provider' concept from kube-lego altogether.