Deleting kubernetes yaml: how to prevent old objects from floating around?

1
votes

i'm working on a continuous deployment routine for a kubernetes application: everytime i push a git tag, a github action is activated which calls kubectl apply -f kubernetes to apply a bunch of yaml kubernetes definitions

let's say i add yaml for a new service, and deploy it -- kubectl will add it

but then later on, i simply delete the yaml for that service, and redeploy -- kubectl will NOT delete it

is there any way that kubectl can recognize that the service yaml is missing, and respond by deleting the service automatically during continuous deployment? in my local test, the service remains floating around

does the developer have to know to connect kubectl to the production cluster and delete the service manually, in addition to deleting the yaml definition?

is there a mechanism for kubernetes to "know what's missing"?

2
kubernetescontinuous-deployment
I think you achieve something similar with helm. – Sithroo
An other option is having a configmap where you have all the objects. When you do a new deploy, you just have to check the configmap and delete the missing elements – pcampana

2 Answers

1
votes

There's no such way. You can deploy resources from yaml file from anywhere if you can reach the node and configure kube config. So kubernetes will not know how to respond on a file deletion. If you still want to do this, you can write a program (a go code) which checks the availability of files in one place and deletes the corresponding resource whenever the file gets deleted.

There's one way via kubernetes is by using kubernetes operator, and whenever there is any change in your files you can update the crd used to deploy resources via operator.

0
votes

You need to use a CI/CD tool for Kubernetes to achieve what you need. As mentioned by Sithroo Helm is a very good option.

Helm lets you fetch, deploy and manage the lifecycle of applications, both 3rd party products and your own.

No more maintaining random groups of YAML files (or very long ones) describing pods, replica sets, services, RBAC settings, etc. With helm, there is a structure and a convention for a software package that defines a layer of YAML templates and another layer that changes the templates called values. Values are injected into templates, thus allowing a separation of configuration, and defines where changes are allowed. This whole package is called a Helm Chart.

Essentially you create structured application packages that contain everything they need to run on a Kubernetes cluster; including dependencies the application requires. Source

Before you start, I recommend you these articles explaining it's quirks and features.

The missing CI/CD Kubernetes component: Helm package manager

Continuous Integration & Delivery (CI/CD) for Kubernetes Using CircleCI & Helm