Skip to main content

Kubernetes: A Rolling Deployment...



This is the last module of our beginner’s tutorial! My how time flies.

So, what’s the last piece of knowledge?

Rolling updates that allow Deployments updates to take place with no downtime.

How?



 By incrementally updating Pods instances with new ones, scheduled on Nodes with available resources.

Before, we just told our application to run multiple instances so we could update and not affect availability.

The default maximum # of pods that can be unavailable during an update is one (1), but you can make that another number or even a percentage of active pods.

Kubernetes updates versions and Deployment updates can be reverted back if it doesn’t work out so nicely.

What if said Deployment is exposed publicly? Then the Service will load balance the traffic to Pods available (aka, not being updated at that exact time)

Rolling updates promote applications from one environment to another by container image updates, or rollback to previous versions, with the continuous integration and delivery of applications - No downtime!

Deployments and Pods - Still 4/4!



kubectl describe pods gives us a lot of information, but somewhere in that infodump tells us that our Pods are running version 1 - We want to update them.

Changed the layout!
Seems like we updated Pods called jocatalin. See what happens next!









Let’s make sure the update is working;

Enjoy stats such as the

  • Name (kubernetes-bootcamp)
  • The node port (<unset> 31139/TCP)
  • The IP and port (10.101.170.210 and <unset> 8080/TCP).


Make an enviroment variable called NODE_PORT with the port assigned.



And there’s our variable with the corresponding number.

curl $(minikube ip):$NODE_PORT
 Hits a different Pod with every request - all Pods are running the latest version.

Let’s also confirm with a rollout status command;

kubectl rollout status deployments/kubernetes-bootcamp

The response we get is essentially “The deployment is out!”
Let’s make sure the update is working;

Enjoy stats such as the name (kubernetes-bootcamp), the node port (<unset> 31139/TCP), and the IP and port (10.101.170.210 and <unset> 8080/TCP),

Make an enviroment variable called NODE_PORT with the port assigned.

And there’s our variable with the corresponding number.

curl $(minikube ip):$NODE_PORT hits a different Pod with every request - all Pods are running the latest version.

Let’s also confirm with a rollout status command;

kubectl rollout status deployments/kubernetes-bootcamp

The response we get is essentially “The deployment is out!”

Perhaps the update isn’t what we wanted, so let’s roll it back.

The version is updaated to 10 and let’s see our deployments.



Hmm. One too many. That’s more resources than we need.

Using the describe modifier gives us a lot of information, but in short; There’s no image called v10 in the repository.



So let’s roll it back with the rollout command to go back to v2, and there are four pods once again.



Comments

Popular posts from this blog

Making KPI Dashboards with PowerBI

 While this is the free tier, I cannot share or collaborate with others, nor can I publish content to other people's workspaces, but they will not stop me from screenshooting and recording these self-taught adventures,so! I'm doing this because I idly searched "Mattel careers" and "Information Technology", and seeing a bulletpoint saying the following: Analytical and reporting skills such as creating dashboards and establishing KPIs such as experience with PowerBI, Cognos, Tableau, and Google Data Lake/AWS is preferred And thought "Well, I've used Tableau, and I've heard about PowerBI,  even if its in-demandness is questionable , so how similar is it? And can I write about it?"  First, PowerBI (PIB) does have a downloadable, local version, but apparently Windows-only. I could download the .exe but I couldn't run it / drag it to applications on my MacBook.  Not a problem, we'll use the online SaaS version, and a dataset found here, ...

Log Sorting with AWS CloudWatch, AWS CloudWatch Insights

 The cool thing is, I was contracted to make these videos in collaboration with CloudAvail Technology Consulting to help people decide which service they wanted to use for their logging - AWS CloudWatch, AWS CloudWatch Insights, DataDog, or New Relic. I'm searching through nginx logs. I have accompanying videos of each service that you can find on the CloudAvail Youtube page; See these links to go to the DataDog and NewRelic posts.   The idea was to be subjective in the videos, but I can be objective on my personal blog.     CloudWatch     The syntax is odd, but easy to grasp. Sort log data by IP addresses, message codes, and status codes. The simplest query system, but not quite robust.   Insights       The syntax has changed - Vastly. I see major SQL influences. You can see that in how the parse function works - in this case, it's often taken pieces of a pre-existing standard - in this case, message - and breaking them into their own c...

Connecting IoT Devices to a Registration Server (Packet Tracer, Cisco)

 If you're seeing this post, I'm helping you, and you probably have LI presence: React and share this post to help me in return.   In Packet Tracer, a demo software made by Cisco Systems. It certainly has changed a lot since 2016. It's almost an Olympic feat to even get started with it now, but it does look snazzy. This is for the new CCNA, that integrates, among other things, IoT and Automation, which I've worked on here before. Instructions here . I don't know if this is an aspect of "Let's make sure people are paying attention and not simply following blindly", or an oversight - The instructions indicate a Meraki Server, when a regular one is the working option here. I have to enable the IoT service on this server. Also, we assign the server an IPv4 address from a DHCP pool instead of giving it a static one. For something that handles our IoT business, perhaps that's safer; Getting a new IPv4 address every week or so is a minimal step against an...