Update Kubernetes agent installation and troubleshooting docs

public/docs/img/infrastructure/deployment-targets/kubernetes/kubernetes-agent/kubernetes-agent-advanced-settings.png.json

@@ -0,0 +1 @@
+{"width":600,"height":601,"updated":"2026-01-15T05:15:01.509Z"}

public/docs/img/infrastructure/deployment-targets/kubernetes/kubernetes-agent/kubernetes-agent-wizard-config.png.json

@@ -1,5 +1 @@
-{
-  "width": 970,
-  "height": 978,
-  "updated": "2025-08-01T08:52:49.163Z"
-}
+{"width":601,"height":623,"updated":"2026-01-15T05:15:01.529Z"}

public/docs/img/infrastructure/deployment-targets/kubernetes/kubernetes-agent/kubernetes-agent-wizard-helm-command.png.json

@@ -1,5 +1 @@
-{
-  "width": 970,
-  "height": 1184,
-  "updated": "2025-08-01T08:52:49.163Z"
-}
+{"width":602,"height":1007,"updated":"2026-01-15T05:15:01.552Z"}

src/pages/docs/installation/load-balancers/index.mdx

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2025-12-08
+modDate: 2026-01-15
 title: Load Balancers
 navTitle: Overview
 navSection: Load Balancers
@@ -17,7 +17,7 @@ Octopus Deploy can work with any http/https load balancer technology.  There are
 Octopus Server provides a health check endpoint for your load balancer to ping: `/api/octopusservernodes/ping`.
 
 :::figure
-![](/docs/img/shared-content/administration/images/load-balance-ping.png)
+![Load balancer ping UI](/docs/img/shared-content/administration/images/load-balance-ping.png)
 :::
 
 Making a standard `HTTP GET` request to this URL on your Octopus Server nodes will return:
@@ -44,15 +44,16 @@ Polling tentacles deserve special attention due to how they work with Octopus De
 We recommend having a dedicated URL for each node in the primary region and routing all traffic through a load balancer or a traffic manager.  When you have to fail over to the secondary region, update the dedicated URLs to point to a corresponding node in the secondary region.
 
 :::div{.warning}
-Important! You must configure the traffic to be “pass through” with no SSL off-loading.  The tentacles and Octopus Deploy establish a two-way trust via certificates.  If a third unknown certificate is introduced, the tentacle and Octopus deploy will reject the connection.
+Important! You must configure the traffic to be "pass through" with no SSL off-loading.  The tentacles and Octopus Deploy establish a two-way trust via certificates.  If a third unknown certificate is introduced, the tentacle and Octopus deploy will reject the connection.
 :::
 
 ## gRPC Services
 
 Several Octopus features (eg. Kubernetes Live Object Status and Argo CD integration) rely on communications via gRPC that require specific configuration to account for certificate trust.
 
 Octopus generates a self signed certificate for gRPC communications. When the a gRPC client needs to connect to Octopus via a load balancer, there are two common methods to achieve this:
-1. Using TLS/SSL bridging, with verification disabled between the load balancer and Octopus
+
+1. Using TLS/SSL bridging, with verification disabled between the load balancer and Octopus. Additional configuration will be required for the gRPC client to trust the load balancer certificate.
 2. Using TLS/SSL passthrough
 
 ## Third Party Load Balancers

src/pages/docs/kubernetes/live-object-status/troubleshooting/index.md

@@ -27,15 +27,21 @@ Support for running the [Kubernetes monitor](/docs/kubernetes/targets/kubernetes
 
 ### gRPC connections via a load balancer
 
-Octopus generates a self signed certificate for gRPC communications like those between Octopus and Kubernetes monitor and requires specific configuration.
+Octopus generates a self-signed certificate for gRPC communications like those between Octopus and Kubernetes monitor and requires specific configuration.
 
 Refer to the [load balancer documentation](/docs/installation/load-balancers#grpc-services) for further information.
 
+### Certificate errors when trying to create gRPC connections
+
+The self-signed certificate is only useful for simple scenarios where the Kubernetes monitor can talk directly to Octopus server (or is proxied with TLS passthrough).
+
+Refer to the [agent installation docs](/docs/kubernetes/targets/kubernetes-agent#grpc-certificates) for more options when using custom certificates.
+
 ## Runtime
 
 ### Failed to establish connection with Kubernetes Monitor \{#failed-to-establish–connection-with-kubernetes-monitor}
 
-Some actions, such as logs and events, require per request communication with the Kubernetes monitor running in your cluster. 
+Some actions, such as logs and events, require per request communication with the Kubernetes monitor running in your cluster.
 
 If the Kubernetes monitor cannot be accessed, follow these steps to determine why:
 
@@ -45,9 +51,9 @@ If the Kubernetes monitor cannot be accessed, follow these steps to determine wh
 
 In almost all cases, we have found restarting the Kubernetes monitor pod will re-establish connection if there are no external factors at play. Please reach out to support if you are finding cases of repeated, unexpected failure.
 
-### We couldn’t find a Kubernetes monitor associated with the deployment target \{#kubernetes-monitor-not-found}
+### We couldn't find a Kubernetes monitor associated with the deployment target \{#kubernetes-monitor-not-found}
 
-Similar to the [error above](#failed-to-establish–connection-with-kubernetes-monitor), however more severe.
+Similar to the [error above](/docs/kubernetes/live-object-status/troubleshooting#failed-to-establish–connection-with-kubernetes-monitor), however more severe.
 
 This error will be shown when Octopus fails to find the registration of a Kubernetes monitor at all. If the Kubernetes agent and monitor are both still running in your Kubernetes cluster, this means the Kubernetes monitor will need to be re-registered with Octopus.
 
@@ -71,10 +77,12 @@ The rate limit is not a hard stop to messages being sent between Octopus Server
 Objects are reported out of sync when the manifest the Kubernetes cluster sends back to use does not match the one that Octopus applied in your deployment.
 
 This can happen for a number of reasons, including
+
 - Someone has made an update to the object outside of Octopus deployments
 - A controller is automatically making changes to the object on your cluster
 - There are additional fields that Kubernetes does not recognize in the applied manifest that Kubernetes automatically removes from the reported live manifest
 
 If possible, we recommend ensuring that
+
 - Octopus is the only entity to modify your deployments
 - You craft your Kubernetes manifests to ensure that there are no invalid fields