はじめに
こんにちは、BTM の藤野です。
業務で Docker 等のコンテナ技術に触れることはありましたが、Kubernetes は使ったことがありませんでした。
この度業務で少しだけ Kubernetes について調査する機会があったので、自身の理解整理も兼ねて概要をまとめておきたいと思います。
Kubernetes とは？
Kubernetes は複数のノード（マシン）上にコンテナ化されたアプリケーションを自動でデプロイ、スケーリング、管理するためのオープンソースシステムです。
数千、数万のコンテナを管理することも可能で、複雑なシステムの運用を効率的に支援してくれます。
数個程度のコンテナであれば手動でも管理は可能ですが、マイクロサービスアーキテクチャのようにアプリケーションが多数のサービスに分割され、管理対象のコンテナが数千、数万といった膨大な数になってくると手動で管理するのは現実的ではありません。
Kubernetes は、これらの課題を解決するために設計されており、システムの「あるべき状態」をマニフェストファイルに記述することで、多数のコンテナの監視や自動修復、コンテナ間の連携、無停止でのデプロイ、オートスケーリングなど、運用を支援してくれる機能を多数備えています。
Kubernetes が提供している基本的な機能
Kubernetes が提供している基本的な機能としては以下のようなものがあります。
自己修復
Kubernetes は、定義された「あるべき状態」を維持するために、コンテナや、各種コンポーネントの障害に対して、マニフェストファイルに記述された「あるべき状態」に自己修復する機能を提供しています。
例えば、Pod と呼ばれる Kubernetes オブジェクトがマニフェストファイルの規定数を下回ってしまった場合に、それを検知して規定の数まで自動で Pod を起動することが可能です。
サービスの検出とロードバランシング
Kubernetes 内外からのリクエストを、対象となるコンテナ群に接続し、リクエストを自動的に適切なコンテナに流す負荷分散を行うことが可能です。
例えば、自己修復機能によりコンテナが再作成されて IP アドレスが変更になった場合でも、Kubernetes はその変更を自動で検知し、リクエストを新しいコンテナへ振り分けてくれるため、リクエストの送信元は IP アドレスの変更を意識することなく運用を継続できます。
ストレージ
コンテナで使用するデータの永続化や、コンテナ間でのデータの共有が可能です。
例えば、コンテナ内のファイルシステムは一時的で、コンテナが削除されるとデータも消えてしまいます。また、複数のコンテナで同じデータを共有することも、通常の方法では困難です。
Kubernetes はこれらの問題を解決するため、コンテナから独立した永続可能なストレージに、コンテナから接続する機能があります。これにより、コンテナが再作成された場合でもデータは残り、複数のコンテナで同じストレージを共有することも可能になります。
自動化されたロールアウトとロールバック
アプリケーションのロールアウト（デプロイ）や、問題が発生した際の以前の状態へのロールバックをコマンド一つで自動的に実行することが可能です。
例えば、新しいバージョンのアプリケーションをデプロイする際、一度に全コンテナを新バージョンにするのではなく、指定数のコンテナを徐々に新バージョンに入れ替えていくローリングアップデートを特別な実装なしでコマンド 1 つで実現できます。
また、その際に問題が発生した場合も旧バージョンへのロールバックをコマンド 1 つで実現可能です。
自動ビンパッキング
Kubernetes には、リソース全体を効率的に利用するため、コンテナを各ノードへ最適に配置する自動ビンパッキング機能があります。
例えば、 Pod がデプロイされる際、コンテナの要求リソースや各ノードの空きリソースを基にしてどのノードにデプロイするかを自動で選定、配置します。
また、どのノードを優先的に使うかといった配置ルール指定も可能で、要求スペックが高い Pod がある場合に、その Pod は必ず高スペックなノードに配置させるといった柔軟な制御も可能です。
機密情報と構成管理
機密情報、一般的な設定情報を、保持管理しアプリケーションからの安全なアクセスを実現する機能があります。
例えば、DB 接続パスワードや API キー等は機密情報として安全な場所に管理し、本番／開発モードなど動作モードの切り替えや接続先などの一般的な情報は構成情報として別途管理します。
これらの情報は Kubernetes によって管理され、コンテナ起動時に環境変数として渡されたり、設定ファイルとしてコンテナ内に配置することで安全に利用できます。
Kubernetes の基本的な構成要素
クラスター
Kubernetes はコントロールプレーン（マスターノード）とワーカーノードという 2 つの主要コンポーネントで構成され、これらを合わせてクラスターと呼びます。
コントロールプレーン（マスターノード）
クラスター全体を管理・制御する司令塔の役割を持つノードで、主に以下のようなコンポーネントで構成されています。
kube-apiserver
コントロールプレーンの中心的なコンポーネントで以下の機能を持ちます。
- Kubernetes 内部コンポーネントやユーザー、外部のツール等が Kubernetes を操作するための Kubernetes API と呼ばれるインターフェースを外部に提供する
- クラスターのリソース（後述する Pod、Service、Deployment 等）の作成、更新、削除、取得はこれを介して行われ、これによりリソースのスケーリングやクラスター全体の状態取得、修復等を実現する
etcd
etcd は Kubernetes クラスターの全データを保存している高可用性をもつキーバリューストアです。
etcd にはマニフェストファイルで定義された「あるべき状態」や、現在のクラスターの状態など全ての情報が保存されています。
etcd のデータをバックアップしておくと万が一クラスター全体で障害が発生した場合も保存していたバックアップからシステムを復元することで障害を回復することも可能です。
kube-scheduler
kube-scheduler は新しく作成された Pod をどのワーカーノードで実行するかを決定する役割を持っています。
kube-scheduler は Pod やコンテナが必要とするリソース要求や、最適な負荷分散等を考慮して適切なワーカーノードを決定します。
kube-controller-manager
kube-controller-manager はクラスターのリソース状態を監視し、「あるべき状態」を維持するための様々なコントローラーを内包しています。
内包している各コントローラーはそれぞれ特定のリソースに対する監視と調整を行う役割を持ち、kube-controller-manager は各コントローラーを統合して実行します。
たとえば、Node Controller はノードの状態を監視し、ノードの応答がなくなった場合は異常を検知したとマークすることで、他のコントローラーがそのノード上の Pod を別の正常なノードで作成するといった自己修復のきっかけを作ったりします。
ワーカーノード
実際にアプリケーションコンテナが動作するノード（マシン）で、コントロールプレーンから指示を受けて動作します。
ワーカーノードは主に以下のコンポーネントで構成されています。
kubelet
ワーカーノード上に必ず一つ存在する最も重要なコンポーネントです。
コントロールプレーンの kube-apiserver から指示を受け Pod の作成、削除、監視を行い、定期的にノードやノード上で稼働する Pod の状態を監視しコントロールプレーンに連携します。
kube-proxy
クラスター内のネットワーク通信を管理し、Pod 間の通信や外部から Pod へのアクセスを可能にします。
コンテナランタイム
kubelet からの指示を受けて、コンテナ（Docker 等）を実行・管理するためのソフトウェアで、
コンテナの起動や停止、リソース（CPU 、メモリ、ストレージ）管理、コンテナイメージ管理、コンテナ同士のネットワーク管理、コンテナのログ管理等を行います。
Kubernetes オブジェクト
Kubernetes では、コンテナや関連リソース（ネットワーク、ストレージ）を「オブジェクト」として定義、管理します。
Kubernetes オブジェクトの情報は YAML 形式のマニフェストファイルに「あるべき状態」として記述され、 この「あるべき状態」に環境を合わせるのが Kubernetes の基本動作といえます。
基本的な Kubernetes オブジェクトには以下のようなものがあります。
Pod
Kubernetes における最小実行単位であり、コンテナを 1 つ以上含み、Pod 内のコンテナは IP アドレスやストレージ等のリソースを共有します。
Pod 自体は 1 台のノードでのみ稼働します。複数のノードにまたがる冗長化は、下記の ReplicaSet 等を用いて Pod を複製配置することで実現します。
ReplicaSet
指定した数の Pod のレプリカが常に稼働している状態を維持するためのオブジェクトです。
現在では下記の Deployment が内部的に呼び出し管理することがほとんどで、直接 ReplicaSet を作成することは稀です。
Deployment
アプリケーションのデプロイを管理する最もよく利用されるオブジェクトで、指定されたコンテナイメージ、コンテナスペック、レプリカ数（Pod の数）等から Pod を作成したり、サービスアップデート時のローリングアップデートや、問題発生時のロールバックといったデプロイを実行可能です。
Service
同じ構成の Pod を配下に束ねて、安定した Pod へのネットワークアクセスを提供します。
Pod が自己修復等により IP アドレスが変わった場合でもアクセスを可能にし、リクエストを配下の Pod に自動的に振り分けます。
ConfigMap
本番／開発モードなど動作モードの切り替えや接続先などの一般的な情報をコンテナから分離して管理するためのオブジェクトで、環境変数や設定ファイルとして Pod に渡すことが可能です。
Secret
DB 接続パスワードや API キー等の機密情報をコンテナから分離して管理するためのオブジェクトで、ロールベースアクセス制御機能や etcd での暗号化機能を組み合わせてデータを安全に保持できます。
ConfigMap と同様に環境変数や設定ファイルとして Pod に渡すことが可能です。
Job
常時稼働する必要のないバッチ処理など 1 回限りのタスクを実行するためのオブジェクトです。
Job を実行すると 1 つ以上の Pod を作成し、タスクが失敗した場合でも Pod の実行が成功するまで再試行します。
あらかじめ指定された数の Pod が正常に完了すると Job は完了したとみなされます。
CronJob
夜間バッチ等定期的なタスクを実行する際に使用するオブジェクトで、Linux の cron と同様の動きをします。
指定された時刻になると設定された Job を自動的に作成します。
まとめ
- Kubernetes は、「あるべき状態」を定義し、大規模なコンテナの管理やシステムの維持、通信、デプロイなどの運用を強力に支援してくれるソフトウェア
- Kubernetes には司令塔の役割をするコントロールプレーンと実際にアプリケーションが稼働するワーカーノードで構成され、これらを合わせてクラスターと呼ぶ
- Kubernetes には Pod や ReplicaSet、Deployment などの Kubernetes オブジェクトがあり、マニフェストファイルに記述された「あるべき状態」を体現する
さいごに
今回は Kubernetes の概要についてまとめてみました。
私自身が概要を知ったぐらいで実際の案件で触れたことが無いので、ローカルで Kubernetes 環境を再現できるツール（Kind や Minikube 等）を使ってもう少し深掘りしたいと思いました。
株式会社 BTM ではエンジニアの採用をしております。
ご興味がある方はぜひ コチラ をご覧ください。