Giter VIP home page Giter VIP logo

ingress's Introduction

Caddy Ingress Controller

This is the Kubernetes Ingress Controller for Caddy. It includes functionality for monitoring Ingress resources on a Kubernetes cluster and includes support for providing automatic HTTPS certificates for all hostnames defined in the ingress resources that it is managing.

Prerequisites

  • Helm 3+
  • Kubernetes 1.19+

Setup

In the charts folder, a Helm Chart is provided to make installing the Caddy Ingress Controller on a Kubernetes cluster straightforward. To install the Caddy Ingress Controller adhere to the following steps:

  1. Create a new namespace in your cluster to isolate all Caddy resources.
kubectl create namespace caddy-system
  1. Install the Helm Chart.
helm install \
  --namespace=caddy-system \
  --repo https://caddyserver.github.io/ingress/ \
  --atomic \
  mycaddy \
  caddy-ingress-controller

Or

  1. Generate kubernetes yaml file.
git clone https://github.com/caddyserver/ingress.git
cd ingress

# generate the yaml file
helm template mycaddy ./charts/caddy-ingress-controller \
  --namespace=caddy-system \
  > mycaddy.yaml

# apply the file
kubectl apply -f mycaddy.yaml

This will create a service of type LoadBalancer in the caddy-system namespace on your cluster. You'll want to set any DNS records for accessing this cluster to the external IP address of this LoadBalancer when the external IP is provisioned by your cloud provider.

You can get the external IP address with kubectl get svc -n caddy-system

  1. Alternate installation method: Glasskube

To install the Caddy ingress controller using Glasskube, you can select "caddy-ingress-controller" from the "ClusterPackages" tab in the Glasskube GUI then click "install" or you can run the following command:

glasskube install caddy-ingress-controller

Add an email address in the package configuration section in the UI to enable automatic HTTPS, or run:

glasskube install caddy-ingress-controller --value "[email protected]"

Debugging

To view any logs generated by Caddy or the Ingress Controller you can view the pod logs of the Caddy Ingress Controller.

Get the pod name with:

kubectl get pods -n caddy-system

View the pod logs:

kubectl logs <pod-name> -n caddy-system

Automatic HTTPS

To have automatic HTTPS (not to be confused with On-demand TLS), you simply have to specify your email in the config map. When using Helm chart, you can add --set [email protected] when installing.

On-Demand TLS

On-demand TLS can generate SSL certs on the fly and can be enabled in this controller by setting the onDemandTLS config to true:

helm install ...\
  --set ingressController.config.onDemandTLS=true

You can also specify options for the on-demand config: onDemandRateLimitInterval, onDemandRateLimitBurst and onDemandAsk

Bringing Your Own Certificates

If you would like to disable automatic HTTPS for a specific host and use your own certificates you can create a new TLS secret in Kubernetes and define what certificates to use when serving your application on the ingress resource.

Example:

Create TLS secret mycerts, where ./tls.key and ./tls.crt are valid certificates for test.com.

kubectl create secret tls mycerts --key ./tls.key --cert ./tls.crt
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
  annotations:
    kubernetes.io/ingress.class: caddy
spec:
  rules:
  - host: test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 8080
  tls:
    - secretName: mycerts # use mycerts for host test.com
      hosts:
        - test.com

Contribution

Learn how to start contributing on the Contributing Guidline.

License

Apache License 2.0

ingress's People

Contributors

aarondewes avatar clems71 avatar dannav avatar dependabot[bot] avatar embraser01 avatar fahurox avatar jakepage91 avatar kiura avatar lion7 avatar malthe avatar mavimo avatar merovius avatar mholt avatar nilathedragon avatar rickfoland avatar riker09 avatar simenandre avatar xinayder avatar xinbinhuang avatar youeclipse avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ingress's Issues

To match all hosts, leave the hostname empty - How to replicate this in ingress

According to the docs:

A site defined as * matches only one-label names like "localhost" but not "example.com". To match all hosts, leave the hostname empty.

This is because the relevant RFC (I forget its number right now, but it's mentioned several times on the issues here previously) restricts wildcards in this manner as they pertain to TLS certificates, and this same string value is what Caddy uses in its TLS certificate logic.

hey @mholt @focux do you have any idea about, how we can replicate this feature in kubernetes ingress controller as caddy ingress?
image

i'm catching all the domain of my multi-tendant app using the default backend of the ingress controller like this
image
image
in this scenario how i could omit the hostname as said in the caddy documentation?
Thanks in advance.

update:-
because of the above bottleneck , caddy couldn't server cert for * matching domains (custom domains cnamed to the main domain, which is not configured in the ingress itself)
image

Originally posted by @ThayalanGR in caddyserver/caddy#2895 (comment)

Can't pull ingresscontroller image from GCR

After applying and running the standard
helm template \ --namespace=caddy-system ./kubernetes/helm/caddyingresscontroller/ \ --set autotls=true \ --set email="myemail" | kubectl apply -f -
I am getting an error in kubernetes telling me "Cannot pull image 'gcr.io/danny-239313/ingresscontroller:v0.1.0' from the registry.
Check Pod's events to see more details"

Running a describe pod gives me these results:

Screen Shot 2019-11-08 at 3 28 42 PM

Watching ingresses in non-selected namespace

Hello,

I'd like to ask if it's only my problem (configuration) or what is going on. :D
I'm using these args.

args:
            - -tls
            - [email protected]
            - -namespace=custom-domains

Idk why but caddy-ingress is still trying to renew certificates from other namespaces too.
Every few minutes, it tries to renew certificate for hidden-domain-name and fails.
It's correct that it fails, becase the domain is in different namespace,ingress. The point is, it should not even try, it's not ingress.class=caddy & namespace does not match.

2020/11/05 16:17:59 [INFO] [hidden-domain-name] acme: Obtaining bundled SAN certificate given a CSR
2020/11/05 16:17:59 [INFO] [hidden-domain-name] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/147874382
2020/11/05 16:17:59 [INFO] [hidden-domain-name] acme: use tls-alpn-01 solver
2020/11/05 16:17:59 [INFO] [hidden-domain-name] acme: Trying to solve TLS-ALPN-01
2020/11/05 16:18:00 http: TLS handshake error from 127.0.0.1:43874: EOF
2020/11/05 16:18:05 [INFO] Deactivating auth: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/147874382
2020/11/05 16:18:05 [ERROR] error: one or more domains had a problem:
2020/11/05 16:18:05 [INFO] Unable to deactivate the authorization: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/147874382
[hidden-domain-name] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Incorrect validation certificate for tls-alpn-01 challenge. Requested hidden-domain-name from 157.245.26.58:443. Received 2 certificate(s), first certificate had names "*.dev.reservio.com", url:
 (challenge=tls-alpn-01 remaining=[http-01])
2020/11/05 16:18:07 [INFO] [hidden-domain-name] acme: Obtaining bundled SAN certificate given a CSR
2020/11/05 16:18:08 [INFO] [hidden-domain-name] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/147874479
2020/11/05 16:18:08 [INFO] [hidden-domain-name] acme: Could not find solver for: tls-alpn-01
2020/11/05 16:18:08 [INFO] [hidden-domain-name] acme: use http-01 solver
2020/11/05 16:18:08 [INFO] [hidden-domain-name] acme: Trying to solve HTTP-01
2020/11/05 16:18:14 [INFO] Deactivating auth: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/147874479
2020/11/05 16:18:14 [ERROR] error: one or more domains had a problem:
[hidden-domain-name] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://hidden-domain-name:443/.well-known/acme-challenge/l0toaZKMoCJXqyUM_iu8cxvlfVzGgNDPvU8UomUi2jw [157.245.26.58]: 403, url:
 (challenge=http-01 remaining=[])
2020/11/05 16:18:14 [INFO] Unable to deactivate the authorization: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/147874479
2020/11/05 16:18:16 [ERROR] attempt 3: [hidden-domain-name] Obtain: [hidden-domain-name] error: one or more domains had a problem:
[hidden-domain-name] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://hidden-domain-name:443/.well-known/acme-challenge/l0toaZKMoCJXqyUM_iu8cxvlfVzGgNDPvU8UomUi2jw [157.245.26.58]: 403, url:
 - retrying in 2m0s (3m50.64647515s/720h0m0s elapsed)...

I'm pretty sure the -namespace arg works because without it, it really renews all certificates in all namespaces.
I've removed caddy with whole namespace, so there is nothing from the old install.

Maybe this somehow related, every few minutes caddy-ingress prints this log

time="2020-11-05T16:27:24Z" level=info msg="Synching Ingress resource source addresses"
time="2020-11-05T16:27:24Z" level=info msg="skipping update of Ingress custom-domains/domains-ingress-000 (no change)"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"
time="2020-11-05T16:27:24Z" level=info msg="updating Ingress translations/translations-ingress status from [{10.135.129.148 }] to [{10.135.129.148 }]"

Thank you for any feedback. :)

edit:

After looking into https://github.com/caddyserver/ingress/blob/master/internal/store/store.go#L21
I'm not sure if there should not be .Ingresses(cfg.WatchNamespace) instead of .Ingresses("")

Failed to list *v1.ConfigMap: configmaps is forbidden

Wiped my test box and ran into this today. Wasn't having this issue yesterday. Not convinced this is an issue w/ the templates.

System:
ubuntu 20.04
k3s v1.17.5+k3s1
helm v3.4.1
caddyserver ingress template as of 66c52c6

Failed to list *v1.ConfigMap: configmaps is forbidden: User "system:serviceaccount:caddy-system:caddy-ingress-controller" cannot list resource "configmaps" in API group "" in the namespace "caddy-system"

Wrong email being used when creating account

caddy-ingress-controller logs:

time="2020-12-07T01:59:43Z" level=info msg="New ingress resource detected, updating Caddy config..."
time="2020-12-07T01:59:43Z" level=info msg="Updating caddy config"
{"level":"info","ts":1607306383.1627984,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
W1207 01:59:43.162938       1 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
{"level":"info","ts":1607306383.1638198,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"ingress_server","https_port":443}
{"level":"info","ts":1607306383.163889,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"ingress_server"}
{"level":"info","ts":1607306383.164303,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["darklshoals.com"]}
{"level":"info","ts":1607306383.1646874,"logger":"admin","msg":"stopped previous server"}
2020/12/07 01:59:43 [INFO][cache:0xc00040f950] Started certificate maintenance routine
2020/12/07 01:59:43 [INFO][cache:0xc0005983c0] Stopped certificate maintenance routine
{"level":"info","ts":1607306383.1726327,"msg":"autosaved config","file":"/.config/caddy/autosave.json"}
time="2020-12-07T01:59:43Z" level=info msg="Synching Ingress resource source addresses"
time="2020-12-07T01:59:43Z" level=info msg="updating Ingress default/example status from [] to [{192.168.214.35 }]"
time="2020-12-07T01:59:43Z" level=info msg="Caddy reloaded successfully."
time="2020-12-07T01:59:43Z" level=info msg="Ingress resource update detected, updating Caddy config..."
time="2020-12-07T01:59:43Z" level=info msg="Updating caddy config"
{"level":"info","ts":1607306383.2071025,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
W1207 01:59:43.207261       1 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
{"level":"info","ts":1607306383.208351,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"ingress_server","https_port":443}
{"level":"info","ts":1607306383.208431,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"ingress_server"}
{"level":"info","ts":1607306383.2086308,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["darklshoals.com"]}
{"level":"info","ts":1607306383.2089708,"logger":"admin","msg":"stopped previous server"}
2020/12/07 01:59:43 [INFO][cache:0xc0005999a0] Started certificate maintenance routine
2020/12/07 01:59:43 [INFO][cache:0xc00040f950] Stopped certificate maintenance routine
{"level":"info","ts":1607306383.215013,"msg":"autosaved config","file":"/.config/caddy/autosave.json"}
time="2020-12-07T01:59:43Z" level=info msg="Caddy reloaded successfully."
2020/12/07 01:59:43 [INFO][darklshoals.com] Obtain certificate; acquiring lock...
2020/12/07 01:59:43 [INFO][darklshoals.com] Obtain: Lock acquired; proceeding...
2020/12/07 01:59:43 [INFO][darklshoals.com] Obtain: Releasing lock
2020/12/07 01:59:43 [ERROR] darklshoals.com: obtaining certificate: context canceled
2020/12/07 01:59:43 [INFO][darklshoals.com] Obtain certificate; acquiring lock...
2020/12/07 01:59:43 [INFO][darklshoals.com] Obtain: Lock acquired; proceeding...
2020/12/07 01:59:43 [INFO] acme: Registering account for caddy.ingress--acmeacme-v02.api.letsencrypt.org-directoryusersdefaultdefault.json
2020/12/07 01:59:44 [ERROR] Making new ACME client: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: "caddy.ingress--acmeacme-v02.api.letsencrypt.org-directoryusersdefaultdefault.json" is not a valid e-mail address, url:  (attempt 1/2)
2020/12/07 01:59:46 [INFO] acme: Registering account for caddy.ingress--acmeacme-v02.api.letsencrypt.org-directoryusersdefaultdefault.json
2020/12/07 01:59:46 [ERROR] Making new ACME client: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: "caddy.ingress--acmeacme-v02.api.letsencrypt.org-directoryusersdefaultdefault.json" is not a valid e-mail address, url:  (attempt 2/2)
2020/12/07 01:59:46 [ERROR] attempt 1: [darklshoals.com] Obtain: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: "caddy.ingress--acmeacme-v02.api.letsencrypt.org-directoryusersdefaultdefault.json" is not a valid e-mail address, url:  - retrying in 1m0s (2.999821801s/720h0m0s elapsed)...
time="2020-12-07T01:59:52Z" level=info msg="Synching Ingress resource source addresses"
time="2020-12-07T01:59:52Z" level=info msg="skipping update of Ingress default/example (no change)"
time="2020-12-07T01:59:57Z" level=info msg="Ingress resource deletion detected, updating Caddy config..."
time="2020-12-07T01:59:57Z" level=info msg="Updating caddy config"
{"level":"info","ts":1607306397.1634908,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
W1207 01:59:57.163648       1 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
{"level":"info","ts":1607306397.1648552,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"ingress_server","https_port":443}
{"level":"info","ts":1607306397.1649482,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"ingress_server"}
2020/12/07 01:59:57 [INFO][cache:0xc0005999a0] Stopped certificate maintenance routine
{"level":"info","ts":1607306397.1653795,"msg":"autosaved config","file":"/.config/caddy/autosave.json"}
time="2020-12-07T01:59:57Z" level=info msg="Caddy reloaded successfully."
{"level":"info","ts":1607306397.1655576,"logger":"admin","msg":"stopped previous server"}
2020/12/07 01:59:57 [INFO][cache:0xc0001f5c20] Started certificate maintenance routine
2020/12/07 01:59:57 [INFO][darklshoals.com] Obtain: Releasing lock
2020/12/07 01:59:57 [ERROR] darklshoals.com: obtaining certificate: context canceled
time="2020-12-07T02:00:22Z" level=info msg="Synching Ingress resource source addresses"

My steps to reproduce (with a fresh k8s master node):

  1. Create caddy-system namespace

  2. Install caddy-ingress-controller chart

helm install --namespace=caddy-system --repo https://caddyserver.github.io/ingress/ --atomic --devel --set image.tag=latest mycaddy caddy-ingress-controller
  1. Fix role (append configmap permission)
kubectl get clusterroles caddy-ingress-controller-role -o yaml > caddy-ingress-controller-role.yaml

edit and reconfigure rule:

  - apiGroups:
      - ""
    resources:
      - services
      - pods
      - nodes
      - routes
      - extensions
      - configmaps
    verbs:
      - list
      - get
      - watc

Then apply

kubectl apply -f caddy-ingress-controller-role.yaml
  1. Apply example deployments, services (from this repo)

  2. Apply custom configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: caddy-global-options
  namespace: caddy-system
data:
  acmeCA: https://acme-staging-v02.api.letsencrypt.org/directory
  email: [email protected]
  debug: "false"
  1. Apply ingress with legit domain

In my case:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example
  annotations:
    kubernetes.io/ingress.class: caddy
spec:
  rules:
    - host: darklshoals.com
      http:
        paths:
          - path: /hello1
            backend:
              serviceName: example1
              servicePort: 8080
          - path: /hello2
            backend:
              serviceName: example2
              servicePort: 8080

Caddy plugin support

I'm sorry for the newbie issue here. I'm hoping to include Caddy ingress with a plugin for Vulcain which has been created. See: https://github.com/dunglas/vulcain/blob/master/docs/caddy.md

I'm sure there are many plugins for Caddy which is one of the great things about it - is there an easy way to use this ingress with additional plugins? If so, it'd be great to see some info in the documentation about it and I'd be using this right away. If not, is it a feature worth considering having the ability to add in or have docs about how one may do this (perhaps creating a new Docker image and basing it on the image here with a small example as a starting point?)

Thanks in advance.

Production ready?

Hi! I'm wondering if this ingress is production ready. It looks very nice! Seems like the latest release also isn't a pre-release.

Handle https redirects

The ingress controller listens on :80 and :443. Caddy prevents https redirects if the server is listening on :80 for backwards compatibility purposes.

If https is setup successfully we should handle https redirects in the ingress controller

Diplomas.

In order to combine automatic certificate distribution, please greatly speed up the update of caddy-ingress

Client IP behind loadbalancer

Hello,

I just tested the latest helm chart: https://github.com/caddyserver/ingress/releases/tag/caddy-ingress-controller-0.0.1-rc1. It worked fine!

I was wondering if it would be possible to enable the proxy protocol support for Caddy? Currently, the requests appears to come from the load balancer IP address and that's not good for services that rely on knowing the IP address of the client.

Also, I tested if it worked out of the box and after enabling proxy protocol on Digitalocean kubernetes panel at each request I receive a 400 HTTP status code which means that caddy doesn't support the proxy protocol without configuring it.

Crash on start up

I am unable to get this running, I am using Helm 3.0.2 and Kubernetes 1.16.2

time="2020-01-30T17:05:30Z" level=warning msg="-namespace flag is unset, caddy ingress controller will monitor ingress resources in all namespaces."
W0130 17:05:30.720396       1 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
time="2020-01-30T17:05:30Z" level=info msg="Creating API client for https://10.245.0.1:443"
time="2020-01-30T17:05:30Z" level=info msg="Starting the caddy ingress controller"
time="2020-01-30T17:05:30Z" level=info msg="Exporting metrics on :9090"
2020/01/30 17:05:30.764	INFO	admin	admin endpoint started	{"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xa0 pc=0x1576fce]

goroutine 29 [running]:
k8s.io/client-go/kubernetes.(*Clientset).CoreV1(...)
	/go/pkg/mod/k8s.io/[email protected]/kubernetes/clientset.go:256
github.com/caddyserver/ingress/pkg/storage.(*SecretStorage).List(0xc0003975c0, 0x19c5274, 0x4, 0x1a88f00, 0x1, 0x10, 0x10, 0xc00039ebf0, 0x292ffc0)
	/app/pkg/storage/storage.go:116 +0x4e
github.com/mholt/certmagic.deleteOldOCSPStaples(0x1c73b80, 0xc0003975c0, 0x28, 0x28fb2d0)
	/go/pkg/mod/github.com/mholt/[email protected]/maintain.go:333 +0x63
github.com/mholt/certmagic.CleanStorage(0x1c73b80, 0xc0003975c0, 0x101, 0x44c1ff2520000)
	/go/pkg/mod/github.com/mholt/[email protected]/maintain.go:319 +0xdc
github.com/caddyserver/caddy/v2/modules/caddytls.(*TLS).cleanStorageUnits(0xc0003565a0)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/modules/caddytls/tls.go:296 +0x14d
github.com/caddyserver/caddy/v2/modules/caddytls.(*TLS).keepStorageClean(0xc0003565a0)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/modules/caddytls/tls.go:278 +0xaf
github.com/caddyserver/caddy/v2/modules/caddytls.(*TLS).Start(0xc0003565a0, 0x0, 0x0)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/modules/caddytls/tls.go:170 +0x132
github.com/caddyserver/caddy/v2.run.func4(0xc000303810, 0xc000307d00, 0xc00039bd40)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/caddy.go:384 +0xfa
github.com/caddyserver/caddy/v2.run(0xc000303810, 0x101, 0x0, 0x0)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/caddy.go:400 +0x2d2
github.com/caddyserver/caddy/v2.unsyncedDecodeAndRun(0xc00033ec60, 0x103, 0x120, 0xc00033ec60, 0x103)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/caddy.go:249 +0x97
github.com/caddyserver/caddy/v2.changeConfig(0x19c4d80, 0x4, 0x19c7bfc, 0x7, 0xc00033ea20, 0x103, 0x120, 0xc0002cb801, 0x0, 0x0)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/caddy.go:160 +0x508
github.com/caddyserver/caddy/v2.Load(...)
	/go/pkg/mod/github.com/caddyserver/caddy/[email protected]/caddy.go:99
github.com/caddyserver/ingress/internal/controller.(*CaddyController).reloadCaddy(0xc0002cc8f0, 0xc000056ef8, 0x5859d5)
	/app/internal/controller/controller.go:218 +0xa7
github.com/caddyserver/ingress/internal/controller.(*CaddyController).Run(0xc0002cc8f0, 0xc0000810e0)
	/app/internal/controller/controller.go:127 +0x43
created by main.main
	/app/cmd/caddy/main.go:62 +0x3b2

Charts problem

Is there any problem with the official Charts warehouse? Please check it thoroughly.

Spinning startup

Hiya,

Using Caddy on K8's ( Client: 1.22.4 Server: 1.21.5 ). When deploying to the cluster the caddy pod, spins every minute with these messages. I can't for the life of me see where the resource name might be" I have looked through the code and can't see any error lines with the caddy config reload: prefix.

Does anyone know what this error refers to?

time="2022-01-03T13:58:55Z" level=info msg="Found TLS certificates on ingress resource. Syncing..."
time="2022-01-03T13:58:55Z" level=error msg="caddy config reload: resource name may not be empty"
time="2022-01-03T13:58:55Z" level=info msg="Ingress resource update detected, updating Caddy config..."
time="2022-01-03T13:58:55Z" level=info msg="Updating caddy config"
time="2022-01-03T13:58:55Z" level=info msg="using config map options: map[redacted]"

Thanks.

Auto-renewal failed - JWS has an invalid anti-replay nonce

Hi There,

Setup

I've installed caddy-ingress via helm onto GKE kubernetes version v1.16.13-gke.401. With 2 replicas setup for caddy deployment and static IP for caddy-ingress-controller service

helm install command:

helm install --namespace=caddy-system --repo https://caddyserver.github.io/ingress --set image.tag=latest --set ingressController.autotls=true --set [email protected] --name caddy-system caddy-ingress-controller

Issue

Found out my site's cert has expired today (been exactly 3 months) and after some log digging I've discovered that caddy cert renewal attempt failed on JWS has an invalid anti-replay nonce: "0004SoE1IQCuMy-jsvKCuEuK6otJYGmikuWhmRBy54NFER8", url:.

This nonce error also have caddy to constantly retry cert renewal and fail, which causes a rate limit error now:

2020-11-19T01:31:10.072816791Z 2020/11/19 01:31:10 [ERROR] attempt 1: [adeptohomes.com] Renew: [adeptohomes.com] acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many certificates already issued for exact set of domains: adeptohomes.com: see https://letsencrypt.org/docs/rate-limits/, url:  - retrying in 1m0s (12.249918115s/720h0m0s elapsed)...

You can find a list of cert renewal attempt of my site here - https://crt.sh/?q=adeptohomes.com

Has anyone bumped into this before? Any help would be appreciated.

Cannot install using Helm - chart not found

Trying to set this up, but can't install it.

Installed Helm, created the namespace, then tried helm install using the command in the README (below):

helm install \
    --namespace=caddy-system \
    --repo https://caddyserver.github.io/ingress/ \
    --atomic \
    --set image.tag=latest \
    mycaddy \
    caddy-ingress-controller

I get this error:

Error: chart "caddy-ingress-controller" not found in https://caddyserver.github.io/ingress/ repository

I'm running on a local cluster.
Helm version is: version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}

Home Cluster ingress/IP address

This isn't an issue, I'm just trying to work out how I might use this ingress controller on a home Raspberry Pi K8s cluster. I have a couple of questions.

They are not urgent but a steer would be appreciated, I have googled extensively I promise.

  1. Do I need Caddy installed as well, or is this effectively caddy-for-K8s and load balancing and reverse proxying is available out-the-box?

  2. Do I need something like MetalLB on top of this in order to use my router IP address with the Caddy ingress controller? I'm confused here. When I try to get the IP I get "pending" presumably because by default it wants a cloud load balancer IP. I'm especially confused because this configuration puts a cloud load balancer in front of Caddy which itself can be a load balancer and reverse proxy?

  3. If I don't need anything else, what is the process to use a local router IP with caddy ingress controller. Is there a way to get it to use the external router IP.

Apologies, I don't have lots of experience with K8s so far.

Error: chart "caddy-ingress-controller" not found in https://caddyserver.github.io/ingress/ repository

I tried following the instruction in the README but I get an error when running helm install

% kubectl create namespace caddy-system
namespace/caddy-system created
% helm install \
>     --namespace=caddy-system \
>     --repo https://caddyserver.github.io/ingress/ \
>     --atomic \
>     --set image.tag=latest \
>     mycaddy \
>     caddy-ingress-controller
Error: chart "caddy-ingress-controller" not found in https://caddyserver.github.io/ingress/ repository

helm version is

version.BuildInfo{Version:"v3.4.1", GitCommit:"c4e74854886b2efe3321e185578e6db9be0a6e29", GitTreeState:"dirty", GoVersion:"go1.15.4"}

Project dead already?

As with the release of caddy 2, and no activity on this repo since february, is this project dead already?

pulling image configured at gcr.io/danny-239313/ingresscontroller:v0.1.0 results in a 401 Unauthorized response

Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  <unknown>           default-scheduler  Successfully assigned caddy-system/caddy-ingress-controller-58f6d99cb8-pd96v to gateway
  Normal   Pulling    33s (x4 over 2m)    kubelet, gateway   Pulling image "gcr.io/danny-239313/ingresscontroller:v0.1.0"
  Warning  Failed     31s (x4 over 117s)  kubelet, gateway   Error: ErrImagePull
  Warning  Failed     31s (x4 over 117s)  kubelet, gateway   Failed to pull image "gcr.io/danny-239313/ingresscontroller:v0.1.0": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/danny-239313/ingresscontroller:v0.1.0": failed to resolve reference "gcr.io/danny-239313/ingresscontroller:v0.1.0": unexpected status code [manifests v0.1.0]: 401 Unauthorized
  Warning  Failed     7s (x6 over 117s)   kubelet, gateway   Error: ImagePullBackOff
  Normal   BackOff    7s (x6 over 117s)   kubelet, gateway   Back-off pulling image "gcr.io/danny-239313/ingresscontroller:v0.1.0"

Does the image no longer exist at this URI?

HA Support

First of all, thanks for bringing Caddy 2 to Kubernetes, I am really glad this project exists.

The main reason I use Caddy over Traefik is its simplicity. Traefik would also have been a nice option - if the free edition supported high availability, a core feature from my point of view.

Will this ingress controller be able to handle high availability deployments (using ReplicaSets and maybe even DaemonSets) with proper handling of certificate requests?

Can not install caddy-ingress-controller using helm install

I use helm installing the caddy-ingress-controller,but it failed with this error:

[root@boxing1 ~]#   helm install \
>     --namespace=caddy-system \
>     --repo https://caddyserver.github.io/ingress/ \
>     --atomic \
>     --set image.tag=latest \
>     mycaddy \
>     caddy-ingress-controller
Error: unknown flag: --atomic

My helm version is:

[root@boxing1 ~]# helm version --tls
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

I think this is because the too old helm version.Can we specify which helm version that we support?Thanks.

Custom configuration

On NGINX, it's possible to include custom configuration using the nginx.ingress.kubernetes.io/configuration-snippet annotation.

Would that be possible to add that as a new feature for Caddy 2 ingress controller?

helm can't find chart

Helm can not find the caddy-ingress-controller chart

$ helm repo add caddyserver https://caddyserver.github.io/ingress/

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "caddyserver" chart repository
Update Complete. ⎈ Happy Helming!⎈

$ helm pull caddyserver/caddy-ingress-controller
Error: chart "caddy-ingress-controller" matching  not found in caddyserver index. (try 'helm repo update'): no chart version found for caddy-ingress-controller-

$ helm version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}

It shouldn't matter but this is in PowerShell on a Windows 10 Pro 64-bit machine.

General questions about the project

  • What's the goal of this project?
  • Is this just a POC to see if there any interest?
  • Have you thought about the integration of the existing directives/middleware in Caddy?
  • Do you have an interest int the Kubernetes ecosystem or this is "just" to "compete" with the alternatives?
  • Are there any plans to incubate Caddy project in the CNCF?

My questions are related to this thread https://groups.google.com/forum/#!topic/kubernetes-sig-network/ULr1a3XWYq0 and the next iteration of the Kubernetes Ingress spec https://docs.google.com/document/d/1BxYbDovMwnEqe8lj8JwHo8YxHAt3oC7ezhlFsG_tyag/edit#

Respect to the first link, Caddy has the advantage of already being used in the project, thanks to CoreDNS.

Support OnDemandTLS feature

Is it possible to set up an ingress to support all domains?

E.g: host: * rather than host: foo.com

For my use case, I want to support automatic cert issuing for all domains, but the amount of domains is constantly changing and dynamic and can't be manually set in the standard K8s ingress host values.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.