nginx - 使用带有Google登录插件的Ingress NGINX Controller在GKE中公开Jenkins

Question

我正在尝试在 Google Kubernetes Engine 中设置我的Jenkins实例，也正在使用 Google登录插件，以便我可以用我的GCP用户登录到Jenkins，我已经安装了Ingress Controller ，它是 NGINX 并公开了Jenkins使用入口的服务。

我要访问Jenkins的域是: util.my-app.com/jenkins

在参数Jenkins URL下的Jenkins配置中，我还设置了该域名 util.my-app.com/jenkins

这是我的Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: jenkins-ing
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: util.my-app.com
    http:
      paths:
      - path: /jenkins/*
        backend:
          serviceName: jenkins-svc
          servicePort: 80

在“GCP凭据”页面中，在“授权的JavaScript起源”下设置 http://util.my-app.com ，在“授权的重定向URI”下设置 http://util.my-app.com/jenkins/securityRealm/finishLogin

它要么返回404状态，要么执行无限重定向，我注意到当Jenkins Google登录插件确实重定向它时，就像 http://util.my-app.com/securityRealm/finishLogin 一样，没有“jenkins”部分，我的设置有什么问题吗？

Answer 1

欢迎来到Stack Laimis!

我测试了您的入口对象，然后出现了一个问题。

您的Ingress缺少rewrite-target:

In some scenarios the exposed URL in the backend service differs from the specified path in the Ingress rule. Without a rewrite any request will return 404. Set the annotation nginx.ingress.kubernetes.io/rewrite-target to the path expected by the service.

文档 shows the structure required中的以下示例:

这是您进行编辑的入口:

添加了一行nginx.ingress.kubernetes.io/rewrite-target: /$1

apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
kind: Ingress
metadata:
  name: jenkins-ing
  annotations:
     nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: util.my-app.com
      http:
        paths:
          - path: /jenkins/*
            backend:
              serviceName: jenkins-svc
              servicePort: 80

复制:

首先，我创建了一个部署。为此，我将echo-app用于其说明性输​​出。

添加一项服务，以将其在port 8080上的集群内部公开，并在外部以NodePort公开。

apiVersion: apps/v1
kind: Deployment
metadata:
 name: echo1-deploy
spec:
 selector:
   matchLabels:
     app: echo1-app
 template:
   metadata:
     labels:
       app: echo1-app
   spec:
     containers:
     - name: echo1-app
       image: mendhak/http-https-echo
       ports:
       - name: http
         containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 name: echo1-svc
spec:
 type: NodePort
 selector:
   app: echo1-app
 ports:
   - protocol: TCP
     port: 8080
     targetPort: 80

我将再创建一个部署和服务，通过这种方式，我们可以进一步尝试Ingress，并演示当您拥有在Ingress上需要公开的多个服务而需要做的事情

apiVersion: apps/v1
kind: Deployment
metadata:
 name: echo2-deploy
spec:
 selector:
   matchLabels:
     app: echo2-app
 template:
   metadata:
     labels:
       app: echo2-app
   spec:
     containers:
     - name: echo2-app
       image: mendhak/http-https-echo
       ports:
       - name: http
         containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 name: echo2-svc
spec:
 type: NodePort
 selector:
   app: echo2-app
 ports:
   - protocol: TCP
     port: 8080
     targetPort: 80

和您一样，我将使用一个入口，唯一的区别是:

将服务更改为echo1-svc，以模拟您的jenkins-svc

在echo2-svc中添加了另一个服务，以重定向除与第一个规则匹配的请求以外的所有http请求。

apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
kind: Ingress
metadata:
  name: jenkins-ing
  annotations:
     nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: util.my-app.com
      http:
        paths:
          - path: /jenkins/*
            backend:
              serviceName: echo1-svc
              servicePort: 80
          - path: /(.*)
            backend:
              serviceName: echo2-svc
              servicePort: 80

现在，我将部署此应用程序和入口:

$ kubectl apply -f echo1-deploy.yaml 
deployment.apps/echo1-deploy created
service/echo1-svc created

$ kubectl apply -f echo2-deploy.yaml 
deployment.apps/echo2-deploy created
service/echo2-svc created

$ kubectl apply -f jenkins-ing.yaml 
ingress.networking.k8s.io/jenkins-ing created

现在让我们检查是否一切都在运行:

$ kubectl get all
NAME                               READY   STATUS    RESTARTS   AGE
pod/echo1-deploy-989766d57-8pmhj   1/1     Running   0          27m
pod/echo2-deploy-65b6ffbcf-lfgzk   1/1     Running   0          27m

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/echo1-svc    NodePort    10.101.127.78   <none>        8080:30443/TCP   27m
service/echo2-svc    NodePort    10.106.34.91    <none>        8080:32628/TCP   27m

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/echo1-deploy   1/1     1            1           27m
deployment.apps/echo2-deploy   1/1     1            1           27m

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/echo1-deploy-989766d57   1         1         1       27m
replicaset.apps/echo2-deploy-65b6ffbcf   1         1         1       27m

$ kubectl get ingress
NAME          HOSTS             ADDRESS   PORTS   AGE
jenkins-ing   util.my-app.com             80      4s

如您所见，echo1-svc在port 30443上暴露在kubernetes外，在echo2-svc上暴露在port 32628上

使用入口规则，我们可以在端口80上 curl ，它将重定向到指定的服务。

由于我没有此域，因此我将在/etc/hosts文件中添加一条记录，以模拟将其定向到我的kubernetes IP的DNS解析。

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

192.168.39.240  util.my-app.com

$ curl util.my-app.com/jenkins
{
  "headers": {
    "host": "util.my-app.com",
    "x-real-ip": "192.168.39.1",
    "x-forwarded-host": "util.my-app.com",
    "x-forwarded-port": "80",
    "x-forwarded-proto": "http",
    "user-agent": "curl/7.52.1",
  },
  "method": "GET",
  "hostname": "util.my-app.com",
  "ip": "::ffff:172.17.0.6",
  "protocol": "http",
   "subdomains": [
    "util"
  ],
  "os": {
    "hostname": "echo1-deploy-989766d57-8pmhj"
  }

您可以看到HTTP GET被重定向到 echo1-svc后端的pod
-现在让我们检查一下在没有 /jenkins/的情况下 curl 域时会发生什么

$ curl util.my-app.com
{
  "headers": {
    "host": "util.my-app.com",
    "x-real-ip": "192.168.39.1",
    "x-forwarded-host": "util.my-app.com",
    "x-forwarded-port": "80",
    "x-forwarded-proto": "http",
    "user-agent": "curl/7.52.1",
 },
  "method": "GET",
  "hostname": "util.my-app.com",
  "ip": "::ffff:172.17.0.6",
  "protocol": "http",
  "subdomains": [
    "util"
  ],
  "os": {
    "hostname": "echo2-deploy-65b6ffbcf-lfgzk"

您可以看到HTTP GET已重定向到 echo2-svc后端的pod。

我知道您的问题也解决了有关您的Google身份验证的问题，但我建议您先更正您的入口，然后在此处粘贴状态(如果您仍然无法正确重定向入口，则返回的状态)。

如果您有任何疑问，请在评论中告诉我。