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?