Answers: <p>Maybe a readiness probe will help. The api server will in this case call your pods on /health and a http status error code means not ready, else ready. As long as the service is not ready, calls will not be routed.</p>
  <pre><code>  - name: name
      image: &quot;docker.io/app:1.0&quot;
      imagePullPolicy: Always
      readinessProbe:
        httpGet:
          path: /health
          port: 5000
        initialDelaySeconds: 5
  </code></pre>
  <p>And in your code</p>
  <pre><code>@app.route(&quot;/health&quot;)
  def health():
      if not os.path.exists('gitfile'):
          return &quot;not ok&quot;, 500
      return &quot;OK&quot;, 200
  </code></pre>
  <p>or else a livenessprobe with checks the return value of the utilities called. zero means success, else fail.</p>
  <pre><code>livenessProbe:
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2022-08-24T15:54:59.197Z
Answers: using a livenessprobe: that's a recipe for app-crashes, file-still-there, pod-wont-restart. readiness makes more sense, when coded into app, alongside whatever other dependency there would be
Answers: SYN
Answers: CC BY-SA 4.0
Answers: 2022-08-25T10:29:01.860Z
Answers: With a readinessProbe I can achieve this much cleaner. Can you update your answer to change from a livenessProbe to a readinessProbe and use 'ls' instead of 'cat' ?
Answers: beirtipol
Answers: CC BY-SA 4.0
Answers: 2022-08-24T09:31:38.760Z
Answers: 2022-08-24T09:31:38.760Z
Answers: Serve Laurijssen
Answers: <p>You should use your initContainer to clone the repository. Don't wait for a file to be present: just pull or clone your conf.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-08-25T10:19:17.790Z
Answers: That doesn't work if I want to keep the repository in sync with a cron job calling git pull/push as the init container dies as soon as it's cloned
Answers: beirtipol
Answers: CC BY-SA 4.0
Answers: 2022-08-25T15:40:31.443Z
Answers: It was clear this is what you're doing. And I didn't want to start my answer with this, but that sounds wrong. Beyond the concurrency/corruption issues you'll face when both app and job tries to write the same file, how do you know your app actually read files that would have changed on its filesystem? You'ld better have jobs restart your deployment. Gitops can be nice, but this is wrong.
Answers: SYN
Answers: CC BY-SA 4.0
Answers: 2022-08-24T15:53:58.177Z
Answers: 2022-08-24T15:53:58.177Z
Answers: SYN
Body: <p>I'm migrating a chunk of applications to k8s. Some of them have large amounts of config files which are best held in GIT as their size exceeds the max size for configmaps. I have a simple git-sync image which I can configure to keep a persistent volume in sync with a git repository and had hoped to use it as a sidecar in some deployments.</p>
  <p>Here's the crux. Some applications (like vendor apps that I can't control) require the configuration files to be there before the application starts. This means I can't just run the git-sync container as a sidecar as there's no guarantee it will have cloned the git repo before the main app starts. I've worked around this by having a separate deployment for the git sync and then having an initContainer for my main application which checks for the existence of the cloned git repo before starting.</p>
  <p>This works but it feels a little messy. Any thoughts on a cleaner approach to this?</p>
  <p>Here's a yaml snippet of my deployments:</p>
  <pre><code>#main-deployment
  ...
  initContainers:
  - name: wait-for-git-sync
    image: my-git-sync:1.0
    command: [&quot;/bin/bash&quot;]
    args: [ &quot;-c&quot;, &quot;until [ -d /myapp-config/stuff ] ; do echo \&quot;config not present yet\&quot;; sleep 1; done; exit;&quot; ]
    volumeMounts:
    - mountPath: /myapp-config
      name: myapp-config
  containers:
  - name: myapp
    image: myapp:1.0
    volumeMounts:
    - mountPath: /myapp-config
      name: myapp-config
  
  volumes:
  - name: myapp-config
    persistentVolumeClaim:
      claimName: myapp-config
  ...
  ---
  #git-sync-deployment
  ...
  containers:
  - name: myapp-git-sync
    image: my-git-sync:1.0
    env:
      - name: GIT_REPO
        value: ssh://mygitrepo
      - name: SYNC_DIR
        value: /myapp-config/stuff
    volumeMounts:
    - mountPath: /myapp-config
      name: myapp-config
  volumes:
  - name: myapp-config
    persistentVolumeClaim:
      claimName: myapp-config
  ...
  </code></pre>
  
Tags: <kubernetes>
Title: How best to delay startup of a kubernetes container until another container has done something?
UserDisplayName: beirtipol
ThreadText: # How best to delay startup of a kubernetes container until another container has done something?
  
  (Asked by: username_0 on 2022-08-23)
  
  I'm migrating a chunk of applications to k8s. Some of them have large amounts of config files which are best held in GIT as their size exceeds the max size for configmaps. I have a simple git-sync image which I can configure to keep a persistent volume in sync with a git repository and had hoped to use it as a sidecar in some deployments.
  
  Here's the crux. Some applications (like vendor apps that I can't control) require the configuration files to be there before the application starts. This means I can't just run the git-sync container as a sidecar as there's no guarantee it will have cloned the git repo before the main app starts. I've worked around this by having a separate deployment for the git sync and then having an initContainer for my main application which checks for the existence of the cloned git repo before starting.
  
  This works but it feels a little messy. Any thoughts on a cleaner approach to this?
  
  Here's a yaml snippet of my deployments:
  
  ```
  #main-deployment
  ...
  initContainers:
  - name: wait-for-git-sync
    image: my-git-sync:1.0
    command: ["/bin/bash"]
    args: [ "-c", "until [ -d /myapp-config/stuff ] ; do echo \"config not present yet\"; sleep 1; done; exit;" ]
    volumeMounts:
    - mountPath: /myapp-config
      name: myapp-config
  containers:
  - name: myapp
    image: myapp:1.0
    volumeMounts:
    - mountPath: /myapp-config
      name: myapp-config
  
  volumes:
  - name: myapp-config
    persistentVolumeClaim:
      claimName: myapp-config
  ...
  ---
  #git-sync-deployment
  ...
  containers:
  - name: myapp-git-sync
    image: my-git-sync:1.0
    env:
      - name: GIT_REPO
        value: ssh://mygitrepo
      - name: SYNC_DIR
        value: /myapp-config/stuff
    volumeMounts:
    - mountPath: /myapp-config
      name: myapp-config
  volumes:
  - name: myapp-config
    persistentVolumeClaim:
      claimName: myapp-config
  ...
  
  ```
  
  **Tags:** kubernetes
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-08-24. Score: 1 | Accepted answer
  
  Maybe a readiness probe will help. The api server will in this case call your pods on /health and a http status error code means not ready, else ready. As long as the service is not ready, calls will not be routed.
  
  ```
    - name: name
      image: "docker.io/app:1.0"
      imagePullPolicy: Always
      readinessProbe:
        httpGet:
          path: /health
          port: 5000
        initialDelaySeconds: 5
  
  ```
  
  And in your code
  
  ```
  @app.route("/health")
  def health():
      if not os.path.exists('gitfile'):
          return "not ok", 500
      return "OK", 200
  
  ```
  
  or else a livenessprobe with checks the return value of the utilities called. zero means success, else fail.
  
  ```
  livenessProbe:
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5
  
  ```
  
  > **Comments:**
  > **username_2**: using a livenessprobe: that's a recipe for app-crashes, file-still-there, pod-wont-restart. readiness makes more sense, when coded into app, alongside whatever other dependency there would be  
  > **username_0**: With a readinessProbe I can achieve this much cleaner. Can you update your answer to change from a livenessProbe to a readinessProbe and use 'ls' instead of 'cat' ?  
  
  ---
  
  ### Answer by username_2 on 2022-08-24. Score: 1
  
  You should use your initContainer to clone the repository. Don't wait for a file to be present: just pull or clone your conf.
  
  > **Comments:**
  > **username_0**: That doesn't work if I want to keep the repository in sync with a cron job calling git pull/push as the init container dies as soon as it's cloned  
  > **username_2**: It was clear this is what you're doing. And I didn't want to start my answer with this, but that sounds wrong. Beyond the concurrency/corruption issues you'll face when both app and job tries to write the same file, how do you know your app actually read files that would have changed on its filesystem? You'ld better have jobs restart your deployment. Gitops can be nice, but this is wrong.  
  
  ---
  
  