Open simonswine opened 7 years ago
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
Is it correct, that this will also solve #68, because I see a selector here?
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:
we always create dynamic services in the target namespace, and manually manage the endpoint resources for them (akin to the current GCLB implementation)
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.we require that kube-lego is running in the target namespace iff the user has configured their ingress to watch just one namespace.
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.
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