Kubernetes 1.23: Dual Stack IPv4/IPv6, CronJobs, Ephemeral Volumes
In the world of cloud native development, the second you blink, you’ve missed something. That’s how quickly things evolve. So much so, it seems it was only yesterday that Kubernetes 1.22 came out 1.22 (It was on Aug. 22 actually).
As they say, that was then, this is now. And the now is all about Kubernetes 1.23 GA (due today, according to the Cloud Native Computing Foundation) This new release is packed with danceable tunes, with over 45 enhancements (11 of which are graduating to stable, 15 have been improved, and 19 are brand-spanking-new). And although those new features might not all be top ten hits, some of them might be very helpful to those working with Kubernetes. However, the real spotlight belongs to the features in 1.23 that have graduated to GA (stability), so they’re ready for production.
Let’s first take a look at the features that have graduated to stable (because those are the ones you’re going to want to immediately start using). Then we’ll take a look at all the other improvements standing in the shadows at this dance, hoping to be noticed.
Hit the lights and cue the disco ball, it’s time to party, Kubernetes style.
Graduating to Stable
Sitting at the top of the graduation list, you’ll find four very exciting features: IPv4/IPv6 dual-stack support, CronJobs, Ephemeral volumes, and the HPA API. Let’s take a look at each of these.
IPv4/IPv6 Dual-Stack Support
With IPv6/IPv6 dual-stack support, Kubernetes can now natively support dual-stack mode in a cluster. That means you can assign both IPv4 and IPv6 addresses to any given pod or service. This is configured with the .spec.ipFamilyPolicy field, which can be set to one of the following:
- SingleStack
- PreferDualStack
- RequireDualStack
To use dual-stack support, you’ll need to set .spec.ipFamilyPolicy to either PreferDualStack or RequireDualStack. This feature is enabled by default in Kubernetes and also includes pod off-cluster egress routing via both IPv4 and IPv6 addresses.
CronJobs
The CronJobs feature makes it possible to run periodic tasks within a Kubernetes cluster. Kubernetes CronJobs is very similar to the Linux cron system. CronJobs has been around since Kubernetes 1.4 and has been widely accepted in production since it reached CRI support in iteration 1.5.
A CronJob is defined in a YAML file as:
kind: CronJob
A sample CronJob manifest to print out “Hello Newstack” every 10 minutes might look like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: batch/v1 kind: CronJob metadata: name: hello spec: schedule: "*/10 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; echo Hello Newstack restartPolicy: OnFailure |
For those that don’t know the cron syntax, it’s like this:
| MINUTE | HOUR | DAY OF MONTH | MONTH | DAY OF WEEK |
If you’re unsure how to create a cronjob, I highly recommend starting with Crontab Guru, which allows you to plug in values into a cronjob and see exactly what they would generate.
Ephemeral Volumes
Ephemeral volumes have been around since Kubernetes 1.19 and allow you to create volumes for specific pods that are then deleted when the pod terminates. In other words, these are temporary volumes.
There are four types of ephemeral volumes supported in Kubernetes, which are:
- emptyDir — an empty volume available at Pod startup that uses storage from the kubelet base directory or RAM.
- configMap, downwardAPI, secret — injects different kinds of Kubernetes data into a specified Pod.
- CSI ephemeral volumes — similar to the other types, but is provided by special CSI drivers.
- generic ephemeral volumes — are provided by all storage drivers (that support persistent storage)
A sample manifest that uses ephemeral storage might look something like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
kind: Pod apiVersion: v1 metadata: name: sample-storage-app spec: containers: - name: storage-frontend image: busybox volumeMounts: - mountPath: "/storage" name: sample-storage-app-vol command: [ "sleep", "1000000" ] volumes: - name: sample-storage-app-vol csi: driver: inline.storage.kubernetes.io volumeAttributes: |
HPA API v2
The Horizontal Pod Autoscaleer API isn’t new to the Kubernetes dance. In fact, it was first introduced in 2016. This feature is responsible for automatically scaling the number of pods in a replication controller, deployment, replica set, or stateful set. The scaling is based on metrics of the following types:
- Resource usage — when a Pod exceeds a threshold of memory or CPU usage. This can be expressed as either a raw value or percentage.
- Custom metrics — this is based on a Kubernetes-reported metric (i.e. rate of client requests per second).
- External metrics — this is based on metrics provided by an external application or service.
Autosaclers operate using a control loop, with a period controlled by the --horizontal-pod-autoscaler-sync-period flag. The default value is 15 seconds. During the control loop, the controller queries the resource utilization of a Pod against the metrics configured in the HorizontalPodAutoscaler definition.
Deprecations and Beta Graduations
There have also been three deprecations of note for Kubernetes 1.23. These include:
- HPA v2beta2 API
- FlexVolume
- klog specific flags
A couple of features have also graduated to beta, including:
- PodSecurity — which replaces the PodSecurityPolicy admission controller.
- Structured logging — most log messages from both kubelet and kube-scheduler have been converted and it’s been recommended that users try out the JSON output.
New Features in Alpha
Kubernetes 1.23 also includes a few new features that are now in alpha. These include:
- Expression language validation for CRD — If
CustomResourceValidationExpressionsis enabled, custom resources will be validated by rules using the Common Expression Language. - Server Side Field Validation — If
ServerSideFieldValidationis enabled, users will receive warnings from the server when unknown or duplicate fields are detected in a request. - OpenAPI v3 —
OpenAPIVis enabled users will be able to request the OpenAPI v3 spec for all Kubernetes types.
For more information on the new release, make sure to check out the full release notes.