使用nginx入口时是否有pod级nginx的意义?

时间:2018-11-02 18:49:33

标签: nginx kubernetes google-kubernetes-engine kubernetes-ingress

我想知道在下面的实现中是否应该具有pod级别的nginx: 从VM迁移后,我以前使用的是普通入口和kube-lego,现在我使用的是cert-manager和GKE。 我的入口:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: myapp-static-ip
    kubernetes.io/ingress.class: nginx
    kubernetes.io/ingress.allow-http: "false"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/rewrite-target: /
    certmanager.k8s.io/cluster-issuer: letsencrypt
  namespace: default
spec:
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-crt
  rules:
  - host: 
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp
          servicePort: http

我的服务:

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 32111
    protocol: "TCP"
    name: http
  selector:
    app: myapp

我的部署

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: gcr.io/myapp-1/myapp:latest
        imagePullPolicy: Always
        env:
            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: cloudsql
                  key: username
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: cloudsql
                  key: password
            -
              name: STATIC_ROOT
              value: https://storage.googleapis.com/myapp-api/static/
            -
              name: STATIC_URL
              value: https://storage.googleapis.com/myapp-api/static/
            -
              name: MEDIA_ROOT
              value: /myapp/media
            -
              name: MEDIA_URL
              value: http://myapp.com/media/

      -
        name: nginx
        image: nginx
        command: [nginx, -g,'daemon off;']

        imagePullPolicy: Always
        volumeMounts:
          -
            name: api-nginx-config
            mountPath: /etc/nginx/nginx.conf
            subPath: nginx.conf
          -
            name: myapp-media
            mountPath: /myapp/media/

        ports:
        - containerPort: 80

      - image: b.gcr.io/cloudsql-docker/gce-proxy:1.05
        name: cloudsql-proxy
        command: ["/cloud_sql_proxy", "--dir=/cloudsql",
                  "-instances=myapp-1:europe-west1:myapp-api=tcp:5432",
                  "-credential_file=/secrets/cloudsql/credentials.json"]
        volumeMounts:
          - name: cloudsql-oauth-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: ssl-certs
            mountPath: /etc/ssl/certs
          - name: cloudsql
            mountPath: /cloudsql
          - name: myapp-media
            mountPath: /myapp/media

      volumes:
        - name: cloudsql-oauth-credentials
          secret:
            secretName: cloudsql-oauth-credentials
        - name: cloudsql
          emptyDir:
        - name: api-nginx-config
          configMap:
            name: api-nginx-config
        -
          name: myapp-media
          persistentVolumeClaim:
            claimName: myapp-media

我的nginx conf:

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-nginx-config
data:
  nginx.conf: |
    events {
      worker_connections  1024;
    }
    http {
      upstream api {
        server 127.0.0.1:8080 fail_timeout=0;
      }
      server {
        access_log /var/log/nginx/http-access.log;
        error_log /var/log/nginx/http-error.log;
        listen 80;
        listen [::]:80;
        server_name myapp.com;

        location /media/ {
        alias   /myapp/media;
        }

       location = /favicon.ico {
        access_log off;
        log_not_found off;
        }

        location / {
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $host;
          proxy_set_header X-NginX-Proxy true;
          proxy_pass http://127.0.0.1:8080/;
        }
      }
    }

给定我可以直接将myapp/media直接映射到卷装载中的/media且我的tls由入口处理的目的,是否有任何主要目的。如前所述,我主要关心的是Pod级Nginx,在这种情况下它没有用吗?这只是我从以前的实现中带来的负担吗?

2 个答案:

答案 0 :(得分:1)

通常,没有必要再添加一个额外的nginx pod。如果这样做,则可能会造成双重入侵。一个nginx入口控制器窗格已经包含nginx,您可以按比例放大/缩小。

您想要保留它的一个原因是为了向后兼容,例如,如果您想要使用一个入口,但又希望以这种方式逐步推出它:创建新的nginx入口->从您自己的流量中获取流量只有通过新的nginx入口和您自己的nginx才能使用nginx,直到您翻转了所有pod为止->逐渐删除自己的nginx,直到全部删除为止。

另一个原因是要支持nginx入口控制器尚不支持的非常特定的nginx配置。

答案 1 :(得分:1)

由于上面的答案中列出的原因,您可能需要运行自己的nginx部署,加上,您可能需要扩展nginx部署,比如说10个副本。您不能像这样缩放入口。但是无论如何,您只需要其中之一。