当記事はみずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画で執筆されたものです。

GKE は Google Cloud の強みとして紹介されることの多いサービスです。
Kubenetes のマネージドサービスである GKE を理解するには、先ずは Kubenetes の理解が必要です。
GKE の優れた点を理解するための調査の一環として Kubenetes について調査することにしました。

G-gen の佐々木です。当記事では、オープンソースのコンテナオーケストレーションツールである Kubernetes の基本を解説します。
Google Cloud における代表的なプロダクトの 1 つである Google Kubernetes Engine ( GKE ) は Kubernetes のフルマネージドサービスであり、それを適切に利用していくためには、基盤となる Kubernetes についてある程度の知識が必要となります。

Kubernetes とは
なぜ Kubernetes が必要なのか
Kubernetes の詳細
Kubernetes の利用方法

Kubernetes とは

Kubernetes (読み：クバネティス / クバネテス / クーベネティスなど) は、コンテナ化されたアプリケーションのデプロイ、スケーリングなどの管理を自動化するための オープンソース の コンテナオーケストレーションツール です。
Google 内部で利用されているクラスタマネージャの Borg を元に 2014 年に開発され、現在は Cloud Native Computing Foundation (CNCF) によって管理されています。

「 Kubernetes 」という語はギリシャ語で「操舵手」を意味し、最初の文字「 K 」と最後の文字「 s 」の間の 8 文字を省略して、K8s と呼ばれることもあります。

なぜ Kubernetes が必要なのか

コンテナ運用の課題

近年、アプリケーション開発の効率化、およびコンピュートリソース利用の効率化の観点から Docker を始めとするコンテナ仮想化技術が注目され、機能単位でアプリケーションを組み合わせてシステムを構成するマイクロサービスアーキテクチャとの相性が良いことから、モダンアプリケーション開発においてコンテナの採用が増えています。

しかし、機能単位でコンテナを実行することでコンテナの数が増えてくると、その運用管理が煩雑になってしまうという課題が出てきます。

コンテナオーケストレーション

コンテナオーケストレーションとは、コンテナ化されたアプリケーションを効率良く開発・運用する技術 のことで、Kubernetes のようなコンテナオーケストレーションツールを利用することで、コンテナの運用管理にまつわる以下のようなタスクを自動化することが可能です。

■コンテナオーケストレーションツールで自動化できることの一例

スケジューリング
ローリングアップデート
スケーリング
死活監視
障害発生時のセルフヒーリング
宣言的なコードによるインフラ管理 ( Infrastructure as Code )

このような利点により、コンテナを用いた一定規模以上のシステム構築では、コンテナオーケストレーションツールの導入が一般的になっています。

デファクトスタンダード

コンテナオーケストレーショツールとしては、Kubernetes の他に Docker Swarm Mode や Apache Mesos などがあります。

しかし、Google だけではなく AWS、Microsoft、Oracle といった企業が Kubernetes を管理している CNCF に参加していることや、AWS や Azure がコンテナオーケストレーションのマネージドサービスとして Kubernetes を採用したことにより、現在では コンテナオーケストレーションツールのデファクトスタンダード としての地位を固めています。

Docker との関係

コンテナ仮想化技術のデファクトスタンダードである Docker とコンテナオーケストレーションツールである Kubernetes は競合するテクノロジーではなく、むしろ連携、補完し合う関係にあると言えます。

Kubernetes は、Docker を用いてコンテナ化されたアプリケーションの運用管理を自動化することで、アプリケーションの開発速度を向上し、大規模な展開を効率よく行うことができます。

Kubernetes の詳細

アーキテクチャ

Kubernetes は、実際にコンテナが実行される 1 つ以上の ノード と、それを管理する コントロールプレーン の 2 種類のコンポーネントからなる Kubernetes クラスタ を構成します。

各コンポーネント内ではコンテナの実行、管理に必要な複数のプロセスが稼働しています。

コントロールプレーンの主なプロセス

プロセス	主な役割
kube-apiserver	Kubernetes API のエンドポイントを提供する。 Kubernetes クラスタを管理するためのリクエストを受信し、Kubernetes の各種リソースの操作（作成、削除など）を自動で行う。
kube-scheduler	新しく作成された Pod を適切なノードに割り当てる。
kube-controller-manager	Kubernetes クラスタを、期待される状態と一致するように管理する。
etcd	Kubernetes クラスタの構成情報の保存先となる。
kube-dns	Kubernetes クラスタ内部の名前解決を可能にする DNS サービスを提供する。

ノードの主なプロセス

プロセス	主な役割
kubelet	Pod 内のコンテナの実行状態を管理し、障害状態にあるコンテナを置き換えたり、コントロールプレーンからの指示を受けてコンテナを起動、停止したりする。
kube-proxy	クラスタ内部または外部のネットワークからの通信を Pod に転送する。

宣言型 API によるリソースの登録

コントロールプレーンの kube-controller-manager には、 Kubernetes クラスタの「実際の状態 (Actual State) 」と「理想の状態 ( Desired State ) 」を常に比較し、両者に差異が生じたときに理想の状態を維持する 仕組みがループ処理として実装されています ( Reconciliation Loop )。

Kubernetes では、管理対象となる リソース を、設定ファイルである マニフェスト として記述します。
マニフェストに対して、システムの「理想の状態」を YAML 形式 で記述し、Kubernetes に登録することで、kube-controller-manager は記述通りの状態にシステムを構成、維持します。

設定ファイルに対して、システムを構成するために実行する処理 ( How ) を記述するような方式である 手続き型 API に対して、Kubernetes のマニフェストのように、どのようなシステムを構成するか ( What ) を記述する方式を 宣言型 API といいます。

Kubernetes リソース

Kubernetes に登録することのできるリソースは、大きく分けて以下の 5 つのカテゴリがあります。

カテゴリ	概要
Workloads API	コンテナの実行に関するリソース
Service API	コンテナを公開するためのエンドポイントを提供するリソース
Config API	設定 / 機密情報 / 永続化ボリュームなどに関するリソース
Cluster API	セキュリティやクォータなどに関するリソース
Metadata API	クラスタ内の他のリソースを操作するためのリソース

ここでは、代表的なリソースの一部を記載します（リソース一覧）。

リソース名	カテゴリ	説明
Pod	Workloads API	Workloads API リソースの最小単位。1 つ以上のコンテナから構成され、同じ Pod 内のコンテナは IP アドレスを共有する。多くの場合 Pod 1 つにつき 1 つのコンテナで構成するが、プロキシやローカルキャッシュ用のサブコンテナを含める場合もある。
ReplicaSet	Workloads API	Pod のレプリカを作成し、指定した数の Pod を維持するように動作するリソース。ノードや Pod に障害が発生すると、指定された数だけ正常な Pod が稼働するように別の Pod を起動する。
Deployment	Workloads API	複数の ReplicaSet を管理するリソースで、ローリングアップデートやロールバックを実現する。 ReplicaSet が Pod を管理するため、3 層の構造を持つことになる。 Deployment 内の ReplicaSet を変更すると、新しい ReplicaSet が作成され、指定された Pod 数を維持しつつ新旧 Pod の入れ替えを行うことができる。
Service	Service API	■ClusterIP Kubernetes クラスタ内で Pod 間通信を行うための内部 IP アドレスを払い出す。クラスタ内の各 Pod にトラフィックを転送する内部ロードバランサとして機能する。 ■NodePort Kubernetes クラスタ内の各ノードに外部 IP アドレスを払い出し、払い出した IP アドレスとポートの組み合わせにより、クラスタ外からのトラフィックを特定の ClusterIP に転送する。クラスタ外から Pod に接続する必要がある場合に使用する。 ■LoadBalancer Kubernetes クラスタ外部にロードバランサを配置し、外部 IP アドレスを払い出すことで、クラスタ内への接続を可能にする。ロードバランサの仕様は Kubernetes クラスタを構築している環境に依存し、Google Cloud の場合は Cloud Load Balancing の L4 ( TCP / UDP ) ロードバランサが自動的に使用される。パスベースのルーティングや SSL ターミネーションなどをサポートする L7 ( HTTP / HTTPS ) ロードバランサを使用したい場合は Ingress リソースを使用する。
Secret	Config API	データベース接続情報や TLS 証明書などの機密情報を Key-Value で保存するために使用する。
ConfigMap	Config API	各種設定情報などを Key-Value で保存するために使用する。 nginx.conf や httpd.conf のような設定ファイルを保存することも可能。
PersistentVolume	Cluster API	Pod とは別のリソースとしてボリュームを作成し、Pod からマウントする形で永続化領域として使用できる。ノードのファイルシステムを使用する hostPath のほか、プラグインを使用することで Amazon EBS や GCE 永続ディスクなど、外部にあるボリュームをアタッチすることもできる。
Node	Cluster API	Kubernetes のコンポーネントの 1 つであるノードも Kubernetes 上のリソースとして登録されている。基本的に作成や削除をするリソースではないが、IP アドレスの情報や、 CPU、メモリなどのリソースの情報を取得する際に、ノードに関する情報を返すように Kubernetes にリクエストすることがある。
Namespace	Cluster API	Kubernetes クラスタ内のリソースをグループ化し、仮想的に分離するために使用する。 Namespace 単位で CPU やメモリのクォータを設定したり、ロールベースのアクセス制御を設定したりすることができる。

Kubenetes の操作 ( kubectl )

Kubernetes では、CLI ツールである Kubectl を使ってコントロールプレーンに対して API リクエストを送信することで、Kubernetes クラスターを操作します。

各種リソースの作成は kubectl create コマンドで行うことができますが、マニフェストファイルで指定したリソースが存在しないときは新規に作成、存在するときは差分を自動で反映してくれる kubectl apply コマンドを使用するのが一般的です。

マニフェストファイルによるリソース定義の例

基本的な記述例

以下の YAML 形式の記述は、nginx コンテナを内包する Pod を 3 台起動し、その状態を維持する ReplicaSet を含めた Deployment リソースを作成するマニフェストです。

リソースの種類は kind で指定し、それに対応する apiVersion を記述する必要があります。
kind と apiVersion の対応は kubectl api-resources コマンドで出力することができます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  template: 
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.23

このマニフェストファイルを用いて kubectl apply コマンドを実行すると、Kubernetes クラスタ内にリソースが作成されます。
リソースを更新する場合、マニフェストファイルを修正し、再度 kubectl apply を実行して修正内容を適用します。

たとえば、実行する Pod の数を 5 に増やしたい場合、replicas の値を 5 に変更して適用します。
そうすると、Kubernetes がマニフェストファイルの差分を検出し、Pod を 2 つ新規作成してノードに割り当てます。

複数のリソースを同時に作成する例

1 つのマニフェストに複数のリソースを記載することもできます。

以下に記述したマニフェストでは、先程と同様の Pod を 3 台起動する Deployment リソースと、Pod を外部公開するための LoadBalancer リソースを 記述されている順番に 作成します。
そして、Key-Value で記述される label と selector の情報を使用して、ロードバランサから特定の Pod 対してトラフィックをルーティングするように設定します。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchlabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.23
---
apiVersion: v1
kind: Service
metadata:
  name: sample-service
spec:
  type: LoadBalancer
  ports:
  - name: "http-port"
    protocol: "TCP"
    port: 8080
    targetPort: 80
  selector:
    app: sample-app