{"id":70831,"date":"2020-02-21T14:42:15","date_gmt":"2020-02-21T11:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obnovlenie-kubernetes-klastera-bez-prostoya"},"modified":"2020-03-03T16:14:45","modified_gmt":"2020-03-03T13:14:45","slug":"obnovlenie-kubernetes-klastera-bez-prostoya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/obnovlenie-kubernetes-klastera-bez-prostoya","title":{"rendered":"Updating a Kubernetes Cluster Without Downtime","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Updating<\/p>\n

The update process for your Kubernetes cluster<\/em><\/p>\n

<\/p>\n

At some point while using a Kubernetes cluster, there is a need to upgrade the running nodes. This can involve package updates, kernel upgrades, or deploying new virtual machine images. In Kubernetes terminology, this is referred to as \"Voluntary Disruption\"<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

This post is part of a series of 4 posts:<\/p>\n

<\/p>\n

    \n
  1. This post.<\/li>\n
  2. Graceful termination of pods in a Kubernetes cluster<\/li>\n
  3. Delayed termination of the pod upon its deletion<\/li>\n
  4. How to avoid downtime in your Kubernetes cluster using PodDisruptionBudgets<\/li>\n<\/ol>\n

    <\/p>\n

    (Translator's note: translations of the other articles in the series will be available soon)<\/em><\/p>\n

    <\/p>\n

    In this article, we will describe all the tools Kubernetes provides to achieve zero downtime for the nodes running in your cluster.<\/p>\n

    <\/p>\n

    Defining the problem<\/h2>\n

    <\/p>\n

    Initially, we will take a naive approach to identify problems and assess the potential risks of this approach, accumulating knowledge to address each of the problems we encounter throughout the series. As a result, we will achieve a configuration that utilizes lifecycle hooks, readiness probes, and Pod disruption budgets to achieve our zero downtime goal. <\/p>\n

    <\/p>\n

    To start our journey, let's take a concrete example. Suppose we have a Kubernetes cluster with two nodes, running an application with two pods, located behind Service<\/code>:<\/p>\n

    \n\"Updating<\/p>\n

    Let's start with two pods with Nginx and the Service running on our two Kubernetes cluster nodes.<\/em><\/p>\n

    <\/p>\n

    We want to upgrade the kernel version of the two working nodes in our cluster. How do we do this? A simple solution would be to boot new nodes with the updated configuration and then shut down the old nodes while launching the new ones. While this will work, there will be several issues with this approach:<\/p>\n

    <\/p>\n