It’s hard to believe that my first VMworld was almost 9 years ago! I feel very blessed to have attended in 2014 (EU), 2015 (EU), 2016 (US), 2017 (EU), 2018 (my first as an employee), 2019 (my first time as a speaker!), and virtually in 2020 and 2021. Over the years VMworld has been hugely formative in my career, I’ve talked many times before about how the trajectory of my career really took off when I got involved with the London VMUG, and how that led to being awarded vExpert in 2013.
In my previous post I walked through configuring kubernetes ingress with automatically generated SSL certificates and DNS registration using Tanzu Kubernetes Grid’s Packages. Another of the packaged applications available is Fluent-bit, which enables log forwarding from your Kubernetes cluster and workloads to a range of supported logging endpoints. There are a couple of tweaks required in order to forward logs to vRealize Automation Log Insight Cloud. We need to use the HTTP output in the Fluent Bit configuration to forward the logs as a JSON payload to the Log Insight API.
So, you’ve set up your shiny new Workload Management on vSphere, created a Namespace and deployed a cluster…now what?! When you deploy a workload cluster from Workload Management on vSphere 7, it comes with basic functionality, but in order to start running workloads you will inevitably need to install additional tools. That’s where Tanzu’s Packages come into play. Tanzu’s User Managed Packages are based on a project called Carvel which:
Just recently Docker announced some new pricing tiers for it’s almost ubiquitous Docker Desktop. I’m not going to opine much on this, time will tell whether this is a company saving move or not. Suffice to say that I work for a large company and would need a subscription to continue using Docker Desktop. The venerable Corey Quinn was on the news like a flash, so I’ll let you read his thread for some hard core snark analysis.
As more services go live on my Kubernetes clusters and more people start relying on them, I get nervous. For the most part, I try and keep my applications and configurations stateless - relying on ConfigMaps for example to store application configuration. This means with a handful of YAML files in my Git repository I can restore everything to working order. Sometimes though, there’s no choice but to use a PersistentVolume to provide some data persistance where you can’t capture it in a config file.
Where can you find me at VMworld 2020 VMworld 2020 - possible together VMworld 2020 is fast approaching (Sept 29th-October 1st), and in case you hadn’t heard, it online and free! If you struggle getting funding for tickets and flights normally, this could be a golden opportunity to get involved! Register for VMworld 2020 for FREE here! Please come and talk to me for my round table session, it will be awkward by myself!
I run quite a few applications in Docker as part of my home network - there’s a small selection below, but at any one time there might be 10-15 more apps I’m playing around with: plex - Streaming media server unifi - Ubiquiti Network Controller homebridge - Apple Homekit compatible smart home integration influxdb - Open source time series database grafana - Data visualization & Monitoring pihole - internet tracking and ad blocker vault - Hashicorp secret management Until recently a single PhotonOS VM with Docker was all I needed to run - everything shared the same host IP, stored it’s configuration locally or on an NFS mount and generally ran fine.
I have been working with VMware Cloud Foundation recently and while for the most part things went well there were occasions where challenges were encountered which made the delivery to the customer all the more trickier than expected. This article is a list of observations and things to most definitely check or watch out for when delivering a VCF project. We were working with VCF version 3.7.2 (yes I am aware 3.
Following on from me recent post deploying Kubernetes with the NSX-T CNP, I wanted to extend my environment to make use of the vSphere Cloud Provider to enable Persistent Volumes backed by vSphere storage. This allows me to use Storage Policy to create Persistent Volumes based on policy. For example, I’m going to create two classes of storage, Fast and Slow - Fast will be vSAN based and Slow will be NFS based.
I’ve done a fair amount of work learning VMware PKS and NSX-T, but I wanted to drop down a level and get more familiar with the inner workings for Kubernetes, as well as explore some of the newer features that are exposed by the NSX Container Plugin that are not yet in the PKS integrations. The NSX-T docs are…not great, I certainly don’t think you can work out the steps required from the official NCP installation guide without a healthy dollop of background knowledge and familiarity with Kubernetes and CNI.