consul multi dc cluster issue with consul-connect-injector when tls and mesh gateway are enabled
- Dominant language
- Go
- Stars
- 30.1k
- Forks
- 4.6k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 43
Description
i am having issues while setting up consul multi dc cluster on k8s when connect,tls and mesh gateway are enabled.
consul-connect-injector pod is not coming up. its getting restarted multiple times. bellow is snippet of the same
consul-connect-injector-webhook-deployment-7f64d8767c-gsj76 0/1 CrashLoopBackOff 12 40m
Normal Scheduled 9m11s default-scheduler Successfully assigned default/consul-connect-injector-webhook-deployment-76c6d6c69f-8zsx2 to zlt19564
Warning Unhealthy 8m47s kubelet, Liveness probe failed: Get https://10.247.211.116:8080/health/ready: dial tcp 10.247.211.116:8080: connect: connection refused
consul info:-
consul info from server
agent:
check_monitors = 0
check_ttls = 0
checks = 0
services = 0
build:
prerelease = rc1
revision = 44e17c81
version = 1.8.0
consul:
acl = disabled
bootstrap = false
known_datacenters = 1
leader = true
leader_addr = 10.244.34.177:8300
server = true
consul info from client/agent
consul info
agent:
check_monitors = 0
check_ttls = 0
checks = 0
services = 0
build:
prerelease = rc1
revision = 44e17c81
version = 1.8.0
consul:
acl = disabled
known_servers = 3
server = false
runtime:
arch = amd64
cpu_count = 8
goroutines = 51
max_procs = 8
os = linux
version = go1.14.1
serf_lan:
coordinate_resets = 0
encrypted = false
event_queue = 0
event_time = 4
failed = 0
health_score = 0
intent_queue = 0
left = 0
member_time = 150
members = 18
query_queue = 0
query_time = 1
please let know if any other information is required here
Contributor guide
Research direction
Start by inspecting the consul-connect-injector-webhook deployment, pod logs, and the /health/ready liveness probe configuration. Reproduce the multi-datacenter Kubernetes setup with Connect, TLS, and mesh gateways enabled, then identify why the injector fails to start. Done means the injector remains ready without CrashLoopBackOff and the readiness probe succeeds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, distributed-systems, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100