ここでは、ingress-controllerをデプロイする方法については説明せず、ingresのnginxを使用する方法のみを示します。これは主に、ingres nginxを使用して、nginxの多様な構成を実現し、nginxの手動展開を使用するのと同じ便利さを実現する方法を示しています。説明のために以下のケースがあります:
-
ケース1(基本的な転送、https構成とアノテーションの基本的な使用)
-
ケース2(アノテーションによるnginxのパーソナライズされた構成)
-
ケース3(注釈による基本的な書き換え構成)
-
ケース4(nginx.ingress.kubernetes.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
上記の入力を定義し、テスト名前空間で実行するように指定しました(この名前空間は自分で作成する必要があります)。バックエンドでは、nginx-a、nginx-b、nginx-c、nginx-dの4つのサービスグループを定義し、サービスポートを80として指定します(これらの4つのサービスグループも独自に定義する必要があります) 。
次に、入力のメイン構成で、tls証明書を定義し、使用可能なホストと使用するシークレットを指定します。最初に証明書をシークレットにインポートしてから、シークレットを直接引用します。インポート方法は次のとおりです。
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时指定的名称
注釈の構成:サーバーでの動作
# 指定了我们使用后端ingress controller的类别,如果后端有多个ingress controller的时候很重要
kubernetes.io/ingress.class: "nginx"
# 指定我们的rules的path可以使用正则表达式,如果我们没有使用正则表达式,此项则可不使用
nginx.ingress.kubernetes.io/use-regex: "true"
ルール構成:場所に基づいて行動する
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
注:入力コントローラーへの上記で定義されたすべてのパスはnginxロケーションルールに変換されるため、ロケーションの優先度はnginxと同じです。パスがnginxに変換された後、最長のパスルールが最初にランク付けされ、最短のルールが最後にランク付けされます。
ケース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に基づいて、注釈のいくつかの構成を追加しました
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つの基本構成をカスタマイズしましたが、さらに基本的な構成を定義することもできます。nginx-configurationアノテーション関連ドキュメントを参照してください。
ケース3(リライトリライト1):
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/(。*)にアクセスすると、https://gogen-test.oss-cn-hangzhou.aliyuncsに書き換えられることを意味します。 com / $ 1、複数のパスがある場合、それぞれが書き換えられるため、単一のパス(つまり、場所)を置き換えるだけでよい場合は、単一のマニフェストを使用して書き込みます。個人的にはそうではないと思います。調査は徹底していません。問題があれば指摘してください。
ケース3(リライトリライト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.ingress.kubernetes.io/server-snippet」を直接使用して構成を指定します。ここでは、nginx構成を直接書き込むことができます。これにより、書き換えの書き換えを実現できるだけでなく、より多くの機能要件を実現できます。サーバー上で動作できます
ケース5(configMapを使用):
アノテーションを使用してnginxの柔軟でパーソナライズされた構成を完全に実装できない場合があります。現時点では、configMap構成を使用する必要があります。公式のconfigMap使用ドキュメント、注釈、および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"
データの内容については、上記の[公式configMap使用文書]を参照してください。メタデータの名前と名前空間を自由に書き込むことはできません。nginx-ingress-controllerYAML構成ファイルの構成を参照する必要があります。
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 = $(POD_NAMESPACE)/ nginx-configuration)」を参照してください。ここで、configmapの名前空間はnginx-ingress-controllerと同じ名前空間である必要があり、名前は「/」の後の名前です。
構成が完了したら、構成リストを適用します。configMapを介して適用された構成は直接有効にできません。ポッドを再起動する必要があります。最も簡単な方法は、編集を使用してnginx-ingress-controllerのコントローラーを編集し、実行するパラメーターを変更することです。ポッドのアップグレードをトリガーするポッドの操作には影響しません。そのため、次のような構成が有効になります。
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
「initialDelaySeconds」を11などに変更できます。この値の意味は、ポッドがヘルスチェックの実行を開始する時間(秒単位)です。
https://blog.51cto.com/270142877/2338348
ここでは、ingress-controllerをデプロイする方法については説明せず、ingresのnginxを使用する方法のみを示します。これは主に、ingres nginxを使用して、nginxの多様な構成を実現し、nginxの手動展開を使用するのと同じ便利さを実現する方法を示しています。説明のために以下のケースがあります: