Дженкинс раба стручок на kubernetes случайно не удается

Я установил мастер Jenkins (на виртуальной jnlp ), и это обеспечивает работу jnlp как kubernetes .

В очень редких случаях происходит сбой конвейера с этим сообщением:

java.io.IOException: Pipe closed
    at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:260)
    at java.io.PipedInputStream.receive(PipedInputStream.java:226)
    at java.io.PipedOutputStream.write(PipedOutputStream.java:149)
    at java.io.OutputStream.write(OutputStream.java:75)
    at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.setupEnvironmentVariable(ContainerExecDecorator.java:510)
    at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.doLaunch(ContainerExecDecorator.java:474)
    at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.launch(ContainerExecDecorator.java:333)
    at hudson.Launcher$ProcStarter.start(Launcher.java:455)

Просматривая логи Stackdriver в Stackdriver, можно увидеть, что модуль действительно может подключиться к мастеру, например

Handshaking
Agent discovery successful
Trying protocol: JNLP4-Connect
Remote Identity confirmed: <some_hash_here>
Connecting to <jenkins-master-url>:49187
started container
loading plugin ...

но через некоторое время это терпит неудачу, и вот соответствующие журналы:

org.csanchez.jenkins.plugins.kubernetes.KubernetesSlave$SlaveDisconnector call
INFO: Disabled slave engine reconnects.
hudson.remoting.jnlp.Main$CuiListener status
Terminated
hudson.remoting.Request$2 run
 Failed to send back a reply to the request hudson.remoting.Request$2@336ec321: hudson.remoting.ChannelClosedException: Channel "hudson.remoting.Channel@29d0e8b2:JNLP4-connect connection to <jenkins-master-url>/<public-ip-of-jenkins-master>:49187": channel is already closed
"Processing signal 'terminated'"
.
.
.

Как я могу дополнительно устранить эту случайную ошибку?

Всего 1 ответ


Можете ли вы взглянуть на под-события Kubernetes с Stackdriver? У нас было похожее поведение с другой CI-системой (GitlabCI). Наши сборки, где также случайно провалились. Оказалось, что JVM внутри контейнера превысила ограничение памяти и была убита Kubernetes (OOMKilled), и CI-System распознала это как ошибку сборки.


Есть идеи?

10000