Kubernetes

In this post we’ll start exploring ways that you might be able to better manage your Kubernetes cluster for security or organizational purposes. Namespaces become a big piece of how your Kubernetes cluster operates and who sees what inside your cluster. Namespaces - The Theory The easiest way to think of a namespace is that its a logical separation of your Kubernetes Cluster. Just like you might have segmented a physical server into several virtual severs, we can segment our Kubernetes cluster into namespaces. Namespaces are used to isolate resources within the control plane. For example if we were to deploy a pod in two different namespaces, an administrator running the “get pods” command may only see the pods in one of the namespaces. The pods could communicate with each other across namespaces however. ...

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? ...

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). ...

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. ...

The following posts are meant to get a beginner started with the process of understanding Kubernetes. They include basic level information to start understanding the concepts of the Kubernetes service and include both theory and examples. To follow along with the series, a Kubernetes cluster should be deployed and admin permissions are needed to perform many of the steps. If you wish to follow along with each of the posts, a cluster with cloud provider integration may be needed. In some cases we need a Load Balancer and elastic storage options. ...

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. ...