0
votes

enter image description hereDeployment resource object is still not supported in our cluster and not enabled. We are using Pod resource object Yaml file. something like below:

apiVersion: v1
kind: Pod
metadata:
  name: sample-test
  namespace: default
spec:
  automountServiceAccountToken: false
  containers:

I have explored patch and Put rest api for Pod(Kubectl patch and replace) - it will update to new image version and pod restarts.

I need help in below:

  1. When the image version is same, it will not update and pod will not restart. How can i acheive Pod restart, is there any API for this or any alternate approach for this. Because My pod also refers configmap and secret. After i make changes to secret, i want to restart pod so that it can take updated value.
  2. Suppose when patch applied with new container image and it fails status is failed, I want to rollback to previous version, How can i acheive this with standalone pod without using deployment. Is there any alternate approach.
1
Why is that you are using such a older version of K8s, where deployment is not supported?Malathi

1 Answers

-1
votes

Achieving solutions for your scenario, can be handled like this:

When the image version is same, it will not update and pod will not restart. How can i acheive Pod restart, is there any API for this or any alternate approach for this. Because My pod also refers configmap and secret. After i make changes to secret, i want to restart pod so that it can take updated value

Create a new secret/configmap each time and update the pod yaml to use the new configmap/secret rather than the old name.

Suppose when patch applied with new container image and it fails status is failed, I want to rollback to previous version, How can i acheive this with standalone pod without using deployment. Is there any alternate approach

Before you do a Pod update, get the current Pod yaml using kubectl like this,

kubectl get pod <pod-name> -o yaml -n <namespace>

After getting the yaml, generate the new pod yaml and apply it. In case of failure, clean up the new resources created(configmaps & secrets) and apply the older version of pod to achieve rollback