Kubernetes multiport service: Unable to connect to graphite port in influxdb from a client pod

7/25/2018

I have an influxdb service running in my kubernetes cluster and it exposes the following two ports

---
apiVersion: v1
kind: Service
metadata:
  labels:
    task: influxdb
  name: influxdb
  namespace: my-namespace
spec:
  type: NodePort
  ports:
  - port: 8086
    name: influxdb-port
    targetPort: 8086
    nodePort: 30101
  - port: 2003
    name: graphite-port
    targetPort: 2003
    nodePort: 30103
  selector:
    k8s-app: influxdb

I also have the graphite enabled in the influxdb.conf as follows

   [[graphite]]
      enabled = true
      bind-address = ":2003"
      protocol = "tcp"

When I deploy this service in my cluster, I am able to write to the graphite database port from outside the k8s cluster as well as any of the k8s node.

  echo "local.random.diceroll 4 `date +%s`" | nc -v 10.233.26.252 2003
  Ncat: Version 7.50 ( https://nmap.org/ncat )
  Ncat: Connected to 10.233.26.252:2003.
  Ncat: 35 bytes sent, 0 bytes received in 0.01 seconds.

However if I run the same command from a client pod running in the same namespace the command hangs. From the same client pod I am able to writing the influxdb port without any issue.

Following is the tcpdump trace of the nc command being sent to the graphite port 2003 from the client pod

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
03:02:17.133367  In b2:7c:b9:93:b8:9c ethertype IPv4 (0x0800), length 76: 10.233.102.131.60272 > 10.233.26.252.cfinger: Flags [S], seq 3653742255, win 29200, options [mss 1460,sackOK,TS val 629141248 ecr 0,nop,wscale 7], length 0
03:02:17.133414 Out ethertype IPv4 (0x0800), length 76: 10.233.102.131.60272 > 10.233.71.26.cfinger: Flags [S], seq 3653742255, win 29200, options [mss 1460,sackOK,TS val 629141248 ecr 0,nop,wscale 7], length 0
03:02:17.133783  In ethertype IPv4 (0x0800), length 76: 10.233.71.26.cfinger > 10.233.102.131.60272: Flags [S.], seq 4245034624, ack 3653742256, win 28960, options [mss 1460,sackOK,TS val 629140002 ecr 629141248,nop,wscale 7], length 0
03:02:17.133791 Out ee:ee:ee:ee:ee:ee ethertype IPv4 (0x0800), length 76: 10.233.26.252.cfinger > 10.233.102.131.60272: Flags [S.], seq 4245034624, ack 3653742256, win 28960, options [mss 1460,sackOK,TS val 629140002 ecr 629141248,nop,wscale 7], length 0
03:02:17.133805  In b2:7c:b9:93:b8:9c ethertype IPv4 (0x0800), length 68: 10.233.102.131.60272 > 10.233.26.252.cfinger: Flags [.], ack 1, win 229, options [nop,nop,TS val 629141248 ecr 629140002], length 0
03:02:17.133809 Out ethertype IPv4 (0x0800), length 68: 10.233.102.131.60272 > 10.233.71.26.cfinger: Flags [.], ack 1, win 229, options [nop,nop,TS val 629141248 ecr 629140002], length 0
03:02:17.134036  In b2:7c:b9:93:b8:9c ethertype IPv4 (0x0800), length 103: 10.233.102.131.60272 > 10.233.26.252.cfinger: Flags [P.], seq 1:36, ack 1, win 229, options [nop,nop,TS val 629141249 ecr 629140002], length 35
03:02:17.134049 Out ethertype IPv4 (0x0800), length 103: 10.233.102.131.60272 > 10.233.71.26.cfinger: Flags [P.], seq 1:36, ack 1, win 229, options [nop,nop,TS val 629141249 ecr 629140002], length 35
03:02:17.134235  In ethertype IPv4 (0x0800), length 68: 10.233.71.26.cfinger > 10.233.102.131.60272: Flags [.], ack 36, win 227, options [nop,nop,TS val 629140002 ecr 629141249], length 0
03:02:17.134258 Out ee:ee:ee:ee:ee:ee ethertype IPv4 (0x0800), length 68: 10.233.26.252.cfinger > 10.233.102.131.60272: Flags [.], ack 36, win 227, options [nop,nop,TS val 629140002 ecr 629141249], length 0
^C
10 packets captured
10 packets received by filter
-- vishpat
flannel
graphite
influxdb
kubernetes
tcpdump

1 Answer

7/28/2018

I had to use the -q0 option instead of -v. The -q0 option makes sure that the netcat connection is closed after sending the data.

-- vishpat
Source: StackOverflow