Kubenetes Ingress Nginnx使用

ここでは、どのようにイングレス・controllerを展開するかについては説明しませんが、イングレスのinxの使い方だけを実証します.主なプレゼンテーションは、手動で展開したnginxと同じように、ingres inxを使用することができるように、ingres inxの多様な構成を実現するために、ingres inxを使用する方法を示しています.ここでは以下のいくつかのケースを使って説明します.

ケース1(基本転送、https構成とannotationsベース使用)

ケース2(annotationsによるnginxの個別設定)

ケース3(annotationsによるrewrite基本構成)

ケース4(inx.ingress.kubergnetes.io/server-snippetの使い方を紹介する)

ケース5(configMapを使ってよりパーソナライズされた構成をする)

ケース1(最も簡単な基本構成):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-a
          servicePort: 80
      - path: /.*.(txt|css|doc)
        backend:
          serviceName: nginx-b
          servicePort: 80
      - path: /(api|app)/
        backend:
          serviceName: nginx-c
          servicePort: 80
      - path: /api
        backend:
          serviceName: nginx-d
          servicePort: 80

上記ではingresを定義し、testの名前空間で実行するよう指定しました.バックエンドは、4つのグループのサービスを定義しました.それぞれ、nginx-a、nginx-b、nginx-cとnginx-dで、サービスのportを80と指定しました.
その後、私達のingresの主な構成では、tls証明書を定義し、使用可能なhostと必要なsecretを指定しました.私たちは先に証明書をsecretに導入し、secretを直接参照します.

kubectl create secret tls gogen.cn --cert=1592339__gogen.cn.pem --key=1592339__gogen.cn.key -n test

tls:
- hosts:                        #     ，     ，                
  - nginx-a.gogen.cn            #    ，       ，  secret       
  secretName: gogen.cn          #  secret      

annotations配置:serverに作用します.

#          ingress controller   ，       ingress controller      
kubernetes.io/ingress.class: "nginx"

#      rules path         ，             ，       
nginx.ingress.kubernetes.io/use-regex: "true"

rules配置:locationに作用する

rules:
- host: nginx-a.gogen.cn            #      nginx   server_name
  http:
    paths:
    - path: /                       #  path      location，path     “/”。        ，           
      backend:
        serviceName: nginx-a        #     service
        servicePort: 80             #    service     ，   service port     
    - path: /.*.(txt|css|doc)        #       （      ）,             ，     ingress controller  nginx   ,         txt,css,doc url     nginx-b service
      backend:
        serviceName: nginx-b
        servicePort: 80
    - path: /(api|app)/              #      api app          nginx-c service
      backend:
        serviceName: nginx-c
        servicePort: 80
    - path: /api                    #      api   url（       ，        ）   ，   nginx-d
      backend:
        serviceName: nginx-d
        servicePort: 80

説明:上で定義されたすべてのpathからiness controllerは、nginx location規則に変換され、locationに関する優先度はnginxと同じである.pathはnginxに変換すると、pathルールの一番長いのが一番前で、一番短いのが一番後ろです.
ケース2(いくつかのパラメータを変更):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-a
          servicePort: 80
      - path: /.*.(txt|css|doc)
        backend:
          serviceName: nginx-b
          servicePort: 80
      - path: /(api|app)/
        backend:
          serviceName: nginx-c
          servicePort: 80
      - path: /api
        backend:
          serviceName: nginx-d
          servicePort: 80

ケース1に基づいてannotationsのいくつかの構成を追加しました.

kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/use-regex: "true"

#      ，   5s
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"

#             ，   60s
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"

#           ，   60s
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"

#       ，    ，   20m
nginx.ingress.kubernetes.io/proxy-body-size: "10m"

上の4つの基本的な構成をカスタマイズしました.また、より多くの基本的な構成を定義できます.
判例3(rewrite書き換え一):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-rewrite-tfs
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: https://gogen-test.oss-cn-hangzhou.aliyuncs.com
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /v1/tfs
        backend:
          serviceName: nginx-a
          servicePort: 80

上記の方法も公式の方法であり、「nginx.ingress.kubernetes.io/rewrite-target」を使って定義されています.上記の定義により代表が訪問すればhttps://nginx-a.gogen.cn/v1/tfs/(.*)は、rewriteがhttps://gogen-test.oss-cn-hangzhou.aliyuncs.com/$1,複数のpathがあれば、それぞれrewriteされますので、単一のpath(つまりlocation)を置き換えるだけであれば、単独でmaniftsを使って書きます.ここは私個人の感覚ではこのようにすべきではないです.徹底的に研究できないので、問題があれば指摘してください.
ケース3(rewrite書き換え2):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/server-snippet: |
        if ($uri ~* "/v1/tfs/.*") {
            rewrite ^/v1/tfs/(.*)$ https://gogen-test.oss-cn-hangzhou.aliyuncs.com/$1 permanent;
        }
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-a
          servicePort: 80
      - path: /.*.(txt|css|doc)
        backend:
          serviceName: nginx-b
          servicePort: 80
      - path: /(api|app)/
        backend:
          serviceName: nginx-c
          servicePort: 80
      - path: /api
        backend:
          serviceName: nginx-d
          servicePort: 80

ここで直接に「nginx.iness.kubernetes.io/server-snippet」を使って配置を指定します.ここで直接にnginxの配置を書くことができます.ここでrewriteの書き換えを実現するだけではなく、より多くの機能ニーズを実現できます.serverに作用するものであれば、すべて書き換えることができます.
ケース5(configMap使用):
私たちはannotationsを使って、全部で私たちのinxの柔軟な個性化の配置を実現することができません.この時、configMapの配置に助けを借りる必要があります.公式configMapは文書を使用して、annotationsとconfigMapは関係表を照合します.
まずconfigMapファイルを作成します.以下の通りです.

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration
  namespace: kube-system
data:
  use-http2: "false"
  ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2"
  ssl-ciphers: "HIGH:!RC4:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!EXP:+MEDIUM"

 dataの内容は上記の「公式configMap使用文書」を参考にして、metadata内のnameとnamespaceは勝手に書いてはいけません.inx-ingres-controller YAMLプロファイルの構成を参照してください.

      containers:
      - args:
        - /nginx-ingress-controller
        - --configmap=$(POD_NAMESPACE)/nginx-configuration
        - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
        - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
        - --annotations-prefix=nginx.ingress.kubernetes.io
        - --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb
        - --v=2

参照"---configmap="(PODuNAMESPACE)/nginx-configration)"では、configmapの名前空間は、nginx-ings-controllerと同じ名前空間が必要です.名前は"/"後の名前です.
配置完了後のappleプロファイルリストは、configMapで構成された配置applyで直接的に有効にならないため、podsを再起動する必要があります.最も簡単な方法は、editでnginx-ingress-controllerを編集し、podsの運転に影響しないパラメータを変更して、podsのアップグレードをトリガします.

        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1

「initial DelaySeconds」を11または他のものに変えてもいいです.この値の意味はpodが起動してからいつ健康診断を開始しますか?単位は秒です.
転載先:https://blog.51cto.com/270142877/2338348