Skip to content

A command line tool to wait for network healthy state to start another command, and then wait for network unhealthy state to stop it.

License

Notifications You must be signed in to change notification settings

taylorchu/wait-for

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

wait-for

A command line tool to wait for network healthy state to start another command, and then wait for network unhealthy state to stop it.

  -wait-start url
    	wait for url to become healthy to start
  -wait-start-interval duration
    	interval for wait-start (default 1s)
  -wait-start-retry uint
    	retry count for wait-start (default 10)
  -wait-start-timeout duration
    	timeout for wait-start (default 1s)
  -wait-stop url
    	wait for url to become unhealthy to stop
  -wait-stop-interval duration
    	interval for wait-stop (default 1s)
  -wait-stop-retry uint
    	retry count for wait-stop (default 10)
  -wait-stop-timeout duration
    	timeout for wait-stop (default 1s)
wait-for --wait-start=tcp://:8000,tcp://:8001 --wait-stop=tcp://:8002,tcp://:8003 -- sleep 60
docker pull taylorchu/wait-for:latest

Why?

Kubernetes

Kubernetes supports multiple containers in a pod, but there is no current feature to manage dependency ordering, so all the containers (other than init containers) start at the same time. This can cause a number of issues with certain configurations:

  1. Kubernetes jobs run until all containers have exited. If a sidecar container is supporting a primary container, the sidecar needs to be gracefully terminated after the primary container has exited, before the job will end.
  2. Sidecar proxies (e.g. Istio, CloudSQL Proxy) are often designed to handle network traffic to and from a pod's primary container. But if the primary container tries to make egress call or recieve ingress calls before the sidecar proxy is up and ready, those calls may fail.

The k8s enhancement to address this is sidecar container, but that KEP will not be progressing. Later, another KEP about keystone container appears, but it is unclear that the KEP design is solid. In 2023, a new sidecar container KEP is created.

Install

  1. Add restartPolicy: Never because we want to manage restart cycle ourselves.
  2. Add volume and init container to copy wait-for binary that will be used in all containers in this pod:
volumes:
  - name: wait-for
    emptyDir: {}
initContainers:
  - name: wait-for
    image: taylorchu/wait-for:latest
    imagePullPolicy: IfNotPresent
    command: ['cp', '/usr/bin/wait-for', '/wait-for/wait-for']
    volumeMounts:
      - name: wait-for
        mountPath: /wait-for
  1. For each container in this pod, add volume mount and command/args:
volumeMounts:
  - name: wait-for
    mountPath: /wait-for
command: ['/wait-for/wait-for', '--wait-start=tcp://some_address', '--wait-stop=tcp://some_address', '--']
args: ['some_command']

Replace some_address and some_command with real values.

Other ideas

About

A command line tool to wait for network healthy state to start another command, and then wait for network unhealthy state to stop it.

Resources

License

Stars

Watchers

Forks