Tag Archives: deployment

To Replicas Or Not To Replicas In Kubernetes Deployments And StatefulSets?

Knowing that HorizontalPodAutoscaler (HPA) manages auto-scaling of our applications, the question might arise regarding replicas. Should we define them in our Deployments and StatefulSets, or should we rely solely on HPA to manage them? Instead of answering that question directly, we’ll explore different combinations and, based on results, define the strategy.

First, let’s see how many Pods we have in our cluster right now.

You might not be able to use the same commands since they assume that go-demo-5 application is already running, that the cluster has HPA enabled, that you cloned the code, and a few other things. I presented the outputs so that you can follow the logic without running the same commands.

kubectl -n go-demo-5 get pods

The output is as follows.

NAME    READY STATUS  RESTARTS AGE
api-... 1/1   Running 0        27m
api-... 1/1   Running 2        31m
db-0    2/2   Running 0        20m
db-1    2/2   Running 0        20m
db-2    2/2   Running 0        21m

We can see that there are two replicas of the api Deployment, and three replicas of the db StatefulSets.
Continue reading

Advertisements

Kubernetes Deployments Compared To Docker Swarm Stacks

This article is part of the series that compares Kubernetes and Docker Swarm features.

If you already used Docker Swarm, the logic behind Kubernetes Deployments should be familiar. Both serve the same purpose and can be used to deploy new applications or update those that are already running inside a cluster. In both cases, we can easily deploy new releases without any downtime (when application architecture permits that).

However, unlike the previous comparison between Kubernetes Pods, ReplicaSets, And Services, on the one hand, and Docker Swarm Stacks on the other, Deployments do provide a few potentially important functional differences. But, before we dive into functionals comparison, we’ll take a moment to explore differences in how we define objects.
Continue reading

Continuous Deployment: Implementation with Ansible and Docker

This article is part of the Continuous Integration, Delivery and Deployment series.

The previous article described several ways to implement Continuous Deployment. Specifically, it described, among other things, how to implement it using Docker to deploy applications as containers and nginx for reverse proxy necessary for successful utilization of blue-green deployment technique. All that was running on top of CoreOS, operating system specifically designed for running Docker containers.

In this article we’ll try to do the same process using Ansible (an open-source platform for configuring and managing computers). Instead of CoreOS, we’ll be using Ubuntu.

Source code used in this article can be found in the GitHub repo vfarcic/provisioning (directory ansible).
Continue reading

Software Development Models: Waterfall

Waterfall model

medium_8054381402The waterfall model originated in manufacturing and construction where changes are costly and investment in design of the production line is often much less than potential loss if the actual production fails. It is based on idea that planning and design costs are much lower than those used in the actual production.

## Software development life-cycle (SDLC)

The software waterfall model often uses some variation of following phases:

  • Requirements specification (Requirements Analysis) resulting in Requirements Document
  • Software design resulting in Software Design (SD) document
  • Implementation resulting in the actual software
  • Integration
  • Testing (or Validation)
  • Deployment (or Installation)
  • Maintenance
    Continue reading