<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>

CC BY-SA 4.0
2022-08-24T15:54:59.197Z
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
SYN
CC BY-SA 4.0
2022-08-25T10:29:01.860Z
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' ?
beirtipol
CC BY-SA 4.0
2022-08-24T09:31:38.760Z
2022-08-24T09:31:38.760Z
Serve Laurijssen
<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>

CC BY-SA 4.0
2022-08-25T10:19:17.790Z
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
beirtipol
CC BY-SA 4.0
2022-08-25T15:40:31.443Z
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.
SYN
CC BY-SA 4.0
2022-08-24T15:53:58.177Z
2022-08-24T15:53:58.177Z
SYN
<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>

<kubernetes>
How best to delay startup of a kubernetes container until another container has done something?
beirtipol
# 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: username_2C_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.  

---

