kustomizeで復数環境のマニフェストファイルを簡単整理

はじめに

前回は、これまで説明したDeploymentやServiceを使って実際にJavaアプリケーションを動作しました。ここでは「kustomize」というツールを利用してマニフェストを統合しました。

今回は、この「kustomize」について少し掘り下げて説明し、実際にkubernetesマニフェストを整理していきます。

kubernetesマニフェストの肥大化

これまで、kubernetes上にアプリケーションを展開するためにマニフェストファイルを書いてきました。アプリケーション1つにマニフェストファイルが1セット、というように対応していれば良いのですが、実際の運用ではそうもいかないことがあります。それこそ前回取り扱ったアプリケーションのように、開発環境と本番環境、あるいはステージング環境で微妙にマニフェストが異なる…ということはよくあります。このときにファイルを用いて差分管理していると、本番環境と開発環境で差分があるのか分からなくなったり、同じdeploymentリソースでステージング環境には変更を入れたものの、開発環境は変更が漏れていた…など、管理が非常に煩雑になります。このときにkustomizeを活用することでマニフェストの共通部分を1ファイルで共有し、差分のみを環境ごとに記述するといったことができるようになります。

kustomizeとは

kustomizeはkubernetesのマニフェストを管理するためのツールで、kubernetesコミュニティの公式ツールとして開発・管理されています。DeploymentやServiceなど、実際にkubernetesにデプロイされるマニフェストファイルとは別に、kustomization.yamlという差分を管理し、マニフェストを統合するためのファイルを記述することでマニフェストを整理できます。kubectlコマンドのサブコマンドやオプションとして実装されていますが、単体のバイナリとして利用することも可能です。以前はkubectlのサブコマンドとして利用できるもののバージョンが古かったのですが、kubectl v1.21でkustomizeがv2.0.3からv4.0.5へと大幅にバージョンアップされ、今後も継続的に最新化されていくとアナウンスされているので、サブコマンドで運用して差し支えなさそうです。

環境差分の吸収

さて、前回取り扱ったアプリケーションでは、kustomizeを利用してイメージと設定値であるconfigmap、secretをkustomization.yamlファイルに分離しているものの、deploymentやservice等のyamlファイルが2つのディレクトリで2重に管理されています。今回は、このkustomizeを利用して、下図のようにディレクトリ構成を変更します。

まず、developとproductionの2つの環境のマニフェストの差分を確認します。大きな違いは、次の3点です。

• イメージのタグがそれぞれdev、prodと異なる
• dev環境ではdebug用の環境変数が設定されている、かつdebugger用のportが指定されている
• dev環境ではDB用のマニフェストが存在する

これらの3点を除けば、ほぼ同一のマニフェストです。これだけのために、ファイルを2重管理したくはないですよね。そこで、この2つのマニフェストをまとめていきます。今回で構成するマニフェストファイル群は、こちらのリポジトリに格納しています。

共通のマニフェストを
baseディレクトリに配置する

それでは、共通で利用されるマニフェストファイルをbaseディレクトリに移動します。結果、baseディレクトリは下記のような構成になりました。

base/
├── deployment-accesscount.yaml
├── deployment-article.yaml
├── deployment-rank.yaml
├── deployment-website.yaml
├── ingress-accesscount.yaml
├── ingress-article.yaml
├── ingress-rank.yaml
├── ingress-website.yaml
├── kustomization.yaml
├── service-accesscount.yaml
├── service-article.yaml
├── service-rank.yaml
└── service-website.yaml

kustomization.yamlの内容は下記のとおりです。もともと存在したConfigmapGeneretorやimagesは環境ごとのyamlファイルで指定するので、ここにはresourcesしか記述していません。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deployment-article.yaml
- service-article.yaml
- ingress-article.yaml
- deployment-accesscount.yaml
- service-accesscount.yaml
- ingress-accesscount.yaml
- deployment-rank.yaml
- service-rank.yaml
- ingress-rank.yaml
- deployment-website.yaml
- service-website.yaml
- ingress-website.yaml

resourcesフィールドについては前回で解説しました。kustomizeでは、このresourcesで指定したマニフェストを読み込んでから、以降のフィールド(transformer)の設定で変更を加え、最終的にマニフェストを出力します。このbaseディレクトリでは共通部のみを表現しているので、transformerはありません。

個別のファイルについても、少し見ておきましょう。deployment-article.yamlの内容はdebuggerの設定がない、prd環境のものと同じですね。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: article
  name: article
spec:
  replicas: 1
  selector:
    matchLabels:
      app: article
  template:
    metadata:
      labels:
        app: article
    spec:
      containers:
      - name: article
        image: article
        envFrom:
        - secretRef:
            name: article-config
        resources:
          requests:
            cpu: 200m
            memory: 512Mi
          limits:
            cpu: '1'
            memory: 2Gi
        ports:
        - name: web
          containerPort: 8080
          protocol: TCP

production用の環境設定

続いて、productionで利用するoverlays/productionを見ていきます。ディレクトリ構成は、次のようになります。

overlays/production/
├── config
│   ├── accesscount
│   │   └── config.env
│   ├── article
│   │   └── config.env
│   ├── rank
│   │   └── config.env
│   └── website
│       └── config.env
└── kustomization.yaml

production用のkustomization.yamlとconfigが含まれています。再度、kustomization.yamlの内容を見てみましょう。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../../base

secretGenerator:
- name: article-config
  envs:
  - config/article/config.env
- name: accesscount-config
  envs:
  - config/accesscount/config.env
- name: rank-config
  envs:
  - config/rank/config.env

configMapGenerator:
- name: website-config
  envs:
  - config/website/config.env

images:
- name: article
  newName: registry.gitlab.com/creationline/thinkit-kubernetes-sample1/article
  newTag: prod
- name: accesscount
  newName: registry.gitlab.com/creationline/thinkit-kubernetes-sample1/accesscount
  newTag: prod
- name: rank
  newName: registry.gitlab.com/creationline/thinkit-kubernetes-sample1/rank
  newTag: prod
- name: website
  newName: registry.gitlab.com/creationline/thinkit-kubernetes-sample1/website
  newTag: prod

上から見ていきます。今まで読み込むyamlファイルを個別に指定していたresourcesを、baseディレクトリを指定するように書き換えています。これでbaseディレクトリのkustomization.yamlの記述を取り込むことができます。

secretGenerator、configMapGeneratorについても前回で解説しました。それぞれ読み込むconfigファイルが異なるため、環境ごとのkustomization.yamlで指定するようにしています。

最後はimagesです。もともとイメージ名をレジストリからのフルパスで置換するように指定していましたが、新たにnewTagフィールドを追加しました。ここでイメージのタグも書き換えています。

それでは、実際にkustomizeで出力されるyamlの内容を見てみましょう。

$ kubectl kustomize overlays/production/

全てのマニフェストが出力されますが、ここではdeployment-articleを抜粋して記載します。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: article
  name: article
spec:
  replicas: 1
  selector:
    matchLabels:
      app: article
  template:
    metadata:
      labels:
        app: article
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: article-config-994cb4cf7h
        image: registry.gitlab.com/creationline/thinkit-kubernetes-sample1/article:prod
        name: article
        ports:
        - containerPort: 8080
          name: web
          protocol: TCP
        resources:
          limits:
            cpu: "1"
            memory: 2Gi
          requests:
            cpu: 200m
            memory: 512Mi

imageのtagが書き換わっていることが確認できました。これで、production環境の構成は完了です。