Docker Quickstartを超意訳する Part 3

Kubernetesでのデプロイ

Part 2ではアプリのコンテナ化を行った.
Part 3ではKubernetesにアプリをデプロイしてみる.

Get Started, Part 3: Deploying to Kubernetes

https://docs.docker.com/get-started/part3/

Prerequisites

https://docs.docker.com/get-started/part3/#prerequisites

Part 2でのアプリのコンテナ化ができていること.
Docker Desktop上でKubernetesが動作していること
- 動作していない場合はPart 1の手順に従う.

Introduction

https://docs.docker.com/get-started/part3/#introduction
前のパートではアプリのコンポーネントを単独のコンテナとして動作させていたが, ここからはそれらをコンテナオーケストレーター(Kubernetes)で管理する.
Kubernetesはコンテナアプリのスケーリング, ネットワーク, セキュリティ, メンテナンスのための, コンテナ自体に最初から入っている機能よりも強力な様々なツールを提供する.

前のパートで作成したコンテナアプリがKubernetes上で動作することを検証するために, 今回は本番環境のKubernetesクラスタではなくDocker Desktopでセットアップした開発マシンのKubernetesを使用する.
Docker Desktopで構築したKubernetes環境は本番環境のクラスタで動作するものと同じ機能を持ち, 開発マシンから容易にアクセスできるという利点がある.

Describing Apps Using Kubernetes YAML

https://docs.docker.com/get-started/part3/#describing-apps-using-kubernetes-yaml
Kubernetesでは全てのコンテナはリソースを共有する複数のコンテナによって構成されるPodという単位で運用される.
また, 実際のアプリで開発者がPodを1つずつ運用することは稀で, Kubernetesが自動でスケーリングなどの管理を行う複数のPodで構成されるDeploymentという単位で運用されることが多い.
全てのKubernetesオブジェクトはKubernetesYAMLファイルと呼ばれるマニフェストファイルで定義される.
このファイルにはKubernetesアプリを構成するコンポーネントと設定の情報が記述されていて, Kubernetes環境でのアプリの作成/削除に使用される.

1: Part 1では簡単な内容のKubernetesYAMLファイルを作成したが, 今回は掲示板アプリを動かすためにもう少し詳細なものをつくってみる.
任意の場所にbb.yamlというファイルを以下の内容で作成する.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bb-demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      bb: web
  template:
    metadata:
      labels:
        bb: web
    spec:
      containers:
      - name: bb-site
        image: bulletinboard:1.0
---
apiVersion: v1
kind: Service
metadata:
  name: bb-entrypoint
  namespace: default
spec:
  type: NodePort
  selector:
    bb: web
  ports:
  - port: 8080
    targetPort: 8080
    nodePort: 30001

このKuberetesYAMLファイルには---で区切られた2つのオブジェクトが記述されている:

Deploymentは中身が同じでスケーリングが可能な複数のPodを定義する.
このファイルではreplica(同じPodの数)が1つであり,
そのPodがPart 2で作成したimage(bulletinboard:1.0)から起動するコンテナを1つ持つことが定義されている.
ServiceはPodに関する通信設定を定義する.
このファイルではホスト(ここでは開発マシン)の30001番ポートをPodの8080番ポートと通信させるNodePort Serviceを定義し, 掲示板アプリに接続できるようにしている.

はじめはこのKubernetesYAMLファイルが長く, 複雑なものに見えるかもしれないが, 実際はどれも同じパターンで記述されている:

apiVersionでこのオブジェクトをパースするKubernetesAPIのバージョンを指定
kindでこのオブジェクトの種類を定義
metadataでオブジェクトの名前などの情報(メタデータ)を定義
specでオブジェクトのパラメータと設定を記述

Deploying and Checking Your Application

https://docs.docker.com/get-started/part3/#deploying-and-checking-your-application
1: bb.yamlがあるディレクトリに移動して, Kubernetesにアプリをデプロイする.

# bb.yamlがあることを確認
$ ls
bb.yaml
# bb.yamlに記述された内容のリソースを作成
$ kubectl apply -f bb.yaml
deployment.apps/bb-demo created
service/bb-entrypoint created

2: 起動しているDeploymentの一覧を表示して動作を確認する.

# Deploymentsの一覧を表示
$ kubectl get deployments
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
bb-demo   1/1     1            1           93s

bb.yamlで定義したDeployment(bb-demo)で1つのPodが正常に動作していることがわかる.

同様にServiceについても動作確認を行う.

# Serviceの一覧を表示
$ kubectl get services
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
bb-entrypoint   NodePort    10.102.111.61   <none>        8080:30001/TCP   6m11s
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP          34d

Kubernetesのデフォルトで使用されるServiceの他に, bb.yamlで定義したService(bb-entrypoint)が動作し, 30001/TCPへのリクエストを受ける設定になっていることがわかる.

3: 開発マシンのブラウザで http://localhost:30001/ を開く.
掲示板アプリの画面
Part 2でコンテナを単体で実行したときと同じ画面が確認できる.

4: 動作確認が完了したら, アプリを削除する.

# bb.yamlに記述された内容のリソースを削除
$ kubectl delete -f bb.yaml
deployment.apps "bb-demo" deleted
service "bb-entrypoint" deleted

Conclusion

https://docs.docker.com/get-started/part3/#conclusion
このパートでは, Docker Desktopを用いて開発マシン上のKubernetesに掲示板アプリをデプロイした.
この程度ではまだKubernetesを使いこなしているとは言えないが, 最初のステップは既にクリアしている.
環境はすでに開発マシンに構築できているので, 同じ手順でKubernetesの機能をさらに活用すればアプリに他のコンポーネントを追加することもできる.

また, このパートではアプリのデプロイに加えてKubernetesYAMLファイルでのアプリ定義も行った.
アプリを動作させるために必要なすべての情報がシンプルなファイルに記述されているため, バージョンコントロール(Gitなど)で管理したり, 他の開発者と簡単に共有することができる.
また, KubernetesYAMLファイルがあればアプリを異なるクラスタに配置することも簡単に行うことができる(例: テスト環境と本番環境を分ける場合など).
[追加]俗に言うInfrastructure as Codeというもの. Kubernetesではアプリの実行に必要なインフラをコードとして管理することで動作環境への依存をなくしている.