# Ignition 8.1.39 Deployment to Kubernetes - Standard Operations Question

**URL:** <https://forum.inductiveautomation.com/t/ignition-8-1-39-deployment-to-kubernetes-standard-operations-question/89543>\
**Category:** Ignition\
**Created:** [April 26, 2024, 5:16pm UTC](https://forum.inductiveautomation.com/t/ignition-8-1-39-deployment-to-kubernetes-standard-operations-question/89543 "2024-04-26T17:16:43Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Norm\_Collins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/norm_collins/32/61556_2.png) [@Norm\_Collins](https://forum.inductiveautomation.com/u/Norm_Collins)\
**Post date:** [April 26, 2024, 5:16pm UTC](https://forum.inductiveautomation.com/t/ignition-8-1-39-deployment-to-kubernetes-standard-operations-question/89543/1 "2024-04-26T17:16:44Z")

</div>

I have an Ignition deployment running in Azure Kubernetes Service. The deployment worked from an Ignition application point of view. As part of the standard operating procedures, there is a requirement to perform backups/restores. I have a couple questions about this:

1. Is the Backup/Restore process expected to function normally while running in kubernetes?
2. Do you have any guidance on how to make sure the image/deployment is kept up to date so that no data is lost in the event of pod/pvc corruption?

I attempted a backup from an already running gateway (VM Based) and tried to perform the restore in the Kubernetes environment and it caused the pod to go into CrashLoopBackoff and continually restart (The application would restart so we could login; then it would crash)

---

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [April 26, 2024, 6:36pm UTC](https://forum.inductiveautomation.com/t/ignition-8-1-39-deployment-to-kubernetes-standard-operations-question/89543/2 "2024-04-26T18:36:16Z")

</div>

Backup and Restore should work like in other containerized run contexts. A typical strategy would be to mount a PVC (could be an Azure Files endpoint) into the pod and configure scheduled backups within Ignition to target it.

If you're going into _CrashLoopBackoff_ after a restore, the first step would be to get the events from the pod, perhaps logs also. There might be something incorrect in your K8s resource configurations. Are you using `StatefulSet` for the Ignition gateway?

---

<div class="post-metadata">

**Author:** ![Norm\_Collins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/norm_collins/32/61556_2.png) [@Norm\_Collins](https://forum.inductiveautomation.com/u/Norm_Collins)\
**Post date:** [May 9, 2024, 4:38pm UTC](https://forum.inductiveautomation.com/t/ignition-8-1-39-deployment-to-kubernetes-standard-operations-question/89543/3 "2024-05-09T16:38:17Z")

</div>

Sorry for the delay - I am attaching the pod logs. Also, I'm confirming that we are not using a StatefulSet for the Ignition Gateway  
[ignition\_pod\_log.txt](https://forum.inductiveautomation.com/uploads/short-url/2CpZmC9HPsAG4m0qbaYYFc4xLFr.txt) (20.9 KB)

---

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [May 9, 2024, 5:49pm UTC](https://forum.inductiveautomation.com/t/ignition-8-1-39-deployment-to-kubernetes-standard-operations-question/89543/4 "2024-05-09T17:49:50Z")

</div>

By the look of that log, it appears to me that you're launching another pod against the same underlying PV, causing contention (with corruption a likely result). Ignition never expects _another_ Ignition to be trying to interact with the same files. While there is now [`ReadWriteOncePod` access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) (GA in K8s 1.29), the best way to avoid this is to leverage the guarantees afforded by [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). If you've not taken a peek at my K8s examples Github repo, it might provide some useful insights into some patterns for setting up your target architecture:

> **[Deployment Patterns for Ignition on Kubernetes](https://inductiveautomation.com/resources/icc/2023/deployment-patterns-for-ignition-on-kubernetes)**
>
> Kevin Collins returns to ICC for a demonstration of how to harness the combined power of Ignition and Kubernetes. This session offers an in-depth look at methods for effectively automating deployment, scaling, and managing containerized Ignition...

> **[GitHub - thirdgen88/icc2023-ignition-k8s: ICC 2023 Session - Deployment...](https://github.com/thirdgen88/icc2023-ignition-k8s)**
>
> ICC 2023 Session - Deployment Patterns for Ignition on Kubernetes - thirdgen88/icc2023-ignition-k8s
