Kubernetesを選んだ技術的理由とコンテナをプロジェクトで活用する上でのポイント：先行事例に学ぶKubernetes企業活用の現実（終）（1/2 ページ）

本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。今回は、Kubernetesを活用することを決めた理由について「技術」面から解説するとともに、「システムの開発やテスト、デプロイの効率を向上させるために、どのような点に配慮すべきか」について説明する。

[藤原涼馬，リクルートテクノロジーズ]

　本連載「先行事例に学ぶKubernetes企業活用の現実」も第3回になり、今回が最後です。あらためて前回までの2回分の連載内容を振り返ってみましょう。初回はDockerについての復習と、Kubernetesが昨今注目される理由を解説しました。第2回では、リクルートテクノロジーズがコンテナ仮想化の本番活用に向けて取り組んだことについて説明しつつ、最終的にKubernetes利用を決断した理由を「周辺環境」の観点から説明しました。

　今回は、Kubernetesを活用することを決めた理由について「技術」面から解説するとともに、「システムの開発やテスト、デプロイの効率を向上させるために、どのような点に配慮すべきか」について説明します。

　Kubernetesの基本的な概念、概要については、「Docker管理ツール、Kubernetes、etcd、flannel、cAdvisorの概要とインストール、基本的な使い方 - ＠IT」「Concepts | Kubernetes」などを参照してください。

Kubernetesの選定理由（技術編）

　Kubernetesの選定理由として最初に挙がるのが、「基本的にシステムで要求される機能・非機能要件を充足するための機能が豊富」な点です。特に重要なのが、下記3点です。

1. 処理形態に合わせたコントローラー種別
2. 環境別の設定・機密情報の管理
3. 冗長性の確保

　以降、この3点について解説します。

【1】処理形態に合わせたコントローラー種別

　「Pod」（コンテナの集合）をどう配置、実行するかを、処理の種類に合わせて「コントローラー」を選択して記述します。主なものとしては以下のようなコントローラーが存在します。

表1コントローラーの種類と内容

コントローラーの種類	内容
ReplicaSet（or Deployments）	特定のPodをレプリケーションして複数のWorkerノードに配置
DaemonSet	全てのノードに1つずつPodが立ち上がるように設定
Job,CronJob	Podが立ち上がって処理を行った後停止する（CronJobは特定の処理を定期的に繰り返す）

　例えば、一般的なWebアプリを動かすのであれば、「ReplicaSet」が適切です。負荷に合わせてスケールさせることができます（Podごとのリソースの下限や上限も指定できるので、指定しておくとより良いでしょう）。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
  labels:
    app: sample
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample
  template:
    metadata:
      labels: 
        app: sample
    spec:
      containers:
      - name: sample-nginx
        image: nginx:latest

ReplicaSetの記述例

　「DaemonSet」は、「Fluentd」「logstash」などを活用したログ集約の仕組みや各種監視用のエージェントの導入など、「全てのホストに一律に導入するもの」に対して活用します。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx
  labels:
    app: sample
spec:
  selector:
    matchLabels:
      app: sample
  template:
    metadata:
      labels: 
        app: sample
    spec:
      containers:
      - name: sample-nginx
        image: nginx:latest

DaemonSetの記述例

　最後の「Job,CronJob」はKubernetesのクラスタ上で単発の、または定期繰り返しのバッチ処理を実施したい場合に適しています。

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: mailcheck-batch
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
          spec:
            containers:
            - name: batch
              image: sample/batch:latest
            restartPolicy: Never

CronJobの記述例（5分おきに実行）

　実際にReplicaSetなどで外部からのアクセスを受け付けられるようにするには、[

Service」「Ingress」の記述が必要になりますが、ここでは割愛します。

【2】環境別の設定・機密情報の管理

　コンテナを使う使わないに関係なく、そもそも「開発」「本番」などの環境における設定の差異は可能な限り埋めるようにさまざまな施策を講じるものと思います。しかし、それでも埋められない環境の差異が残った場合もKubernetesを用いてカバーすることが可能です。

　環境差異を埋めるのが「ConfigMap」「Secrets」です。

　ConfigMapでは、環境ごとの設定ファイルや環境変数をKubernetesのクラスタ内部で管理することで環境別の設定管理を容易にします。

　Secretsも、ConfigMapと同じく、環境変数や設定ファイルの形で環境別の設定を管理できます。SecretsはKubernetesのクライアント（kubectl）から確認した場合でもbase64を用いて難読化されているため、環境固有の機密情報（DBのパスワードなど）を格納する際に利用しましょう。

【3】冗長性の確保

　Kubernetesでは、Masterノードを3台以上用意することでクラスタの冗長性を高めることが可能です。3台であれば1台までのMasterノードの停止、5台であれば2台までのMasterノードの停止に耐えることが可能です。よって奇数台のMasterノードと任意台数のWorkerノードを準備するようにしましょう。

　MasterノードをHA化する方法についてはKubernetesの公式ドキュメントや各デプロイツールにある記載の通りに実施するといいでしょう。

yamlによる宣言的なデプロイ設定

　ここまで見て分かる通り、Kubernetesの設定には、複数のyamlファイルが出てきました。そこには処理内容は書かれておらず、最終的にどうあるべきかということが宣言的に記述されています。前回の記事でも説明した通り、このように宣言的に記述することで、ある程度システム全体の規模が大きくなっても全体像を把握しつつ設定を記述することが可能になります。

　Kubernetesでは、kubectl（Kubernetesのクライアントコマンド）を用いてyamlファイルを適用することで、自動的に「yamlファイルに記述された状態」になるようにKubernetsクラスタが動作します。

　ここまでで、Kubernetesがさまざまなシステムを動作させる上で機能面、非機能面それぞれで必要とされそうな事柄をカバーしていることが確認できました。以降では、「Kubernetesをより良く活用する上で、どのような環境が必要か」を整理します。