We have noticed that certain Kubernetes plugins versions do not work with Jenkins LTS versions (could be any LTS, but we have tried with 2.387.2, 2.375.x) as they do not have the JNLP Retry logic present. 

We see this JNLP 255 exception when we run a Jenkins pipeline: 

• jnlp – terminated (255)
  ----Logs------------
  Aug 08, 2023 5:31:33 PM hudson.remoting.Engine startEngine
  INFO: Using Remoting version: 4.11
  Aug 08, 2023 5:31:33 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
  INFO: Using /home/jenkins/agent/remoting as a remoting work directory
  Aug 08, 2023 5:31:33 PM org.jenkinsci.remoting.engine.WorkDirManager setupLogging
  INFO: Both error and output logs will be printed to /home/jenkins/agent/remoting
  Aug 08, 2023 5:31:33 PM hudson.remoting.jnlp.Main$CuiListener status
  INFO: Locating server among [http://ipp-blossom-dev-updated-golden-image-svc.jenkins-master-ns.svc.cluster.local:8080/ipp-blossom-dev-updated-golden-image/]
  Aug 08, 2023 5:31:53 PM hudson.remoting.jnlp.Main$CuiListener error
  SEVERE: Failed to connect to http://ipp-blossom-dev-updated-golden-image-svc.jenkins-master-ns.svc.cluster.local:8080/ipp-blossom-dev-updated-golden-image/tcpSlaveAgentListener/: ipp-blossom-dev-updated-golden-image-svc.jenkins-master-ns.svc.cluster.local
  java.io.IOException: Failed to connect to http://ipp-blossom-dev-updated-golden-image-svc.jenkins-master-ns.svc.cluster.local:8080/ipp-blossom-dev-updated-golden-image/tcpSlaveAgentListener/: ipp-blossom-dev-updated-golden-image-svc.jenkins-master-ns.svc.cluster.local
  at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:214)
  at hudson.remoting.Engine.innerRun(Engine.java:724)
  at hudson.remoting.Engine.run(Engine.java:540)
  Caused by: java.net.UnknownHostException: ipp-blossom-dev-updated-golden-image-svc.jenkins-master-ns.svc.cluster.local
  at java.base/java.net.AbstractPlainSocketImpl.connect(Unknown Source)
  at java.base/java.net.Socket.connect(Unknown Source)
  at java.base/sun.net.NetworkClient.doConnect(Unknown Source)
  at java.base/sun.net.www.http.HttpClient.openServer(Unknown Source)
  at java.base/sun.net.www.http.HttpClient.openServer(Unknown Source)
  at java.base/sun.net.www.http.HttpClient.<init>(Unknown Source)
  at java.base/sun.net.www.http.HttpClient.New(Unknown Source)
  at java.base/sun.net.www.http.HttpClient.New(Unknown Source)
  at java.base/sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
  at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source)
  at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
  at java.base/sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
  at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:211)
  ... 2 more
   

With certain Kubernetes plugin versions, the pipeline retries the connection and succeeds, then continues with the rest of the pipeline. 

With other Kubernetes plugin versions, like the newest released, the pipeline does not do any retry and therefore the build fails. 

Why is there an inconsistency with the Kubernetes plugin and how can we fix this issue? We are forced to create our Jenkins instances with specific K8s plugin versions, which have security vulnerabilities.