Kubernetes - Old replica sets remains after deployment

In this post i will write about annoying Kubernetes problem I managed to solve (at least I think it solved)
after long struggle.

So, here is the problem:

After running update-deployment-image command:

kubectl set image deployment/my-app my-app=gcr.io/my-cloud/my-app:new-image-tag 

The kubernetes showed that although the new image successfully updated, the old replicaset still remains:

Old replicates are all with 0 pods, but not removed.

Solution

The solution I found is to change the "selector" node in deployment configuration -
From:

  selector:
    matchLabels:
      app: my-app
      version: $SHORT_SHA

To

  selector:
    matchLabels:
      app: my-app

(Remove the "version" label)
And to add revisionHistoryLimit entry

spec:
  replicas: 2
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: my-app

Make travis to push tags

What is travis you already know from the previous post. But what the kubernetes is?
According to the docs: "Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available"
Get the long things shorter: kubernetes is the way to upload applications to google cloud, and also it can do lots of other things.

My Goal

So, my goal was: to get things published to cloud after all the testing stuff was done. (or after the travis finished)
Google cloud builder - another google cloud tool can be activated in response to push to some branch or in response to publishing some tag

In other words - my goal is to make travis to push tag after successful testing of every commit.

After Success Hook

Fortunately I found that travis has a after_success hook which I can utilise for my scenario:

language: node_js
node_js:
  - "9"
sudo: required
branches:
  except:
    - /^v.*\_.*/ 
dist: trusty
addons:
  chrome: stable
cache:
  directories:
  - $HOME/.npm
env:
  matrix:
    - MONGODB=3.6.6
before_install:
  - export GITHUBKEY=put-here-your-github-auth-token-key
install:
  ...
  ...
script:
  # run build script specified in package.json
  - npm run tslint
  - npm run test
  - npm run build
after_success:
  # CREATE GIT TAG
  - bash ./scripts/push_tag.sh

And here is the bash script code:

#!/bin/sh
git config --global user.email "koko@moko.com"
git config --global user.name "koko"
# Version key/value should be on his own line
PACKAGE_VERSION=$(cat package.json \
  | grep version \
  | head -1 \
  | awk -F: '{ print $2 }' \
  | sed 's/[",]//g' \
  | tr -d '[[:space:]]')

# should start cloud build only on prod test dev branches 
if [[ "${TRAVIS_BRANCH}" = prod || "${TRAVIS_BRANCH}" = test || "${TRAVIS_BRANCH}" = dev ]]; then
    export GIT_TAG="v${PACKAGE_VERSION}_${TRAVIS_BUILD_NUMBER}"
    echo "tag is ${GIT_TAG}"
    git tag $GIT_TAG -a -m "Generated tag from TravisCI build $TRAVIS_BUILD_NUMBER [ci skip]" $TRAVIS_BRANCH
    git push --tags https://$GITHUBKEY@github.com/oyrname/yourrepo
fi

Notice, that travis will react to the tag pushed by himself unless except entry configured properly:

branches:
  except:
    - /^v.*\_.*/

Making travis to test nodejs app

Tra... what?

May be you have noticed .travis.yml file in some of open source GitHub repos. Travis tool - is a CI tool for github. CI - means continuous integration, which in turn - means that after every change of code some checks will be run automatically. It can be unit test, can be code standard checks (like lint) or whatever you want to be checked.

My Situation

In my case - In our company we have some nodejs + typescript + mongo application which has mocha/chai unit tests (pretty common stack nowdays).
Here is basic travis configuration which runs tslint and unit tests

language: node_js
node_js:
  - "9"
sudo: required
dist: trusty
addons:
  chrome: stable
cache:
  directories:
  - $HOME/.npm
env:
  matrix:
    - MONGODB=3.6.6
install:
  - wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-${MONGODB}.tgz
  - tar xzf mongodb-linux-x86_64-${MONGODB}.tgz
  - ${PWD}/mongodb-linux-x86_64-${MONGODB}/bin/mongod --version
  - npm install
before_script:
  - mkdir ${PWD}/mongodb-linux-x86_64-${MONGODB}/data
  - ${PWD}/mongodb-linux-x86_64-${MONGODB}/bin/mongod --dbpath ${PWD}/mongodb-linux-x86_64-${MONGODB}/data --logpath ${PWD}/mongodb-linux-x86_64-${MONGODB}/mongodb.log --fork
script:
  # run build script specified in package.json
  - npm run tslint
  - npm run test
  - npm run build

Notice that mongo can be installed at testing machine travis creates each time when tests are run. Mongo is needed for run unit tests