I need to clone my deployment including the volume. I couldn't find any resources on this question except about cloning volume using CSI driver as explained in this https://kubernetes-csi.github.io/docs/volume-cloning.html#overview
Is there a way to clone a deployment other than renaming the deployment and deploying it again through the kubectl?
Is there a way to clone a deployment other than renaming the
deployment and deploying it again through the kubectl?
Unfortunately no. At the time of this writing there is no such a tool that will allow to clone your deployment. So you will have to use the option already mentioned in the question or deploy that using helm chart.
With helm your can pass custom parameters such as --generate-name or edit values.yaml content to quickly deploy similar deployment.
Worth mentioning here is also Velero. A tool for backing up kubernetes resources and persistent volumes.
Related
I have a few services running on a kubernetes cluster, and I use Helm Chart where I placed all my services. However, I was asked to transfer Helm Charts into Helmfile.
If I use
helmfile import myrepo/mychart
helmfile sync
Will it redeploy and substitute existing running pods or It will deploy just deploy additional services mentioned
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Helmfile is a declarative spec for deploying helm charts. It lets you...
Keep a directory of chart value files and maintain changes in version control.
Apply CI/CD to configuration changes.
Periodically sync to avoid skew in environments.
To avoid upgrades for each iteration of helm, the helmfile executable delegates to helm - as a result, helm must be installed.
Like #DavidMaze suggested, use helm diff command first to determine the changes and then use helm sync command for applying them.
I have a lot of cronjobs I need to set on Kubernetes.
I want a file to manage them all and set them to Kubernetes on deployment. I wish that if I remove a cron from that file it will be removed from Kubernetes too.
Basically, I want to handle the corns like I'm handling them today on the machine (from a cron file that I would deploy). Add, remove and change crons.
I couldn't find a way of doing so. Does someone have an idea?
Library or framework I can use like helm? Or any other solution.
I highly recommend using gitops with argocd as a solution for Kubernetes configure management. Run crontab in deployment is a bad ideal because it hard to monitor your job result (cronjob job result can be get by kube-state-metrics exporter).
The ideal is packaging your manifest (it may be kubernetes manifest, kustomize, helm...etc...) -> put them to git -> argocd makes sure your configure deployed correctly
The advantages of gitops are include:
centralize your configuration
versioning your configuration
git authentication & authorization
traceable
multi-cluster deployment with argocd
automation deployment & sync
...
Gitops is not a difficult and is the mordern way for kubernetes configure management. Let's try
I used Helm to do so. I built a template to go over all crons, which I inserted as values to the helm template (Very similar to crontab but more structured) - see in the example.
Then, all I need to do is run a helm upgrade with a new corn (values) file and it updates everything accordingly. If I updated, removed, or added a new corn everything is happening automatically and with versioning. You can also add a namespace to your cronjobs to make it more encapsulated.
Here is a very good and easy-to-understand example I used. And its git repo
Any example appsmith yaml for deploying appsmith since I don't want use helm in prod environment?
There's no official direct YAML files for deploying Appsmith on Kubernetes today. The Helm chart at helm.appsmith.com, and as documented at https://docs.appsmith.com/getting-started/setup/installation-guides/kubernetes, is the recommended way to install Appsmith on your cluster.
Asking as an engineering team member with Appsmith, can you elaborate a little on why avoid Helm for production please?
These are the best practises for a helm deployment which I figured out so far:
Use versioned images, because deploying via latest tag is not sufficient, as this may not trigger a pod recreate (see When does kubernetes helm trigger a pod recreate?).
Use hashed configmap metadata to restart pods on configmap changes
(see https://helm.sh/docs/howto/charts_tips_and_tricks/)
In a development environment new images are created often. Because I don't want to trash my container registry, I'd prefer using latest tags.
The only solution - I can think of - is to use versioned imaged and a cleanup job to remove old image from the registry. But this is quite complicated.
So what are your best practises for helm deployments in a development environment?
Indeed, using :latest will mean that your deployments will be mutable.
AWS ECR allows you to keep limited number of latest images according to certain regex. So you can use dev- prefix for your non-production deployments (for example triggered outside of master branch) and keep only 10 latest of them.
I am using gcp and kubernetes.
I have gcp repository and container registry.
I have a trigger for build container after pushing into the master branch.
I don't know how to set some auto-trigger to deploy new version of the container (docker file).
How can I automate the build process?
You need some extra pieces to do it, for example if you use Helm to package your deployment you can use Flux to trigger the automated deployment.
https://helm.sh/
https://fluxcd.github.io/flux/
There are two solutions here.
You can expand the build step. Cloud Build can also push changes to your GKE cluster. You can read more about this here
What you currently have is a solid CI pipeline, for the CD, you can use Spinnaker for GCP, which was released recently. This integrates well with GCE, GKE and GAE and allows you to automate the CD portion.