It sounds like you are getting the default chart from helm, which is slightly different than the instructions you will find on the kube-lego Github. The helm chart uses Let's Encrypt's staging server by default. Also if you are not familiar with helm it can be quite tricky to undo the remnants that the kube-lego helm chart leaves behind, specially as tiller likes to keep the old installation history.

Here's a brief overview of setting up Gitlab Auto Devops with Google Kubernetes Engine. I should mention that you can skip up to step 13 if you use the Gitlab GKE wizard introduced in 10.1, but it won't really tell you what's happening or how to debug when things go wrong, also the wizard is a one way process.

1. In Gitlab under integrations you'll find a Kubernetes integration button
   1. You can also find this under CI/ CD -> cluster
2. The API URL is the endpoint ip prefixed by https://
3. The "CA Certificate" it asks for is service account CA, not the same as the cluster CA
4. To connect to gitlab you'll need to create a k8s service account and get the CA and token for it. Do so by using gcloud to authenticate kubectl. GCE makes it easy by doing this for you through the "connect" button in k8s engine
   1. https://kubernetes.io/docs/admin/authentication/#service-account-tokens
5. All commands must be run with a custom namespace, it will not work with default
6. kubectl create namespace (NS)
7. kubectl create serviceaccount (NAME) --namespace=(NS)
   1. This will create two tokens in your configs/secrets, a default one and you service account one
8. kubectl get -o json serviceaccounts (NAME) --namespace=(NS)
9. kubectl get -o json secret (secrets-name-on-prev-result) --namespace=(NS)
10. To decode the base64 values echo them to base64 -d, for example
    1. Echo mybase64stringasdfasdf= | base64 -d
11. To install helm, use the installation script method
    1. https://docs.helm.sh/using_helm/#from-script
12. Init helm and update it's repo
    1. helm init
    2. helm repo update
13. Install nginx-ingress, its ingress with nginx. You could use the Google load balancer as well, but it's not as portable.
    1. helm install stable/nginx-ingress
14. Make a wild card subdomain with an A record pointing to the IP address set up by ingress
15. In Gitlab, Make auto devops use your newly setup wildcard subdomain, if its "*.x" on "me.com" you should enter "x.me.com" in the auto devops settings.
16. Now install kube lego
    1. helm install --name lego-main \ --set config.LEGO_EMAIL=CHANGEMENOW@example.com \ --set config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory \ stable/kube-lego
       1. Helm installations are called charts, equal to a k8s container installation
       2. If you wish to delete a release, you must purge it, otherwise tiller will keep a history, with:
          1. helm delete --purge my-release-name
       3. You can find the release names and their associated chart in
          1. helm list

Troubleshooting

• Order doesn't seem to matter too much. attaching to a pod can be a useful way of debugging problems, such as a bad email address. The Ideal order however is probably, nginx-ingress, then kube-lego, then gitlab. I did make it work with gitlab first, then nginx-ingress, then kube-lego.

I heard from Sid that they are working to make this easier... let's hope so.