Recently-Added

Securing and hardening our Kubernetes clusters is a must do activity. We need to remember that containers are still just processes running on the host machines. Sometimes these processes can get more privileges on the Kubernetes node than they should, if you don’t properly setup some pod security. This post explains how this could be done for your own clusters. Pod Security Policies - The Theory Pod Security policies are designed to limit what can be run on a Kubernetes cluster. Typical things that you might want to limit are: pods that have privileged access, pods with access to the host network, and pods that have access to the host processes just to name a few. Remember that a container isn’t as isolated as a VM so we should take care to ensure our containers aren’t adversely affecting our nodes’s health and security. ...

There are a myraid of ways to deploy Kubernetes clusters these days. Kubernetes the Hard Way Cluster API Kubeadm Kubespray kops Those are just a few of the ways and I’m sure you’ll have a favorite. But for the work I’ve been doing lately, I don’t want to spend a bunch of time cloning repos, updating configs, running ansible scripts and the like, just to get another clean kubernetes cluster in my lab to break. So, I took the individual parts of a Kubernetes build and created a list of ordered jobs in my Jenkins server. ...

In programming, we sometime set breakpoints as a way of debugging our code. Maybe a small piece of our routine isn’t functioning optimally and we want the program to pause, part way through, so we can identify the issues with that one section of code. These breakpoints might be great for coding, but we can apply this to our own lives as well. I’ve recently switched jobs and between ending my previous job and starting the new one, I took some time off. My own personal breakpoint where I paused the larger routine (in this metaphor, the routine is my work life) so that I could focus on pieces of my life that might need more attention. ...

I’m not going to lie to you, as of the time of this writing, maybe the biggest hurdle to learning Kubernetes is getting a cluster stood up. Right now there are a myriad of ways so stand up a cluster, but none of them are really straight forward yet. If you’re interested in learning how Kubernetes works, and just want to setup a basic cluster to poke around in, this post is for you. ...

So Long AHEAD I have been fortunate to work for a fantastic company the past five and half years. While starting at AHEAD I had ambitions to be a top caliber VMware expert and work with people who would challenge me. Part of my decision to join the AHEAD team was to see how good I really was. AHEAD had plenty of talent and three VCDXs when I started and I needed to know how I stacked up. In the end, I think I did OK. ...

If you’ve just gotten started with Kubernetes, you might be curious to know how the desired state is achieved? Think about it, you pass a YAML file to the API server and magically stuff happens. Not only that, but when disaster strikes (e.g. pod crashes) Kubernetes also makes it right again so that it matches the desired state. The mechanism that allows for Kubernetes to enforce this desired state is the control loop. The basics of this are pretty simple. A control loop can be though of in three stages. ...

Today Sysdig announced a new update to their Cloud Native Visibility and Security Platform, with the release of Sysdig Secure 2.4. The new version of the Secure product includes some pretty nifty enhancements. Runtime profiling with machine learning - New containers will be profiled after deployment to give insights into the processes, file system activity, networking and system calls. Once the profiling is complete, these profiles can be used to create policy sets for the expected behavior. Sysdig also offers a confidence level of the profile. Consistent behavior generating a higher confidence level whereas variable behavior would have a lower level. ...

One of the best things about Kubernetes, is that I don’t have to think about which piece of hardware my container will run on when I deploy it. The Kubernetes scheduler can make that decision for me. This is great until I actually DO care about what node my container runs on. This post will examine one solution to pod placement, through taints and tolerations. Taints - The Theory Suppose we had a Kubernetes cluster where we didn’t want any pods to run on a specific node. You might need to do this for a variety of reasons, such as: ...

Any system that’s going to be deployed for the enterprise needs to have at least a basic level of monitoring in place to manage it. Kubernetes is no exception to this rule. When we, as a community, underwent the shift from physical servers to virtual infrastructure, we didn’t ignore the new VMs and just keep monitoring the hardware, we had to come up with new products to monitor our infrastructure. Sysdig is building these new solutions for the Kubernetes world. ...

The Kubernetes series has now ventured into some non-native k8s discussions. Helm is a relatively common tool used in the industry and it makes sense to talk about why that is. This post covers the basics of Helm so we can make our own evaluations about its use in our Kubernetes environment. Helm - The Theory So what is Helm? In the most simplest terms its a package manager for Kubernetes. Think of Helm this way, Helm is to Kubernetes as yum/apt is to Linux. Yeah, sounds pretty neat now doesn’t it? ...