Sidekicks not dedicated to master?

Archive Rancher 1.x
1

What happens to the network configuration when you scale up a service containing sidekicks and the server talks to the sidekick over the network?

I made a test on that. I made a simple busybox parent with a child sidekick and scaled it to 2.

parent:
  labels:
    io.rancher.sidekicks: child
  tty: true
  image: busybox
  stdin_open: true
child:
  tty: true
  image: busybox
  stdin_open: true

I then logged in to one of the parents and pinged the child container several times.

/ # ping child
PING child (10.42.229.78): 56 data bytes
64 bytes from 10.42.229.78: seq=0 ttl=62 time=0.723 ms
64 bytes from 10.42.229.78: seq=1 ttl=62 time=0.745 ms
64 bytes from 10.42.229.78: seq=2 ttl=62 time=0.710 ms
--- child ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.710/0.726/0.745 ms
/ # ping child
PING child (10.42.126.185): 56 data bytes
64 bytes from 10.42.126.185: seq=0 ttl=64 time=0.152 ms
64 bytes from 10.42.126.185: seq=1 ttl=64 time=0.106 ms
64 bytes from 10.42.126.185: seq=2 ttl=64 time=0.100 ms

The result is that the name is resolved to a random choice of the child IP numbers. I.e. the sidekick is not dedicated to the parent. Therefore is the sidekick can’t hold any kind of state as the master will quite often call the sidekick of the other master.

My question: Is this intentional?

1 Like