当該コンテンツは、ローカリゼーションサービスを準備しております。早急にローカライズサービスをご提供できるよう、努めております。

Ingress チュートリアル

Ingressは、クラスタ外部からのリクエストをIngressリソースで定義された規則に従ってクラスタ内部のサービスに接続します。 さらに詳しい説明は、KubernetesのIngress文書をご参照ください。 このガイドでは、URIによるルーティングとホストによるルーティングの2つの方法を設定してみます。

準備事項

  • 運用中のクラスターとkubectlのインストール、環境変数の設定が必要です。
  • クラスター生成はクラスター生成をご参考ください。
  • kubectlのインストールと環境変数の設定は、kubectlをインストールするを参照してください。

Ingress Controller 配布

次のコマンドを実行すると、ingress-nginxというNamespaceが作成され、Ingress実装チェーンのingress-nginxに必要なリソースが生成されます。

kubectl --kubeconfig $KUBE_CONFIG apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/2de5a893aa15f14102d714e918b0045b960ad1a5/deploy/static/mandatory.yaml
  • 実行結果
    namespace/ingress-nginx created
    configmap/nginx-configuration created
    configmap/tcp-services created
    configmap/udp-services created
    serviceaccount/nginx-ingress-serviceaccount created
    clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
    role.rbac.authorization.k8s.io/nginx-ingress-role created
    rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
    clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
    deployment.apps/nginx-ingress-controller created
    

Ingress Service 生成

外部からアクセスできるようLoadBalancerタイプのIngressServiceを作成します。

kubectl --kubeconfig $KUBE_CONFIG apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/2de5a893aa15f14102d714e918b0045b960ad1a5/deploy/static/provider/cloud-generic.yaml
  • 実行結果
    service/ingress-nginx created
    

    ロードバランサー作成可否をリアルタイムで確認

    kubectl --kubeconfig $KUBE_CONFIG get service -n ingress-nginx --watch
    
  • 実行結果
    NAME            TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
    ingress-nginx   LoadBalancer   172.17.116.11   <pending>     80:31583/TCP,443:32586/TCP   4s
    ingress-nginx   LoadBalancer   172.17.116.11   slb-1976810.n...   80:31583/TCP,443:32586/TCP   27s
    

    EXTERNAL-IP 確認

    サービスが pending 状態で作成が完了すると、 EXTERNAL-IPを確認します。
    kubectl --kubeconfig $KUBE_CONFIG get service -n ingress-nginx
    
  • 実行結果
    NAME            TYPE           CLUSTER-IP      EXTERNAL-IP                 PORT(S)                      AGE
    ingress-nginx   LoadBalancer   172.17.116.11   slb-1976810.ncloudslb.com   80:31583/TCP,443:32586/TCP   59s
    

Application とサービス配布

各々異なる情報を持つ2つの例題用デバイスとサービスを作成します。 例題用のDeploymentは自分のホスト情報を表示するdemo用のnginx containerで、各サービスはCluster IPタイプで生成されて外部から直接アクセスできない状態です。

kubectl --kubeconfig $KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/c47620d8d25b2a0e08648f225043adf6/raw/675addde0a56ba727824f30f92a73b40550fb73c/nks-tutorial-hello-service.yaml
  • 実行結果
    deployment.apps/a created
    service/a-svc created
    deployment.apps/b created
    service/b-svc created
    

URI ベースルーティング

先ほど作成したIngressServiceのExternalIPの後に付くPath別にルーティングをして、 /aを要請する場合と /bを要請する場合、それぞれ別のサービスにつながるように設定してみます。

Ingress 生成

例題のIngressリソースは以下の通り、各 pathによって backendを別々に設定し、 /aでアクセスする場合は a-svcに、 /bでアクセスする場合は b-svcにアクセスするように設定しました。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ab-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /a
        backend:
          serviceName: a-svc
          servicePort: 80
      - path: /b
        backend:
          serviceName: b-svc
          servicePort: 80

次のコマンドでIngressを生成します。

kubectl --kubeconfig $KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/eca9d12336e008f1c7102892750aeae5/raw/3f3d0916d89161a1d81ed19464b9991154a8b9f8/nks-tutorial-ab-ingress.yaml
  • 実行結果
    ingress.extensions/ab-ingress created
    

    例題ではTLS 設定を行わなかったため、強制redirection を防ぐために ingress annotation に nginx.ingress.kubernetes.io/ssl-redirect: "false"を追加しましたが、TLS を設定する際にはその annotation を削除してください。

Ingress 生成確認

kubectl get ingress コマンドで生成されたingressを確認することができます。

kubectl --kubeconfig $KUBE_CONFIG get ingress
  • 実行結果
    NAME         HOSTS   ADDRESS                     PORTS   AGE
    ab-ingress   *       slb-1976810.ncloudslb.com   80      19s
    

    サービス接続確認

    ブラウザまたはカレントを通して接続結果を確認すると、各自異なるサービスのPodにアクセスすることを確認できます。

    例題

  • http://slb-1976810.ncloudslb.com/a
    $ curl http://slb-1976810.ncloudslb.com/a
    Server address: 172.24.21.10:80
    Server name: a-57598bbddd-9hcc6
    Date: 09/Jul/2019:09:03:36 +0000
    URI: /a
    Request ID: add732582fb99d0cfffe3edc83169517
    
  • http://slb-1976810.ncloudslb.com/b
    $ curl http://slb-1976810.ncloudslb.com/b
    Server address: 172.24.21.11:80
    Server name: b-657f4794f4-k48hb
    Date: 09/Jul/2019:09:03:37 +0000
    URI: /b
    Request ID: 6cfd25c99f677c75ad815eaf57fc24c5
    

ホストベースのルーティング

今回は、同じEXTERNAL-IPに対してそれぞれ異なるドメインで、要請があれば別のサービスにつながるように設定してみます。

既存のingress削除

先に前で生成したab-ingressを削除します。

kubectl --kubeconfig $KUBE_CONFIG delete ingress ab-ingress
  • 実行結果
    ingress.extensions "ab-ingress" deleted
    

Ingress 生成

a.svc.comでリクエストする場合は a-svcで、 b.svc.comでリクエストする場合は、b-svcで接続するようにそれぞれの hostによって backendを設定した例は以下のとおりです。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ab-host-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: a.svc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: a-svc
          servicePort: 80
  - host: b.svc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: b-svc
          servicePort: 80

次のコマンドでIngressを生成します。

kubectl --kubeconfig $KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/39913ee1025c45aaa0d50753db8a7555/raw/91082b01c0f26313b0a11e61df8984ac6c6b5c46/nks-tutorial-ab-host-ingress.yaml
  • 実行結果
    ingress.extensions/ab-host-ingress created
    

    Ingress 生成確認

    kubectl get ingress コマンドで生成されたingressが確認でき、 HOSTSa.svc.com, b.svc.comがあります。
    kubectl --kubeconfig $KUBE_CONFIG get ingress
    
  • 実行結果
    NAME              HOSTS                 ADDRESS                     PORTS   AGE
    ab-host-ingress   a.svc.com,b.svc.com   slb-1976810.ncloudslb.com   80      3m57s
    

サービス接続確認

例題のホストに設定したドメインは実際には存在しないドメインであるため、curl コマンドに -H host オプションを入れて、ホスト別接続時に他のサービスが表示されるか確認してみます。

例題

  • a.svc.com
    $ curl -H host:a.svc.com http://slb-1976810.ncloudslb.com
    Server address: 172.24.21.10:80
    Server name: a-57598bbddd-9hcc6
    Date: 09/Jul/2019:08:33:03 +0000
    URI: /
    Request ID: b340711ab142bef67fdb07e7fd077ddb
    
  • b.svc.com
    $ curl -H host:b.svc.com http://slb-1976810.ncloudslb.com
    Server address: 172.24.21.11:80
    Server name: b-657f4794f4-k48hb
    Date: 09/Jul/2019:08:33:12 +0000
    URI: /
    Request ID: eb6a876acbb2db7155ff26992b6635e4
    

参考事項

名前に _(underscore)があるRequest Headerは、サーバで確認できません。

ingress-nginxでは、request header名に_(underscore)が入ると強制的に削除します。 これを回避するためには、ConfigMapに enable-underscores-in-headers: trueを追加する必要があります。 詳細については、 ingress-nginxのConfigMaps文書を参照してください。

Load Balancerでingress-nginx PodがないNodeは、Health Checkに失敗することで表示されます。

上記の例で、ingress-nginxService .spec.externalTrafficPolicy: Localに設定されていることを確認することができます。

.spec.externalTrafficPolicyはサービスで外部トラフィックをどのようにルーティングするかを設定できます。 使用可能な値は Cluster(default)と Localです。

  • Cluster: 外部トラフィックを全Podに分散します。 他のNodeにあるPodに伝えるとき、2番目のホップを誘発することはできますが、Podへのトラフィックはバランスよく分散できます。
  • Local: 外部トラフィックをローカル NodeにあるPodでのみ伝達します。 他のNodeに対する2番目のホップを避け、不均衡なトラフィック分散が発生することがあります。

ingress-nginxServiceの .spec.externalTrafficPolicy: Localになっている場合は、ingress-nginxPodが動作中のNodeのみトラフィックが伝達されるので、それ以外のサーバはHealthCheckに失敗するという結果になります。

動作の詳細は Kubernetesの文書動作の詳細は[で確認することができ、 各サービスに合わせた設定への変更をお勧めします。

に対する検索結果は~件です。 ""

    に対する検索結果がありません。 ""

    処理中...