※このブログではサーバー運用、技術の検証等の費用のため広告をいれています。
記事が見づらいなどの問題がありましたらContactからお知らせください。
＜前のページ
【Kubernetes】MinikubeでIngressによるServiceの公開方法の解説

【Kubernetes】Ingressで複数のServiceをパスごとに公開

kubenetes Minikube Ingress kubectl Service サーバー開発

投稿日：2020年10月19日

このエントリーをはてなブックマークに追加
Ingressを使用するとパスごとに違うServiceをルーティングするすることができあます。この記事ではその方法について解説します。

はじめに

この記事について

この記事ではIngressを使用して複数のServiceをパスごとにコントロールして公開する方法について解説します。

環境

  • kubectl version 1.19.2
  • minikube version 1.13.1

実践

Ingressコントローラーの有効化

まずはIngressコントローラーを有効化させます。

今回の環境はMinikubeなのでアドオンのnginx-ingressのコントローラーを有効化させます。

ターミナル
$ minikube addons enable ingress
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled

アプリのデプロイ（複数）

まずはIngressでルーティングする対象のPodとServiceを作成します。

今回はリクエストが最終的にどのPodにたどり着いたのかを明確にするためにHelloKubernetesのImageを使用します。このImageはHTTPリクエストを送ると動いているPodのnameを表示してくれます。

まずはyamlファイルを作成します。

deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp1-pod
  template:
    metadata:
      labels:
        app: webapp1-pod
    spec:
      containers:
        - name: webapp1-app
          image: paulbouwer/hello-kubernetes:1.8
          ports:
            - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp2-pod
  template:
    metadata:
      labels:
        app: webapp2-pod
    spec:
      containers:
        - name: webapp2-app
          image: paulbouwer/hello-kubernetes:1.8
          ports:
            - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp3-pod
  template:
    metadata:
      labels:
        app: webapp3-pod
    spec:
      containers:
        - name: webapp3-app
          image: paulbouwer/hello-kubernetes:1.8
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: webapp1-svc
  labels:
    app: webapp1-svc
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: webapp1-pod
---
apiVersion: v1
kind: Service
metadata:
  name: webapp2-svc
  labels:
    app: webapp2-svc
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: webapp2-pod
---
apiVersion: v1
kind: Service
metadata:
  name: webapp3-svc
  labels:
    app: webapp3-svc
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: webapp3-pod

デプロイします。

ターミナル
$ kubectl apply -f deployment.yaml 
deployment.apps/webapp1 created
deployment.apps/webapp2 created
deployment.apps/webapp3 created
service/webapp1-svc created
service/webapp2-svc created
service/webapp3-svc created

Ingressルールの作成

次にserviceへルーティングするルールを作成します。

ターミナル
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: webapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: my.kubernetes.example
      http:
        paths:
          - path: /webapp1
            backend:
              serviceName: webapp1-svc
              servicePort: 80
          - path: /webapp2
            backend:
              serviceName: webapp2-svc
              servicePort: 80
          - path: /*
            backend:
              serviceName: webapp3-svc
              servicePort: 80

このルールは以下のようにルーティングする設定になります。

  • 接頭辞に/webapp1とついたパスのリクエスト（/webapp1、/webapp1aaa/bbb、webapp1/bbbなど）にはname:webapp1-svcのサービスを公開
  • 接頭辞に/webapp2とついたパスのリクエスト（/webapp2、/webapp2aaa/bbb、webapp2/bbbなど）にはname:webapp2-svcのサービスを公開
  • 上２つを満たさない全てのパスにはname: webapp3-svcのサービスを公開します。

ルールをデプロイします。

ターミナル
$ kubectl apply -f ingress.yaml 
ingress.networking.k8s.io/webapp-ingress created

ホストマシンから確認

ホストマシンから確認してみます。

まずはminikubeのノードのIPを確認し、ローカルの環境で名前解決をできるように/etc/hostsを編集します。

ターミナル
$  minikube ip
192.168.39.6
/etc/hosts
[...]

192.168.39.6  my.kubernetes.example

[...]

ブラウザからそれぞれのURLで確認してみましょう。

▲/webapp1のパスのページ
▲/webapp1/aaaのパスのページ
▲webapp2/bbbのページ
▲ルートページ
▲ランダムな文字列のパスのページ

問題なさそうですね。

ちなみに画像やCSSが取得できていない部分は特に問題ありません。

ワイルドカードで全てのパスがname:webapp1-svcに向いてしまっているため

/image/〇〇.jpgや/css/〇〇○.cssなどの素材に対してもこのサービスが公開されてしまっているだけです。

このエントリーをはてなブックマークに追加
＜前のページ
【Kubernetes】MinikubeでIngressによるServiceの公開方法の解説
関連記事
記事へのコメント
　　　　
検索
カテゴリ
Web開発
機械学習
プログラミング
その他
サーバー開発
Linux
目次