Hello, I have followed your example terraform-gcp-gke-ingress-controller and ran into the following error.

The following CNAMES is setup

CNAME(proxy): "docker-helloworld.${zone_name}" --> "cluster.${zone_name}"
CNAME(noproxy): "cluster.${zone_name}" --> "xxxx.cfargotunnel.com"

When visiting the site via https I get the following error.

CONNECTED(00000006)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 340 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 340 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

*   Trying 172.67.186.49:443...
* Connected to docker-helloworld.zone_name (xx.xx.xx.xx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, handshake failure (552):
* error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure

The nginx proxy/ingress controller handles https requests fine, if I turn on proxy for "cluster.${zone_name}".

I suspect the error is that cloudflared does not strip the https?

I should mention that the zone_name uses the .app extension, so maybe the nginx ingress controller forces https?

Is it possible to use one Cloudflare tunnel across multiple namespaces. Instead of deploying it to the default namespace

Greeting
cant use default cloudflared.yaml
on ARM. processors
please advice

I've completed steps 1 to 4 but on step 5 the cloudflared pod is on a CrashLoopBackOff returning:

2021-06-03T23:01:05Z INF Cannot determine default origin certificate path. No file cert.pem in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared] originCertPath=
2021-06-03T23:01:05Z ERR You need to specify the origin certificate path by specifying the origincert option in the configuration file, or set TUNNEL_ORIGIN_CERT environment variable. See https://developers.cloudflare.com/argo-tunnel/reference/service/ for more information. originCertPath=
error parsing tunnel ID: Error locating origin cert: client didn't specify origincert path

In this example:

Wouldn't this result in a potential 10 second outage?

Is there a reason it is not set to 1?

Could you provide an example of how to use Ingress + Cloudflare tunnel?

I guess it is possible to avoid using the Cloud Provider Load Balancer solution if all traffic goes through Cloudflare Tunnel, right?

You can provide the example using Ingress Nginx OR Traefik OR any solution that allows defining custom routes for specific services, for example:

https://github.com/webmakaka/Microservices-with-Node-JS-and-React/blob/master/10_Testing_Isolated_Microservices/k8s/ingress-controller.yaml#L12-L16

PR proposal: Provide direct link to docs and httpHostHeader example

Changes: diff in my repository

Filing this as a result of my experience, and opening this issue first per the contributing guidelines.

Rationale

The httpHostHeader key defaults to "" per the documentation, which overrides what the browser sends and requires this key to be set for most k8s ingress controllers configured on a per host basis. Most k8s implementations will have cloudflared call a common ingress controller which, if looking for a specific host, as is usually the case, and the request comes in without it, will 404. Therefore, I recommend including the example.

(Even better, in the future, would love to see an option to preserve this header in named tunnels. A workaround is to directly attach cloudflared to the ingress service.)

In addition, based on the difficulty navigating documentation to find these parameters and, in particular, their defaults, I recommend including the direct link to those docs similar to the ingress doc link further down in the config.yaml example.

Is there interest by the owners of this repository in a helm chart to replace deployment.yaml in named-tunnel-k8s? I've written one and can contribute if desired.

I can only see livenessProbe:

What's the reason readiness probe is not in use?

I'm attempting to get the simple named tunnel example working in a rapi homelab k3s cluster on my home lan. I've verified the tunnel on my mac now attempting to get it running in the cluster.

I'm getting this error message:

error parsing tunnel ID: REST request failed: Get "https://api.cloudflare.com/client/v4/accounts/976950979e32e569298940bab05aab7a/tunnels?is_deleted=false&name=example-tunnel": x509: certificate signed by unknown authority

Any pointers?

Well this is the chart for helm which is not possible to access at all. Wheres the helm-chart repository?

You have official cloudflare helm-chart repo in here: https://github.com/cloudflare/helm-charts but the only chart is this one https://github.com/cloudflare/helm-charts/tree/master/charts/argo-tunnel and it's a legacy argo ingress controller which doesn't work anymore. Why not to put this chart in there and destroy that legacy one? I'm actually need this heavily for automation, I don't want to fork your repo or store chart locally. Can I contribute somehow in here please? We "SIA Setupad" your enterprise client.

Setup better logging and metrics

I have a local Kubernetes created by Rancher Desktop. I have deployed a named Cloudflared Tunnel based on this tutorial.

I recently started to get error:

failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.

Note this does not affect the actual function of Cloudflared Tunnel, which is more like a warning. However, I do hope to fix it.

I have read the content in the link. However, this is running in a pod, so I am not sure how to fix it.

Below is full log:

2023-03-18 00:27:51.450Z 2023-03-18T00:27:51Z INF Starting tunnel tunnelID=c9aa4140-fee8-4862-a479-3c1faacbd816
2023-03-18 00:27:51.450Z 2023-03-18T00:27:51Z INF Version 2023.3.1
2023-03-18 00:27:51.450Z 2023-03-18T00:27:51Z INF GOOS: linux, GOVersion: go1.19.7, GoArch: arm64
2023-03-18 00:27:51.451Z 2023-03-18T00:27:51Z INF Settings: map[config:/etc/cloudflared/config/config.yaml cred-file:/etc/cloudflared/creds/credentials.json credentials-file:/etc/cloudflared/creds/credentials.json metrics:0.0.0.0:2000 no-autoupdate:true]
2023-03-18 00:27:51.453Z 2023-03-18T00:27:51Z INF Generated Connector ID: a2d07b8a-3343-4b28-bbb5-a0cc951d5093
2023-03-18 00:27:51.453Z 2023-03-18T00:27:51Z INF Initial protocol quic
2023-03-18 00:27:51.456Z 2023-03-18T00:27:51Z INF ICMP proxy will use 10.42.0.32 as source for IPv4
2023-03-18 00:27:51.456Z 2023-03-18T00:27:51Z INF ICMP proxy will use fe80::3c91:31ff:fe74:68ee in zone eth0 as source for IPv6
2023-03-18 00:27:51.456Z 2023-03-18T00:27:51Z WRN The user running cloudflared process has a GID (group ID) that is not within ping_group_range. You might need to add that user to a group within that range, or instead update the range to encompass a group the user is already in by modifying /proc/sys/net/ipv4/ping_group_range. Otherwise cloudflared will not be able to ping this network error="Group ID 65532 is not between ping group 1 to 0"
2023-03-18 00:27:51.456Z 2023-03-18T00:27:51Z WRN ICMP proxy feature is disabled error="cannot create ICMPv4 proxy: Group ID 65532 is not between ping group 1 to 0 nor ICMPv6 proxy: socket: permission denied"
2023-03-18 00:27:51.460Z 2023-03-18T00:27:51Z INF Starting Hello World server at 127.0.0.1:34545
2023-03-18 00:27:51.460Z 2023-03-18T00:27:51Z INF Starting metrics server on [::]:2000/metrics
2023-03-18 00:27:51.462Z 2023/03/18 00:27:51 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.
2023-03-18 00:27:51.592Z 2023-03-18T00:27:51Z INF Connection ca329025-1f06-4f36-a8b2-27eda979345d registered with protocol: quic connIndex=0 ip=198.41.192.107 location=LAX
2023-03-18 00:27:51.760Z 2023-03-18T00:27:51Z INF Connection a25fdab3-adff-4be5-8eb3-c22d593dfbc5 registered with protocol: quic connIndex=1 ip=198.41.200.193 location=SJC
2023-03-18 00:27:52.670Z 2023-03-18T00:27:52Z INF Connection ef583d03-d123-4e8e-b8ad-37eed817d2da registered with protocol: quic connIndex=2 ip=198.41.200.113 location=SJC
2023-03-18 00:27:53.684Z 2023-03-18T00:27:53Z INF Connection 25609514-8c37-451e-b4ac-1fb9fba2b9b8 registered with protocol: quic connIndex=3 ip=198.41.192.37 location=LAX

Hi, using the manifest with the following settings

    livenessProbe:
      httpGet:
        # Cloudflared has a /ready endpoint which returns 200 if and only if
        # it has an active connection to the edge.
        path: /ready
        port: 2000
      failureThreshold: 1
      initialDelaySeconds: 10
      periodSeconds: 10

My tunnel shuts down to early, most likely because this:
Liveness probe failed: Get "http://10.244.4.35:2000/ready": dial tcp 10.244.4.35:2000: connect: connection

When I removed livenessProbe tunnel seems to be okay.
Are there any updated livenessProbe settings to use?

I am using tunnel version 2022.2.1

I'm actually heavily confused why there's a secret generated in chart template and secret string is just being passed as variable in open form? When you describe the deployment with kubectl, you'll expose the secret to all admins who manages kubernetes. This is not wrong. I have SRE who doesn't have access to view secrets, but have access to describe deployments. In terraform this secret string could be passed securely, but this violates pretty much basic security standards.

In this there's a need to have a secret in place already. So why not to do it this way?