数多く台頭しているDockerの運用管理に関する製品/サービスの特長、使い方を徹底解説する特集。今回は、Google Cloud Platformで動くKubernetesの管理サービスであるGKEや、グーグル独自のDockerリポジトリであるGoogle Container Registryの概要や主な機能、環境構築方法、使い方について。
数多く台頭しているDockerの運用管理に関する製品/サービスの特長、使い方を徹底解説する本特集「Docker運用管理製品/サービス大全」。今回は、Google Container Engine(GKE)や、グーグル独自のDockerリポジトリであるGoogle Container Registryの概要と使い方を解説します。
内容は、2015年6月の記事執筆時のもので、GKEのバージョン「アルファ」です。なお環境構築手順の紹介で扱うDocker自体のバージョンは1.6を使っています。
GKEは、グーグルが提供するDockerオーケストレーションツールのSaaSです。VMインスタンスでDocker Engineが動作するホストを構築し、ネットワークの負荷分散でロードバランシングを行います。
またGKEは、Kubernetesの管理サービスですので、Kubernetesについて知らない方は前回の「Docker管理ツール、Kubernetes、etcd、flannel、cAdvisorの概要とインストール、基本的な使い方」を参照しておいてください。
なお、Google Container Engineの略称はGCEではなく「GKE」です。Google Compute Engineの略称が「GCE」なので重複を避けたようです。
GKEの紹介の前に、前提知識としてGKEが動くGoogle Cloud Platform(GCP)について解説します。
GCPは、グーグルが利用しているインフラと同一のインフラをユーザー向けに提供しているIaaSです。
GCPはGoogleアカウントで利用可能で、一つのGoogleアカウントについて、GCP上で複数のプロジェクトを作成、管理できます。GCPは、このプロジェクト内でVMインスタンスを作成したり、コンテナークラスターを作成したりすることが可能になります。また、他のユーザーはオーナー/閲覧者などの権限でプロジェクトに参画することが可能になります。
GKEの構成は下記のようになります(参考)。
KubernetesのPodです。単一または複数のコンテナーをまとめて扱うためのものになり、Pod内では同一のIPアドレス/共通のストレージを使えます。
ClusterはMasterとNodeで構成されています。MasterとNodeは同一プライベートネットワーク上に存在します。
KubernetesのMasterの役割を持つVMインスタンスです。下記の機能を持ちます。
KubernetesのReplication Controllerです。多重化されたPodを作成します。仮に多重度が「1」の場合でもReplication Controllerは1つのPodが動くことを保証するので、Pod単体で作成するよりReplication Contorllerを使用した方がいいです。
KubernetesのMinionの役割を持つVMインスタンスです。Dockerコンテナーを実行するCPU/メモリを提供します。Nodeの数はCluster生成時に決定します(最大50個)。
アルファ版のGKEではNodeの数は生成時に設定した数に固定されます。
また、アルファ版ではClusterのNodeを別リージョンに作成できません。ただし、アルファ版の場合はNodeの数がCluster生成時に固定になっているため、次のバージョン以降では作成できるようになる可能性があります。
KubernetesのServiceです。Podの通信のエンドポイントとして動作し、内部的なロードバランサーになります。Podはkube-controll-managerで生成/削除されるため、PodへのアクセスはServiceを介して行います。
GKEではcreateExternalLoadBalancerオプションが使用でき、こちらをtrueにするとネットワーク負荷分散が作成されます。
GKEの機能でServiceにcreateExternalLoadBalancerオプションを付けて作成すると自動的に作成されるネットワーク負荷分散の転送ルールです。転送ルールはCluster配下全てのNodeがターゲットになります。
GKEはKubernetesの機能に加えて、下記の機能を持っています。
GCPのネットワーク負荷分散の機能を使ってServiceへの通信を負荷分散します。
HTTP負荷分散はHTTP/HTTPSプロトコルのみのロードバランサーですが、リージョン間ロードバランシングを行うことができます。このロードバランサーとGKEを連携させることができます(この機能はGKEとGCPの連携機能です)。
kube-apiserver.logにアクセスされたAPIの履歴が残ります。ただし、誰がアクセスしたかの情報は出力されません。
DockerコンテナーのログをFluentd経由で収集し監視のログに表示させます。
これについては、「FluentdによるDockerコンテナーログの監視」で確認しています。
DockerのプライベートリポジトリであるGoogle Container RegistryをGKE内に持っています。
これについては、「Google Container Registryの使用方法」で確認しています。
GKEではコンテナーリソースの監視は行っていないようです。コンテナーリソースを監視する場合は、前回紹介したcAdvisorを使います。cAdvisorの監視範囲はcAdvisorのコンテナーが生成されたホストです。そのため、Master/各Nodeにセットアップする必要があります。
※2015年6月5日の原稿執筆時点ではcAdvisorのコンテナーはデフォルトで作られません。kubeletは以前cAdvisorで取得した情報を使用していたのですが、0.17以降はkubelet自身に情報取得機能が付与されたためです(参考)。
Copyright © ITmedia, Inc. All Rights Reserved.