Kubernetesのポッド導入の仕組み

「Kubernetes」を使ったDevOps導入で欠かせない、ポッドとノードの関係

コンテナによってアプリケーションとインフラの間で抽象化が進んでいる。だが「Kubernetes」の導入で成功を収めるには、アプリケーションコンポーネントの関係性を厳密に把握することが欠かせない。

　アプリケーションとインフラの構図がますます抽象化され、以前にも増して関係性の重要度が高まっている。DevOpsの導入では目標とリソースの両方を抽象化することが重要になる。

　コンテナ統合管理ツールの「Kubernetes」は、ノード（Node）とポッド（Pod）によって導入を抽象化する点が1つの強みだ。この2つの要素は、クラスタ（Cluster）、デプロイメント（Deployment）、サービス（Service）のコンテキストで機能する。管理者がKubernetesのポッドとノードを完全に理解するには、こうした関係性を把握しなければならない。

　アプリケーションはそれぞれ関連があり、ワークフローを通じて結び付く一連のコンポーネントから組み立てられる。これらのコンポーネントはそれぞれ、アプリケーションにとって欠かせないものであり、ホスティングと接続の要件に適合したインフラに導入しなければならない。ワークフローに基づくコンポーネントの関係性が消失するとどうなるだろう。その場合、アプリケーションを導入しても実行されなくなり、復元も不可能になる。Kubernetesのポッドはこのような関係性の情報を取り込む。

　Kubernetesのポッドとは、同じ場所に共存するコンテナセットを保持する仮想構造を指す。システム管理の観点から考えると、各ポッドはIPアドレスとポート一式を備え、複数のLinuxコンテナをホストする単一のサーバのようなものだ。ポッド内のコンテナの数を外部から確認することはできない。ポッドでは、アプリケーションがただ1つのレベルに抽象化されるためだ。ポッドには、ポッドと対応するコンポーネントが必要とする環境変数が全て保持される。そのためポッドは1つの完全な導入単位になる。

Kubernetesのポッド導入の仕組み

　Kubernetesのポッドはノードに導入される。ノードとは一種の論理マシンだ。ノードはコンテナのホスティングポイントで、仮想マシン（VM）の場合もあればベアメタルの場合もある。1つのノードに対してポッドを1つだけ導入することも、多数導入することも可能だ。通常、ノードはクラスタにグループ化される。クラスタはリソースのプールに相当するもので、アプリケーションをサポートするために連携する。ノードで障害が発生した場合は、Kubernetesによってノードがクラスタ内で導入し直される。ノードには、コンテナのタスクを管理するKubernetesランタイムエージェントや、コンテナシステムのランタイムも含まれている。ランタイムには、Dockerの「Docker」やCoreOSの「rkt」などがある。

　Kubernetesの導入はノードのクラスタが出発点になる。各クラスタは、連携する一連のアプリケーションのリソースプールになる。つまり、こうしたアプリケーションは、ワークフローや共有データベースを介して情報を交換するか、まとまったビジネス機能群をサポートする。クラスタサーバは、仮想化やクラウドリソースプールに似ており、導入時にポッドへマップされるノードから構成される。各クラスタには、クラスタ全体のKubernetesプロセスを調整するマスターノードが含まれる。

　デプロイメントは、ポッドをクラスタ内のノードに割り当てるプロセスだ。ノードの共有方法や、冗長性を確保するためにKubernetesによって作成されるポッドのレプリカ数などはポリシーによって決まる。クラスタ内のノードは、そのクラスタに関連付けられるアプリケーションの全体リソースとなる。ただし特定のポッドセットの使用を制限するためにノードをあらかじめ確保しておくことが可能だ。これはKubernetes用語でテイント（taint）と呼ばれる。Kubernetesのデプロイメントでは、ポッドをノードに割り当てた後に、ノードコンテナ管理システムをアクティブにし、パラメーターベースの導入を実行して待機する。ただし、その結果はまだ機能しない。

　デプロイメントが実行されるとKubernetesのポッドが配置されるが、その存在はまだ確認できない。つまり、外部にはまだ公開されていない。Kubernetesとコンテナ管理システムからはポッドが認識される。だが、IPアドレスとポートにアドレスマッピングが行われていない。このような外部への公開を可能にするのがサービスだ。

　サービスは、クラスタ内のポッドのコレクションで、運用環境内でのポッドの機能へのアクセス方法に関する指示が含まれる。機能をどこまで公開するかはサービスで定義できる。具体的には、クラスタ内部でのみ公開する。これがデフォルトになる。または、仮想プライベートネットワーク（VPN）上またはパブリックインターネットで外部に公開できる。管理者はサービスを定義する際に、一連のポッド間に作業を分散させる外部のロードバランサーを指定することもできる。

この記事の著者

関連記事

• 

  Dockerの新世代ユーティリティーが「コンテナ管理の決定版」になれない理由

• 

  「Docker」活用の鍵、コンテナ管理ツールの使いこなし術

• 

  AWS vs. Google vs. Azure、各クラウドのコンテナ管理サービスを比較

• 

  「コンテナオーケストレーション」ツールを比較　AWS、Google、Microsoftのどれが最強？

• 

  コンテナ vs. 仮想化、クラウドでアプリケーションを構築するならどっち？

新着ホワイトペーパー PR

• 製品資料
  [株式会社キーエンス] なぜRPA導入は頓挫する？　シナリオ作成の壁を乗り越える解決策とは
• 製品資料
  [株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？　PLMとの融合で実現する高速開発
• 事例
  [日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？　「新たな働き手」を支える3要素とは
• 製品資料
  [日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
• 製品資料
  [サイボウズ株式会社] AIが「わざわざ使うツール」になっていない？　業務で自然に使う導線にする秘訣