The IT Hollow

Containerizing applications and running them on Kubernetes doesn’t mean we can forget all about resource utilization.

VMware offers a Kubernetes Cloud Provider that allows Kubernetes (k8s) administrators to manage parts of the vSphere infrastructure by interacting with the Kubernetes Control Plane.

VMware recently released the 1.0 release of Tanzu Kubernetes Grid (TKG) which aims at decreasing the difficulty of deploying conformant Kubernetes clusters across infrastructure.

There is a worldwide pandemic going on right now and it has disrupted practically everything.

VMware Tanzu is a family of products and services for modernizing your applications and infrastructure with a common goal: deliver better software to production, continuously.

A pretty common task that a Kubernetes administrator must do is to resize the cluster.

When we need to segment resources within a Kubernetes cluster, we often use a namespace.

I’ve written about deploying clusters in the past, but if you are a TMC customer, those steps can be skipped altogether.

No matter what flavor of Kubernetes you’re using, the cluster should have some high level of common functionality with the upstream version.

Kubernetes releases a new minor version every quarter and updating your existing clusters can be a chore.

What do you do if you’ve already provisioned some Kubernetes clusters before you got Tanzu Mission Control?

Controlling access to a Kubernetes cluster is an ongoing activity that must be done in conjunction with developer needs and is often maintained by operations or security teams.

Most of the blog posts I write about Kubernetes have examples using publicly available images from public image registries like DockerHub or Google Container Registry.

Recently I was tasked with setting up some virtual machines to be used as a load balancer for a Kubernetes cluster.

Its 2020 and I’ve had plenty of time at home due to the social distancing and global pandemic going on.

Sometimes things don’t go quite as we’ve planned.

If you’ve been on the operations side of the IT house, you know that one of your primary job functions is to ensure High Availability (HA) of production workloads.

You’ve stood up your Kubernetes (k8s) cluster and are really looking forward to all of your coworkers deploying containers on it.

The way you deploy Kubernetes (k8s) on AWS will be similar to how it was done in a previous post on vSphere.

If you’re struggling to deploy Kubernetes (k8s) clusters, you’re not alone.

Sometimes we need to run a container to do a specific task, and when its completed, we want it to quit.

One of my least favorite parts of computers is dealing with certificate creation.

Securing and hardening our Kubernetes clusters is a must do activity.

There are a myraid of ways to deploy Kubernetes clusters these days.

Deploying Kubernetes clusters may be the biggest hurdle in learning Kubernetes and one of the challenges in managing Kubernetes.

In the traditional server world, we’ve taken great lengths to ensure that we can micro-segment our servers instead of relying on a few select firewalls at strategically defined chokepoints.

In programming, we sometime set breakpoints as a way of debugging our code.

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.

So Long AHEAD I have been fortunate to work for a fantastic company the past five and half years.

If you’ve just gotten started with Kubernetes, you might be curious to know how the desired state is achieved?

I don’t know about you, but I learn things best when I have a visual to reference.

DaemonSets can be a really useful tool for managing the health and operation of the pods within a Kubernetes cluster.

Today Sysdig announced a new update to their Cloud Native Visibility and Security Platform, with the release of Sysdig Secure 2.4.

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.

You’ve been dabbling in the world of Kubernetes for a while now and have probably noticed there are a whole lot of vendors packaging their own version of Kubernetes.

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.

We’re getting into the habit of tagging everything these days.

The Kubernetes series has now ventured into some non-native k8s discussions.

The focus of this post is on pod based backups, but this could also go for Deployments, replica sets, etc.

As with all systems, we need to be able to secure a Kubernetes cluster so that everyone doesn’t have administrator privileges on it.

Learning new things can be pretty exciting, and lucky for IT Professionals, there is no lack of things to learn.

We love deployments and replica sets because they make sure that our containers are always in our desired state.

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.

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.

Containers are often times short lived.

Secret, Secret, I’ve got a secret!

Sometimes you need to add additional configurations to your running containers.

DNS is a critical service in any system.

It’s time to look closer at how we access our containers from outside the Kubernetes cluster.

You’ve been working with Kubernetes for a while now and no doubt you have lots of clusters and namespaces to deal with now.