MicroK8sでContourを利用する

はじめに

他に似た記事がなかったので備忘録。

Ingressを使ったバーチャルホスト運用をする中で、CI/CD上でバーチャルホストを新たに増やして、試験デプロイするようなイカした環境を構築したかった。
一つのIngressリソースの中でバーチャルホストを動的に増減させようとすると、Manifestのspec.rulesの書き換えする必要があるが、kubectlコマンドやテンプレートエンジンがうまく使えず、思っていた以上に簡単ではなかった。
何か良い方法はないかと探していたところ、ContourのHTTPProxyリソースが使えそうだったので試してみた。

環境

• Ubuntu 19.04
• MicroK8s v1.15.7
• Contour v1.10

インストール

事前準備

MicroK8sのingressアドオンはLoadBalancerの替りとしてNodeの80/443を奪ってしまうので、MicroK8sのアドオンで入っているingressを無効化しておく。

$ sudo microk8s.disable ingress

Contourをインストールする

公式のGetting Startedを頼りにしてインストールを進める。

デフォルトだとtype: LoadBalancerのServiceが必要だが、MicroK8sでのLoadBalancerの配置は難しい上に、1つのワーカノードしかなくLoadBalancer不要なので、MicroK8sのingressアドオンと同様な構成にすることで、解決を図った。

具体的にはデプロイManifestの一部を、type: ClusterIPのServiceにNodeのIPをexternalIPsに付与する形に変更した。

$ wget https://projectcontour.io/quickstart/contour.yaml

$ vi contour.yaml
・・・
apiVersion: v1
kind: Service
metadata:
  name: envoy
  namespace: projectcontour
spec:
  ports:
    - port: 80
      name: http
      protocol: TCP
    - port: 443
      name: https
      protocol: TCP
  selector:
    app: envoy
  type: ClusterIP
  externalIPs:
    - ＜NodeIP＞
・・・

$ kubectl apply -f contour.yaml

使い方

http://my-application.＜ドメイン名＞/ でnginxを公開するサンプルは下記の通り。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application
  namespace: my-namespace
  labels:
    app: my-application
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-application
  template:
    metadata:
      labels:
        app: my-application
    spec:
      containers:
        - name: my-application
          image: nginx

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-application
  name: my-application
  namespace: my-namespace
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: my-application
  type: ClusterIP

---
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: my-application
  namespace: my-namespace
spec:
  virtualhost:
    fqdn: my-application.＜ドメイン名＞
  routes:
    - conditions:
        - prefix: /
      services:
        - name: my-application
          port: 80

複数アプリケーションを同じクラスタにデプロイする際に、アプリケーションごとにHTTPProxyリソースを記載できるので、Ingressリソースのように一つのManifestをこねくり回さなくて良くなり、Manifest管理が楽になった。
また、IngressリソースだとNamespaceを超えたServiceを利用する際はExternalNameを使ったServiceをさらにもう一つ作る必要があった¹が、HTTPProxyはNamespaceを跨いでHTTPProxyを配置できるので、その考慮も不要になった。

まとめ

1. 自前LoadBalancerを用意しなくてもContourのHTTPProxyが利用できた
2. Single Node KubernetesでのHTTPProxyは超便利！！

1. Ingressでクロスネームスペースでのロードバランシング ↩