Containers on The IT Hollow

Kubernetes - Role Based Access

Mon, 20 May 2019 14:10:48 +0000

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.

Kubernetes - StatefulSets

Mon, 01 Apr 2019 14:20:48 +0000

We love deployments and replica sets because they make sure that our containers are always in our desired state. If a container fails for some reason, a new one is created to replace it. But what do we do when the deployment order of our containers matters? For that, we look for help from Kubernetes StatefulSets.

StatefulSets - The Theory

StatefulSets work much like a Deployment does. They contain identical container specs but they ensure an order for the deployment. Instead of all the pods being deployed at the same time, StatefulSets deploy the containers in sequential order where the first pod is deployed and ready before the next pod starts. (NOTE: it is possible to deploy pods in parallel if you need them to, but this might confuse your understanding of StatefulSets for now, so ignore that.) Each of these pods has its own identity and is named with a unique ID so that it can be referenced.

Kubernetes - Cloud Providers and Storage Classes

Wed, 13 Mar 2019 14:20:23 +0000

In the previous post we covered Persistent Volumes (PV) and how we can use those volumes to store data that shouldn’t be deleted if a container is removed. The big problem with that post is that we have to manually create the volumes and persistent volume claims. It would sure be nice to have those volumes spun up automatically wouldn’t it? Well, we can do that with a storage class. For a storage class to be really useful, we’ll have to tie our Kubernetes cluster in with our infrastructure provider like AWS, Azure or vSphere for example. This coordination is done through a cloud provider.

Kubernetes - Persistent Volumes

Mon, 04 Mar 2019 15:00:51 +0000

Containers are often times short lived. They might scale based on need, and will redeploy when issues occur. This functionality is welcomed, but sometimes we have state to worry about and state is not meant to be short lived. Kubernetes persistent volumes can help to resolve this discrepancy.

Volumes - The Theory

In the Kubernetes world, persistent storage is broken down into two kinds of objects. A Persistent Volume (PV) and a Persistent Volume Claim (PVC). First, lets tackle a Persistent Volume.

Kubernetes - Secrets

Mon, 25 Feb 2019 15:00:56 +0000

Secret, Secret, I’ve got a secret! OK, enough of the Styx lyrics, this is serious business. In the previous post we used ConfigMaps to store a database connection string. That is probably not the best idea for something with a sensitive password in it. Luckily Kubernetes provides a way to store sensitive configuration items and its called a “secret”.

Secrets - The Theory

The short answer to understanding secrets would be to think of a ConfigMap, which we have discussed in a previous post in this series, but with non-clear text.

Kubernetes - ConfigMaps

Wed, 20 Feb 2019 15:00:40 +0000

Sometimes you need to add additional configurations to your running containers. Kubernetes has an object to help with this and this post will cover those ConfigMaps.

ConfigMaps - The Theory

Not all of our applications can be as simple as the basic nginx containers we’ve deployed earlier in this series. In some cases, we need to pass configuration files, variables, or other information to our apps.

The theory for this post is pretty simple, ConfigMaps store key/value pair information in an object that can be retrieved by your containers. This configuration data can make your applications more portable.

Kubernetes - Service Publishing

Tue, 05 Feb 2019 16:30:54 +0000

A critical part of deploying containers within a Kubernetes cluster is understanding how they use the network. In previous posts we’ve deployed pods and services and were able to access them from a client such as a laptop, but how did that work exactly? I mean, we had a bunch of ports configured in our manifest files, so what do they mean? And what do we do if we have more than one pod that wants to use the same port like 443 for https?

Kubernetes - Endpoints

Mon, 04 Feb 2019 15:00:02 +0000

It’s quite possible that you could have a Kubernetes cluster but never have to know what an endpoint is or does, even though you’re using them behind the scenes. Just in case you need to use one though, or if you need to do some troubleshooting, we’ll cover the basics of Kubernetes endpoints in this post.

Endpoints - The Theory

During the post where we first learned about Kubernetes Services, we saw that we could use labels to match a frontend service with a backend pod automatically by using a selector. If any new pods had a specific label, the service would know how to send traffic to it. Well the way that the service knows to do this is by adding this mapping to an endpoint. Endpoints track the IP Addresses of the objects the service send traffic to. When a service selector matches a pod label, that IP Address is added to your endpoints and if this is all you’re doing, you don’t really need to know much about endpoints. However, you can have Services where the endpoint is a server outside of your cluster or in a different namespace (which we haven’t covered yet).

Kubernetes - Services and Labels

Thu, 31 Jan 2019 15:00:54 +0000

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.

Kubernetes - Deployments

Wed, 30 Jan 2019 15:01:37 +0000

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.

Kubernetes - Replica Sets

Mon, 28 Jan 2019 15:00:59 +0000

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.

Kubernetes - Pods

Mon, 21 Jan 2019 16:30:30 +0000

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.

Deploy Kubernetes Using Kubeadm - CentOS7

Mon, 14 Jan 2019 15:35:36 +0000

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.

How to Setup Amazon EKS with Mac Client

Tue, 31 Jul 2018 14:06:02 +0000

We love Kubernetes. It’s becoming a critical platform for us to manage our containers, but deploying Kubernetes clusters is pretty tedious. Luckily for us, cloud providers such as AWS are helping to take care of these tedious tasks so we can focus on what is more important to us, like building apps. This post shows how you can go from a basic AWS account to a Kubernetes cluster for you to deploy your applications.

How to Setup Amazon EKS with Windows Client

Mon, 30 Jul 2018 16:05:09 +0000