Deis Workflow v2.13.0でKubernetesのIngressがサポートされた件

Deisがverupした

本日、Deis Workflowがverupしたんですが、Changelogを見てるとIngressというものがなんか導入されてDeis/routerなくてもいけるみたいなことが。

そもそもWhat is Ingress?

Kubernetesのたくさんあるリソースのタイプのうちの一つのIngress。 これについて学習したその記録を残す。

Kubernetesのリソース Service

まず、Ingressを理解する前にKubernetesにおけるServiceを理解する必要がある。Serviceã‚‚Kubernetesのリソースのタイプのうちの一つで、簡単に言うとclusterと外部を接続を抽象化したもの。例えば、このserviceのtypeã‚’LoadBalancerと書けば、kubernetesがいい感じにバックエンドのクラウドプロバイダーを見て勝手にLBを作ってくれる。 バックエンドがAWSならELB、GCPならGoolge Load Balancingという具合に。

こういう概念になる。

    internet
        |
  ------------
  [ Service ]  (例: ELBなど)
        |
  [ App     ] 

:point_up: ここでは分かりやすさのためにAppって書いてるけど、本当はKubernetesの場合、コンテナのセットのPodという単位が基本。本当はそのPodを集合したReplicaSet、それを司るDeploymentとかがいるんだけど、その辺は割愛。まぁアプリケーションが動いているコンテナがいると思ってくれればOK。

他に増えたらルーティングどうするの

さっきの例だと一つのServiceとあるバックエンドのアプリケーションという感じだった。これを複数のアプリケーション立ち上げようとするとどうなるかっていうと、Serviceをたくさん増やしてあげればいいんだけど、そうするとその分、外部から接続するためのIPアドレスがたくさん生成されるし、DNSレコードの管理とか面倒になってくる。DNSだとキャッシュとかあるし、迅速で柔軟な変更が難しいよね（って話がどっかに書いてあったんだけど忘れてしまった・・）

            internet
                |
              [ dns ]
     |-----------|-----------|
  ------------------------------------
   IP:1.2.3.4   IP:5.6.7.8  IP:9.1.2.3
  [ Service ]  [ Service ] [ Service ]
        |          |            |
  [   App  ]   [   App  ]   [   App  ]

じゃあDeis君はルーティングどうしてたのか

Deis/routerっていうcomponentがあって、それがLBと振り分けを行うnginxで構成されてた。GCP上で作るとこうなる。Load Balancerは1つなのでIPアドレスも一つ。

            internet
                |
             [ dns ]
                |
  -------------------------------------
           IP:1.2.3.4
           [ Service ] <- Google LoadBalnacing
                |
          [ Deis/router ] <- 簡単に言えばただのnginx。virtual hostでbackendに流す
                |
       ------------------------
      |          |            |
 [   App  ]   [   App  ]   [   App  ]

Deis/routerの代わりにKubernetesのリソース Ingress

Ingressは各Serviceへのルーティングのルールセットを抽象化したようなもの。L7のルーティングができるやつ。そのルールの書き方は、host baseだったり、pathベースだったりで書ける。また、SSL終端などの設定も書くことができる。 例：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

ただ、Ingressはルールを抽象化しただけのobjectなのでこいつ自身がルーティングとか何かの処理を受けるということではなく、ルーティングしたりする実際の処理を行うIngress Controllerという実体へ命令するだけである。 なので、Ingressへルールを書くと、何が起きるかというと、そのルールを見て、バックエンドにいるIngress ControllerへAPIを発行するなり、configを突っ込んだりするなどの命令を出すだけの存在。なので、terraform的なものに近いのかもしれない。

Ingress Controllerとは

github.com

で、Ingress Controllerってなんなのかっていうと、結局は、LoadBalancerの実装である。標準で用意されているIngress ControllerはNginxとGCEという2つがあり、Nginxは単にnginxでできたLBの実装である。 もちろん、自分でIngress Controllerを作ることもできる。例として、traefikというGolangでできたReverse Proxy的なやつをIngress Controllerとする例がDeisの公式にはのっていた。

GCEの場合は、Google Loadbalancing、URL MapなどGCPのリソースでそれを実現するようになってる。

なので、Ingressを使った場合はこのようになる。下の図の外部と接続するServiceからAppと接続するための内部用Serviceあたりまでを多分管理してくれる。

            internet
                |
             [ dns ]
                |
  -------------------------------------
           IP:1.2.3.4
           [ Service ] <- Google LoadBalnacing
                |
  [ HTTP TargetProxy や URL map ] <- GCPの振り分けしてくれるやーつ
                |
       ------------------------
      |          |            | 
 [ Service ]  [ Service ] [ Service ] <- 内部IPだけのNodePortというtypeのサービス
      |          |            |
 [   App  ]   [   App  ]   [   App  ]

まとめ

なので、Ingressを使えば、Deis/routerはいらなくなるっていう話。Deis/routerは設定が色々面倒なので、Ingressを利用した方が色々とすっきりしそうだし、わざわざこれが作られるってことは今後はDeis/routerからIngressベースのものになっていくのではと予想している。 というか、Deis君が実装しているものはどんどんKubernetesが吸収していき、いつかDeis君はいなくなるのではという未来が見えてきた。

あと、KubernetesはIngressやServiceのように現実世界のある何かを一つのものに抽象化して、裏側でよしなに実装がせっせと書いてあるという仕組みになっている。ほんと発想がすごい なので、Kubernetesやるときは、あんまりTerraformの出番がない。ないけど、あんまり困らない。なぜかっていうとKubernetesもTerraformみたいなものでもあるから。