K
Q

How do you manage kubernetes deployment yaml file with continuous delivery?

4/4/2017

Let's say I have a simple deployment kubernetes config:

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: backend
spec:
  replicas: 1
  template:
    metadata:
      name: backend
    spec:
      containers:
      - name: backend
        image: backend:1.0.0
        resources:
          limits:
            memory: "500Mi"
            cpu: "100m"
        imagePullPolicy: Always

And I want to have continuous deployment.

  • One way to do it would be to simply use this file for creation, and for updates run something like kubectl set image deployment/backend backend=backend:1.1.0. But what if at some point later I wanted to change e.g. limits, I would have to find out the current version running, replace that in yaml file and apply it? Seems cumbersome

  • Google seems to use sed for replacing image version in their example, and this kind of works fine if your kubernetes config files are stored in the same repo as your code. And what if they are stored elsewhere, or your build takes quite some time? So just to change a single property you would have to run through the whole build process, which might be too long

  • Have a script that autogenerates yaml file after each deployment based on version input, and always edit the template only (but then again, where do you store the last deployed version?)

  • Some third party tool?

-- gerasalus
kubernetes

Similar Questions

Kubernetes Replication Controller name is not RFC1035 compliant
Kubernetes Docker OS parameters vs Host OS parameters
Multiple environments (Staging, QA, production, etc) with Kubernetes
Kubernetes executor on Gitlab - ERROR: Job failed (system failure): Post *api/v1/namespaces/gitlab/pods: x509: certificate signed by unknown authority

2 Answers

9/26/2018

I'm assuming you have the yaml files in the same repo as the code you're building.

We used a label (ie :snapshot) in the YAML file. This was however only used when initially created, or when you used "kubectl apply" to apply other changes to the file. When CI was done building, it ran essentially:

docker build -t <image>:<id> -f Dockerfile .
docker push <image>:<id>
docker tag <image>:<id> <image>:<snapshot>
docker tag <image>:snapshot
docker push <image>:snapshot
kubectl set image deployment <depl> <foo>=<image>:<id>

We never had issues with this, as we seldom updated the YAML files; however, you could never be sure there wasn't an old version of :snapshot cached somewhere.

If you want to always do "kubectl apply" in CI, you'll need to inject the label externally somehow (e.g. via sed, or through some kind of templating):

docker build -t <image>:${CI_BUILD_LABEL} -f Dockerfile .
docker push <image>:${CI_BUILD_LABEL}
cat template/deployment.yaml | sed s/MYPOD_VERSION/${CI_BUILD_LABEL} | kubectl apply -f -
-- rln
Source: StackOverflow
4/5/2017

Helm charts become an increasingly popular way of managing kubernetes deployments. In short it allows you to generate deployments with only defining the variables that you need with a simple configuration and it has a built in upgrade mechanism as well. In other words it provides meta-deployments.

Refer to the following docs.

-- Oswin Noetzelmann
Source: StackOverflow