Update worker tool versions and improve documentation (#3058)

* Update DW tool versions and improve documentation to meet linting standard

Author: Justin-Walsh

src/pages/docs/infrastructure/workers/dynamic-worker-pools.md

@@ -1,9 +1,9 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2024-09-24
+modDate: 2026-03-10
 title: Dynamic Worker pools
-description: Dynamic Worker pools are used in our cloud product to dynamically create and assign workers to running tasks.  This page describes how dynamic worker pools work.
+description: Dynamic Worker pools are used in our cloud product to dynamically create and assign workers to running tasks. This page describes how dynamic worker pools work.
 navOrder: 50
 ---
 
@@ -21,7 +21,7 @@ Octopus Cloud will automatically destroy dynamic workers as soon as one of these
 - The worker has been idle for 60 minutes.
 - The worker has existed for 72 hours (3 days).
 
-Please reach out to our [support team](https://octopus.com/support) if you need these values to be adjusted for your instance. 
+Please reach out to our [support team](https://octopus.com/support) if you need these values to be adjusted for your instance.
 :::
 
 Worker VMs are provisioned with at least 20GB of available disk space, which is persistent until the worker is destroyed.
@@ -36,7 +36,7 @@ Each dynamic worker pool uses a specific worker image. This is a VM image which
 
 When you sign up to [Octopus Cloud](/docs/octopus-cloud) (or create a new [space](/docs/administration/spaces)), you automatically receive a worker pool for the `Ubuntu (default)` image, and a worker pool for the `Windows (default)` image.
 
-The full list of available worker images includes both specific operating system versions (e.g., `Ubuntu Linux 22.04`), and also generic "default" options such as `Ubuntu (default)`. Choosing the default option means that your worker will use the latest stable worker image when it is released. 
+The full list of available worker images includes both specific operating system versions (e.g., `Ubuntu Linux 22.04`), and also generic "default" options such as `Ubuntu (default)`. Choosing the default option means that your worker will use the latest stable worker image when it is released.
 
 The current default images are:
 
@@ -50,14 +50,14 @@ The default image is a good option to choose if you are:
 - Running a simple script that doesn't require specific tools or operating system versions
 - Running a step [inside a container](/docs/projects/steps/execution-containers-for-workers)
 
-If you're writing a script that relies on a specific version of tooling (e.g., Helm), then we recommend using [execution containers for workers](/docs/projects/steps/execution-containers-for-workers) to run the script in a Docker container with the tool versions you need. 
+If you're writing a script that relies on a specific version of tooling (e.g., Helm), then we recommend using [execution containers for workers](/docs/projects/steps/execution-containers-for-workers) to run the script in a Docker container with the tool versions you need.
 
 Alternatively, you can choose a specific worker image, instead of the "default" options, to prevent worker image upgrades from impacting your deployments.
 
-|Type | Pros | Cons                                                                                                                                                                                                                         |
-|-----|------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Default (eg `Ubuntu (default)`) | Automatically uses the latest image. Deployments will continue to work even when a worker image is marked as deprecated or decommissioned.| The versions of dependencies (e.g. Helm) are not fixed. Deployments that rely on specific versions of dependencies or operating system specific features may break during upgrades.                                          |
-| Specific (e.g., `Ubuntu Linux 22.04`) | The version of the operating system and dependencies are fixed and can be relied upon. | When a worker image is marked as deprecated, warnings will start to appear in your deployment logs. When a worker image is decommissioned, you will need to take action to update your worker pool or deployments will fail. |
+| Type                                 | Pros                                                                                                                                       | Cons                                                                                                                                                                                              |
+|--------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Default (eg `Ubuntu (default)`)      | Automatically uses the latest image. Deployments will continue to work even when a worker image is marked as deprecated or decommissioned. | The versions of dependencies (e.g. Helm) are not fixed; deployments that rely on specific versions of dependencies or operating system‑specific features may break during upgrades.               |
+| Specific (e.g., `Ubuntu Linux 22.04`)| The version of the operating system and dependencies are fixed and can be relied upon.                                                     | When a worker image is marked as deprecated, warnings will start to appear in your deployment logs; when it is decommissioned, you will need to update your worker pool or deployments will fail. |
 
 ### Deprecation
 
@@ -69,15 +69,15 @@ If your Worker Pool is set to use the Operating System default, for example, `Ub
 
 You should validate that your deployments and runbooks work with the new version prior to the cutover date. The new image will be made available prior to the cutover date and we will notify you of the cutover date to give you time to undertaking any required testing.
 
-### Modifying the worker pool 
+### Modifying the worker pool
 
 If the worker pool has been configured to specifically use a deprecated worker type, you will need to update the worker image on the worker pool.
 
 Navigate to your space, then go to **Infrastructure ➜ Worker Pools**. Worker pools with a deprecated worker image will show a `Deprecated` label next to the worker pool.
 
 Click the overflow menu (`...`) and click **Edit**. You can then select a new worker image from the dropdown list, such as `Ubuntu (default)` or a specific operating system version.
 
-## Available Dynamic Worker Images 
+## Available Dynamic Worker Images
 
 Worker images are rebuilt on a regular basis, so that the operating system is up to date with the latest security patches.
 
@@ -87,72 +87,61 @@ This is the default for the Ubuntu operating system, referenced as `Ubuntu (defa
 
 Each `Ubuntu Server 22.04` worker is provisioned with a baseline of tools including (but not limited to):
 
-- .NET 6
+- .NET (8.0, 6.0)
 - Docker (latest)
 - PowerShell Core (latest)
 - Python 3 (latest)
-- GCloud CLI (367.0.0)
+- GCloud CLI (550.0.0)
 
 :::div{.hint}
-Ubuntu workers are designed to use [execution worker containers](https://octopus.com/blog/execution-containers) for tooling such as `kubectl` and `helm`. This makes it much easier to choose the appropriate runtime environment with the tools you need for your use case.
+Ubuntu workers are designed to use [execution worker containers](https://octopus.com/blog/execution-containers) for tooling like `kubectl` and `helm`. This makes it much easier to choose the appropriate runtime environment with the tools you need for your use case.
 :::
 
-
 ### Windows Server Core 2022
 
 This is the default for the Windows operating system, referenced as `Windows (default)`.
 
 Each `Windows Server Core 2022` worker is provisioned with a baseline of tools including (but not limited to):
 
-- .NET Core (2.1, 3.1)
+- .NET (8.0, 6.0)
 - .NET Framework 3.5
 - .NET Framework 4.8
-- AWS IAM Authenticator (0.5.3)
+- AWS IAM Authenticator (0.7.10)
 - Chocolatey (latest)
 - Docker (latest)
-- Helm (2.9.1)
+- Helm (3.19.4)
 - Kubectl (multiple versions)
-- Microsoft Service Fabric (6.1.480.9494)
-- Microsoft Service Fabric SDK (3.0.480)
+- Microsoft Service Fabric (10.1.2338.9590)
+- Microsoft Service Fabric SDK (7.1.2338)
 - Nuget CLI (latest)
 - Octopus Client (latest)
 - Pip (latest)
 - PowerShell Core (latest)
-- Python (3.7.4)
-- GCloud CLI (339.0.0)
+- Python (3.14)
+- GCloud CLI (550.0.0)
 
-Windows 2022 workers are capable of running [execution worker containers](/docs/projects/steps/execution-containers-for-workers). 
+Windows 2022 workers are capable of running [execution worker containers](/docs/projects/steps/execution-containers-for-workers).
 
 :::div{.hint}
 We recommend execution containers as the preferred option for steps requiring external tools. This allows you to control which version of the tools will be used as your scripts will rely on a specific version that they are compatible with to function correctly.
 :::
 
-
 ## kubectl on Windows Images
 
 Windows dynamic worker images come with many versions of `kubectl` available.
 
-A specific version can be used by [specifying a custom kubectl location](/docs/deployments/kubernetes/kubectl) of `c:\tools\kubectl\{{version}}\kubectl.exe`, where `{{version}}` is one of the following: 
-
-- `1.11.1`
-- `1.11.3`
-- `1.12.1`
-- `1.13.12`
-- `1.14.9`
-- `1.15.6`
-- `1.16.10`
-- `1.17.5`
-- `1.18.0`
-- `1.19.9`
-- `1.20.5`
-- `1.21.9`
-- `1.22.6`
+A specific version can be used by [specifying a custom kubectl location](/docs/deployments/kubernetes/kubectl) of `c:\tools\kubectl\{{version}}\kubectl.exe`, where `{{version}}` is one of the following:
+
+- `1.32.12`
+- `1.33.8`
+- `1.34.4`
+- `1.35.1`
 
 ## Installing Software On Dynamic Workers
 
-Octopus does not recommend installing additional software on Dynamic Workers. 
+Octopus does not recommend installing additional software on Dynamic Workers.
 
-By default, every dynamic worker is destroyed after it has been idle for 60 minutes or allocated for over 72 hours. Additionally, Octopus cannot guarantee that the dynamic worker leased to run one step will be the same worker leased to other executing steps in a deployment or runbook run. 
+By default, every dynamic worker is destroyed after it has been idle for 60 minutes or allocated for over 72 hours. Additionally, Octopus cannot guarantee that the dynamic worker leased to run one step will be the same worker leased to other executing steps in a deployment or runbook run.
 
 For deployments and runbook runs that require additional software dependencies on a dynamic worker, our recommendation is to leverage [execution containers for workers](/docs/projects/steps/execution-containers-for-workers).  Octopus provides execution containers with a baseline of tools (`octopusdeploy/worker-tools`) pre-installed. These tools won't include every possible software combination you might need. If you require a specific set of software and tooling we recommend [building your own custom Docker images for use with execution containers](/docs/projects/steps/execution-containers-for-workers/#custom-docker-images).