OpenShiftで作ったサービスを、Routeを使わずにアクセスさせる

はじめに

OpenShiftのチュートリアルや教育資料を見ると、OpenShift上のアプリケーションへのアクセスにRouteを使う例が多いです（ちなみにRouteがOpenShiftとしての奨励手段のようです）。Routeを使うと、"oc expose"コマンドでServiceを外部からURLでアクセスできるようになります。たとえば、"myservice"というServiceを、"myservice.ocp4.example.local"というホスト名で公開したい場合、以下のようなコマンドでRouteをつくることができます（なお、ホスト名は"<任意の名前>.."という形になります）。

oc expose service myservice --hostname=myservice.ocp4.example.local

ただ、Routeを使いたくない！という場合もあり、本記事ではRouteを使わずにServiceを公開する方法を紹介します。なお、単にNodePort + Load Balancerを使う、というだけのお話なので、OCP/k8sに詳しい人は読み飛ばしてください(^^;)

RouteでServiceを公開するハードル

前述の方法でServiceをRouteを使って公開することができるのですが、実際には少しハードルがあります。それは、このの例の"myservice.ocp4.example.local"という名前を、OpenShiftの前段にあるLoad BalancerのIPアドレスに解決する必要があるということです。OpenShiftを構築するときには、こういった名前解決を行うためのDNSが必要となるため、Helper Node上に独自にDNSを立ることもあるかと思います。このDNSを使えば、上記の名前解決はできます。
ただし、外部からアクセスするクライアントは、Helper Node上のDNSではなく、イントラネット上に存在するDNSを使っているはずです。そのため、名前解決ができず、Routeへアクセスできない、というケースも有るかと思います。

これを解決するためには、ワイルドカードDNSレコードをイントラネット側のDNSに設定する必要があります。これによって、イントラネット側から"*.ocp4.example.local"という名前をLoad BalancerのIPアドレスに解決できるようになります。ただ、なかなかこれが難しい場合があります。理由としては・・・

1. イントラネット側のDNSが、そもそもワイルドカードDNSレコードをサポートしていない場合がある
2. イントラネットのDNSにワイルドカードDNSレコードを登録してもらうための社内申請やネゴが面倒

というようなことが考えられます。

Routeをつかわないでサービスを公開する簡単な方法

そこで、Routeではない他の単純な方法でサービスを公開したくなります。一番簡単な方法は、PodへアクセスするためのServiceをNodePortとして作ることです。NodePortを使うと、各Workerノードが持つIPアドレスを使ってアクセス可能になります（なお、どのworkerノードへアクセスしても、Podが存在するノードへ転送されます）。ポート番号はデフォルトの設定では、30000〜32767の間のいずれかが自動割当されます。ポート番号を明示的に指定することも出来ます。
以下のサービス定義例では、myappというdeployのポート8080を、NodePortのポート30030として公開しています。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: myapp
  name: myservice
spec:
  type: NodePort
  ports:
  - name: nginx
    port: 8080
    protocol: TCP
    nodePort: 30030
  selector:
    deployment: myapp

これで、"workeｒノードのIP:30030"でOCPクラスター外からサービスにアクセスできるようになりました。ただ、これだと外部からアクセスするときに特定のworkerノードのIPを指定する必要があります。workerノードの一部がメンテナンス中のときには他のworkerノードにアクセスする、みたいなことをクライアント側にやらせたくありません。
そこで、OpenShiftには必須なLoad Balancerを使って、リクエストを全workerノードの30030ポートへ分散させることにします。これによって、あるworkerノードがメンテナンス中の場合も、他のノードが自動的に使われるようになります。外部からアクセスするときは、"LoadBalancerのホスト名:転送元ポート"のような形でアクセス可能になります。

たとえば、Load BalancerとしてHAProxyを利用していて、ポート8000から、各workerノードのポート30030へ転送したいときは、以下のような設定をhaproxy.cfgへ入れることになります。

frontend nginx-http
    bind *:8000
    default_backend nginx-http
    option tcplog

backend nginx-http
    balance source
    server worker0 10.91.51.118:30030 check
    server worker1 10.91.51.119:30030 check
    server worker2 10.91.51.120:30030 check

これで、イントラネット側のDNSにワイルドカードDNSレコードを定義せず、お手軽にServiceを外部へ公開できるようになりました！
なお、Load BalancerはPodがどのWorkerノードで動いているか知っているわけではないので、指定したアルゴリズムで機械的に各ノードへ分散させているだけです。そのため、Load Balancerがリクエストを転送したworkerノードから、さらにPodが動いているWorkerノードへリクエストが転送されるオーバーヘッドが生じており、かならずしもパフォーマンス面からは最適なソリューションでは無いかもしれませんので、ご注意ください。