Kubernetes上的GitLab Auto DevOps挂起、网络超时、无法执行yj

u3r8eeie  于 2023-01-20  发布在  Kubernetes
关注(0)|答案(1)|浏览(147)

当使用GitLab Auto DevOps构建应用程序并将其从我的存储库部署到microk8s时,构建作业通常需要很长时间才能运行,最终会超时。99%的情况下都会发生这个问题,但有些构建会运行。通常,构建会在构建脚本中的不同时间停止。
这些项目不包含.gitlab-ci.yml文件,完全依赖Auto DevOps功能发挥作用。
对于Sping Boot /Java项目,通过Gradle Package 器下载Gradle时,构建通常会失败;其他时候,构建会在下载依赖项本身时失败。错误消息非常模糊,毫无帮助:

Step 5/11 : RUN /bin/herokuish buildpack build
 ---> Running in e9ec110c0dfe
       -----> Gradle app detected
-----> Spring Boot detected
The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 35

有时候,如果你运气好的话,错误是不同的:

Step 5/11 : RUN /bin/herokuish buildpack build
 ---> Running in fe284971a79c
       -----> Gradle app detected
-----> Spring Boot detected
-----> Installing JDK 11... done
-----> Building Gradle app...
-----> executing ./gradlew build -x check
       Downloading https://services.gradle.org/distributions/gradle-7.0-bin.zip
       ..........10%...........20%...........30%..........40%...........50%...........60%...........70%..........80%...........90%...........100%
       To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.0/userguide/gradle_daemon.html#sec:disabling_the_daemon.
       Daemon will be stopped at the end of the build
       > Task :compileJava
       > Task :compileJava FAILED
       
       FAILURE: Build failed with an exception.
       
       * What went wrong:
       Execution failed for task ':compileJava'.
       > Could not download netty-resolver-dns-native-macos-4.1.65.Final-osx-x86_64.jar (io.netty:netty-resolver-dns-native-macos:4.1.65.Final)
       > Could not get resource 'https://repo.maven.apache.org/maven2/io/netty/netty-resolver-dns-native-macos/4.1.65.Final/netty-resolver-dns-native-macos-4.1.65.Final-osx-x86_64.jar'.
       > Could not GET 'https://repo.maven.apache.org/maven2/io/netty/netty-resolver-dns-native-macos/4.1.65.Final/netty-resolver-dns-native-macos-4.1.65.Final-osx-x86_64.jar'.
       > Read timed out

对于React/TypeScript问题,症状类似,但错误本身的表现方式不同:

[INFO] Using npm v8.1.0 from package.json
/cnb/buildpacks/heroku_nodejs-npm/0.4.4/lib/build.sh: line 179: /layers/heroku_nodejs-engine/toolbox/bin/yj: Permission denied
ERROR: failed to build: exit status 126
ERROR: failed to build: executing lifecycle: failed with status code: 145

这个问题似乎主要发生在GitLab运行程序本身在Kubernetes中被部署的时候。microk 8 s使用Project Calico来实现虚拟网络。
什么原因?为什么错误信息没有帮助?有没有办法打开冗长的构建日志或调试构建步骤?

wtzytmuj

wtzytmuj1#

这似乎是一个网络问题所造成的不兼容的MTU设置之间的Calico网络层和Docker的网络配置(和无法自动配置MTU正确?)当MTU值不匹配,网络数据包得到碎片和Docker运行者无法完成TLS握手.据我所知,这只影响DIND(docker-in-docker)运行者.
即使找到这个问题也需要跳过几个圈。你必须:
1.启动CI管道并等待作业“挂起”

  1. kubectl exec到当前/活动的GitLab runner pod中
    1.找出DOCKER_HOST环境变量的正确值(例如,通过greppingthroughx 1 m2n1x。很可能是tcp://localhost:2375)。
    1.导出要由docker客户端使用的值:export DOCKER_HOST=tcp://localhost:2375
  2. docker ps,然后将docker exec复制到实际CI作业容器中
    1.使用ping和其他工具查找正确的MTU值(但MTU是什么?Docker、Calico、OS、路由器...?)。使用curl/openssl验证(某些)https站点是否会从DIND容器内部导致问题。
    执行
microk8s kubectl get -n kube-system cm calico-config -o yaml

并查找veth_mtu值,该值很可能被设置为1440。DIND使用相同的MTU,因此无法发送或接收某些网络包(每个虚拟网络需要向网络包添加自己的报头,这在每层添加了几个字节)。
最简单的解决方法是将Calico设置更改为更高或更低的值,但不知何故,即使在Calico部署之后,这也不起作用。此外,该值似乎不时地重置为原始值;可能是由microk 8 s(作为Snap来的)的自动更新引起的。
那么,什么是真正有效且永久的解决方案呢?可以通过编写自定义.gitlab-ci.yml文件来覆盖Auto DevOps的DIND设置,只需包含Auto DevOps模板:

build:
  services:
    - name: docker:20.10.6-dind # make sure to update version
      command: ['--tls=false', '--host=tcp://0.0.0.0:2375', '--mtu=1240']

include:
    - template: Auto-DevOps.gitlab-ci.yml

build.services定义是从Jobs/Build.gitlab-ci模板复制的,并使用附加的--mtu选项进行扩展。
到目前为止,我将DIND的MTU设置为1240,这比Calico的MTU低200字节,这是一个很好的经验。作为一个额外的好处,它不会影响任何其他pod的网络设置。对于CI版本,我可以接受非最佳网络设置。
参考文献:

相关问题