当前位置: 首页 > 知识库问答 >
问题:

为Jenkins启动kubernetes吊舱颁发证书(托管在kubernetes集群之外)

西门正平
2023-03-14

我们正在尝试使用Jenkins Kubernetes插件添加云代理。到kubernetes的连接可以工作(我已经通过测试连接验证了这一点。此外,当我的作业尝试启动时,pods容器会添加到集群中)。我正在我的pod模板中添加以下配置--pod容器在我的kubernetes引擎中启动。

问题-作业不运行,并不断创建新的豆荚和删除旧的豆荚。在正确的方向上需要一些帮助。我在网上搜索了一下,寻找是否有人有类似的问题或设置。似乎每个人都在k8s和云代理中托管詹金斯。

我认为问题是因为我们的詹金斯在我们的库伯内特斯星系团之外。

    null

谷歌stackdriver日志错误-

SEVERE: Failed to connect to https://bflow.br.iq/tcpSlaveAgentListener/: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target`

`java.io.IOException: Failed to connect to https://bflow.br.iq/tcpSlaveAgentListener/: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:214)
    at hudson.remoting.Engine.innerRun(Engine.java:689)
    at hudson.remoting.Engine.run(Engine.java:514)
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alert.createSSLException(Alert.java:131)
    at sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
    at sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
    at sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
    at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654)
    at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)
    at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
    at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377)
    at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
    at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
    at sun.security.ssl.TransportContext.dispatch(TransportContext.java:182)
    at sun.security.ssl.SSLTransport.decode(SSLTransport.java:149)
    at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1143)
    at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1054)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:394)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:167)
    at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:211)
    ... 2 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:456)
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:323)
    at sun.security.validator.Validator.validate(Validator.java:271)
    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:315)
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:223)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
    at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)
    ... 16 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:451)
    ... 22 more

共有1个答案

董凡
2023-03-14

安装详细信息:

  • Jenkins master作为docker容器在VM上运行。
  • Jenkins在专用网络上运行。
  • Kubernetes插件已安装
  • Kubernetes集群中创建的Jenkins命名空间、serviceAccount、Role和RoleBinding。
  • 托管节点和云>配置云>Kubernetes下,配置所需的详细信息。
    • Kubernetes URL
    • Kubernetes服务器证书密钥
    • Kubernetes命名空间
    • 凭据
    • WebSocket

    出现这个问题是因为最终用户必须使用带有HTTPS的Jenkins作为自签名证书。因此,当Kubernetes插件试图启动基本jenkins-inbound-agent容器时,它不会标识主Jenkins证书。因此,无法找到请求目标的有效证书路径错误。

      null
        $ openssl s_client -connect jenkins.my.domain.net:443 -showcerts > jenkins.crt
        depth=0 C = IN, ST = , L = Delhi, O = domain, OU = IT Operations, CN = *.jenkins.my.domain.net
        verify error:num=20:unable to get local issuer certificate
        verify return:1
        depth=0 C = IN, ST = , L = Delhi, O = domain, OU = IT Operations, CN = *.jenkins.my.domain.net
        verify error:num=21:unable to verify the first certificate
        verify return:1
        $ ls -lrth jenkins.crt
        -rw-rw-r--. 1 jenkins jenkins 3.3K Oct 20 09:52 jenkins.crt
        $
    
    COPY jenkins.crt /tmp/jenkins.crt
    RUN keytool -import -trustcacerts -keystore /opt/java/openjdk/jre/lib/security/cacerts -storepass ******* -noprompt -alias jenkins-master -file /tmp/jenkins.crt \
         && rm -Rf /tmp/jenkins.crt
    
    $ docker build . -t myregistery.company.net:5000/company/jenkins-agent:latest
    $ docker push myregistery.company.net:5000/company/jenkins-agent:latest
    
    • 管理詹金斯>管理节点和云>配置云Kubernetes云详细信息
    • 高级..>默认提供程序模板名称>设置值default-java
    • 展开pod模板
      • name设置为default-java
      • 名称设置为JNLP
      • Docker图像设置为myregistery.company.net:5000/company/jenkins-agent:lates
      • 设置总是拉图像
      • 设置分配pseudo-ttytrue

      在此之后,创建一个示例管道项目,并使用下面的代码在Kubernetes集群上动态测试运行jenkins-inbound-agent。

      pipeline {
        agent {
          kubernetes {
            yaml '''
              apiVersion: v1
              kind: Pod
              '''
          }
        }
        stages {
          stage('Run') {
            steps {
                  sh 'date'
                  sh 'ls -lrth'
              
            }
          }
        }
      }
      

 类似资料:
  • 我试图配置RBAC来添加访问受限的新用户。我正在遵循以下教程:https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/#use-case-1-create-user-with-limited-namespace-access 它要求我使用Kubernetes CA批准用户签名请求: 找

  • 我们正在使用Docker 1.19运行库伯内特斯(1.18) Container是一个基于Java13的Spring启动应用程序(使用基本图像作为openjdk: 13-alpin),下面是内存设置。 豆荚: 内存-最小448M,最大2500M cpu-最小值0.1 容器: Xms:256M,Xmx:512M 当流量发送更长时间时,容器会突然重新启动;在Prometheus中,我可以看到Pod内存

  • 我对AWS上POD之间的跨集群通信有疑问。 我正在使用kubernetes在AWS上部署集群。两个星团位于同一区域和AZ。两个集群都部署在各自的VPC中,子网不重叠。我已经成功创建了VPC对等,以在两个VPC之间建立通信。VPC的仆从(实例)可以通过私有IP相互ping。 问题是,来自一个集群(VPC)的Kubernetes吊舱不能通过其内部IP ping另一个集群中的吊舱。我看到流量离开吊舱和仆

  • 我在GKE负责詹金斯。构建的一个步骤是使用< code>kubectl部署另一个集群。我在jenkins容器中安装了gcloud-sdk。正在讨论的构建步骤是这样做的: 然而,我得到了这个错误(虽然它在本地正常工作): 注意:我注意到,在没有配置的情况下(~/.kube为空),我可以使用kubectl并访问pod当前运行的集群。我不知道它是如何做到的,它是否使用/var/run/secrets/k

  • 我在minikube上运行kubernetes,我在一个代理后面,所以我设置了env变量(HTTP_代理) pod从未启动,我得到了错误 运行良好

  • 我的Java微服务正在AWS EC2实例上托管的k8s集群中运行。 我有大约30个微服务(nodejs和Java8的良好组合)在K8s集群中运行。我面临一个挑战,我的java应用程序pods意外重启,导致应用程序5xx数量增加。 为了调试它,我在pod和应用程序中启动了一个newrelic代理,并找到了以下图表: 在我可以看到的地方,我的Xmx值为6GB,我的用途最大为5.2GB。 这清楚地表明J