marclamberti commented on pull request #8777: URL: https://github.com/apache/airflow/pull/8777#issuecomment-648276874
@Siddharthk , 1 / It's not a bug, it's the way Kubernetes works. If you update your Helm chart with a new image tag, then Kubernetes will update your app to keep the state you desire. Take a look at the document right here: https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/. At the bottom you can read: > Similar to application Scaling, if a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update. In case your Airflow instance is running in dev/staging, that should not be a problem as it may be ok to have a little downtime between updates. In case you are in production, you should have your webserver in HA (highly available), and so, replicas running with a load balancer in front of them. During the rolling update, while one pod is being updated, the others are still accessible as well as the Airflow UI. 2/ I don't think there is a recommended way to store logs as it depends on your environment and requirements. For instance, I store my logs in S3. S3 is cheap and reliable. I can process the logs later with other tools to make analysis if needed and I can archive them at a defined time. 3 3/ About your error, I got it once with the "unofficial" chart. Sadly I don't remember how I fixed it. Check with kubectl describe your pod if you don't get additional information and keep your workers after completion so that you can debug them. Hope it helps :) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
