Author: Claudio Masolo

Google Cloud has announced a suite of new tools and features designed to help organizations reduce costs and improve efficiency of AI workloads across their cloud infrastructure. The announcement comes as enterprises increasingly seek ways to optimize spending on AI initiatives while maintaining performance and scalability.

The new features focus on three key areas: compute resource optimization, specialized hardware acceleration, and intelligent workload scheduling. These improvements aim to address one of the primary challenges enterprises face when deploying AI at scale—balancing innovation with cost management.

In the announcement, Google Cloud’s VP of AI Products said:

Organizations are increasingly looking for ways to optimize their AI costs without sacrificing performance or capability, these new features directly address that need by providing more efficient ways to run machine learning training and inference.

Google Cloud’s approach begins with strategic platform selection. Organizations now have multiple options ranging from fully-managed services to highly customizable solutions. Vertex AI offers a unified, fully managed AI development platform that eliminates infrastructure management concerns, while Cloud Run with GPU support provides a scalable inference service option. For long-running tasks, Cloud Batch combined with Spot Instances can significantly reduce costs. Organizations with existing Kubernetes expertise may benefit from Google Kubernetes Engine (GKE), while those requiring maximum control can utilize Google Compute Engine.

A key recommendation focuses on optimizing container performance. When working with inference containers in environments like GKE or Cloud Run, Google advises keeping containers lightweight by externally storing models using Cloud Storage with FUSE, Filestore, or shared read-only persistent disks. This approach dramatically reduces container startup times and improves scaling efficiency—critical factors in managing both performance and costs.

Storage selection emerges as another critical factor in optimization. Google Cloud recommends Filestore for smaller AI workloads, Cloud Storage for object storage at any scale, and Cloud Storage FUSE for mounting storage buckets as a file system. For workloads requiring lower latency, Parallelstore provides sub-millisecond access times, while Hyperdisk ML delivers high-performance storage specifically engineered for serving tasks.

To prevent costly delays in resource acquisition, Google Cloud emphasizes the importance of Dynamic Workload Scheduler and Future Reservations. These tools secure needed cloud resources in advance, guaranteeing availability when required while optimizing the procurement process for popular hardware components.

The final strategy addresses deployment efficiency through custom disk images. Rather than repeatedly configuring operating systems, GPU drivers, and AI frameworks from scratch, organizations can create and maintain custom disk images that allow new, fully-configured workers to deploy in seconds rather than hours.

AI cost management has become increasingly critical across industries, in response to the growing demand for more efficient and cost-effective AI infrastructure, both AWS and Microsoft Azure have also ramped up their efforts to support enterprise AI workloads. AWS has introduced new cost-aware tools within its SageMaker platform, including Managed Spot Training and model monitoring capabilities to help users optimize both performance and budget. Similarly, Azure is enhancing its AI offering through Azure Machine Learning with features like intelligent autoscaling, reserved capacity pricing, and seamless integration with Azure Kubernetes Service (AKS) for better workload orchestration.

Like Google Cloud, both AWS and Azure are emphasizing hybrid flexibility, storage optimization, and GPU acceleration to give enterprises more control over how they scale and spend. This convergence signals a competitive push across cloud providers to address the pressing challenge of AI cost management while still empowering innovation at scale.

TraefikLabs recently announced the latest release of Traefik Proxy v3.3 (codenamed “saint-nectaire” due to a French cheese). This release focuses primarily on two critical areas: observability capabilities and improved documentation structure. These enhancements aim to make the popular open-source reverse proxy even more powerful for platform engineers working in complex cloud-native environments.

Observability has become essential in modern infrastructure, allowing engineers to quickly identify and recover from service disruptions. Traefik v3.3 significantly expands its observability toolkit through extended OpenTelemetry integration. Building on the foundation established in v3.0, this release adds experimental support for logs and access logs alongside existing metrics and tracing capabilities. This creates a comprehensive observability solution that provides complete visibility into ingress traffic patterns.

Additionally, the new version introduces granular configuration control. Previously, observability features could only be enabled globally. With v3.3, platform engineers can now define default behaviors at the entryPoint level, enable or disable tracing, metrics, and access logs on a per-router basis, override inherited configurations for specific routers, and apply temporary observability settings during troubleshooting. This flexibility allows teams to implement precise monitoring strategies tailored to their specific needs, reducing unnecessary data collection while ensuring critical services remain observable.

This is now equivalent:

entryPoints:
  foo:
	address: ':80'

To this:

entryPoints:
  foo:
	address: ':80'
	observability:
  	tracing: true

In this release, Traefik has begun a major revamp of its documentation architecture, recognizing this as a crucial entry point for users. The v3.3 release delivers the first milestone with a completely reorganized reference section that targets three distinct personas: beginners, advanced operators, and advanced developers. It separates high-level use cases from detailed configuration options and creates a more intuitive structure for finding information.

The new reference documentation follows a logical progression from installation through configuration discovery, entry points, observability settings, and more. This improved organization helps both newcomers and experienced users quickly locate the information they require.

Beyond the core focus areas, v3.3 introduces several quality-of-life improvements. These include better control over ACME (Let’s Encrypt) propagation checks, configuration dump support via API endpoint for easier troubleshooting, optional IngressRoute kind in Kubernetes configurations, and Kubernetes serving endpoint status support for stickiness. The update also brings configurable paths for sticky cookies, host header configuration in the HTTP provider, preservation of Location headers in ForwardAuth middleware, and more efficient basic auth hash calculation for concurrent requests. Platform engineers will also appreciate request body forwarding to authorization servers, configurable API and Dashboard base paths, and the option to abort startup if plugin loading fails.

When considering alternatives to Traefik Proxy, many other reverse proxies and load balancers stand out: Nginx, serves as both a web server and a reverse proxy, offering stability and low resource consumption, making it ideal for handling high-traffic applications. For those seeking simplicity with built-in automatic HTTPS, Caddy is another option, featuring an easy-to-use configuration and strong security defaults. Envoy Proxy, originally developed by Lyft, is a cloud-native proxy that excels in dynamic service discovery, observability, and advanced traffic management, making it a great fit for microservices architectures. Lastly, Kong doubles as an API gateway and microservices management tool, providing authentication, rate limiting, and logging functionalities on top of Nginx. Each of these alternatives presents unique strengths, catering to different needs based on security, scalability, and ease of use.

The Grafana k6 team releases a new version of its open-source load testing tool approximately every two months, bringing new features and improving user experience. Several recent updates have introduced key improvements, notably related to TypeScript support, ECMAScript compatibility, and enhancements to browser testing, gRPC, memory management, cryptography, and test result storage.

One of the major updates introduced in the k6 version 0.52 release is allowing native support for TypeScript. Previously, developers using TypeScript with k6 were required to bundle their scripts using tools like Webpack or Rollup before running them. With this update, TypeScript tests can now be run directly from the k6 command-line interface (CLI) by using a special compatibility mode option. This new feature significantly simplifies the testing process for developers who prefer TypeScript, making it easier to work with k6, especially when reusing existing TypeScript libraries.

In addition to TypeScript, the v0.52 release also introduced support for a range of ECMAScript 6 (ES6) and newer features that had previously been unavailable in k6. These include features like optional chaining, object spread, and private class fields. By incorporating these ECMAScript (ES+) features, k6 has become more compliant with the modern JavaScript ecosystem, allowing developers to utilize contemporary JavaScript syntax without the need for workarounds. As of the k6 v0.53 release, these ES6+ features are now available in the default compatibility mode, making it even easier for developers to use them without any special configuration.

Another area of focus in recent k6 updates has been the browser testing module. Initially introduced in 2021, the browser module did not support asynchronous operations or the JavaScript async and await keywords. This changed with the k6 v0.52 release, where browser APIs were made fully asynchronous, aligning with the broader JavaScript ecosystem and ensuring compatibility with tools like Playwright. This update has made the browser testing experience more user-friendly and intuitive, although it did introduce breaking changes to existing browser scripts. To help users adapt to these changes, the k6 team provided a migration guide detailing the affected APIs and how to modify existing scripts to ensure compatibility. The browser module has now officially graduated from experimental status to a core module, making it stable and available under k6/browser instead of k6/experimental/browser.

Alongside the browser module, the gRPC streaming functionality also underwent significant changes. In the k6 v0.51 release, the grpc. Stream feature, which supports bi-directional gRPC streaming, was fully integrated into the stable k6/net/grpc module. This graduation ensures that no further breaking changes will occur, allowing developers to confidently use the gRPC APIs in their tests and upgrade to future versions without concern. In addition, the gRPC module now supports non-blocking asynchronous operations with the client.asyncInvoke method, which returns a Promise and provides more efficient performance.

The k6 v0.51 release also addressed the challenge of running load tests with large files, which previously led to Out of Memory (OOM) errors. While the SharedArray object had provided some relief, it still loaded all file content into memory. To tackle this, the k6 team introduced the Stream module, which allows developers to read large files in small chunks, reducing memory consumption and significantly improving efficiency. The new Stream API enables k6 to handle large datasets by loading them piece by piece, preventing OOM issues during testing.

Additionally, the k6 v0.51 release made common JavaScript timer methods like setTimeout, clearTimeout, setInterval, and clearInterval globally available. Previously, these methods had to be imported from the k6/timers or k6/experimental/timers modules. By making these methods globally accessible, k6 now aligns more closely with the behaviour of other JavaScript environments and simplifies the process of managing asynchronous operations within tests.

Cryptographic operations have also seen improvements in recent k6 releases. The tool now supports additional Web Crypto methods, including new asymmetric cryptography algorithms such as ECDH and ECDSA, along with support for pkcs8 and spki formats. It also supports the import and export of keys in JSON Web Key (JWK) format, further enhancing k6’s ability to test secure applications that use cryptography. While the webcrypto module remains a work in progress, these updates are a step forward in making cryptographic testing more robust within k6.

Finally, the integration of OpenTelemetry (OTEL) into k6’s core functionality was another important update introduced in the k6 v0.53 release. OTEL has become a standard for telemetry and observability, and its inclusion in k6 allows users to send test results directly to OpenTelemetry backends. This addition enables k6 users to map k6 metrics and tags to OTEL equivalents and output test results to default OTEL exporters without needing additional configurations. This further expands k6’s flexibility in how test results are stored and analyzed, integrating it with industry-standard telemetry tools.

In addition to k6, other noteworthy load testing tools include Autocannon and Locust. Autocannon, written in Node.js, is a fast HTTP benchmarking tool designed for testing web server performance under heavy traffic. It provides key metrics like throughput and latency. Meanwhile, Locust is an open-source load testing tool that uses Python scripts to define custom user behaviour. It can simulate millions of concurrent users, making it ideal for large-scale performance testing.

The Kubernetes SIG Network announced the version 1.1 of Gateway API. This update sees several key features moving to the Standard Channel (GA), including support for service mesh and GRPCRoute. Additionally, new experimental features such as session persistence and client certificate verification have been introduced.

The v1.1 release marks the transition of four highly anticipated features from experimental to Standard. This signifies confidence in the API’s stability and provides backward compatibility guarantees. Standard Channel features will continue to evolve with backward-compatible enhancements.

Gateway API now supports service mesh, enabling users to manage both ingress and mesh traffic with a unified API. Routes like HTTPRoute can now reference a Service as a parentRef, allowing for precise traffic control to specific services. To go deeper into this feature, check out the Gateway API documentation.

A possible implementation of canary deployment with HTTPRoute is the following:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

This configuration splits traffic 50/50 between the original color Service and the color2 Service in the faces namespace.

GRPCRoute has been part of the Standard Channel since v1.1.0. For users of the experimental channel, it is recommended to wait for controller updates before upgrading to the standard channel version. Meanwhile, the experimental channel version in v1.1 includes both v1alpha2 and v1 API versions.

HTTPRoute is a Gateway API type for specifying routing behavior of HTTP requests. Each Route provides a method to reference the parent resources it intends to attach to. Typically, this will be Gateways, but implementations have the flexibility to support other types of parent resources as well. The port field has been added to ParentReference, allowing resources to be attached to Gateway Listeners, Services, or other parent resources by specifying the port. This enables attachment to multiple Listeners simultaneously.

Example of attaching an HTTPRoute to specific Gateway Listeners by port:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httproute-example
spec:
  parentRefs:
  - name: acme-lb
    port: 8080

Note that the target Gateway needs to allow HTTPRoutes from the route’s namespace to be attached for the attachment to be successful and binding to a port also allows attaching to multiple listeners at once

The conformance report API now includes the mode field and gatewayAPIChannel (standard or experimental). The gatewayAPIVersion and gatewayAPIChannel are automatically populated, and the reports are better structured, allowing implementations to include testing details and reproduction steps.

A new addition to the experimental channel is about Gateways. In particular, it is now possible to configure client certificate verification for each Gateway Listener using the new frontendValidation field within TLS. This field allows the configuration of CA Certificates to validate client certificates.

An example of configuration is the following:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

Another new addition to the experimental channel is Session persistence. It is introduced via a new policy (BackendLBPolicy) for Service-level configuration and as fields within HTTPRoute and GRPCRoute for route-level configuration. These settings include session timeouts, session name, session type, and cookie lifetime.

An Example of BackendLBPolicy configuration for cookie-based session persistence is the following:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

To ensure consistent TLS terminology, breaking changes have been made to BackendTLSPolicy, resulting in a new API version (v1alpha3). Implementations must handle this version upgrade by updating references and configurations accordingly.

Other notable changes:

• targetRef becomes targetRefs
• tls becomes validation
• tls.caCertRefs becomes validation.caCertificateRefs
• tls.wellKnownCACerts becomes validation.wellKnownCACertificates

Unlike other Kubernetes APIs, upgrading to the latest Kubernetes version isn’t necessary to use the newest Gateway API. As long the cluster is on Kubernetes 1.26 or later, it is possible to start using the latest Gateway API right away.

The Kubernetes SIG Network announced the version 1.1 of Gateway API. This update sees several key features moving to the Standard Channel (GA), including support for service mesh and GRPCRoute. Additionally, new experimental features such as session persistence and client certificate verification have been introduced.

The v1.1 release marks the transition of four highly anticipated features from experimental to Standard. This signifies confidence in the API’s stability and provides backward compatibility guarantees. Standard Channel features will continue to evolve with backward-compatible enhancements.

Gateway API now supports service mesh, enabling users to manage both ingress and mesh traffic with a unified API. Routes like HTTPRoute can now reference a Service as a parentRef, allowing for precise traffic control to specific services. To go deeper into this feature, check out the Gateway API documentation.

A possible implementation of canary deployment with HTTPRoute is the following:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

This configuration splits traffic 50/50 between the original color Service and the color2 Service in the faces namespace.

GRPCRoute has been part of the Standard Channel since v1.1.0. For users of the experimental channel, it is recommended to wait for controller updates before upgrading to the standard channel version. Meanwhile, the experimental channel version in v1.1 includes both v1alpha2 and v1 API versions.

HTTPRoute is a Gateway API type for specifying routing behavior of HTTP requests. Each Route provides a method to reference the parent resources it intends to attach to. Typically, this will be Gateways, but implementations have the flexibility to support other types of parent resources as well. The port field has been added to ParentReference, allowing resources to be attached to Gateway Listeners, Services, or other parent resources by specifying the port. This enables attachment to multiple Listeners simultaneously.

Example of attaching an HTTPRoute to specific Gateway Listeners by port:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httproute-example
spec:
  parentRefs:
  - name: acme-lb
    port: 8080

Note that the target Gateway needs to allow HTTPRoutes from the route’s namespace to be attached for the attachment to be successful and binding to a port also allows attaching to multiple listeners at once

The conformance report API now includes the mode field and gatewayAPIChannel (standard or experimental). The gatewayAPIVersion and gatewayAPIChannel are automatically populated, and the reports are better structured, allowing implementations to include testing details and reproduction steps.

A new addition to the experimental channel is about Gateways. In particular, it is now possible to configure client certificate verification for each Gateway Listener using the new frontendValidation field within TLS. This field allows the configuration of CA Certificates to validate client certificates.

An example of configuration is the following:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

Another new addition to the experimental channel is Session persistence. It is introduced via a new policy (BackendLBPolicy) for Service-level configuration and as fields within HTTPRoute and GRPCRoute for route-level configuration. These settings include session timeouts, session name, session type, and cookie lifetime.

An Example of BackendLBPolicy configuration for cookie-based session persistence is the following:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

To ensure consistent TLS terminology, breaking changes have been made to BackendTLSPolicy, resulting in a new API version (v1alpha3). Implementations must handle this version upgrade by updating references and configurations accordingly.

Other notable changes:

• targetRef becomes targetRefs
• tls becomes validation
• tls.caCertRefs becomes validation.caCertificateRefs
• tls.wellKnownCACerts becomes validation.wellKnownCACertificates

Unlike other Kubernetes APIs, upgrading to the latest Kubernetes version isn’t necessary to use the newest Gateway API. As long the cluster is on Kubernetes 1.26 or later, it is possible to start using the latest Gateway API right away.

RedHat has announced the general availability of Red Hat OpenShift 4.15, based on Kubernetes 1.28 and CRI-O 1.28. Red Hat OpenShift is an application platform that allows developers and DevOps to build, and deploy applications.

This release introduces some changes for application build like the Red Hat Developer Hub operator, the Integration of role-based access controls (RBAC) via the web interface, the migration to the new Backstage backend system, and the support for viewing installed plugins through the web interface and the compatibility with Azure Kubernetes Services (AKS) and Elastic Kubernetes Services (EKS) for installation.

Red Hat OpenShift Local lets users set up a mini OpenShift cluster on their local machine. This mimics a cloud development environment, providing all the tools you need to build container-based applications.

The versions 2.31 of OpenShift Local, built upon OpenShift 4.14.7, Podman 4.4.4, and MicroShift 4.14.7, benefit from several enhancements:

• Windows GUI Launcher: A new helper tool (win32-background-launcher) simplifies starting OpenShift Local as a background service on Windows machines.
• Bug Fixes: This update addresses issues encountered during daemon initialization.
• Admin Helper Update: The admin-helper tool has been upgraded to version 0.5.2.
• Libvirt Driver Update: OpenShift Local 2.32 uses an updated crc-libvirt-driver (version 0.13.7).

Red Hat OpenShift Dev Spaces offers a web-based development environment tailored for Red Hat OpenShift. The latest release: Red Hat OpenShift Dev Spaces 3.11, built on Eclipse Che 7.80 and compatible with OpenShift versions 4.11 to 4.14, empowers cluster admins with enhanced access management capabilities and supports Microsoft Visual Studio Code extensions utilizing OAuth2 authorization code flow. Moreover, it defaults to Java 17 in the universal developer image and streamlines workspace configuration for various Git providers. Similarly, Red Hat OpenShift Dev Spaces 3.12, based on Eclipse Che 7.82, extends the collaborative environment by enabling the sharing of certificates, secrets, and configuration files across users. This release also enhances flexibility by allowing the override of the editor’s image using dedicated URL parameters and introduces support for running Che-Code editor in the Red Hat Universal Base Image 9. Explore the Dev Spaces v3.12 release notes for detailed insights.

The OpenShift Toolkit IDE extension by Red Hat enhances the development experience by facilitating code deployment to OpenShift directly from Visual Studio Code and IntelliJ. This extension integrates seamlessly with OpenShift Serverless Functions, improves Helm Chart deployment, and offers convenient access to Developer Sandbox environments from within the IDE. Explore the extension’s features to boost productivity in your development workflow.

OpenShift Serverless, providing autoscaling and networking for containerized microservices and functions, unveils version 1.32, featuring Knative 1.11. This release introduces Knative Eventing monitoring dashboards, on-cluster function building for IBM P/Z, and custom CA bundle injection for system components. Additionally, it offers new capabilities in technology preview, including Go language support for Serverless Functions and enhanced trigger filters for Event-driven apps. Dive into the release notes for a comprehensive overview of its features.

Red Hat’s migration toolkit for applications 7.0 offers support for multiple languages, enhanced rules syntax, automated classification, and dynamic reporting capabilities. Container images for OpenShift now include Node.js 20, while Java 21 builder and runtime container images are also available. Quarkus 3.8 will introduce Redis 7.2 support, Java 21 support, Arm native support, and OpenSearch Dev services. Additionally, Spring Boot 3.1.x and 3.2.x have been tested and verified for runtimes on OpenShift.

Red Hat OpenShift GitOps allows administrators to configure and deploy Kubernetes infrastructure and applications across various clusters and development life cycles. With the release of OpenShift GitOps 1.11, leveraging Argo CD 2.9.2, users gained access to dynamic shard rebalancing in Technology Preview mode alongside other new capabilities. In the subsequent release, OpenShift GitOps 1.12, built on Argo CD 2.10, users can enjoy several additions, including introducing an Argo CD CLI in technology preview. For an extensive overview of all the new features, refer to the “What’s new in Red Hat OpenShift GitOps 1.12” documentation.

OpenShift Pipelines stands as a cloud-native continuous integration and continuous delivery (CI/CD) solution rooted in Kubernetes, streamlining deployments across multiple platforms by abstracting away implementation complexities. The latest version, Openshift Pipelines 1.14.0, powered by Tekton 0.56, introduces a new web console plugin in technology preview, enabling users to visualize pipeline and task execution statistics. Additionally, it embraces Pipeline as a Code methodology to interface with multiple GitHub instances.

OpenShift Service Mesh 2.5, built on Istio 1.18 and Kiali 1.73, users can expect a host of enhancements:

• General Availability support for Arm clusters, broadening compatibility.
• Expanded observability integrations with the inclusion of Zipkin, OpenTelemetry, and envoyOtelAls extension providers.
• General Availability status for the OpenShift Service Mesh Console plug-in, enhancing management capabilities.
• Developer Preview features including IPv4/IPv6 dual-stack support and the Kiali Backstage plug-in for Red Hat Developer Hub.
• Updated Developer Preview of the Service Mesh 3 Kubernetes Operator (or the Sail Operator), offering improved functionality.

The Red Hat build of OpenTelemetry, based on the OpenTelemetry framework, simplifies telemetry data collection for cloud-native software. Version 3.1 (based on OpenTelemetry 0.93.0) introduces support for the target allocator in the OpenTelemetry Collector. This feature optimizes Prometheus receiver scrape target allocation across deployed OpenTelemetry Collector instances and integrates seamlessly with Prometheus PodMonitor and ServiceMonitor custom resources.

HashiCorp recently released version 2.3 of Terraform Cloud Operator for Kubernetes with a new feature: the ability to initiate workspace runs declaratively. The Terraform Cloud Operator for Kubernetes was introduced in November 2023 to provide a Kubernetes-native experience while leveraging Terraform workflows.

The Terraform Cloud Operator allows users to manage Terraform Cloud resources with Kubernetes Custom Resource Definitions (CRD). This operator allows the users to provision infrastructure internal or external to the Kubernetes cluster directly from the Kubernetes control plane.

The Key Benefits of Terraform Cloud Operator are:

• Flexible resource management: Version 2 introduces multiple custom resources with dedicated controllers for various Terraform Cloud resources, enhancing flexibility and performance for managing custom resources concurrently in large-scale deployments.
• Namespace management: Tailor the operator’s watch scope to specific namespaces using the --namespace option, enabling fine-grained resource management tailored to your organizational needs.
• Configurable synchronization: Adjust the synchronization frequency between custom resources and Terraform Cloud with the --sync-period option, ensuring timely updates and operational smoothness.

In previous iterations of the Terraform Cloud Operator v2, initiating a run was limited to patching the restartedAt timestamp within the Module resource. This method proved non-intuitive, lacked universality across workspace types, and offered no control over run types, hampering migration efforts. However, version 2.3 addresses these challenges by enabling users to declaratively commence plan, apply, and refresh runs on workspaces, thereby empowering developers with enhanced self-service capabilities across all Operator-managed workspaces, including VCS-driven ones.

Version 2.3 introduces three new annotations within the Workspace custom resource to facilitate workspace run initiation:

• workspace.app.terraform.io/run-new: Set to true to trigger a new run.
• workspace.app.terraform.io/run-type: Control the run type (plan, apply, or refresh).
• workspace.app.terraform.io/run-terraform-version: Specify the Terraform version for speculative plan runs.

This is an example of Workspace Resource and Annotation:

apiVersion: app.terraform.io/v1alpha2
kind: Workspace
metadata:
  name: this
spec:
  organization: kubernetes-operator
  token:
    secretKeyRef:
      name: tfc-operator
      key: token
  name: kubernetes-operator

To immediately initiate a new apply run for the above workspace resource using kubectl:

kubectl annotate workspace this 
    workspace.app.terraform.io/run-new="true" 
    workspace.app.terraform.io/run-type=apply --overwrite

After successful execution, the annotation is reflected in the Workspace resource for observability:

apiVersion: app.terraform.io/v1alpha2
kind: Workspace
metadata:
  annotations:
    workspace.app.terraform.io/run-new: "true"
    workspace.app.terraform.io/run-type: apply
  name: this
spec:
  organization: kubernetes-operator
  token:
    secretKeyRef:
      name: tfc-operator
      key: token
  name: kubernetes-operator

Post-run completion, the operator automatically resets the run-new value to false.

With Terraform Cloud Operator v2.3, initiating and managing workspace runs becomes more intuitive, empowering teams to efficiently manage infrastructure while embracing Kubernetes-native experiences.