Recently-Added

As with all systems, we need to be able to secure a Kubernetes cluster so that everyone doesn’t have administrator privileges on it. I know this is a serious drag because no one wants to deal with a permission denied error when we try to get some work done, but permissions are important to ensure the safety of the system. Especially when you have multiple groups accessing the same resources. We might need a way to keep those groups from stepping on each other’s work, and we can do that through role based access controls. ...

Whenever I talk cloud with a customer, there is inevitably a discussion around how much the cloud costs vs what is in the data center. The conversation usually starts with one of several declarations. “The Cloud is more expensive than on-premises but we want the capabilities anyway.” “We need the Cloud so we can drive down our costs.” Well yes, if you’ve paid attention, those are two different arguments about why you need cloud, and both of them came to different conclusions about whether or not the public cloud is more expensive or less expensive than running your own data center. ...

If you’ve been following the series, you may be thinking that we’ve built ourselves a problem. You’ll recall that we’ve now learned about Deployments so that we can roll out new pods when we do upgrades, and replica sets can spin up new pods when one dies. Sounds great, but remember that each of those containers has a different IP address. Now, I know we haven’t accessed any of those pods yet, but you can imagine that it would be a real pain to have to go lookup an IP Address every time a pod was replaced, wouldn’t it? This post covers Kubernetes Services and how they are used to address this problem, and at the end of this post, we’ll access one of our pods … finally. ...

After following the previous posts, we should feel pretty good about deploying our pods and ensuring they are highly available. We’ve learned about naked pods and then replica sets to make those pods more HA, but what about when we need to create a new version of our pods? We don’t want to have an outage when our pods are replaced with a new version do we? This is where “Deployments” comes into play. ...

In a previous post we covered the use of pods and deployed some “naked pods” in our Kubernetes cluster. In this post we’ll expand our use of pods with Replica Sets. Replica Sets - The Theory One of the biggest reasons that we don’t deploy naked pods in production is that they are not trustworthy. By this I mean that we can’t count on them to always be running. Kubernetes doesn’t ensure that a pod will continue running if it crashes. A pod could die for all kinds of reasons such as a node that it was running on had failed, it ran out of resources, it was stopped for some reason, etc. If the pod dies, it stays dead until someone fixes it which is not ideal, but with containers we should expect them to be short lived anyway, so let’s plan for it. ...

Amazon Web Services has released yet another service designed to improve the lives of people administering an AWS environment. There is a new backup service, cleverly named, AWS Backup. This new service allows you to create a backup plan for Elastic Block Store (EBS) volumes, Elastic File System (EFS), DynamoDB, Relational Database Services (RDS), and Storage Gateway. Now we can build plans to automatically backup, tier and expire old backups automatically based on our own criteria. ...

We’ve got a Kubernetes cluster setup and we’re ready to start deploying some applications. Before we can deploy any of our containers in a kubernetes environment, we’ll need to understand a little bit about pods. Pods - The Theory In a docker environment, the smallest unit you’d deal with is a container. In the Kubernetes world, you’ll work with a pod and a pod consists of one or more containers. You cannot deploy a bare container in Kubernetes without it being deployed within a pod. ...

I’ve been wanting to have a playground to mess around with Kubernetes (k8s) deployments for a while and didn’t want to spend the money on a cloud solution like AWS Elastic Container Service for Kubernetes or Google Kubernetes Engine . While these hosted solutions provide additional features such as the ability to spin up a load balancer, they also cost money every hour they’re available and I’m planning on leaving my cluster running. Also, from a learning perspective, there is no greater way to learn the underpinnings of a solution than having to deploy and manage it on your own. Therefore, I set out to deploy k8s in my vSphere home lab on some CentOS 7 virtual machines using Kubeadm. I found several articles on how to do this but somehow I got off track a few times and thought another blog post with step by step instructions and screenshots would help others. Hopefully it helps you. Let’s begin. ...

Okay, I’m scared of change just like everyone else. I have been building Visios for a pretty long time and know where all the menus are so I’m pretty fast with it. But I do use a Macbook when I travel and firing up Fusion just to run Visio is frustrating. I thought since it’s a new year I should try Lucidchart and see what I though. Now I’m still kind of fond of Visio, but the Integrations feature with Lucidchart on top of the web interface allowing me to use it anywhere, is enough to make me drop Visio for the long haul. ...

I recently attended the Devops Enterprise Summit in Las Vegas so that I could keep up to date on the latest happenings around integrating devops for companies. This conference was nothing short of amazing, but what I wasn’t anticipating was a theme around IT burnout. The IT Revolutions team who puts on the conference started one of the keynotes on the topic of burnout, from Dr. Christina Maslach who is Professor of Psychology, Emerita University of California, Berkeley. In addition to this powerful session, there was another panel group that happened on Wednesday, that went further into the discussion including the ultimate consequence of burnout, which is suicide. ...