Tag - Kubernetes

During my last post I was trying to restore a demo Wordpress deployment using Velero. The deployment itself was nothing fancy, and was exposed via NodePort instead of an Ingress. The restored app would start as expected but was not accessible with the same NodeIP:NodePort combination that I had from its initial deployment. Here’s my Wordpress manifest (lovingly taken from https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/): apiVersion: v1 kind: Service metadata: name: wordpress-mysql labels: app: wordpress spec: ports: - port: 3306 selector: app: wordpress tier: mysql clusterIP: None --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: wordpress-mysql labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: mysql strategy: type: Recreate template: metadata: labels: app: wordpress tier: mysql spec: containers: - image: mysql:8.

I recently posted how to upgrade VMware Cloud Director’s Container Service Extension from 4.0.1 to 4.0.3. The next step in the journey is to configure the new CAPVCD provider (1.0.1) on any existing Kubernetes clusters deployed by CSE, and then upgrade those clusters from TKG 1.5.4 images to TKG 1.6.1 images. Wait, what am I updating? Kubernetes clusters deployed by CSE include what’s called a Cluster API Provider (CAP) for VMware Cloud Director (VCD) which is where we get CAPVCD.

I’ve got VMware Cloud Director Container Service Extension (CSE) 4.0.1 running in my lab to test and demo Kubernetes Clusters as-a-service in Cloud Director. CSE 4.0.3 was released on the 20th of April 2023 and came with significant improvements. Let’s take a look at my current environment: VCD 10.4.1 CSE UI Plugin 4.0.1 CSE Server 4.0.1 vSphere 7.0U3 NSX-T 4.0.1.1 NSX ALB (Avi) 22.1.2-9086 Based on the above, I don’t need to change a single thing for CSE 4.